Wbudowane systemy czasu rzeczywistegolielow/PTM/Wyklady/W14_Wbudowane...FreeRTOS •FreeRTOS jest systemem czasu rzeczywistego przeznaczonym dla urządzeń wbudowanych o dużych ograniczeniach

Techniki mikroprocesorowe

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



• 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



• 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



• 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



• 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



• 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

– PPC405, PPC404

• PIC

– PIC18, PIC24, dsPIC, PIC32

• NXP

– 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

https://github.com/adamdunkels/uip

http://savannah.nongnu.org/projects/lwip/


Komponenty trzecie

• wolfSSL – biblioteka na licencji GPL dostarczająca wsparcia dla SSL/TLS dla platform wbudowanych http://www.wolfssl.com/wolfSSL/Products-wolfssl.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

http://www.wolfssl.com/wolfSSL/Products-wolfssl.html



http://elm-chan.org/fsw/ff/00index_e.html




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

https://code.google.com/p/u8glib/

http://code.google.com/p/m2tklib/

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

Documents

Wbudowane systemy czasu rzeczywistegolielow/PTM/Wyklady/W14_Wbudowane...FreeRTOS •FreeRTOS jest systemem czasu rzeczywistego przeznaczonym dla urządzeń wbudowanych o dużych ograniczeniach