Real-Time Operating Systems (RTOS) en hun toepassingen

Wat is RTOS

Een Real-Time Operating System (RTOS) is een lichtgewicht besturingssysteem dat wordt gebruikt om multitasking en taakintegratie te vergemakkelijken in ontwerpen met beperkte middelen en tijd, wat gewoonlijk het geval is in ingebedde systemen. Bovendien duidt de term "real-time" eerder op voorspelbaarheid/determinisme in de uitvoeringstijd dan op ruwe snelheid, zodat meestal kan worden aangetoond dat een RTOS aan harde real-time-eisen voldoet dankzij zijn determinisme.

Kernbegrippen van RTOS zijn:

Taak

Taken (kunnen ook processen/threads worden genoemd) zijn onafhankelijke functies die in oneindige lussen draaien, gewoonlijk elk verantwoordelijk voor één functie. Taken worden onafhankelijk van elkaar uitgevoerd in hun eigen tijd (temporele isolatie) en geheugenstapel (ruimtelijke isolatie). Ruimtelijke isolatie tussen taken kan worden gegarandeerd met behulp van een hardwarematige geheugenbeschermingseenheid (MPU), die de toegankelijke geheugenregio beperkt en foutuitzonderingen activeert bij toegangschending. Normaal worden interne randapparaten in het geheugen gemapt, zodat een MPU kan worden gebruikt om ook de toegang tot randapparaten te beperken.

Taken kunnen zich in verschillende staten bevinden:

• Geblokkeerd - taak wacht op een gebeurtenis (bv. time-out voor vertraging, beschikbaarheid van gegevens/middelen)
• Klaar - taak is klaar om op CPU te draaien, maar draait niet omdat CPU in gebruik is door een andere taak
• Lopend - taak is toegewezen om op CPU te worden uitgevoerd

Scheduler

Schedulers in RTOS bepalen welke taak op de CPU moet worden uitgevoerd, en er zijn verschillende scheduling algoritmes beschikbaar. Normaal gesproken zijn ze:

• Preventief - taakuitvoering kan worden onderbroken als een andere taak met hogere prioriteit gereed is
• Coöperatief - taakomschakeling gebeurt alleen als de huidige lopende taak zichzelf opgeeft

Preventieve scheduling staat taken met een hogere prioriteit toe om een lagere taak te onderbreken om aan real-time beperkingen te voldoen, maar het gaat ten koste van meer overhead bij context switching.

Inter-taak communicatie (ITC)

Meerdere taken zullen normaliter informatie of gebeurtenissen met elkaar moeten delen. De eenvoudigste manier om te delen is door gedeelde globale variabelen rechtstreeks in RAM te lezen/schrijven, maar dit is ongewenst wegens het risico van gegevenscorruptie veroorzaakt door een "race condition". Een betere manier is het lezen/schrijven van file-scoped statische variabelen die toegankelijk zijn via setter en getter functies, en race conditions kunnen worden voorkomen door interrupts uit te schakelen of een mutual exclusion object (mutex) te gebruiken binnen de setter/getter functie. De schonere manier is het gebruik van "thread-safe" RTOS-objecten zoals een berichtwachtrij om informatie tussen taken door te geven.

Naast het delen van informatie zijn RTOS-objecten ook in staat de taakuitvoering te synchroniseren omdat taken kunnen worden geblokkeerd om te wachten op de beschikbaarheid van RTOS-objecten. De meeste RTOS hebben objecten zoals:

• Berichtwachtrij
  • FIFO-wachtrij (first-in-first-out) om gegevens door te geven
  • Gegevens kunnen worden verzonden als kopie of als referentie (pointer)
  • Gebruikt om gegevens te verzenden tussen taken of tussen interrupt en taak
• Semafoor
  • Kan worden behandeld als een referentieteller om de beschikbaarheid van een bepaalde hulpbron te registreren
  • Kan een binaire of tellende semafoor zijn
  • Gebruikt om het gebruik van middelen te bewaken of taakuitvoering te synchroniseren
• Mutex
  • Vergelijkbaar met binaire semafoor, over het algemeen gebruikt om het gebruik van een enkele bron te bewaken (MUTual EXclusion)
  • FreeRTOS-mutex komt met een prioriteit overervingsmechanisme om prioriteit inversie (conditie wanneer taak met hoge prioriteit eindigt met wachten op taak met lagere prioriteit) probleem te vermijden.
• Mailbox
  • Eenvoudige opslagplaats om een enkele variabele te delen
  • Kan beschouwd worden als een wachtrij met één element
• Evenementengroep
  • Groep voorwaarden (beschikbaarheid van semafoor, wachtrij, gebeurtenisvlag, enz.)
  • Taken kunnen worden geblokkeerd en kunnen wachten tot aan een specifieke combinatievoorwaarde is voldaan
  • Beschikbaar in Zephyr als Polling API, in FreeRTOS als QueueSets

Systeemtik

RTOS heeft een tijdbasis nodig om de tijd te meten, normaal gesproken in de vorm van een systeemtikteller-variabele die wordt opgehoogd in een periodieke hardware-timeronderbreking. Met systeemtikken kan een toepassing meer dan op tijd gebaseerde diensten onderhouden (taakuitvoeringsinterval, wachttime-out, time slicing) met slechts één hardwaretimer. Een hogere tikfrequentie zal echter alleen de RTOS-tijdbasisresolutie verhogen, het zal de software niet sneller laten werken.

Waarom RTOS gebruiken

Organisatie

Toepassingen kunnen altijd op een bare metal manier worden geschreven, maar naarmate de complexiteit van de code toeneemt, zal het hebben van een of andere structuur helpen bij het beheren van verschillende delen van de toepassing, door ze gescheiden te houden. Bovendien, met een gestructureerde manier van ontwikkelen en een vertrouwde ontwerptaal, kan een nieuw teamlid de code begrijpen en sneller beginnen bij te dragen. RFCOM Technologies heeft toepassingen ontwikkeld met verschillende microcontrollers zoals Texas Instruments' Hercules, Renesas' RL78 en RX, en STMicroelectronics' STM32 op een ander RTOS. Vergelijkbare ontwerppatronen maken het mogelijk toepassingen te ontwikkelen op verschillende microcontrollers en zelfs op een verschillend RTOS.

Modulariteit

Verdeel en heers. Door functies in verschillende taken te scheiden, kunnen nieuwe functies gemakkelijk worden toegevoegd zonder andere functies te breken; op voorwaarde dat de nieuwe functie gedeelde bronnen zoals de CPU en randapparatuur niet overbelast. Ontwikkeling zonder RTOS zal normaal gesproken in een grote oneindige lus zijn waar alle functies deel van uitmaken. Een wijziging van een functie binnen de lus zal gevolgen hebben voor andere functies, waardoor de software moeilijk te wijzigen en te onderhouden is.

Communicatiestacks en drivers

Veel extra drivers of stacks zoals TCP/IP, USB, BLE-stacks, en grafische bibliotheken worden ontwikkeld/geporteerd voor/naar bestaande RTOS'en. Een applicatieontwikkelaar kan zich concentreren op een toepassingslaag van de software en de time-to-market aanzienlijk verkorten.

Tips

Statische toewijzing

Het gebruik van statische geheugentoewijzing voor RTOS-objecten betekent het reserveren van een geheugenstapel in RAM voor elk RTOS-object tijdens het compileren. Een voorbeeld van een statische toewijzingsfunctie in freeRTOS is xTaskCreateStatic(). Dit zorgt ervoor dat een RTOS-object met succes kan worden aangemaakt, waardoor de rompslomp van het afhandelen van een mogelijk mislukte toewijzing wordt bespaard en de toepassing deterministischer wordt.

Om te bepalen welke stackgrootte nodig is voor een taak, kan de taak worden uitgevoerd met een grotere (meer dan voldoende) stackgrootte en kan het stackgebruik in runtime worden gecontroleerd om de hoogwaterlimiet te bepalen. Er is ook een statisch stack analyse gereedschap beschikbaar.

Abstractie-laag van het besturingssysteem (OSAL) en betekenisvolle abstractie

Net als de Hardware Abstraction Layer (HAL) maakt het gebruik van de RTOS-abstractielaag het mogelijk om toepassingsprogrammatuur gemakkelijk te migreren naar andere RTOS'en. De eigenschappen van RTOSs zijn redelijk gelijk, dus het maken van OSAL zou niet al te ingewikkeld moeten zijn. Bijvoorbeeld:

De freeRTOS API rechtstreeks gebruiken:

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

De RTOS API in OSAL verpakken:

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

gebruik van de abstractielaag voor inter-taak communicatie om code leesbaarder te maken en de reikwijdte van een RTOS object te minimaliseren:

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

Bovendien stelt de abstractie een programmeur ook in staat om het RTOS-object dat eronder wordt gebruikt te veranderen (b.v. van mutex naar tellende semafoor) als er meer dan één SPI-module beschikbaar is. OSAL en andere abstractielagen helpen ook bij het testen van software door het vereenvoudigen van het invoegen van nepfuncties tijdens het testen van eenheden.

Selectie tikinterval

Idealiter is een lagere tikfrequentie beter vanwege minder overhead. Om een geschikte tikfrequentie te selecteren, kan de ontwikkelaar timingbeperkingen van modules in een toepassing oplijsten (herhalingsinterval, timeout-duur, enz.). Als er enkele uitschietende modules zijn die een klein interval nodig hebben, kan een speciale timeronderbreking worden overwogen voor de uitschietende modules in plaats van de RTOS tikfrequentie te verhogen. Indien de hoogfrequente functie zeer kort is (b.v. schrijven naar een register om een LED aan of uit te zetten), kan zij worden uitgevoerd in een Interrupt Service Routine (ISR), anders kan uitgestelde interrupt-afhandeling worden gebruikt. Uitgestelde onderbreking afhandeling is een techniek om onderbreking berekening uit te stellen naar een RTOS taak, de ISR zal alleen een gebeurtenis genereren via het RTOS object, dan zal de RTOS taak gedeblokkeerd worden door de gebeurtenis en de berekening uitvoeren.

Tikonderdrukking voor toepassing met laag vermogen

Tikloze ruststand schakelt de tikonderbreking uit als het systeem langere tijd in rust gaat. Een belangrijke manier voor ingebedde firmware om het stroomverbruik te verminderen is het systeem zo lang mogelijk in de spaarstand te zetten. Tikloze ruststand wordt geïmplementeerd door de periodieke tikonderbreking uit te schakelen en dan een afteltimer in te stellen om te onderbreken wanneer een geblokkeerde taak uitgevoerd moet worden. Als er geen taak wacht op een time-out, kan de tikonderbreking voor onbepaalde tijd worden uitgeschakeld totdat een andere onderbreking optreedt (b.v. knop ingedrukt). Bijvoorbeeld, in het geval van een Bluetooth Low Energy (BLE) baken, kan de MCU in diepe slaap worden gebracht tussen de reclame-interval. Zoals in Afbeelding 1 te zien is, wordt het baken het grootste deel van de tijd in de diepe slaapstand gezet, waarbij tientallen µA stroom wordt verbruikt.

Afbeelding 1: Stroomverbruik van een BLE-baken (Afbeelding bron: RFCOM)

Conclusie

Een RTOS biedt functies als scheduler, taken, en inter-task communicatie RTOS-objecten, alsmede communicatiestacks en drivers. Ontwikkelaars kunnen zich concentreren op de toepassingslaag van de embedded software, en gemakkelijk en snel multitasking software ontwerpen. Maar net als elk ander tool moet het op de juiste manier worden gebruikt om meer waarde op te leveren. Om veilige, beveiligde en efficiënte embedded software te maken, moeten ontwikkelaars weten wanneer ze RTOS-functies moeten gebruiken en ook hoe ze RTOS moeten configureren.