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

Sziasztok!

Frekvenciát szeretnék mérni STM32H753 mikrovezérlővel input capture dma segítségével. 0-4000Hz között, kb. TIM2 és TIM5 CH1 bemeneteket kiválasztottam, DMA-t beállítottam hozzá.

Amit találtam projektet, hibát ad kettő sorra. Viszont ez F373 mikrovezérlőre van:


A hiba a képen, mert nem engedte betenni.

Bármilyen segítséget szívesen fogadok!
Köszönöm

Miért nem a H753-hoz való input capture példából indulsz ki?

Nem találom a dma példát, csak simát láttam.

A NUCLEO-H743ZI példái között nézted?
Van TIM_InputCapture és van TIM_DMA is. Szerintem ezekből könnyebb összehozni, mint egy másik MCU családból áthozni.

Igen, az input capture az IT. Dma-t nem néztem.

Megnézem majd. Komplett példából jobban ment volna

Sima frekvencia méréshez mi szükség DMA-ra?

Nem sima frekvenciamérés. Ezen kívül elég sok dolog van a projektben. Komplett touchgfx. 7csatorna adc dmaval(ez működik). Can busz kezelés.

Nem kétlem, hogy más dolga is van a procinak..., csak akkor sem értem, hogy egy hardveres számláláshoz mi szükség DMA-ra?!

Az a tippem, hogy CPU idő nélkül szeretne hosszabb időn keresztül, rendszeresen frekvenciát mérni, és az eredményeket eltenni a RAM-ba.

Cpu idő nélkül szeretném számolni.
Fordulatszám mérés és sebesség

Alacsony frekvenciát csak reciprok méréssel érdemes mérni! Ilyen magas órajel esetén viszont még 1 sec alatt is bődületes felbontás jön ki! 32 bites hardveres számláló pedig nem fog túlcsordulni nagyon hosszú idő alatt csak. Nem hinném, hogy az kevés lenne a feladathoz...

A méréshez nem is kell CPU erőforrás, csak hardveres számláló! A számoláshoz pedig mindenképpen kell a végén...

Tehát aztmondod a példák közötti input capture is jó nekem?

Bármelyik számláló jó, amelyiknek az engedélyezése külső lábhoz rendelhető...

Sziasztok! Keilben dolgozom. Van egy normál program rész, és van egy szoftver update rész. Utóbbi 0x7000 felett, section _at-ekkel fix cimen.
Csakhogy, a fordito minduntalan a normál programrészből is rak fel valamit, a update rész UTÁNra. Úgy bukott le hogy olvasható dolgot, const char* stringet is feltett, de általában kódot rak.
Hogy lehet a normál programrésznek megmondani hogy 7000 fölé soha semmit?

Nocsak, még csak nem is "igazi" kódot rak oda , hanem a ram inicializálás értékeit. Például
char SRV[8] = "PMIN189"; -ből a PMIN189 -et, meg még pár időzítés jellegzetes kezdőértékét felismertem. Vagyis nem általam írott függvény/kód , hanem rendszer init függvény, ill annak adatmezeje lehet. Na ez különösen ne kerüljön oda

Szerintem a scatter fájlban kell megadni a sectionokat, és ott meg tudod adni hogy mit hova tegyen. Sorry, pontosabban nem tudom elmondani, mert évekkel ezelőtt írkáltam ilyeneket.

GCC-ben pedig a linker scriptben. De a Keil cseppet más.

Az most már biztos, hogy a reset_handlert rakja fel oda, kisakkoztam (lehet h mást is de azt biztosan) Namost a Keilben a reset_handler nem létezik szöveges formában, egyből az .o-ba kerül. Hogyan tudom mégis máshova tenni? (Szegény chatgpt-t már teljesen lefárasztottam, már csak önmagát tudja ismételni, nem bírja megugorni h nincs hozzáférhető reset_handler.)

Ezt a linkert biztos hogy kutyák ivadékainak ivadékai írták, egymásnak (nagyon finom voltam). Nehogy már véletlenül egymás után folyamatosan tenné a területeket , 0tól felfelé.... Mindig kell legyen nagy üres terület, és mindig valami UTÁN kell tenni a valamit!
Ez csak jó bonyolult scatter file-lal oldható meg, amit folyamatosan piszkálok ahogy a program nő. (ide jönne egy szaftos káromkodás)

Fütyüld ki!!!

Nem tudom melyik fordítót használod (nem írtad) de próbáld ki a másikat, hátha az logikusabban működik. Valami olyan is rémlik, hogy a 6-os kompatibilis a GCC linker szintakszissal, de ebben nem vagyok biztos.

5-ösöm valamiért nincs csak 6. A c90/c99-et próbáltam, mert valaki javasolta, lényegi különbség nincs. Nem a fordító hülye itt, hanem a linker.

Abban segítsetek légyszi, hogy tegyük fel hogy van linker script( keilben scatter file), 3 szekcióval (start, normál, szoftver update), akkor hogyan lehet több (sok) függvényt egyszerre egy adott szekcióba tenni. Én nem találtam rá megoldást. Nem szeretném egyesével mind az egymillió függvényhez odabiggyeszteni hogy ki melyik szekció tagja. Nem életszerű.

Szia!
Nem tudom,hogy aktuális -e,és bár én más kontrolleren csinálom az upgrade-eket,és én is a végére pakolgattam. Nálam csak az volt a megoldás,hogy ne pakoljon a végére(mert nagyon szeretett volna ),hogy az upgrade rész utáni területet teljesen lefoglaltam 1 tömbbel.