Názory k článku Architektura mikrořadičů s jádry ARM Cortex-M4

uCLinux na M3/Mx může běžet, port pro LPC1789 jsem zkoumal. Port obsahuje i možnost použít MPU k chránění procesů mezi sebou a ochraně jádra. Bohužel regionů je celkem málo, ale lze je drobit bitmapou na několik stejně dlouhých úseků a v kombinaci s tím, že se při výjimce určitá část regionů plní ze simulované stránkové tabulky pro každý proces, lze pokrýt kompletní adresní prostor.

Bohužel zatím veškeré Cortex-M mají zásadní chybu pro použití s plnohodnotným OS. Stav procesoru se při přechodu z uživatelského do systémového režimu ukládá vždy na zásobník přerušeného procesu. Z toho vyplývá, že i kdyby byla přidaná MMU, tak není možné zajistit swapování a ani mapování zásobníku přes softwarově obslouženou MMU nebo MPU. Nepřístupný zásobník vede ke ztrátě stavu přerušeného vlákna/procesu a vyhlášení dvojité chyby. Jediné řešení je pak daný proces ukončit. MPU uCLinux to řeší tak, že regiony pro zásobník jsou natvrdo nastavené při každém přepnutí úlohy (procesu,vlákna).

Celkově ale použití MPU jako softwarové TLB vede k nedeterminismu běhu a tím pádem k latence již nevyhoví velkému množství řídicích/real-time aplikací, pro které je Cortex-M určený.

Dále rozumný běh Linuxu v dnešní době vyžaduje alespoň 4 (spíše 8) MB paměti. To sice třeba na naší desce máme http://pikron.com/pages/products/cpu_boards/lx_cpu.html , ale stejně bude overhead Linuxu a přístupu do vnější paměti velký. Myslím si tedy, že na Cortex-M má smysl především uvažovat o menších otevřených systémech jako je MBed https://developer.mbed.org/, NuttX http://nuttx.org/ nebo RTEMS https://www.rtems.org/, které všechny máme včetně TCP/IP na našem HW odzkoušené.

Pro seriózní aplikace, kde je účelné nasadit Linux, je pak rozumné uvažovat BeagleBone a spol (AM335x, AM43xx, AM5728, i.MX6 atd). Na hraní a experimentování pak lze použít RPi2 nebo nějaký Allwinner.

Spojení "plnohodnotný OS" mi působí určité potíže. V embedded světě existují trochu jiná měřítka a např. MMU/MPU tu IMHO rozhodně nepatří mezi must-have.
Jinak mi ovšem poněkud uniká, co vedlo architekty Cortexů M k tomuto řešení, pokud jde o práci se zásobníky. Logika oddělených zásobníků je tím dost silně narušena.

Tak pro mě bylo zvykem RTOS, které se linkují s aplikací do jednoho adresního prostoru, spíš říkat Real-Time Executiva něž klasický (víceuživatelský) operační systém. Holt první systém, když nepočítám osmibitové počítače jen s monitorem/Basicem, se kterým jsem přišel někdy okolo roku 1988 do kontaktu byl víceterminálový vývojový systém na bázi Unixu. Sice jsem pak na svém SAPI86 pak roky pracoval pod DOSem, ale tomuto zavaděči bych také operační systém neříkal.

Ale je to jen věc zvyku a souhlasím s tím, že v mnoha RT aplikcích není MMU potřeba a často ani být ani kvůli zpomalení a zhoršení determinizmu běhu být nemá. I když jakmile je v systému cache, a ta tam pro rychlé zpracování velkých objemů dat být musí, tak klasické metody ověření bezpečnosti také selhávají.