Systemy operacyjne czasu rzeczywistego (RTOS) i ich zastosowania

Czym jest system operacyjny czasu rzeczywistego (RTOS)

System operacyjny czasu rzeczywistego (RTOS) jest lekkim systemem operacyjnym ułatwiającym uzyskanie wielozadaniowości i integracji zadań w projektach o ograniczonych zasobach i czasie, co zwykle ma miejsce w systemach wbudowanych. Ponadto termin „czas rzeczywisty” wskazuje raczej na przewidywalność/determinizm czasu wykonania niż na samą szybkość, dlatego też zwykle można wykazać, że RTOS spełnia surowe wymagania czasu rzeczywistego ze względu na jego determinizm.

Kluczowe koncepcje systemów RTOS to:

Zadanie

Zadania (które mogą być również nazywane procesami lub wątkami) są niezależnymi funkcjami działającymi w nieskończonych pętlach, a zazwyczaj każda z nich odpowiada za jedną funkcję. Zadania są uruchamiane niezależnie w swoim czasie (izolacja czasowa) i stosie pamięci (izolacja przestrzenna). Izolacja przestrzenna pomiędzy zadaniami może być zapewniona dzięki zastosowaniu sprzętowej jednostki ochrony pamięci (MPU), która ogranicza dostępny region pamięci i wyzwala wyjątki błędów przy naruszeniu dostępu. Zwykle wewnętrzne urządzenia peryferyjne są mapowane na pamięć, więc jednostki MPU można również używać do ograniczania dostępu do urządzeń peryferyjnych.

Zadania mogą mieć różne stany:

• zablokowane - zadanie czeka na zdarzenie (np. upływ czasu opóźnienia, dostępność danych/zasobów)
• gotowe - zadanie jest gotowe do uruchomienia na procesorze, ale nie jest uruchomione, ponieważ procesor jest zajęty przez inne zadanie
• uruchomione - zadanie jest przydzielone do wykonania na procesorze

Harmonogram

Harmonogramy w systemie RTOS kontrolują, które zadanie ma być uruchomione na procesorze. Dostępne są różne algorytmy harmonogramów. Zwykle są one:

• wywłaszczające - wykonywanie zadania może zostać przerwane, jeśli inne zadanie o wyższym priorytecie jest gotowe
• współpracujące - przełączenie zadania nastąpi tylko wtedy, gdy aktualnie działające zadanie samo ustąpi

Harmonogram wywłaszczający pozwala zadaniom o wyższym priorytecie na przerywanie zadań o niższym priorytecie, aby wywiązać się z ograniczeń czasu rzeczywistego, ale wiąże się to z dodatkowym kosztem przełączania kontekstu.

Komunikacja między zadaniami (ITC)

Poszczególne zadania muszą udostępniać sobie nawzajem informacje lub zdarzenia. Najprostszym sposobem takiej wymiany jest bezpośrednie odczytywanie/zapisywanie wspólnych zmiennych globalnych w pamięci RAM, jednak jest to niepożądane z uwagi na ryzyko uszkodzenia danych spowodowanego przez zjawisko hazardu. Lepszym sposobem jest odczytywanie/zapisywanie zmiennych statycznych przypisanych do pliku, dostępnych przez funkcje ustawiające i pobierające, a hazardowi można zapobiec przez wyłączenie przerwań lub użycie obiektu wzajemnego wykluczenia (mutex) wewnątrz funkcji ustawiającej/odczytującej. Czystszym sposobem jest użycie do przekazywania informacji między zadaniami bezpiecznych wątkowo obiektów RTOS, takich jak kolejka komunikatów.

Oprócz współdzielenia informacji, obiekty RTOS są również w stanie synchronizować wykonywanie zadań, ponieważ zadania mogą być blokowane w oczekiwaniu na dostępność obiektów RTOS. Większość systemów RTOS posiada obiekty takie jak:

• Kolejka komunikatów
  • Kolejka typu pierwszy na wejściu - pierwszy na wyjściu (FIFO) do przekazywania danych
  • Dane mogą być wysyłane jako kopia lub jako odniesienie (wskaźnik)
  • Wykorzystywana do przesyłania danych między zadaniami lub między przerwaniem i zadaniem
• Semafor
  • Może być traktowany jako licznik referencyjny do rejestrowania dostępności danego zasobu
  • Może być semaforem binarnym lub liczącym
  • Służy do ochrony wykorzystania zasobów lub synchronizacji wykonywania zadań
• Element mutex
  • Podobny do semafora binarnego, na ogół jest wykorzystywany do ochrony pojedynczego zasobu (mutex = MUTual EXclusion, czyli wzajemne wykluczenie)
  • Element mutex w systemie FreeRTOS jest wyposażony w mechanizm dziedziczenia priorytetów, aby uniknąć problemu inwersji priorytetów (stan, w którym zadanie o wysokim priorytecie oczekuje na zadanie o niższym priorytecie).
• Skrzynka pocztowa
  • Proste miejsce przechowywania do udostępniania pojedynczej zmiennej
  • Można ją uznać za jednoelementową kolejkę
• Grupa zdarzeń
  • Grupa stanów (dostępności semafora, kolejki, flagi zdarzenia itp.)
  • Zadanie można zablokować i może ono oczekiwać na wypełnienie określonego połączenia warunków
  • W systemie Zephyr dostępne jako interfejs API odpytywania, w systemie FreeRTOS jako QueueSets (zestawy kolejek)

Takt systemowy

System RTOS potrzebuje podstawy czasu do pomiaru czasu, zwykle w postaci systemowej zmiennej licznika taktów inkrementowanej w okresowym przerwaniu sprzętowego układu czasowego. Dzięki taktowi systemowemu aplikacja może zapewnić nie tylko usługi oparte na czasie (interwał wykonywania zadań, limit czasu oczekiwania, podział czasu) używając tylko jednego sprzętowego układu czasowego. Jednak wyższa częstotliwość taktów zwiększy jedynie rozdzielczość podstawy czasu systemu RTOS, ale nie sprawi, że oprogramowanie będzie działać szybciej.

Dlaczego warto korzystać z systemów RTOS

Organizacja

Aplikacje zawsze można pisać w stylu „bare-metal” (z pominięciem systemu operacyjnego), ale wraz ze wzrostem złożoności kodu posiadanie pewnego rodzaju struktury pomoże w zarządzaniu różnymi częściami aplikacji, oddzielając je od siebie. Ponadto, dzięki uporządkowanemu sposobowi rozwoju i znanemu językowi projektowania, nowy członek zespołu może szybciej zrozumieć kod i zacząć wnosić swój wkład. Firma RFCOM Technologies opracowała zastosowania z wykorzystaniem różnych mikrokontrolerów, takich jak Texas Instruments Hercules, Renesas RL78 i RX, i STMicroelectronics STM32 na innym systemie RTOS. Podobne wzorce projektowe umożliwiają nam tworzenie zastosowań na różnych mikrokontrolerach, a nawet na innym systemie RTOS.

Modułowość

Dziel i rządź. Dzięki rozdzieleniu funkcji na różne zadania można łatwo dodawać nowe funkcje bez naruszania innych funkcji, pod warunkiem, że nowa funkcja nie przeciąża współużytkowanych zasobów, takich jak procesor i urządzenia peryferyjne. Programowanie bez systemu RTOS zwykle jest wielką, nieskończoną pętlą, do której należą wszystkie funkcje. Zmiana jakiejkolwiek funkcji w obrębie pętli będzie miała wpływ na inne funkcje, co czyni oprogramowanie trudnym do modyfikacji i utrzymania.

Stosy komunikacji i sterowniki

Wiele dodatkowych sterowników lub stosów, takich jak TCP/IP, USB, stosy BLE i biblioteki graficzne są rozwijane/przenoszone do istniejących systemów RTOS. Deweloper aplikacji może skupić się na warstwie aplikacyjnej oprogramowania i znacznie skrócić czas wprowadzania produktu na rynek.

Wskazówki

Alokacja statyczna

Zastosowanie statycznej alokacji pamięci dla obiektów RTOS oznacza rezerwację stosu pamięci w pamięci RAM dla każdego obiektu RTOS w czasie kompilacji. Przykładem funkcji alokacji statycznej w systemie freeRTOS jest xTaskCreateStatic(). Zapewnia ona możliwość skutecznego utworzenia obiektu RTOS, oszczędzając kłopotów związanych z obsługą ewentualnie nieudanej alokacji i czyniąc aplikację bardziej deterministyczną.

Jeśli chodzi o określanie rozmiaru stosu potrzebnego dla zadania, zadanie może być uruchamiane z większym (więcej niż wystarczającym) rozmiarem stosu, a następnie użycie stosu może być sprawdzane w czasie wykonania, aby ustalić znacznik wysokiego poziomu. Dostępne jest również narzędzie do analizy stosu statycznego.

Warstwa abstrakcji systemu operacyjnego (OSAL) i zrozumiała abstrakcja

Podobnie, jak w przypadku warstwy abstrakcji sprzętowej (HAL), wykorzystanie warstwy abstrakcji systemu RTOS umożliwia łatwą migrację oprogramowania aplikacyjnego na inne systemy operacyjne. Funkcje systemów RTOS są całkiem podobne do siebie, dlatego utworzenie warstwy OSAL nie powinno być zbyt trudne. Na przykład:

Bezpośrednie użycie interfejsu API systemu freeRTOS:

if( xSemaphoreTake( spiMutex, ( TickType_t ) 10 ) == pdTRUE ) { //dosomething }

Opakowanie interfejsu API systemu RTOS w warstwę OSAL:

if( osalSemTake( spiMutex, 10 ) == true) { //dosomething }

wykorzystanie warstwy abstrakcji w komunikacji między zadaniami, aby poprawić czytelność kodu i ograniczyć zakres obiektu RTOS:

if( isSpiReadyWithinMs( 10 ) ) { //doSomething }

Ponadto abstrakcja umożliwia programiście zmianę obiektu RTOS użytego w niższej warstwie (np. element mutex na semafor zliczający), jeżeli dostępny jest więcej niż jeden moduł szeregowego interfejsu urządzeń peryferyjnych (SPI). OSAL i inne warstwy abstrakcji pomagają również w testowaniu oprogramowania przez uproszczenie wstawiania makiet funkcji podczas testów jednostkowych.

Wybór interwału taktu

W idealnym przypadku niższa częstość taktu jest lepsza z powodu mniejszego obciążenia ogólnego. Aby wybrać odpowiednią częstość taktu, deweloper może wypisać ograniczenia czasowe modułów w aplikacji (interwał powtarzania, długość limitu czasowego itp.). Jeśli istnieją pewne moduły odstające, które potrzebują krótkiego odstępu czasu, można rozważyć posiadanie dedykowanego przerwania układu czasowego dla modułów odstających, zamiast zwiększać częstotliwość taktu RTOS. Jeśli funkcja o wysokiej częstotliwości jest bardzo krótka (np. zapis do rejestru w celu włączenia/wyłączenia diody LED), może być wykonana wewnątrz procedura obsługi przerwania (ISR), w przeciwnym razie można zastosować odroczoną obsługę przerwań. Odroczona obsługa przerwań jest techniką przekazywania obliczania przerwania do zadania RTOS, procedura ISR generuje tylko samo zdarzenie przez obiekt RTOS, następnie zadanie RTOS zostanie odblokowane przez zdarzenie i wykona obliczenie.

Pomijanie taktów w zastosowaniach o niskiej mocy

Tryb jałowy beztaktowy wyłącza przerwanie taktu, gdy system jest bezczynny przez dłuższy czas. Jednym z istotnych sposobów na zmniejszenie zużycia energii przez wbudowane oprogramowanie układowe jest wprowadzanie systemu w tryb niskiej mocy na tak długo, jak to możliwe. Tryb jałowy beztaktowy jest realizowany przez wyłączenie okresowego przerwania taktu i ustawienie w układzie czasowym licznika odliczającego czas do przerwania, gdy ma zostać wykonane zablokowane zadanie. Jeśli nie ma żadnego zadania oczekującego na upłynięcie limitu czasowego, przerwanie taktu może być wyłączone na czas nieokreślony, dopóki nie pojawi się inne przerwanie (np. naciśnięcie przycisku). Na przykład: w przypadku emitera sygnału Bluetooth Low Energy (BLE), mikrokontroler MCU może być wprowadzony w stan głębokiego uśpienia pomiędzy interwałami rozgłaszania. Jak ukazano na ilustracji 1, emiter sygnału przez większość czasu jest w trybie głębokiego uśpienia, a jego pobór energii to dziesiątki µA.

Ilustracja 1: pobór prądu przez emiter sygnału BLE (źródła ilustracji:RFCOM)

Podsumowanie

System RTOS udostępnia takie funkcje jak: harmonogram, zadania, obiekty RTOS do komunikacji międzyzadaniowej, a także stosy komunikacji i sterowniki. Pozwala to deweloperom skupić się na warstwie aplikacji oprogramowania wbudowanego, aby łatwo i szybko projektować wielozadaniowe oprogramowanie. Jednak tak jak w przypadku każdego innego narzędzia, należy go odpowiednio używać, aby dawało więcej korzyści. Aby tworzyć bezpieczne, pewne i wydajne oprogramowanie wbudowane, deweloperzy powinni wiedzieć, kiedy używać funkcji RTOS, a także jak konfigurować system RTOS.