Cortex-M0 gcc problem

[Jaroslav Buchta]

Ja mam na STM32F4 jinou zahadu dneska, asi je to moji neznalosti, jedna 
se o tento projekt: http://mcu.cz/news.php?extend.2800

Portoval jsem to bez problemu na GNU GCC s prostredim C::B bez problemu, 
fungovalo to skvele hned, ale jen bez optimalizace Os (bez to ma asi 
90kB, s asi 38kB)
Problem byl zde v souboru stm32f4_discovery.c zde:
GPIO_TypeDef* const GPIO_PORT[LEDn] = {LED4_GPIO_PORT, LED3_GPIO_PORT, 
LED5_GPIO_PORT,
                                  LED6_GPIO_PORT};

hloupe pole konstantnich ukazatelu, definovane mimo funkci cili staticky 
ale nebylo tam puvodne const. Po optimalizaci se to nejak zpotvorilo a 
prvni ukazatel byl OK, dalsi za konec RAM (aspon kdyz se prvrk pole 
predal jako parametr fce) a pak to pri pouziti to spadlo v void 
HardFault_Handler(void) do nekonecne smycky...

void STM32F4_Discovery_LEDInit(Led_TypeDef Led)
{
   GPIO_InitTypeDef  GPIO_InitStructure;

   /* Enable the GPIO_LED Clock */
   RCC_AHB1PeriphClockCmd(GPIO_CLK[Led], ENABLE);

   /* Configure the GPIO_LED pin */
   GPIO_InitStructure.GPIO_Pin = GPIO_PIN[Led];
   GPIO_InitStructure.GPIO_Mode = GPIO_Mode_OUT;
   GPIO_InitStructure.GPIO_OType = GPIO_OType_PP;
   GPIO_InitStructure.GPIO_PuPd = GPIO_PuPd_UP;
   GPIO_InitStructure.GPIO_Speed = GPIO_Speed_50MHz;
TADY!   GPIO_Init(GPIO_PORT[Led], &GPIO_InitStructure);
}


Trosku mne to znervoznuje, nenapada me, proc to takhle dopadlo. Po 
doplneni const to ovsem zda se funguje normalne... Jen jsou asi 4 
warningy se zapnutou optimalizaci, to budu zkoumat pozdeji.
Prekvapilo me taky, ze projekt na obyc. VCP je tak rozsahly. Ted se 
pustim do zkoumani ethernetu ;-)

Dne 30. 3. 2013 19:10, Miroslav Mraz napsal(a):
> Gcc je z gcc.gnu.org, vlastní kompilace (parametry v minulém příspěvku),
> ty knihovny jsou nějak špatně, na webu jsem našel spoustu nápadů, jak to
> zkompilovat, aby to bylo dobře. Jenže se nedozvíte, jak to nakonec
> dopadlo. Podstatná informace je ten patch od Yagarto, protože ho máte
> vyzkoušený. Pokud byste mi ho poskytl, včetně parametrů kompilace, byl
> bych vám nesmírně zauzlován. Ale pokud tam máte zakázán interworking,
> asi se na to vykašlu a zůstanu u toho wraperu, co mám. Nebo zkusím
> gcc-4.8.0.
> Jsem asi nějakej divnej, ale tyhle nástroje si vytvářím sám a nepoužívám
> ani ty Eklipsy a Korálová studia, takže mě STM donutili napsat si k tomu
> Makefile, ale není to taková hrůza.
> To demo co mají v F4 Discovery jsem rozchodil za dnešní odpoledne,
> běželo to na první pokus - a to je složitý jako cukrovar. Dokonce i tou
> myškou mi to hýbe.
>
> Mrazík
>
> Milan B. píše v So 30. 03. 2013 v 16:56 +0100:
>> On 30. 3. 2013 16:12, Miroslav Mraz wrote:
>>> Když si o to říkáte, prosím. Domníval jsem se, že je to poměrně známý
>>> problém. Takže minimální main.c:
>> U mna - po skompilovani a zlinkovani, vyzera disassemblovany zaciatok
>> prilinkovanej funkcie asi takto (tu adresu si netreba vsimat, mapu som
>> neriesil):
>>
>> 00008020 <__aeabi_idiv>:
>>       8020:       2900            cmp     r1, #0
>>       8022:       d041            beq.n   80a8 <.divsi3_skip_div0_test+0x84>
>>
>> 00008024 <.divsi3_skip_div0_test>:
>>       8024:       b410            push    {r4}
>>       8026:       1c04            adds    r4, r0, #0
>>
>> Takze thumb. Kompilovane v 4.7.2 + patch z Yagarto, vlastna kompilacia
>> pod Linuxom. Podobny vysledok aj u GCC ARM Embedded.
>>
>> Problem nevidim ani tak v kompilatore, ako skor v nespravnom vybere
>> vhodnej verzie libgcc pri linkovani. Skontrolujte, ci sa pouzije spravna
>> multilib kniznica (parameter -v pomoze) - u mna je to kniznica z
>> adresara ...../lib/gcc/arm-none-eabi/4.7.2/thumb/v6m , co je pre M0 spravne.
>>
>> Kompilator pochadza odkial? Vlastna kompilacia? Su vygenerovane spravne
>> varianty kniznic?
>>
>> -m-
>
> _______________________________________________
> HW-list mailing list  -  sponsored by www.HW.cz
> Hw-list na list.hw.cz
> http://list.hw.cz/mailman/listinfo/hw-list