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