Založen: May 22, 2013 Příspěvky: 325 Bydliště: Psáry JN79GW
Zaslal: út duben 05 2016, 21:04 Předmět:
mtajovsky napsal(a):
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? _________________ Jirka
Založen: Sep 19, 2007 Příspěvky: 3698 Bydliště: Praha
Zaslal: st duben 06 2016, 9:38 Předmět:
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
Založen: May 22, 2013 Příspěvky: 325 Bydliště: Psáry JN79GW
Zaslal: čt duben 07 2016, 6:54 Předmět:
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á. _________________ Jirka
Založen: Nov 20, 2012 Příspěvky: 1453 Bydliště: Praha
Zaslal: čt duben 07 2016, 9:39 Předmět:
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:
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.
Založen: May 22, 2013 Příspěvky: 325 Bydliště: Psáry JN79GW
Zaslal: čt duben 07 2016, 18:51 Předmět:
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. _________________ Jirka
Založen: Sep 19, 2007 Příspěvky: 3698 Bydliště: Praha
Zaslal: pá duben 08 2016, 12:14 Předmět:
Jirka525 napsal(a):
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.
Založen: May 22, 2013 Příspěvky: 325 Bydliště: Psáry JN79GW
Zaslal: pá duben 08 2016, 17:37 Předmět:
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é. _________________ Jirka
Časy uváděny v GMT + 1 hodina Jdi na stránku Předchozí1, 2
Strana 2 z 2
Nemůžete odesílat nové téma do tohoto fóra. Nemůžete odpovídat na témata v tomto fóru. Nemůžete upravovat své příspěvky v tomto fóru. Nemůžete mazat své příspěvky v tomto fóru. Nemůžete hlasovat v tomto fóru. Nemůžete připojovat soubory k příspěvkům Můžete stahovat a prohlížet přiložené soubory
Informace na portálu Elektro bastlírny jsou prezentovány za účelem vzdělání čtenářů a rozšíření zájmu o elektroniku. Autoři článků na serveru neberou žádnou zodpovědnost za škody vzniklé těmito zapojeními. Rovněž neberou žádnou odpovědnost za případnou újmu na zdraví vzniklou úrazem elektrickým proudem. Autoři a správci těchto stránek nepřejímají záruku za správnost zveřejněných materiálů. Předkládané informace a zapojení jsou zveřejněny bez ohledu na případné patenty třetích osob. Nároky na odškodnění na základě změn, chyb nebo vynechání jsou zásadně vyloučeny. Všechny registrované nebo jiné obchodní známky zde použité jsou majetkem jejich vlastníků. Uvedením nejsou zpochybněna z toho vyplývající vlastnická práva. Použití konstrukcí v rozporu se zákonem je přísně zakázáno. Vzhledem k tomu, že původ předkládaných materiálů nelze žádným způsobem dohledat, nelze je použít pro komerční účely! Tento nekomerční server nemá z uvedených zapojení či konstrukcí žádný zisk. Nezodpovídáme za pravost předkládaných materiálů třetími osobami a jejich původ. V případě, že zjistíte porušení autorského práva či jiné nesrovnalosti, kontaktujte administrátory na diskuzním fóru EB.