FreeRTOS

FreeRTOS
Logo
Rodzina System operacyjny czasu rzeczywistego
Typ rdzenia mikrojądra
Stan projektu W rozwoju
Kaucja github.com/FreeRTOS/FreeRTOS
Platformy ARM (ARM7, ARM9, Cortex-M3, Cortex-M4, Cortex-A), Atmel AVR , AVR32 (en) , HCS12 (en) , MicroBlaze , MSP430 , Microcontrôleur PIC , Renesas H8/S , SuperH , RX, x86 , 8052 , Motorola ColdFire , V850 (en) , 78K0R, seria Fujitsu MB91460, seria Fujitsu MB96340, Nios II (en)
Firma /
Deweloper 		Amazon, Richard Barry i zespół FreeRTOS
Licencja MIT , wcześniej zmodyfikowana GNU GPL
Stany źródłowe Darmowe oprogramowanie dla systemu wbudowanego
Napisane w VS
Najnowsza stabilna wersja 202012.00-LTS (15 grudnia 2020 r.)
Stronie internetowej www.freertos.org

FreeRTOS jest system operacyjny czasu rzeczywistego ( RTOS ), małe rozmiary , laptop , poboru i open source dla mikrokontrolera . Został przeniesiony do ponad 40 różnych architektur. Stworzony w 2003 roku przez Richarda Barry'ego i zespół FreeRTOS, jest dziś jednym z najczęściej używanych na rynku systemów operacyjnych czasu rzeczywistego.

FreeRTOS jest dostępny za darmo na licencji MIT od 29 listopada 2017 r. Poprzednie wersje były dostępne na zmodyfikowanej licencji GPL i można z nich korzystać bez opłat licencyjnych, ta licencja nie zobowiązuje programistów do publikowania kodu ich aplikacji, ale wymaga zachowania jądro FreeRTOS Open Source. Licencja komercyjna z obsługą ad hoc (OpenRTOS) jest również oferowana przez firmę High Integrity Systems.

Liczba zadań działających jednocześnie i ich priorytet są ograniczone jedynie sprzętem. Scheduling to system kolejkowania oparty na semaforach i mutexach . Opiera się na modelu Round-Robin z zarządzaniem priorytetami. Zaprojektowany jako bardzo kompaktowy, składa się tylko z kilku plików języka C i nie zawiera żadnego sterownika sprzętowego.

Obszary zastosowań są dość szerokie, ponieważ główne zalety FreeRTOS to wykonywanie w czasie rzeczywistym, otwarty kod źródłowy i bardzo mały rozmiar. Dlatego jest używany głównie w systemach wbudowanych, które mają ograniczone miejsce na kod, ale także w systemach przetwarzania wideo i aplikacjach sieciowych, które mają ograniczenia w czasie rzeczywistym.

Definicja

FreeRTOS to darmowy i otwarty system operacyjny czasu rzeczywistego, pierwotnie opracowany przez Real Time Engineers Ltd.

W 2017 roku projekt i jego zespół programistów zostały przejęte przez Amazon. Powstała również specyficzna wersja FreeRTOS o nazwie Amazon FreeRTOS, zawierająca szereg bibliotek ułatwiających integrację z chmurą Amazon AWS.

Został przeniesiony do ponad 40 różnych architektur i 15 łańcuchów budowania . W 2019 roku pobrano go ponad 185 500 razy.

Jego konstrukcja jest celowo minimalistyczna, aby można ją było zainstalować w małych systemach. Binarny obraz z rdzeniem waży od 4 KB , a 9KB (4,3 KB opracowano na ARM7). Minimalny zestaw ma tylko kilka funkcji do zarządzania zadaniami i pamięcią. Dodatkowo implementowane są kolejki , semafory i muteksy .

Jądro w wersji 7.3.0 składa się z pięciu plików kodowanych w języku C . Sekcje w Assemblerze umożliwiają zapewnienie kompatybilności FreeRTOS z różnymi architekturami sprzętowymi.

Nieograniczona liczba zadań może być wykonywana jednocześnie i bez ograniczeń.

Architektura

FreeRTOS został zaprojektowany tak, aby był bardzo lekki, od 4KiB do 9kiB dla typowego obrazu binarnego jądra RTOS. Samo jądro składa się z trzech plików źródłowych napisanych w języku C .

Harmonogram

Głównym celem planowania zadań jest podjęcie decyzji, które z zadań są w stanie „gotowości” do wykonania. Aby dokonać takiego wyboru, harmonogram FreeRTOS opiera się wyłącznie na priorytetach zadań.

Zadania we FreeRTOS są przypisane do ich tworzenia, a poziom priorytetu jest reprezentowany przez liczbę całkowitą. Najniższy poziom to zero i musi być ściśle zarezerwowany dla zadania Idle . Użytkownik ma możliwość nadpisania tego poziomu niestandardowym priorytetem poprzez modyfikację stałej  : tskIDLE_PRIORITY . Maksymalna liczba poziomów priorytetów jest określona przez stałą: tskMAX_PRIORITIES . Kilka zadań może należeć do tego samego poziomu priorytetu.

We FreeRTOS nie ma mechanizmu automatycznego zarządzania priorytetami. Priorytet zadania można zmienić tylko na wyraźną prośbę dewelopera.

Zadania to proste funkcje, które zwykle działają w nieskończonej pętli i mają następującą ogólną strukturę:

void vATaskFunction( void *pvParameters ) { for( ;; ) { -- Ajouter le code de votre tâche ici -- } }


W przypadku mikrokontrolera posiadającego tylko jeden rdzeń, w danym momencie wykonywane będzie tylko jedno zadanie. Harmonogram zawsze upewni się, że zadanie o najwyższym priorytecie, które można uruchomić, zostanie wybrane do przejścia w stan uruchomienia. Jeśli dwa zadania mają ten sam poziom priorytetu i oba mogą być uruchomione, wtedy dwa zadania będą uruchamiane naprzemiennie w odniesieniu do wybudzeń harmonogramu ( round robin ).

Aby wybrać zadanie do wykonania, harmonogram musi sam wykonać i wywłaszczyć zadanie w stanie wykonania. Aby zapewnić wybudzenie harmonogramu, FreeRTOS definiuje okresowe przerwanie zwane „tick przerwaniem”. To przerwanie działa w nieskończoność z określoną częstotliwością, która jest zdefiniowana w pliku FreeRTOSConfig.h przez stałą:

configTICK_RATE_HZ /* Fréquence d’exécution de la "tick interrupt" en Hz. */

Stała ta następnie opisuje okres czasu przydzielony do minimum dla każdego zadania lub wyjaśniony inaczej, interwał oddzielający dwa przebudzenia harmonogramu.

Jak opisano w tej sekcji, FreeRTOS jest zatem systemem RTOS, który wykorzystuje planowanie z wywłaszczaniem do zarządzania zadaniami. Może jednak opcjonalnie używać (jeśli jest mu nadana dyrektywa) kooperacyjnego planowania . W tym trybie planowania zmiana kontekstu wykonania ma miejsce tylko wtedy, gdy wykonywane zadanie jawnie zezwala na uruchomienie innego zadania (na przykład poprzez wywołanie Yield()) lub poprzez wejście w stan blokowania. Dlatego zadania nigdy nie są przesądzone. Ten tryb planowania znacznie upraszcza zarządzanie zadaniami, niestety może prowadzić do mniej wydajnego i mniej bezpiecznego systemu.

FreeRTOS może również korzystać z harmonogramów hybrydowych, korzystając z harmonogramów z wywłaszczaniem i harmonogramów kooperacyjnych. W tym trybie zmiana kontekstu wykonania może nastąpić również podczas zdarzenia przerwania.

Głód

We FreeRTOS zadanie o najwyższym priorytecie gotowe do uruchomienia będzie zawsze wybierane przez harmonogram. Może to doprowadzić do sytuacji głodu . Dzieje się tak, ponieważ jeśli zadanie o najwyższym priorytecie nigdy nie zostanie przerwane , wszystkie zadania o niższym priorytecie nigdy nie zostaną uruchomione. FreeRTOS nie implementuje żadnego automatycznego mechanizmu zapobiegającego zjawisku głodu. Deweloper musi upewnić się, że nie ma zadań, które zmonopolizują cały czas wykonania mikrokontrolera. W tym celu może umieszczać zdarzenia, które przerwą zadanie o wyższym priorytecie na określony czas lub do wystąpienia innego zdarzenia i tym samym pozostawi wolne pole do realizacji dla zadań o niższych priorytetach.

Aby uniknąć głodu, deweloper może użyć harmonogramu monotonicznego (RMS). Jest to technika przydzielania priorytetów, która przypisuje każdemu zadaniu unikalny priorytet zgodnie z częstotliwością jego wykonywania. Najwyższy priorytet jest nadawany zadaniu o najwyższej częstotliwości wykonywania, a najniższy priorytet ma zadaniu o najniższej częstotliwości. Harmonogramowanie w tempie monotonicznym umożliwia maksymalizację harmonogramowania zadań, ale pozostaje to trudne do osiągnięcia ze względu na charakter zadań, które nie są całkowicie okresowe.

Bezczynne zadanie

Mikrokontroler zawsze powinien mieć coś do roboty. Innymi słowy, zawsze musi być uruchomione zadanie. FreeRTOS zarządza tą sytuacją, definiując zadanie bezczynności, które jest tworzone po uruchomieniu harmonogramu. Do tego zadania przypisany jest najniższy priorytet jądra. Mimo to zadanie bezczynności może mieć kilka funkcji do wykonania, w tym:

  • Zwolnij miejsce zajmowane przez usunięte zadanie.
  • Przełącz mikrokontroler w stan wstrzymania, aby oszczędzać energię systemu, gdy żadne zadanie aplikacji nie jest uruchomione.
  • Zmierz szybkość wykorzystania procesora .

Opis zadań

We FreeRTOS każde zadanie jest opisane przez blok TCB (Task Control Block), który zawiera wszystkie informacje niezbędne do określenia i reprezentowania zadania.

Blok kontroli zadań
Zmienne Opis
pxTopOfStack Wskaźnik do ostatniego elementu na górze stosu
xGenericListItem Członek (xListItem) listy używanej do umieszczania TCB na liście stanów (gotowy, zablokowany lub zawieszony).
xEventListItem Element listy (xListItem) używany do umieszczania TCB na liście zdarzeń.
uxPriorytet Priorytet zadania
pxStos Wskaźnik do początku stosu procesów
pxEndOfStack Wskaźnik do końca stosu procesu
uxTCBNnumer Rozmiar stosu w liczbie zmiennych
pcNazwaZadania Liczba zwiększana za każdym razem, gdy tworzona jest baza TCB (używana do debugowania)
uxBasePriorytet Ostatni priorytet przypisany do zadania
ulRunTimeCounter Oblicza czas spędzony przez zadanie w stanie wykonania
pxTagzadania Umożliwia dodanie znacznika do zadania. Tag służy do prowadzenia logów poprzez wyjścia analogowe lub cyfrowe dzięki funkcji traceSWITCHED_IN().
uxZagnieżdżanie krytyczne Umożliwia zapisanie głębokości zagnieżdżenia krytycznych sekcji tego zadania. Za każdym razem, gdy zadanie wchodzi do sekcji krytycznej, zmienna jest inkrementowana, jest zmniejszana, gdy tylko zadanie opuści sekcję krytyczną.

Ta zmienna jest konieczna, ponieważ możliwe jest, że zadanie przestanie mieć kontrolę, gdy znajduje się w sekcji krytycznej.

Zadania we FreeRTOS mogą istnieć w 5 stanach: „usunięte”, „zawieszone”, „gotowe”, „zablokowane” lub „w trakcie wykonywania”.

We FreeRTOS nie ma zmiennej, która jednoznacznie określałaby stan zadania, w zamian FreeRTOS używa list stanów. Obecność zadania na typie listy statusów określa jego status (gotowe, zablokowane lub zawieszone). Ponieważ zadania często zmieniają stan, planista będzie musiał jedynie przenieść zadanie (element (xListItem) należący do tego samego zadania) z jednej listy stanów na inną.

Podczas tworzenia zadania, FreeRTOS tworzy i wypełnia odpowiednią bazę TCB, a następnie bezpośrednio wstawia zadanie do „Gotowej listy” (Lista zawierająca odniesienie do wszystkich zadań będących w stanie „Gotowe”).

FreeRTOS utrzymuje kilka „list gotowych”, lista istnieje dla każdego poziomu priorytetu. Wybierając kolejne zadanie do wykonania, planista analizuje „Gotowe listy” od najwyższego do najniższego priorytetu.

Zamiast jawnie definiować stan „uruchomiony” lub powiązaną z nim listę, jądro FreeRTOS opisuje zmienną „pxCurrentTCB”, która identyfikuje wykonywany proces. Ta zmienna wskazuje na TCB odpowiadającą procesowi znajdującemu się w jednej z „Gotowych list”.

Zadanie może znaleźć się w stanie „zablokowane” podczas uzyskiwania dostępu do kolejki odczytu/zapisu, jeśli kolejka jest pusta/pełna. Każda operacja dostępu do kolejki jest skonfigurowana z limitem czasu (xTicksToWait). Jeśli ten limit czasu wynosi 0, zadanie nie jest blokowane, a operacja dostępu do kolejki jest uważana za nieudaną. Jeśli limit czasu nie jest równy zero, zadanie przechodzi w stan 'zablokowany', dopóki nie nastąpi modyfikacja kolejki (np. przez inne zadanie). Gdy operacja dostępu do kolejki jest możliwa, zadanie sprawdza, czy nie upłynął limit czasu, i pomyślnie kończy operację.

Zadanie może zostać dobrowolnie umieszczone w stanie „zawieszonym”, zostanie wtedy całkowicie zignorowane przez program planujący i nie będzie zużywało więcej zasobów, dopóki nie zostanie usunięte ze stanu i wprowadzone z powrotem w stan „gotowy”.

Ostatnim stanem, jaki zadanie może przyjąć, jest stan „usunięty”, ten stan jest konieczny, ponieważ usunięte zadanie nie zwalnia natychmiast swoich zasobów. W stanie „usuniętym” zadanie jest ignorowane przez program planujący, a inne zadanie o nazwie „BEZCZYNNY” jest odpowiedzialne za zwolnienie zasobów przydzielonych przez zadania będące w stanie „usuniętym”.

Zadanie „IDLE” jest tworzone po uruchomieniu harmonogramu i ma przypisany najniższy możliwy priorytet, co prowadzi do opóźnionego zwolnienia zasobów, gdy żadne inne zadanie nie jest uruchomione.

Struktury danych FreeRTOS

Listy

Listy to najczęściej używane struktury danych we FreeRTOS. Służą do organizowania i planowania zadań, a także do realizacji kolejek.

FreeRTOS definiuje kilka struktur reprezentujących listy:

  • Struktura xLIST reprezentuje nagłówek list tworzonych i używanych przez program planujący. Na przykład listy gotowych zadań (lista według priorytetów), lista zablokowanych zadań itp. Ta struktura zawiera w pewien sposób inne struktury list używane przez FreeRTOS.

Struktura xLIST jest zdefiniowana w następujący sposób:

typedef struct xLIST { volatile unsigned portBASE_TYPE uxNumberOfItems; /* Le nombre d'éléments dans cette liste. */ volatile xListItem * pxIndex; /* Pointeur utilisé pour parcourir cette liste, il pointe successivement sur les éléments (xLIST_ITEM) contenus dans cette liste. */ volatile xMiniListItem xListEnd; /* Élément marquant la fin de cette liste. Elle contient pour cela la valeur maximale de la variable xItemValue dans la liste. */ } xList;


  • Struktura xLIST_ITEM reprezentuje elementy listy (typu xLIST). Każdy element listy jest powiązany z zadaniem, a różne zmienne struktury xLIST_ITEM służą do organizowania zadań i łączenia ich ze sobą w celu utworzenia podwójnie połączonej listy.

Struktura xLIST_ITEM jest zdefiniowana w następujący sposób:

struct xLIST_ITEM { portTickType xItemValue; /* Une valeur attribuée à cet élément, cette valeur est utilisée afin de trier la liste (de type (xLIST) contenant cet élément (xLIST_ITEM)) dans un ordre décroissant. */ volatile struct xLIST_ITEM * pxNext; /* Pointeur vers le prochain élément (xLIST_ITEM) dans la liste (xLIST). */ volatile struct xLIST_ITEM * pxPrevious; /* Pointeur vers le précédent élément (xLIST_ITEM) dans la liste (xLIST). */ void * pvOwner; /* Pointeur vers l'objet contenant cet élément, cet objet est, dans la plupart des cas, le TCB d'une tâche. */ void * pvContainer; /* Pointeur vers la liste (xLIST) dans laquelle cet élément est contenu. */ };


  • Struktura XMiniListItem jest zmniejszoną wersją XLIST_ITEM . Nie zawiera zmiennych pvOwner i pvContainer . Stanowi element wyznaczający koniec tej listy.


Linie

Kolejki to główne mechanizmy, które umożliwiają wzajemną komunikację i synchronizację zadań.

Podstawowa struktura kolejki jest opisana w następujący sposób:

typedef struct QueueDefinition { signed char *pcHead; /* Pointeur sur l'octet de début de la file en mémoire */ signed char *pcTail; /* Pointeur sur l'octet de fin de la file en mémoire (un octet de plus que nécessaire, car utilisé comme un marqueur de fin). */ signed char *pcWriteTo; /* Pointeur sur le prochain [[octet]] libre dans la file. */ signed char *pcReadFrom; /* Pointeur sur le dernier octet lu de la file. */ xList xTasksWaitingToSend; /* Liste des tâches (ordonnées par niveau de priorités) qui sont bloquées en attente d’écriture sur la file. */ xList xTasksWaitingToReceive; /* Liste des tâches (ordonnées par niveau de priorités) qui sont bloquées en attente de lecture depuis la file .*/ volatile unsigned portBASE_TYPE uxMessagesWaiting; /* Nombre d'éléments actuellement contenus dans la file. */ unsigned portBASE_TYPE uxLength; /* Taille de la file définit comme le nombre d'éléments maximum qu'elle peut contenir et non le nombre d'octets. */ unsigned portBASE_TYPE uxItemSize; /* Taille de chaque élément (en octet) que la file pourra contenir. */ } xQUEUE;


Kolejka zawiera skończoną liczbę elementów o stałym rozmiarze. Fizyczny rozmiar kolejki jest określany przez maksymalną liczbę elementów, które może ona zawierać ( uxLength ) pomnożoną przez rozmiar każdego elementu w bajtach ( uxItemSize ).

We FreeRTOS zapisywanie lub wysyłanie danych do kolejki odbywa się poprzez kopiowanie bajt po bajcie i niezależnie od jego typu, ponieważ czas życia zapisanego elementu jest często krótszy niż czas życia kolejki. Podobnie jak w przypadku operacji zapisu, odczyt lub odbiór danych odbywa się również poprzez kopiowanie bajt po bajcie danych, które zostaną usunięte z kolejki.

Kolejki są niezależnymi obiektami, nie ma przypisania ani członkostwa do zadania. Są to struktury, które umożliwiają wzajemną komunikację zadań. W rezultacie mogą jednocześnie wykonywać wiele zadań odczytu i zapisu.

Operacje zapisu lub odczytu w kolejkach mogą być blokujące lub nieblokujące. Operacje nieblokujące bezpośrednio zwracają status powodzenia lub niepowodzenia do kolejki. Operacje blokowania są skonfigurowane z limitem czasu, który pozwala im blokować i określa maksymalny czas, w którym mogą pozostać w tym stanie.

Zarządzanie zasobami

FreeRTOS wykorzystuje kolejki jako środek komunikacji między zadaniami. Jednak kolejki zarządzają również synchronizacją i rywalizacją między zadaniami. Dlatego ta struktura jest podstawowym elementem zarządzania zasobami we FreeRTOS.

FreeRTOS synchronizuje zadania za pomocą głównie dwóch mechanizmów: Semaphores i Mutex .

Semafory

FreeRTOS umożliwia tworzenie i używanie semaforów z kilkoma elementami. Semafory są zaimplementowane w postaci kolejki w taki sposób, że liczba elementów semafora reprezentuje maksymalną liczbę elementów, które może zawierać kolejka. Kolejka reprezentująca semafor nie zapisuje żadnych danych, zajmuje się jedynie zarejestrowaniem liczby aktualnie zajętych przez nią wpisów. Rozmiar elementów w kolejce wynosi zatem zero (uxItemSize = 0). Dostęp do Semafora tylko zwiększa lub zmniejsza liczbę zajętych wpisów w kolejce i nie jest wykonywana żadna kopia elementu.

Interfejs API oferowany przez FreeRTOS do zarządzania semaforami rozróżnia semafory N-elementowe od semaforów binarnych. Semafory binarne mogą być postrzegane jako kolejki, które mogą zawierać tylko jeden element. Semafor binarny może być zatem wzięty tylko raz, zanim stanie się niedostępny, w przeciwieństwie do semafora z n elementami, który można wziąć kilka razy, co umożliwia np. zdefiniowanie liczby dostępnych zasobów lub policzenie liczby zdarzeń, które muszą jeszcze być straconym.

Mutex

Mutex służy do ochrony udostępnionego zasobu.

Implementacja Mutex we FreeRTOS jest podobna do semaforów binarnych (w postaci kolejki), z tym wyjątkiem, że zadanie, które pobiera Mutex, musi go obowiązkowo zwrócić. Można to rozumieć jako powiązanie tokena z zasobem, zadanie pobiera token i wykorzystuje zasób, a następnie zwraca token na końcu, przy czym żaden inny dodatkowy token nie może być powiązany z zadaniem.

Kolejną istotną różnicą między Mutex i Binary Semaphores we FreeRTOS jest system dziedziczenia priorytetów. Gdy kilka zadań żąda pobrania Mutexu, priorytet posiadacza Mutexu jest chwilowo ustawiany na wartość najwyższego priorytetu spośród zadań oczekujących na jego uwolnienie. Ta technika skutkuje zapobieganiem zjawiskom zagrożonym odwróceniem priorytetów, nawet jeśli nie gwarantuje to niezawodnego bezpieczeństwa w obliczu tych zjawisk.


Zarządzanie przerwaniami

Przerwanie to mechanizm czysto sprzętowy, który jest implementowany i inicjowany przez ten ostatni. FreeRTOS zapewnia tylko metody obsługi przerwań i może również inicjować przerwania przez wywołanie instrukcji sprzętowej.

FreeRTOS nie narzuca programistom żadnej konkretnej strategii obsługi przerw, ale oferuje kilka sposobów, dzięki którym wybrana strategia może być łatwo zaimplementowana i utrzymana.

Procedury przerwań (ISR) to funkcje wykonywane przez sam mikrokontroler, które nie mogą być obsługiwane przez FreeRTOS, co może powodować pewne problemy. Z tych powodów procedury przerwań nie mogą używać zwykłych funkcji API FreeRTOS, z których może korzystać każde inne podstawowe zadanie. Jednak FreeRTOS definiuje grupę funkcji specjalnie zaprojektowanych dla ISR-ów, na przykład ISR użyje funkcji xSemaphoreGiveFromISR() zamiast xSemaphoreGive() , podobnie użyje funkcji xQueueReceiveFromISR() zamiast xQueueReceive() .

Aby określić politykę zarządzania przerwaniami i zarządzać dostępem do funkcji jądra specyficznych dla ISR, FreeRTOS definiuje stałe w pliku konfiguracyjnym FreeRTOSConfig.h  :

  • configKERNEL_INTERRUPT_PRIORITY  : Definiuje poziom priorytetu przerwania czasowego ( ang . Tick interrupt), które jest okresowym przerwaniem używanym do uruchamiania harmonogramu w każdym przedziale czasu.
  • configMAX_SYSCALL_INTERRUPT_PRIORITY  : Definiuje najwyższy poziom priorytetu, dla którego można używać funkcji FreeRTOS specyficznych dla ISR.

Definicja tych dwóch stałych umożliwia określenie polityki zarządzania ISR zgodnie z ich poziomem priorytetów:

  • ISR z poziomem priorytetu pomiędzy configKERNEL_INTERRUPT_PRIORITY i configMAX_SYSCALL_INTERRUPT_PRIORITY będzie mógł korzystać z funkcji API specyficznych dla ISR-ów, będzie mógł wywłaszczyć zadanie, ale nie jądro ani zadanie wykonujące sekcję krytyczną. Nie może być wywłaszczony przez planistę, ponieważ przerwanie odliczania czasu ma niższy priorytet.
  • ISR z poziomem priorytetu ściśle wyższym niż configMAX_SYSCALL_INTERRUPT_PRIORITY będzie w stanie wywłaszczyć planistę , nawet podczas wykonywania sekcji krytycznego kodu. W zamian nie będzie już miał dostępu do żadnej z funkcji API FreeRTOS.
  • ISR nie korzystający z żadnej funkcji API FreeRTOS może używać dowolnego poziomu priorytetu.

Definicja dwóch poprzednich stałych dodaje również do ISR specyfikę zagnieżdżania przerwań ( ang . Interrupt Nesting). Zagnieżdżanie przerwań to możliwość, że drugie przerwanie wystąpi w tym samym czasie, gdy inne przerwanie jest przetwarzane przez ISR. To drugie przerwanie może wywłaszczyć pierwsze, jeśli ma wyższy priorytet.

Należy zauważyć, że priorytety przerwań są określone przez architekturę mikrokontrolera. Są to priorytety sprzętowe, które nie mają związku z priorytetami oprogramowania, które można przypisać do zadań we FreeRTOS.

Odroczone przerwy

Jak wspomniano wcześniej, ISR to sekcje kodu wykonywane przez mikrokontroler, a nie przez FreeRTOS. Co prowadzi do nieoczekiwanego zachowania jądra. Z tego powodu konieczne jest zminimalizowanie czasu wykonania ISR. Jedną ze strategii skrócenia czasu wykonania jest użycie semaforów binarnych oferowanych przez FreeRTOS. Semafor binarny może być użyty do odblokowania zadania za każdym razem, gdy wystąpi określone przerwanie. W ten sposób część kodu wykonywanego w ISR może zostać znacznie zredukowana, a zarządzanie przerwaniem w dużej mierze wróci do odblokowanego zadania. W ten sposób odroczyliśmy proces przerwania do prostego zadania.

Jeśli przerwanie okaże się krytyczne, wtedy priorytet zadania zarządzania przerwaniami można zdefiniować tak, aby zawsze wywłaszczać inne zadania systemu.

Zawieszenie przerw

FreeRTOS umożliwia ochronę sekcji kodu należących do zadania przed jakąkolwiek zmianą kontekstu, działaniem harmonogramu, a nawet wywołaniem przerwania; te fragmenty kodu są nazywane sekcjami krytycznymi . Użycie sekcji krytycznych może być skuteczne w poszanowaniu niepodzielności niektórych instrukcji. Niemniej jednak te krytyczne sekcje powinny być używane z ostrożnością, ponieważ podczas ich wykonywania system pozostaje statyczny i całkowicie nieaktywny w stosunku do innych krytycznych zadań, które byłyby blokowane lub w przypadku przerwań sygnalizujących krytyczne zdarzenia zewnętrzne.

Aby zdefiniować fragment kodu jako sekcję krytyczną, wystarczy umieścić go między dwiema instrukcjami początku i końca sekcji krytycznej: taskENTER_CRITICAL () i taskEXIT_CRITICAL () .

Zarządzanie pamięcią

FreeRTOS jądro musi dynamicznie przydziela RAM pamięć za każdym razem zadanie , A kolejka lub Semafor jest tworzony. Użycie tradycyjnych metod Malloc() i Free() jest nadal możliwe, ale może stwarzać pewne problemy, ponieważ nie są one deterministyczne i mogą cierpieć na zbyt fragmentaryczną pamięć. Dlatego we FreeRTOS istnieją dwie metody wykorzystujące te same prototypy: pvPortMalloc() i vPortFree() .

Każdy z nich jest realizowany w trzech różnych sposobów opisanych w plikach Heap_1.c , Heap_2.c i Heap_3.c ale użytkownik może swobodnie definiować własne funkcje.

Stała configTOTAL_HEAP_SIZE zdefiniowana w pliku konfiguracyjnym FreeRTOSConfig.h

Pierwsze wdrożenie

Ta wersja nie definiuje metody zwalniania miejsca w pamięci RAM.

Pamięć jest podzielona na tablicę o rozmiarze configTOTAL_HEAP_SIZE (w bajtach) o nazwie „stos FreeRtos”.

Gdy jądro musi przydzielić pamięć, rezerwuje dwa wolne miejsca na to samo zadanie. Pierwsza jest używana dla TCB, a druga reprezentuje kolejkę. Ponieważ przestrzeń pamięci dla zadań nigdy nie jest zwalniana, stos zapełnia się do momentu wyczerpania dostępnego miejsca.

Druga realizacja

Ta reprezentacja różni się od pierwszej tym, że posiada metodę vPortFree() , która zwalnia pamięć przydzieloną do zadania i może ponownie przydzielić ją do innego zadania. Rozmiar bloku pamięci nowego zadania musi być co najwyżej równy rozmiarowi bloku starego zadania.

Trzecia realizacja

Jest to tylko redefinicja Malloc() i Free(), ale gdzie bezpieczeństwo zostało zwiększone przez zawieszenie wszystkich zadań na czas operacji na pamięci.

Charakterystyka

Obsługiwane architektury sprzętowe

Świadczone usługi i obszary zastosowań

Dzięki bardzo małemu rozmiarowi pamięci i portowi na wielu architekturach sprzętowych FreeRTOS jest używany głównie jako wbudowany system operacyjny. Został zaimplementowany na urządzeniach mobilnych i jest często używany na procesorach ARM.

Będąc systemem operacyjnym zorientowanym wyłącznie w czasie rzeczywistym, dostarczanym bez aplikacji, często służy jako baza do rozwoju określonych i/lub zastrzeżonych interfejsów API. Jest zatem stosowany w wielu różnych dziedzinach, w których ograniczenia czasu rzeczywistego są silne, takich jak na przykład urządzenia do nadzoru medycznego, narzędzia kontroli sejsmicznej i środowiskowej, a nawet sterowanie urządzeniami przemysłowymi i robotami. Jego funkcje zarządzania zadaniami zapewniają integralność danych gromadzonych w czasie rzeczywistym przy użyciu najwyższych poziomów priorytetów.

Dziedziną techniczną, w której ten system czasu rzeczywistego jest najczęściej używany, jest sieć, aw szczególności transmisja danych w sieciach bezprzewodowych. W przypadku sieci o bardzo wysokiej częstotliwości, takich jak WPAN , na architekturach sprzętowych o bardzo małej pojemności pamięci, podczas wymiany systemów z pojedynczą pętlą występują zjawiska przepełnienia . Jednak realizacja tych wymian w postaci różnych zadań komplikuje rozwój. Dzięki zarządzaniu priorytetami i harmonogramowi wielozadaniowości FreeRTOS eliminuje tego typu problemy. Każde zadanie posiadające zarezerwowany blok, zjawisko przepełnienia jest eliminowane, ponieważ nie ma już przepełnienia pamięci z powodu braku zasobów.

W przypadku aplikacji kontrolnych, takich jak śledzenie wzroku w oparciu o wbudowany sprzęt z ograniczonymi zasobami, FreeRTOS zapewnia rdzeń podstawowego systemu zarządzającego sprzętem, umożliwiając dodawanie określonych aplikacji. Tutaj znowu, przede wszystkim harmonogram i jego zarządzanie zadaniami i system priorytetów są niezbędne dla tego typu aplikacji. Oprogramowanie sprzętowe tego urządzenia mobilnego składa się z 3 warstw, warstwy HAL, która zarządza warstwą abstrakcji sprzętu, diody LED, która zarządza dodatkowymi komponentami procesora oraz TAL, która jest częścią zadań, która zarządza FreeRTOS. Ten rodzaj aplikacji ma na celu dostosowanie się do użytkownika zgodnie z tymi reakcjami postrzeganymi przez ruchy jego oczu.

FreeRTOS jest również szeroko stosowany do implementacji stosu sieciowego i często jest kojarzony z uIP. W przypadku urządzeń mobilnych, takich jak telefony, można go nawet znaleźć do zarządzania wideo. Jest również często używany w implementacjach warstwy sieci MAC, takich jak szeroko stosowany protokół 802.15.4 dla bezprzewodowych sieci czujników. Jedną z mocnych stron FreeRTOS jest również jego aspekt open-source oraz fakt, że pozwala na implementację bardzo lekkich i łatwych do przenoszenia warstw sieci IP, takich jak uIP czy lwIP.

Kolejnym ważnym obszarem zastosowania jest bezprzewodowa sieć czujników . Systemy te składają się z zestawu czujników przesyłających swoje dane do węzła, aby ewentualnie przesłać je do systemu centralnego. Ten rodzaj sieci jest obecny w medycynie do monitorowania pacjentów lub w rolnictwie do lokalizowania i monitorowania gospodarstw.

FreeRTOS to system operacyjny czasu rzeczywistego z wyboru w tej dziedzinie ponieważ czujniki zużywają bardzo mało energii i mają bardzo ograniczone zasoby pamięci RAM.

Pobór mocy jest również argumentem przemawiającym za FreeRTOS. Urządzenia mobilne wszelkiego rodzaju mają to zasadnicze ograniczenie, a ten system operacyjny umożliwia przetwarzanie w czasie rzeczywistym przy jednoczesnym zapewnieniu minimalnego zużycia energii.

Dzięki konwergencji różnych technologii i ich miniaturyzacji, FreeRTOS umożliwia połączenie prostych i wydajnych implementacji baterii sieciowych z potrzebami oszczędzania energii. Dobrym przykładem są nowe urządzenia mobilne, takie jak telefony. To rozwiązanie programowe umożliwia również znaczne obniżenie kosztów produkcji.

Skupiając się na wielu architekturach, a wraz z rozwojem kart w szczególności opartych na kartach sieciowych integrujących układy FPGA , FreeRTOS umożliwia posiadanie systemów z dostosowanym systemem pozwalającym skupić się na ostatecznych celach projektu.

Jednak będąc na licencji GPL, nawet jeśli pozwala na tworzenie zastrzeżonych aplikacji, jego kod źródłowy musi pozostać otwarty i dlatego jest uprzywilejowany w dziedzinie badań i edukacji. Jego zastrzeżeni konkurenci, tacy jak QNX, są najczęściej wybierani w świecie przemysłowym.

Istnieje również wiele różnych zastosowań w dziedzinie edukacji. FreeRTOS służy do badania wdrażania harmonogramu, zarządzania zadaniami i programowania modułowego. Umożliwia także tworzenie aplikacji z dziedziny elektroniki, takich jak odczyt temperatury i jej wyświetlanie.

FreeRTOS zrodził również frameworki dzięki otwartemu kodowi, niewielkim rozmiarom, skalowalności i rozszerzalności. Niektóre z tych ram są wykorzystywane w przemyśle motoryzacyjnym

Alternatywne rozwiązania

Odmiany FreeRTOS

Projekt FreeRTOS zrodził dwie wersje systemów operacyjnych czasu rzeczywistego opartych na jądrze FreeRTOS: OpenRTOS i SafeRTOS.

OpenRTOS

OpenRTOS to komercyjna wersja FreeRTOS, która zawiera zestaw sterowników połączeń USB, system plików FAT oraz stos TCP/IP. Licencja komercyjna zwalnia użytkowników OpenRTOS z obowiązku publikowania swoich modyfikacji do jądra FreeRTOS oraz oferuje im komercyjne wsparcie i zabezpieczenia niezbędne dla ich osiągnięć.

OpenRTOS jest przez globalną firmą inżynierską A licencją Real Time Engineers Ltd .

SafeRTOS

SafeRTOS to system operacyjny czasu rzeczywistego dla rynku systemów krytycznych . Został opracowany przez firmę WHIS (systemy wysokiej integralności WITTENSTEIN) we współpracy z Real Time Engineers Ltd .

SafeRTOS i FreeRTOS mają ten sam algorytm planowania, ten sam interfejs API, te same wymagania dotyczące pamięci RAM i ROM i działają na tych samych typach mikrokontrolerów. Zostały one jednak opracowane inaczej iz różnymi celami.

FreeRTOS był przedmiotem badania HAZOP, które zidentyfikowało kilka słabości funkcjonalnych i behawioralnych związanych z interfejsem API lub możliwymi błędami użytkownika systemu. Aby zaradzić tym słabościom, SafeRTOS został opracowany w cyklu rozwojowym SIL poziomu 3 normy IEC 61508. SafeRTOS posiada certyfikat SIL3 wydany przez niemiecką jednostkę certyfikującą i normalizacyjną TUV (Technischer Überwachungs-Verein).

Jedną z wielkich osobliwości SafeRTOS jest jego rozmiar pamięci, który nie przekracza 14 KB, co pozwala na umieszczenie go bezpośrednio w pamięci ROM mikrokontrolera. Ponadto, po zaimplementowaniu w pamięci ROM, kod SafeRTOS może być używany tylko w początkowej konfiguracji i nie można go zmienić, co eliminuje możliwe awarie systemu związane z błędami użytkownika oraz ułatwia certyfikację i walidację systemu opartego na jądrze SafeRTOS.

SafeRTOS jest używany w kilku systemach komercyjnych, w tym w niektórych mikrokontrolerach Stellaris ARM firmy Texas Instruments .

SafeRTOS jest przez globalną firmą inżynierską A licencją Real Time Engineers Ltd .

Nagrody

  • Najczęściej używany system operacyjny czasu rzeczywistego w 2011 i 2012 roku.
  • System operacyjny czasu rzeczywistego rozważany jako przyszły projekt w 2011 i 2012 roku.

Uwagi i referencje

Bibliografia

  1. "  Wydanie FreeRTOSv202012.00-LTS  " ,15 grudnia 2020 r.(dostęp 31 marca 2021 )
  2. (en-US) “  Ogłaszamy wersję 10 jądra FreeRTOS | Amazon Web Services  ” , Amazon Web Services ,29 listopada 2017 r.( przeczytaj online , konsultacja 30 czerwca 2018 r. )
  3. Melot 2009+ , s.  4
  4. Kontakt, wsparcie i reklama dla FreeRTOS
  5. (en-US) „  Ogłaszamy Amazon FreeRTOS — umożliwia miliardom urządzeń bezpieczne korzystanie z chmury | Amazon Web Services  ” , Amazon Web Services ,29 listopada 2017 r.( przeczytaj online , konsultacja 30 czerwca 2018 r. )
  6. FreeRTOS, strona główna
  7. FreeRTOS, Strona domowa: Dlaczego FreeRTOS? 2007
  8. Barry 2009 , s.  15
  9. Melot 2009+ , str.  08
  10. Barry 2009 , s.  28
  11. Barry 2009 , s.  04
  12. Barry 2009 , s.  05
  13. Barry 2009 , s.  44
  14. Barry 2009 , s.  19
  15. Melot 2009+ , s.  09
  16. Barry 2009 , s.  29
  17. Svec 2012
  18. Barry 2009 , s.  32
  19. Barry 2009 , s.  42
  20. Barry 2009 , s.  47
  21. Melot 2009+ , s.  12
  22. Barry 2009 , s.  80
  23. Barry 2009 , s.  83
  24. Barry 2009 , s.  105
  25. Melot 2009+ , s.  16
  26. Melot 2009+ , s.  17
  27. Barry 2009 , s.  95
  28. Barry 2009 , s.  94
  29. Barry 2009 , s.  69
  30. Melot 2009+ , s.  18
  31. Barry, 2009 , str.  135
  32. Barry 2009 , s.  138
  33. Barry 2009 , s.  139
  34. Woodcock 2009 , s.  24
  35. Ju 2009 , s.  2
  36. Wauthy 2010 , s.  3
  37. Bulling 2008 , s.  3
  38. Szczęsny 2009 , s.  3
  39. Borchert 2012 , s.  446
  40. Schoofs 2009 , s.  3
  41. Chen 2010 , s.  3
  42. Mera 2010
  43. Borchert 2012 , s.  435
  44. Huangfu 2009 , s.  2
  45. Tardieu 2009 , s.  4
  46. Machanick 2011 , s.  2
  47. Vanhatupa 2010 , s.  2
  48. Salminen 2011 , s.  4
  49. Inam 2011
  50. Widziane w 2012 r. , s.  7
  51. OpenRTOS, strona główna
  52. SafeRTOS, strona główna
  53. Jan 2008 , s.  3728
  54. SafeRTOS, Przegląd
  55. SafeRTOS, Certyfikacja
  56. Texas Instruments SafeRTOS
  57. Texas Instruments gwiezdne
  58. EETIMES Wbudowany Market Study 8 kwietnia 2011

Załączniki

Bibliografia

  • (pl) Richard Barry , FreeRTOS - BEZPŁATNY RTOS dla małych systemów wbudowanych czasu rzeczywistego ,2005, 112  s. ( przeczytaj online )
  • (pl) Richard Barry , Korzystanie z jądra czasu rzeczywistego FreeRTOS — praktyczny przewodnik ,2009, 163  s. ( prezentacja online )
  • (en) Amy Brown , Greg Wilson i Christopher Svec , Architektura aplikacji Open Source , tom.  2: Struktura, skala i jeszcze kilka nieustraszonych hacków ,2012, 390  pkt. ( ISBN  9781105571817 , czytaj online ) , rozdz.  3 („FreeRTOS”)
  • (en) Yan Meng , Johnson Kerry , Brian Simms i Matthew Conforth , „  A Generic Architecture of Modular Embedded System for Miniature Mobile Robots  ” , Intelligent Robots and Systems, 2008. IROS 2008. Międzynarodowa konferencja IEEE/RSJ ,2008, s.  3725-3730 ( ISBN  978-1-4244-2058-2 , DOI  10.1109 / IROS.2008.4651001 )
  • (en) Ramon Serna Oliver , Ivan Shcherbakov i Gerhard Fohler , „  An Operating System Abstraction Layer for Portable Applications in Wireless Sensor Networks  ” , Proceedings of the ACM Symposium 2010 on Applied Computing ,2010, s.  742-748 ( ISBN  978-1-60558-639-7 , DOI  10.1145 / 1774088.1774243 )
  • (en) João F. Ferreira , Guanhua He i Shengchao Qin , „  Automated Verification of the FreeRTOS Scheduler in HIP/SLEEK  ” , Teoretyczne aspekty inżynierii oprogramowania (TASE), Szóste Międzynarodowe Sympozjum 2012 ,2012, s.  51 - 58 ( DOI  10.1109 / TASE.2012.45 )
  • (en) Xiaohan Ji , Dapeng Zhang i Chunmeng Wang , „  Urządzenie do odczytu liczników watogodzin dla dodatku na energię elektryczną  ” , Sztuczna inteligencja, nauka o zarządzaniu i handel elektroniczny (AIMSEC), II międzynarodowa konferencja z 2011 r. ,2011, s.  3695 - 3697 ( DOI  10.1109 / AIMSEC.2011.6009920 )
  • (pl) Bo Qu i Daowei Fan , „  Projektowanie systemu zdalnego monitorowania i rejestracji danych w oparciu o ARM  ” , Industrial and Information Systems (IIS), 2010 II Międzynarodowa Konferencja ,2010, s.  252 - 255 ( DOI  10.1109 / INDUSIS.2010.5565698 )
  • (en) Zhuan Yu , Jie Wu , MingPu Xie i Yang Kong , „  Wdrożenie rozproszonego systemu akwizycji danych w czasie rzeczywistym o wysokiej precyzji  ” , Konferencja czasu rzeczywistego, 2009. RT '09. 16. IEEE-NPSS ,2009, s.  446 - 449 ( DOI  10.1109 / RTC.2009.5321600 )
  • (en) Jinsik Kim i Pai H Chou , „  Energy-Efficient Progressive Remote Update for Flash-Based Firmware of Networked Embedded Systems  ” , ACM Transactions on Design Automation of Electronic Systems ,2010, s.  7: 1-7: 26 ( ISSN  1084-4309 , DOI  10.1145 / 1870109.1870116 )
  • (en) David Déharbe , Stephenson Galvão i Anamaria Martins Moreira , „  Formalizing FreeRTOS: First Steps  ” , Formal Methods: Foundations and Applications (Wykłady z informatyki) ,2009, s.  101-11703 ( ISBN  978-3-642-10451-0 , DOI  10.1007 / 978-3-642-10452-7_8 )
  • (en) Florin Catalin Braescu , Lavinia Ferariu i Andrei Franciuc , „  Monitoring CAN Performances in Distributed Embedded Systems  ” , System Theory, Control and Computing (ICSTCC), 2011 15. Międzynarodowa Konferencja ,2011, s.  1-6
  • (en) Tao Xu , „  Porównanie wydajności FreeRTOS i abstrakcji sprzętu  ” , Niepublikowana praca doktorska, Uniwersytet Techniczny w Eindhoven ,2008
  • (en) Roman Glistvain i Mokhtar Aboelaze , „  Romantiki OS - A single stack Multitasking Operating System for Resource Limited Embedded Devices  ” , Informatics and Systems (INFOS), 2010 VII Międzynarodowa Konferencja ,2010, s.  1-8
  • (en) Rafia Inam Jukka Maki-Turja Mikael Sjödin , SMH Ashjaei i Sara Afshar , „  Wsparcie w FreeRTOS hierarchicznych Scheduling  ” , nowymi technologiami i automatyki przemysłowej (ETFA) 2011 IEEE 16. konferencja ,2011, s.  1-10 ( DOI  10.1109 / ETFA.2011.6059016 )
  • (en) Nicolas Melot , „  Systemy operacyjne dla urządzeń wbudowanych  ” , Studium systemu operacyjnego: FreeRTOS (praca dyplomowa) , 2009+, s.  1-39 ( przeczytaj online )
  • (en) Aamir Mahmood i Riku Jãntti , „  Dokładność synchronizacji czasu w bezprzewodowych sieciach czujników czasu rzeczywistego  ” , Communications (MICC), 2009 IEEE 9th Malaysia International Conference ,2009, s.  652 - 657 ( DOI  10.1109 / MICC.2009.54311415 )
  • (en) Per Lindgren , Johan Eriksson , Simon Aittamaa i Johan Nordlander , „  TinyTimber, Reactive Objects in C for Real-Time Embedded Systems  ” , Design, Automation and Test in Europe, 2008. DATA '08 ,2008, s.  1382 - 1385 ( DOI  10.1109 / DATA.2008.4484933 )
  • (en) Jim Woodcock , Peter Gorm Larsen , Juan Bicarregui i John Fitzgerald , „  Metody formalne: praktyka i doświadczenie  ” , ACM Comput. Surv. 41, 4, art. 19 ,2009, s.  19: 1-19: 36 ( DOI  10.1145 / 1592434.1592436 )
  • (en) Dieu-Huong Vu i Toshiaki Aoki , „  Wiernie formalizując specyfikację systemu operacyjnego OSEK/VDX  ” , SoICT '12 Proceedings of the Third Symposium on Information and Communication Technology ,2012, s.  13 - 20 ( ISBN  978-1-4503-1232-5 , DOI  10.1145 / 2350716.250721 )
  • (en) Jean-François Wauthy i Laurent Schumacher , „  Wdrożenie stosu protokołów IEEE 802.15.4-2006 na instrumencie Texas CC2430  ” , Proceedings of 7th ACM Workshop on Performance assessment of wireless ad hoc, sensor and wszechobecnych sieci , Oprócz tego będziesz musiał dowiedzieć się o tym więcej.2010, s.  33 - 39 ( ISBN  978-1-4503-0276-0 , DOI  10,1145 / 1868589,1868596 )
  • (en) Arto Salminen , Juha-Matti Vanhatupa i Hannu-Matti Järvinen , „  Ramowy kurs programowania wbudowanego  ” , Materiały z 11. Międzynarodowej Konferencji Koli Calling na temat badań edukacji komputerowej ,2011, s.  54 - 59 ( ISBN  978-1-4503-1052-9 , DOI  10.1145 / 2094131.2094142 )
  • (en) Andreas Bulling , Daniel Roggen i Gerhard Tröster , „  To w twoich oczach: w kierunku świadomości kontekstu i mobilnego interfejsu HCI przy użyciu gogli EOG do noszenia  ” , Proceedings of the 10th international Conference on Ubiquitous computing ,2008, s.  84-93 ( ISBN  978-1-60558-136-1 , DOI  10.1145 / 1409635.1409647 )
  • (en) Samuel Tardieu et Alexis Polti , „  Uzupełnianie Ady innymi językami programowania  ” , Proceedings z corocznej międzynarodowej konferencji ACM SIGada na temat Ady i technologii pokrewnych ,2009, s.  105 - 114 ( DOI  10.1145 / 1653616.1647444 )
  • (en) Juha-Matti Vanhatupa , Arto Salminen i Hannu-Matti Järvinen , „  Organizowanie i ocena kursu w zakresie programowania wbudowanego  ” , Materiały z 10th Koli Calling International Conference on Computing Education Research ,2010, s.  112 - 117 ( DOI  10.1145 / 1930464.1930484 )
  • (en) David Szczęsny , Sebastian Hessel , Felix Bruns i Attila Bilgic , „  Przyspieszenie sprzętowe w locie do przetwarzania stosów protokołów w urządzeniach mobilnych nowej generacji  ” , Materiały z 7. międzynarodowej konferencji IEEE / ACM na temat współprojektowania sprzętu / oprogramowania i systemu synteza ,2009, s.  155 - 162 ( ISBN  978-1-60558-628-1 , DOI  10,1145 / 1629435,1629457 )
  • (en) Yu-Ting Chen , Ting-Chou Chien i Pai H. Chou , „  Enix: lekki dynamiczny system operacyjny dla ściśle ograniczonych bezprzewodowych platform czujnikowych  ” , Materiały z 8. konferencji ACM poświęcone wbudowanym systemom czujników sieciowych ,2010, s.  183 - 196 ( DOI  10.1145 / 1869983.1870002 )
  • (en) Philip Machanick , „  Zasady projektowania dla informatyki kontaktowej  ” , Proceedings of the South African Institute of Computer Scientists and Information Technologists Conference on Knowledge, Innovation and Leadership in a Different, multidyscyplinarne środowisko ,2011, s.  306 - 309 ( DOI  10.1145 / 207221.2072264 )
  • (en) Wei Huangfu , Limin Sun i Xinyun Zhou , „  NISAT: środowisko testowe bez efektu ubocznego dla bezprzewodowych sieci czujnikowych  ” , Materiały z 7. Konferencji ACM na temat wbudowanych sieciowych systemów czujnikowych ,2009, s.  313 - 314 ( ISBN  978-1-60558-519-2 , DOI  10.1145 / 1644038.1644077 )
  • (pl) Per Lindgren , Johan Eriksson , Simon Aittamaa i Johan Nordlander , „  TinyTimber, reaktywne obiekty w C dla systemów wbudowanych czasu rzeczywistego  ” , Materiały z konferencji „Projektowanie, automatyzacja i testowanie w Europie” ,2008, s.  1382 - 1385 ( ISBN  978-3-9810801-3-1 , DOI  10,1145 / 1403375,1403708 )
  • (w) Zhuan Yu; Jie Wu; Mingpu Xie; Yang Kong Yu , Jie Wu , Mingpu Xie i Yang Kong , „  Wdrożenie rozproszonego systemu akwizycji danych w czasie rzeczywistym o wysokiej precyzji  ” , Konferencja czasu rzeczywistego, 2009. RT '09. 16. IEEE-NPSS ,2009, s.  446 - 449 ( DOI  10.1109 / RTC.2009.5321600 )
  • (en) DE Mera i NG Santiago , „  Low Power Software Techniques for Embedded Systems Running Real Time Operating Systems  ” , Midwest Symposium on Circuits and Systems (MWSCAS), 2010 53. IEEE International ,2010, s.  1061 - 1064 ( DOI  10.1109 / MWSCAS.2010.5548830 )
  • (en) Anthony Schoofs , Charles Daymand , Robert Sugar , Ulrich Mueller , Andreas Lachenmann , Syed M. Kamran , Alain Gefflaut , Lasse Thiem i Mario Schuster , „  Streszczenie plakatu: Stanowisko testowe oparte na IP do monitorowania stada  ” , Proceedings of the 2009 International Konferencja nt. Przetwarzania Informacji w Sieciach Sensorowych ,2009, s.  365-366 ( ISBN  978-1-4244-5108-1 )
  • (pl) Christoph Borchert , Daniel Lohmann i Olaf Spinczyk , „  CiaO/IP: wysoce konfigurowalny stos IP zorientowany na aspekt  ” , Materiały z 10. międzynarodowej konferencji Systemy, aplikacje i usługi mobilne ,2012, s.  435-448 ( ISBN  978-1-4503-1301-8 , DOI  10.1145 / 2307636.2307676 )

Powiązane artykuły

Linki zewnętrzne