Wbudowane systemy czasu rzeczywistego Wykład 14

Wbudowane systemy czasu rzeczywistego Wykład 14

Systemy operacyjne czasu rzeczywistego System czasu rzeczywistego (RTOS) to system operacyjny opracowany tak, by spełnić wymagania narzucone na czas wykonywania zadanych operacji Systemy RTOS dzielą się na twarde i miękkie 2

Twarde systemy RTOS Są to systemy RTOS, dla których znane są maksymalne, czyli najgorsze, czasy reakcji (odpowiedzi) oraz gwarantujące, że czas ten nie zostanie przekroczony w żadnych okolicznościach Zastosowania: wszelkiego typu urządzenia, w których opóźnienie w obsłudze zdarzenia może doprowadzić do strat materialnych lub zagrożenia dla życia i zdrowia 3

Miękkie systemy RTOS Miękkie systemy czasu rzeczywistego, w odróżnieniu od systemów twardych, nie mają określonego maksymalnego czasu odpowiedzi, ale gwarantują wykonanie zadania w możliwie krótkim czasie Zastosowania: urządzenia, w których minimalizacja czasu reakcji i odpowiedzi wpływa pozytywnie na działanie, ale niespełnienie tego wymogu nie niesie ryzyka, np. systemy multimedialne 4

Miękkie systemy RTOS ChibiOS/RT DioneOS FlexOS ucrtos MicroC/OS-II ecos QNX OS9 VxWorks LynxOS Phoenix-RTOS irmx RT-Linux RTKernel DRYOS Windows CE SCIOPTA Sirius RTOS 5

Prosty system RTOS dla mikrokontrolerów System RTOS przewidziany do działania w urządzeniu opartym na mikrokontrolerze jednoukładowym, musi spełniać szereg warunków Zapewniać niezbędne czasy odpowiedzi w określonych sytuacjach Działać stabilnie i płynnie w środowisku o bardzo ograniczonych zasobach Wykorzystywać specyfikę architektury urządzenia, na którym działa 6

Prosty system RTOS dla mikrokontrolerów Zapewniać niezbędne czasy odpowiedzi w określonych sytuacjach, to znaczy Wykonywać określone zadania w czasie krótszym niż dopuszczalny czas przewidziany na te zadania, to jest gwarantującym poprawne działanie urządzenia i eliminującym ryzyko takich anomalii jak utrata danych, przyjęcie przez urządzenie niedozwolonego stanu lub jego uszkodzenie 7

Prosty system RTOS dla mikrokontrolerów Działać stabilnie i płynnie w środowisku o bardzo ograniczonych zasobach, czyli m.in. Nie dopuszczać do przekroczenia przez zadanie dostępnego przewidzianego (dostępnego) czasu procesora, tak by powodować opóźnień w wykonywaniu innych danych, mogących spowodować brak reakcji na zdarzenie lub utratę danych Zarządzać dostępną pamięcią RAM w sposób uniemożliwiający jej przepełnienie, a tym samym awarię systemu 8

Prosty system RTOS dla mikrokontrolerów Wykorzystywać specyfikę architektury urządzenia, na którym działa, czyli m.in. Wykorzystywać obecność mechanizmów sprzętowych umożliwiających poprawienie działania, zmniejszenie obciążenia i zwiększenie stabilności Uwzględniać braki i ograniczenia mechanizmów sprzętowych, wykorzystywanych powszechnie na innych platformach do wykonywania określonych zadań 9

Projektowanie prostego RTOS Jakie są zadania, które są wykonywane przez cały czas (np. obsługa interfejsu użytkownika)? Ile zasobów zajmują te zadania? Jakie zadania (obsługa zdarzeń) pojawiają się okresowo/losowo? Ile maksymalnie razy w jednostce czasu może pojawić się każde z tych zadań? Ile zasobów zajmie obsługa pojedynczej instancji każdego takiego zadania? 10

Projektowanie prostego RTOS Jakie są priorytety tych zadań? Czy terminowe wykonie któregoś z nich jest istotniejsze dla poprawnego działania urządzenia niż pozostałych? Czy niewykonanie zadania określonego typu może doprowadzić do niedopuszczalnych anomalii w działaniu urządzenia? 11

Asynchroniczność w prostych RTOS Większość prostych mikrokontrolerów jednoukładowych nie umożliwia/umożliwia w bardzo ograniczonym stopniu implementację podziału czasu, wieloprogramowości i podobnych mechanizmów znanych z pełnowartościowych platform Istnieje jednak możliwość zapewnienia w pewnym zakresie asynchroniczności wykonywanych zadań 12

Asynchroniczność na przykładzie AVR Najprostszym sposobem zapewnienia namiastki wieloprogramowości w mikrokontrolerach AVR jest wykorzystanie przerwań: Pochodzenia wewnętrznego, zgłaszanych np. przez timery przy przepełnieniu lub zgodności Pochodzenia zewnętrznego, zgłaszanych przez moduły komunikacyjne lub porty INTx lub PCIx Można też zrealizować podział czasu w pętli głównej 13

Wykorzystanie przerwań Przerwania pozwalają na szybką obsługę zdarzenia Przerwania zapewniają wywłaszczanie zrealizowane sprzętowo, zgodnie tabelą priorytetów przerwań Nie ma dwóch przerwań o tym samym priorytecie Priorytety przerwań nie mogą zostać zmienione 14

Wykorzystanie przerwań W przypadku wykorzystania przerwań istnieje ryzyko wystąpienia następujących anomalii: Ryzyko głodzenia programu z pętli głównej, polegające na zawieszaniu jego wykonywania, a w skrajnym wypadku, na całkowitym jego zatrzymaniu Ryzyko zablokowania obsługi przerwań o niższym priorytecie: co prawda przerwania te zostaną obsłużone po zakończeniu obsługi przerwania o wyższym priorytecie, ale zostaną obsłużone tylko raz bez względu na liczbę ich wystąpień w momencie blokady 15

Wykorzystanie przerwań W przypadku wykorzystania przerwań istnieje ryzyko wystąpienia następujących anomalii: Ryzyko pominięcia wystąpień danego przerwania w trakcie jego obsługi spowodowane zbyt częstym jego zgłaszaniem lub zbyt długim czasem obsługi 16

Wykorzystanie pętli głównej Pętla główna może zostać wykorzystana do realizacji wielozadaniowości Bez wywłaszczania zadania muszą być wystarczająco krótkie lub muszą samodzielnie zwalniać procesor po wykorzystaniu określonego czasu Z wywłaszczaniem, trudne w implementacji, brak wsparcia sprzętowego 17

FreeRTOS FreeRTOS 18

FreeRTOS FreeRTOS jest systemem czasu rzeczywistego przeznaczonym dla urządzeń wbudowanych o dużych ograniczeniach na ilość posiadanych zasobów, przede wszystkim pamięci RAM Ze względu na swoją niezawodność i stabilność jest powszechnie wykorzystywany w rozwiązaniach przemysłowych 19

FreeRTOS FreeRTOS oferowany jest na zmodyfikowanej licencji GNU, umożliwiającej komercyjną dystrybucję gotowego oprogramowania bez udostępniania kodu źródłowego Podobnie jak inne systemy dla platform o ograniczonych zasobach, FreeRTOS jest kompilowany razem z obsługiwanymi aplikacjami 20

FreeRTOS FreeRTOS nie oferuje Wsparcia dla mechanizmu sterowników urządzeń Zaawansowanego zarządzania pamięcią Zaawansowanych algorytmów pracy schedulera Obsługi sieci (obsługa sieci może być zrealizowana za pomocą bibliotek trzecich) Obsługi kont użytkowników w jakiejkolwiek postaci 21

FreeRTOS FreeRTOS oferuje Scheduler nadzorujący wykonywania zadań Mechanizmy kolejkowania, umożliwiające obsługę przerwań Semafory i mutexy, umożliwiające kontrolę dostępu do zasobów 22

FreeRTOS Jedyne mechanizmy zależne od platformy obsługiwane przez system to układy licznikowe i ewentualne przerwania softwarowe (o ile dana platforma je udostępnia) Warstwa abstrakcji dla Pozostałych układów peryferyjnych mikrokontrolera nie jest nadzorowana przez system, dzięki czemu ograniczone zostaje zużycie zasobów na obsługę komunikacji między warstwą obsługi sprzętu i warstwą aplikacji 23

FreeRTOS 24

Wybrane platformy Atmel AVR, AVR32 SAM3, SAM4, SAM7, SAM9, SAM D20, SAM L21 ARM ARM7, ARM9, ARM Cortex- M0, ARM Cortex-M0+, ARM Cortex-M3, ARM Cortex-M4, ARM Cortex-A Intel X86, 8052 IBM PIC NXP PPC405, PPC404 PIC18, PIC24, dspic, PIC32 LPC1000, LPC2000, LPC4300 STMicroelectronics STM32, STR7 25

Wybrane elementy FreeRTOS Scheduler Zadania Kolejki Semafory i mutexy 26

Scheduler Scheduler (wywłaszczający lub niewywłaszczający) systemu odpowiada za kontrolę wykonywania zadań i zarządza przydziałem czasu procesora Podstawową jednostką czasu jest tick, wynoszący zwykle 1-10ms Scheduler systemu FreeRTOS obsługuje priorytety zadań 27

Scheduler Operacje na zadaniu wpierane przez scheduler Utworzenie i usunięcie Zawieszenie i wznawianie Opóźnienie wykonywania 28

Zadania Zadania są podstawową strukturą FreeRTOS Są to zazwyczaj funkcje zawierające nieskończone pętle programowe Wykonywanie zadań jest nadzorowane przez scheduler Każde zadanie posiada swój własny stos, priorytet oraz opcjonalnie handler 29

Zadania Elementy zadania Stos obszar pamięci przechowujący aktualny stan zadania, jego rozmiar musi być zadeklarowany dla każdego zadania osobno Priorytet liczba naturalna decydująca o czasie procesora, który zostanie przyznany zadaniu i po przekroczeniu którego zadanie zostanie wywłaszczone przez scheduler Handler obiekt reprezentujący zadanie, pozwala na zarządzanie zadaniem przez inne zadanie 30

Tworzenie zadania portbase_type xtaskcreate( pdtask_code pvtaskcode, const portchar * const pcname, unsigned portshort usstackdepth, void *pvparameters, unsigned portbase_type uxpriority, xtaskhandle *pvcreatedtask ); 31

Tworzenie zadania pvtaskcode wskaźnik do funkcji stanowiącej zadanie pcname nazwa zadania (opcjonalna) usstackdepth wielkość stosu pvparameters opcjonalne parametry, które zostaną przekazane do kodu zadania uxpriority priorytet zadania pvcreatedtask opcjonalny wskaźnik do handlera 32

Kolejki Kolejki są podstawowym mechanizmem umożliwiającym wymianę danych między zadaniami 33

Tworzenie kolejki xqueuehandle xqueuecreate( unsigned portbase_type uxqueuelength, unsigned portbase_type uxitemsize ); uxqueuelength długość kolejki uxitemsize wielkość pojedynczego obiektu 34

Wysyłanie komunikatu portbase_type xqueuesend( xqueuehandle xqueue, const void * pvitemtoqueue, portticktype xtickstowait ); xqueue kolejka pvitemtoqueue element do wysłania xtickstowait maksymalny czas oczekiwania na umieszczenie zadania w kolejce 35

Odbieranie komunikatu portbase_type xqueuereceive( xqueuehandle xqueue, void *pvbuffer, portticktype xtickstowait ); xqueue kolejka pvbuffer bufor, w którym zostanie umieszczony odebrany element xtickstowait maksymalny czas oczekiwania na pojawienie się elementu gotowego do odbioru 36

Kolejki i przerwania FreeRTOS dostarcza funkcje do obsługi kolejek, które mogą być bezpiecznie używane w funkcji obsługującej przerwanie, nie blokując działania funkcji xqueuesendfromisr xqueuereceivefromisr 37

Semafory Semafory umożliwiają synchronizację wykonywanych zadań Semafory udostępniane przez system FreeRTOS mają właściwości analogiczne jak semafory w innych systemach 38

Tworzenie semafora vsemaphorecreatebinary( ); xsemaphorehandle xsemaphore xsemaphore handler semafora 39

Ustawianie semafora xsemaphoretake( xsemaphorehandle xsemaphore, portticktype xblocktime ); xsemaphore handler semafora, który ma zostać ustawiony xblocktime maksymalny czas liczony w tickach schedulera przewidziany na ustawienie semafora 40

Zwolnienie semafora xsemaphoregive( ); xsemaphorehandle xsemaphore xsemaphore handler semafora przewidzianego do zwolnienia 41

Semafory i przerwania Funkcja zwalniająca semafor posiada swój odpowiednik wykorzystywany wewnątrz funkcji obsługujących przerwania xsemaphoregivefromisr 42

Komponenty trzecie uip stos TCP/IP na licencji opensource, obecnie część systemu Contiki https://github.com/adamdunkels/uip lwip inny otwartoźródłowy stos IP, wspierający takie protokoły jak IP, ICMP, IGMP, UDP, TCP, DNS, SNMP, DHCP itp. http://savannah.nongnu.org/projects/lwip/ 43

Komponenty trzecie wolfssl biblioteka na licencji GPL dostarczająca wsparcia dla SSL/TLS dla platform wbudowanych http://www.wolfssl.com/wolfssl/productswolfssl.html FatFs otwartoźródłowa biblioteka zapewniająca wsparcie dla systemów plików Fat12/Fat16/Fat32 (zapis i odczyt) http://elm-chan.org/fsw/ff/00index_e.html 44

Komponenty trzecie u8glib biblioteka na licencji BSD umożliwiająca tworzenie interfejsów graficznych na platformach wbudowanych https://code.google.com/p/u8glib/ M2tklib biblioteka graficzna na licencji GPL dla platform wbudowanych http://code.google.com/p/m2tklib/ 45

Inne systemy RTOS Inne systemy RTOS 46

OpenRTOS Zmodyfikowana licencja FreeRTOS, której jeden z zapisów mówi, że kod systemu FreeRTOS użytego w komercyjnym projekcie musi być udostępniony (nie dotyczy do kodu nie będącego częścią dystrybucji FreeRTOS), może powodować trudności z wykorzystaniem go w projekcie o zamkniętych źródłach, zwłaszcza w sytuacji, gdy kod jakiegoś komponentu systemu został zmodyfikowany 47

OpenRTOS Projekt OpenRTOS firmy WITTENSTEIN High Integrity Systems bazuje na kodzie źródłowym FreeRTOS, ale jest wydawany na całkowicie komercyjnej licencji, umożliwiającej pełne zamknięcie kodu OpenRTOS posiada ponadto pełny support 48

SafeRTOS SafeRTOS jest systemem bazującym na FreeRTOS, rozwijanym przez firmę WITTENSTEIN High Integrity Systems podobnie jak OpenRTOS SafeRTOS przeszedł proces certyfikacji potwierdzającej, że specyfikacja systemu jest zgodna ze stanem rzeczywistym Firma WITTENSTEIN High Integrity Systems umożliwia również certyfikację gotowych rozwiązań opartych o SafeRTOS 49

SafeRTOS SafeRTOS posiada certyfikaty spełniania norm umożliwiające stosowanie go w następujących gałęziach przemysłu Industrial (UL 1998, IEC 61508) Transportation/Rail (CENELEC EN 50128, IEC 61508) Medical (FDA 510(k), IEC 62304, IEC 60601, ISO 14971) Nuclear (IEC 61513, IEC 62138, ASME NQA-1 2008) Process (IEC 61511) Automotive (ISO 26262, IEC 61508) Aerospace (DO178B) 50