A volatile annyit mond a compilernek, hogy a változó tartalma megváltozhat két elérés között akkor is, ha az adott kódban nem változtat rajta semmi. Ezért mindig az adott címen éri el.
Tipikus esete ennek, amikor valami megszakíthatja a kód futását, például interrupt handler vagy OS esetén másik task. Ahogy fentebb írtam a cache egy transzparens hardver, az ellen nem véd.
Harvard architektúra esetén ez annyival bonyolódik, hogy a programkód és az adatok külön memóriában (buszon) vannak és ha van cache, az sem közös. Mikrokontrollerek esetén a konstans adatok is a programkóddal együtt a flashben tárolódnak, hogy ne vesszenek el. Ezért ott bevett dolog, hogy bekapcsoláskor ezeket a konstansokat beolvassa a RAM-ba, ahol a többi adat is van, és soha többé nem nézi meg őket a flashban. Általában speciális flash elérési utasításokkal lehet rávenni a CPU-t, hogy ott keresse midnen egyes alkalommal az adatot. A volatile ebben sem segít.

Akkor ezt beszéld meg a fordítókkal is, hogy eszerint működjenek, mert amikkel nekem dolgom volt, azok konzekvensen úgy működtek, ahogy már leírtam!!
Amúgy örülök, hogy begugliztad magadnak a leírásokat, és azokat adod itt elő egy az egyben, ezt más is meg tudja tenni! Ami már nehezebb, az a gyakorlati tényekkel szembemenni...
Egyébként, az még lehetséges, hogy optimalizációs beállítás kérdése is ennek a működése..., nálam általában szinte mindig méretre van maximálisan optimalizálva a kód, néha egyes modulok sebességre, de olyan szinte sohasincs, hogy optimalizálás/debug nélküli verzió fut...

Sziasztok!
Embitzben programozok STM32F103-at:
lassú külső portok figyelése, vezérlése, grafikus LCD-ra való rajzolás.A portok között van, amit sima pollinggal, van, amit megszakítással figyelek. Használok Timereket, de az adott rész működésébe nem szólnak bele.
A gondom a következő: egy hibát keresve debugolom, de gyakran más eredmények születnek a continuous és a next step debug allkalmazásakor. Figyelem a portokat külön is, és azt kizárnám, hogy a menet közbeni portok változása, vagy zajossága okozza a gondomat.
Nincs watchdog, a Timerek itt nem játszanak, -O0 optimalizációval fordítom.
Kódot nem mellékelek, mert elég nagy a forrás. Nem kódvadászatra, inkább tanácsra lenne szükségem, hogy mire kellene még figyelnem?
(A debugolást még az is nehezítette, hogy ST-link V3-at használtam, de azzal gyakran megszakad a kapcsolat. Lehet, az USB kábel vacakol a nagyobb sebesség miatt. ST-link V2-vel úgy tűnik, hogy stabil az EBlink.)
Egyenként léptetve a program jól működik, de folyamatos módban, live variable-t figyelve már gyakran hibázik. Debug nélkül simán futtatva is hibázik.
GPIO-IDR regisztereket figyelve mintha régi állapotot olvasna időnként. Nem használok API-kat, simán a regisztert olvasom: if((GPIOA->IDR) & GPIO_IDR_IDR11) counter++;

Lehet, hogy hülyeséget csináltam. Tegnap órákat vacakoltam ezzel, most meg beugrott - miután leírtam a kérdésem -, hogy az egyik bemeneten egy viszonylag nagy időállandójú integrátort tettem, és lehet, hogy a bemenet változása után nem várok elég időt a lekérdezéssel.
Sajnos, csak hétfőn tudom ezt ellenőrizni.

Kedves Fórumtársak!

Valaki megmérte, de legalábbis feltöltötte valahova az ATMEGA328p ADC valódi karakterisztikáját; honnan indul, milyen görbe mentén, meddig mér valójában... stb..

Ha valakinek megvan legyen szíves feltölteni.

Köszönöm szépen!

Derűs napot; Tambi