Välja rätt RTOS och mikrostyrenhetsplattform för sakernas internet

Att utveckla en IoT-enhet kan vara mer utmanande än många utvecklare eller företag inser. Bara att ansluta ett inbäddat system till molnet ökar systemets timingkomplexitet betydligt. Ökad timingkomplexitet innebär att utvecklarna behöver ett bättre sätt att hantera hur deras programvara beslutar vilken kod som ska köras när. Det bästa sättet att undvika att skriva anpassade schemaläggares eller hantera timingen på ren metallnivå är att istället använda ett realtidsoperativsystem (RTOS) för att hjälpa oss att hantera timingkomplexiteter.

En utmaning med att använda ett RTOS idag är att många utvecklare kommer från en ren metallmiljö utan operativsystem (OS) och att välja rätt RTOS för en given tillämpning kan vara utmanande. En snabb undersökning av RTOS-marknaden online visar att det finns över 100 RTOS tillgängliga som användarna kan använda och som varierar från öppen källkod till certifierade kommersiella RTOS. Så hur väljer man ett RTOS och kommer igång?

I den här artikeln ska vi gå igenom hur man utvärderar vilken RTOS som är bäst för din tillämpning och sedan undersöka utvecklingsplattformar från STMicroelectronics och Renesas som kan användas för att komma igång.

Faktorer att överväga när du väljer RTOS

Realtidsoperativsystem utgör grunden som utvecklarna bygger sin programkod på. Att välja rätt RTOS är kritiskt för att säkerställa att tillämpningen byggs på en stadig och beprövad grund. Ofta baseras dock RTOS-valet på en enda parameter: kostnad.

Kostnaden är en viktig faktor, men den bör inte vara den enda. Ett utvecklingsteam kan utan problem lägga tio gånger kostnaden för ett kommersiellt RTOS om de har svårt att ansluta, implementera eller saknar stöd för det RTOS de väljer, för att inte tala om den tid som kan tappas i projektet. I allmänhet finns det åtta olika kategorier som ett utvecklingsteam bör tänka på när de väljer ett RTOS för sin tillämpning. Dessa är:

• Juridiskt ansvar och exponering
• Prestanda
• Funktioner
• Kostnad
• Ekosystem
• Mellanprogramvara
• RTOS-återförsäljare
• Tekniska preferenser

Inom varje kategori kan det finnas flera kriterier som ska utvärderas för varje RTOS. I kategorin juridiskt ansvar, till exempel, kan teamen behöva ta hänsyn till följande:

• RTOS-överträdelseansvar
• Skadeersättning
• Garanti
• Behovet av att granska RTOS ur juridisk synvinkel

I prestandakategorin kan utvecklarna tänka på följande:

• Körbar minnesyta
• RAM-yta
• Högsta graden av determinism
• Körtidseffektivitet

Varje huvudkategori kan undersökas av utvecklings- och ledningsgruppen för att avgöra vilka kriterier som RTOS ska utvärderas för. När kriterierna har valts kan flera olika RTOS utvärderas med en Kepner-Tregoe-matris (KT). Det här är en rationell modell för beslutsfattande som hjälper till att samla in, prioritera och utvärdera information med betoning på bedömning och prioritering av risk. Det avlägsnar partiskhet i beslutsfattandeprocessen och hjälper dig att komma fram till det bästa möjliga valet, med minimala negativa konsekvenser. Nu ska vi i undersöka hur vi kan använda en KT-matris för att välja ett RTOS.

Använda en KT-matris för att välja ett RTOS.

KT-matrisen för RTOS-val kan ställas in enligt figur 1 och figur 2. Idén är att för varje urvalskategori så identifierar vi våra urvalskriterier och listar dem i en kolumn. Vi kan identifiera en vikt för varje kriterium som visar hur viktigt det kriteriet är för oss på en skala från 1 och 5, där 5 är mycket viktigt (t.ex. kostnad) och 1 är inte så viktigt (t.ex. juridiskt ansvar). Kolumner kan sedan skapas för varje medlem i teamet för att ranka hur viktigt varje kriterium är för varje RTOS som undersöks. Varje kriterium kan sedan viktas, summeras och ett opartiskt, numeriskt resultat genereras. RTOS med det högsta värdet är det RTOS som uppfyller kriterierna bäst.

Figur 1: Den övre halvan av KT-matrisen för RTOS-urval. Detta innefattar utvärdering av ansvarsexponering, RTOS-prestanda, egenskaper och kostnad. (Bildkälla: Beningo Embedded Group)

Figur 2: Den nedre halvan av KT-matrisen för RTOS-urval, som innefattar utvärdering av ekosystemet, mellanprogramvara, återförsäljare och verksamhet. (Bildkälla: Beningo Embedded Group)

Exemplen i figur 1 och 2 är ganska omfattande i antalet kriterier som utvärderas. Det är förmodligen utöver vad de flesta utvecklingsteam är intresserade av att utvärdera, men antalet kriterier kan enkelt tas bort genom att ställa in vikten på 0 eller dölja raden i kalkylbladet.

Plattformar som RTOS-utvecklingen kan startas på

Ett område där utvecklarna kan få kämpa med att utvärdera ett RTOS är när det gäller att avgöra om det uppfyller de ställda prestanda- och kapacitetskraven. I många fall kan utvecklarna inte vara säkra om de inte gör en grundlig utvärdering och smutsar ner händerna genom att använda RTOS:et. Det visar sig att ett extremt enkelt och billigt sätt att utvärdera och testa ett RTOS är att utnyttja en befintlig utvecklingsplattform som använder det. Vi ska titta på några plattformar med stöd för de populära FreeRTOS- och Express Logics ThreadX-operativsystemen med öppen källkod.

Den första plattformen som vi ska undersöka är STMicroelectronics STM32Cube-plattform. STM32Cube-plattformen har stöd för FreeRTOS som en del av STMicroelectronics STM32CubeMx- och STM32CubeIDE-utvecklingsmiljöer. Dessa verktyg gör det möjligt för utvecklaren att aktivera FreeRTOS genom att markera kryssrutan FreeRTOS och därefter använda ett FreeRTOS-konfigurationsverktyg för att ställa in alla konfigurationsvärden i det. Det gör det möjligt för utvecklarna att komma igång med FreeRTOS mycket snabbt så att de kan börja utvärdera dess funktioner och prestandaegenskaper.

Med the STMicroelectronics verktygskedja finns det många olika utvecklingskort att välja mellan. Ett av de beprövade utvecklingskorten som har varit mycket populärt under lång tid är STM32F429 Discovery board (STM32F429I-DISC1) (figur 3).

STM32F429 är en Arm^® Cortex^®-M4-processorer som kan köras med frekvenser upp till 168 megahertz (MHz). Mikrostyrenheten stödjer 2 megabyte flash och 256 kilobyte SRAM, vilket är tillräckligt mycket kod och minne för att utveckla en relativt avancerad tillämpning. Utvecklingskortet inkluderar även en LCD, flera LED-lampor och ett utökningsbart I/O.

Figur 3: STM32F429I Discovery-kortet är ett billigt utvecklingskort som använder en Arm Cortex-M4-processor för att ge utvecklare som vill utvärdera ett RTOS rejält med processorkraft. (Bildkälla: STMicroelectronics)

För utvecklare som arbetar med RTOS-baserade IoT-kantenheter som också kan behöva utföra maskininlärning är STM32F7 Discovery-kortet (STM32F746G-DISCO) ett bättre val (figur 4). STM32F7 Discovery-kortet baseras på en Arm Cortex-M7-processor, som inkluderar cacheminne, kan köras på klockfrekvenser upp till 216 MHz och inkluderar 1 Mbyte flash och 340 kbyte SRAM. Utvecklingskortet inkluderar även en 4,3-tums display med 480 x 272 pixlar, Ethernet, SD-kortplats, USB-, mikrofon- och högtalaranslutningar med mera.

Figur 4: STM32F746G Discovery-kortet är ett billigt utvecklingskort som använder en Arm Cortex-M7-processor så att utvecklare inte bara kan utvärdera ett RTOS, utan även eventuella maskininlärningsslutsatser som de kan tänkas behöva i sin IoT-kantenhet. (Bildkälla: STMicroelectronics)

Ett sista utvecklingskort som bör övervägas är STM32L0 Nucleo-kortet (NUCLEO-L073RZ) (figur 5). STM32L0 Nucleo baseras på Arm Cortex-M0+, som är utformat för lägsta möjliga energiförbrukning, vilket gör det perfekt för batteridrivna IoT-kantenheter med låg strömförbrukning. STM32L0-mikrostyrenheten kan köras med klockfrekvenser upp till 24 MHz och inkluderar 192 kbyte flashminne och 20 kbyte SRAM. Detta är mycket nära minimikraven som man kan vilja ha om man ska köra ett RTOS. Utvecklingskortet är avskalat med bara en användarswitch och en LED.

Figur 5: Utvecklingskortet NUCLEO-L073RZ STM32L0 baseras på en Arm Cortex-M0+-processor som är utformad för att ge hög prestanda till enheter med låg strömförbrukning. (Bildkälla: STMicroelectronics)

Den andra plattformen som vi ska undersöka är Renesas Synergy™-plattform. Den är unik i den inbäddade branschen genom att den levereras med omfattande tredjepartsprogramvara och utvecklingsverktyg för etablerade leverantörer.

Om någon exempelvis skulle använda ett utvecklingskort från STMicroelectronics och ville använda Express Logics ThreadX RTOS med IAR Systems Embedded Workbench-kompilator och utvecklingsmiljö skulle de behöva kontakta IAR för kompilatorn och Express Logic för RTOS och köpa licenser för att använda dem. Om utvecklarna däremot bara köper en enskild mikrostyrenhet som är del av Renesas Synergy-plattform får de automatiskt dessa verktyg och RTOS att arbeta med utöver övrig mellanprogramvara.

För utvecklare som vill testa ThreadX på en högkapacitetsprocessor är Renesas Synergy SK-S7G2 utvecklingskort (YSSKS7G2E30) ett utmärkt val (figur 6). SK-S7G2 baseras på en Arm Cortex-M4-processor som kan köras på 240 MHz och inkluderar 3 Mbyte flash och 640 kbyte RAM. Det här utvecklingskortet är välfyllt och inkluderar en LCD, flera LED-lampor, I/O-expansion, CAN, PMOD-expansion och enkel åtkomst till serieportar och ytterligare I/O.

Figur 6: Renesas Synergy SK-S7G2 utvecklingskort levereras med kommersiella utvecklingsverktyg som inkluderar Express Logic ThreadX RTOS. ((Bildkälla: Renesas)

Ett alternativt utvecklingskort som kan användas för att testa ThreadX är Renesas Synergy TB-S5D5 (YSTBS5D5E10) (figur 7). TB-S5D5-kortt är ett billigt utvecklingskort som inkluderar en Arm Cortex-M4-processor med klockfrekvensen 120 MHz med 1 Mbyte flash och 384 kbyte SRAM. Utvecklingskortet har minimala funktioner för att minimera kostnaderna. Det inkluderar en användarknapp, kapacitiv beröring och en LED-lampa.

Figur 7: Renesas Synergy TB-S5D5 utvecklingskort ger utvecklarna 1 Mbyte kodflashminne och 384 kbyte SRAM för att testa ThreadX. ((Bildkälla: Renesas)

Andra intressanta alternativ för utvecklare, särskilt sådana som är intresserade av IoT-tillämpningar är Renesas Synergy AE-Cloud1 IoT-sats, YSAECLOUD1 (figur 8 ) och Renesas Synergy AE-Cloud2 Cellular IoT-sats, YSAECLOUD2 (figur 9).

Synergy Cloud1 IoT-satsen ger utvecklarna möjlighet att ansluta till molnet via Wi-Fi, medan Cloud2 Cellular-satsen också gör det möjligt att ansluta via ett mobilnätverk. Båda utvecklingskorten baseras på S5D9-processorn och inkluderar inbyggda sensorer och LED-lampor som kan övervakas och styras från molnet. Satserna har även förinstallerad programvara som inkluderar ThreadX och gör det möjligt för utvecklarna att testa en hel anslutningslösning med sitt RTOS. (Det kan hjälpa utvecklaren att utvärdera mellanprogramvarudelen av KT-matrisen som diskuterades ovan.)

Figur 8: Renesas Synergy AE-Cloud1 IoT-sats är ett utvecklingskort som är specifikt utformat för IoT-enheter som vill ansluta till molnet via Wi-Fi. Det innefattar förmågan att styra LED-lampor och övervaka sensorvärden från en molnleverantör som Amazon Web Services (AWS) eller Microsoft Azure. ((Bildkälla: Renesas)

Figur 9: Renesas Synergy AE-Cloud2 Cellular IoT-sats är ett utvecklingskort som är utformat för IoT-enheter som ansluter till molnet via Wi-Fi- eller mobilnätverk. Det innefattar förmågan att styra LED-lampor och övervaka sensorvärden från molnleverantörer som AWS eller Azure. ((Bildkälla: Renesas)

En viktig anmärkning om plattformar: När du utvärderar ett RTOS på en, se till att du jämför äpplen med äpplen. Om du exempelvis utvärderar FreeRTOS på STM32F429 Discovery-kortet vid 168 MHz, se till att du antingen använder samma utvecklingskort eller ett kort som körs med samma klockfrekvens när du utvärderar övriga RTOS.

Tips och trick för att använda ett RTOS

Varje RTOS har egna tips och trick, med det finns flera tumregler som kan tillämpas på RTOS generellt:

• Tilldela aktiviteter och RTOS-objekt statiskt. Att tilldela aktiviteter och objekt dynamiskt kräver användning av minnestilldelning (malloc()) som inte är deterministisk och kan orsaka problem med heap-fragmentering vilket kan leda till försämrad prestanda eller till och med systemkrasch i värsta fall.
• Ändra standardstackstorleken beroende på dina tillämpningsbehov. Många RTOS har ett standardstackvärde som är överdimensionerat för de flesta uppgifter, vilket leder till bortkastad RAM. Konfigurera standardstackstorleken manuellt, men se även till att du ställer in stackstorleken för varje aktivitet baserat på dess funktion och behov.
• Funktioner som anropas från en uppgift ska vara återanropbara. Det säkerställer att det vid funktionsanrop från flera uppgifter inte finns någon risk för att skada de andra uppgifternas data om den avbryts av en uppgift med högre prioritet.
• Använd minnesblockpooler om de är tillgängliga. En minnesblockpool är en minnespool som har deterministiskt beteende och kan användas under körtiden för att tilldela minne dynamiskt. Det är ett bättre alternativ än att använda malloc(), men de flesta operativsystem med öppen källkod inkluderar den här minneshanteringsfunktionen.
• Minimera antalet uppgifter som används i tillämpningen. Ett RTOS kan locka till att skapa många uppgifter, men att skapa uppgifter som inte är nödvändiga kan minska det tillgängliga minnet dramatiskt på grund av behovet för uppgiftskontrollblocket och det separata stackutrymme som förknippas med det.

Slutsats

Eftersom IoT driver på behovet av ökande programvarukomplexitet i inbäddade system har användningen av ett RTOS blivit ett krav för att hjälpa utvecklarna att hantera den här komplexiteten och abstrahera bort den. Tricket är dock att inte välja vilket RTOS som helst. Eftersom alla RTOS inte är desamma kan mycket tid och arbete slösas bort om RTOS:et går stick i stäv med utvecklarens syften.

Istället behöver utvecklarna använda en proaktiv metod vid RTOS-valet och noga välja ut alla olika aspekter av inte bara RTOS, utan även andra frågor som RTOS-leverantör och den support som är tillgänglig när problem uppstår. En effektiv metod är att börja med en KT-matris för att noga utvärdera aktuella RTOS och därefter köra det valda RTOS:et på mikrostyrenhetsplattformar som kan stödja det för att säkerställ att det är rätt för tillämpningen.