Mennyi adat tárolásáról van szó? Lehet egyszerűbb lenne azokat máshol menteni más formában. Az is benne van a pakliban, hogy a 100 000 ciklus nem annyi, hanem jóval kevesebb.

Melyik típus tud 100 ezer írást? Az stm32-re pl. csak 10 ezret garantálnak. Amúgy célszerű valahogy optimalizálni, hogy ne legyen annyira sokat írva. Milyen sűrűn változnak az adatok? Meg van oldva, hogy csak akkor írja a program memóriát, ha az adatok megváltoztak?

Gépészeti rendszer és az egyik hőszivattyú naponta vagy 30-40-szer leállt és hibaüzenetet dob, amit naplóznunk kell a BMS felé.

SD kártyára az adatokat pl. OpenLog modul segítségével, csak egy UART kell hozzá. Annó teszteltem, bőven jobb volt a vártnál: Bővebben: Link. Ha nagyon tutira akarsz menni, két modult is használhatsz egyszerre, filléres tétel.

Ez kevesebb, mint 4k ciklust jelentene csak! Ráadásul, ha jól értem, mivel megmarad minden log, még csak ugyanazok a terültetek sincsenek írva minden esetben, így még ennek is csak a töredéke kellene legyen a ciklusszám...
Szinte biztos, hogy valami nagyon nincs egzaktul használva, vagy kivitelezve e funkció körül....

Vagy ennyit tud a kínai mikrovezérlő.

Van SD kártya, így ez is opció és ráadásul maximum cserélem, ha tönkremegy, olcsóbb, mint a teljes HMI.

Van FRAM memória is, amiből hajdanában én egy RAMTRON 1 Mbites mintát gyűjtöttem be (8 lábú, I2C), állítólag 10^14 írási ciklust bír ki.

I2C/SPI EEROM is megoldás lehet. Ez egy tokba épített SRAM, EEPROM és tápfeszültség figyelő. Bármennyiszer lehet írni, hiszen az adat a RAMba kerül. Ha a beépített tápfeszültség figyelő észreveszi, hogy elmegy a táp, akkor az IC melletti kondenzátorban tárolt energia segítségével elmenti a teljes RAMot az EEPROMba. Induláskor pedig betölti. A programozó számára teljesen transzparens.

Nem mi gyártottuk a HMI-t. Ezen már nem segít semmi. Olyan, amilyen. Utólag erre nem nagyon lehet ráapplikálni semmit. Ráadásul az IDE felülete is elég kötött. Ha rá is hakelnék bármilyen külső tárolót, nem tudom meghívni az IDE felületről.

Ha így áll a történet, szerintem ne agonizáljatok rajta...valami szünetmentes dolgot pakoljatok alá, és az olcsóbban megoldja... )

Nem tudom, ki, hogyan értelmezi. Ezt küldte a gyártó (kép).

EERAM a neve...
Bővebben: Link

Sziasztok!

STM32F103C8 (bluepill modul) ADC üzemmódjával ismerkedek, és szíííívok.

A célom az lenne, hogy 3-5 analóg csatorna jelét mérjem, s a főprogramban minidig rendelkezésre álljon egy közel friss adat. (Nem szeretném, hogy a főprogram szórakozzon azzal, hogy indítgassa a mérést.)
A ST pdf leírás és a Youtube videók szerint erre kiválóan alkalmas lenne az ADC és DMA páros.
Józan paraszti ésszel és a könnyítéshez egy kis Youtube videóval (Bővebben: Link) összeállítottam a programom. De az gyakorlatilag elszáll.

Nevezetesen a probléma az lehet, hogy ha a scan üzemmód és a Continuous üzemmód is engedélyezett és a DMA mód Circular, akkor elszáll a program.
Ha csak a scan üzemmódot kapcsolom be, és időnként elindítom a HAL_ADC_Start_DMA() függvénnyel a mérést a kijelölt csatorna sorra, akkor minden rendben, lefut az egyszeri mérési sorozat.

Kérdésem:
Mi a francot nem állítok be megfelelően még, hogy a HAL_ADC_Start_DMA() függvényt csak egyetlen egyszer kelljen elindítani?

Üdv!
Z.

Lefagyni leginkább úgy tud egy ilyen program, ha véletlenül bekapcsoltad az interruptokat, viszont az ISR handlert nem állítottad be. Nem lehet, hogy ez áll a hiba hátterében? Ebből is két féle lehetséges: felkonfigurálatlan interrupt általában a hiba handlerben végződik, ami alapból egy végtelen ciklus. Vagy fel van konfigurálva az interrupt, de az nem törli az interruptot kiváltó státuszjelző bitet (lásd adatlap, van ami magától törlődik, de van amit törölni kell manuálisan), és amikor az ISR kilép, egyből újrahívódik, a főprogram pedig soha nem tud futni.

Egy másik eset, amit el tudok képzelni, és amitől lefagyás lehet, az az ha a DMA hibásan van felparaméterezve és olyan memóriaterületet ír felül, ami elrontja a program futását, például a stacket.

Debuggered van? Azzal talán el lehet fogni mindkét esetet, bár nem egyszerű.

A DMA-nál szerintem egy kicsit egyszerűbb interrupttal megvalósítani ezt. Persze kevésbé hatékony, de a főprogramból így sem kell törődni a folyamattal: beállítod, hogy amikor kész az ADC, akkor legyen en interrupt. Ebben az interruptban az eredményt egy tömbbe írod. Utána pedig körbe-körbe a következő ADC inputra indítasz egy új ADC-t.

Az architektúrán a 32 bites érték írása atomi (tudtommal), így még ISR kizárásos védelmet sem kell használni sehol, a főprogramban elegendő csak kiolvasni a tömb megfelelő eleméből az ADC legfrissebb értékét.

Ja, és konkrét segítséghez meg kell osztanod a kódot, hátha valakinek lesz türelme kielemezni.

Ehhez szerintem nem kell DMA, bőven elég az, hogy az ADC IRQ_Handler-ben kiolvasod a konvertálás eredményét, és berakod egy globális változóba. Nyilván DMA-val szebb, gyorsabb, kulturáltabb stb. de első lépésben hagyd ki, olvasd ki az eredményt a megszakításban.

Úgy emlékszem, hogy a reguláris csatornák pásztázása eleve DMA-t igényel (mert az ADC-nek nincs hová tennie az adatokat). Legfeljebb 5 csatorna esetén ezt úgy lehet kijátszani, hogy egy reguláris és néhány (legfeljebb négy) injektált csatornát konfigurálunk. Az injektált csatornáknak ugyanis van saját adatregisztere.

A 2019/2020 évadból a 2019. december 5-i és 2019. december 19-i előadásokat ajánlom (STM32F103C8 + Keil)

A 2020/2021 évadból a 2020. november 5-i és 2020. december 3-i előadásokat ajánlom (STM32F446RE és STM32F103C8 + STM32CubeIdes)

Sajnos, pont olyan példám nincs, ami a kérdezőn segítene...

Köszönöm mindenki válaszát, aki foglalkozott a kérdéssel!

Ha valakit érdekel a kód, s tudna vele foglalkozni, akkor megosztom természetesen, jelzésre. Semmi titok nincs benne, egyszerű tanulgatás.
A debug-ot még nem csináltam sosem ezzel az eszközzel, s elsőre nem is adta magát nekem az st-link v2 klónhoz, vagy a v3 eredetihez. Ennek tanulása is hátra van még. Van hová fejlődni még bőven.

A githubon a hoverboard átalakításnál találsz erre példát C-ben, Emmanuel Feru jóvoltából
Ha jól emlékszem, öt csatornát mért egyszerre, ráadásul duplán: adc1 és adc2 is 5-5 cdstornát mért.

Köszönöm a tippet!

Elég összetett a példa, de sok érdekesség van a kódban.
Alaposan el kell mélyülni benne.

Nálam így van beállítva egy G4-en. F1-nél is hasonló.

Elszállás alatt mit értesz? Hol áll meg a program?

Simán elképzelhető.


Szerintem DMA-val a legegyszerűbb. Nagyjából 4 kattintás CubeMX-ben. Utána még két sor kód, és onnantól folyamatosan frissülő tömbben lesznek a mért értékek.

Sziasztok! STM32F103 az alany. Ez van a bluepill-en is. Szeretnék egy saját áramkört csinálni ugyanezzel a procival, de a saját szükségleteimnek megfelelően. A 8Mhz kvarc kell rá az órajel miatt, főleg mert kell a pontos.(tudom, hogy van belső RC oszcillátora is). Viszont mivel óra nem lesz róla hajtva, ezért és a 32,768kHz-es kristályt lehagynám. Feltételezem nem kell a működéshez. Igazam van, a többit meg már megoldom Válaszokat előre is köszönöm.

A 32,768kHz-es órakvarc kizárólag az RTC (real time clock) periféria működéséhez szükséges. A proci nélküle is működik.

Az vajon mitől lehet, hogy egy LDR fény értékeit mérem egy NUCLEO-val és ami eddig 70 és kb 920 tartományba esett az most kb 920 és 690 érék közé esik ? Azaz 690 érték alá mostanában nem megy pedig azelőtt lement akár 70-ig is. Az LDR olyan egyszerű hogy annak a hibájára nem gondolok, de amúgy is átkötöttem egy másik portra és ott is ugyanazt mérte .

Ezt elég egyszerű validálni: állandó fény mellett megméred egy multiméterrel a feszültséget és összenézed azzal, amit az MCU mért. Ha eltérés van, akkor az MCU ADC hibázik, ha nincs, akkor meg a LDR hibázik. Ha megvan hogy mi hibázik, akkor közelebb leszel ahhoz is, hogy mi lehet az oka.

Most próbaképpen kicseréltem az LDR-t (elvileg ugyanaz a tipus mert egyszerre lett rendelve egy pár darab ugyanabból a tipusból, bár az elég nagy baj hogy nincs rájuk irva semmi) és ugyanazt méri, tehát kicsi a valószinűsége hogy az LDR-el van baj. Ha meg MCU ADC-vel van baj akkor az nem úgy kéne jelentkezzen, hogy semmit nem mér?

Szia!

Az MCU ADC referencia feszültsége nem változott meg? Vagy a referencia forrás kiválasztásának beállítása? Vagy érintkezés hiba valahol?

Nem , minden ugyanaz...

Az LDR az passzív dolog ugye, tehát ő nem ad feszültséget, csak az ellenállása változik fény hatására? Akkor ő feszültség osztóban működik, vagy áramgenerátor hajt át rajta áramot és emiatt esik rajta majd feszültség. A környezete is hozza amit kell? Az LDR helyett jól megválasztott fix ellenállásokat használva is magas értékeket mér az MCU?