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.