Kontrola zásobníku v Atmel Studiu

Zpráva

#16 Příspěvek od **mtajovsky** » 05 dub 2016, 15:28

Tak použijte data breakpoint:

http://www.atmel.com/webdoc/atmelstudio ... indow.html

Jirka525 · #17 Příspěvek od **Jirka525** » 05 dub 2016, 22:04

mtajovsky píše:Tak použijte data breakpoint:

Děkuji za radu, domnívám se, že tohle bude případně 2. krok. Když mě to přepisovalo konstanty, tak jsem poměrně snadno poznal, co se přepsalo. Nyní to s největší pravděpodobností přepisuje proměnné, které za chodu programu přirozeně mění svoji hodnotu. Momentálně jsem na kroku 0, snažím se identifikovat adresy, které se samovolně přepisují. Další záludnost spočívá v tom, že ke zhroucení dojde až po několika hodinách provozu. Zatím prověřuji na sucho části programu, kde používám nepřímé adresování. Jestli nic nenajdu, tak se vydám tou trnitou cestou ladění SW. Nebo máte jiné postupy pro vyhledávání podobných chyb?

#18 Příspěvek od **FHonza** » 06 dub 2016, 10:35

První co mě napadá: Nejsou to náhodou globální proměnné použité v přerušení, kterým chybí "volatile" ?

#19 Příspěvek od **mtajovsky** » 06 dub 2016, 10:38

Jiná než trnitá cesta není

a já obvykle ihned přecházím na debug s živými daty. Na chyby je třeba myslet již při psaní kódu a programovat defenzívně. Kontrolovat v důležitých bodech programu, jestli se neděje něco, co nemá být. Příklad - vypršel časovač, ačkoliv v daném stavu programu neměl být aktivován. Nebo jako index výběru hodnoty z nějakého pole byla vypočítána hodnota mimo rozsah pole, a tak dále. V tuto chvíli ihned volat nějakou rutinu pro fatální chybu a ze stacktrace se dá poznat, odkud jsme se tam dostali. Více viz https://cs.wikipedia.org/wiki/Defenzivn ... %A1n%C3%AD

Jirka525 · #20 Příspěvek od **Jirka525** » 07 dub 2016, 07:54

FHonzo a mtajovsky děkuji za náměty. Skutečně jsem našel proměnné v přerušení, které neměly nastaven kvalifikátor volatile. Tak jsem to opravil, spolu s dalšími drobnými chybami, o kterých nejsem přesvědčen, že to jsou vysloveně chyby, spíš takové nešikovnosti, které by za určitých okolností mohly zlobit. Pracovalo to celý večer bez chyby. Na plácání po zádech je ale příliš brzy, chyba o které se tu bavíme se projevila až po několika hodinách nepřetržitého provozu. A já jsem dost často restartoval.
Ten kvalifikátor volatile je pro mě tak trochu záhadou. Dočetl jsem se že kompilátor na ně nepoužívá optimalizaci. Z praxe jsem zjistil, že je vhodné používat jej na globální proměnné, pomocí kterých přenáším data mezi hlavním programem a funkcemi nebo mezi funkcemi. V určitých případech, a zase nejsem schopen to detailně popsat, deklarovaná globální proměnná bez kvalifikátoru volatile je problematická a program nefunguje správně. Pro sebe jsem si to vysvětlil tak, že kompilátor si na adresy globálních proměnných, které nemají kvalifikátor volatile, umisťuje dočasně jiné proměnné. Takhle přesně, jak to tu píši jsem se to nikde nedočetl. Myslíte, že takováto zvěrstva jsou skutečně možná? To by pak vysvětlovalo různé záhady, které se mě staly při programování MCU.
To defenzivní programování je zajímavý přístup. Musím si to ale trošku přerovnat v hlavě, zatím nemám moc nápadů, jak to prakticky realizovat. Já jsem byl odkojený strukturovaným programováním, když jsem po škole nastoupil do 1. zaměstnání a dodnes se snažím tyto zásady ctít, i když jsem se pak živil programováním PLC, kde je ta problematika úplně jiná.

#21 Příspěvek od **FHonza** » 07 dub 2016, 10:39

matematické operace lze provádět pouze v registrech a ne v RAM. No a protože načtení proměnné z RAM do registru a po provedení operace její opětné uložení do RAM "stojí" kus kódu i rychlosti, snaží se překladač udržovat proměnné při optimalizaci pokud možno v registrech. Zkusim to vysvětlit na příkladu:

Kód: Vybrat vše

A+=2
A*=2

bez optimalizace překladač vygeneruje zhruba toto
1. načtení A z RAM do registru
2. přičtení dvojky
3. uložení A z registru do RAM
4. načtení A z RAM do registru
5. vynásobení dvěma
6. uložení A z registru do RAM

evidentně je bod 3 a 4 zbytečný, takže při optimalizaci se vyhodí. Kód je menší, rychlejší, všichni jsou spokojeni. Jenže když bude proměnná A použitá v přerušení a to se vykoná mezi body 2 a 5, tak je malér. V přerušení se načte hodnota proměnné A z RAM do registru, která je ale v tu chvíli neaktuální. Proto se používá klíčové slovo volatile, které říká (kromě jiného) že taková proměnná se musí vždy uložit do RAM po každé operaci a musí se z RAM načíst před každou operací.

Ve skutečnosti je to ještě o trochu složitější, protože překladač se snaží pokud možno udržovat proměnnou v registru po celou dobu její platnosti (když je na to v registrech místo). Při optimalizaci může překladač vyhodnotit, že se daná proměnná v oboru své platnosti již nepoužije a proto v registrech "zaujme" její místo jiná proměnná. u volatile proměnné se tato optimalizace nepoužije.

Tak snad je to trochu srozumitelné

Jirka525 · #22 Příspěvek od **Jirka525** » 07 dub 2016, 19:51

Honzo děkuji za vysvětlení. Tohle jsem přesně potřeboval vědět. Podle tvého příspěvku je povinná deklarace volatile proměnných pouze pro proměnné, které jsou využívány v přerušovacích procedurách. Z toho vyplývá, že deklarovat ostatní globální proměnné jako volatile je nadbytečné a skoro bych řekl kontraproduktivní. Člověk omezuje možnosti optimalizace kódu. Stejně se nemohu zbavit pocitu, že jsou i další důvody pro deklaraci volatile proměnných. Bohužel to nemám podložené znalostmi ale pouze zkušenostmi.

#23 Příspěvek od **mtajovsky** » 08 dub 2016, 13:14

Jirka525 píše:Stejně se nemohu zbavit pocitu, že jsou i další důvody pro deklaraci volatile proměnných. Bohužel to nemám podložené znalostmi ale pouze zkušenostmi.

Může to být případ vícevláknových aplikací, kde vlákna sdílejí společná data. Vlákna se však u malých MCU většinou nepoužívají. Ovšem samotný design vícevláknových aplikací by měl vyloučit takováto rizika pomocí prostředků zamykání a synchronizace vláken.

Jirka525 · #24 Příspěvek od **Jirka525** » 08 dub 2016, 18:37

Vícevláknové aplikace jsem zatím naštěstí dělat nemusel. Několikrát se mě stalo, že nějaký SW vykazoval nelogické chování, debuggerem jsem chybu nenašel a když jsem vyčerpal rozumné možnosti, začal jsem zkoušet i ty "nerozumné" a problém se vyřešil třeba vypnutím optimalizace. Na základě těchto zkušeností jsem nabyl dojmu, že kompilátor pracuje nějak podivně s globálními proměnnými, a proto jsem si pro sebe stanovil zásady - pro přenos informací mezi funkcemi nebo mezi funkcemi a hlavním programem používat volatilní proměnné. To ale z dnešního pohledu vypadá, jako příliš silné omezení. Jsem rád, že jste mě osvětlili princip optimalizace. Já v tom hledal nějaké temné síly a ono je to vlastně naprosto logické.