STM32 fejelsztői környezet

Fejlesztés

Fejleszt(get) valaki ilyenre? Milyen fejlesztői környezetet használ?
Szeretnék valami egyszerű de megbízható környezetet Cortex M0 - M3 -ig. Ami első lépésben kellene a compiler - melyiket is, valami amivel tudok flasht programozni (ST-LINK V2 ocó Kínai modell). Persze a debuggolási lehetőség is jól jöhet de még ráér.
Persze szeretném, ha ez képes lenne együtt működni a meglévő Linux fejlesztői környezettel - azaz nem annyira egyedi környezet, hogy semmi másra nem használható, így vagy virtuális gép vagy egy teljesen más konfiguráció.
A Debian előnyben.
A cross platform felállás, nekem úgy tűnik arról szól, hogy a különféle architektúra, de Linux, nem "bare metal".
Később, kellhet valami library - most nem ugrik be hogy hívják a szabványt.

OFF: Miközben az STM8S103F mcu -val piszmogok (inkább hobby mint üzlet - nagyon cuki) egyre közeledik az a pont amikor "de jó is lenne" ha ez mégis inkább 32 bites lenne. Máris kezdem súrolni a korlátokat. Újra ránéztem az árukra és azt látom hogy a 32 bites olcsóbb :O

( apal v | 2018. 01. 13., szo – 16:09 )

Igen. Reszletesebben:
- amik szobakerultek: STM32F302CBT6, STM32F407VGT6;
- elektronika tervezes: gEDA/gschem, gEDA/pcb;
- forditas: gcc-arm-none-eabi, binutils-arm-none-eabi;
- perfieria konyvtarak/headerek: en.stm32f30x_dsp_stdperiph_lib.zip, en.stm32f4_dsp_stdperiph_lib.zip;
- programozo hardver: ST-Link v2;
- programozas, debuggolas: openocd.

Mindez kozonseges mezei Debian alatt (debian/stretch, minden van csomagban). Igaz, a fenti *.zip-ekbol csak a CMSIS-t ill a periferia-regiszterkeszlet headereket hasznalom, igy inkabb "bare metal"-hoz all kozelebb a programozas. A linkelest is -nostartfiles opcioval csinalom - de a fenti *.zip-ekben van minden. Igy mondjuk talan jobban meg lehet ismerni a cuccok lelkivilagat, de persze igyis meg ugyis vannak kihivasok a dologban :)

Ez is egy jo kiindulas: https://www.triplespark.net/elec/pdev/arm/stm32.html.

Mindezenfelul jatszashoz egy, a fenti linken is hivatkozott "discovery board"-ot is erdemes beszerezni szerintem. En anno ilyesmit rendeltem. Vagyis ez a linkelt tipus (meg) rendelheto, az eggyel-kettovel korabbi amit anno rendeltem, mar sajnos kifutott. Ezeknek boardnak az az elonye hogy:
- a programozast a beepitett ST-Link v2-vel is meg tudod csinalni (USB, bedugod, mukodik);
- kulso ST-Link v2-t is hasznalhatsz (4-6 madzagot kell atkotnod, tapellatastol fuggoen);
- sajat elektronikak fejlesztesehez a kesobbiekben ezt a boardot is tudod hasznalni mint egy ST-Link programozo.

Egy hatranya van ezeknek a boardoknak, megpedig az hogy kommunikaciohoz fizikai illeszto (phy) nincs nagyon rajtuk. Szoval TTL UART-ot le tudsz vezetni egyszeruen de pl RS485-ot, RS232-t vagy hasonlokat mar nem. Ahol nem kell fizikai illesztes (pl SPI) ott persze nincs ilyen problema.

( Foltos | 2018. 01. 13., szo – 17:26 )

Fejlesztői környezetnek Eclipse CDT -t javaslom (https://www.eclipse.org/cdt/). Érdemes ezt a plugin -t is feltenni: https://sourceforge.net/projects/embsysregview/?source=directory
Debuggolás: Eclipse alatt GDB -megy, azaz kell egy PC -n futó GDB szerver ami beszél a debug interfészeddel, az pedig SWD -n vagy JTAG -en a hardverrel. Erre régebben a már emlitett OPENOCD volt ingyenes megoldás (http://openocd.org/). Az egyik fizetős verzió pedig: https://www.segger.com/products/debug-probes/j-link/tools/j-link-gdb-se…

Debug interfésznek sok minden szóba jöhet:

Flash programozás:
A debug interfész csak hozzáférést ad a hardwerhez, azaz megoldja a kommunikációt. Az Eclipse+DBG szerver (openocd) megoldja a debuggolást (regiszterek olvasása/írása, break pointok, stb...), viszont nem tud FLASH -t programozni. A fizetősz IDE -k (IAR, Keil, etc...) rendelkeznek FLASH programozásra valamilyen megoldással. Letöltenek JTAG -en keresztül RAM -ba valamilyen FLASH programozó programot, majd JTAG -en letöltik RAM pufferbe a programod darabjait, és JTAG -en vezérelve a programozó alkalmazást felprogramozzák a FLASH -t. No erre pár éve még nem volt FLOSS megoldás.
Sok MCU rendelkezik pl soros boot-loader -rel, azaz soros porton fel lehet programozni. Ehhez kell a PC -dbe egy sorosport (USB Serial manapság), meg egy programocska ami elküldi sorosporton a programodat. (pl https://sourceforge.net/projects/stm32flash/). A letöltendő programot általában vagy raw-bináris formátumba vagy s-record formátumba kell konvertálni letöltés előtt. Ha GCC -t használsz objcopy a barátod.

Compiler:
Ha ingyenes kell, akkor GCC: https://developer.arm.com/open-source/gnu-toolchain/gnu-rm
Mivel a GCC FLOSS, bárki fordíthat binárist a meglévő forrásokból, így több bináris terjesztés is létezik ARM támogatással. Jelenleg az ARM port hivatalos karbantartója az ARM (link fent).
A C környezet nélkülözhetetlen része a standard library. A fizetős fordítóknak ez szerves része, ám a GCC -nek nem. ARM körökben legtöbbször newlib -et adnak hozzá. Sajnos ez elég nagy méretű, érdemes lehet a későbbiekben alternatívát keresni.

Egyebek:
Az ARM Cortex MCU -khoz ad könyvtárat ami a core perifériákat támogatja. Ez CMSIS néven fut. Github -on fent van.
A legtöbb gyártó ad ingyenes driver könyvtárat a chip -jeihez (timer, UART, SPI, DMA, etc...). Ezek legtöbbször tartalmazzák a CMSIS -t. Működnek, de elég limitáltak, és a verziók közötti kompatibilitás is problémás. Arra valók, hogy gyorsan össze lehessen prototípusokat kalapálni belőlük, bár (sajnos) sok termékbe is bekerülnek.

ARM -on érdemes elgondolkozni egy RTOS használatán is. Ezekben e körökben az OS jelentheti az ütemezőt illetve a hozzá tartozó szinkronizációs eszközöket (event, mutex, etc...), de akár "Linux" szerű, sok szolgáltatás adó környezetet is (TCP/IP, file-system, etc...). Itt érdemes megnézni a FreeRTOS -t (nemrég volt hír, hogy támogatja az Amazon felhő szolgáltatása), a ChibiOS -t, illetve az mbed -et.

Ha nagyobb MCU -d van (órajel > 100MHz, van >100K RAM -od), illetve az alkalmazás egyszerű érdemes eljátszani valamilyen szkript nyelvvel. Pl:https://micropython.org/, http://jerryscript.net/, http://www.eluaproject.net/. Ezek portolása sok tapasztalatot adó kihívás, az eredmény pedig egy nagyon flexibilis kütyü. Egyszerű feladatokra illetve protontipizálásra ideális.

Működnek, de elég limitáltak, és a verziók közötti kompatibilitás is problémás
Igen, sajnos ezek a konyvtarak sok esetben nem masok mint a periferia-regiszterkeszlet fuggvenyekkel torteno manipulalasa. Ami abban az esetben amikor viszonylag egyszeru periferiarol van szo (pl az STM32F3xx-nel az UART) akkor tkp teljesen jo a gyakorlatban.

De nehany periferianal annyira kacifantos a tortenet hogy ez a doksi elolvasasa alol es/vagy valami sokkal magasabbszintu konyvtar hasznalata alol nem ment mar fel. Pl az STM32F3xx-nel az SPI mezei klasszikus 8-bites uzemmodban valo hasznalata elegge nagy szopas volt, mert csak 16 ill. 32 bites fifo-kvantumokban erheto el az adat regiszter. Igy mar egy "kuldj ki mondjuk 5 byte-ot egy eeprom/flash muvelethez" folyamat sem igazan jol kezelheto :/ Vsz itt arra gondolhatott a kolto hogy ilyen mezei klasszikus 8-bites uzemmodban inkabb az USART-ot hasznald, sync uzemben. Mindezzel parhuzamosan meg az STM32F4xx-nel meg ugyanolyan egyszeru a mezei klasszikus 8-bites SPI kezelese mint mondjuk egy AVR eseteben.

Háááát....

Az ebay -es oldal tele van marhaságokkal. Pl elobb irja hogy tud PIc32 -t meg Renesast, lejebb márcsak ARM procik vannak a listaban.
Azt irja, van benn ethernet, de csak USB csatlakozoja van.
Azt irja, hogy GDB kompatibilis, de ez GDB stub vagy GDB server nelkul nem fog menni. A Jlink-pro -ban van beépitve GDB stub, de annak van ethernet portja. Val a seggernek kulon GDB szervere is (PC -n fut), de nem tudom evvel menni fog e. Openocd, vagy pyocd megoldas lehet.

Ma már van DAP-link (CMSIS-DAP), az STM discovery boardjai használhatóak JTAG/SWD interfészként, illetve kis turással lehet találni stlinkv2 vagy jlink firmware kompatibilis boardokat (pl https://github.com/jeanthom/DirtyJTAG).
Gondolom a kinai verzio is valami stm32 alapu STLink v2 kompatibilis off-the-self board, segger Fw -vel (https://www.segger.com/products/debug-probes/j-link/models/other-j-link…). Mondjuk ez alapján akár jó is lehet.

Majd írd meg hogy megy.

Inkább majd keresek valakit Bpesten aki egy teszt kedvéért segít. (Azt sem tudom pontosan mit várhatok el tőle, ill. mit is érdemes megnézni)
Az meg hogy az eBay kereskedő összehord hetet-havat már megszoktuk. Talán egy próba ennyit megér.

* Én egy indián vagyok. Minden indián hazudik.

+1 az System Workbench for STM32 (sw4stm32) és az STM32CubeMX-nek! Nagyon jól használható mindkettő. Az STM32CubeMX-el könnyen generálhatók alap driver-ek mindenféle perifériához.
OFF: írtam egy filerendszert NOR flash-ekhez. STM32Fxxx procikhoz van demó is, PC-hez emulátor. Valaki más is kipróbálhatná rajtam kívül: https://github.com/ivanovp/pifs

Jó pár percig nézegettem a System Workbench honlapját, de nem látom mit is lehet ott letölteni.
Ez a cucc most egy csomag, vagy egy részletes leírás hogy kellene a toolokat telepíteni, beállítani?
Milyen Linux disztrót preferálnak?
Az about épp nem sokat mond arról mit is és hogyan kellene feltelepíteni.

* Én egy indián vagyok. Minden indián hazudik.

Először regisztrálj az www.openstm32.org -on, majd lépj be és utána lesz letölthető a System Workbench for STM32. Van Windows, Mac OS X, Linux telepítő is. Én Arch Linux-szal próbáltam, biztosan megy Debian/Ubuntu alatt is. Csak arra kell figyelni, hogy néhány tool 32 bites könyvtárakat igényel.

( martonmiklos v | 2018. 01. 14., v – 13:49 )

Ha nem akarsz szívni a fejlesztői környezet összerakásával akkor:
http://www.openstm32.org/System%2BWorkbench%2Bfor%2BSTM32

Ez egy Eclipse + OpenOCD + GDB + gcc alapú fejlesztőkörnyezet.
Kell hozzá egy talicska RAM, meg megszokni az Eclipse hülyeségeit de alapvetően ootb működik.

Illetve érdemes az Atollicon rajta tartani a szemed, mert megvette az ST.

Még csak "puhatolózom". Az Atollic már régen a célkeresztemben van, de a windows (bármelyik taszít).
Anno egy akkoriban neves ma már egy másik cég C/C++ fejlesztői környezete ahogy "nőtt" a projekt egyszerre csak összeomlott, piszok nagy csalódás és pofára esés volt.
A Linuxon (általában) jól elkülönülnek a dolgok. Nem tudom (még) hogy a System Workbench pl. milyen formátumban tárolja a munkával kapcsolatos konfigurációs adatokat, de számítok rá hogy olvasható, értelmezhető, még ha nem is olyan egyszerű (a feladatok is jóval bonyolultabbak, összetettebbek).

* Én egy indián vagyok. Minden indián hazudik.

A 8.x óta már Linuxra is van Atollic. Ez is Eclipse alapú, de fejlesztettek hozzá sok dolgot embedded fejlesztéshez, főleg debug vonalon. Az STM CubeMX is integrálható bele pluginnal. A gcc-t amit belecsomagolnak azt ők rakják össze az általuk összeválogatott/saját patch készletükkel, továbbá szoktak a gcc projektbe vissza is küldeni patcheket.

( tovis v | 2018. 01. 14., v – 14:57 )

Először is köszönöm a sok jó tanácsot és leírást!
Sejtettem, hogy az Eclipse -nél lyukadunk ki, de végül is az Atmel Studiónál csak gyorsabb lehet :)
A gcc tud közbülső assembly -t listázni?
(sokat dolgoztam vele de nem így és nem azt ahol ez jól jön)

OFF: Az Eclipse -ben nekem az az ijesztő, hogy túl sok az infó és kevés a munkaterület - legalábbis amit eddig láttam belőle.

A gyári szerkezetekkel az az egyik bajom, hogy ráépülnek a gyári librarykra ami nem mindig optimális. Arra jó, hogy kipróbáljam az óco kínai cuccaimat - pl. ST-LINK V2 (kétféle is van, egy olyasmi mint egy pendrive - STM8 -al égetésre használom - és egy olyan ami pont úgy néz ki mint a gyári darab)
Még amikor nagyon az Atmel felé tendáltam, beszereztem egy ATATMEL-ICE nevű gyári cuccot, AVR -el jól működik. (Ráadásul "PCB only" verziót vettem és csak amikor megérkezett szúrtam ki hogy a csatlakozók 1,27" pitch - jól benéztem, de megoldottam) Viszont az Atmel Stúdió kiábrándítóan lassú. Szerintetek támogatja az ATATMEL-ICE JTAG -at openodc?

Ami az első célterületet illeti, az a STM32F030F4 ami össz-vissz 4K RAM - ez még k'va kevés egy rtos -hoz, az majd egy következő lépés lehet - viszont ez "könnyű" átmenetnek tűnik a 8 bites világból a 32 bitbe :)

* Én egy indián vagyok. Minden indián hazudik.

A gcc tud közbülső assembly -t listázni?

Biztosan tud, én a SystemWorkbench debuggerét szoktam nézegetni.
A kínai STLink ugyanazt tudja mint a gyári (a gyárni nem leválasztott).
A JTAGICE3 ha jól emlékszem CMSIS kompatibilis, tehát elvben az openocd támogatja, de az Stlink klónok nem túl lassúak (egy ICD3-hoz képest.)
Illetve pár arc kiszúrta az STM32CubeProgrammer releaseben az Stlink/V3 támogatást, szóval valami új is lesz nemsoká, ami csak nem lesz lassabb.

Azért nem értettem - ha akarod bogaras vagyok, valamiért a kezdetektől fogva nem kedvelem a PIC filozófiát, architektúrát.
El kell ismerni, hogy rengeteg érdekes/értékes dolgot csináltak vele. Az én bogaram, hogy mellőzöm ezt a vonalat.

* Én egy indián vagyok. Minden indián hazudik. 

arm-none-eabi-gcc -S {my_source.c}

-S Stop after the stage of compilation proper; do not assemble. The output is in
the form of an assembler code file for each non-assembler input file specified.
By default, the assembler file name for a source file is made by replacing the
suffix ‘.c’, ‘.i’, etc., with ‘.s’.
Input files that don’t require compilation are ignored.
Vagy object fáljból objdump -s 

arm-none-eabi-objdump -S {my_object.o}

ami össz-vissz 4K RAM
Felejtsd el. Ezek az ARM procik nem a nyomorgásról szólnak. Lehet - és néha kell is - optimalizálni/túrni assembly -ben, de ez ritka eset, zömében nem erről szól az élet. Érdemes a fejlesztést a család legcombosabb darabján kezdeni, és amikor készen van, optimalizálni kisebb darabra a sorozatgyártás előtt. No ez az ami a hobbi bütykölésből kimarad.
A könnyű átmenet csalóka lehet, hiszen a fő különbség a HW bonyolultsága, amit nem spórolsz meg. Olyasmire gondolok, pl. mint egy sima kimenet használatba vétele/felprogramozása. 8 biten simán ráírsz egy címre és kész. ARM chippekben jellemzően engedélyezned kell 1-2 periféria órajelét, kivenned 1-2 perifériát reset -ből, (eddig a pontig a GPIO -hoz még nem is nyultál), alternate functiont allítani, majd jöhet a GPIO: az adott kimenetet output -ra állítani, pull-up konfigurálás, drive strength konfigurálás. Ha mindez megvolt, már mehet is. Az hogy csak 4K RAM -od van, ezen nem egyszerűsít.
Szóval válts egy nagyobb chipre és játssz a 32 bites világ igazi kihívásával ami a "system integration". Úgy kell tudni különböző termékeket egybe gyúrni, hogy egyiket sincs időd részletekbe menően megismerni. Pl: ha kell egy file-system (pl SD kártyához), kell TCP/IP illetve USB, csak egy "hétköznapi" connectivity -vel rendelkező eszközöd van, viszont mind a 3 terület kimerítő ismerete egyenként is "éveket" igényel.
Itt nem az az igazi kihívás, hogy azt a pár részt ami idő/teljesítmény kritikus összekalapáld, hanem hogy megfelelő félépítést találj a szoftvernek. Azért itt még elég alacsony az eszköz teljesítménye, hogy a túlzott absztrakció tarthatatlan lassulást okozzon, és túl nagy a kód komplexitás ahhoz, hogy absztrakció illetve megfelelő struktúra nélkül kezelhető legyen. Kérdés, mi a megfelelő egyensúly?
Tengernyi időt lehet elverni a hardver marhaságaira is. A dokumentáció általában silány, a referencia implementáció pedig pont az érdekes részeket mellőzi.

Amikor board -ot választasz arra is gondolni kell mire akarod használni. A discovery board -ok olcsók, de nincs rajtuk semmilyen periféria kiépítve, így ha bármit kezdeni akarsz vele "elő kell venne a pákát". Ha egy drágább board -ot választasz, kapsz rendes tápegységet (az egyéb áramköreidet (érzékelők, stb..) tudod tápolni róla, lesz rendes soros portod, etherneted, USB -d, stb. Nagyon sok időt lehet evvel spórolni. Nézd meg a https://www.mikroe.com/ vagy az https://www.olimex.com/ cuccait. Az Olimex board -ok open hardware -ek, azaz kapsz hozzá kapcsirajzot, nyáktervet, mindent. Mondjuk nem is 3-4000 az áruk.

Köszönöm! Látszik, hogy nem vagy kispályás az ARM vonalon.
Pont az általad elmondottak miatt, illetve a Raspberry miatt ódzkodtam tőlük - sok energiát kell fektetni a perifériák felpiszkálásához. Tulajdonképpen inkább nevezném ezeket az eszközöket micro alaplapnak, közelebb állnak a Soic cuccokhoz.
Vegyünk csak egy IP kamerát - van hozzá interfésze (már a 407 -ben ott csücsül) van ethernet phy - vagyis mőgé kell tenni a tcp/ip stacket. Ilyeneket már nemigen fejleszt az ember hobbiból. "Third party library" -k kellenek és azok munkáját kell összehangolni.
Természetesen lehet felső szintről kezdeni és nem beleveszni a GPIO rejtelmeibe.
OFF: Szeretek pákát venni a kezembe. Az első keresetemből egy Weller pákát vettem anno. Az első PC -met még magam élesztettem a Műszertechnika által eladott selejt XT alaplapokból (a HOMELAB III. nem is merem említeni). De ez már igencsak történelem.
Ha most ebből kéne megélnem én is a te utadat járnám, de hobbira az ember nem költ túl sokat, annál több időt próbál rászánni.

* Én egy indián vagyok. Minden indián hazudik.

Kiindulásnak az STM32CubeMX egész jól használható.
Gyakorlatilag egy alap konfigurációt össze lehet benne rakni órajel-beállításokkal, Ethernet-képességgel (LwIP integrációval), USB-kezeléssel akár.

Tehát a 3rd-party libek összehangolásába már elég sok energiát belefektettek, és egész használható eszközöket ad.

Ráadásul Java program lévén az STM32CubeMX működik szépen Debian alatt, a már említett System Workbench-el egyetemben.
Ebay-en lehet venni pl. STM32F103C8T6, ill. STM32F407VET6 kontrollerrel boardokat olcsón, próbálgatni egész jól lehet vele.
Végleges rendszerhez meg készülhet saját áramkör és jöhet a forrasztópáka. :)

Átfutottam mit ír róla azt ST tényleg egyszerűsítheti a munkát.
De az ilyen kisebb cuccoknál mint STM32F030F (20 pin ;) először megpróbálom magam. Az első "megközelítés" amúgy is arról szól, hogy mennyire lehet a 8 bites mcu -kat az egyszerűbb Arm -kal kiváltani.
Az eddig elhangzottakból az jön le, hogy leginkább a combosabb verziókat használják, ami egyben azt is jelenti, hogy a compiler terjengős, kódszátyár - kit érdekel ha egy-két kilobájttal hosszabb, nem fél a rekurziótól.
Az én elképzeléseim a "sok kicsi sokra megy" elvre alapulnának. Azaz több kisebb mcu mint egy nagy, így egy-egy mcu nagyon jól definiált feladatot lát el, nem lesz olyan mint egy falba épített PC, ami a karácsonyfa kivetítéstől a galaktikus szimulációig mindenre alkalmas.
(pl. láttam olyat, hogy SPI to UART chip - tulajdonképpen ezekkel a kis mcu -kal és némi szoftverrel ez mosolyogva megvalósítható. A TCP/IP már nehezebb tészta, de sok olcsó chip van erre is.)

* Én egy indián vagyok. Minden indián hazudik.

A TCP/IP-re ajanlom a W5500-ast. Sima binaris SPI, 80mhz-n, igy lenyegeben 100mbit-et majdnem teljesen ki lehet tolni vele ha epp arra van szukseg. 2-3 euroba kerul az ice maga, de van breakout-board verzio is (igaz, az joval dragabb). Es ez tenyleg annyira egyszeruen kezelheto hogy egy ATmega328P-s bootloadere(!) is elviszi, azaz 2k-4k flash-ba is belefer minden.

A sok kis MCU-val meg alapvetően az a probléma, hogy mindegyiket külön kell felprogramozni.
Ha a gyártást más végzi, nem feltétlen fog örülni neki... :)

Nekem vannak olyan kódjaim, amik STM32-n készültek, de AVR-en is fut belőlük.
Igaz, ez célom is volt vele.

A hálózati (TCP/IP) kommunikáció, USB, komolyabb kijelző, komolyabb flash IC (meg egyéb, járulékos dolgok) kezelése azért STM32-vel egyszerűbb...
...meg azért más feladatokra való igazán. :)

Azért a Raspy más kategória. A Cortex-M -ek az MCU -k, jellemzően egy maggal, MMU és bonyolult CACHE nélkül. Egyel nagyobb kategória a Cortex-R (realtime processors), és csak utána jön a Cotrex-A (application processors). Minnél feljebb megyünk, annál inkább igaz, "kézzel", hobbi szinten nem nagyon lehet az igényeknek megfelelő FW -t írni. Ezek inkább speciális PC -k, Linux -szal, és fejleszteni is így kell rájuk.
Manapság mindent hajlamosak beágyazott rendszernek nevezni, és ebből kifolyólag mindent beágyazott szoftvernek hívnak. Ma inkább hardware-level programozásról, meg application-level programozásról beszélhetünk. A Cortex-M jellemzően az előbbi kategóriába esik, A Cortex-A jellemzően a másodikba (senki nem mondja nekem, hogy az apache2 beágyazott-szoftver csak mert Rpi-n fut). Az első kategória inkább villamosmérnök meló, a második inkább programozók dolga.

Visszatérve a te esetedre el kell ismernem, hogy ha csak az a cél, hogy 8 bites alkalmazásokat kiválts ARM -mal, akkor egy kis ARM ideális választás. Ezekhez NYÁK -ot csinálni is egyszerűbb (pl: LPC800 -ból van DIP8 tokozású).
Azért a nagyobb Cortex-M -ektől sem kell megijedni. Egy ChibiOS vagy mbed sok alap funkciót megold, lehet építeni a tetejére.

És végezetül megemlíteném a CrossWorks -őt. Ugyan nem ingyenes (150 USD a Personal licence. Emberhez kötött, több gépen is használhatod.) de nagyon jól összekalapált rendszer a Rowley Crossworks (http://www.rowley.co.uk/arm/). Ha nem a tool -okkal akarsz szívni, és van egy kis pénzed érdemes elgondolkodni rajta.

Amit az RPI -ről írsz azzal egyet kell értenem. Van egy open hardware aminek closed a software!? Nincs egy korrekt, gyors ADC/DAC megoldás. A leggyorsabb interfésze egy USB -n kezelt USB combo. Viszont rengeteg dolog készen áll, néhány scriptum és bármi működik rajta ami egy átlagos PC -n. Kimagasló ár/érték arányú SBC, rajta az alapvető beágyazott perifériákkal mint SPI, I2C és akár 1wire. Nagyon vagány :)
Nem ijedek meg semmitől, csak ugye az idő amíg átrágod magad az alapokon. Ráadásul sosem tudod, hogy most a te szoftvereddel vagy a környezeteddel van a baj.
A Rowley Crossworks jól hangzik, de még nem értem meg rá. (Ráadásul míg szinte az összes Atmel Arm chipet támogatja a "hivatalos" ATATMEL-ICE JTAG -et nem. Pedig ők is érzik, hogy ha ilyen lassú a "hivatalos" IDE akkor van mit kereskedni)
Ja és van Linux verzió, gcc toolchain :)

* Én egy indián vagyok. Minden indián hazudik.

Olyasmire gondolok, pl. mint egy sima kimenet használatba vétele/felprogramozása. 8 biten simán ráírsz egy címre és kész. ARM chippekben jellemzően engedélyezned kell 1-2 periféria órajelét, kivenned 1-2 perifériát reset -ből, (eddig a pontig a GPIO -hoz még nem is nyultál), alternate functiont allítani, majd jöhet a GPIO: az adott kimenetet output -ra állítani, pull-up konfigurálás, drive strength konfigurálás. Ha mindez megvolt, már mehet is.
Igen, ez teljesen jogos hogy 4K RAM azert nem annyira sok - ellenben hogy precizebben fogalmazzunk, ez az altalad emlegetett problemakor a flash-fogyasztast noveli, nem a RAM-fogyasztast. Szoval inkabb azt mondanam, hogy amire mondjuk AVR-nel eleg volt ~8k flash, arra itten lehet hogy mar ~32k is kellhet, tobbekkozott ilyesmik miatt is.

Én itt nem is annyira a memória igényre gondoltam, hanem a feladat bonyolultságára. 8 biten ~2 utasítás ARM -on ~4-6 függvényhívás, függvényenként 2-4 C forrás sor, fene tudja hány utasítás. Meg ugye dokumentációból is sokkal többet kell megérteni, hiszen több perifériának kell együtt működnie egy ilyen egyszerű feladathoz is.
Szóval ha ARM -ozik az ember, inkább a komplexitás növekedése a kihívás, ebből erednek a fő különbségek a 8 bithez képest.

Abban teljesen igazad van, hogy amit írtan nem a RAM igényt fogja növelni. Az is igaz, hogy egy kis ARM -ban több a RAM és a FLASH mint egy kis 8 bitesben.

Még nem tanulmányoztam az Arm utasítás készletét, de az AVR RISC az STM8 nem igazán (vagy már így ki sem írják, bár a szorzás és osztás mint művelet nem a risc mcu -k jellemzője).
A risc alapból kódszátyár, már assembly szinten, amit az MCS51 mcu -kon egy utasítással elintéztem az itt akár négy is lehet, ezért jobb rájuk C programokat írni és nem nézegetni mi is az assembly -ben.
OFF: STM8S UART interruptal és cirkuláris bufferrel az SDCC kódhoz képest harmad annyira összenyomtam - az SDCC nem használja ki az indirekt, indexelt címzést. Bocs lehet már írtam ezt valahol - szenilis is vagyok :(

* Én egy indián vagyok. Minden indián hazudik.

( balagesz | 2018. 01. 14., v – 21:37 )

Ez egy érdekes fórumtopik, sub. :)

(Lassan nekem is lesz egy ARM-os projektem, itt meg van egy rakás információ / link segítségnek.)

( Caro | 2018. 01. 14., v – 22:18 )

Fura, hogy még senki nem javasolta a nucleókat.
Nagyon jó és olcsó kis fejlesztőpanelek, integrált ST-LINK-el, amit természetesen akár külön is lehet használni.

Nézegettem már őket - a Farnell -t nagyon becsülöm, jól áraz és pontosan szállít. De az eBay -en a "márkás" cuccok rögtön kétszer annyiba kerülnek, mint az egyébként tök ugyanaz "minimal development board" de nincs rá integrált ST-LINK.
De igen, ha hivatalosan kellene azt venném. Tökéletesen megfelel a célnak.

* Én egy indián vagyok. Minden indián hazudik.

( ptiszai v | 2018. 01. 16., k – 12:15 )

STM32f779I-EVAL: http://www.st.com/en/evaluation-tools/stm32f779i-eval.html
Farnell.hu-: 100e Ft
Win 10 alatt fejlesztek:
-VS2015
-VisualGDB: https://visualgdb.com/ 1 évre 90 dollár
-SEGGER JTAG: https://www.segger.com/products/debug-probes/j-link/models/j-link-pro/
-CubeMX : http://www.st.com/en/development-tools/stm32cubemx.html
- bootloader munkám, stm32f7 eredeti átírva, kiegészítve:https://github.com/ptiszai/STM32f779I-EVAL_IAP_bootloader

( tovis v | 2018. 01. 18., cs – 17:13 )

Megjelent az Atolic 9.0 STM32 prof nincs korlátozás. Kicsit nehezen tudtam letölteni. Már csak egy kis idő kell hogy kipróbáljam - valami "blink" kaliberű példa kellene, mondjuk STM32F103C8 -ra az van fiókban.

* Én egy indián vagyok. Minden indián hazudik.

( Foltos | 2018. 01. 19., p – 10:22 )

Most futottam bele ebbe: https://gnu-mcu-eclipse.github.io/
Ez egy free Eclipse "csomag" mikrokontrolleres fejlesztésre kihegyezve. Az alap Eclipse + néhány témába vágó plugin.
Sosem használtam, csak az utókor számára jegyezném fel.

( tovis v | 2019. 03. 19., k – 21:31 )

Most már nagyon megérett a helyzet, hogy beletanuljak.
Az Atollic 9.3.0 gond nélkül felment a Debian 9.8 -ra.
A SysTick/main.c lefordult mint a villám - ck. 1 perc!?
Tanulási célra vettem két STM32F0 DISCO panelt - amilyen a szerencsém kettőből egy hibás, már az STlink -sem felismerhető, nem tudja kiolvasni az ID -ket az USB alrendszer :(
Tudtok ehhez valami jó leírást? - én csak videókat találok sajnos a beszélt angol nem az erősségem.

* Én egy indián vagyok. Minden indián hazudik.

( tovis v | 2019. 03. 20., sze – 23:18 )

Belenéztem miket is generált le a TrueSTUDIO.
Van egy inicializációs startup_stm32f0xx.s ami egy assembly fájl?
Klassz, tehát lehet assembly kódot is írni valahogy.
Van egy Libraries mappa benne CMSIS és rengeteg .h file.
Illetve van egy STM32F0xx_StdPeriph_Driver mappa amiben (ha jól látok) minden perifériához van valami driver féle init és sok mindenféle beállítás.
HUH! Most ezzel mit kellene csinálni?
Valahol, valaki óva intett ezektől a driverektől - mindenképpen át kell tanulmányozni mik is ezek és mit tartalmaznak - lehet használható?
hg2ecz adott nekünk egy pár egyszerű LED villogtató programot - igazi bare metal semmi ide csak a compiler, töltő program és make.
Megpróbáltam "buildelni" villanás és semmi - hosszas keresgélés után találtam egy console -t amiben látszik, hogy a make -ben használt arm-none-eabi-gcc compájlert hiányolja - amit nem telepítettem, gondoltam majd az Atollic.
Megnéztem az Atollic bin/ dolgait van ott bőven gcc de ilyen pont nincs.
Kicsit elbizonytalanodtam.
Próbálkozás képpen csináltam egy "c" projectet is.
Itt már a CMSIS mellet az STM32F0xx_HAL_Driver mappa jelenik meg de üresen?
Csak egy .txt fájl van hogy ide adjam a HAL drivereket. Honnan is?
Eddig ez nagyon zavaros és eléggé szokatlan. Gond hogy az Eclips -et sem ismerem :( Lehet a HAL driverek helyett itt is használhatnám az StdPeriph_Driver -ket?
Vagy hagyjam az egészet ... és induljak a kályhától - compiler, letörltő és persze make, illetve a CMSIS érdekes lehet, úgy tűnik ott van az összes definíció?
Mi a véleményetek, melyik vonalon induljak neki?

* Én egy indián vagyok. Minden indián hazudik.

Telepíts egy STM32CubeMX-et és a Truestudio vagy a System Workbench IDE-t, mindkettő Eclipse alapú (a Truestudio jobban össze van rakva).

Itt egy Blinky példa végigvezetve: https://www.youtube.com/watch?v=6RqUkFIeN6w

Az STM32CubeMX le fogja generálni a komplett Eclipse projectet, beinclude-olja a szükséges CMSIS és HAL library-kat, ad egy működő template main.c-t ami bekonfigurálja a használt perifériákat.

Az stdperiph helyett a HAL és/vagy LL (low level) library-k használatát javasolják és támogatják.

Ha nem ismeri az STM32cubemx az általad használt devboard-ot (pl. kínai Blue pill), akkor elég a mikrovezérlőt kiválasztani és beállítani milyen órajelről megy.

Ha nincs a devboard-on programozó akkor a külső St-Link GND, SWDIO, SWCLK-t kell összekötni programozáshoz és debuggoláshoz.

Kösz! Sajnos most épp a fejlesztő gépemet próbálom helyre rakni - valami szétesett a particionálás tájékán.
Aztán elkezdem kibogozni mi a CMSIS, StdPeriph_Driver és a HAL.
Amit biztos nem akarok az az objektum orientált programozás - plain C (a szívem csücske).
A Bluepill -t még nem akartam elővenni, egyenlőre a jóval kisebb STM32F030F4 - Cortex M0 picurka. De ahhoz kaptam némi segítséget, így megnéztem. Van egy origin ST STM32F0 DISCO board -om, ahhoz már megtaláltam a a példa projekteket.

* Én egy indián vagyok. Minden indián hazudik.

Amit biztos nem akarok az az objektum orientált programozás - plain C (a szívem csücske).

A CubeMX csak C projektet tud generálni (sajnos).

Ja a HAL mellett egy ideje van LL (Low Level API is)

Itt tudod kiválasztani melyik perifériához melyik drivert használja (HAL/LL):
https://imgur.com/a/hZOf9IQ

Tudom sokan esküsznek a C++ -ra illetve ipari szabvány.
De engem jobban izgat az assembly - tudom furcsa, de eddig mindig azt találtam, hogy a compilernél sokkal tömörebb kódot tudtam vele írni.
A screen shot a CubeMX -ből való?
Egyébként a TrueSTUDIO is tud C, C++ projektet generálni mcu -ra vagy board -ra szabva.

* Én egy indián vagyok. Minden indián hazudik.

Azt gondolom egyszerűbb elindulni valamiből ami működik, mivel elég sok buktatóba belefut az ember ha szeretne elkezdeni az STM Cortex-ekkel foglalkozni. A gyártó is alapos munkát végzett az alapvető információk rengeteg különböző 100-1000 oldalas dokumentációban elrejtésével, az stdperiph-hal-LL API káosszal, látszik hogy nem hobbisták a célközönség.

A példaprojektekkel a következő problémák lehetnek:
* nem tudod megnyitni IDE-ben, mert nincs eclipse project hozzá. Project nélkül neked kell kitalálni az összes include path-t, compiler beállítást, stb.
* ha sikerült megnyitni, nem fordul le valamiért:
* nem a te board-odra/mcu-dra készült, adaptálni kellene
* másik négy library-ra hivatkozik, amiket nem talál
* soha nem próbálták lefordítani nemwindowson, ezért a kód tele van szórva backslash path vagy random-case filenevekkel

A HAL-nál nem nehéz tömörebb/gyorsabb C kódot írni, az assembly-vel nem hiszem túl sok sikered lesz.

Ha mégis a nehezített pályát szereted: https://github.com/WestfW/Minimal-ARM/tree/master/Blink

Kösz a linket! Nem egészen ilyesmire gondoltam, de első lépéseknek tanulságos lehet. Az assembly kódolást nem ilyen dolgokra szoktam használni, hanem mondjuk amolyan HAL szerű rutinokhoz (pl. UART kezelés fifo -val vagy cirkuláris bufferrel, vagy ami a leglátványosabb az egyszerű tick számlálóval). Egyébként is ami az STM8 -nál megfogott az az extended műveleti készlet, roppant rafinált címzési módokkal, a bitmanipulációt nagyon utálom C -ben írni.
Egyelőre még mindig úgy érzem, hogy nagy a káosz (főleg a fejemben). A cél hogy a puszta kódoláson és működőképes programokon kívül lehetőség legyen pl. debuggolásra.
Arra is hajlandó vagyok hogy mások által készített HAL -t használjak de akkor azt át kell rágnom, meg kell értenem a kódot, ehhez meg egy-két dolgot érdemes megírni.
Ráadásul az eclipse IDE is eléggé idegen - nem találom benne a dolgokat - tény a visual C -vel is így kezdődött.

* Én egy indián vagyok. Minden indián hazudik.

Amikor ilyen 8 bites mikrovezérlős téma van (általában AVR vagy PIC), akkor mindig van valaki aki beírja, hogy "miért nem használsz 32 bites ARM-et inkább?". Mindegyikkel ennyi szívás van? Hogy még egy alap példát lefordítani is kínszenvedés?

Teljes IDE-ket kell használni, mert anélkül senki sem érti, hogy mi történik? És mindegyik inkompatibilis mindegyik másikkal? Vagy valamit nagyon félreértek, és valójában egy 5 soros makefile is működne?

Mert ha így van, akkor egyáltalán nem bánom, hogy egyelőre a bites ATMegáknál maradtam :-)

apt install avr-gcc avrdude és minden megvan ami a programozáshoz kell. 5 soros makefile felviszi a vezérlőre, debuggolni meg ott a szkóp :-)

Szívás, mert nagy az ecosystem, sok partnercég fejleszt megoldásokat

* több különböző fejlesztőkörnyezet van (15+ az ST szerint)
* több különböző fordító (Keil, GCC, IAR, ...)
* több különböző library, inkompatibilis API-al (stdperiph, LL, HAL, opencm3)
* több különböző JTAG/SWD debugger
* a dokumentáció több ezer oldal

Természetesen ha ezekben eligazodsz és tudod mire van szükséged akkor itt is megy az apt-get install gcc-arm-none-eabi stlink stm32flash ...

Debugger nélkül is lehet kódot flashelni, ha tudod hogy kell a beépített bootloadert előcsalni és használni.

STM32-knél a bootloadert a BOOT0 láb 3,3V-ra húzásával + RESET lehet előcsalni (BOOT1 marad GND-n). Ekkor az stm32flash progi szépen beletölti a szoftvert. Ehhez USB-UART átalakító kell, vagy például a Raspberry Pi UART-ja.
A BOOT0-t vissza GND-re és RESET aztán fut a kódod. Lásd közelmúltban mellékelt teljes példámat.

Ami még kellemes: a System Memory-ban levő Boot Loadert nem tudod kinyírni, tehát bátran lehet vele próbálkozni.

Három STLink V2.0 van a kezem ügyében. (Olyan olcsó hogy lehet érdemes fejlesztő panelknek használni.) Akkor miért használsz USB - UART (TTL) átalakítót az égetéshez?
Az stm32flash nem ismeri az STLink V2.0 -át? A manuáljában szó sem esik róla :O

* Én egy indián vagyok. Minden indián hazudik.

stm32flash:

"Open source cross platform flash program for the STM32 ARM microcontrollers using the built-in ST serial bootloader over UART or I2C"

Kifejezetten az on-chip ROM boot-loader -rel beszél, JTAG -hez semmi koze.
JTAG -en talán az OpenOCD tud ilyet: https://jacobmossberg.se/posts/2017/01/10/using-openocd-flash-arm-corte….

( Caro | 2019. 03. 23., szo – 15:28 )

Ha már kinőtted a 8 bitet, akkor érdemes feljebb lépni.
De igen, ha nem akarsz IDE-t, a toolchain-t össze kell rakni, ami azért erősen bonyolultabb az avr-gcc-nél meg az xc8-nál.
Én makefile-t használnok, neten lehet azért erre is példákat találni. Az mindig lefordul.
De azért a 32 bites kontrollerhez nem érdemes ugyanazzal a megközelítéssel menni, mint a 8 biteshez.

[szerk] Ez válasz akart lenni a felette lévőre :)

Nem nőttem ki semmit. Vallom hogy a feladat szabja meg mit használunk. Az AVR és a PIC RISC az '51 és az STM8 bővített utasításkészlettel rendelkezik, szeretem.
Sajnos az ARM is RISC, viszont rendkívül sokrétű egészen a DSP szintekig. Kihagyhatatlan.
Viszont elég zűrös vele elindulni. Az STM8 és az AVR esetében fogtam a Geany -t és makefile. Viszont van debug lehetőség!
Ki kell próbálni.

* Én egy indián vagyok. Minden indián hazudik.

toolchain-t össze kell rakni, ami azért erősen bonyolultabb az avr-gcc-nél meg az xc8-nál.
Ez ketsegtelen, de leginkabb azert mert kismillio fele ARM-es MCU kering a vilagban, nem csak annyi mint amennyi AVR-es. Ellenben szerintem nem haszontalan ezeket is megismerni:

  • Vagy akkor, mikor mar eleve nagyon jol ismersz mar egy jol osszerakott ARM-es toolchain-t hogy ki tudod belole siliabizalni hogy mi kell neked konretan egy adott hardverhez/projekthez.
  • Vagy akkor, mikor mar az AVR (vagy altalaban egy ilyen beagyazott mikrokontroller) lelkivilagat, memoria-felosztasat, stb annyira jol ismered hogy azalapjan (plusz kis netes keresgeles alapjan) tudsz mar extrapolalni hogy navajh' egy adott ARM eseten ez hogy is lehet.

A toolchain meg nagyjabol ezekbol a komponensekbol es egyeb input file-okbol all:

  • fordito (arm-none-eabi-gcc)
  • linker (arm-none-eabi-ld)
  • object extraction (arm-none-eabi-objcopy)
  • libc (newlib: /usr/lib/arm-none-eabi/newlib/armv6-m/libc.a, usr/lib/arm-none-eabi/newlib/armv6-m/libc_nano.a
  • libgcc (arm-none-eabi-gcc: /usr/lib/gcc/arm-none-eabi/5.4.1/armv6-m/libgcc.a)
  • linker script (pl. stm32f407.ld)
  • _start (/usr/lib/arm-none-eabi/newlib/armv6-m/crt0.o, vagy teljesen sajat)
  • vector table

Na, es ezutobbi harom osszevadaszasa az, amihez mar elegge ismerni kell az architekturat. A linker script-ben az MCU-fuggo resz az ARM architekturaja miatt joesetben csak a ROM meg a RAM szekciokat tartalmazza, de a vector table-ban mar hivatkozni kell a linker script-ben definialt szimbolumokra is (pl a stack pointer kezdeti ertekere). A _start pedig akar lehet maga a main() is, de a bss meg az (i)data elokeszites is ide tartozik.

Egyelore ezeket mar nagyjabol sikerult hellyel-kozzel erthetoen osszelonom. Ami meg hatra van, az az hogy a heap kezelese: azaz hogy a libc_nano-ben levo malloc() tudja hogy a RAM melyik teruleten tud allokalni. De ez ugye annyira nem fontos mert azert annyira nem szeretek veszelyesen elni hogy MCU + malloc() kombinaciot hasznaljak :) De tanulsagosnak tanulsagos lesz, az biztos.

Effele "alulrol epitkezos" kiindulasnak ez a kis leiras is nagyon jo.

apal! Szépen összefoglaltad és a leírást/prezentációt is köszönöm. Ha végképp kiábrándulok a TrueStudio -ból jöhet ez a megoldás.
Az összelövéssel az a gond, hogy ahhoz kellenek valamiféle "próba" programok minimum az embedded világ "hello world" -je a blink. Viszont így félő hogy amikor kicsit tovább lépsz ezen újabb hibákat találsz a tol chain -ben.

* Én egy indián vagyok. Minden indián hazudik.

Ha teljesen osszeall a kep akkor szivesen csinalok egy komplett(ebb) leirast a dologrol. Tenyleg par finom reszletet kell ismerni csak, a tobbi az stock csomagbol (openocd, binutils-arm-none-eabi, gcc-arm-none-eabi, libnewlib-arm-none-eabi) megoldhato. Ami ugye annyit tesz van lesz egy projekt-konyvtarad, kis fileokkal, `make && make upload` es akkor hajra.

toolchain-t össze kell rakni, ami azért erősen bonyolultabb az avr-gcc-nél meg az xc8-nál.

FYI: Ha az Atollicot letöltöd felrak mindent: gross compilert, IDE-t, debuggert.

Míg a Microchipnél letöltöd az MPLABX-et majd a fordítót (XC8) neked kell beszerezni.

Ezt én nem erősen nehezebbnek, hanem könnyebbnek ítélem meg.

Valóban egyszerűnek tűnik, a TRUEStudio viszont rögtön oda bagarintja a CMSIS -t, a HAL (az LL -el még nem találkoztam), az STDperipherla libraryt. Cserébe nem igazán ismerem ki rajta magam :(
Pl. várnék valami "burn" menüpontot, ahol letölthetném a programomat - nem találom. Mikor új projektet kezdek, akkor ki tudom választani pl. az mcu típusát, később nem találom ezt a beállítást.
Arról már nem is beszélve, hogy a szerkesztő "mező" nem éri el a képernyő kétharmadát - mintha egy kulcslyukon át kellene programozni.
A TrueStudio leírások zömében videók - nem lehet lapozni, nem lehet keresni (hacsak nem csinálsz magadnak egy indexet) és a beszéd értelmezésem sem túl jó.
Tudom, bennem van a hiba, küzdök.

* Én egy indián vagyok. Minden indián hazudik.

Pl. várnék valami "burn" menüpontot, ahol letölthetném a programomat - nem találom.

Nyomd meg az F11 gombot.

Mikor új projektet kezdek, akkor ki tudom választani pl. az mcu típusát, később nem találom ezt a beállítást.

Projekten jobbeger -> Properties majd itt tudodz MCU-t átállítani:
https://imgur.com/a/Kp9aMyn

Eclipse alapú. Az osztások mozgathatóak. Az editor "fülén" duplát kattintva teljes képernyőbe megy, és minden mást eltűntet. Az összes mező külön becsukható, átrendezhető, külön ablakba mozgatható. Tehát teljesen testreszabható, hogy mit látsz a képernyődön, mi mekkora.

Gondolom Eclipse alapú pluginek is telepíthetőek, amikkel további funkcionalitást lehet hozzáadni az editorhoz.

Eléggé rugalmas platform az Eclipse.

A library-ket a CubeMX bagarintja, ha igényled. A Truestudio egy IDE, elindulhatsz üres lappal is, meg assemblyben is kódolhatsz.

Programozás: Run -> Debug (itt jó esetben legyárt egy működő debug konfigurációt, megtalálja az ST-Linket, SWD-n rákötött mcu-t) - ez feltölti a lefordított firmware-t, berak egy breakpointot a kód legelejére, átkapcsol Debug view-ra.

Futtatás: Run/Resume

Na ez az az infó amire vártam! Én úgy értelmezem, hogy akár bare metall programozással is indulhatok :)

A lényeg, hogy nem kell első lépésként rögtön kitanulni a CMSIS, a Standard Peripheral Library, HAL, LL és végül mondjuk az RTOS.
Biztos el kell azokat is sajátítani, de egy mcu legyen mcu.

A PC programozást sem a Win API -val kezdtem.

* Én egy indián vagyok. Minden indián hazudik.

A CMSIS tobb modulbol all.
Egy resze a Cortex-M core periferiainak a drivere (NVIC, SYSTICK). Megirhatod nullarol, de felesleges.
Masik resze egy "cimpiler abstraction layer". Egy kupac Cortex-M specifikus intrinsic -et rejt hordozhato makrok es fuggvenyek moge. Kidobhatod, ujra irhatod, de felesleges.
A harmadik resze egyes periferiakra ad szabvany driver API -t. Ezt a legtobb chip vendor nem hasznalja, es amugy is eleg szar. Ezt erdemes kidobni.

Az SPL, HAL es egyebek a chip gyarto cuccai. Ezek referencia kodok, nem valok termekbe. Mankonak valo a sajat cuccok megirasahoz. Persze rengeteg hobbi es profi projektben egy-az egyben hasznaljak oket, mert ingye van, es a kovetelmenyek lehetove teszik. Pl egy debug UART csatornat kb mindegy mivel hajtasz.
Azert is erdemes elszakadni toluk, mert ebben van a vendor lock-in, itt kifejezetten szempont, hogy ne legyen hordozhato. Soknak a licence is tiltja, hogy mas gyarto csippjevel hasznald.

"bare metal"
Manapsag ez mar kb. mindent jelent. Pl. linuxos korokben a userland nelkuli fejlesztest is hallotam mar igy megnevezni (Linux kernel + egyetlen sajat applikacio, vagy kernel + kernelen belul sajat kod).
Cortex-M teruleten az RTOS nem egy Linux szeru gazdag kornyezet. Inkabb csak az utemezot kell alatta erteni, illetve a processzek szinkronizalasahoz szukseges alapveto funkciokat (mutex, semafor, event, stb...). Azaz nincs benne faljrendszer, halozati tamogatas, meg ilyesmi. Van egy ket ingyenes csomag ahol ezek is megvannak (pl: mbed-os, Zephyr, Chibi-os, a FreeRTOS bizonyos valtozata), de jellemzoen ezeket neked kell megirni, vagy integralni. Pont ez a terulet legnagyobb kihivasa, hogy tudni kell viszonylag nagy kulso modulokat megerteni es integralni. Pl. TCP/IP stacket senki sem all neki sajatot irni. Egyreszt sok munka, masreszt sok olyan mukodes van ami nem egyertelmu a szabvanyban, es a "piac" a windows + linux paros mukodeset koveti. Ilyenekbol jonnek ki az olyan csodak, amikor minden jo, de az eszkozod megsem mindig jut at a routeren, mert az valamit feltetelezett amit te nem ugy csinalsz. Erdemeseb berantani pl egy LWIP -t mer igy egy csomo masok alltal lekodolt tudast hasznalni tudsz. Illetve kerdezni is van kitol.

1 szo mint 100: persze faragj sajat drivereket, es probald ki az assembly -t, de ennek a teruletnek a szoftver integracio, illetve az optimalizalas megfelelo celpontjanak megkeresese a sava-borsa. Ez a kulcsa a time to market es a megfelelo mukodes kozotti egyensuly megtalalasanak.

Persze hobbiban mindent szabad, egyszer erdemes sajat driver stacket, sajat utemezot, sajat mindenmast irni, mert sokat lehet belolle tanulni. Azert a bonyolultabb dolgokat (sajat TCP stack) nem biztos hogy ertelmes vegigcsinalni. LWIP ala megirni egy EMAC drivert sem egyszeru, es majdnem mindent meg kell hozza tanulni ami TCP fejleszteshez kell. Gondolok itt a TCP/IP eleg alapos ismeretere, halozat debuggolasra (tcpdump, wireshark), teljesitmeny meresre, memory leak keresere, esatobbi. Pl mar azon is jokat lehet filozofalni, hogy az EMAC driver a legregebbi vagy a legujabb csomagot dobja el, ha nincs memoria tobb csomagnak.

A Cortex-M -ek eleg izmosak a bonyolult szoftverekhez, de nem eleg izmosak az esz nelkuli pazarlashoz. Megtalalni az egyensulyt az igazi muveszet, ismerni ennek eszkozeit pedig eladhato tudas.

Jól belementél. Amiért a "bare metal" programozást akarom először kipróbálni pont az, hogy kiismerjem magam az architektúrán. Az ARM olyan mintha egy alaplapot kellene programozni - van benne órajel, interrupt kezelő és DMA. Így foglalnám össze a legalapvetőbb különbségeket a jól ismert 8 bites mcu -hoz képest.
Az előre gyártott freeware kódokkal folyton ez a probléma - hol vannak a határai, mennyire is használható valójában. Azért nagy gáz ha lekódolod amit kell és ott sül ki hogy nem bírja hazárdos, nehezen kinyomozható hibákat okoz.
A keretprogramok oda csapják ezeket a kódokat.
Viszont, nem akarom feltalálni a spanyol viaszt, és az összes vezérlő regisztert ledefiniálni - lusta vagyok és nem tartom ésszerűnek, ha van kész és mindenki azt használja - azaz más is ki igazodhat rajta.
A ip stacktől egyelőre olyan messze vagyok mint Makótol Jeruzsálem. Valószínűleg ott kellhet igazából az RTOS mint ütemező és valami kész, akár fizetős ipstack kód. (Így is annyi ilyen van már és én is láttam hogy milyen bugosak tudnak lenni)
Ami az izomzatot illeti, kicsit zavarba ejtő, hogy mekkora flash áll rendelkezésre, míg mondjuk az M0 legfeljebb 8k RAM, valljuk meg ez minden csak nem izmos. Minden periféria igényel puffereket, mérési eredmények tárolása további feldolgozáshoz stb. és akkor azért a stack -re is vigyázni kell nestelt interrupt és egyebek.
Apropó, több helyen olvasom hogy az interruptot nem ISR szolgálja ki hanem callback? Vagyis kilép a védett üzemmódból és mókol valahol?

* Én egy indián vagyok. Minden indián hazudik.

"Apropó, több helyen olvasom hogy az interruptot nem ISR szolgálja ki hanem callback? Vagyis kilép a védett üzemmódból és mókol valahol?"
Ez egy dizajn dontes. Egyreszt nem szeretjuk a hosszu megszakitasokat, mert nehezen kontrollalhato keslelteteseket okoznak, ugyanakkor nem szeretjuk kesleltetve kiszolgalni a periferiat, mert ez lassit, illetve adatvesztest okozhat (pl UART elhagyja a karaktereket). Hogy melyik periferiahoz mi lesz a megfelelo egyensuly a 2 kozott, az alkalmazas es periferia fuggo. Pl. hogy az UART -nal maradjunk, ha az UART -nak van FIFO -ja, vagy DMA -val hasznalod, akkor jobb ha az ISR -bol csak kuldesz egy event -et az UART kiszolgalo processnek, es az majd feldolgozza az esemenyt amikor a rendszer raer. Ha az UART -nak sem FIFO-ja, sem DMA -ja nincs, akkor az ISR leteheti a karaktert egy FIFO -ba (ez gyors) majd az ISR event -et kuld, es a process majd feldolgozza a FIFO tartalmat kesobb. Ha az UART -ot figyelo processz idokritikus dolgot csinal (real-time protokoll -t futtat, es idoben kell tudjon valaszolni), akkor a feldolgozast vegzo teljes allapotgep futhat ISR kontextusban.

A "call-back" mint programozasi technika a fentiekkel nem feltetlenul van összefüggésben, amennyiben call-back hivhato ISR contextusbol, illetve azon kivulrol is. A call-back inkabb egyfajta "runtime dependency injection", vagy runtime szoftverkonfiguracios megoldas. Ez inkabb arrol szol, hogy a hivo kod csak a hivott kod elvart viselkedeset illetve az interfeszt hatarozza meg, de a konkret mukodest az imlementaciora bizza.

Köszönöm. Viszont ha "call back" -re bízom az interrupt kezelést, akkor simán előfordulhat, hogy az ISR újra meghívja, mielőtt az előző hívás lefut - ehhez minimum reentrans kód kell. Akkor tudom elképzelni, ha eleve reentrans a teljes kód (gondolom az RTOS vagy más multitask ütemezők ezt amúgy is is elvárják). Ráadásul, ha megszalad az interrupt forrás az felzabálhatja a stack -et, nem árthat arra is figyelni hanyadik instance fut.

* Én egy indián vagyok. Minden indián hazudik.

Ha jól értelmezem ez nem reentrans, hanem egy eseményfeldolgozón futnak sorban a callback-ek. De nem ismerem a rendszert, csak a parent komment alapján mondom.

Minden ilyen rendszerben biztosítani kell, hogy a következő input előtt lekezeljük az előzőt, különben egymásra fognak szaladni, betelik a puffer, stb. Ha esetleg nem tudjuk mindig garantálni, csak átlagban, még az is jó lehet. A lényeg, hogy a puffer, amibe az ISR pakol, elég nagy legyen.

Az egyetlen hátránya a keretrendszernek csak az lehet, hogy esetleg nem tudjuk pontosan, hogy mi mennyi idő, meg hogy történnek-e pluszban adminisztratív taszkok is, mert azokkal is számolni kell. De ezeket a kérdéseket fokozatosan megoldja, ha megismerjük a rendszer részleteit.

Amikor a core megkezdi az IRQ kiszolgálását, az NVIC felhúzza az aktuális IRQ prioritási szintet a kiszolgált IRQ szintjére. Ez minden további IRQ -t kimaszkol, aminek a prioritása nem magasabb. Azaz amíg az IRQ handlered vissza nem tér, ugyan ez az IRQ újra nem "csaphat be".
Sot, az NVIC -nek van egy regisztere ami megmondja, hogy az IRQ prioritás bitek közül hány bit a lesz "preempt priority és hány "sub priority". (Lásd itt, illetve itt). IRQ handlert csak a magasabb "preemt priority" -vel rendelkező interrupt szakíthat meg.

Ezt a könyvet mindenképpen zsákold be, ha a Cortex-M -ek lelki világa érdekel (Kb. Cortex-M biblia).

Én úgy értelmezem, hogy a call back kilép az ISR -ből, újra engedélyezve az adott IRQ -t, vagyis a call back már védtelen, akár újra hívható anélkül hogy az előző kört befejezte volna. Pont akkor kellhet használni, ha pl. alacsonyabb prioritású interruptoknak is érvényre kel jutni.
A könyv tippet köszönöm, csak az SE van meg, de gondolom olyan nagy különbség nincs, ami egy kezdőnek számítana.

* Én egy indián vagyok. Minden indián hazudik.

"Én úgy értelmezem, hogy a call back kilép az ISR -böl..."
Cortex-M -re elég jól definiált, hogyan működik az interrupt exception, illetve, hogy mit jelent az interrupt context. Kicsit berozsdásodtam, de ha jól emlékszem az LR -be kerül speciális érték, és amikor az utolsó return ezt betölti a PC -be, akkor fog a HW kilépni IRQ context -böl.
Tehát alap esetben bármit amit ISR handlerbol hívsz, IRQ context -ben hajtasz végre, így értelem szerűen a call-back -eket is.

Még ha RTOS -od van, akkor is a normál menet az, hogy ISR contex -bol event -et küldesz, ami a fogadó processz ready állapotba teszi. Amikor az IRQ handler -ed kilep, az OS végignézi a ready állapotú processzeket, és a legmagasabb prioritásúra fog visszatérni. Ahhoz, hogy ez működjön "meghamisítja" a stack -re mentett exception frame -et. De ez a működés implementáció specifikus, mert pl. vannak olyan OS -sek amik erőltetik a time sliceing -et, azaz mielőtt egy processz időszelete lejárna, semmiképpen sincs processz váltás.
Az OSE (mondjuk ARM -on sosem használtam) definiál pl interrupt processz típust. Itt mindenképpen az az elvárás, hogy az IRQ handler csak minimális munkát végez, és a speciálisan kezelt interrupt processzt fogja az ütemező elindítani. De ez is kb a fentiekkel megegyező eljárás, csak az OSE sajátosan kezeli ezeket, és saját nevezéktant vezet be emiatt.

Tulajdonképpen arról van szó, hogy van az IRQ handler, ami IRQ exeption context -ben fut. Ezt indítja el a hardware válaszul az IRQ kérésre, és ez a kód fogja tudni megszakítani a processz kontextusban futó kódot. Azaz "ezek ellen" kell(het) re-entrancy védelmet biztosítani, azaz ezek bármilyen normál kódot megszakíthatnak. Van továbbá az IRQ service rutin, ami futhat akar sima processz kontextusban is. Ez végzi a munka nehezét. Az, hogy a 2 -őt egyben implementálod, vagy a 2. -at IRQ contextben futtatva call-back -kent hívod, vagy a processz contexttel komunikalva hajtod valahogy végre a te döntésed (design decision).

Pl1: ha nincs RTOS, és csak egy nagy main loop -pal "ütemezel", akkor az IRQ handler beállít egy globális változót, hogy jelezze az eseményt. A main loop amikor oda ér, ellenőrzi a változót, és ha az állapota eseményt mutat, lefuttatja az IRQ service rutin-t.
Pl2: a kis latency követelmény az adott perifériánál, ezért vagy az IRQ handler egyben az IRQ service is, vagy az IRQ handler call-back -ként hívja az IRQ service rutint.
Pl3: van RTOS, így az IRQ handler call-back -et hiv. A call back RTOS fugvennyel eventet/messaget kuld a processznek ami majd megfelelo utemezes mellett lefuttatja az IRQ service rutint.

A példákból érezhető, hogy a call-back mint megoldás csak a modularizációt/konfigurálhatóságot szolgálja.

Ez most jól jött, kösz! Most néztem meg (az M0) utasítás készketét és rájöttem, hogy "hiányzik" belőle a tradicionális call és ret és reti (ami az interruptból visszatérés). Nagyon komoly eltérés azokhoz az eszközökhöz képest amit eddig programoztam. Ezt most emésztenem kell. Pl. mi lesz az "reti" atomiságával? Hogy valósítható meg az alapvető test-and-set utasítás (vagy az mégis van). Mivel több utasításból áll, ezeket akár is megszakíthatja egy másik interrupt?!
Hűha! Mielőtt jobban belemelegednénk a interrupt kiszolgálásba át kell tanulmányoznom az utasítás készletet.

* Én egy indián vagyok. Minden indián hazudik.

Yep. LR -t hívó felelőssége menteni. Ha érdekelnek a részletek errefelé olvasgass: https://developer.arm.com/architectures/system-architectures/software-s… (téged első sorban az ABI érdekelhet.)

Amúgy a Joseph Yiu féle könyvben minden benne van amit tudni szeretnél (illetve amit érdemes) ;)

A HW viszont tud. Maga a HW fogja lementeni a regisztereket a stack -re (r0-r3,lr,pc,xpsr). (Az LR -be spéci érték kerül.) Ezután meghívja az exception handlert. Ez mint bármely sima C függvény menti amit még használ (pl LR). Elvégzi a dolgát, majd visszatölti az EXEC_RETURN magic value -t a PC -be. Itt a core tudja, hogy véget ért az IRQ és az eredeti context -et visszatölti a stack -rol.
Tőszavakban ilyesmi :)

Az ARM ABI szerint az r0-r3 mentése a hívó feladata. Az (r4-12,lr,pc,xpsr) mentése pedig a hívott függvényé. Szóval exception esetén pont azt látja a meghívott handler, mintha sima függvényként hívnák, és úgy is kell visszatérjen. Ezért írják, hogy támogatja a core a C -t.

( whitehawk v | 2019. 03. 24., v – 12:11 )

Én gentoo alatt raktam fel crossdevvel a cross-arm-none-eabi toolchaint (gcc, gdb, binutils, newlib).
Felraktam Geany-t IDE-nek, egy baj volt, hogy a debugger pluginba bele van drótozva a gdb elérése, így a cross-os gdb-t nem tudtam használni, és akkor nem foglalkoztam ezzel, de szerintem megoldható lenne..
st-link van még, az ment, és valamiért az OpenOCD-hez nem jutottam el.
Régen a sourcery G++-t használtam, de az most már csak macerás vadászat után található meg mióta a Mentor megvette.

Software is like sex, it's better with a penguin. :D (r)(tm)(c) آكوش

Nem hiszem hogy érdemes lenne visszalépni az ilyen eszközökhöz, ha van "gyári" jól működő megoldás. Ráadásul nem a toolchaint akarom fejleszteni, debuggolni.
A kérdés inkább az, hogy az Atollic TruStudio -t tudom e használni a bare metal -hoz lehető legközelebbi módon - hall, ll, stdperipheral library nélkül, csak a belső regiszter definíciókat szeretném használni - közös nyelv.

* Én egy indián vagyok. Minden indián hazudik.

( tovis v | 2019. 05. 21., k – 11:15 )

Nincs két éve, hogy az ST "megvette" az Atollic TrueStudio -ját, már azt látom, hogy nem támogatott a jövőbeni fejlesztésekhez!?
Mi lehet a helyes megközelítés? Iparilag mit használnak?

* Én egy indián vagyok. Minden indián hazudik.

Szerintem "csak" átalakul.
Múltkor a System Workbench-nél néztem, hogy NRND státuszba került, azóta visszatették Active-ba.

Az a helyzet, hogy készítenek egy STM32CubeIDE nevű megoldást, ami, ha jól értelmeztem, leváltaná a TrueSTUDIO-t és a System Workbench-et is.
Ill. konkrétan a TrueSTUDIO-nál látom is ezt leírva.

Mivel TrueSTUDIO-t nem használtam, így nem tudom megmondani, ez milyen változást jelent és jobb vagy rosszabb lesz a helyzet így.

Én feltettem ezt az STM32CubeIDE-t (Linux alá), de még nem álltam át rá, mert szimpla "programozás" pontot nem találtam meg, bár "debug" módban feltölötte a kódot és át is váltott debug nézetre, továbbá STM32CubeMX-szel generált projektet első körben importáláskor lenullázta (csak a .ioc maradt, minden mást törölt), bár második próbálkozásra betöltötte és működött... szóval néhány hete még bugosnak láttam, de valamiért a System Workbench-et is visszatették Active-ra NRND-ből.

Egyébként nem tűnik annyira rossznak, ha egyszer rendesen elkészül... lehet benne fordítót is választani, meg programozó/debuggert (OpenOCD mellett ST-Link is választható), de sokat nem nyomkodtam. A programozót frissíteni akarta, de nem tette tönkre vele. :)
Ezt az STM32CubeMX felületet integrálták bele.

Alapvetően úgy gondoltam, hogy a magasabb szintű perifériákhoz ad némi előnyt, meg az eltérő procik között könnyebb átjárást.
...végül is lehet, bár USB Device-hoz más library-t használtam, mert a HAL-ossal nem lehet több endpoint-ot létrehozni.

Most egy H7-esen szeretnék Ethernet kapcsolatot, ami F4-en jól működött, itt viszont valamiért változott az alacsonyabb szintű kezelés - ami alapvetően nem lenne baj, de most jobban függ a keretrendszer által favorizált LAN8742A PHY-től (annak speciális regisztereit kérdezi), viszont a saját boardra nem ez került... regiszterkezelés szintjén helyretettem, kommunikál is vele, de még nem tudom, mi hiányzik neki, ami miatt az MCU fizikailag nem is küld még adatot a PHY felé (ez a fentitől független dolog).
Valószínűleg órajel / RAM kezelés (itt azért másképpen működik) / DMA beállítás még nincs rendben.
Még úgy tűnik, ezen a procin kiforratlan a dolog, habár egy ideje piacon van már.

Mentségükre szóljon, hogy azért eléggé más a H7-es MCU a többi szériához képest, meg talán még nem is túlságosan elterjedt...

Az alap problémát az okozta, hogy az Ethernet periféria belső DMA vezérlője nem éri el a "DTCM" memóriáját a procinak, így azt a területet, amit az Ethernet DMA-jának el kell érni, a "D1" vagy "D2" SRAM-ba kell definiálni.
Így már láttam kifelé menő adatot is a PHY felé, ekkor már csak a "SCB_CleanInvalidateDCache();"-t kellett meghívni, hogy érvénytelenítse a cache-t a DMA műveletek előtt.

Most elindult, DHCP-n kap IP-t és pingelhető - tehát megy a kommunikáció.

A szívást inkább a proci eltérő működése / felépítése okozta, ilyen szinten azért ezt mint "HAL" nehezen kezelheti, mert nem feltétlen tudja, mit akarsz csinálni.
Konfiguráció terén a "Cube" azért adhatna nagyobb segítséget ezen a téren...

A PHY kezelése más kérdés, azt módosítanom kellett... nem vagyok biztos benne, lehet, korábban a DP83848-at használták - most megnyitottam egy új projektet F4-hez és ennél a procinál konkrétan kiválasztható, hogy DP83848 vagy LAN8742A "címet" használjon.
Amiatt raktam az új boardra is a DP83848-at, mert korábban jól működött, és ezt azért elég nagy biztonsággal be lehet kézzel is forrasztani - a LAN8742A SQFN tokozása ebből a szempontból kevésbé szimpatikus.

Az újabb működés egyébként logikusabban (szebben) van megírva, bár lehetne kevésbé specifikus.

Amennyire ismerem, az ARM processzoroknak "csak" a magja azonos, ez jó a compiler -nek de nem sokat segít a HAL (BIOS) típusú kódoknak. A PC -ben a BIOS -t rendre inkább kerülgetik, vagy nem is használják miután a rendszer be bootol.
Itt sem lesz másként, azaz mindig lesz aki saját hw vezérlő, irq kiszolgáló rutinokat ír.
Sajnos specifikusan, az ethernet phy -hez nem tudok hozzátenni. Nincs vele tapasztalatom. Fizikai átviteli szinten nagyon vonzó (akár 10G, galvanikus leválasztással és akár 100m átviteli szakaszokkal, mindezt akár zavart ipari környezetben is, az egyik legolcsóbb kábel féleség az UTP) viszont protokoll szinten eléggé bonyolult, azaz gyengébb egy chipes eszközökkel nem használható - nevetséges módon (nekem úgy tűnik) a WiFi könnyebben elérhető, egyszerűbben megvalósítható.

* Én egy indián vagyok. Minden indián hazudik.

Teljesen saját, alacsony szintű dolgokat nem érdemes írni rá, mert nehezen fogsz tudni másik MCU-ra átállni.
IRQ kiszolgáló rutinok nyilván lesznek, meg ehhez tartozó beállítások, időzítések, egyéb megfontolások...

...azért a kódok nagy részét igyekszem úgy megírni, hogy STM32, AVR, vagy akár MSP430-on is használható legyen.

Az, hogy az LwIP-t hogyan éleszted fel, persze más kérdés... de, ha működik, akkor a magasabb szintű réteg már használhatja.

Relatíve gyenge kontrolleren nem igazán lesz 10G egy darabig. :)
...bár ez az ARM azért gyengének nem nevezhető.
Amúgy WiFi modulból valóban van olcsón olyan eszköz, ami egyszerűen működésre bírható - bár ez nem azt jelenti, hogy maga a megoldás is egyszerű (rádió és egyebek), de az interfész, amiről eléred, az valóban az. Pl. ESP ismeri a WPA2-t, titkosításokat, csatlakozik a hálózatra, rajt van a TCP/IP stack, gyakorlatilag csak használni kell - a bonyolultabb részét már megoldották.
Ethernetből ennyire egyszerű megoldásról nem tudok, a W5100/W5200/W5500 közelít hozzá.

Absztrakció terén kíváncsi leszek, hogy a Rust nyelvű implementációban mennyire fogják tudni kényelmessé tenni a mikrovezérlő programozást. Jelenleg itt tartanak:
https://docs.rs/stm32f7/

És egy tavalyi cikk:
https://medium.com/coinmonks/coding-the-stm32-blue-pill-with-rust-and-v…

( tovis v | 2019. 05. 23., cs – 16:37 )

Mielőtt teljesen beszűkül a szöveg.
Egyelőre nem is cél a 10G, sőt 10M is beérem. Viszont az említett Wiznet chipek elég szépen fogyasztanak, ill. több helyen írják hogy lefullad/elakad.
A C még mindig az a nyelv ami legelőször megvan és a leghatékonyabban kihasználja a cpu/mcu lehetőségeit minden léptékben. Mindig vannak próbálkozások, még olyannal is találkoztam, hogy visszanyúltak a forth -ig. De előbb utóbb mind elakad, megragad egy készletnél. Jó játék.

* Én egy indián vagyok. Minden indián hazudik.

Kínai SIM800;SIM900 és társainak szintén nem árt ha szoftverből van mód tápciklusra mert a sima reset nem mindig segít rajta (ezek jó táppal is szarok). Telit (pl. xL865), Sierra Wireless, Quectel ezek jók. Viszont kellően jó táp nélkül mindegyik GSM modul elmegy az erdőbe, instabil lesz. A legtöbb gyártó mellékel táp referencia tervet is (pl. itt 25. oldalon, stb.). A probléma az, hogy egy GSM modul nem annyit fogyaszt adáskor mint ami a táblázatban van. 2G-nél adáskor 4.6ms-enként egy-egy 577us széles 2A(!) (de akár 3A is lehet) fogyasztási csúcsai vannak a GSM moduloknak (2W adóteljesítményhez), ezeknek az átlaga a kb. 400-450mA ami a táblázatban van megadva fogyasztásként. "Gyors" táp kell (kapcsolóüzemű esetén >=500KHz) nagy pufferkondival (>= 1000uF illetve Siemens modulnál >=4700uF).

Igen, no meg ennek a sávszélességnek is akkor van értelme, ha ki is tudja használni az ember.

Egyébként az Ethernet úgy általánosságban viszonylag sok energiát igényel.
Nem tudom, mennyire jók amúgy ezek a Wiznet-es megoldások, mindenesetre egyszerűbb kontrollerhez is illeszthetőek.

Igen, a C az a nyelv, ami ad egyfajta univerzalitást, de viszonylag közel lehet kerülni a hardverhez, viszont bonyolult működés is könnyen megvalósítható vele.
Ha olyan nyelven kezd el programozni az ember, amit kevesen használnak, akkor sokkal inkább magára van utalva és kisebb eséllyel írják meg alá a támogatást az adott hardverhez - a legrosszabb dolog másokra várni, hogy az adott funkció / hardver támogatott legyen, mialatt az ember az érdemi működést szeretné megvalósítani rá.
Ilyen szempontból jó, ha a gyártó ad hozzá egyfajta támogatást, mert van mibe kapaszkodni, ha valami nem működik - egy alternatív nyelvnél azért ez problémás.

Egyébként az Ethernet úgy általánosságban viszonylag sok energiát igényel.
+1

Nem tudom, mennyire jók amúgy ezek a Wiznet-es megoldások, mindenesetre egyszerűbb kontrollerhez is illeszthetőek.
Teljesen jo tapasztalataim vannak a W5500-es rendszerekkel. Felprogramozod, mukodik. Stresszteszteket is birja. Az RPi-hez illesztett konfig is teljesen jol mukodik (akkor nem tcp/ip hanem sima raw uzemben), bar a kernelmodulon par aprosagot kellett reszelni (leginkabb hogy warning nelkul leforduljon mert a fejlesztese leallt jonehany verzioval ezelott).

( tovis v | 2019. 05. 25., szo – 19:40 )

Csak "pásztáztam" a webet. Valaki dolgozott már az ARM DS-5 Community Edition -el?

* Én egy indián vagyok. Minden indián hazudik.

( nyuszis | 2019. 09. 16., h – 16:17 )

Szia!
Olvastam a témaindító hozzászólást és mivel én is hasonló cipőben járok, kértem egy felhasználót, hogy beírhassak. Látom, hogy sok hozzászólás érkezett, de én is leírom az én válaszom, mert bennem is ugyanaz az igény fogalmazódott meg mint amit írsz, hogy "bare metal" módon tudjam a legkisebb TSOP20 tokozású STM32F030f4p6 programozni.
Az alapok ugyanazok nálam is mint amit írtál, az STM8-al és több más mikrovezérlővel is hobbi szinten foglalkozom, ugyanúgy szeretem felhasználni az STM8S103F3P6 mikrovezérlőt, mert nagyon olcsó, könnyen programozható és beforrasztani sem nehéz, jelenleg a forrasztóállomásomat is ez az MCU vezérli. Én ugyan windowst használok, mert a munkám azt követeli meg, de SDCC és GCC-vel fordítok, ezek linux alatt is rendelkezésre állnak.

Mellékelek egy példakódot és egy fordítókörnyezetet, lent a DRIVE-os link.

A fordításhoz kell egy ARM-GCC, én most letöltöttem a legújabbat, ezt használom gcc-arm-none-eabi-8-2019-q3-update , ezen felül kellhet még az STM32F0xx standard peripherals library (STSW-STM32048 névre rákeresve letölthető), ha esetleg érdekelnek a példaprogramok. Az SPL sajnos elég nagy kódot generál, sokszor nem is fér el 16K-ban.
A példakód egy blink a PIN10/PA4-en, de beállítok egy USART-ot is, hogy lehessen követni hol tart, PIN8/PA2/TX, PIN9/PA3/RX. 


RCC->AHBENR |= RCC_AHBENR_GPIOAEN;
GPIOA->MODER |= 0b0100000000U; // Output PA4
GPIOA->ODR |= (1U << 4 );
...
GPIOA->ODR &= ~(1U << 4 );

https://drive.google.com/open?id=1nWA94UvQdlUt3QFqwri27BFQnk2KBinq

https://i.ibb.co/bb684pR/stm32f030-bare-metal.jpg

Nagyon köszönöm!
Egyelőre még mindig az elmélkedésnél tartok :(
Úgy látom ezzel tovább léphetek.

OFF: Mindig jön valami égetőbb, ráadásul a év melegebb időszakában minden hétvégémet a vidéki házamban töltök, ahol mindig van tennivaló. Így ez is addig tolódik mire okafogyottá válik. De ezt még nem adtam fel.

* Én egy indián vagyok. Minden indián hazudik.

Egyébként ha van nálad Raspberry vagy egyéb SBC, akkor ott minden rendelkezésre áll a repóból a fordításhoz (apt install gcc-arm-none-eabi és lesz arm-none-eabi-gcc, *-ld, *-objcopy) és a letöltéshez jó, hiszen a 3,3V-os UART pont ideális. Letöltő program szintén a repóban van: apt install stm32flash

A boot ROM-ot nem tudod tönkretenni, a boot0 H és boot1 L szintű akkor lép RESET után a boot módba, amikoris stm32flash progival beletöltheted az UART-jának RX, TX lábain kereszül a kódot.

Köszönöm! A Pi kicsit lassú az ízlésemnek.
Az asztali gép (akár egy öreg Core2Duo) sokkal hatékonyabb tud lenni.
Ráadásul van ST-Link V2 gyári "kinézetű" és a kis klón + van egy klón JLink V8 (még ki sem próbáltam sajnos).

* Én egy indián vagyok. Minden indián hazudik.

A gyári dolgokkal az szokott a baj lenni, hogy gyári szoftver is kell hozzájuk, ami nem nyílt forrású, és másik kernelhez való, csak Windowsos, stb. Egyszerűbb lehet egy 3.3V-os USB-UART átalakító, ezeket a Linux általában OOB soros portként felismeri és csak működnek. Párszáz forintért be lehet szerezni és egy csomó egyéb célra is jó.

Lehet így is. De szeretnék debuggolni is.

OFF: 1988 tájékán kezdtem foglalkozni előbb Z80, majd MCS-51 programozással.
Isteni lett volna egy debugger. Persze, megoldottam a soros porttal vagy egy GPIO -val, Ráadásul, nem kell EPROM -ot sütögetni/napoztatni (vagy EPROM emulátort készíteni). De ah van lehetőség miért ne használjuk?

* Én egy indián vagyok. Minden indián hazudik.

Ez is off+off.
1985 tájékán olyan 8085 debuggert használtam, amely az utasítások egyes fázisain is meg tudott állni. Meg olyan logikai analizátort, amiben disassembler is volt. (MP/M, 8db Z80, 128++ csatorna)

A második téma: Ledvillogtató program, igaz nem STM, hanem PIC. 

PROCESSOR p18f24k50
#include <P18F24K50.INC>
   cblock  0
   Counter
   endc
 
   org   0
   banksel  __BANK_15
   assume  __BANK_15
   clrf  ANSELA 
   bcf   TRISA,TRISA2,a
loop   
   dcfsnz  Counter, a
   btg   PORTA,RA2,a
   org   .1000
   goto  loop
   END

Ha már szoftver loop, akkor adjuk meg a módját!
Igaz, magamtól soha nem írok ilyet.
Csak belenéztem a thread elején a kódba. :(

C-ben mennyivel szebb: 


#include <18F24K50.h>

void main() {
    unsigned char counter = 0;

    ANSELA = 0;
    TRISA.2 = 0;

    while (1) {
        while (--counter);
        PORTA.2 = !PORTA.2;
    }
}

(Ezzel a fordítóval wine segítségével parancssorból tudod lefordítani, -a kapcsoló olvasható asm kimenetet is csinál.)

Látom a poént nem fogtad: Ha már szoftver loop, akkor adjuk meg a módját!
Igaz pongyolán fogalmaztam, mert szoftver loopokkal megvalósított delay a helyes kifejezés.

Az apró nüánsznyi különbség (ahogy Hofi mondaná), hogy a C program periódusideje 6,164 ms, míg az asm periódusideje pedig 1,022 s. Szerintem a 6ms nem annyira látható. ;)

Sajnos a program sajtóhibás, itt van helyesen (a POTB6 és 7-en van az analizátor): 

PROCESSOR p18f24k50
#include <P18F24K50.INC>
   cblock  0
   Counter
   endc
 
   org   0
   banksel  __BANK_15
   assume  __BANK_15
   clrf  ANSELB, b
   bcf   TRISB,7,a
loop   
   dcfsnz  Counter, f, a
   btg  PORTB, 7, a
   org   .1000
   goto  loop
   END

A C fordító királyság! Bár néha btg néha meg két ugrás a végeredmény - aminek azért van oka is, de inkább riasztó, mint hasznos.

A szoftver loop helyett a fiatalságot a timer és interrupt használatára kéne tanítani. Még akkor is, ha csak ledet kell villogtatni.
Hasonlít ez ahhoz, amikor egy FIR filtert linkeltél. Ott is csak a magas órajel volt kihasználva, pedig dsPIC-en futott. Én már csak a tanulás miatt kipróbáltam volna a dsp lehetőségeit.

Anno letöltöttem az Atollic fejlesztőt - akkor ez volt az irány.
De már pár hónap múlva nem támogatott lett.
Most úgy látom az ST honlapján, hogy az STM32Cube a támogatott, ami hat program csomagból áll. Mondjuk gyanús, hogy nem épp a bare metal programozást támogatja.

* Én egy indián vagyok. Minden indián hazudik.

Erről beszéltünk korábban ebben a topicban.

Az Atollic és AC6 + STM32CubeMX-et is szeretnék összehozni az STM32CubeIDE-ben.
Én úgy láttam, ez alapvetően hasonlít arra a megoldásra, amit használok, de jobban szeretnék integrálni bele ez az STM32Cube rendszerüket...
Nem pár hónapon belül nem lett támogatott, hanem két régi termékvonalat éppen most gyúrnak össze.

Egy GUI-t is adó lehetőség a PlatformIO, ami egész messze jutott az elmúlt években. Itt még keretrendszert is lehet választani ami STM32 esetén lehet Arduino, SPL, CMSIS, STM32Cube, annyi csak, hogy még nincs a támogatott hardverek között a kis STM32F030f4p6, de a BluePill-el ( STM32F103C8T6 ) lehet próbálkozni. ARM-GCC-t használ a fordításhoz és a környezetet maga tölti le és konfigolja.
Csak ki kell választani a board-ot és a környezetet, ha debug is kell akkor az plusz egy sor az INI-ben és működik az olcsó kínai STLINK-V2 -vel is (a fémházas USB stickszerűvel $2).
De ha nem lenyitogatja a választókat az ember akkor az INI-ben ennyi elég: 


[env:genericSTM32F103C8]
platform = ststm32
board = genericSTM32F103C8
framework = cmsis

upload_protocol = stlink
debug_tool = stlink

Jelenleg két editorral működik, én most az Atom-ot használtam.

CSak gyorsan rákerestem és ránéztem. A screen jól néz ki - ha jól értelmezem, C kód mellett a debugger assembly trace. (Lassan úgy érzem az életem rövid lesz, hogy minden ilyet kipróbáljak).
Az Arduino pont nem érdekel - jó ha valami demot gyorsan akarsz összerakni, de valójában komolytalannak érzem (hacsak nem fejlődött amióta ránéztem). A másik ami zavar az IOT értem, hogy mainapság minden az interneten forog, de ennek is megvannak a korlátai.
Pl. a télen gyorsan rittyentenem kellett egy kazán reteszt (ha megy a páraelszívó nem mehet a cirkó) végül STM8S103F3P6 -al és 433MHz -en oldottam meg. No debug, no internet de működik.

* Én egy indián vagyok. Minden indián hazudik.

azért mertem ezt javasolni, mert nem kell hozzá sok idő és nulla konfigolást igényel ha az említett bluepill-t akarod használni. Az ATOM editor feltelepítése után csak az editor saját Package Manager-ében kell kikeresni a platformio-ide csomagot és rányomni az installra.

Mint írtam az STM32F030f4p6 nincs benne sajnos, de érdekelt és utánaolvastam, hogyan lehet saját board-ot telepíteni és egy json fájlt kellett csak létrehoznom.
Persze ezután a fordítás még nem ment, de mivel a python scons library-t használja a buildhez ki tudtam keresni mi a baja, mert forrás szinten fent vannak a platformok fordításához használt scriptek. Ha jól emlékszem nem is kellett kódot átírnom, csak onnan néztem ki milyen struktúrában kell létrehoznom új könyvtárakat és belemásolnom a kellő fájlokat, hogy ne száljon el exception-nel. Ha lesz egy kis időm utánanézek és lehet beküldöm a változtatást git-be mert opensource.

Az STM8S103F3P6 nekem is kedvencem. Mint írtam az hajtja a forrasztóállomásom, de az időzíti a levilágítóm, szabályozza a bluetooth-os erősítőm és vezérli a DMX RGB ledszalagomat, stb.
Régóta fontolgattam, hogy áttérek erre a Coretex-M0 lapkára, lehet most meg is kaptam a kellő lökést, hogy ezeknek most utánanéztem. Az Atom-ban tetszik, hogy jól működik az autocompletion, hajlamos vagyok az elgépelésre

Pl. a télen gyorsan rittyentenem kellett egy kazán reteszt (ha megy a páraelszívó nem mehet a cirkó) végül STM8S103F3P6 -al és 433MHz -en oldottam meg. No debug, no internet de működik.
Régen rádióamatőr probléma volt, hogy nem kapcsolhatsz addig anódfeszültséget, amíg nincs fűtőfeszültség. A logika bonyolultsága hasonló, de akkor még meg tudták oldani két kapcsolóval. ;)
A cirkó és páraelszívó reteszelése nem minden esetben elegendő. Lehet egy kis szél és/vagy egy nyitott ablak vagy ajtó és megfordulhat a huzat. Úgy mondtuk: "belefúj a szél a kályába".

Szerencsémre ezt már tudja a cirkó. 12 éve üzemel megesett nagy szélben nem gyulladt be.
A retesztelést pedig úgy oldottam meg, hogy a cirkó ionizációs érzékelőjének van egy LED -je azt figyelem és befért a cirkó lehajtható fedele mögé - megbízhatóan működik. (A páraelszívót egy a Conrad -tól vásárolt rádiós relé működteti - nem mintha nem tudnék ilyesmit rittyenteni, de erre mindenféle minősítés megvan, nem vegzálhatnak, hogy mondjuk tűzveszélyes).

* Én egy indián vagyok. Minden indián hazudik.

Bocs, ezt nem értem :(
(Nyócker, több mint száz éves építésű társasházról van szó. Nem, az ablakok, ajtók nem zárnak légmentesen. 11 éven át enélkül is jól működött, a fürdőszobában van egy lélegeztető szelep/rés, 80nm és 360cm belmagasság, jó nagy légtér, nehéz megfulladni)

* Én egy indián vagyok. Minden indián hazudik.

( tovis v | 2019. 09. 29., v – 11:55 )

Új hús?
STM32-BASE
A célkitűzések hasonlóak mint amit én szeretnék.
Viszont hobbi projektként írja le és nem világos meddig jut el.
A git repoban nincs publikus tag? Furcsa (nekem).

* Én egy indián vagyok. Minden indián hazudik.

( tovis v | 2020. 01. 05., v – 20:45 )

"Új" alternatíva. STM32CubeIDE. Ingyenesen letölthető (regisztráció kell) . Eclipse alapú
Debian 10 -re szó nélkül felment.
Látszólag minden rendben - kicsit lassú de ez valószínűleg az antik C2D proci és alaplap, mindössze 4G DDR2 800MHz RAM (viszont a 120G SSD sokat lendít rajta, még kipróbálok egy SATA3 vezérlőt).
Némi botladozás után megtaláltam az STM32F0DISCOVERY kit -hez tartozó kódokat. A CubeMX segítségével (bele van integrálva) felpiszkáltam az alapokat - írhatom a szoftverkémet. Nehéz lesz vele lépésről lépésre dolgozni, mivel eddig úgy tűnik azt szeretné, hogy mindent előre felkonfiguráljak, de azért megpróbálom.
Sajna sokat kell itt tanulni: MCU, Eclipse, CubeMX, HAL (és nem), CMSIS.
Röpke hetek kérdése.
Amit eddig találtam, hogy a CubeMX ablakocskáit "rángatni" kell , mert a konfigurációs lehetőségek nem látszanak.
OFF: Dolgoztam ilyesféle környezetben, ez leginkább egy RAD -hoz hasonló, engem a Clarion/Top Speed adatbázis turkáló program készítő keretrendszerre emlékeztet. Ha jól kitanulja az ember akkor rengeteg rutin feladatot megcsinál. A gondok akkor kezdődnek, ha a feladat valahol túl lóg a rendszerbe épített kereteken - pl. rajzoltam FFT -t vagy csináltam egy kis windowsos TCP/UDP teszt programot. Szóval nem egyszerű a korlátokat túllépni de lehet és érdemes.

* Én egy indián vagyok. Minden indián hazudik.

Volt rá workaround ezért nem érezték fontosnak. :) miután az ST átpecselte az Atollic 9-et CubeIDE 1.0-ra akkor a második update után a beépített MX repo letöltése már nem működött, hanyattaesett attól hogy a felhasználónevem szóközt és ékezetet tartalmazott. (alapból az appdata alatt akarta tárolni amit letöltött). Megadtam neki másik útvonalat akkor már letöltte de nem tudta kicsomagolni, azt mondta hibás a ZIP. Nem volt hibás a ZIP. :) Aztán még két update után ez tán megjavult, akkor meg azt kezdte el, hogy az MX-ben konfiguráláskor az órajelet rosszul kezelte, azt hiszem beszorozta 1 millióval. Beírtam a MHz mezőbe, hogy 12 erre piros lett minden és átírta valami veszett számra, konkrétan használhatatlan volt. De csak az IDE-be beépített MX csinálta a standalone MX nem. Ezt legalább fél évig nem javították vagy tán még több idő kellett hozzá. Aztán az egyik újabb F0 kontrollernél az MX konfiguráláskor csak egy UART-ot mutatott a holott kettő volt az uC-ben. stb. Aztán időnként szó nélkül bepusztul az MX kódgeneráláskor. Ennek a folyamata az, hogy ha már volt előző generálás akkor felolvas mindent (hogy ne vesszenek el a Te módosításaid) majd törli az összes fájlt és generál. Na amikor a törli az összes fájlt és nem generál, az azért jó mert mire majd újrapróbálkozások után amikor majd generál az már "szűz" kimenet lesz, nem lesznek benne a Te módosításaid az "USER CODE" blokkok között. Lehet a working copy diffből visszamazsolázni. Mondjuk nálam ez nem tragédia mert nem használom közvetleül azt a projektet amit generál, csak abból a kód és fejléc könyvtárakat linkelem át egy másik (az éles) projetkbe. Kalandos a cucc, minden update zsákbamacska. :-D

Kalandos a cucc, minden update zsákbamacska. :-D

Ez pontosan olyan mint az összes többi Javaban írt foshalom IDE.

Talán a Texas CCS-e tűnik egy hangyafasszal jobban összerakottnak.  Bár lehet csak azért érzem ezt, mert abban régebben és csak kevesebbet dolgoztam.

A kommandlájn TASM 7 semmi ilyennel nem rendelkezett. Viszont hiába vetettem be XMS-t és EMS gyorspostát is, ha a makrókat nem ott tárolta. Ezért kellett "'epítenem" egy 900k DOS memóriával rendelkező gépet. Pedig csak egy 6800 soros terminál program volt néhány billentyűzet és escape definícióval - innen a sok makró.

Gondolom, a MASM lefordította volna 640k-ban is, de nem arra voltam ráállva.

Ne is kockáztass! Én most csak hobbizok, nincs produkciós kötelezettségem, viszont valami azt súgja ez lesz a befutó, majd egyszer.
Ha sok az időd próbáld ki, de fejlesztés közben váltani a "tökön szúrom, magam" kategória, ha csak nem nagyon az elején jársz és jó hosszú a határidő.

* Én egy indián vagyok. Minden indián hazudik.

( Foltos | 2020. 01. 31., p – 14:57 )

Az Mbed-OS -re, illetve az Mbed Studio IDE -re szeretném felhívni a figyelmetek.

Mbed-OS
Az mbed-OS egy "rich" OS mikrokontrollerekre tervezve (Cortex-M). Magasabb rétegei C++ -ban íródtak, a hardware kozeli rétege C -ben. Van benne Cellular connectivity, WIFI, Ethernet, TCP/IP, FAT FS, Failsafe FLASH FS, Bluetooth, LoRa, NFC, RFID, I2C, SPI, etc... Természetesen konfigurálható, hogy mi forduljon be. Nyilt forrású, de nem open governence.

MBed Studio
Őkelme egy Visual Studio code alapú IDE, beágyazott fejlesztéshez átszabva, természetesen Mbed-OS fókusszal.

Megemlíteném még az mbed-cli -t, ami egy python -ban írt szoftverintegrációs rendszer, build system, illetve teszt tool. Ez megy az Mbed Studio alatt, de kézzel is használható.