Reaaliaikakäyttöjärjestelmät (RTOS) ja niiden sovellukset

Mikä on RTOS?

Reaaliaikakäyttöjärjestelmä (RTOS) on kevyt OS, jolla helpotetaan moniajoa ja tehtävien integrointia resurssi- ja aikarajoitteisissa toteutuksissa, mitä sulautetut järjestelmät normaalisti ovat. Lisäksi käsite ”reaaliaikainen” viittaa raa’an nopeuden sijasta ennakoitavuuteen/determinismiin suoritusajassa. Näin ollen RTOS normaalisti täyttää todistetusti determinisminsä ansiosta kovat reaaliaikavaatimukset.

RTOS-pääkonsepteja ovat:

Tehtävä

Tehtävät (voidaan kutsua myös prosesseiksi/säikeiksi) ovat ikuisessa silmukassa suoritettavia itsenäisiä funktioita, joista kukin vastaa normaalisti yhdestä ominaisuudesta. Tehtävät ajetaan itsenäisesti käyttäen omaa suoritusaikaa (ajallinen eristys) ja muistipinoa (tilallinen eristys). Tehtävien välinen tilallinen eristys voidaan taata käyttämällä muistisuojayksikköä (MPU), joka rajoittaa käytettävissä olevan muistialueen ja käynnistää vikapoikkeuksen, jos käyttöoikeutta loukataan. Sisäiset oheislaitteet näkyvät normaalisti muistiavaruudessa, joten MPU-yksiköllä voidaan rajoittaa myös oheislaitteiden käyttöä.

Tehtävä voi olla eri tiloissa:

• Estetty – tehtävä odottaa tapahtumaa (esim. viiveen aikakatkaisu, datan/resurssien saatavuus)
• Valmis – tehtävä on valmis ajettavaksi CPU-yksikössä, mutta se ei ole ajotilassa, koska toinen tehtävä käyttää CPU-yksikköä
• Ajossa – tehtävä on asetettu ajoon CPU-yksikössä

Vuorontaja

RTOS-vuorontajat ohjaavat mikä tehtävä CPU-yksiköllä suoritetaan. Käytettävissä on erilaisia vuoronnusalgoritmeja. Ne ovat normaalisti:

• Irrottava – tehtävän suorittaminen voidaan keskeyttää, jos toinen tehtävä, jolla on korkeampi prioriteetti, on valmis
• Ei-irrottava (yhteistyö) – tehtävä vaihdetaan vain jos nykyinen käynnissä oleva tehtävä sallii sen

Irrottava vuoronnus sallii sen, että korkeamman prioriteetin tehtävä keskeyttää alhaisemman prioriteetin tehtävän reaaliaikarajoitteiden täyttämiseksi, mutta sen haittapuolena on raskaampi kontekstin vaihto.

Tehtävien välinen kommunikointi (ITC)

Moniajo edellyttää normaalisti informaation tai tapahtumien jakoa tehtävien kesken. Yksinkertaisin tapa jakaa on lukea/kirjoittaa globaaleja muuttujia suoraan RAM-muistista, mutta tämä ei ole suositeltavaa kilpailutilanteesta aiheutuvan datan korruptoitumisriskin vuoksi. Parempi tapa lukea/kirjoittaa tiedostotyyppisiä staattisia muuttujia on käyttää asetus- ja hakufunktioita. Kilpailutilanteet voidaan estää kieltämällä keskeytykset tai käyttämällä asetus/hakufunktion sisällä yhteistä poissulkuobjektia (mutex). Siistimpi tapa tehtävien välisen informaation siirtoon on käyttää säieturvallisia RTOS-objekteja kuten viestijonoa.

Informaation jakamisen ohella RTOS-objektit voivat myös synkronoida tehtävien suorittamisen, koska tehtävät voidaan asettaa odottamaan RTOS-objektien saantia. Useimmilla RTOS-järjestelmillä on sellaisia objekteja kuten:

• Viestijono
  • FIFO (First-In-First-Out) -jono datan siirtoa varten
  • Data voidaan lähettää kopiona tai viitteenä (osoitin)
  • Käytetään datan lähettämiseen tehtävien välillä tai keskeytyksen ja tehtävän välillä
• Semafori
  • Voidaan käyttää referenssilaskurina tietyn resurssin saatavuuden hallitsemiseksi
  • Voi olla binäärinen tai laskeva semafori
  • Käytetään resurssien käytön suojaamiseen tai tehtävien synkronointiin
• Mutex
  • Binäärisen semaforin kaltainen, käytetään yleensä yksittäisen resurssin käytön suojaamiseen (MUTual EXclusion)
  • FreeRTOS mutex sisältää prioriteetin perintämekanismin, jotta vältetään prioriteetin inversio-ongelma (tilanne, jossa korkean prioriteetin tehtävä joutuu odottamaan alhaisemman prioriteetin tehtävää).
• Postilaatikko
  • Yksinkertainen tallennuspaikka yksittäisen muuttujan jakamista varten
  • Voidaan ajatella yksittäiseksi elementtijonoksi
• Tapahtumaryhmä
  • Joukko ehtoja (semaforin, jonon, tapahtumalipun yms. saatavuus)
  • Tehtävä voidaan asettaa estotilaan odottamaan tietyn yhdistelmäehdon täyttymistä
  • Käytettävissä Zephyrissä pollaus-API-rajapintana ja FreeRTOS:ssa muodossa QueueSets

Järjestelmän aikalaskuri

RTOS tarvitsee tavan ajan mittaukseen. Tähän käytetään normaalisti järjestelmän aikalaskurimuuttujaa, jota kasvatetaan laitteiston kellokeskeytyksessä. Järjestelmän aikalaskurin ansiosta sovellus voi ylläpitää useampia aikapohjaisia palveluita (tehtävien suoritusväli, odotuksen aikakatkaisu, aikaviipalointi) käyttäen yhtä ainutta laitteistoajastinta. Korkeampi laskurinopeus lisää kuitenkin vain RTOS-järjestelmän aikapohjaista resoluutiota, se ei nopeuta ohjelmiston suoritusta.

Miksi käyttää RTOS-järjestelmää

Organisointi

Sovellukset voidaan aina kirjoittaa suoritettavaksi suoraan raudan päällä, mutta koodin kompleksisuuden kasvaessa jonkinlainen rakenne auttaa sovelluksen eri osien hallinnassa ja pitämisessä erillään. Lisäksi uusi tiimin jäsen voi strukturoidun kehitystavan ja tutun suunnittelukielen ansiosta ymmärtää koodin ja alkaa töihin nopeammin. RFCOM Technologies on kehittänyt sovelluksia käyttämällä eri mikrokontrollereita, kuten Texas Instruments Hercules, Renesas RL78 ja RX sekä STMicroelectronics STM32, ja eri RTOS-järjestelmiä. Samankaltaiset suunnittelumallit mahdollistavat sovellusten kehittämisen eri mikrokontrollereita ja jopa eri RTOS-järjestelmiä varten.

Modulaarisuus

Hajota ja hallitse. Uusia toimintoja voidaan lisätä helposti muita ominaisuuksia rikkomatta erottamalla ominaisuudet eri tehtäviin. Edellytyksenä on, ettei uusi ominaisuus ylikuormita jaettuja resursseja kuten CPU ja oheislaitteet. Ohjelmistokehitys ilman RTOS-järjestelmää tarkoittaa normaalisti isoa päättymätöntä silmukkaa, jossa kaikki ominaisuudet ovat silmukan osia. Minkä tahansa silmukan ominaisuuden muutos vaikuttaa muihin ominaisuuksiin, minkä vuoksi ohjelmiston muokkaus ja ylläpito on hankalaa.

Kommunikaatiopinot ja -ohjaimet

Monia ylimääräisiä ohjaimia ja pinoja, kuten TCP/IP-, USB-, BLE-pinot ja grafiikkakirjastot, on kehitetty/portattu nykyisiä RTOS-järjestelmiä varten. Sovelluskehittäjä voi nyt keskittyä ohjelmistossa sovellustasoon ja nopeuttaa huomattavasti tuotteen saamista myyntiin.

Vinkkejä

Staattinen allokointi

Muistin staattinen allokointi RTOS-objekteja varten tarkoittaa, että RAM-muistista varataan käännösaikana muistipino jokaista RTOS-objektia varten. Esimerkki staattisesta freeRTOS-allokointitoiminnosta on xTaskCreateStatic(). Tämä takaa, että RTOS-objektin luonti onnistuu, ja säästää vaivalta, jonka mahdollisen epäonnistuneen allokoinnin käsittely aiheuttaa. Tämä tekee sovelluksesta deterministisemmän.

Kun halutaan päättää pinokoko tehtävää varten, tehtävää voidaan suorittaa ylisuurella (enemmän kuin riittävällä) pinokoolla ja sitten pinon kulutusta voidaan seurata ajoaikana maksimaalisen muistikulutuksen määrittelemiseksi. Saatavilla on myös staattinen pinoanalyysityökalu.

Käyttöjärjestelmän abstraktiotaso (OSAL) ja merkityksellinen abstraktio

Aivan kuten laitteiston abstraktiotason (HAL), myös RTOS-abstraktiotason käyttö mahdollistaa sovellusohjelmiston helpon muunnon muihin RTOS-järjestelmiin. RTOS-järjestelmien toiminnot ovat melko samankaltaisia, joten OSAL-kerroksen luonnin ei pitäisi olla liian monimutkaista. Esimerkiksi:

freeRTOS API-rajapinnan suora käyttö:

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

RTOS API-rajapinnan peittäminen OSAL-kerroksella:

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

abstraktiotason käyttö tehtävien väliseen kommunikointiin lisää koodin luettavuutta ja minimoi RTOS-objektin näkysyysalueen:

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

Lisäksi abstraktio mahdollistaa sen, että ohjelmoija voi vaihtaa alla käytettävää RTOS-objektia (esim. Mutexista laskevaan semaforiin), jos käytettävissä on useampia SPI-moduuleja. OSAL ja muut abstraktiotasot auttavat myös ohjelmiston testauksessa helpottamalla testifunktion liittämistä yksikkötestauksen aikana.

Aikaintervallin valinta

Alhaisempi laskurinopeus on periaatteessa parempi koska se on kuormittaa järjestelmää vähemmän. Kehittäjä voi listata moduulien ajoitusrajoitteet sovellukseen (toistumisväli, aikakatkaisun kesto yms.) sopivan laskurinopeuden valitsemiseksi. Jos järjestelmässä on lyhyempiä aikavälejä edellyttäviä ulkopuolisia moduuleita, ulkopuolisille moduuleille voidaan harkita dedikoidua ajastinkeskeytystä RTOS-aikalaskurin muuttamisen sijasta. Jos usein toistuva toiminto on hyvin lyhyt (esim. kirjoitus rekisteriin ledin kytkemiseksi päälle/pois), se voidaan suorittaa keskeytysrutiinissa (Interrupt Service Routine, ISR). Muutoin voidaan käyttää viivästettyä keskeytyskäsittelyä. Viivästetty keskeytyskäsittely on tekniikka, jolla keskeytyksen käsittely siirretään RTOS-tehtävään. ISR luo vain tapahtuman RTOS-objektin kautta, sen jälkeen tapahtuma vapauttaa RTOS-tehtävän ja suorittaa laskennan.

Aikalaskurin ohitus vähävirtaisissa sovelluksissa

Jos järjestelmä on valmiustilassa pidemmän aikaa, kellokeskeytys voidaan deaktivoida. Yksi merkittävä tapa, jolla sulautettujen ohjelmistojen virrankulutusta voidaan laskea, on kytkeä järjestelmä mahdollisimman pitkäksi aikaa virransäästötilaan. Järjestelmäaikaa päivittämätön valmiustila toteutetaan deaktivoimalla jaksottaisen kellokeskeytys ja asettamalla sitten ajastimeen keskeytys, kun estotilassa oleva tehtävä on määrä suorittaa. Ellei yksikään tehtävä odota aikakatkaisua, kellokeskeytys voidaan deaktivoida määrittelemättömäksi ajaksi, kunnes tapahtuu seuraava keskeytys (esim. painiketta painetaan). Esimerkiksi Bluetooth Low Energy (BLE) -majakan tapauksessa MCU voidaan asettaa mainostapahtumien välissä syvään lepotilaan. Kuten kuvasta 1 näkyy, majakka on asetettu syvään lepotilaan suurimman osan ajasta, jolloin se kuluttaa sähköä vain muutamia kymmeniä mikroampeereita.

Kuva 1: BLE-majakan virrankulutus (virranlähde: RFCOM)

Yhteenveto

RTOS tarjoaa sellaisia toimintoja kuten vuorontaja, tehtävät ja tehtävien väliset RTOS-kommunikaatio-objektit sekä kommunikaatiopinot ja -ohjaimet. Kehittäjät voivat sen ansiosta keskittyä sulautetun ohjelmiston sovellustasoon ja suunnitella moniajo-ohjelmistoja helposti ja nopeasti. Sitä on kuitenkin käytettävä oikein jotta siitä saisi lisäarvoa, kuten mitä tahansa muuta työkalua. Jotta kehittäjät voivat luoda turvallisen, varman ja tehokkaan upotetun ohjelmiston, heidän täytyy tietää, milloin käyttää RTOS-ominaisuuksia ja myös miten konfiguroida RTOS.