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.

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.

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?

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...

Közben az AI-val már az 5.-ik verziónál tartunk.
Rendelek egy hardvert, és meglátom mi sül ki belőle. Persze nem szó szerint...

Jópofa projekt, kitartást kívánok hozzá! Azért a bukósisakról se feledkezz meg, mert van itt a 10 emeletes tövében egy gyereknek egy eredeti. Amikor jön vagy megy, azt szoktam nézni, hogy mikor esik már a fejére véletlenül egy cserepes muskátli.

Nyílt forrású Cortex-M debugger?

Sziasztok!
Az utóbbi kb. két és fél hónapban vibe-kódoltam egy Cortex-M debugger kezdeményt. Mostanra kicsit elfogyott a lendületem, más hobbival is kellene már foglalkoznom, így ezt egy kicsit félreteszem. Azonban talán nem felesleges megmutatnom, hogy hova jutottam el vele. Lehet, hogy nem egyedül vagyok azzal az érzéssel, hogy a gyári debuggereket fájdalmas használni (lassúak, meredek induló tanulási görbe), ha másik gyártóra vált az ember, akkor kezdheti elölről. Ráadásul másik probe-ot kell beszerezni. ST: St-link, NXP: MCU-link, stb.
Az ARM érzékelte ezt, és kitalálta a DAP-linket, amit le lehet otthon gyártani pl. egy RP2040-ből, de nagyon sok más olcsó dev-board-ból is, talán blu-pill-ből is. Először egy probe-rs projekthez akartam egy GUI-t, de rá kellett jönnöm, hogy a probe-rs egy félkész cucc. Utána jött, hogy sebaj, van PyOCD (ez talán a legjobban használható, de én egy kompakt projektet akartam. Akkor fordultam az openOCD felé. Ebben viszont nincsenek új mcu támogatások, holott én pont egy új mcu miatt kezdtem az egészet. Estig tudnék mesélni a buktatókról. Most ott tartok, hogy a projektben van svd-parser, elf-parser, disassembly, a GDB-t is kiváltottam (ebben van pl. a step logika: step-over, step-into), FLM és pdsc parser.
Ha valaki kíváncsi a Windowsos program GUI felületére, a zip file-ban a Build könyvtárban indíthatja az .exe-t, elméletileg nincs benne függőség, csak OpenGL. Alul a "F" gombbal beállíthatja az elf file-t, a forrást, és akkor a "Source" ablakban akár assembly nézetet is bekapcsolhatja.
A fejlesztésben ekkor jöttek az mcu specifikus dolgok: init, flash, stb. Ezeket sajnos már nem lehet általánosan megalkotni, sok tesztelés és némi reverse engineering is kell hozzá, no meg minden mcu családból egy board.
Amit viszont bebizonyítottam magamnak, hogy lehetne open-source-os eszközökkel közel Ozone (J-link) színvonalú debuggert megalkotni, de sokkal olcsóbb programozóval (DAPlink 1.0, 2.0).

Ha valakiben felkeltettem az érdeklődést egy vélemény írására, nyugodtan jöhetnek a negatív kritikák is.