Kontrola zásobníku v Atmel Studiu

[mtajovsky]

Tak použijte data breakpoint:

http://www.atmel.com/webdoc/atmelstudio/atmelstudio.debugging.databreakpoint.window.html

[mtajovsky]

Tak použijte data breakpoint:

http://www.atmel.com/webdoc/atmelstudio/atmelstudio.debugging.databreakpoint.window.html

[Jirka525]

[FHonza]

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

[FHonza]

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

[mtajovsky]

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%C3%AD_programov%C3%A1n%C3%AD

[mtajovsky]

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%C3%AD_programov%C3%A1n%C3%AD

[Jirka525]

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á.

[FHonza]

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:

[FHonza]

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:

[Jirka525]

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.

[mtajovsky]

[mtajovsky]

[Jirka525]

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é.