Vlákno názorů k článku STM32: mikrokontrolér vstřícný k amatérům od blume - STM32 je oproti AVRkum hardwarove znacne dal, predevsim...
-
blume (neregistrovaný)
STM32 je oproti AVRkum hardwarove znacne dal, predevsim v periferiich. Sam jsem na tuto platformu presel asi pred rokem (po cca 5 letech s AVR) a postavil na ni uz peknou radku produkcnich veci, takze si myslim, ze snad muzu uz i hodnotit..
Pozitiva:
(1) JDE TO DEBUGOVAT/KROKOVAT!! Neskutecny pokrok oproti printum do seriaku :)
(2) Ma to tolik ruznych HW interfacu, o kterem se mi na AVR nikdy nesnilo.. CAN bus(y), hromadu UARTu, I2C, SPIcek, x-kanalove 12-bitove A/D, DMA, uzasne..
(3) sw4stm postavene na eclipsu (coz me, jako stareho javistu samozrejme tesi)Negativa:
(1) Je to brutalne slozitejsi nez AVR. Nastavit pin, ze ma byt output, pull-up a kdesi cosi zabere cca 15 radku kodu :-O
(2) V HALu (Hardware Abstraction Layer) jsou zakerne chyby. Lisi se to platformu od platformy, ja mam (zatim) zkusenosti jen s F105, F042, F103, L152. Takze pouzivam STL (Standard Periperal Library), ktera se ovsem architekturu od architektury lisi, takze jsem si musel nakonec napsat (asi jako vsichni ostatni) vlastni knihovny.
(3) Kdyz ma clovek nekde problem, tak ani gougl moc nepomuze, examples moc neexistuji (a kdyz uz neco najdete, tak vetsinou pro HAL nebo jinou architekturu - M0, M0+, M3..)
(4) A kdyz uz najdete nejaky example, tak jsou to vetsinou takove ty boilerplate marketingove ukazky, ktere neresi detaily a speky, ktere zrovna potrebujete.
(5) Fora a komunita moc nefunguji. Bud to nikdo nepouziva, nebo to nikdo necte :)
(6) I kdybych pouzival STM Cube, tak to neumi vygenerovat konfiguraci pro vsechny (koupitelne, ve smyslu dostupnosti ci "active marketing") IC. Takze kdyz vybirate cip podle konfigurace, co se vam zrovna hodi, tak je dobre se zavcas (i.e.pred nakupem) podivat i tam.
(6) Za pouziti STL (a mozna na to maji vliv i ty moje knihovny) se vam kod, ktery se zkompiloval na AVR bez problemu do 16kB FLASH nevejde do 32KB, a to ani v release modu. Takze je potreba radeji pocitat s vetsi FLASHkou na cipu.S BluePill zadne zkusenosti nemam, jen jsem nekde cetl, ze se to da programovat pres Arduini IDE (ci platformio), coz by mohlo pro zacatecniky byt neskutecnou vyhodou.
V souhrnu je STM32 fakt brutalne nabusena masina, libi se mi, ac zrovna nadavam a zapasim s nejakym dalsim problemem na I2C :)
-
X125 (neregistrovaný)
Naprosto souhlasím. Taky jsem před časem pokukoval po STM32. Hlavně z důvodů možnnosti debugu, větší paměti a široké nabídky rozhraní.
Nakonec jsem to vzdal a vrátil se k AVR. STM32 je šíleně složité a to i jednoduché až triviální věci. Na internetu nejdou najít ani pořádné příklady ani řešení různých problémů. Asi je ta komunita přiliš malá. -
Petr M (neregistrovaný)
Já zase zápasím s vlastní grafikou na STM32F429. Co se dalo sehnat, tak buďto licence za 100€ (na desítky kusů spec. zařízení nedává smysl), nebo binární bloby, co se nedají přilinkovat (protože se někdo rozhodl pro soft float a potřebuju hard float). DMA2D a LCDC jsou ale luxusní periferky.
-
Různých prostředí a operačních systémů pro ARM ale i jiné MCU je velké množství. Bohužel většina lidí a výrobců se nechá nachytat na jméno FreeRTOS, což minimálně dříve byla jen reklama na předražený SafeRTOS. Jak jde vývoj nyní nevím. Jinak s FreeRTOSem mám zkušenosti, starší verze opravdu nebyly na mnoha architekturách RT (přeplánování až po dalším tiku hodin atd.), zdrojáky ošklivé, ale použít se to nakonec dá. Bohužel nejsou zahrnuté ovladače nebo alespoň jejich kvalitní příklady, takže komunita kolem OS nevznikla. Každá firma, případně výrobce čipů si vytvoří vlastní rozhraní/framework, který bere jako velké know-how a sdílet s ostatními ho nechce. Přitom vývoj dělá z nuly a s lidmi, co moc systémovou představu nemají.
Určitě použitelná volba je mBED, pokud se používá s vlákny, tak je vespod použité RTX vypadá celkem dobře. Nevýhoda je, že po převzetí společností ARM nikdy nebude multiplatformní a to je v době nástupu RISC-V celkem škoda.
Mě se nakonec ze všech malých systémů nejvíce líbí NuttX http://nuttx.org/ , je psaný čistě, dokáže s pár kB RAM nabídnout i TCP/IP, umožňuje programovat s využitím podmnožiny POSIXu, takže lze psát přenositelné aplikace, které běží na Linuxu i na MCU. Bohužel RT až tak moc zatím není (mnoho algoritmů je O(n)), SMP sice jako experimental nabízí, ale je to strašně daleko od použitelnosti. Výhoda je, že je téměř pro všechny architektury (ARM, MISP PIC32, RISC-V atd.). Nabízí dokonale jednotné API k periferiím přes všechny platformy. Bohužel jako téměř one-man show zůstává podpora mnoha čipů jen minimální. TCP/IP má zázračně malé požadavky na RAM, bohužel při testování ale tak dobré jako lwIP není.
lwIP mám otestované s naším syslessem (základ firmware bez OS pro více architektur LPC, nRF51, H8S atd.), FreeRTOSem a RTEMSem (http://rtems.org/), a vykazuje lepší výsledky.
Výhoda NuttX je, že nabízí kromě shellu a dalších aplikací i kompletní grafické prostředí NxWidgets. Takže zpět k otázce, existuje mnoho použitelných knihoven pro grafická prostředí na malé MCU.
Jinak jednu vlastní (SuiTk) jsme ve firmě (http://pikron.com/) vyvinuly, běží nad MicroWindows API (http://microwindows.org/) na Linuxu na framebufferu, v X11 v emulovaném okně, na RTEMSu i na MCU systémech bez OS. Je to kód v čistém C, přitom podporuje signal-sloty a použít lze buď přímo pro stavění obrazovek v C, kdy mnoho obějktů může být zakompilovaných jako statických do Flash nebo umožňuje tvorbu obrazovek a stavovými automaty řízených přechodů mezi nimi v deklarativním XML.
Pokud by měl o projekt někdo zájem, tak se mi může ozvat, obecně byl zamýšlený jako open-source (GPL+LGPL+MPL). Na druhou stranu je to dost komplexní řešení a protože zatím nebyly síly na tvorbu stránek, tak framework publikovaný. Generovaná dokumentace v (dost řídkém) PDF asi 600 stránek plus několik krátkých přehledových návodů.
Ale pro začátečníky to smysl v současné podobě nemá, seminář a výuka by znamenala pro mě desítky hodin a ty nemám. To ječ důvod, proč to zatím nepublikuji. Pokročilí by se do projektu mohli zapojit, případně jsem schopný dohodnout/zajistit s kolegou, který se kterým jsem to pro naše aplikace psal a platil mu za to, placené úpravy na míru.
Bez XML vrstvy lze napsat aplikaci, která běží na LPC s 32 kB RAM. XML vrstva již vyžaduje více. Šlo by ale navrhnout compile time konvertor, který by značnou část dokázal uložit jako předpřipravené statické struktury do Flash.Jinak pro větší projekty, kde je potřeba výkonné SMP a vejde se FreeBSD stack (tak 4 MB RAM), ale stále to není na OS s MMU je rozumné použít RTEMS (http://rtems.org/), je to volba ESA a NASA a existují i certifikované verze, přitom je to od 80-tých let opensource.
-
S FreeRTOSem jsem se setkal před pár lety, kdy jsem pokukoval po nějakém systému, který by posunul dále mé vývojářské úsilí, tehdy na platformě PIC24. I přes ten fakt, že představuje asi nejvíce zmiňovaný operační systém RT pro mikrokontroléry vůbec, zrovna dvakrát mi k srdci nepřirostl. Jak uvádíte, zdrojové kódy tvoří svojí "přehledností" skvělý poukaz na obsypky, o ovladačích ani nemluvě. Přes toto cesta nevedla.
Proprietárnost nePOSIX systému by mi ani tolik nevadila, u Microchipu si na ni člověk tak nějak zvykne :-) Podobně i občas pokulhávající běh v reálném čase, jelikož v mých aplikacích (regulátory teploty, řízení kotlů, senzorika...) na nějaké mikro až milisekundě zas tak moc nezáleželo.Po nějakou dobu jsem používal vlastní jednoduchý systém, který mi zajišťoval konkurenční běh úloh, aniž by si žádal větší programovou režii. Avšak s rostoucí složitostí programů bylo potřeba učinit radikální řez - nakonec jsem skončil u zde téměř neznámého frameworku QPC od firmy QuantumLeaps (www.state-machine.com), který svým pojetím představuje do určité míry opozici k tradičním RT systémům v oblasti MCU. Hlavní důraz je zde kladený na hierarchické stavové automaty a událostně řízené programování... Osobně jsem s tímto systémem spokojený, byť si žádal nemálo času k pochopení a změně přístupu v programování :-)
-
MK (neregistrovaný)
Vzhledem k faktu, ze vyvoj embedded zarizeni zahrnuje HW, ktery se neda rozumne vyvijet metodou pokus-omyl, az to zacne "nejak" fungovat po x-te uprave odhadem jako u "moderniho" aplikacniho vyvoje a celkove to vyzaduje orientaci ve vice technickych oborech, ktere se musi doplnovat, tak to proste pro uspesne vysledky vyzaduje "staromodne" vecem rozumet od zakladu...
...no a kdyz uz tomu od zakladu nekdo rozumi tak, ze mu za to i plati, tak si v pripade jakehokoli problemu otevre referencni manual k MCU, podiva se pres JTAG/SWD do tech spravnych (obvykle perifernich) registru a problem si vyresi sam...
No a kdyz to ten dotycny dokaze, tak ma dost dulezitejsi a uzitecnejsi prace, nez brouzdat po forech a vysvetlovat zacatecnikum, kteri zatim nemeli cas nebo nebyli ochotni zacit poctive studovat principy mikroprocesorove techniky (elektrotechnika + zakladni teorie SW vyvoje), kde delaji chybu.
Tim padem kdo s tim umi, ten fora necte ani do nich nema duvod psat...
Nevim co se dnes uci ve skolach, ale ocekaval bych naivne, ze to, jak se zamyslet, vhodne vybrat prostredky, pouzit dokumentaci a vyresit zadany problem prakticky... ;-)
-
Cm (neregistrovaný)
mam s STM roky zkusenosti. Takze:
- HW je to dost dobrej
- vyvoj je velmi pohodlny, pouzivam c::b a GCC
- jakykoliv SW od STM lze pouzit pouze jako inspiraci, v zadnem pripade ne do release kodu. Je to totalni shit. Probiral jsem se hlavne STL tam to plati na 100%. Na HAL jsem uz nenasel odvahu, ale dle zkusenosti znamych je to to samy.
- od STM prevzit hlavickovy soubory pro platformu a zbytek vydiskutovat s manualem
- mne jejich manualy zcela vyhovuji ( na rozdil od nekterych kolegu )
- pokud neni prase, tak si casem si clovek vytvori knihovny pro pouzivane periferie a vyvoj je velmi rychly a efektivniAle chce se tomu chvili opravdu venovat. Za odpoledne se to seriozne rozbehat neda. Na druhou stranu, pokud se vse necha jak to bylo po resetu, tak rozblikani LEDky tim nejprimitivnejsim zpusobem vyzaduje jen nastudovani GPIO a chvilku prace. Takze pro start OK
-
PetrM (neregistrovaný)
Jenomže to je na STM32 taky. Když nepotřebuješ rozcházet DMA, HW CRC z podobný kraviny, tak si taky vystačíš s trojicí registrů. A když chceš víc, tak si to můžeš dopřát (za cenu složitější konfigurace, samozřejmě). To je na STM32 geniální.
UART, to je trivalita, stačí zapnout hodiny a přerušení, nastavit baudrate a CR1, namapovat na GPIO a jede. Další ovládání pomocí SR (status), CR1 (základní ovládání) a DR (data in/out).
Ostatní registry jsou třeba na RTS, CTS, podporu LIN, SIM karet, bit timeout, DMA,... a na standardní RS-232 nebo USB-UART adaptér pod přerušením nebo s čekáním ve smyčce je nepotřebuješ.
Jediný blbý věci, na který jsem u něho narazil, je absence HW přepínání duplexu pro RS-485 na F4 (nutnost šmrdlat pinem, F0 to umí sama) a volba jenom 8 nebo 9b (narozdíl od třeba AVR, kde je 5-9b).
-
Kiwi (neregistrovaný)
/* GPIOC Periph clock enable */
RCC_AHBPeriphClockCmd(RCC_AHBPeriph_GPIOC, ENABLE);
/* Configure PC8 and PC9 in output pushpull mode */
GPIO_InitStructure.GPIO_Pin = GPIO_Pin_8 | GPIO_Pin_9;
GPIO_InitStructure.GPIO_Mode = GPIO_Mode_OUT;
GPIO_InitStructure.GPIO_OType = GPIO_OType_PP;
GPIO_InitStructure.GPIO_Speed = GPIO_Speed_50MHz;
GPIO_InitStructure.GPIO_PuPd = GPIO_PuPd_NOPULL;
GPIO_Init(GPIOC, &GPIO_InitStructure);Tohle je asi pro někoho strašně složitý, že... Pak ovšem nechápu, k jakým účelům ten procesor chtějí používat, když tohle se jim zdá jako komplikovaná záležitost.
