Embedded RTOS - nasze doświadczenie
March 25, 2024

Rozpoczynając rozwój aplikacji w systemie embedded, developer staje przed wyborem od czego zacząć – bare metal czy GPOS (General Purpose Operating System, np. Linux), a może RTOS (Real Time Operating System).
Czym się one różnią?

Bare metal.
Kiedyś konieczność (kto programował mikrokontrolery w pierwszej dekadzie tego wieku?). Dziś widywany przez nas w wyjątkowych rozwiązaniach:
+ bardzo mały, specjalistyczny mcu;
+ monotematyczna funkcjonalność urządzenia;

Linux.
Daje pełne wsparcie hardware i izolację od warstwy sprzętowej. Tylko aplikacyjne niebo nad nami. Koszty takiej wygody? Potrzebna względnie duża moc obliczeniowa i pamięć do postawienia sprawnego systemu. Rozwój technologiczny zaciera powoli ten argument. Zostaje drugi - albo jesteś mocny w linuxa i wiesz gdzie co i dlaczego, albo jesteś zdany na łaskę losu. Jak działa, to jest fajnie i łatwo. Jak nie działa, to czasami dojście do “dlaczego” potrafi trwać dniami czy wręcz tygodniami.

RTOS.
Rozwiązanie pośrednie. Obarczone dodatkowym narzutem pamięci i performance, akceptowalnym w dzisiejszym świecie mikrokontrolerów (gdzie wielkość pamięci wyraża się co najmniej w dziesiątkach lub setkach kB). Od prostych schedulerów do układania zadań w Round Robin po mini systemy operacyjne (np. Zephyr). Rozróżniamy soft RTOS i hard RTOS. Czym się różnią? Hard RTOS musi odpowiedzieć na zdarzenia w ściśle określonym czasie. Soft RTOS “starają się” odpowiedzieć jak najszybciej na zdarzenia, poprzez wrzucenie takiego zadania do kolejki “do wykonania”.

RTOSy rosną w siłę, co skutkuje ich rozwojem w ostatniej dekadzie (głównie soft RTOSy).

Popularność ich związana jest z kilkoma czynnikami:

  • Rozwój Mikrokontrolerów: Wraz z rosnącą dostępną ilością pamięci w mikrokontrolerach, nie musimy już martwić się o to, ile miejsca zajmuje RTOS (oczywiście w granicach rozsądku).
  • Zarządzanie Zasobami: RTOS-y często dostarczają własne mechanizmy zarządzania pamięcią i zasobami, co ułatwia pracę i zwiększa bezpieczeństwo.
  • Open Source: Wiele dostępnych RTOS-ów jest oferowanych jako oprogramowanie open source, co oznacza, że są bezpłatne i można dostosowywać ich kod źródłowy.
  • Determinizm Czasowy: Gwarancja, że system zawsze zareaguje na zewnętrzne zdarzenia w określonym czasie, jest kluczowa dla wielu zastosowań.
  • Modularność: Niektóre RTOS-y są bardzo modularne i pozwalają dostosować je do swoich potrzeb, np. Zephyr pozwala wypiąć nawet scheduler.

Wg wikipedii dostępnych na rynku RTOSów kompatybilnych z ARM Cortex-M jest aż 18.
W rzeczywistości jest ich zapewne o wiele więcej (sami kiedyś popełniliśmy mały prosty RTOSik na potrzeby malutkich 16 bitowców).

Nasze doświadczenie zawodowe skupia się wokół 4 z nich. I to o nich będzie ten cykl artykułów.
A są to:

  • FreeRTOS - własność Amazona (stworzony przez Richarda Barry’ego). Prosty RTOS z niskimi wymaganiami sprzętowymi. Niejako standard RTOS na rynku. Udostępniany na licencji MIT.
  • Zephyr - projekt open source zarządzany przez Linux Foundation. Szybko rozwijający się w ostatnich 2-3 latach. Duża modularność, wsparcie dla dużej bazy sprzętu. Udostępniany na licencji Apache 2.0.
  • ThreadX - przejęty przez Microsoft (pierwotnie Express Logic) dojrzały system (jak twierdzi Microsoft, obsługuje go 12 miliardów urządzeń). Udostępniany na licencji MIT.
  • embOS - własność firmy SEGGER. Kompatybilny z MISRA-C 2012. Certyfikowany pod standardy medyczne i automotive. Licencja komercyjna.

Odwieczne pytanie - który będzie dla naszego projektu najlepszy?
Odpowiedź doświadczonego programisty może być tylko jedna - to zależy.

Nasza konkluzja jest trochę z innego podwórka - w 70-80% projektach to nie ma większego znaczenia.
A co z pozostałymi 20-30%?

Od kiedy pamiętamy RTOSy biją się o prym lekkiego jak piórko i "zero cycle waste". W dzisiejszych czasach taka bitwa jest często bezcelowa. Naszym zdaniem najmocniej liczy się wsparcie middleware i community. I tym aspektom przyjrzyjmy w tej serii najmocniej.

A co ze stroną praktyczną? Jak wygląda porównanie ich performance?

Sprawdzimy to za pomocą 3 prostych testów:

  • pomiar czasu jaki każdemu RTOS-owi zajmuje przełączenie kontekstu między prostymi taskami;
  • okresowość samych tasków;
  • sprawdzenie ile czasu zajmuje  przełączanie kontekstu przy wychodzeniu z obsługi przerwań;

Na końcu porównamy sobie wyniki działania w prostej, aczkolwiek praktycznej aplikacji obsługującej wyświetlacz TFT i liczącej transformatę Fouriera.

#RTOS #Zephyr #FreeRTOS #ThreadX #embOS #GoodByte