Przenośne i do wbudowania

Systemy czasu rzeczywistego są źródłem rozwiązań, z których korzystają producenci oprogramowania dla platform przenośnych i aplikacji osadzonych (embedded).

Systemy czasu rzeczywistego są źródłem rozwiązań, z których korzystają producenci oprogramowania dla platform przenośnych i aplikacji osadzonych (embedded).

Przenośne i do wbudowania

System operacyjny QNX o architekturze mikrokernelowej

Trudno jednoznacznie zdefiniować, czym jest system czasu rzeczywistego. Przyjmuje się, że algorytmy działające w czasie rzeczywistym są poprawne wtedy, gdy nie tylko dają prawidłowy wynik przy zadanych kryteriach parametrów wejściowych, ale wynik ten jest jednocześnie wyznaczany w ściśle określonym oknie czasowym.

Najbardziej znanym systemem czasu rzeczywistego (RTS) jest QNX. Pierwsza jego wersja pojawiła się w 1981 r. Najnowsza to QNX Neutrino RTOS 6.2.

QNX jest systemem operacyjnym o architekturze mikrokernelowej. Dzięki temu jądro systemu jest bardzo małe i w pełni odpowiada za interakcję ze sprzętem (nie dochodzi do sytuacji, w których sterownik bezpośrednio komunikuje się z urządzeniem - zawsze w odwołaniu pośredniczy mikrokernel).

QNX jest w pełni zgodny z POSIX. Można go dowolnie skalować - minimalne wymaganie to ok. 64 KB pamięci. Mimo tak małej ilości pamięci, w systemie są zaimplementowane wszystkie standardy RTOS opracowane w ramach POSIX - wątki, mutexy, sygnały, algorytmy dzielenia czasu itp.

QNX to jednocześnie biblioteka aplikacji usługowych - dostępne są np. microGUI, klient Citrix, olbrzymia liczba bibliotek dla programistów i różnych kompilatorów.

Interfejs microGUI pozwala na elastyczny wybór składników. Konfiguracja z systemem okienkowym, przeglądarką WWW, programem do obsługi poczty i systemem plików dostosowanym do pamięci flash wymaga 2 MB ROM i 2 MB RAM.

Linux i Windows na małym ringu

Na początku grudnia ub.r. na Uniwersytecie Bostońskim odbyła się konferencja poświęcona zastosowaniom Linuxa w systemach czasu rzeczywistego. Została zorganizowana przy współudziale Real Time Linux Foundation. Celem, jaki postawiła sobie część środowisk linuxowych, jest stworzenie odmiany kernela Linuxa, który mógłby obsługiwać procesy zachodzące w czasie rzeczywistym. Na razie są to głównie prace teoretyczne.

Przykładem systemu czasu rzeczywistego bazującego na programowaniu open source jest LynxOS 4.0. To system w pełni zgodny z POSIX, który dodatkowo zachowuje binarną kompatybilność z aplikacjami linuxowymi (działającymi na jądrze 2.4.x i wykorzystującymi glibx 2.2.2). LynxOS 4.0 obsługuje do 256 poziomów priorytetów i umożliwia wybór strategii rozdzielania zadań, zgodnie z wymaganiami urządzenia. Obsługuje niemal te same urządzenia co Linux.

Windows CE.Net 4.1 jest najnowszym systemem operacyjnym czasu rzeczywistego opracowanym przez Microsoft. W przeciwieństwie do QNX nie jest to system oparty na architekturze stricte mikrokernelowej. Główną cechą, która sprawia, że zalicza się go do RTOS, jest inny mechanizm obsługi przerwań. Pozwala bowiem określić maksymalny i minimalny czas między zgłoszeniem przerwania a uruchomieniem procedury obsługi przerwania o danym priorytecie. Równocześnie mechanizm kolejkowania zadań jest deterministyczny. Obsługę przerwań podzielono na dwa etapy ISR - proces zgłoszenia przerwania i IST - właściwy wątek obsługi przerwania. Manipulując priorytetami wątków, można zapewnić odpowiedni czas obsługi krytycznych przerwań. Dzięki temu jest to system, który nadaje się do sterowania urządzeniami przemysłowymi.

Warto wspomnieć, że w wielu źródłach jest przedstawiany pogląd, iż system czasu rzeczywistego powinien być systemem mikrokernelowym - jednak przykłady LynxOS, Linux RT czy Windows CE wydają się temu przeczyć. Duża część interfejsów programistycznych CE.Net przypomina zwykłe API Win32, jednak nie są one w pełni zgodne z Win32.

Na początku stycznia br. Microsoft opublikował pakiet Platform Builder do budowy własnych obrazów CE.Net, dostosowanych do danej platformy sprzętowej (CE.Net obsługuje ponad 100 różnych procesorów, ale nie ma już wśród nich Power PC). Nowym, dosyć istotnym elementem Platform Builder jest mechanizm automatycznego testowania docelowego obrazu - czy to na platformie testowej BSP, czy też w emulatorze.

Podczas wyboru poszczególnych komponentów można podać zestaw testów (duża ich część jest już przygotowana), które sprawdzą, czy dana konfiguracja będzie działać zgodnie z zamierzeniami. W podobny sposób można także testować, czy na pewno aplikacja, która ma działać na danym systemie, będzie mieć do dyspozycji niezbędne API. Rozbudowano mechanizmy zdalnego śledzenia i monitorowania instalacji CE.Net.


TOP 200