Operační systémy v reálném čase (RTOS) a jejich aplikace

Co je RTOS

Real-Time Operating System (RTOS) je odlehčený operační systém používaný ke zjednodušení multitaskingu a integrace úloh v prostředcích a časově omezených provedeních, což je obvykle případ vestavěných systémů. Kromě toho pojem „reálný čas“ označuje předvídatelnost / determinismus v době provádění, nikoli základní rychlost, proto lze RTOS obvykle prokázat, že díky svému determinismu splňuje tvrdé požadavky v reálném čase.

Klíčové koncepty RTOS jsou:

Úloha

Úlohy (lze také nazvat procesy / vlákna) jsou nezávislé funkce běžící v nekonečných smyčkách, obvykle každý odpovědný za jednu funkci. Úlohy běží nezávisle ve svém vlastním čase (časová izolace) a zásobníku paměti (prostorová izolace). Prostorovou izolaci mezi úlohami lze zaručit použitím jednotky ochrany hardwarové paměti (MPU), která omezuje oblast přístupné paměti a spouští výjimky z poruch při narušení přístupu. Normálně jsou interní periferní zařízení mapována do paměti, takže MPU lze použít také k omezení přístupu k periferním zařízením.

Úlohy mohou být v různých stavech:

• Blokováno - úloha čeká na událost (např. časový limit zpoždění, dostupnost dat / zdrojů)
• Připraveno - úloha je připravena ke spuštění na CPU, ale neběží, protože CPU používá jinou úlohu
• V chodu - úloha je přiřazena ke spuštění na CPU

Plánovač

Plánovače v RTOS řídí, která úloha má být spuštěna na CPU, a jsou k dispozici různé plánovací algoritmy. Normálně jsou:

• Preventivní - provedení úlohy lze přerušit, pokud je připravena jiná úloha s vyšší prioritou
• Kooperativní - k přepnutí úlohy dojde, pouze pokud se aktuální spuštěná úloha vrátí

Preventivní plánování umožňuje úlohám s vyšší prioritou přerušit úlohu s nižší prioritou, aby splnily omezení reálného času, ovšem na úkor na vyšší režie při přepínání kontextu.

Komunikace mezi úlohami (ITC)

Za normálních okolností bude nutné, aby si navzájem sdílely informace nebo události více úloh. Nejjednodušší způsob sdílení je přímé čtení / zápis sdílených globálních proměnných do paměti RAM, ale to je nežádoucí kvůli riziku poškození dat způsobenému sporem. Lepším způsobem je čtení/zápis statické proměnné s rozsahem souboru přístupné funkcemi setter a getter, a konfliktům časování lze zabránit deaktivací přerušení, nebo použitím objektu vzájemného vyloučení (mutex) uvnitř funkce setter/getter. Čistší způsob je předávání informací mezi úlohami pomocí objektů RTOS bezpečných pro vlákna, jako je fronta zpráv.

Kromě sdílení informací mohou objekty RTOS také synchronizovat provádění úloh, protože úlohy lze blokovat a čekat na dostupnost objektů RTOS. Většina RTOS má objekty, jako například:

• Fronta zpráv
  • Fronta FIFO pro předávání dat
  • Data lze zaslat kopií nebo odkazem (ukazatel)
  • Používá se k odesílání dat mezi úlohami nebo mezi přerušením a úlohou
• Semafor
  • Lze s ním zacházet jako s referenčním počitadlem pro záznam dostupnosti konkrétního zdroje
  • Může je jednat o binární nebo počítající semafor
  • Používá se k hlídání využití zdrojů nebo synchronizaci provádění úloh
• Mutex
  • Podobně jako u binárního semaforu, který se obvykle používá k ochraně využití jednoho zdroje (MUTual EXclusion)
  • FreeRTOS mutex je dodáván s mechanismem prioritní dědičnosti, aby se zabránilo problémům s prioritní inverzí (stav, kdy úloha s vysokou prioritou skončí čekáním na úlohu s nižší prioritou).
• Poštovní schránka
  • Jednoduché umístění úložiště pro sdílení jedné proměnné
  • Lze považovat za frontu s jedním prvkem
• Skupina událostí
  • Skupina podmínek (dostupnost semaforu, fronty, příznaku událostí atd.)
  • Úlohu lze zablokovat a může čekat na splnění konkrétní podmínky kombinace
  • K dispozici v Zephyru jako Polling API, ve FreeRTOS jako QueueSets

Systémová událost Tick

RTOS potřebují k měření času časovou základnu, obvykle ve formě proměnné počítadla systému, která se zvyšuje v periodickém přerušení hardwarového časovače. Díky systémové události Tick může aplikace udržovat více než časově orientované služby (interval provádění úloh, časový limit čekání, časování) pomocí jediného hardwarového časovače. Vyšší rychlost událostí Tick však pouze zvýší rozlišení časové základny RTOS a software nebude běžet rychleji.

Proč používat RTOS

Organizace

Aplikace lze vždy psát holým kovem, ale jak se zvyšuje složitost kódu, bude mít určitý druh struktury pomoc při správě různých částí aplikace a jejich oddělení. Navíc díky strukturovanému způsobu vývoje a známému návrhovému jazyku může nový člen týmu porozumět kódu a začít přispívat rychleji. Technologie RFCOM vyvinul aplikace využívající různé mikrokontroléry jakoTexas InstrumentsHerkules ,Renesas 'RL78 aRX , aSTMicroelectronics 'STM32 na jiném RTOS. Podobné návrhové vzory nám umožňují vyvíjet aplikace na různých mikrokontrolérech a dokonce i na jiném RTOS.

Modularita

Rozděl a panuj. Oddělením funkcí v různých úlohách lze snadno přidat nové funkce, aniž by došlo k porušení dalších funkcí; za předpokladu, že nová funkce nepřetíží sdílené zdroje, jako je CPU a periferní zařízení. Vývoj bez RTOS bude normálně ve velké nekonečné smyčce, kde jsou všechny funkce součástí smyčky. Změna jakékoli funkce ve smyčce bude mít dopad na další funkce, takže bude obtížné software upravovat a udržovat.

Komunikační komíny a ovladače

Mnoho stávajících ovladačů nebo zásobníků, jako jsou TCP / IP, USB, zásobníky BLE a grafické knihovny, je vyvíjeno / portováno pro / do existujících RTOS. Vývojář aplikací se může zaměřit na aplikační vrstvu softwaru a výrazně zkrátit dobu uvedení na trh.

Tipy

Statická alokace

Použití statického přidělení paměti pro objekty RTOS znamená vyhrazení zásobníku paměti v paměti RAM pro každý objekt RTOS během doby kompilace. Příkladem funkce statické alokace ve freeRTOS je xTaskCreateStatic (). Tím je zajištěno, že objekt RTOS lze úspěšně vytvořit, čímž se ušetří potíže s manipulací s možným neúspěšným přidělením a aplikace bude více deterministická.

Pokud jde o rozhodování o velikosti zásobníku potřebné pro úlohu, lze úlohu spustit s větší (více než dostatečnou) velikostí zásobníku a poté lze za běhu zkontrolovat využití zásobníku a určit značku vysoké hladiny. K dispozici je také nástroj pro statickou analýzu zásobníku.

Abstrakční vrstva operačního systému (OSAL) a smysluplná abstrakce

Stejně jako vrstva HAL (Hardware Abstraction Layer) umožňuje použití abstrakční vrstvy RTOS aplikačnímu softwaru snadnou migraci na jiné RTOS. Vlastnosti RTOS jsou poměrně obdobné, takže vytváření OSAL by nemělo být příliš komplikované. Příklad:

Přímé použití rozhraní freeRTOS API:

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

Zabalení RTOS API do OSAL:

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

použití abstrakční vrstvy na komunikaci mezi úlohami k lepší čitelnosti kódu a minimalizaci rozsahu objektu RTOS:

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

Abstrakce navíc umožňuje programátorovi změnit objekt RTOS použitý pod ním (např. z mutexu do počítajícího semaforu), pokud je k dispozici více než jeden modul SPI. OSAL a další abstrakční vrstvy pomáhají při testování softwaru také zjednodušením falešného vkládání funkcí během testování jednotky.

Volba intervalu událostí Tick

V ideálním případě je nižší rychlost událostí Tick lepší kvůli menší režii. Pokud chce vývojář vybrat vhodnou rychlost událostí Tick, může vypsat omezení časování modulů v aplikaci (interval opakování, doba časového limitu atd.). Pokud existují některé odlehlé moduly, které potřebují malý interval, lze u odlehlých modulů zvážit vyhrazené přerušení časovače místo zvýšení rychlosti událostí Tick RTOS. Pokud je vysokofrekvenční funkce velmi krátká (např. zápis do registrace pro zapnutí / vypnutí LED), lze ji provést uvnitř rutiny přerušení služby (ISR), jinak lze použít odložené zpracování přerušení. Zpožděné zpracování přerušení je technika odložení výpočtu přerušení do úlohy RTOS, ISR vygeneruje událost pouze prostřednictvím objektu RTOS, poté bude událost RTOS událostí odblokována a provede výpočet.

Potlačení událostí Tick pro aplikaci s nízkou spotřebou

Funkce Tickless idle deaktivuje přerušení událostí Tick, je-li systém po delší dobu nečinný. Jedním z významných způsobů, jak lze pomocí vestavěného firmwaru snížit spotřebu energie, je uvést systém do režimu nízké spotřeby na co nejdelší dobu. Funkce Tickless idle je implementována deaktivací periodického přerušení událostí Tick a následným nastavením časovače odpočítávání na přerušení v okamžiku, kdy se má spustit blokovaná úloha. Pokud na vypršení časového limitu nečeká žádná úloha, lze přerušení událostí Tick deaktivovat na dobu neurčitou, dokud nedojde k dalšímu přerušení (např. stisknutí tlačítka). Například v případě majáku Bluetooth Low Energy (BLE) lze MCU uvést do hlubokého spánku mezi reklamním intervalem. Jak je znázorněno na obrázku 1, maják je po většinu času přepnut do režimu hlubokého spánku a spotřebovává energii v desítkách µA.

Obrázek 1: Odběr proudu majáku BLE (zdroj obrázku: RFCOM)

Závěr

RTOS poskytuje funkce jako plánovač, úlohy a objekty RTOS pro komunikaci mezi úlohami, jakož i komunikační zásobníky a ovladače. Umožňuje vývojářům soustředit se na aplikační vrstvu integrovaného softwaru a snadno a rychle navrhovat software pro více úloh. Stejně jako všechny ostatní nástroje je však nutné jej správně používat, aby přinesl větší hodnotu. Aby mohli vývojáři vytvářet bezpečný, zabezpečený a efektivní vestavěný software, měli by vědět, kdy používat funkce RTOS a také jak konfigurovat RTOS.