avr-gcc - velikost stacku v nejhorším případě?

[Ondrej Stanek]

Děkuji za odpovědi, ze souhrnu metod jsem si zvolil "Stack paint" 
řešení, v podstatě jsem kompletně převzal "InstrumentationCode.c" od 
Deana Camery. (Na tohle jméno narážím často a vždy v souvislosti s 
kvalitním a inspirujícím kódem). Do nějakých hrátek se statickou 
analýzou jsem se pouštět nechtěl, neboť by to mohlo být nechtěně 
zatíženo nějakou chybou nebo opomenutím z mojí strany.

Nechal jsem robota běžet ve všech možných režimech a konfiguracích, a 
nakonec jsem si přes UART vypsal kompletní dump SRAM.
Velice mě překvapilo, že stack ukousl ze "stejku" (0xDEADBEEF) jen 80 
bajtů. Čekal jsem tedy daleko více. Na druhou stranu, nikde v kódu 
explicitně nealokuji paměť na zásobníku, funkce mají střídmý počet 
parametrů, rekurze se nekoná, strom volání je poměrně mělký a interruptů 
je je jen pár a nevolají další funkce.

Buffer jsem přesunul do sekce .noinit, která se skutečně linkuje až za 
.bss sekci, jak jsem si ostatně ověřil z memory dumpu. Takže teď můžu 
vesele nafouknout buffer a přitom klidně spát.. Nechám si tam ještě 
navíc 100B rezervu pro stack, pro případ budoucí změny kódu nebo 
nečekaných událostí.

Ještě jednou díky za rady a odkazy!

Ondra Staněk



On 27.5.2014 00:15, Jan Waclawek wrote:
>> Jeden sposob je taky, ze v startup kode sa naplni cela pamat nejakym vzorom (s oblubou sa pouziva 0xDEADBEEF,
> https://github.com/abcminiuser/stackchecker/blob/master/StackChecker/Resources/InstrumentationCode.c
>
> _______________________________________________
> HW-list mailing list  -  sponsored by www.HW.cz
> Hw-list na list.hw.cz
> http://list.hw.cz/mailman/listinfo/hw-list

On 27.5.2014 19:28, Miroslav Mraz wrote:
> command cmd1Buf[BUFLEN]__attribute__((section(".xxx")));