Valós idejű operációs rendszerek (RTOS-ek) és alkalmazásuk

Mi az az RTOS

A valós idejű operációs rendszer (RTOS) egy erőforrás kímélő (lightweight) operációs rendszer, amely megkönnyíti a többfeladatos működést és a feladatok integrálását olyan erőforrás- és időbeli korlátok esetén, amelyek általában a beágyazott rendszereket jellemzik. Különben is, a „valós idő” elnevezés a nyers sebesség helyett a végrehajtási idő megjósolhatóságára és a determinisztikus működésre utal, ezért az RTOS a determinizmusának köszönhetően általában bizonyíthatóan megfelel a kemény (hard) valós idejű rendszerek követelményeinek.

Az RTOS-eknél használt legfontosabb fogalmak a következők:

Feladat

A feladatok (vagy más néven folyamatok/szálak) független függvények, amelyek végtelen ciklusokban futnak, rendszerint mindegyik egy-egy funkcióért felel. A feladatok függetlenül futnak a saját idejükben (időbeli elszigeteltség) és a memóriaterületükön (térbeli elszigeteltség). A feladatok közötti térbeli elszigeteltség egy hardveres memória védelmi egység (MPU) használatával garantálható, amely korlátozza az elérhető memóriaterületet, és hiba miatti kivételes eseményt indít a hozzáférés megsértése esetén. Normál esetben a belső perifériák memória-leképezésűek, így az MPU a perifériák hozzáférésének korlátozására is használható.

A feladatok különböző állapotúak lehetnek:

• Blokkolt – a feladat eseményre vár (pl. késleltetés leteltére, adatok/erőforrások elérhetővé válására)
• Készenléti – a feladat a CPU-n történő futásra kész, de nem fut, mert a CPU-t egy másik feladat használja
• Futó – a feladat hozzá van rendelve a CPU-hoz futtatásra

Ütemező

Az RTOS-ben levő ütemezők vezérlik, hogy melyik feladat fusson a CPU-n és különböző ütemezési algoritmusok állnak rendelkezésre. Ezek szokásosan a következők:

• Preemptív (prioritáson alapuló) – a feladat végrehajtása megszakadhat, ha egy másik, magasabb prioritású feladat áll készenlétben
• Kooperatív (együttműködő) – a feladatváltás csak akkor történik meg, ha az aktuálisan futó feladat megengedi

A preemptív ütemezés a valós idejűség követelményeinek teljesítése érdekében lehetővé teszi, hogy a magasabb prioritású feladatok megszakítsák az alacsonyabb prioritású feladatokat, de ez az átkapcsolási idők (context switching) miatt többletráfordítással jár.

Feladatok közötti kommunikáció (ITC)

Több feladat esetén a feladatoknak általában információkat vagy eseményeket kell megosztaniuk egymással. A megosztás legegyszerűbb módja megosztott globális változók közvetlen olvasása/írása RAM-ban, de ez nem kívánatos a versenyhelyzet okozta adatsérülés veszélye miatt. Jobb módszer a setter és getter függvények által elérhető fájlhatókörű statikus változók olvasása/írása, a versenyfeltételek kialakulása pedig megakadályozható a megszakítások letiltásával vagy a setter/getter függvényen belül egy kölcsönös kizárási objektummal (mutex). A „tisztább” módszer a szálbiztos RTOS objektumok, például üzenetsor használata az információknak a feladatok közötti átadásához.

Az információk megosztása mellett az RTOS-objektumok képesek szinkronizálni a feladatok végrehajtását is, mivel a feladatok blokkolhatók, hogy várják meg az RTOS-objektumok elérhetőségét. A legtöbb RTOS a következő objektumokkal rendelkezik:

• Üzenetsor
  • FIFO sorbanállási technika az adatok átadásához
  • Az adatok másolással vagy hivatkozással (mutató) küldhetők
  • Adatok küldésére szolgál a feladatok vagy a megszakítás és a feladat között
• Szemafor
  • Referenciaszámlálóként kezelhető egy adott erőforrás rendelkezésre állásának rögzítésére
  • Lehet bináris vagy számláló szemafor
  • Az erőforrások használatának védelmére vagy a feladat-végrehajtás szinkronizálására szolgál
• Mutex
  • A bináris szemaforhoz hasonlóan általában egyetlen erőforrás használatának védelmére használatos (MUTual EXclusion (kölcsönös kizárás))
  • A FreeRTOS mutex egy prioritásöröklődési mechanizmussal rendelkezik, hogy elkerülje a prioritás inverzióját (vagyis amikor egy magas prioritású feladatnak egy alacsonyabb prioritású feladat befejeződésére kell várnia)
• Postaláda
  • Egyszerű tárolóhely egyetlen változó megosztására
  • Felfogható egyelemű várakozási sorként
• Eseménycsoport
  • Feltételek csoportja (szemafor, várakozási sor, eseményjelző stb. elérhetősége)
  • A feladat blokkolható és megvárhatja, amíg egy adott kombinációs feltétel teljesül
  • A Zephyr-ben Polling API-ként, a FreeRTOS-ban QueueSets-ként érhető el

Rendszerórajel

Az RTOS-nek időalapra van szüksége az idő méréséhez. Általában ez egy rendszerórajel-számláló változó, amelynek növelése hardver által generált periodikus időzítő megszakítással történik. A rendszerórajelnek köszönhetően egy alkalmazás több időalapú szolgáltatást (feladat-végrehajtási intervallumot, várakozási időtúllépést, időszeletelést) képes fenntartani egyetlen hardveres időzítő használatával. A gyorsabb rendszerórajel azonban csak az RTOS időalap felbontását növeli, nem fogja gyorsabban futtatni a szoftvert.

Miért használjunk RTOS-t

Szervezés

Az alkalmazások mindig megírhatók „bare metal” (a futtatásukhoz operációs rendszert nem igénylő) módon, de a program bonyolultságának növekedésével valamilyen struktúra megléte segít az alkalmazás különböző részeinek kezelésében, elkülönítve tartásában. Ezenkívül strukturált fejlesztési mód és ismerős programfejlesztő nyelv alkalmazásával egy új munkatárs képes megérteni a programot és gyorsabban megkezdheti a hozzájárulást. Az RFCOM Technologies különböző mikrovezérlőket, pl. a Texas Instruments, Hercules termékének, a Renesas RL78 és RX termékeinek, illetve az STMicroelectronics STM32 termékének használatával különböző RTOS-eken használó alkalmazásokat fejlesztett ki. A hasonló tervezési minták lehetővé teszik számunkra alkalmazások fejlesztését különböző mikrovezérlőkön és akár egy másik RTOS-t is.

Modularitás

Oszd meg és uralkodj. A különböző feladatok funkcióinak szétválasztásával új funkciók könnyen hozzáadhatók más funkciók sérülése nélkül – feltéve, hogy az új funkció nem terheli túl az olyan megosztott erőforrásokat, mint a CPU és a perifériák. Az RTOS nélküli fejlesztés esetén általában egy nagy végtelen ciklusról van szó, ahol az összes funkció a ciklus része. A hurokban lévő bármelyik funkció megváltoztatása hatással lesz a többi funkcióra, ami miatt a szoftver módosítása és karbantartása nehézkes.

Kommunikációs memóriaterületek és illesztőprogramok

A meglévő RTOS-ekhez sok külső illesztőprogram vagy memóriaterület, például TCP/IP, USB, BLE memóriaterület és grafikus könyvtár van kifejlesztve vagy portolva. Egy alkalmazásfejlesztő mérnök a szoftver alkalmazási rétegére összpontosíthat, és jelentősen csökkentheti a piacra kerülés idejét.

Tippek

Statikus memóriafoglalás

A statikus memóriafoglalás az RTOS-objektumok számára azt jelenti, hogy a RAM-ban lévő memóriaterületek lefoglalására fordítás közben kerül sor. A statikus memóriafoglalás funkció freeRTOS-beli használatának egy példája az xTaskCreateStatic(). Ez biztosítja az RTOS-objektum sikeres létrehozását, kiküszöbölve az esetleges sikertelen foglalás kezelésével járó fáradságot és determinisztikusabbá téve az alkalmazást.

Ami a feladathoz szükséges memóriaterület méretének eldöntését illeti, a feladat nagyobb (több mint elegendő) memóriaterülettel futtatható, majd futás közben ellenőrizhető a memóriaterület használata a legmagasabb érték meghatározásához. Statikus memóriaterület-elemzés is rendelkezésre áll.

Operációs rendszer absztrakciós réteg (OSAL) és értelmes absztrakció

Csakúgy, mint a hardver absztrakciós réteg (HAL), az RTOS absztrakciós réteg használata is lehetővé teszi az alkalmazás szoftverének könnyű migrálását más RTOS-ekre. Az RTOS-ek funkciói nagyon hasonlóak, így az OSAL létrehozása nem nehéz. Például:

A freeRTOS API közvetlen használatával:

if( xSemaphoreTake( spiMutex, ( TickType_t ) 10 ) == pdTRUE ) { //dosomething }

Az RTOS API beillesztése OSAL-be:

if( osalSemTake( spiMutex, 10 ) == true) { //dosomething }

Az absztrakciós réteg használata a feladatok közötti kommunikációban a program olvashatóbbá tétele és az RTOS-objektum terjedelmének minimalizálása érdekében:

if( isSpiReadyWithinMs( 10 ) ) { //doSomething }

Ezenkívül, az absztrakció lehetővé teszi a programozó számára, hogy megváltoztassa az alatta használt RTOS-objektumot (például mutexről számláló szemaforra), ha egynél több SPI modul áll rendelkezésre. Az OSAL és más absztrakciós rétegek segítenek a szoftvertesztelésben, valamint egyszerűsítik a modellfunkciók beillesztését az egység tesztelése során.

Az órajel-intervallum kiválasztása

Ideális esetben a lassúbb órajel jobb, mert kevesebb többletigénnyel jár. A megfelelő órajel-frekvencia kiválasztásához a fejlesztő felsorolhatja a modulok alkalmazáson belüli időzítési korlátjait (ismétlődési intervallum, időtúllépés időtartama stb.). Ha vannak olyan külön modulok, amelyek kis intervallumot igényelnek, akkor számukra az RTOS órajel-frekvencia növelése helyett célszerűbb megfontolni dedikált időzített megszakítások alkalmazását. Ha a nagy frekvenciájú funkció nagyon rövid (pl. regiszter írása LED be-ki kapcsolásához), akkor elvégezhető egy megszakítási szolgáltatási rutinon (ISR) belül, ellenkező esetben késleltetett megszakításkezelés használható. A késleltetett megszakításkezelés a késleltetett megszakítás RTOS feladatba való beszámításának technikája. Az ISR csak egy eseményt hoz létre az RTOS-objektumon keresztül, majd az esemény feloldja az RTOS feladat blokkolását és ez utóbbi elvégzi a számítást.

Órajel elnyomása alacsony fogyasztású alkalmazásokhoz

Az órajel nélküli üresjárat kikapcsolja az órajel-megszakítást, ha a rendszer hosszabb ideig üresjáratban van. A beágyazott firmware az energiafogyasztást jelentősen csökkenteni tudja, ha a rendszert a lehető leghosszabb ideig alacsony fogyasztású üzemmódba kapcsolja. Az órajel nélküli üresjárat megvalósítása a periodikus órajel-megszakítás letiltásával, majd egy olyan visszafelé számláló beállításával történik, amely a blokkolt feladat végrehajtása miatt szükséges megszakítást időzíti. Ha nincs olyan feladat, amely időzítés lejártára vár, akkor az órajel-megszakítást határozatlan időre ki lehet kapcsolni, amíg újabb megszakítás, (pl. gombnyomás) nem történik. Például egy kis teljesítményű Bluetooth (Bluetooth Low Energy, BLE) jeladó esetén az MCU mélyalvás üzemmódban lehet a hirdetési intervallumok között. Amint az 1. ábrán látható, a jeladó az idő nagy részében mélyalvás üzemmódba kerül, és áramfelvétele tíz µA-kben mérhető.

1. ábra: Egy BLE jeladó áramfelvétele (Kép: RFCOM)

Összegzés

Az RTOS olyan funkciókkal rendelkezik, mint például az ütemező, a feladatok, a feladatok közötti kommunikációs RTOS-objektumok, valamint a kommunikációs memóriaterületek és illesztőprogramok. Ez lehetővé teszi a fejlesztők számára, hogy a beágyazott szoftver alkalmazási rétegére összpontosítsanak és könnyen, gyorsan többfeladatos szoftvereket tervezhessenek. Ugyanakkor, mint bármely más eszközt, ezt is megfelelő módon kell használni, hogy az minél jobban kihasználható legyen. Üzembiztos, biztonságos és hatékony beágyazott szoftverek létrehozásához a fejlesztőknek tudniuk kell, mikor kell használni az RTOS-funkciókat, illetve ismerniük kell az RTOS konfigurálásának módját.