Názory k článku STM32: mikrokontrolér vstřícný k amatérům

Za sebe můžu říct, že ono to zase tak růžový není, jako se vším.

STM32 jsou super z pohledu HW, zatím (na rozdíl od třeba SAMů od Atmelu všechno fungovalo), ale přesto je tady několik detailů, na který by měl být brán zřetel:

1) STLink I vs STLink II. Jednička je nepoužitelná a v Linuxu se tuším ani nedá rozchodit.
2) Dodávaný soubory s popisem periferek jsou zmatený a leckde obsahují cyklický inkluze atd. Strávil jsem asi dva týdny jenom fixováním, aby to šlo rozumně zbuildovat.
3) Některý HAL moduly jsou nefunkční. Třeba USB Device ve funkci COM portu nemá (resp. před dvěma lety) funkce pro zápis/čtení dat (!!!).
4) Když STM32, tak je výhodou použít FreeRTOS. Ten je dokonce součástí kódu, který vybleje STMCube (nástroj pro konfiguracia vygenerování projektu). Jenže co je platný naportovaný a běžící FreeRTOS, když obsluha HW nečeká na mutex nebo event, ale motá se v cyklu?

Z důvodů 2,3,4 mám napsaný vlastní HAL. Holt podpora SW ze strany výrobců MCU je standardně výsměchem a mezi slepými jednooký králem :( Asi ty knihovny píše nějaký student na praxi.

Existuje i komunitní řešení: https://github.com/libopencm3/libopencm3

Hodně nízkoúrovňové knihovny, ale zatím jsem neměl problém.

Jenže unstable APIs. Což může dělat hodně problémů a může to hodně věcí rozbít... :( Spravovat si vlastní kód je v tomto případě jistota.

Ono to je růžové asi jako socani. Pokud budete používat Standard Library, NEEEEEE HAL, Cube. A budete trochu umět Cčko. A použijete Keil (32kB Vašeho, přeloženého kódu). Jen proboha NEEEEEEE Atollic. Ten druhý den neví, že jste včera udělali projekt. Teda asi jen pod Win10. Jinak fungoval. Asi za to může šmírácký Win10, který je HOOOOOOOdně nefunkční.

Pepo, Atollic TrueSTUDIO je pro někoho jako jsem já, který nemá na KEIL, záchrana. Hlavně že mají napsaný GDP stack, tudíž to jde krásně ladit.

Po precteni par odstavcu me bohuzel presvedcilo, ze pan autor STM32 moc nerozumi... :(

Stm32 jsem si plny iluzi o tom jak to bude rychlejsi a lepsi nez ardiono koupil pred pul rokem. Musim podotknout ze nejsem programator a arduino jsem zvladl samostudiem, diky velke komunite a prikladum co jsou na webu vcetne podpory. To vse stm nema a to nejhorsi je ze tam nefunguje ani nic takoveho jako mnohdy velmi pomlouvane a zavrhovane ide na arduinu. U stm se mi doposud nepodarilo nic tak nativniho objevit. Proto za mne pro profiky asi dobry ale pro kutily jen velka ztrata casu.

Víš co? Já jsem se učil jednočipy na 8051 (ASM) a první Cčkový program byl na T89C8951ED2, nebo jak se to jmenovalo. Buildil jsem tehdy v SDCC přes command line a debugoval v terminálu pomocí výpisů. Co bych tehdy dal i za takový pitomý, nepoužitelný IDE jako C::B. Ale dalo se zvyknout...

Btw, Mardův seriál o STM32VL na mcu.cz jsi našel? A jak koukám, tak tenhle dnešní čánek už tam taky vyšel. Dva měsíce zpět. http://mcu.cz/comment-n4007.html

Zkus chibios a jeho nakonfigurovane eclipse chibistudio. Vyviji to chlapek, ktery dela pro st micro.

Zkus platformio - neni to IDE, ale teoreticky by s tim mohlo byt jednoduche programovat - a myslim, ze to zvladne zkompilovat nektery arduinovy kdo pro STM32.

Zkus energia.nu - umi army a je to v podstate 1:1 s arduino ide.

Jen mi teď došlo že stellaris launchpad se kterým jsem to používal jaksi nemá STM32 ale EK-LM4F120XL. Ale stačilo UTFG a vidím věci jako https://github.com/rogerclarkmelbourne/Arduino_STM32 - čili na prvotní osahání dostačující ...

OMG!
Stačí si stáhnout referenční příručku. V dodatcích na konci máš i příklady. Komu tohle nestačí, ať se raději věnuje okopávání brambor.

V jednoduchosti je krása. Napájení 4,5 až 15V ! Za cenu za kterou bych nevyrobil tišťák.
Pro řízení motorů USS Enterprise (NCC-1701) by to asi nebylo úplně ono, ale na tlačítka světýlka automatu na polévky super věc.

Pokud si někdo chce začít hrát s stm32 a nechce se mu příliš pájet je tu česká stavebnice BigClown která je založena na STM32L083CZ což je právě low power verze, základní jednotka má na sobě krom stm32 i teplotní čidlo, akcelerometr, rádio. Na githubu je sdk plus examply jak to programovat.

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/KRO­KOVAT!! 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 :)

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

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.

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

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 efektivni

Ale 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

AVR sa dá debugovať. Menšie procáky pomocou debugwire, vačšie maju aj JTAG.

Já si naopak myslím, že naprosté většině amatérů stačí právě to AVRko, právě proto, že tak obrovsky složité periferie vůbec nepotřebují, a jsou rádi, že k ovládání UART jim stačí 3-4 registry a pár řádek kódu...

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


/* GPIOC Periph clock enable */
RCC_AHBPeriphCloc­kCmd(RCC_AHBPe­riph_GPIOC, ENABLE);
/* Configure PC8 and PC9 in output pushpull mode */
GPIO_InitStruc­ture.GPIO_Pin = GPIO_Pin_8 | GPIO_Pin_9;
GPIO_InitStruc­ture.GPIO_Mode = GPIO_Mode_OUT;
GPIO_InitStruc­ture.GPIO_OTy­pe = GPIO_OType_PP;
GPIO_InitStruc­ture.GPIO_Spe­ed = GPIO_Speed_50MHz;
GPIO_InitStruc­ture.GPIO_PuPd = GPIO_PuPd_NOPULL;
GPIO_Init(GPIOC, &GPIO_InitStruc­ture);


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.

Nehledě na to, že tohle jim vygeneruje Cube, takže to vymýšlet fakt nemusí. A pak už stačí jen použít něco jako
HAL_GPIO_Toggle­Pin(LED_GPIO_Por­t, LED_Pin);

ADC+VCP z arduino IDE zabere cca 250kB
v Keil uVision ADC+VCP+hnusně napsané LCD má 20kB

teto vete tedy moc nerozumim:
"Co se výpočetního výkonu týče, vítězí Raspberry, za ním jsou ARMy a nakonec 8bity."

V RPi neni ARM? Nebo co to znamena oznaceni ARM? Cokoli od miniaturniho M0 (kteryho nektery osmibity prekonaji!) az po multijadro AArch64?

Tiez som sa nad tym pozastavil. Mozno tymi ARMamy myslel rozne mikrokotrolery na ARMe zalozene.

> miniaturniho M0 (kteryho nektery osmibity prekonaji!)

Které třeba?

Silabs nebrat ani pod pohrůžkou násilí.

Proč? Protože staví na 8051. Na tom se nedá normálně používat C. Kde není C, tam je potřeba ASM. A kde je ASM, tam klesá udržovatelnost i efektivita vývoje a člověk se zamkne na jednu věc.

Tohle patří do muzea, ne do vývoje v 21. století.

ESP maximalne ako wifi modul. Radšej by som skusil nejaké procaky Texas instruments. Code composer studio od TI funguje aj na linuxe.

No ty taky nejsou kdoví jaká hitparáda. STM32 při srovnání na jednom z posledních projektů vyšel o 30% levněj než srovnatelná MSP430. S tím, že je tam vyšší výkon, 32b, srovnatelná spotřeba, víc paměti a lepší periferky. A standardní jádro, takže kdyby STM32 skončilo, stačí přeportovat periferly třeba na LM nebo LPC. U MSP430 je všechno proprietální.

A pokud se podíváš na originál hlavičkový soubory k MSP430, doporučuju mít ucpávku v konečníku, jinak nedoběhneš.

Není co řešit...

S tým že MSP430 su grc súhlasím, nie je nič frustrujucejsie než nefungujuce examply pre niektoré exotickejšie procaky (napr tie s FRAm pamatou). Mna viac chytili DSP texasu, ziatial mi stačia TMS320F2802x a TMS320F2803x (C28x Picollo seria). Ked sa prekonaju prvotné problémy so spustanim programu z RAM alebo Flash, tak potom sú to celkom v pohode procaky, teda aspon na to čo robím - vykonové meniče a meranie/digitalne spracovanie/ge­nerovanie signálov. Medzi amatermi dosť neznáme, ale videl som ich už v konkurenčných frekvenčných meničoch aj solarnych invertoroch.

Mne by zajimalo koli vocasu zacne remcat nad kompletnim kitem za 3kkc kde je pomalu i ta pajka pri dnesnich cenach. Pamatuju jak nebyla k dostani ceska mcu hrackarna pod 7kkc a to bylo jen nejakych 20 let tomu nazad. Levne kity dostavaly pouze prumky (ano, tehdy kdo nechodil na prumku byl lama) a par prestarlych inzenyru vyrabelo pro studenty nejake prototypovaci desky. Ve skrze jen klavesnice,LEDky atd.

STM32 (F4 a F37) jsem zacal pouzivat pred par lety pro narocnejsi projekty, kde AVR nestaci.
Napr. pro zpracovani mereni je velmi pohodlne mit hardwarovy floating point, a u STM32F37
jsou vyborne precizni sigma-delta ADC. O DMA a spouste dalsich periferii ani nemluve.
Pro zacatecnika jsou prvni kroky urcite tezsi nez s 8bity, kvuli mnohem komplexnejsimu nastaveni.
Na druhe strane, i pro amatery jsou STM32 vhodne, pouzdra QFP typu s rozteci .5mm jsou rucne pajitelna
(sam jsem to delal) a DPS se necha za par dolaru vyrobit v Cine. Pro zacatecni hrani staci samozrejme discovery kit. Sam nepouzivam zadne IDE, jsem "fanda prikazove radky", takze vim, gcc, make, stlink. Pred par lety jsem
napsal i malinke howto na toto tema s par triky a ukazkami zdrojaku:
http://www.pittnerovi.com/jiri/hobby/electronics/stm32f4/index.html

Vstřícný k amatérů, to si jako děláte prdel? Vstřícný k amatérům je takový MCU, který žádný podělaný vývojový kit ani žádnou podobnou prasárnu nepotřebuje.

Důležitá otázka: je kompilátor, toolchain a programátor dostupný v běžném linuxovém distru? Funguje to bez zbytečných doinstalování binárních sraček? Stačí k naprogramování pár drátků do paralelního portu? Kolik "bižuterie" je potřeba, pokud si chci navrhnout vlastní desku s tímto MCU.

A ne nějaké podělané kity!!!

Každý si představuje pod pojmem "vývojový kit" něco jiného. Jsou třeba desky, kde je základní zapojení MCU a hotovo. Viz ebay, "STM32F minimum development kit"

- Na druhou otázku odpovídám ANO.
- Nevím co myslíte binárními sračkami. To je nějaké přerušovaná stolice?
- Pár drátků do paralelního portu nestačí, protože programátor je do USB a pak jsou třeba 3-4 drátky. Viz ebay " ST-Link Mini V2"
- Kolik bižuterie - a až mě to nebaví. Co takhle místo vykřičníků zagooglit? Malá nápověda - je to srovnatelně málo, jako u starých osmibitových MCU typu ATMega.

Jestli jste omylem vrhnul svoji stolici na svůj kit, tak bude asi lepší přehodnotit pracovní postupy.

Podpora ARMů je standardně v GCC pro jednočipy non-eabi toolchin. OpenOCD a STLink na debugování, jako IDE C::B, Eclipse,...

Jako programátor mám nodmálně Discovery kit (na USB), no problem. Paralelní port je za tímto účelem out cca 15 let (co umřely W95/98/ME). Ostatní rodny widlí ani Linux tě normálně nepustí z aplikace k HW (žádoucí chování) a nemůžeš si jenom tak šmrdlat drátkma, i kdybys tam ten port fyzicky měl. Pokud to máš jinak, udej svoje časoprostorový koordináty.

Bižuterka u STM32 (ta povinná) jsou blokovací kondíky 10nF co nejblíž ke každýmu napájecímu pinu + 2u2 keramika z každýho vývodu VCAP proti zemi. S tím, že
- Když chceš externí krystal nebo oscilátor, tak ho připojíš. Když ne, jedeš na interní RC.
- Když chceš on-board ladění, tak čtyři 10k odpory navíc (pull-up, pull-down na příslušný piny).
- Když chceš externí RESET nebo WDT, přidáš externího brouka.
- Když chceš zálohovat RAM a RTC, tak k pinu VBAT hodíš BAT45C a 100n kondík proti zemi. Jinakten pin upneš na napájení.
- Když chceš RTC, přidáš hodinkový krystal a dva kondíky. Jinak máš ty dvě nožičky jako GPIO.
- Když chceš přesnou referenci pro ADC/DAC, máš na to extra pin a prostě tam tu referenci přivedeš. Když nechceš, pin zapojíš na Vcc a máš jako referenci napájení.
Zbytek je na čipu a zapneš/vypneš si to softwarově za běhu.

A kit je potřeba k tomu, že periferky nemůžou jet v luftě. Když chceš ladit Ethernet, potřebuješ k tomu mít LAN PHY. Když chce ladit grafiku, potřebuješ přidat externí video ram a konektor pro displej. Když chceš ladit NAND FLASH, musíš ji mít na sběrnici. Když chceš dělat s audiem, musíš mít ADC/DAC pro audio na I2Sku...

Navíc kity mají jednu obrovskou výhodu, pokud děláš na nějakým placeným projektu. Když koupíš kit třeba u Farnella, za dva dny můžeš testovat na reálným HW, jak se nějaká část chová. Když budeš hned dělat desku, tak týden navrhuješ, měsíc na sehnání součástek, výrobu desky a osazení a pak teprve zjišťuješ, jestli ti ten procák (ne)vyhovuje s tím, že měsíc a půl práce (materiál + mzda, klidně 100k) možná spláchneš do WC... Budeš se divit, ale na jednom projektu jsme právě kvůli času ocenili kit za $1200

"Linux tě normálně nepustí z aplikace k HW"

Je triviální napsat si udev pravidlo, aby k HW pustilo specifickou grupu...

"Budeš se divit, ale na jednom projektu jsme právě kvůli času ocenili kit za $1200"

Co na slovu "amatér" je ti nesrozumitelného?

Baví mě porovnávání AVR oproti STM32. AVR jsou hloupé mikrokontroléry, které nic moc neumí. Proto je jejich ovládání tak jednoduché.
STM32 má ARM jádro, už tím vznikají složitější postupy jak co nastavit. Ale nastavit GPIO jako výstup s pull-upem nezabere 15 řádků kódu.
Chcete-li to používat stejně jako Arduino, moc neoceníte různé "fíčury" a zůstanete u jediné výhody a to, že má víc FLASH a RAM. Ostatní vám zůstane skryto.

Zkoušel jste někdo ATXmega? To je "paráda" na nastavování periférií...

Kdyby byly STM32 tak hrozně špatné, neprodávaly by se milionů kusů denně.
Pro bastlíře, který zná jen ATmega328 (čti Arduino) jsou jednoduché a funkční cesty, jak mít STM32 "jako Arduino". github.com/stm32du­ino. Tak či tak, já začal na 89C2051, přes ATMega8(a další), MSP430 až jsem skončil na STM32 a nedám na ně dopustit.

Přechodem na nový mikrokontorlér VŽDY vznikají překážky.

O ATXMega nemluv, mám kopřivku, jenom si na tu hnědou lepkavou věc vzpomenu.

1/4 času na projektu zabrala komunikace s arogantníma kreténama od Atmela, protože odmítali uznat, že jejich HW nefunguje, zásadně nepsali do dokumentace "nepodstatný detaily" jako tolerance bandgap reference,... A když napsali, tak v reálu se některý parametry o stovky procent lišily (standby spotřeba, například).

Nebo třeba za běhu vydali jinou revizi čipu, kde u některých perferek přeházeli registry, probuzení ze spánku trvalo 450ms (!!!) protože si nějaký hňup při návrhu čipu prohodil dráty. A erraty typu "I2Cx nemá vyvedený signál SCL. Workaround: Nepoužívejte jej" s tím,. že lákají zákazníky na počet I2C a započítají i nefunkční....

A to byl projekt, na který jich padlo 200k ročně. Nechci si ani představovat, jak by to dopadlo být v garážovce, která by dělala 200ks ročně a neměl bych přímou lajnu na jejich support do Indie.

Xmegu jsem chtěl zkusit kvůli novému USB rozhraní, ale ukázalo se, že pod Linuxem to nebude vůbec jednoduché, oficiální podpora je jen na vývoj pod Windoze. Vždy jsem používal alternativní USB stacky (LUFA, V-USB) a bez problému, podpora Xmegy je tam ale ve stádiu experimental, nebo jsou forky na GitHubu od nějakých dobrých duší - též experimental. Takže jsem to nakonec uložil k ledu. Po referencích na Xmegy, co člověk všude možně slyší, mě nic nemotivuje se k tomu vrátit, asi to už neopustí šuplík.

To dřív zkusim nějakou novější megu nebo tiny s usb rozhraním nebo přejdu na PIC... anebo se spokojim s čistě sofwarovým stackem, jako jsem to po amatérsku dělal doteď.

Trochu mi v tomhle úvodu chybí zmínka o tom, jak naprosto zásadní je STM32 pro drony nebo pro modelové létání obecně. Betaflight běží na STM32. [https://github.com/betaflight/betaflight] Už tohle samo o sobě znamená pro STM32 pozici v síni slávy; dnes už asi neexistuje závod dronů, kde by Betaflight nehrál klíčovou roli. A pak je tu samozřejmě (původní) Cleanflight, poněkud radikální Raceflight nebo fotografickým dronům přizpůsobený iNavFlight. Vše na STM32, samozřejmě, se spoustou společného kódu. Pixhawk je další flight controller, který má STM32 [https://pixhawk.org/modules/pixhawk] a donedávna byl zaměřený spíš na autonomní létání než na závodní drony (ano, donedávna: https://pixhawk.org/modules/pixracer). Pixhawk nemá nic společného s Betaflightem; používá firmware PX4 založený na drobném RTOS řešení. [https://github.com/PX4/Firmware] Samozřejmě to nekončí flight controllery. STM32 je taky v transmitterech (Taranis (OS OpenTX), Devo (OS Deviation)), v receiverech (FrSky přinejmenším), dokonce i v některých ESC a tak dále. Bez STM32 by se dnes asi tolik nelétalo a pokud ano, bylo by létání mnohem složitější.

Hraju si s klony maple mini (STM32F103) z Číny za 2 až 3 dolary, perfektně podporovaný ChibiOS + grafická knihovna ugfx na touch tft přes 8bitový paralel, vývoj v eclipse a nepřijde mi to až tak zásadně složitější než komplikovanější projekty v arduinu. HAL pro STM32 je v ChibiOS docela slušný http://www.chibios.org/dokuwiki/doku.php?id=chibios:product:hal:platforms , rozhodně není ovládání pinů na 10 příkazů http://www.playembedded.org/blog/en/2017/09/02/stm32-gpio-chibios-pal/#Changing_the_logic_level_of_output_pins

Ještě jedna drobná poznámka ke složitosti HW. Ať je HW sám jakkoliv složitý, programátor to má vždycky tak složitý, jak si to udělá.

Pokud si napíše modul, do kterýho schová obsluhu, tak bez ohledu na platformu stačí inkludovat gpio.h (ovladač GPIO), hardware.h (s makrama s mapováním periferek a nastavením), zavolat SetPin(PORT_LEDKY , LED_4) a je to. Takže na úrovni logiky aplikace je změna pinu vždycky na jeden řádek. Podle desky mení konfiguraci, podle procesoru střídá verze souboru gpio.c, který přilinkuje.

Pokud je někdo blbec a na padesáti místech ručně nastavuje hexa hodnoty do registrů mimo ovladač, tak si to utrpení právem zaslouží. A ideálně i po roce portaci na jiný typ brouka/jinou desku, aby si při hledání jedné zapomenuté změny z 850ti zapamatoval, co je to abstrakce.

Když člověk potřebuje něco na takt přesně načasovat, tak jsou mu veškeré knihovny nahovno...

Shodou okolnosti si zrovna hraji s procesory STM8. A mam nekolik problemu.

1) ST zapomelo definovat rozlozeni pinu na tech 4-pin ISP konektorech, coz v praxi znamena, ze kazda deska to ma trosku jinak a clovek porad musi zkoumat, jak zapojit ISP kablik. Ocekavam, ze u STM32 to bude stejny chaos. Porovnam-li toto s ISP pro ATMEL, tak tam je to snadne, prakticky se pouizvaji jen dva konektory, starsi 10-pinovy a novejsi 6-pinovy, ktery se dnes pouziva na vsech novych deskach;

2) Licencni politika ST. Prakticky vse je chraneno nejakou neprijemnou licenci; bez registrace si s webu ST moc nestahnete, i pro stazeni blbeho ISP programatoru musite ST sdelit platnou emalovou adresu; Potreboval jsem novy firmware pro STLINK-V2; dva dny mi trvalo, nez jsem se k tomu dostal; nevim, zda byla chyba na me strane, nebo tam meli nejakou chybu a posilali mi spatny link. Proste peklo, ktere Vam zacatek neusnadni.

3) SDCC; z nejakeho duvodu nejsou v SDCC knihovny pro STM8 procesory; nenasel jsem ani definice registru (adresar /usr/share/sdcc/in­clude/stm8 neexistuje). Toto muze byt dusledek licencni politiky ST. Takze si vse musim najit v datasheetu a napsat vlastni definice HW. Take je mozne, ze ty definice jsou tak rostristene, ze nema smysl to psat obecne (nikdo nemel potrebu s tim ztracet cas). Anebo jen je ta podpora v SDCC prilis cerstva, ze se tam tyto soubory casem objevi.

4) Chybi C++ prekladac (gcc STM8 nepodporuje), coz je pry duvod, proc Arduino nebylo portovano pro STM8. Existuje nejaky pokus, ktery stavi na SDCC, a autor vysvetluje proc nemuzu udelat plnohodnotny port; chybi C++; takze vytvari nedokonalou kopii v SDCC; problemem jsou moduly.

5) Nevyrabi se STM8 procesor v DIP pouzdru; na eBay lze levne sehnat ruzne male modulu vcetne regulatoru napeti, tlacitka reset a nekolika LED, ale to je rozmerne v porovnani s DIP pouzdrem.

6) Obecne povedomi o STM8 je nizke; temer kazdy zna a pouziva Atmel AVR, pripadne PIC; STM8 je exotika. Chybejici pozdro DIP muze byt zasadnim duvodem, proc jsou tyto MCU amatery ignorovany.

Nejaka pozitiva? Ano, ten STLINK programuje procesory rychle, to se mi libi stejne jako to, ze k programovani staci pouhe 4 piny. A ty procesory jsou velmi levne a maji dost RAM a z Ciny lze levne sehnat ruzne moduly ktere tyto procesory pouzivaji. Zatim jsem nasel jen same regulatory teploty a podobne zamerene moduly a nenasel zadnou hracku, ktera by byla rizena STM8, treba hodiny s LED displejem, analogove hodiny s LED, nebo jednoducheho robota (treba sledovani cary); vsechny hracky na eBay pouzivaji procesory ATMEL nebo casteji, cinske verze vylepsene 8051 (STC15Wxxx, STC15Fxxx, STC89Cxx, atd).

A proc pouzivat STM8 a ne STM32? Treba proto, ze STM8 lze provozovat i na 5V... ;-) Teoreticky by to mohla byt zajimava alternatova k AVR od Atmelu, ale bylo by treba vyladit nekolik detailu, treba to C++...

Ale to H8S se dá taky používat na 5V, programovat pomocí čtyř pinů (zem, reset, rxd, txd),... A má to podporu v GCC. Akorát to nikdo nezná...

Osmibitů jsou tři zadnice a kousek. Jenomže je tam několik průšvihů, pomalostí výpočtů počínaje (násobení 16b * 16b se provádí na čtyři části a ty je ještě třeba složit), malý rozsahy adresování a z toho plynoucí odrbávky při potřebě větší paměti, pomalost, špatná podpora (protože nikdo neodladí pořádně tool, který používají 2% lidí),...

Přitom ARMy nasadily výkon x-krát vyšší, odladěný tooly, jednotnou HW/SW platformu pro několik výrobců*) a cenu často nižší, než stejně vybavený osmibit. No není o čem (v profi projektu)...

*) Výjimkou je třeba SAM-ICE, verze JLINKu zamčený jenom pro Atmely

Technická poznámka. Na osmibitu NEJDE používat C++ ve smyslu toho, co jako C++ definuje ANSI standard. Tam je tak šílený overhead, že tolik ramky nejenom nebývá na čipu, ale ani by jí tolik nezvládl adresovat.

Arduino je co ? C++ na osmibitu. C++ může být trochu náročnější na paměť, ale pokud v něm píšete trochu umravněně, je to v zásadě stejné jako čisté C. Výhoda 32-bit architektur je jen v tom, že používají zpravidla jednotný adresní prostor, což velmi usnadňuje vývoj překladačů z vyšších jazyků. Takže pro ARM můžete použít třeba clang a tím pádem i vše co je postaveno nad LLVM. Jsou různí podivíni a ti si tak můžou poměrně snadno stvořit vlastní kompilovaný jazyk a ten pak používat.

DIP neni historicka zalezitost. A SMD pouzdro neni jen o pripajeni na desku; pro vyvoj je DIP super. DIP obvod lze dat do levne patice a velmi snadno vyjmout, vymenit. Pripajet SMD umim, na vymenu SMD nenam vybaveni, takze takovy pokus konci poskozenim PCB. Asi jsou i patice pro SMD pouzdra...

Chapu ze vetsina tech obvodu je v SMD provedeni, pro masovou vyrobu je to jedina rozumna moznost. Ale STM8 nema jediny obvod v provedeni DIP pouzdra, obvod ktery by byl vhodny pro vyvoj a pro DIY. Z meho pohledu je to dulezity faktor, proc se zatim neprosadil v amaterskych projektech. Srovnejte s PIC & AVR & C51.

Co se tyka C++, mozna to neni jen o C++; duvodem muze byt, ze GCC generuje lepsi kod nez SDCC. Cinan to neresi, vsechny zdrojaky co jsem sehnal pro 8051 byly psane pro KeilC a ten rozdil proti SDCC je videt, KeilC kompiluje lepe; pokud je kod na hranici velikosti FLASH, tak se musi udelat hodne rucni optimalizace, aby se tam vesel i po prelozeni SDCC. Neocekavam ze pro STM8 bude SDCC generovat lepsi kod...

DIP je těžká historie. Nevyřešíš u něho chlazení (PowerPad), je to velký, max. 48 nožiček (nebo PLCC, kde je taky možnost patice do 84 nožiček), takže z toho ani nevytáhneš dost GPIO a musíš cpát brouky kolem.

Výměna odpálenýho brouka v protoypu? To obvykle znamená, že někdo pohnojil zdroje, nebo rve do GPIO co nemá a po výměně to zařve zase. Tohle neřeší patice, tohle řeší při návrhu myslet a než dám desku do výroby, tak si projít jednu cestu po druhé a zkontrolovat, že ti neuteče dým. Když si tohle ověříš, jsou obvody nesmrtelný bez ohledu na pouzdro.

Jaká je výhoda 5V provozu? Většina periferií funguje na 3.3V, kromě těch speciálně dělaných pro základní arduina.

To je hodně dobrá otázka. Asi aby se mu to líp napájelo z 3.7V LiIonky :)

Ve skutečnosti opravdu není důvod řešit velikost napájecího napětí.

Logika kolem - 74HC a 74AC jedou od 2V do 7V. S 3V3 nemají sebemenší problém.

Pokud potřebuju výstup na 5V, pokužiju 74HCT - vstupní úrovně sedí, výstup je v 5V TTL.

Vyšší napětí a proudy (12V/1A) musím tak jak tak řešit tranzistorama a 3V3 na saturaci tranzisotru stačí s přehledem.

5V vstup do 3V3 procáku taky není problém, stačí odpor na omezení proudu do vstupu a klampovací diody se postarají o zbytek.

Získat 3V3 je stejně easy jako získat +5V, u buck konvertoru stačí vyměnit dva odpory za jinou hodnotu, u lineární stabilizace třeba hloupá LE33 místo 7805.

Jediný rozdíl je, že pokud klesne napětí tak, že už neutáhne zdroj 5V, 3V3 jedou vesele dál.

S mikročipy si jenom hraju doma, ale 5V už skoro nepoužívám. Jenom když potřebuju rychlejší arduino, pak vezmu 5V klon mini pro (atmega328) na 16MHz a pustím jej na 3.3V. Běží sice mimo specifikaci, ale zatím vždy OK.

Ale ty STM8 procesory umi i 3.3V, tech 5V je bonus, ktery STM32 nema. Treba USB ma 5V, lze to tedy pripojit primo, neni treba regulator na 3.3V.

Kristova prostřední noho... LE33 seženeš za 16Kč v drahým obchodě. Stojí ti regulátor za míň jak dvacku za to, aby se drbal s optimalizacema, řešil shift registrama za půl sta míň GPIO,...?

Navíc ten stabilík je i jako ochrana proti přepětí, takže si hned neodstřelíš MCU.

Vetsina tech malych projektu jsou jen stavove automaty, zobrazovani udaju na LED/LCD, generovani PWM, komunikace po I2C, seriova komunikace pres RS232/USB, na to 8-bit staci. 16x16 nasobeni je treba az kdyz se zacne uvazovat o serioznim zpracovani analogovych signalu, pak muze byt vyhodnejsi DSP nebo 32-bit MCU. Pokud se vyzaduje i sitova komunikace (Ethernet/WiFi), nema dnes smysl pouzit 8-bit.

O H8S nic nevim; na eBay se neprodava, pokud jsou tam vzorky, jsou ukrutne drahe. Pro me je eBay vyznamnym indikatorem trhu, co se pouziva a co je exotika. Pokud delate v raketovem vyzkumu, eBay muzete ignorovat, a objednat od vyrobce presne ten procesor, ktery potrebujete... Je zajimave, ze exotika jako H8S ma podporu v GCC.

Rensas není exotika, jenom jiná liga. Průmysl, automotive, spolehlivý věci. Dělal jsem na projektu, kde padlo za pár let 4.5M H8S/2118 a 1.5M H8S/2134. Na konci výroby jsme posílali těch 200ks, co neprošlo testama, na analýzu. 180 jich bylo mimo toleranci, 20 špatných. Pravda, i v tomhle množství to bylo po 3$ za kus.

Podpora v GCC je od firmy KPIT - https://www.kpit.com/ Dělají i industry/tran­sportatio/medi­cal, potřebovali kompilátor pro spolehlivý MCUčka, tak si udělali reklamu na GCC. NIc podívnýho za tím hledat nemusíš. Dělal jsem na tom asi 10 projektů a šlapalo to fajn.

eBay je spíš indikátor, že je něco moderní. Někdo něco ubastlí, lidi se toho chytnou, zvedne se vlna poptávky a číňani nacpou klony na ebay. O kvalitě, dostupnosti a podpoře produktu to neříká vůbec nic. Já se třeba rozhoduju tak, že si před projektem udělám tabulku, do ní nasypu parametry nalezených brouků a porovnávám, co z toho vypadne ( a STM32 nebo H8 z toho padá podezřele často).