STM32F051 CMSIS bare metal header files

C/C++

Bare metal programming -hoz keresem a megfelelő CMSIS fájlokat, arm-none-eabi tool chain, de eltévedtem az erdőben.

STM32F051 -es MCU-hoz keresem a megfelelő CMSIS fájlokat. Az egyik git repoban találtam olyat, hogy stm32f031x6.h (ezzel sikerült is egy kínai gyártmányú kis panelt a blink-ig felébreszteni).
A google a developper.arm.com -ot dobja fel, de az mintha a keil-hez fűződne ill. valami olyan ide-hez ami kezeli a (számomra szokatlan) .pack fájlt.
Megint a google feldob egy kimondottan az STMicroelectronics "cmsis_core" repót a git-en. Viszont itt nyoma nincs az ilyen nevesített fájloknak amit idéztem, olyat látok benne mint az stm32f0xx.h -t (amit az előzőleg idézett blinky repo is használ).

Két, jónak mondható bare metal programming guide-t is találtam, az egyik a git "cpq" nevével illetve a másik "független" a Vivonomicon sorozata.
Először a cpq verzióval indultam el (persze ott sincs pont az F051 mcu) de még nem sikerült működésre bírni vele a kártyámat.
Találtam egy igen régi csomagot is egy bizonyos "Frank Duignan" blogja - több stm gyártmányú arm-al is foglalkozik, viszont igen régi, és persze nincs ott sem szó az F051-ről.

Hogy lehet összerakni, egy használható fejlesztői CMSIS fájl készletet az STM32F051 -hez?

( apal v | 2024. 04. 21., v – 11:31 )

Szerkesztve: 2024. 04. 21., v – 11:32

A CMSIS az a Cortex-Mx specifikus dolgokat (SysTick, NVIC: interrupt controller, stb) tartalmazza csak. Az STM32F051xx specifikus definiciok azok az stm32f0xx.h-ban vannak, de amikor behuzod azt #include-dal akkor definiald a -DSTM32F051 makrot is a forditas soran, kulonben nem lesz jo. A teljes bundle (CMSIS headerek plusz STM32Fxxx specifikus header fileok)  letoltheto az ST oldalarol. 

Nem tudom mit is gondoljak.
Végül, az STMicroelectronic honlapján kezdtem keresgélni "célirányosan" - csupa STM32Cubexxx csomagot kaptam :(
Viszont, miután a git repboban kezdtem keresgélni https://github.com/orgs/STMicroelectronics/repositories és itt arra kerestem hogy "STM32F0" kaptam egy olyan találatot, hogy "cmsis_device_f0" és ebben vannak az olyan headerek, mint pl. az stm32f051x8.h és az assembly fájlok mint pl. "startup_stm32f051x8.s"

Viszont itt pedig hiányoznak (a működő blinky-hez képest) a következők:
cmsis_gcc.h
core_cm0.h
core_cmFunc.h
core_cmInstr.h

Hány részletben kell egy "teljes" készletet összerakni?

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

Én ebből a git repoból bányásztam, amikor STM32H743-ra csináltam valamit:

https://github.com/STMicroelectronics/STM32CubeH7.git

CMSIS is van benne, de az igazából csak ARM-hoz van, nem STM specifikus.
 

Az upstream CMSIS itt van elrejtve:

https://github.com/ARM-software

Mar anno jopar eve leszedtem innen-onnan a szukseges fileokat es ezeket hasznalom mindenhol. Igen, ugy latom en is hogy azota tenyleg egy kicsit atrendeztek, de azert relative konnyen osszeszedheto most is ha tudjuk mit kell keresni. Konkretan:

  • Innen le tudod szedni ezt a STM32F0xx standard peripherals library nevu dolgot.
  • Ebben a *.zip-ben a
    • ./STM32F0xx_StdPeriph_Lib_V1.6.0/Libraries/CMSIS/Include alkonyvtarban vannak a CMSIS-es headerek, es a 
    • ./STM32F0xx_StdPeriph_Lib_V1.6.0/Libraries/CMSIS/Device/ST/STM32F0xx/Include konyvtarban vannak az ST32F0xx specifikus headerek
  • A nagyon "bare metal" programozashoz a tobbi lenyegtelen.
  • Ezt a ket konyvtarat masold be valahova (nekem omlesztve vannak egy konyvtarba), az legyen benne az -I... include search path-ba
  • A forrasfileok-ba eleg csak az <stm32f0xx.h>-t behuznod, az maga utan rantja a tobbit (azaz CMSIS-es headereket, mint pl a core_m0.h meg az egyeb absztrakcios headereket mint a core_cmInstr.h meg ilyesmik, amikbe a rendszerszintu utasitasokhoz /barrier-ek, wait-for-interrupt, stb/ tartozo makrok vannak)

A "nagyon bare metal" az itten azt jelenti hogy a periferiakhoz tartozo definciokat (azaz a periferia-objektumokat illetve azok cimtartomanyait) megkapod - felteve ha a forditaskor definialod azt hogy milyen MCU-val dolgozol, esetedben a -DSTM32F051 kapcsolo az kell - de az fontos hogy ezeken felul semmi mast nem kapsz meg. Azaz ami itten hianyzik meg a teljes build folyamathoz, az a 

  • execution startup rutinok (crt0) es a
  • linker script

En ezt a kettot mindig magamnak szoktam megirogatni meg modositgatni ha kell (marpedig kell, pl bootloader-ekhez meg ilyesmikhez), de kiindulasnak a bundle-ban levo fileok is jok. Azaz lasd:

  • ./STM32F0xx_StdPeriph_Lib_V1.6.0/Libraries/CMSIS/Device/ST/STM32F0xx/Source/Templates/gcc_ride7/startup_stm32f051.s, illetve 
  • ./STM32F0xx_StdPeriph_Lib_V1.6.0/Projects/STM32F0xx_StdPeriph_Templates/TrueSTUDIO/STM32F051/STM32F051R8_FLASH.ld.

Sot, vsz alapszintu hasznalatre ezek jobbak is azert mint a full sajat :) De a sajat valtozatok is kb 50-50 sorosak (mind a crt0.c, mind a main.ld), szoval akar ide is be tudom masolni ha erdekel :] Ha sajat exectuion startup rutinokat hasznalsz, akkor a linkelest a -nostartfiles opcioval kell csinalnod, de azt leszamitva nincs (erdemi) kulonbseg a ket folyamat kozott. 

Szerk: a gcc es/vagy libc (itt: newlib, picolibc) is tartalmazhat mindenfele implementaciokat execution startup-ra illetve linker scriptre, de jo kerdes hogy ezzel mennyire jarsz jol... szoval itt talan inkabb a gyarto es/vagy MCU-specifikus implementaciokat erdemes alapul venni, de ketsegtelen hogy bizonyos, jobban egyesegesitett architekturaknal (pl RISC-V) mar a libc specs-ben hivatkozott megoldasok is jok lehetnek. Tapasztalat az az hogy az ARM az sajnos nem ennyire egysegesitett. 

Nagyon köszönöm a segítséget!
Különösen a linket! - működik :)

A "bare metal" itt azt jelentené, hogy nem szeretnék "gyári" periféria drivereket használni, amíg nem látom át (lelgalább nagyjából), hogy mit is csinálnak, hogy kellene működniük.
Viszont mazochista sem vagyok, nem akarok mindent is újra írni - különösen a #define VLMI 0x3000000 - ráadásul, ha használható lesz (valamire) közkincs lehet belőle, nem árt ha nem kellnyomozni miről is van szó.
 

Még valami, ugye a "-DSTM32F051" a make fájlban definiálandó?

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

Még valami, ugye a "-DSTM32F051" a make fájlban definiálandó?

Ez az arm-none-eabi-gcc számára egy opció/paraméter, azaz már a fordítás legelejétől kezdve létezik ez az STM32F051 mint #define-ált szimbólum(szerűség). De igen, nagyon célszerű bekerakni a Makefile-ba, a CFLAGS részeként. En pl imígy szoktam összerakni:

ARM_CPU=cortex-m0
ARM_ARCH=armv6-m

STM=STM32F072

ARM_DIR=/usr/local/arm-none-eabi

SPECS  += -specs=nano.specs -specs=nosys.specs
CCARCH += -mcpu=$(ARM_CPU) -mthumb -masm-syntax-unified

CFLAGS += $(CCARCH) $(SPECS) 
CFLAGS += -fno-common 
CFLAGS += -D$(STM) 
CFLAGS += -Wall -Wno-pointer-sign -O2
CFLAGS += -I$(ARM_DIR)/include
CFLAGS += -ffunction-sections -fdata-sections

LFLAGS += $(CCARCH) $(SPECS)
LFLAGS += -Wl,--gc-sections
LFLAGS += -Tmain.ld -nostartfiles

Es akkor a CFLAGS reszekent megjelenik a -DSTM32F072 (az esetemben):

$ arm-none-eabi-gcc -mcpu=cortex-m0 -mthumb -masm-syntax-unified \
 -specs=nano.specs -specs=nosys.specs  -fno-common \
 -DSTM32F072  -Wall -Wno-pointer-sign -O2 -I/usr/local/arm-none-eabi/include \
 -ffunction-sections -fdata-sections -c whatever_module.c

A *.c fileokban meg csak ennyi van az elejen ami architektura-specifikus:

#include <stm32f0xx.h>

( tovis v | 2024. 04. 21., v – 14:06 )

Még egy érdekes csomag:

https://github.com/libopencm3

Aktívan fejlesztik, de nem találkoztam még erre alapuló projectel.
Nagyon másként néz ki, viszont van egy nagy kupac példa is hozzá.

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

( balagesz | 2024. 04. 21., v – 15:27 )

Egy kis offtopik morgás: pár éve én is kódoltam pár projektet STM32-re. Akkor az lett a megoldás, hogy levadásztam a CubeMX IDE-t. A vadászat szó szerinti: az ST oldalán az összes link a login oldalra visz (vitt), én meg marhára nem akartam még egy újabb helyen regisztrálni. Egy rakás keresés után viszont találtam talán egy gentoo ebuild-ot? Vagy valamilyen arch-os csomagot? Amiben volt egy, az ST oldalára mutató direkt link a csomagra. Viszont ezt az egészet azóta se értem: a gyártónak mi az érdeke? Nem az, hogy eladja a csipjeit? Akkor meg mi a búbánatért szívatja a lehetséges vásárlóit ezekkel? Eh... (És nagyon nem az ST az egyetlen ezzel a hozzáállással, ugyanaz a marketinges köröz ezen cégek között? Vagy mi? :) )

Na de a lényeg: a leszedett cuccot felrakva és elindítva kreáltam egy új projektet az adott csippel, amire az IDE letöltötte/bemásolta a könyvtárba a szükséges inklúdokat, onnan tudtam kibányászni az adott csiphez valót. Utána (némi masszírozás után) már tudtam használni a saját környezetemben. Nem állítom hogy elegáns megoldás, de ez akkor működött.

Lehet ez lesz a vége. Akár marketing akár nem ők a profikra utaznak, az amatőröknek meg ott van az Arduino. Alapvetően (ha jól működik) akkor nem rossz ha a gyártó támogat egy jól összerakott tool chaint. A gond hogy sokan panaszkodnak hibákra illetve azok lassú javítására.

Én egyszerűen szeretnék egy mondjuk úgy tiszta környezetet, persze azért most minek kezdjem 1000x-re feltalálni a perifériákhoz tartozó header fájlokat?
Aztán itt van a startup code ami általában egy "kis" assembly fájl benne a interrupt és reszet vektorokkal, illetve a linker fájl. Egy adott típushoz értelmetlennek tűnik újra írni. (A kínai F051C8-as minimál fejlesztő lapot egy olyan kóddal élesztettem fel ami F031-hez készült és hibátlanul műkdik - közben így meggyőzödem arról is hogy az STLink V3SET debuggerem is rendben van, jó a bekötés)

Viszont ahogy nézegetem egyik kódot a másik után (bare metal) mindegyik kicsit másként fest és persze egyik sem épp az F051-re készült. Más más stílusban íródtak (pl. a GPIO pín kezelő makrók). Az assembly is elég érdekes (számomra) szokatlan kulcs szavak és konstrukciók - de ebben tud segíteni a Gemini. Szóval hobbinak jó.

Nem számítottam rá hogy ekkora kavalkád van a CMSIS, Standard Peripheral Library a HAL és végül a GUI tool-ok mint a CubeMX és Cube IDE. Jobban szerettem volna a kódra és az mcu-ra koncentrálni és nem a WEB-es keresgélésre.

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

Nekem is csak a startup meg a periféria headerek kellettek. (Meg talán még a linker szkript.) Viszont ezek behúznak pár CMSIS headert is, ezekről meg nem akartam lebeszélni őket, nagyrészt úgyis csak definíciók.

Viszont volt egy olyan is, hogy a Cube által legenerált fájlokkal nem fordult a tesztem. Mint kiderült, hiába a kiválasztott pontos típus, valamelyik header fájlban benne volt kikommentelve egy rakás csip-típus, fölötte azzal a megjegyzéssel, hogy kommenteld vissza azt a fajtát, ami neked kell. :-D

Amúgy persze, nem árt, ha a gyártó ad egy használható fejlesztőkörnyezetet, az oké. Meg a profik is oké. De ezekkel a körülményes hozzáférésekkel őket is szívatják. Tudom, hogy nem vagyok egy nagy minta, de ha legközelebb valamihez µC-t vadászok, hát, ezen hozzáállásuk itt lesz a fejemben. ;)

( Foltos | 2024. 04. 21., v – 22:58 )

Nem tudom mit szeretnél csinálni, és mit értesz bare metal alatt (manapság már webes környezetben is használják ezt a kifejezés).

Ha terméket fejlesztesz, a STM -es periféria driverek abba nem valók, ha rendes cucc kell, írj sajátot. Minden szilikon gyártó igyekszik bezárni a saját világába. Az ST sem ad "csak úgy" drivereket, hanem a Cube MX -et erőlteti. Hogy a vendor lock-in neked baj vagy sem azt te tudod.

Érdemes megnézni a kevésbé bare metal projekteket, mint a Zephyr illetve a PlatformIO. Ezeken keresztül rengeteg funkcionalitáshoz hozzáférsz. Ma már kevés az MCU projekt ahol ne kellene egy filesystem, TCP/IP, vagy hasonló.

Az ST sem ad "csak úgy" drivereket, hanem a Cube MX -et erőlteti. Hogy a vendor lock-in neked baj vagy sem azt te tudod.

Mondjuk az ST meg mindig a jobbak kozul valo, mar kellett dolgoznom ennel sokkalta rosszabb eszkozokkel is... persze kis reszelessel, a korabbi tapasztalatok alapjan azert sikerult kiherelnem az osszes eroltetett IDE-s dolgot ezutobbiakbol is, de na :/ Az irany az ketsegtelenul nem jo. 

Évek óta nézegetem a különféle 32 bites mcu-kat. Az eddigiek alapján azt kell mondanom, az ST a legjobb, ha beleveszed a fejlesztéshez szükséges eszközök árát  is.

Alapvetően nincs kifogásom a "Cube"-os cuccokkal kapcsolatban, de több helyen úgy halottam gondsok vannak vele. Illetve, mivel igyekszik eltakarni a HW-t, nekem nem jó. 

 

OFF: Az egész történet, egy hobbi projektről szól - MOSFET alapú műterhelés. A műterhelés analóg része egy kínai panel, egy darab MOSFET-el. Jól működik és egy régi P4 hűtőbordával, beépítve egy régi ATX táp házba (80 mm ventiátorral) kb. 120W simán megeszik. Viszont a kínaiak által forgalmazott panel műszerek sz'rok. Ha műszerekről van szó, mind máig azt látom, hogy ha képes kommunikálni (mondjuk PC-vel soiroson) akkor az ára hirtelen 1,5-re ugrik (vagy többre úgy, hogy semmivel nem tud többet). Szóval kell egy olyen vezérlő egység, ami képes kihajtanai 2x3(4) hétszegmenses LED-et, mérni a feszültséget 100(200)V-ig és az áramot 10(20) amperig. Mérni a hőmérsékletet (persze beavatkozni mielőtt leolvad), esetleg külső hőmérsékletet is tud mérni (a tesztelt eszköz). Ezen felül tudni kell kommunikálni egy PC-vel - itt még kicsit bizonytalan vagyok (WiFi, BL, Ethernet, soros). A mechanikus konstrukció lehetővé teszi, hogy akár egy kis 12V-os akkuról működjön (hálózati táp helyett) és ha WiFI/BL akkor mobil is lehet.
De a leglényegesebb feladat a mérés és megjelenítés.

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

Milyen 8 bites mcu-t javasolnál?

A 8 bites mcu-k általában 10 bites ADC és nem igen találtam DAC-ot.
Ha a hőmérsékletet is ki akarom jelezni, min 3x3 digites hétszegmenses kijelző kell multiplexelve - ami most a fiókban van az HC164 - elég sűrűn kell újratölteni.
Ha mcu akkor az áram szabályozás leginkább inkrementális adóval működik (helytakarékos) - esetleg potméter aminek a viperjét egy ADC csatornára kötsz.
Kommunikálni is kellene.
Összességében határeset.

Egyébként ez egy ARM Cortex-M0 -ás, árban nagyjából ugyanannyi mint egy 8 bites.

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

Ezért írtam, hogy ha az ismerkedés a cél akkor OK. Igen árban már kb. egy szinten vannak. Csak pont az "egyszerűsége" miatt mondtam, egy 8 bitest egyszerűbb beröffenteni. Nem írtál konkrét követelményeket, így nehéz konkrét MCU-t javasolni hozzá. Mondjuk a DAC mindjárt tizedeli a lehetséges indulókat.

A 32+ bites MCU-k kozul meg szerintem meg mindig az STM32-nek indul a legmeredekebben a tanulasi-siker gorbeje (fejlesztokeszlet az `apt install` modon felmegy, van olcso off-the-shelf debuggerrel es debug UART-tal ellatott fejlesztokeszlet peldaprogramokkal es kapcsolasi rajzzal a legegyszerubbtol a bonyolultabbig, sok periferia van eleve, sok howto-manual-pelda van a neten, az IC-k doksija is meglepoen jo es egyseges, stb). Szoval hamar 32 bites, akkor ez egy jo valasztas.

A 8 meg 16 bites MCU-kkal annyi lehet a fenntartas hogy amint tulleped az architektura limitacioit (azaz a 16 bites address space melyseget), akkor az egy teljesen uj vilag, az univerzum osszes elkepzelheto hardveres-asssmeblyszintu-szofveres-gccs-linkeleses hekkeleseivel egyutt. Meg akkoris ha a hw maga latszolag egyszeruen tamogatja azt... szoval kicsit kevesbe "future proof", kevesbe elegans, foleg ha szep hordozhato kodot akarunk irni hardver-specifikusabb esetekre is.

A 8/16 bites rendszerek elonyeit gyakorlatban inkabb ott latom hogyha nagyon integralt az alkalmazas, akkor fizikailag kisebb csippet konnyebb 8/16 bitre talalni. Azaz ha pl csak egy DFN8-nyi vagy VQFN16-nyi hely van csak, arra hamarabb lesz MCU. 

Szerintem manapság szinte az egyedüli jó választás. Bármerre indulsz a csipek és az eszközök egyre drágábbak.
Szerintem a nyolcbitesek akkor jöhetnek szóba, ha nem kell nagy számítási kapacitás viszont a nagyon kicsi fogyasztás fontos - pl. ha elemről kell működtetni.
Ráadásul,  nyolcbitesek nehezen vagy drágán debuggolhatóak, az eszközök akár drágábbak is lehetnek.
Más kérdés, hogy a 32 bitesek programozásához nagyobb erőfeszítések kellenek. Jóval bonyolultabbak a perifériák is, pl. a nyolcbiteseknél nemigen láttam DMA-t.

Elkezdtem, egy STM8-as fejlesztést is, de már 2x4 digit HC164 kihajtástól "liheg", alig van benne szufla a többi feladatra.

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