STM32 - minimalisticky vyvoj, chyby, objednavky

[kenshin]

na stm32 (aj AVR) pouzivam C++, disciplinovane :

na std knizniciach je zle to, ze tam vidno snahy o akesy "OOP" programovanie v C (rozne handlers a init struct), vysledok je hrozny hnoj, da sa cez nen prejst zaobalenim do vlastnych tried v C++; zdrzi to zvacsa len inicializacie, ale ostatny beh je v poriadku;

nejake napady co som zatial poskusal :

1, gpio cez templates - rychlost je potom na urovni assembleru:
cosi ako :

TGpio<PORTA, 3, MODE_OUT> led; //konstruktor bude asi trocha dlhsi
led = 1; //ale toto sa uz na AVR prelozi na jednu instrukciu
led = 0;

2, pamat pokial mozno len na zaciatku alokovat

3, mat triedu pre casovace, pomocou abstraktnych tried sa da vyhnut callbacks, a vytvorit udalostne riadeny planovac - bez ozajstneho multitaskingu, ale na vela veci to staci;

podla mna nie je zly napad mat aplikacny thread ako potomok nejakej abstraktnej triedy; netreba potom prasacka pointre na funkcie a inu ciernu magiu

4, existuje embedded stl, vyuziva staticku alokaciu https://www.etlcpp.com/
5, pouzivam arm-none-eabi-g++, pocas kompilacie je vypnuta podpora vynimiek, pri trocha snahe je kod takmer rovnako rychly ako v C, s neporovnatelne vacsim komfortom

6, casovo kriticke casti vzdy mozu byt v C / inline assemblery

7, ano, startup v asm je tam des, mam napisany v C

[Reklama]

[mhi_]

Takze aktualne mam na stole LPC15xx a STM32F103. Zvazuju jeste Cortex-M3 od Infineonu https://www.infineon.com/dgdl/Infineon-XMC4100_XMC4200-DS-v01_02-en.pdf?fileId=db3a30433afc7e3e013b3cf9b2816573&ack=t  a M4ku od Renesasu.

Pouzivate nekdo ARMy od Renesasu / Infineonu ? Na co si u techto firem dat pozor?

Veci od Renesasu jsem pouzival v minulosti, trosku me desilo to mnozstvi typu a architektur procesoru (ruzne verze V850 apod). Nevim co mam cekat od jejich ARMu...

[MarSik]

TGpio<PORTA, 3, MODE_OUT> led; //konstruktor bude asi trocha dlhsi
led = 1; //ale toto sa uz na AVR prelozi na jednu instrukciu
led = 0;

Osobně preferuji gpio_set()/gpio_clear() z opencm3, překládá se na jednu instrukci a je to přehlednější.

netreba potom prasacka pointre na funkcie a inu ciernu magiu

4, existuje embedded stl, vyuziva staticku alokaciu https://www.etlcpp.com/

Když mluvíme o etlcpp, tak tam je https://www.etlcpp.com/function.html pro odkazy na funkce.

5, pouzivam arm-none-eabi-g++, pocas kompilacie je vypnuta podpora vynimiek, pri trocha snahe je kod takmer rovnako rychly ako v C, s neporovnatelne vacsim komfortom

C++ není téměř stejně rychlé, je stejně rychlé. Při vhodném použití static, inline a správných přepínačů je tam nulový overhead.

[mhi_]

K STM32 bych mel jeste jeden dotaz: na STM32F103C8) "bluepill" jsem rozchodil zde odkazovany minimalisticky USB stack (CDC, UART). Pouzivate jej nekdo? Na bluepillu jsem vymenil odpor na USB DP+ podle instrukci (i tak to myslim je ale spatne, odpor by mel byt po enumeraci odpojen (viz konkurencni NXP https://community.nxp.com/thread/483690 ).

Na bluepill vzdy jeste pridavam hromadku kondiku, tak jak to je z vyroby to je nepouzitelna nestabilni deska, nechapu ze to lide nezminuji.

Kazdopadne problem je v tom, ze OBCAS se mi ve Windows moje zarizeni nenaenumeruje (bud' Windows vubec nic nedetekuji, nebo "zarizeni nefunguje", nebo se naenumeruje treba za 5-10 vterin. Nejsem schopen diagnostikovat kde je problem, zda ve Windows ci driverech (ano, obcas to delaji i s jimymi zarizeni, pomuze ale obvykle jen restart, coz neni tento pripad), nebo to je tim mini-stackem, nebo nejaky elektricky problem. Nez zacnu resit debugging, mate nekdo praktickou zkusenost?

U Microchipu se nam bezne stavalo, ze *obcas* v kombinaci s nekterymi chipsety doslo ke ztrate dat pri prenosu MCU->PC, problem se nepovedlo vyresit. Nerad bych opakoval podobnou zkusenost i zde, kdy budeme zakaznikum dodavat neco, co nekomunikuje spolehlive.

[mhi]

Jen pro info, asi jsem to s nekym resil v jinem threadu, ale padla otazka ruznych klonu STM32; aktualne mi na stole pristal bluepill s necim co je oznaceno CKS32F103C8T6 a pod tim napis CKS; pry je to to same jako GigaDevices GD32F103C8T6 ; jedna pani povidala, ze to jsou plagiaty STM32 (gigadevices delaji i Risc-V verzi, ktera by mela mit stejne periferie, takze asi maji v ruce vic nez jen finalni podklady pro vyrobu).

Hodil jsem do toho aplikaci, ktera pouziva GPIO, timery, ADC, chodi to zda se identicky s original STM32F103C8T6. st-link vraci jiny JTAG ID, takze musi byt novejsi st-flash:

st-flash write lcd18.bin  0x8000000
st-flash 1.6.1-88-g0a6fe3a
2020-08-10T20:35:14 INFO common.c: F1xx Medium-density: 20 KiB SRAM, 64 KiB flash in at least 1 KiB pages.
file lcd18.bin md5 checksum: d978fcb81aa72893407eab658b1b98e7, stlink checksum: 0x000bf206
2020-08-10T20:35:14 INFO common.c: Attempting to write 9194 (0x23ea) bytes to stm32 address: 134217728 (0x8000000)
2020-08-10T20:35:14 INFO common.c: Flash page at addr: 0x08000000 erased
2020-08-10T20:35:14 INFO common.c: Flash page at addr: 0x08000400 erased
2020-08-10T20:35:14 INFO common.c: Flash page at addr: 0x08000800 erased
2020-08-10T20:35:15 INFO common.c: Flash page at addr: 0x08000c00 erased
2020-08-10T20:35:15 INFO common.c: Flash page at addr: 0x08001000 erased
2020-08-10T20:35:15 INFO common.c: Flash page at addr: 0x08001400 erased
2020-08-10T20:35:15 INFO common.c: Flash page at addr: 0x08001800 erased
2020-08-10T20:35:15 INFO common.c: Flash page at addr: 0x08001c00 erased
2020-08-10T20:35:15 INFO common.c: Flash page at addr: 0x08002000 erased
2020-08-10T20:35:15 INFO common.c: Finished erasing 9 pages of 1024 (0x400) bytes
2020-08-10T20:35:15 INFO common.c: Starting Flash write for VL/F0/F3/F1_XL core id
2020-08-10T20:35:15 INFO flash_loader.c: Successfully loaded flash loader in sram
  9/9 pages written
2020-08-10T20:35:15 INFO common.c: Starting verification of write complete
2020-08-10T20:35:15 INFO common.c: Flash written and verified! jolly good!

[Reklama]

[incorporated]

Nevím jak CS32F103, CK32F103, HK32F103 a podobné, ale GigaDevice má legitimně licencované ARM jádro pro svoje (ARMové) GD32 čipy. Poznáte to například tak, že pro Keil se oficiálně dají stáhnout packy.
Dál se z toho dá vyvodit, že když za jádro platí, nemají STM32F103 zkopírované komplet celé. Takže si myslím, že si koupili jádro s tím, že periferie si napíšou sami podle "specifikace" v reference manuálu STM32F103.
Také třeba IP bxCAN (a dost možná i další) periferie si ST nepíše vlastní, ale má ho licencované. GD si pak může buď koupit stejné IP ze stejného zdroje, nebo se ke zdrojům dostane nelegitimním způsobem snáz, než k vlastnímu proprietárnímu IP ST.
Ještě si ušetří spoustu práce s routováním tím, že se můžou podívat, jak je zhruba rozložený layout původního ST čipu, a budou hned vědět, že když bloky rozhází na podobná místa, půjde to dobře naroutovat.

[mhi]

Nekdy to prozkoumam dukladneji, treba to ADC pouzivam s DMA v takovem dost zvlastnim rezimu a stejne to chodi na urovni bin kompatibility. Prislo mi divne, ze by se jim povedlo navrhnout tak "dokonaly" klon nezavisle. Nicmene die vypadaji jinak ... to je pravda. A treba vypis z takove te systemove oblasti flash vypada stejne jako u STM32. Zajimave je https://www.richis-lab.de/STM32.htm ; to mozna rozlouskne spoustu otazek.

Ne ze bych ty CK32F103 / GD32F103 chtel pouzivat, dokonce mam pocit, ze STMcko koupim original levneji nez umim koupit GD32 (mozna proto, ze neumim cinsky a nevim kde to najit levneji ).

[mhi]

Chvili jsem koukal na ty decapnute IC a je zjevne, ze to neni klon 1:1. Designy jsou ruzne, GD32xx pouziva dokonce nejspis seriovou flash pamet ! Viz https://www.richis-lab.de/images/STM32/11_02.jpg  ; CKS32F103 je zase dalsi (jiny) design. Pak jsou jeste nejake pro mne uplne nezname a jen castecne kompatibilni SoC.

Nekdy si budu muset pohrat s STM32RV (Risc-V).

Zarazi mne ale ta kompatibilita, to je neco co dle meho nazoru cinan sam moc neumi udelat. Alespon z me zkusenosti, vzdycky tam je nejaky hacek. Mam kod, ktery pouziva rekl bych celkem mezni vlastnosti STM32, treba pokud jde o casovani, DMA, ... a na tom CKS32 to proste chodi "as is". Nekdy vyzkousim jeste USB a CAN.

Gigadevices maji evidentne i "vyssi" procesory, ovsem tam uz vidim rozdily - treba CAN/USBD sdilena pamet ma jinou velikost u STM32 a jinou u GD32.

Jako logicke vysvetleni bych prijal to, ze do ciny pristaly podklady z ST (netlisty/HDL) a cinan dostal za ukol udelat neco, co bude moci prohlasit za vlastni a jen si to slepili dohromady.

[Jakub Štech]

Já přidám pár mouder co jsem tu zatím neviděl (nebo přehlédnul):

Cena stm32 bluepill: osazený MCU může být pravý, ale ne nutně oficiální. STM32F103 je jeden z nejstarších, určitě se dostaly ven i kousky, co neprošly testováním a měly být zničeny.

Nebo je to opravdu "fake": recyklace (odpájet, vyčistit ultrazvukem, zbrousit vrch, přestříknout plastem, vypálit nové značení) je v okolí Shenzhenu a Guangdongu obrovský business. U dražších součástek (tradičně atmegy, wiznety) se dokonce vyplatí kompletní přebalení, tj. stará součástka se rozleptá, die se dá na nový leadframe, nalisují nové zlaté drátky, zataví se to do nové pryskyřice a šup pod laser označit. Moc doporučuji tuto NASA prezentaci, je tam k tomu hodně statistik, obrázků a případů. S přeznačenými a přebalenými čipy jsem se už setkal taky, nesouhlasil SN zespoda na těle s tím, co byl v read-only registru.

Knihovny: používám nejradši STM32F0, narozdíl od F1 a F3 řad je mladší, použité IP jsou o dost lepší. Nedělám nic vyloženě originálního, běžné věci jako I2C, SPI, CAN, různé timery, DMA, a vše bez problémů. Používám ChibiOS - je to čistě v C psaný RTOS s vlastním HALem s důrazem na korektnost. Je to výborně čitelné, dokumentované, pracuje na tom pár zaměstnanců ST.

Ten RISC-V gigadevice je skutečně source compatible s STM32F103 :-) nedávno mi přijel vzorek ze seeed studia, vzal jsem pár programů co jsem kdysi napsal pro bluepill, jen to překompiloval, nahrál, a jelo to včetně CANu.

[mhi]

ehh.. s/STM32RV/GD32VF !! nevim co pisu

kde se to da koupit za rozumny peniz ? Ja mam jen komplet kit s LCD, hodily by se mi samotne v QFP48. Videl jsem neco na ali, ale cena ... ach jo. Digi/mouser/tme/lcsc to nemaji..

[incorporated]

Já GD32VF103 v samotných čipech za rozumný (atraktivní) peníz nenašel. Objednal jsem v jednom listingu na Aliexpressu dva boardy s displejem, debugger a deset čipů á 1.7 USD. Celkem to vyšlo na 38 USD, 5 z toho poštovné.
Pořád mi to leží na stole a ještě jsem to ani nezapojil.

[incorporated]

Ještě bych se chtěl zeptat na to source-compatibility. Jak moc to tak je, když skoro každá aplikace spoléhá na věci od ARMu jako systick a NVIC? Co různé power saving módy?

[mhi]

Takze jsem se dokopal k tomu udelat plosnak na LPC51U68 , st-link pres SWD vycte core ID, tzn. procesor asi bezi jak ma. Krome toho LPC mam jeste v supliku neco od Renesasu a Infineonu, vse novejsi Cortex-M3/M4 (nechce se mi hledat ted typ).

Prozradite mi nekdo, jak temto procesorum pripadne programujete flash pod Linuxem ? Jde tedy o LPC, Renesas a Infineon. Na starsi LPC jsem nasel pres seriovy bootloader v bootrom, ale radsi bych pres SWD.

Dale jsou nekde k sehnani header files CMSIS pro gcc pro tyto procesory ? Na STM32 jsem si to posbiral z ruznych zdroju.