Systemy RTOS dostarczają specjalnie zaprojektowane rozwiązania middleware, które są dostosowane do potrzeb konkretnego systemu operacyjnego. Dostosowanie pod konkretne rozwiązanie ma za zadanie podnieść jego wydajność i możliwości. Poniższa tabela i towarzyszący jej opis zawierają przegląd możliwości RTOS-ów, takich jak FreeRTOS, ThreadX, embOS, i Zephyr. Co porównujemy? To co według nas najczęściej sprawia problem: obsługa plików, komunikacja USB, stos TCP/IP i kilka innych funkcjonalności.
Według naszych doświadczeń wsparcie middleware dla RTOSa to jedna z kluczowych rzeczy w rozwoju projektu. RTOS-y oczywiście wychodzą naprzeciw takim potrzebom i dostarczają własne, stworzone specjalnie pod swój system rozwiązania. Tabelka poniżej w skondensowany sposób przedstawia informacje, które mogą pomóc w doborze RTOS-a zależnie od wymagań projektu. Rozwinięcie kilku aspektów wraz z komentarzem znajduje się pod nią.
Poniżej przejdziemy przez najważniejsze z naszej perspektywy komponenty warstwy middleware.
File management
- Zephyr: oferuje Zephyr RTOS Virtual Filesystem Switch (VFS) – system ten zapewnia tzw. Mount points pozwalające na podpięcie pod aplikację osobnych (w tym własnych) systemów plików; repozytorium Zephyra dostarcza kilka przykładów uruchomienia takiego systemu, np. w formacie FAT;
- FreeRTOS: Oferuje FreeRTOS-Plus-FAT czyli system plików kompatybilny z FAT 12/16/32, DOS/Windows. System wciąż jest rozwijany a konfiguracja odbywa się tradycyjnie jak we FreeRTOS-ie czyli modyfikując parametry w odpowiednim pliku nagłówkowym.
- ThreadX: FileX wspiera te same formaty co FreeRTOS (FAT 12/16/32) ale oferuje też analizę poziomu zużycia pamięci FLASH w postaci dodatkowego modułu LevelX.
- embOS: Segger proponuje 4 pakiety: PRO, FAT, EFS i Storage Layer. Najbardziej zaawansowany, czyli PRO oferuje wsparcie dla FAT12/FAT16/FAT32 oraz gotowe sterowniki dla pamięci NAND i NOR FLASH. Dodatkowo dane można też zaszyfrować szyframi DES oraz AES.
FAT wiecznie żywy. Rozwiązanie Zephyra wydaję się najbardziej uniwersalne - wspiera wersje od oldschoolowego FatFs (napisany jeszcze w ANSI C89) przez bezpieczniejszego LittleFS. Rozwiązania FreeRTOS i ThreadX są tożsame.
USB
- Zephyr: Zephyr zapewnia stack dla urządzenia i wsparcie takich klas jak audio czy BT. Niestety host dostępny jest tylko w formie eksperymentalnej biblioteki – docelowo ma ona zastąpić obecną.
- ThreadX: USBX to stack oferujący wsparcie dla hosta oraz urządzenia USB, jak i opcję OTG (on-the-go). Moduł jest lekki (kod zajmuje 10,5 KB dla urządzenia i 18 KB dla hosta) oraz specjalnie przygotowany do pracy z FileX.
- embOS: Obsługa USB podzielona jest pomiędzy 2 osobne middleware’y: emUSB-Host oraz emUSB-Device. Licencja dzieli się na 2 wersje: Pro i Base. Base oferuje podstawową obsługę pamięci masowej oraz HID, z kolei Pro rozszerza ją o chociażby obsługę audio, wideo czy drukarek.
Zephyr OS i embOS dostarczają własne, zintegrowane stacki USB, co ułatwia implementację. FreeRTOS wymaga zewnętrznych rozwiązań do obsługi USB, co zapewnia elastyczność, ale może również wymagać dodatkowej pracy przy integracji. ThreadX za pośrednictwem USBX oferuje rozbudowane wsparcie USB. Brak wsparcia dla USB od ThreadX jest niemiłym zaskoczeniem.
TCP/IP
- Zephyr: Zephyr dostarcza pełny Network Stack pozwalający na pełną konfigurację – używanie dostarczonych rozwiązań, czy tez opieranie nowych na wybranych warstwach architektury. Pośród udostępnionych protokołów można wyróżnić podstawowe IPv4 czy IPv6 ale też wsparcie dla WiFi, Ethernetu, BT oraz CANa. Dostępne jest też popularne w IoT MQTT.
- FreeRTOS: Oferuje kilka osobnych bibliotek. FreeRTOS-Plus-TCP to podstawowy stack TCP/IP obsługujący IPv4 jak i IPv6, idealny dla mniejszych mikrokontrolerów. Potrzebne protokoły mogą być dodane przy użyciu osobnych bibliotek coreHTTP, coreSNTP i coreMQTT. Dodatkowo, Amazon jako właściciel FreeRTOS-a oferuje biblioteki pozwalające na integrację funkcjonalności specyficznych dla usług AWS IoT.
- ThreadX: Podstawowa, autorska biblioteka Microsoftu NetX to stack dla TCP/IP IPv4. Oferuje ona najczęściej używane protokoły, takie jak HTTP, DHCP, UDP, TCP oraz obsługę Ethernetu, WiFi i BLE. Osobno można użyć też NetX Duo który jest niejako kolejnym krokiem rozszerzającym standard o IPv6 i zabezpieczenia SSL/TLS/DTLS. Dodatkowo Duo zawiera też middleware pomiędzy ThreadX a Azure SDK używanym do obsługi serwisów Azure IoT co ułatwia ich integrację.
- embOS: emNet używany w programatorach J-Link, reklamowany jest jako baza pod aplikacje IoT – dostarcza on stack TCP/IP i protokoły takie jak UDP czy TCP na których można łatwo budować wyższe warstwy. Do działania zalecany jest oczywiście RTOS, ale możliwa jest też samodzielna praca bez niego. Dodatkowo, Segger oferuje wsparcie dla RTOS-ów innych niż ich własny. emNet dostarcza też obsługę Ethernetu i WiFi (wymaga osobnego sterownika);
Zephyr OS i embOS wyróżniają się szerokim wsparciem bibliotek i modułowością w kontekście protokołu TCP/IP. FreeRTOS zapewnia zewnętrzny moduł FreeRTOS+TCP, który można konfigurować pod specyficzne potrzeby. ThreadX, z kolei, oferuje wydajne stosy NetX i NetX Duo, które są dobrze zintegrowane z ekosystemem Microsoft, w tym Azure IoT.
Kryptografia
- Zephyr: dostarcza 2 biblioteki kryptograficzne. Pierwsza z nich to TinyCrypt dostarczająca podstawowe algorytmy takie jak SHA-256 i przeznaczona na małe urządzenia (z ograniczeniami dotyczącymi pamięci czy mocy obliczeniowej). Druga biblioteka z kolei służy do generowania liczb prawdziwie i pseudo losowych zgodnie z wymaganiami NIST (National Institute of Standards and Technology - amerykańska agencja rządowa).
- FreeRTOS: FreeRTOS oferuje corePKCS11 oparty na PKCS#11 (implementacja standardu pod FreeRTOS). Jest to API używane do manipulowania obiektami kryptograficznymi w taki sposób aby nie udostępniać ich zawartości pamięci programu (klucze prywatne, certyfikaty). Dla przykładu, biblioteka ta używana jest przez AWS przy autentykacji klucza w protokole TLS.
- embOS: emCrypt jest kryptograficzną biblioteką na podstawie której zbudowane są też inne produkty Seggera skierowane na szyfrowanie: emSSL, emSSH i emSecure. Sam emCrypt (wersja BASE) zawiera szeroką gamę najpopularniejszych algorytmów (AES-128/256 DES, 3DES, SHA-224/512).
ThreadX (a w zasadzie Eclipse ThreadX) wyróżnia się tu zdecydowanie brakiem szerszego wsparcia bibliotek kryptograficznych.
Czy to kwestia coraz tańszych mikrokontrolerów ze wsparciem sprzętowym kryptografii?
GUI
- ThreadX: GUIX dostarcza API pozwalające na standardową obsługę interfejsu graficznego, tj. rysowanie podstawowych kształtów, funkcje matematyczne, sterowniki dla popularnych wyświetlaczy, bibliotekę gotowych widżetów czy odczyt plików .jpg. Dodatkowo, Microsoft zapewnia też GUIX Studio, czyli desktopową aplikację w której można stworzyć interfejs w pełni graficznie (WYSIWYG) a następnie wygenerować na jej podstawie kod w C gotowy do użycia w aplikacji.
- embOS: emWin ma 4 wersję licencjonowania: PRO, BASE color, BASE grayscale oraz BASE b/w. PRO posiada dodatkowo chociażby opcję antyaliasingu czy obsługę widżetów, zaś reszta różni się od siebie dostępną kolorystyką. Podobnie jak GUIX, emWin także ma swoją dedykowaną aplikację pozwalającą projektować interfejs nie pisząc ani linijki kodu – AppWizard.
Brak wsparcia od Zephyra i FreeRTOSa dla graficznych bibliotek.
Tak, dobrze przeczytaliście - chcesz mieć antyaliasing w embWin-> musisz kupić odpowiednią wersję biblioteki.
Nie spotkaliśmy się do tej pory z podobnym podejściem u żadnego dostawcy biblioteki graficznej (TouchGFX, Embedded Wizard, LVGL czy Microchip Graphics Library).
W powyższej liście widać ogólną tendencję.
Szerokie wsparcie wewnątrz RTOSa (Zephyr, embOS) vs zewnętrzne moduły (freeRTOS) vs własne rozwiązania (ThreadX).
#RTOS #Zephyr #FreeRTOS #ThreadX #embOS #GoodByte