Skill bővítés

Sziasztok!
Én is most merülnék bele az ARM világba. Anno sok évvel ezelőtt beszereztem egy STM32F407Discovery board-ot, és csináltam is vele 1-2 hello world programot, de annyi.
15 éve PIC-ezek (8 bit, asm) és PC-n programozok (ez utóbbit munkahelyen is).
Viszont szeretnék kicsit piacképesebb lenni, gondolom az ARM-es fejlesztést jobban honorálják.
Az iparban/cégeknél melyik család az elterjedtebb? Láttam pont itt előttem tárgyaltátok, hogy az ST kicsit problémás, de én lehet mégis ezt választanám.
A terv, hogy HAL, LL, bare-metal szinteket kb. ebben a sorrendben sajátítom el.
És ha már van egy board-om, kezdem azzal.
Felraktam a STM32CubeIDE és STM32CubeMX progikat (most már külön vannak, régen egybe voltak), és össze is ütöttem egy progit. Tetszik hogy a CubeMX-ben bármit módosítok, rányomok a kódgenerálásra, és az IDE-ben is rögtön változik az érintett kód.
Csak mielőtt nagyon belemerülnék kérdezem, hogy érdemes-e. Egyelőre azt látom, hogy ez az egyik legelterjedtebb/legtámogatottabb/legmegbízhatóbb (mármint az ST).
Illetve, van-e valakinek tapasztalata a munkaerőpiacon a témában...
Előre is köszönöm!

Fél szemmel a RISC-V felé is érdemes odanézni, mert az is terjed...

Gondolom a licenszdíj kötöttsége (illetve, annak hiánya) miatt.
Ebben lehet valami. Egyre több kiforrott mag lesz, egy idő után megfontolandó lesz a cégeknek váltani, vagy mennek a süllyesztőbe ha az lesz uralkodó. Persze ez most még erős feltételezés.
Most nézem, az ESP32C szériája már nem a korábbi Xtensa-t használja, hanem RISC-V-t.

"az ESP32C szériája már nem"

A C5 használata komolyan tervben van, persze csak hobbiként. Pár hónapja még ott tartott a dolog, hogy az SDK (mármint az ESP-IDF) nem volt hibátlan, ill. tán funkcióiban sem volt teljes az új procikhoz.

Az sima esp32, vagy S3 dual core proci nekem szimpatikusabb

Belső oszci pontosság

Na belevágtam, egyelőre még csak HAL szinten.
Ami kicsit aggaszt, hogy irgalmatlan sok beállítást látok egy egyszerű bármilyen periféria beindításához. Ezeket fejből vágni.. Hát eléggé ki vagyok egyelőre szolgáltatva a CubeMX kódgenerátornak és AI-nak.

Ja igen, a lényeg
Van valakinek gyakorlati tapasztalata a STM32G030F6 belső (HSI) 16MHz-es oszcijának pontosságáról? Adatlapban van róla infó, csak nem tudom a gyakorlat mit mutat. PIC-nél szerettem biztosra menni, és általában inkább beraktam egy kvarcot.

A belső oszcillátorokat általában (nem tudom, hogy ennél a típusnál van-e éppen) lehet egy regiszter állítással kicsit hangolni, pontosítani.
Azonban ezzel nem biztos, hogy megoldottad a problémát, mert a hőfüggésük jóval magasabb, mint egy külső oszcillátornak, vagy kvarcnak. Ha pl. kültérbe rakod, vagy melegedő tápegység mellé, akkor a 20Celsius fok helyett egy 50 fokos dobozban akár 2 %-kal is eltérhet egy belső RC oszcillátor frekvenciája. Ha csak LED-et villogtatsz észre sem veszed, de más esetben ez már akár probléma is lehet. Én nem szoktam sajnálni a kb. 3 mm (vagy kisebb) méretű tokozást a panelról.

A2 "irgalmatlan sok" beállítást illetően sajnos ez van. A nagyobb, profibb szolgáltatáscsomag magával vonja a több regisztert és a bonyolultabb beállításokat. A gyártók nemhiába adnak kisegítő kódgenerátorokat és API-kat (LL és HAL az ST esetében). Az ST "hitvallása" pedig az általános felhasználás, hogy legyen mindenre is jó, mindent is lehessen benne beállítani. Ezért van egy I2C-hez legalább 7 flag, amit API használata nélkül már kissé időigényes lekezelni. Ez nem csak az ST sajátja, más gyártóknál sem biztos, hogy jobb a helyzet.

Köszi!

Igen, ezen agyalok most, hogy mennyire gáz ez vagy sem.
Adatlap szerint -40°C és +85°C között -2% és +1.5% között van a freki drift.
Hát lehet maradok inkább a kvarcnál itt is.

Előre nem nyilatkozom, de annyit tudnak már ezek a chipek az I/O-t is beleértve, hogy nem lenne meglepő, ha specializáltabb szeletekre hasadnának és akár többféle architektúra is gyártásban maradna hosszabb távon (és összességében még több funkciót kapnának). Nem is tudom még, hogy ez az alacsony fogyasztású második processzor mire képes.

Szerintem (számomra) az egyik nagy előny és út a profibb megoldások felé, hogy egy ideje az ESP32 chipek az adott nagy memóriákkal és nyolcszoros SPI kapcsolattal (és cache-en át) alkalmasak elfogadható sebességgel (meglehetősen stabil) TLS kommunikációra egy csomó socketen, ami nem annyira gyakori - nincsenek előttem a pontos értékek, de nagy szám lenne ugyanezt még kisebb fogyasztásból megoldani. (Ezeket saját tapasztalatból tudom, írtam egy nagyobb kódot, egy ilyen távvezérelt I/O eszköz még S2-essel is szépen működik egy ismerősnél a falon magára hagyva, de S3-assal még jobb.)

Ugyanakkor az eddig olvasottakból inkább úgy látszik, hogy nincs a második processzor automatikusan kihasználva, ahogy az Xtensával, negyede az órajele, vagyis két mag helyett egyen fut minden, ami elvileg sokat lassít az egészen, hiába gyorsabb az új fő mag egy Xtensa magnál. Tehát lehet, hogy a RISC-V vonal kicsit másra lesz alkalmas - vagy hamar kihoznak újabb változatokat, amik gyorsabbak...

Persze a saját írásom helyett inkább másokat kellene olvasgatni a konkrét információkkal, csak léteznek már... : -)

STM32 RTC

Sziasztok!

2 kérdésem is lenne egyszerre, hátha.
STM32F103RF MCU-val készítek egy vezérlő áramkört, amelyen van egy RTC is.
Már 3. napja kínlódok az óra kvarccal, illetve annak illesztésével.
Az eszköz egészen addig jól működik, ameddig az RTC óra és naptár funkciókat be nem kapcsolom a CubeMX-el. Majd utána sok szórakozás közben rájöttem, hogy ha egy pillanatra oda nyúlok a 32KHz-es kvarc lábához, azonnal elindul a program. Vagy is feltételezem, hogy a program vár egy ideig, hogy gerjedjen magától a kvarc, ha nem nyúlok oda, akkor csak várakozik esetleg hibára futva leáll.

Amiket kipróbáltam vagy csináltam már mint javítási szándék:
Átnéztem a nyákot nincs e valami furcsaság, ki is mértem, minden rendben van a nyákkal.
Cseréltem kondikat: 1, 7, 10, 12, 15, 22, 33pF-os kondikkal próbáltam, mindegyikkel ugyan úgy viselkedett.
Tettem a két láb közi ellenállást, hátha, 500K és 1MOhmmal próbálkoztam, sikertelen.
Kicseréltem már 2szer a kvarcot, hátha. Közvetlen STM32 lábára kötöttem, ugyan az a szitu.
Próbáltam a lábakat le vagy felhúzni ellenálláson keresztül, illetve a kvarc házát is próbáltam le vagy felhúzni ellenálláson keresztül és direktben is.
CubeMX kvarc és egyéb beállítva, már csináltam párszor ilyent, eddig nem volt gond. (valamire most nem gondoltam vagy nem figyelek)
Programban minden beállítást próbáltam, amit lehetséges beállítani, kivéve az időzítést azt csak 1 vagy 2 állapotban, hogy mikor induljon el az RTC.

Abban a pillanatban, ha a kvarc lábához érek azonnal elindul a program és utána a következő kikapcsolásig jól működik. Olyan mint, ha az én érintésem gerjesztené be a kvarcot.

Találkozott már valaki ilyesmivel? Mit tehetek még? Ötlet?
Előre is köszi.

ui: A második kérdést inkább egy következő bejegyzésben, hogy ne vigyem el a fókuszt.

PIC mikrokontrollerek adatlapjában írnak soros ellenállásról, lásd melléklet. Továbbá, ha tudod, oszcilloszkóppal ellenőrizd a tápfeszültséget bekapcsoláskor, hátha "túl lassan" éri el a kívánt értéket és ez a lassú felfutás nem indítja be a kvarcot. Igaz, ez utóbbi elég ritka esetnek számít és talán ilyenre fel vannak készítve a kontrollerek (BOR, POR).

Újra elkezdtem vele vacakolni, az egyik felére 12pF a másik felére 10pF kondit tettem és egyszer csak elindult, azóta működik. Nem tudom mitől javult meg.

STM32G030F6 kvarc

Sziasztok,
Nálam is kvarccal kapcsolatos kérdés lenne.
Szóval adott egy TSSOP20 tokozású STM32G030F6 proci.
A CubeMX-ben azt vettem észre, hogy a 2-es lábon be lehet állítani az RCC_OSC_IN funkciót, viszont a 3-as lábon csak olyan van hogy RCC_OSC_EN, tehát RCC_OSC_OUT nincs.
Az adatlapok kicsit ellentmondásosak. A reference manual 5.2.1 fejezetében még ábra is van a HSE kvarcról.
Viszont az adatlap 32. oldalán is azt tapasztalom, mint a CubeMX-ben, tehát a 3-as lábnál csak RCC_OSC_EN funkció van.
Csatolok képeket is a CubeMX-ból.
Szóval a CubeMX rossz, vagy ez a proci nem tudna HSE módban kvarcról járni?

CubeIDE-ben a -ban:

A RCC_OscInitStruct.HSEState értéke tud még RCC_HSE_OFF meg RCC_HSE_ON lenni.

De a valóságban itt ez hibára fut (16MHz-es kvarc van két 15pF-al).

Na a lényeg lemaradt a CubeMX képről, csatoltam.

Na úgy tűnik a 2. verzió lesz a megoldás. Vagyis ez a proci nem tud közvetlenül kvarcról járni.
És a reference manualban azért van benne, mert a nagyobb, LQFP48 verziók viszont tudnak.
Bővebben: Link
Bővebben: Link

STM32F407VET6

Szevasztok!
Csodálkozva látom, hogy az ESP fórum mintha nem menne úgy mint az arduinos.
Pedig már az ESP is legalább annyira elterjedt, ha nem jobban is. Vagy mindenki tud mindent?

Most járok itt először, és az ESP világában is, ezért szükségem volna egy kis segítségre.
A lényeg, hogy vettem egy elektromos motorkerékpárt (még úton van), aminek hangja nem sok van.
Éppen ezért közlekedés közben attól tartok, nem fogják hallani, ha megyek/jövök (nézőpont kérdése).

Azt találtam ki, kellene neki valami motor hang, mondjuk egy Harley...
Szóval megadtam egy ilyen hanggenerátor kódolására ezt a koncepciót a ChatGPT-nek,
és generáltattam vele egy elvileg már működő kódot. Persze a probléma az, hogy a hardver még nincs nálam, és hogy őszinte legyek, nem is rendelném meg addig, amíg nem lehetek benne valahogy biztos, hogy az Ai valóban meg tudta oldani ezt a feladatot. Mert ugyebár, szeret néha nagyzolni.

Szóval akinek van egy STM32F407VET6 teszt board-ja, szeretném megkérni, hogy töltse fel rá a mellékelt kódot, és számoljon be milyen lett. Elvileg van egy normál alapjárati hang, és két bemenet. Egyik analóg, és a gázkar feszültségszintjét érzékeli. A másik digitális, és a kerék HALL jeladó impulzust érzékeli. A két bemenet kizárja egymást, tehát vagy-vagy alapon működik.
A lényeg, hogy amelyik bemenetre a megfelelő jelet kapja, a szerint változik a motor fordulatszáma.

Ha valahová egy demo mp3 vagy videó fájlt is fel tudna tölteni valaki, nagyszerű lenne. Köszönöm.

Ui.: De ha esetleg ismer valaki hasonló már kész projektet, azt is szívesen veszem.

Az STM32-esek nem ESP-k; st.com vs. espressif.com. Másfelől a processzor típusából még nem lehet tudni, milyen test board-ról van szó, melyiken van hangszóró stb.

Na kb ennyire vagyok vele tisztában...
Hangszóró melyiken van, azt nem tudom, de ezen nincs.
Ebben viszont van integrált DAC ezért ajánlotta az AI ezt a MCU-t.
Tehát a DAC kimenetre kell egy pár W-os erősítő is.

Egyébként ilyen:
STM32F407VET6

Ez a proci az ARM családba tartozik, szerintem vitesd át oda a témát. Itt bal felül kb a 4. téma

Úgy lesz. Kösz.

Szóval az a kérésed valakihez, hogy tervezzen meg és építsen egy kapcsolást az adott kártyára egy potméterrel, ami a gázkart imitálja, egy állítható jeladóval, ami időnként impulzusokat ad, hogy a kerék mozgását imitálja, aztán építsen az egyik kimenetre egy erősítőt és tegyen rá egy hangszórót - a piezo ide kevés -, majd keltse életre az AI által generált projectet, töltse fel a programot, keresse meg a be- és a kimeneteket, módosítsa a kódot úgy, hogy működőképes is legyen, pl. pótolja a kódban a láthatóan hiányzó függvényeket, amik megszerzik az információkat a hardverektől, meg még ami eszembe sem jut...

Nem egészen. Mint említettem, vagy egyik, vagy másik bemenetet kell csak használni.
És természetesen a potmétert sokkal egyszerűbb bekötni, mint a HALL jeladót.
Ezért a kérés kb az lenne, hogy egy potmétert az analóg bemenetre, egy kis erősítőt pedig a DAC kimenetére.

De gondoltam, a feltöltött fájlokban benne van a szükséges információ.
MotorSoundF407.ioc megfelelő részei?

Én ugyan most látok ilyen kódot először, de ránézésre feltételezem a következőket:

PA0 = Analóg bemenet, potméter.
PA4 = Analóg kimenet, erősítőre.
PA5 = Digitális bemenet, HALL jeladóról.
De a PA5-öt nem kell használni, mert a potméter tökéletesen megfelel a teszthez.

Ezt a három fájlt kaptam, avval a javaslattal, hogy ha ezt fordítom, mehet fel a board-ra,
és elvileg működik.

Meglátásod szerint milyen függvény hiányzik egyébként?

Nehéz kérdés, hogy hogyan álljon hozzá az ember az ilyen jellegű kérdésekhez... Léteznek rettenthetetlen altruisták, akiknek idejük is akad éppen és eszközük is és levezényelnek egy ilyen helyzetet, de én nem próbálnék meg konkrét tervek nélkül segítséget kérni. Főleg mert menet közben szokott kiderülni, hogy lényegesen több megoldanivalót jelent valamit életre kelteni, mint a hozzávetőleges elképzelés volt róla. Azt értem, hogy jó lenne hallani, milyen hangot produkál az a kód, ezt nem is tudom ránézésre megmondani, csak azt látom, hogyan készül. De szinte biztos, hogy ilyen jellegű kérést nem fog elsőre elfogadhatóan megcsinálni. Ilyenkor át szokta írni az ember a programot PC-re, többnyire gyorsabb megoldás, kísérletezni is könnyebb. Ahogy "házilag" el lehet készíttetni valamit, az általában több lépcsőben, párbeszéddel javításra, kiegészítésre szokott szorulni. Ahhoz meg meg kell próbálni megtanulni legalább lefordítani a kódot. Abban is segít az AI, de nem tudom megmondani, sikerülni fog-e neked. Amúgy igazad van, leírtad, hogy a jeladó egyelőre nem érdekes.

Ami a két függvényt illeti, szerintem ezek hiányoznak és ezek nem is a fejlesztőrendszer részei:


Az analóg bemenet értékét, ill. az impulzusok sebességét adják meg, az utóbbi kicsit bonyolultabb is lehet, de az elnevezésből látszik, hogy egy timerre épít - nyilván megszámolja, hogy egy adott idő alatt hány impulzus jött a megfelelő lábra. Ez is úgy kell megíratni, hogy alkalmas legyen a feladatra.

Titánok harca: generáltattam a Claude-dal egy teszprogramot. Nem is lett olyan rossz (némi javítás után), de még mindig nagyon féloldalas a generálás. A felvételen a csúszkát én tologattam kissé ügyetlenül, azért vannak ugrások a hangmagasságban.

Egy ilyen devboard nem olyan nagy összeg.
Vedd meg, és próbáld ki.
Elsőre úgysem fog sikerülni. Aztán mikor működik, akkor neked nem fog tetszeni. Aztán végül a motoron nem fog működni, mert az elektromos zajok megölik az MCU-t, stb.
Szóval ez egy iteratív folyamat, amit a hardver nélkül nem fogsz tudni megcsinálni.

Ez nekem is megfordult a fejembe...

Na most kissé összezavartál.
Ha az említett két függvény nem létezik, akkor hogyan fordult le a kód és szólalt meg?
Máshogy oldottad meg?

Nem gondoltam, hogy szoftveresen is le lehet szimulálni az analóg bemenet jelét.
Mint említettem, STM -el most foglalkozom elsőre.
A megoldás egyébként megér egy hangszórót... Köszi.

Ui.: A hangminta kicsit arra emlékeztet, mintha egy 90-es évekbeli C64 -es motor szimulátort hallanék...

Nem a nagy összeg zavart, hanem inkább az, ha valami sületlenség jön ki a hangszórón, akkor amúgy is halott ügy lenne, jobbítani sem igazán tudnám. Így csak feleslegesen állna a fiókban a hardver. De így, hogy hallottam, lehet, hogy megrendelem, és belevágok.

Egyébként valami hasonlót kellene megpróbálni generáltatni vele...