Előszeretettel használom az STM32G031-et. Még a chip hiány előtt vettem néhányat 0.8 usd/db áron. Most persze drágább, de így se vészes.

Meglep hogy ennyire nem tetszik neked, mert én az évek során sok mindent kipróbáltam és valahogy mindig visszatértem a Keil-hez. Elsősorban SMT32-t programozok, kényelmes, hogy az STM32CubeMX közvetlenül együttműködik vele. A debuggere mindent tud ami kell, különösen Jlinkkel.

Az Eclipse alapú IDE-k nekem nem tetszettek, bár tulajdonképpen nincs velük különösebb baj. Próbáltam az Atollic-ot, meg az ST ezen alapuló CubeIDE-t.
Ami bejött:
Segger Embedded Studio, jó a debuggere, és az RTT tetszett. De visszatértem a Keil-hez, beteszem az RTT-t a projectbe ha kell.

VSCode&PlatformiIO párost is használok olyan uC fejlesztéshez, aminek nem akarom komolyan megtanulni a tulajdonságait, csak Arduinóval próbálok összehozni vele valami egyszerűt. Pl. ESP8266 és ESP32, Pi Pico. A VSCode tetszik mint IDE, sajnos a debuggolási lehetőségei a PIO pluginnel nagyon korlátozottak. Ha ravaszabb probléma adódott, Segger Ozone-nal debuggoltam a PIO-val létrehozott .elf-et.
Mivel a VSCode tetszett, próbaképpen STM32-es fejlesztést (CubeMX HAL alapon) is próbáltam vele. Nem volt semmi gond, jól ment, de valahogy mégis visszatértem a Keil-hez.

Úgy célszerű bekötni, hogy a 8 bit egy port 8 bitje legyen, és a többi bitje ne legyen bekötve, akkor egy utasítással ki tudod vinni a 8 bitet. GPIOx->ODR = 0xakármi
Ha szükség van a többi port bitre és békén kell hagyni, akkor több lépés, beolvas, kinulláz, hozzávagyol.

A vezérlő jeleket meg bitbang-elni a
GPIOx->BRR = GPIO_PIN_yz
GPIOx->BSRR = GPIO_PIN_yz
utasításokkal. Ez nagyon gyors tud lenni.

Az LCD-k meghajtóinak általában van 16 bites módja is. Ha a uC elég sok kivezetéses, akkor a 16 bitet egyetlen portra kötve többszörösére gyorsul a dolog. Simán el lehet érni 20msec-es frame sebességet.

Az Eclipse-szel (CubeIDE, Atollic True Studio, stb.)én is hasonlóan vagyok. Nem rossz, de kösz nem kell.
A Keil nekem is tetszett anno, de a 32kB korlátot túlléptem. A VSCode bejövős, de a PlatformIO helyett Cortex Builder + Cortex debug plugineket használom, bár én csak STM32-t programozok vele. Ami hiányzik, hogy a debugban nincs live variables.
Most a VisualGDB-t nézegetem, de eddig nem jött át az a WOW érzés. A Visual Studio irdatlan beállítási lehetősége a sírba visz. A debug esetén a live variables megvan, de ez máshol is megtalálható. A változók grafikus megjelenítési lehetősége nem lehet rossz, de még nem sikerült előcsalnom. Az STMStudio is tudja ezt, igaz debug nélkül.
Ezen kívül mi az, ami olyan nagy előnyt jelent a VisualGDB-ben, hogy érdemes lenne pénzt adni érte?
lehet, hogy inkább cross51-nek kellett volna feltennem a kérdést, mert ő írta, hogy VisualGDB-t használ.

Seggert használok Nordic ARM-hoz, Atmel Studiot AVR-hez és nagyritkán SAM-hez.
STM32-höz sokáig VisualGDB-t használtam, szerintem annak a legjobbak a debug képességei, mint élő változók, RTOS taskok, memória használat, stb. A munkahelyemen átálltunk a CLionra, mert az multiplatform. Nekem nem jön be, még nem tud túl sokat a beágyazott debug módja, de folyamatosan fejlesztik. Az utóbbi időben viszont átszoktam a CubeIDE-re, az Azure RTOS támogatás miatt.

Köszi. A bekötés természetesen így van. Egy porton az az adat és másik port a vezérlő bitek.
Ez csakis 8 bites vezérlést tud. Less át az LCD élesztése topicba, ott van lábkiosztás és össz népi tanácstalanság.
Annyival vagyok már előrébb az ott tárgyaltaktól, hogy a lábkiosztás tutibiztos és van egy analizátorral lelopott vezérlési metódusom a gyári meghajtóval.

Ha FMC/FSMC képes kontrollert használsz, akkor az hardverből le tudja kezelni a vezérlővonalakat, így az írási művelet mindössze memóriaírási műveletnek számítana, amit lehetne akár DMA-val is működtetni.

Ez hol van? Nem találom.

Itt: Bővebben: Link

Próbáltam STM32CubeMX alapon egy USB audio kapcsolatot létrehozni, a PC felől hang streamet átvinni egy STM32F103C8-ba. Egy sor programot se írtam le, mégis hibás. (úton vagyok a program nélküli hiba felé) Rádióamatőr cucchoz kellene.

Csak az abszolút minimumot csináltam: CubeMX (latest greatest), beállítom az órajeleket, hs oscillatort, system-ben a debuggert, engedélyezem az USB-t, middleware-ben az audio-t. Egyetlen paramétert állítok, 48KHz-es hang. Minden egyéb, VID, PID stb defaultban.
A managerben a heap-et felviszem 4k-ra (mert malloc-kal csinál majd egy nagy buffert), a stacket 1k-ra. Ennyi.

Ami történik:
- enumeration rendben lemegy, a PC audio eszköznek látja, ki tudom választani a PC-n mint hangszórót
- a debuggerben látom, hogy létrehozza a malloc a buffert a bejövő stream számára, mikor rádugom az usb-re
- viszont egy bit hang streamet se tesz a bufferbe, ha hangot küldök ki a PC-vel az audio eszközre

Kipróbáltam betűre ugyanezt másféle uC-kkel is:
STM32F407V: rendesen tölti a buffert, ha hangot küldök (csak ennyire teszteltem, a debuggerben látom ahogy frissül a buffer)
STM32F411C: rendesen működik, mint az F407
STM32F303C: nem működik, nem tölti buffert, ugyanolyan mint az F103-mmal

A PC felől is látszik a különbség a következő módon: Gépház, rendszer, hang, tulajdonságok, az eszköz további tulajdonságai. Enhancements fül, Disable all enhancements. Majd Speciális fül, itt mutatja szépen, hogy 16bit 48000Hz. Mellette Tesztelés gomb. Ha ezt megnyomom, máshogy viselkedik a működő és a nem működő:
F411, szerintem jó: kb 3 másodpercre feketére vált, majd visszajön a zöld, ennyi ideig nyomta ki a teszt hangot. Ha megint megnyomom, ugyanez történik.
F103, hibás: első megnyomásnál több mint 5 másodpercre feketére, vált, majd visszajön zöldre, és újabb megnyomásnál már nem vált feketére
(meg persze a debuggerben is látom, hogy az F411 tölti a buffert, az F103 meg nem)
De az F103-ban is látszólag fut a háttérben a program, nem fut hardfault-ra vagy ilyesmi.

Tanácstalan vagyok, hogy a CubeMX hibás, vagy én kattintgatok rosszul valamit.

Amit még próbáltam:
Google-lel kerestem, hátha valaki feltett valahová működő usb audio speaker programot F103-mmal, mivel a BluePill a legnépszerűbb STM. Nem találtam CubeMX HAL alapút.
Olyat találtam, ami SPL-lel van megírva, kipróbáltam, nekem is szépen működik.

Vagyis tulajdonképpen meg tudom oldani amit szeretnék, akár az F411 BlackPill-lel, akár a F103-mal a standard library-vel.
Viszont egy napot elszerencsétlenkedtem a CubeMX-szel, és nagyon szeretném tudni, miért nem sikerült.

Van esetleg ötletetek, mi ez, mit kellene kipróbálni?

Én első körben tolnék egy lsusb -vvvv-t a mindkét MCU-n, hogy lássuk van-e valami eltérés az USB descriptorokban. A CubeMX, HAL meg kb. sosem szentírás csak elindulni jó

usbtreeview-val megnéztem a jót is, rosszat is, nem látok gyanús különbséget.
Az USB minden rétege jó bonyolult, ha egy mód van rá, nem szeretném beleásni magam. Ha nincs megoldás, beletörődök, és valamelyik működő változattal folytatom.

Hát ha nem termék lesz csak pár darab kellene belőle akkor ez a legjobb megoldás.
Bár ST fronton manapság az F103 azért jobb választás lehet, mert annak tuti vannak GigaDevices klónjai .

Vagy 1db lesz belőle, vagy egy se - ha nem sikerül.

A CubeMX-es verziót feladtam, mert az usb audio részt sikerült olyan bonyolultra megírniuk, és olyan eszetlenül dokumentálni, hogy több óra tanulmányozás után se jöttem rá alapvető dolgokra.
Az SPL alapú példa meg egyszerű, mint a faék. Egyből látom, mi hol van, mit akartak, hogyan oldották meg.

Egy FT8 adót tervezgetek. Nem azért, mert kell - van kész gyári transceiverem. Hanem mert szeretek programozgatni.
A lényeg, hogy az FT8 üzemmód a szokásos módon úgy működik, hogy a PC-n futó WSJT-X program előállít egy hang jelet, amit a transceiver SSB üzemmódban felkever a sávba. Maga a jel egymáshoz közeli frekvenciák között váltogat.

Én ezt SSB nélkül próbálom megoldani. A uC USB-n megkapja a hang streamet, és folyamatosan méri a frekvenciát, és egy SI5351 szintézer csippel előállítja magát a kész jelet, amit már csak erősíteni kell és antennára küldeni. Van ilyen készülék, a qrplabs megoldotta, szóval lehetséges.

Egyelőre a küszöbön botlottam el. A példa program 8 bit 22kHz, ez kevés, 16bit 48kHz kellene. Próbálom átalakítani, de valamit elrontok, ha állítok valami, nem jön a stream. Idő és tipródás kérdése, szerintem menni fog.

A tipródás megvolt, működik az USB-s hang stream 48kHz 16 bit módban. A frekvenciamérés nullátmenet interpolálással sima ügynek látszik.
Az SI5351 vezérlése érdekesebb lesz, a szokásos könyvtárak általában nem képesek a szükséges finomsággal állítani a frekvenciát. (8 tone van egy 50Hz-es sávban, pl. 7,074MHz-en)

Sziasztok!
Valaki dolgozik assemblyben STM32F103-al? Milyen program/IDE-t használ?
Mit érdemes használni, ami mint az avr időkben kód ír, lefordít, letölt és tudok debugolni.(JTAG-ICE)
ST-LinkV2 programozóm van és BluePill-t nyúzok.
Találtam ezt az oldalt:nicerland, de a Keil-t használja,ami kódméret limites.Ezt szeretném elkerülni,ha lehet.

Használd a gyári :
Bővebben: stm32cubeIde
Ingyenes, gyorsabban fordít mint a keil, a asm és C. rész az pedig egységes ezért hordozható.

EmBitz és asm. Lent a kód.
Hozzáférek a system regiszterekhez és így egész jól tudom állítani az órajelet, viszont akkor is kevés. A 11,99MHz-t milyen beállításokkal sikerült elérni?
A lenti kóddal 8MHz belső órajelről 190kHz jel van a kimeneten, ha PLL-t használok,és PLLSRC->HSI/2 és PLLMUL=2,akkor ugyanaz a 190kHz-et kapok.
Ha átváltok fixen PLL-re és HSE-re, növelem a PLLMUL értékét,akkor szépen nő a kimeneti freki is, egészn 1,71MHz-ig.
A CubeMX órajel konfigurátora szerint PLLMUL=9 a legnagyobb, hogy a Systemclk=72MHz a megengedett legnagyobb.
Ha ennek ellentmondok és PLLMUL értékét beállítom x16-ra,akkor 3,05MHz-lesz.(amikoris a CubeMX szerint már 128MHz a systemclk)
Tehát szépen skálázódik,de a megengedett értékig. De hogy lett 11,99MHz ?

Valahol utána lehet nézni, hogy melyik utasítást hány órajel alatt hajt végre ?

Mellékelek egy képet, azon látszik a kód, és az is, hogy mire fordult le. Keil IDE, Keil compiler. De ha a disassembly ablakban látható kódot beírod az Embitz-be, nyilván azonos lesz az eredmény.

Beállítások:
CubeMX: 72 MHz 8 MHz-es kristályról
GPIO C13, high speed-re állítva
Compiler:
-03 optimalizálás, speed bejelölve

Az eredmény 12MHz a C13 pinen. Ha a C13 low speed-re van állítva, akkor 8MHz a kimenet.

A te assembly kódod több utasításból áll, és valószínűleg nem állítottad high-re a port speedet (low a default), ezért kisebb a frekvencia.

Feltűnt nekem, hogy az Embitz kicsit mintha homályosan jelenne meg (úgy értem, nem teljesen élesek a betűk, mintha túl kis felbontású fényképen nézném). Ugyanez Keil-lel is előfordult, ha közvetlenül indítottam, ha viszont a CubeMX-ből, akkor éles volt.
Talán másnak is segíthet a megoldás. A Windows csinálja vele, jobb katt az indító ikonon, tulajdonságok, és a képen látható magas DPI beikszelése.

Tipikusan 2, ha flashben fut a kód, mivel a flash lassú, ezért 1 wait-et iktat be. Ha literalt tölt flashből, vagy lassabb buszon futó perifériához nyúl, akkor persze több. Pl. GPIO utasítás is lehet hosszabb, ha low speed van beállítva.

Nem vagyok túl gyakorlott az ARM utasítások időzítésében, próbálom kerülni. (Sokat dolgoztam PIC-kel, ott természetes gyakorlat volt időket számolgatni, de ARM-oknál már nem.) Abban a nagyon ritka esetben, ha ciklusból időzítek, szkóppal meg szoktam mérni. De inkább arra törekszem, hogy timerekkel vagy más perifériákkal, DMA-val stb érjem el a megfelelő real-time viselkedést. Különösen, mivel a kicsit nagyobb uC-kben már végképp elbonyolódik a dolog, mert gyorsítótár van stb, és ha interruptok ketyegnek, ráadásul kiüríthetik a gyorsítótárat is, akkor kegyetlenül nehéz kisakkozni korrekt ciklusidőket.

A példában látszik, hogy mindhárom utasítás 2 ciklusos, ebből jön ki a 12MHz. A 99 végződés oka, hogy a CubeMX defaultban felhúzza a systick interruptot, ami persze beleszaggat a négyszögjelbe.

Nem próbáltam, de szerintem tovább gyorsítana, ha a kész kódot RAM-ból futtatnád, mivel a RAM elérésben nincs wait.

Ha pl. az a feladat, hogy gyors, komplex bitfolyamot kell létrehozni, az spi-vel lehet legkönnyebben megoldani. Ha DMA eteti egy RAM pufferből, akkor alig terheli a cpu-t.

Igen, gyors, komplex byte folyamra van szükség, plusz 3 egyéb bit bizergálása. Kipróbálom a módosítást. Köszi az ötleteket.

Siker, másképp, de megoldva a 12MHz-s kimenet jel.
Végképp eldőlt, hogy ASM irányba megyek tovább.
Lényegében egy drivert kell írni egy 640x240-es LCD kijelzőhöz. Plusz ami nehezebb lesz, hogy úgy kell adatot fogadni (SPI,UART,stb, még képlékeny), hogy ne akadjon meg a kijelzés.
Bár az lenne a legjobb, ha lenne egy olyan memóriám,amit egyik oldalról a driver olvas, míg másik oldalról egy másik MCU tölt meg időnként adattal. Létezik ilyen memória?

Ha minden igaz, megtaláltam
Lint, ha ha kattintasz

Ez az alap, de nem elég, mert ezt még módosítják az egyedi hw sajátosságok. Pl. ami itt 1 ciklus, az az STM32F103 esetén 2 ciklus lesz, ha a szokásos módon flash-ből fut a kód, mert beiktat a hw 1 wait ciklust minden flash elérésbe.

Ez DMA-val könnyen megoldható. A DMA az érkező adatot szépen memóriába pakolja anélkül, hogy a cpu működését lassítaná. Persze előbb-utóbb csinálni kell valamit a memóriába került adattal. A DMA interruptot adhat minden fél memória átlépésnél, így lehet tudni hogy hol tart, és hogy melyik memória szegmenst lehet feldolgozni éppen anélkül, hogy a dma felülírná munka közben.

Ebben a műfajban a hasonló árfekvésű Pi Pico ügyesebb.
- maga a periféria is programozható, így pl. a vezérlő bitek kiadását teljesen rá lehet hagyni
- 2 cpu van, egyik foglalkozhat a kijelzővel, a másik meg zavartalanul minden mással
- eleve gyorsabb cpu-k

Az STM32F103-at már nem gyártják. A különféle utánérzett gyártmányok közül a GD32F103 vagy F303 (ez M4 magos) vált be, eddig nem tapasztaltam inkompatibilitást (ellentétben több más gyártmánnyal), és gyorsabbak az eredetinél, mert egyrészt RAM-ból futtatnak alapból, másrészt 108MHZ a specifikált maximum.
Az F303 elnevezés némiképp megtévesztő, mert azt lehetne gondolni, hogy ez az STM32F303 megfelelője, de nem az. A perifériái az F103-mal egyeznek meg. A fő különbség az M4 mag, és egy D/A konverter pluszban.

Ez nem igaz. Kérlek, nézz utána, és linkelj forrást.
Az STM 2021 januárban kiadott hosszútávú tervében azt nyilatkozta, hogy még legalább 10 évig gyártásban marad. Nem szoktak egyik napról a másikra megszűntetni egy-egy termékcsládot.
Bővebben: STM Product Longevity