Nem akarom szétoffolni a topicot. Soha nem dolgoztam olyan helyen, ahol bármi ilyen elvárás lett volna, és valószínüleg nem is foogok. Pont az ilyen elvárások miatt. A C kódot a gépnek írom, tömören. A kommentet a programozóknak. Természetesen magamnak is, ahogy fent említetted. Mert valóban változunk, változik a stílusunk, és egy bonyolult dolgot nehéz a forrásból megérteni, ha nincs komment.

A gyári STM32F103-al (bluepill) valójában mennyire kompatibilis a CKS32F103 (szintén bluepill) ?
Arduinoval használnám, észre fogom venni a különbséget ?

köszi a válaszokat.

Szia kiborg!
Szerintem nem azért nem válaszolt senki, mert nem olvassuk a fórumot, hanem mert nincs tapasztalatunk ezzel a cuccal. Igy a bluepill témához írva sem lesz nagyobb szerencséd.

Itt az egyik fórumozó (zoobab) pont arról ír, hogy Arduino IDE-vel használva volt gondja a bootloaderrel, de megoldható.
CKS32 vs Aduino

Köszi, hasznos olvasnivaló. Egyik topik sem pörög mostanában, ezért duplikáltam, hogy hátha ...

Nincs jó tapasztalatom. Másképp működik. Saját fejlesztéshez nem is használtam soha, ezért nem tudom, mik a pontos különbségek. Open source projektek utánépítésekor próbáltam használni. Az adott cucc (motorvezérlő, floppy emulátor, stb) jól működött az eredeti mikrokontrolleren, a klónon viszont nem indult el a bootloder, nem volt stabil a működés, stb. Nem nyomoztam, inkább kerülöm.
Miért nem próbálom meg kiismerni a klónokat? Hiszen olcsóbbak. Szerintem nem éri meg. Ahány klón, annyiféle módon működik másképp. Ráadásul nem is mindig tudni, hogy melyikkel van dolgod, mert sokszor ráhamisítják az STM32 nevet is.

Én nemrég vettem 10 klónt. A legnagyobb bajom annyi volt vele, hogy csak rx, tx lábakon tudtam rátölteni a szoftvert, de működik Arduino alól. Szerintem megéri kicsit gyökölni néha. Uno R3 klónnál azonban tapasztaltam furcsaságokat. Készítettem R2R létrával 8bites DAC-ot. A régebbi klónokkal teljesen jól futott, az újak lefagyogatnak. Mivel erősen memória igényes, gondolom az lehet a gond, hogy kisebb a memória. Nagyon minimális ránézésre a különbség. Néhány átkötés nincs meg ezeken a paneleken, amiről egyértelműen kiderült, hogy gond van vele. Ugyanilyenek voltak a Geekcreit klónok. Azonban más feladatokra ezek is jók.

Na, ez a másik. Én is belefutottam olyan klónba, amit nem tudtam debuggolni. Részemről ez is kizáró ok.

Nálam nem gond, mert eleve olyan mikrokontrollereket használtam, ahol mégcsak nem is volt debug. Ha megszokod, hogy jóra írod a szoftvert, kevesebb a baj . Debugnak sokszor megteszi egy led, vagy a soros port a PC felé.

A munkám során megszoktam, hogy a Cortex debugon megy keresztül a live memory view és a HIL tesztelés is. Miért adnám lejjebb a hobbim közben? Nem azért hobbi, hogy szenvedjek.

Sziasztok!


STM32CubeIDE a környezet.
Összeraktam egy W25Qxx flash kezelő fájlt, osztály kezeléssel(illetve template), ezért C++.
Az a bajom, hogy a main.c-ben ha használom a függvényeit akkor nem működik az osztály miatt. Ha konvertálom a projectet C++-ra és átnevezem main.cpp-re akkor tökéletesen működik.

Mi a megoldás, hogy C++ függvényeket tudjak használni C forrásokban?
Arduino biztos más, de ott simán ment.

Köszönöm!

1. A projektet mindenképpen C++-ra kell konvertálni. Az úgy is marad, nem bántja a CubeMX.
2. A main maradhat c fájl.
3. Egy osztály tagfüggvényét nem fogod tudni meghívni C-ből. Ehhez szükséged lesz egy globális C++ segédfüggvényre, amit extern "C"-nek deklarálsz, amivel jelzed, hogy C-ből hívható módon kell fordítani.
Lásd részletesen itt.

Én úgy szoktam csinálni, hogy a CubeMX által készített main.c mellé teszek egy application.h-t és cpp-t. Ott extern "C"-vel létrehozok egy mainLoop nevű függvényt. A C kódban lévő main ezt hívja meg miután végzett az inicializálással, de még a while(1) előtt. Ott már minden C++, onnan indítom el például az RTOS taskokat is.
Callbackekhez szintén készíteni kell egy-egy globális segédfüggvényt.
Ott kezd bonyolódni, ha szeretnél (saját) könyvtárakat is használni, amik nem ismerhetik az aktuális applikációd függvényeit. Ilyenkor az egyik lehetséges megoldás az, hogy létrehozol egy application singleton objektumot. Kicsit csúnya, mert globális, de nem nagyon, mert csak egy van belőle. Az extern "C" callback függvények is ennek a tagfüggvényeit hívják. Ez a singleton pedig ismeri az összes libet, amit használsz, és továbbítja a hívásokat. Tulajdonképpen diszpécserként működik a C és a C++ között.

Szia

Ezt a projektet csak próbaként raktam össze, a main-ben próbálgattam.

Ahol használni akarom ott van rtos és touchgfx is.
Az adatok betöltése bekapcsoláskor történne meg(a beállítási adatokat tölteném be) , aztán az adatok mentése viszont csak akkor történik, ha majd a kijelzőn átírok egy beállítási értéket és enter-t nyomok(touchgfx).
De még nincs numerikus billentyűzetem touchgfx-re Ez a következő projekt, ami számok, tizedes és -/+ is tud.

Köszi a segítséget!

Sziasztok, ha én megadom így a változót, fix címre a flashbe:
static const uint32_t Uzemido _ADDR(0x2000)= 0;
az csodás, csakhogy minden ki-bekapcs után kinullázza. Hogy lehet úgy hogy ne tegye?
A 0 kezdőérték egyszer kell, amikor felprogramozom.

És hogyan módosítod az értékét? Ha const akkor az fix, nem változtatható... szerintem

Flash read, write rutinokkal átirom ahogy kell. Ő hogyan csinálja, azt nem értem....

Azt hiszem az lesz h ennél a procinál a boot miatt a 0x2000 nem a tényleges flash.

Szerintem csak újra kell olvastatnod az értéket a kódban. Biggyessz elé egy volatile kulcsszót...

Köszönöm! A volatile is kell, és az is hogy a main memoryba, 0x08002000-re írjam, ne a 0x2000-re - enélkül meg kezdőértéket nem tudtam adni neki. Sajnos kapkodnom kell, nincs időm végiggondolni mi ez az egész, hogyan képes féligmeddig működni minden rossz variáció, és mitől működhetett mégis a flashbe írás-olvasás. Ha valakinek van rá kedve-ideje, megfejthetné.

A címet azt nem is néztem, de emlékeim szerint ez simán a RAM-ba foglalt memóriát azon a címen! Az érdekesebb, hogy a flash írás/olvasás hiba nélkül lefutott és még módosította is a (RAM)regisztereket

Csak egy észrevétel...

Az STM-nek van saját tökéletes, könnyen kezelhető eeprom emulátor könyvtára. Nem véletlenül! A flash csak viszonylag kevésszer törölhető, illetve újraírható (kb 10k) . Ezért a mindig azonos cella írása hamar tönkreteszi azt. Következő projektnél érdemes alapul venni az AN4894-ben foglaltakat.

A ram nem 0x2000 hanem 0x20000000. Csak nagyon vad ötletek jutnak eszembe, ennyire a kinaiak se vadak, szóval nem találok értelmes magyarázatot.

Köszönöm, esetemben minimális számú kibekapcsolás van, azért is választottam ezt a megoldást.

A táblázat szerint az első 0x10000 cím mappelve van a 0x8010000 címre. Ezért működhetett a flash írás. Így tényleg csak a volatile hiányzott...

Ha rám van türelmed, próbáld valahogy elmagyarázni, mert nem értem.
A non-volatile esetben hogyan kerül be tápreset után újra az eredeti érték bármilyen flashnek látszó tárgyba? Vagy honnan nem törlődött amikor felülírtam, vagy ... érted...

A fordító valójában nem tudja, hogy te flash utasításokkal írod azt a címet. csak annyit lát, hogy ott egy konstans van definiálva. Azt pedig simán kioptimalizálja a ram-ba, a gyorsabb elérés miatt a háttérben. Te ebből annyit látsz, hogy bár olvasod azt a flash címet, valójában ez nem történik meg, mert egy árnyékregisztert olvas csak ki...
A volatile jelzővel arra kényszeríted a fordítót, hogy mindenképpen arról a címről olvasson, amire az mutat.

Nem RAM-ba, hanem regiszterbe teszi az értéket. A volatile gondoskodik róla, hogy ne a regiszterből olvasson.
Sajnos a volatile nem akadályozza meg azt, hogy az adott érték cache-be kerüljön. Így arra küön ügyelni kell, ha az adott MCU-ban van cache.

Hát ez így több sebből vérzik... A volatile nem azt mondja meg, hogy ne regiszterből olvasson, hanem azt, hogy nem optimalizáljon rajta lehetőleg semmit, onnan olvas, ahová az adat definiciója mutat, és azt mindig tegye meg, amikor az adatot akarjuk elérni! Ha flash, akkor onnan, ha ram, akkor onnan.
A cache is csak ram, ahogy a regiszterek is azok! Tehát, mindegy, minek nevezzük a periféria egységét, a lényeg nem ez, hanem amit feljebb leírtam...

A cahce kontroller transzparens módon működik, a CPU nem látja, hogy az adott memória olvasás valóban a memóriából olvas vagy a cacheből. Tehát a volatile nem véd meg attól, hogy a cacheből olvasott érték nem egyezik a memóriában tárolt értékkel.
Éppen ezért nem is szerepel a volatile leírásában a cahce:
Bővebben: Introduction To The Volatile Keyword In C/C++
Bővebben: volatile type qualifier

Ez valószínűleg így van..., de azért a mikrovezérlők világában ez még ma sem egy gyakori probléma, hogy adat cache van a láncban...

Azért a nagyobb ARM MCU-knál már gyakori. Futottunk is bele problémába emiatt.