FreeRTOS | |
Család | Valós idejű operációs rendszer |
---|---|
Core típus | Mikronukleus |
Projekt állapota | Fejlesztés alatt |
Letét | github.com/FreeRTOS/FreeRTOS |
Platformok | 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, Fujitsu MB91460 sorozat, Fujitsu MB96340 sorozat, Nios II (en) |
Cég / Fejlesztő |
Amazon, Richard Barry és a FreeRTOS Team |
Engedély | MIT , korábban módosított GNU GPL |
Forrásállamok | Ingyenes szoftver a beágyazott rendszer |
Beírva | VS |
Legújabb stabil verzió | 202012.00-LTS (2020. december 15) |
Weboldal | www.freertos.org |
A FreeRTOS egy kis méretű , hordozható , megelőző és nyílt forráskódú valós idejű operációs rendszer ( RTOS ) a mikrokontrollerek számára . Több mint 40 különböző architektúrába került. Richard Barry és a FreeRTOS Team 2003-ban hozta létre, és ma a valós idejű operációs rendszerek piacán a legelterjedtebbek közé tartozik.
A FreeRTOS 2017. november 29. óta ingyenesen elérhető MIT licenc alatt . A korábbi verziók módosított GPL licenc alatt voltak elérhetőek, és jogdíjak megfizetése nélkül is használhatók, ez a licenc nem kötelezi a fejlesztőket az alkalmazásszoftverük kódjának közzétételére, de meg kell tartaniuk a FreeRTOS Open Source rendszermagja. Kereskedelmi engedélyt ad hoc támogatással (OpenRTOS) kínál a High Integrity Systems vállalat is.
Az egyszerre futó feladatok számát és prioritását csak a hardver korlátozza. Az ütemezés egy Szemafororák és Mutex alapú sorbanállási rendszer . A Round-Robin modellen alapszik , prioritáskezeléssel. Nagyon kompakt kialakítású, csak néhány C nyelvű fájlból áll, és nem valósít meg hardver illesztőprogramot .
Az alkalmazási területek meglehetősen tágak, mivel a FreeRTOS fő előnyei a valós idejű végrehajtás, a nyílt forráskód és a nagyon kicsi méret. Ezért elsősorban beágyazott rendszerekhez használják , amelyeknek helyigénye van a kód számára, de videofeldolgozó rendszerekhez és hálózati alkalmazásokhoz is, amelyek valós idejű korlátokkal rendelkeznek.
A FreeRTOS egy ingyenes és nyílt forráskódú, valós idejű operációs rendszer, amelyet eredetileg a Real Time Engineers Ltd. fejlesztett ki.
2017-ben a projektet és fejlesztői csapatát felvásárolta az Amazon. Létrejött a FreeRTOS Amazon FreeRTOS nevű saját verziója is, beleértve az Amazon AWS felhővel való integrációt elősegítő könyvtárak sorozatát.
Több mint 40 különböző architektúrába és 15 építési láncba került . 2019-ben több mint 185 500 alkalommal töltötték le.
Kialakítása szándékosan minimalista, így kis rendszerekre is telepíthető. A bináris kép a mag súlya között 4 KB és 9KB-og (4.3 KB összeállított ARM7). A minimális készlet csak néhány funkcióval rendelkezik a feladatok és a memória kezelésére. Ezenkívül sorok , szemaforok és mutexek kerülnek megvalósításra.
A 7.3.0 verzió rendszermagja csak öt, C nyelven kódolt fájlból áll . Az Assembler szakaszai lehetővé teszik a FreeRTOS kompatibilitásának biztosítását a különböző hardverarchitektúrákkal.
Korlátlan számú feladat hajtható végre egyszerre és korlátozás nélkül.
A FreeRTOS-t nagyon könnyűnek tervezték, 4KiB-től 9 KB-ig egy tipikus RTOS- rendszermag bináris kép esetén . Maga a kernel csak három forrásfájlból áll, C nyelven írva .
A feladatütemezés fő célja annak eldöntése, hogy a "kész" állapotban lévő feladatok közül melyiket hajtsa végre. E választáshoz a FreeRTOS ütemező kizárólag a feladatok prioritásán alapul.
A FreeRTOS-ban lévő feladatok hozzárendelésükhöz vannak hozzárendelve, egy prioritással, amelyet egész szám képvisel. A legalacsonyabb szint nulla, és szigorúan a tétlen feladathoz kell fenntartani . A felhasználónak lehetősége van felülírni ezt a szintet egy egyéni prioritással az konstans módosításával : tskIDLE_PRIORITY . A prioritási szintek maximális számát az állandó határozza meg: tskMAX_PRIORITIES . Több feladat is tartozhat ugyanahhoz a prioritási szinthez.
A FreeRTOS-ban nincs automatikus prioritáskezelési mechanizmus. Egy feladat prioritása csak a fejlesztő kifejezett kérésére változtatható meg.
A feladatok egyszerű funkciók, amelyek általában végtelen ciklusban futnak, és a következő általános struktúrát követik:
void vATaskFunction( void *pvParameters ) { for( ;; ) { -- Ajouter le code de votre tâche ici -- } }
Abban az esetben, ha egy mikrovezérlő csak egy maggal rendelkezik, akkor bármikor csak egy feladat lesz végrehajtva. Az ütemező mindig biztosítja, hogy a futtatható állapotba való belépéshez a legmagasabb prioritású feladat legyen kiválasztva. Ha két feladat ugyanazt a prioritási szintet osztja meg, és mindkettő képes futtatni, akkor a két feladat felváltva fog futni az ütemező felébresztése ( körbefutás) függvényében .
A végrehajtandó feladat kiválasztásához az ütemezőnek magának végre kell hajtania és meg kell előznie a feladatot végrehajtási állapotban. Az ütemező felébresztésének biztosítása érdekében a FreeRTOS meghatároz egy "kullancs megszakítás" nevű időszakos megszakítást. Ez a megszakítás végtelen ideig fut egy bizonyos frekvencián, amelyet a FreeRTOSConfig.h fájlban az állandó határoz meg :
configTICK_RATE_HZ /* Fréquence d’exécution de la "tick interrupt" en Hz. */Ez az állandó leírja azt az időtartamot, amelyet az egyes feladatokra a minimumra osztanak vagy másként magyaráznak, az időzítő két ébresztését elválasztva.
Az ebben a szakaszban leírtak szerint a FreeRTOS tehát egy olyan RTOS, amely megelőző ütemezést használ a feladatok kezeléséhez. Választhatja azonban opcionálisan (ha az irányelv megkapja) a kooperatív ütemezést is . Ebben az ütemezési módban a végrehajtási kontextus megváltoztatása csak akkor történik meg, ha a végrehajtó feladat kifejezetten engedélyezi egy másik feladat futtatását (például egy Yield () meghívásával) vagy blokkolási állapotba lép. A feladatokat ezért soha nem előzik meg. Ez az ütemezési mód nagyban leegyszerűsíti a feladatok kezelését, sajnos kevésbé hatékony és kevésbé biztonságos rendszerhez vezethet.
A FreeRTOS hibrid ütemezést is használhat, megelőző ütemezéssel és kooperatív ütemezéssel. Ebben a módban a végrehajtási kontextus megváltoztatása megszakítás esetén is megtörténhet.
ÉhezésA FreeRTOS-ban a futtatásra kész legmagasabb prioritású feladatot mindig az ütemező választja ki. Ez éhínséghez vezethet . Ugyanis, ha a legmagasabb prioritású feladatot soha nem szakítják meg , akkor az összes alacsonyabb prioritású feladat soha nem fog futni. A FreeRTOS nem valósít meg semmilyen automatikus mechanizmust az éhezés jelenségének megakadályozására. A fejlesztőnek meg kell győződnie arról, hogy nincsenek olyan feladatok, amelyek monopolizálják a mikrovezérlő teljes végrehajtási idejét. Ehhez olyan eseményeket helyezhet el, amelyek meghatározott időre vagy egy másik esemény bekövetkeztéig megszakítják a magasabb prioritású feladatot, és így szabadon hagyják a mezőt az alacsonyabb prioritású feladatok végrehajtásához.
Az éhezés elkerülése érdekében a fejlesztő használhatja a monoton sebesség ütemezését (RMS). Ez egy prioritás-hozzárendelési technika, amely minden feladathoz egyedi prioritást rendel a végrehajtás gyakorisága szerint. A legmagasabb prioritást a legmagasabb végrehajtási gyakoriságú feladathoz rendeli, a legalacsonyabb prioritást pedig a legalacsonyabb gyakoriságú feladathoz. A monoton ütemezéssel történő ütemezés lehetővé teszi a feladatok ütemezhetőségének maximalizálását, de ezt továbbra is nehéz megvalósítani a nem teljesen periodikus feladatok jellege miatt.
A tétlen feladatA mikrovezérlőnek mindig legyen tennivalója. Más szóval, mindig futnia kell egy feladatnak. A FreeRTOS úgy kezeli ezt a helyzetet, hogy meghatározza az Idle feladatot, amely az ütemező indításakor jön létre. A legalacsonyabb kernelprioritást ehhez a feladathoz rendelték. Ennek ellenére a tétlen feladatnak több funkciója is lehet:
A FreeRTOS-ban az egyes feladatokat egy TCB (Feladatvezérlő blokk) írja le, amely tartalmazza a feladat megadásához és ábrázolásához szükséges összes információt.
Változók | Leírás |
---|---|
pxTopOfStack | Mutató az utolsó elemhez a verem tetején |
xGenericListItem | A TCB államok listájába (kész, blokkolt vagy felfüggesztett) felsorolásához használt lista tagja (xListItem ). |
xEventListItem | Listaelem (xListItem), amely a TCB elhelyezésére szolgál egy eseménylistában. |
uxPriority | Feladat prioritása |
pxStack | Mutató a folyamat verem elejére |
pxEndOfStack | Mutató a folyamatverem végéig |
uxTCBNumber | Verem mérete a változók számában |
pcTaskName | Minden TCB létrehozásakor növekvő szám (hibakereséshez) |
uxBasePriority | A feladathoz rendelt utolsó prioritás |
ulRunTimeCounter | Kiszámítja a feladat által végrehajtási állapotban töltött időt |
pxTaskTag | Lehetővé teszi címke hozzáadását a feladathoz. A címkét a naplók analóg vagy digitális kimeneteken keresztül történő végrehajtására használják a traceSWITCHED_IN () függvénynek köszönhetően. |
uxCriticalNesting | Lehetővé teszi a feladat kritikus szakaszainak beágyazási mélységének mentését. Minden alkalommal, amikor a feladat belép egy kritikus szakaszba, a változó növekszik, és csökken, amint a feladat elhagy egy kritikus részt.
Erre a változóra azért van szükség, mert lehetséges, hogy a feladat visszaadja az irányítást, amíg a kritikus szakaszban van. |
A FreeRTOS alatt álló feladatok 5 állapotban létezhetnek: "törölt", "felfüggesztett", "kész", "blokkolt" vagy "végrehajtás alatt".
A FreeRTOS-ban nincs olyan változó, amely kifejezetten megadná a feladat állapotát, cserébe a FreeRTOS állapotlistákat használ. A feladat jelenléte egy típusú állapotlistában meghatározza annak állapotát (kész, blokkolt vagy felfüggesztett). Mivel a feladatok gyakran megváltoztatják az állapotát, az ütemezőnek csak akkor kell áthelyeznie a feladatot (az ugyanahhoz a feladathoz tartozó elemet (xListItem)) az egyik állapotlistáról a másikra.
Feladat létrehozásakor a FreeRTOS létrehozza és kitölti a feladatnak megfelelő TCB-t, majd közvetlenül beszúrja a feladatot egy "Ready List" -be (olyan lista, amely hivatkozást tartalmaz az összes "Ready" állapotban lévő feladatra).
A FreeRTOS több "Kész listát" vezet, az egyes prioritási szintekhez tartozik egy lista. A következő végrehajtandó feladat kiválasztásakor az ütemező a "Kész listákat" elemzi a legmagasabb prioritástól a legalacsonyabbig.
Ahelyett, hogy kifejezetten meghatározná a "futó" állapotot vagy a hozzá társított listát, a FreeRTOS kern egy "pxCurrentTCB" változót ír le, amely azonosítja a végrehajtó folyamatot. Ez a változó a TCB-re mutat, amely megfelel a „Kész lista” egyikében található folyamatnak.
Egy feladat "blokkolt" állapotba kerülhet az olvasási / írási sor elérésekor, ha a sor üres / megtelt. Minden várólista-hozzáférési műveletet időtúllépéssel (xTicksToWait) konfigurálnak. Ha ez az időtúllépés értéke 0, akkor a feladat nincs blokkolva, és a várólista-hozzáférési művelet sikertelennek tekinthető. Ha az időkorlát nem nulla, a feladat „blokkolt” állapotba kerül, amíg a sor módosul (például egy másik feladattal). Miután a várólista-hozzáférési művelet lehetséges, a feladat ellenőrzi, hogy az időtúllépése nem járt-e le, és sikeresen befejezi a műveletet.
Egy feladat önként elhelyezhető "felfüggesztett" állapotban, ezt aztán az ütemező teljesen figyelmen kívül hagyja, és nem fog több erőforrást felemészteni, amíg azt nem távolítják el az állapotból, és nem állítják vissza "kész" állapotba.
Az utolsó állapot, amelyet egy feladat elvégezhet, a "törölt" állapot, erre az állapotra azért van szükség, mert a törölt feladat nem szabadítja fel azonnal az erőforrásait. A "törölt" állapotba kerülve az ütemező figyelmen kívül hagyja a feladatot, és egy másik "IDLE" nevű feladat felelős a "törölt" állapotban lévő feladatok által allokált erőforrások felszabadításáért.
Az 'IDLE' feladat az ütemező elindításakor jön létre, és a lehető legalacsonyabb prioritást kapja, amely késleltetett erőforrás- felszabaduláshoz vezet, ha más feladat nem fut.
A listák a leggyakrabban használt adatstruktúrák a FreeRTOS-ban. Feladatok szervezésére és ütemezésére, valamint sorok végrehajtására szolgálnak.
A FreeRTOS több struktúrát határoz meg a listák ábrázolása érdekében:
Az xLIST struktúrát a következőképpen definiáljuk:
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;Az xLIST_ITEM struktúra a következőképpen definiálható:
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. */ };A várakozási sorok azok a fő mechanizmusok, amelyek lehetővé teszik a feladatok kommunikációját és szinkronizálását egymással.
A várólista alapvető felépítését a következőképpen írják le:
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;
A sor véges számú, rögzített méretű elemet tartalmaz. A várakozási sor fizikai méretét az általa tartalmazható elemek maximális száma ( uxLength ) szorozva megszorozva az egyes elemek bájtjaival ( uxItemSize ).
A FreeRTOS-ban az adatok írása vagy elküldése a várólistára bájt byte-onként történő másolásával történik, annak típusától függetlenül, mert a mentett elem élettartama gyakran kevesebb, mint a sor élettartama. Az írási művelethez hasonlóan az adatok kiolvasását vagy fogadását is elvégezzük, ha byte-ból bájtra másoljuk azokat az adatokat, amelyek törlésre kerülnek a sorból.
A várólisták független objektumok, nincs hozzárendelés vagy tagság egy feladathoz. Ezek azok a struktúrák, amelyek lehetővé teszik a feladatok egymással való kommunikációját. Ezért egyszerre több olvasási és írási feladatuk lehet.
A sorok írási vagy olvasási műveletei lehetnek blokkoló vagy nem blokkoló műveletek. A nem blokkoló műveletek közvetlenül visszaállítják a sikeres vagy sikertelen állapotot a sorba. A blokkolási műveletek időzítéssel vannak beállítva, amely lehetővé teszi számukra a blokkolást, és meghatározza a maximális időt, amely alatt ebben az állapotban maradhatnak.
A FreeRTOS a sorokat használja a feladatok közötti kommunikáció eszközeként. A sorok azonban a feladatok szinkronizálását és versenyét is kezelik. Ezért ez a struktúra az erőforrás-kezelés alapvető eleme a FreeRTOS-ban.
A FreeRTOS főként két mechanizmus segítségével szinkronizálja a feladatokat: Semaphore és Mutex .
SzemaforokA FreeRTOS lehetővé teszi több elemű szemaforok létrehozását és használatát . A szemaforok sor formájában valósulnak meg, oly módon, hogy a szemafor elemeinek száma jelenti a maximális számú elemet, amelyet a sor tartalmazhat. A szemaforot reprezentáló sor nem menti az adatokat, csak a jelenleg elfoglalt bejegyzések számának rögzítésével foglalkozik. A sorban lévő elemek mérete tehát nulla (uxItemSize = 0). A szemaforhoz való hozzáférés csak növeli vagy csökkenti a sorban elfoglalt bejegyzések számát, és nem készül elemmásolás.
A FreeRTOS által a szemaforok kezelésére kínált API különbséget tesz az N-elem szemaforok és a bináris szemaforok között. A bináris szemaforok olyan sorokként tekinthetők, amelyek csak egy elemet tartalmazhatnak. A bináris szemafor tehát csak egyszer vehető fel, mielőtt elérhetetlenné válna, ellentétben egy n elemet tartalmazó, többször is felvehető szemaforral, amely lehetővé teszi például számos rendelkezésre álló erőforrás definiálását, vagy az események számának megszámlálását. végre kell hajtani.
MutexA Mutex egy megosztott erőforrás védelmére szolgál.
A Mutex megvalósítása a FreeRTOS-ban hasonló a bináris szemaforokhoz (sor formájában), azzal a különbséggel, hogy a Mutexet elfogadó feladatnak kötelezően vissza kell adnia. Ez úgy tekinthető, mint egy token és egy erőforrás társítása, egy feladat elveszi a tokent, és az erőforrást használja, majd a végén visszaküldi a tokent, ugyanakkor más kiegészítő token nem társítható a feladathoz.
Egy másik fő különbség a Mutex és a bináris szemaforok között a FreeRTOS-ban az elsőbbségi öröklődési rendszer. Amikor több feladat kéri a Mutex felvételét, a Mutex tulajdonosának prioritása pillanatnyilag a legmagasabb prioritás értékére van állítva a kiadásra váró feladatok közül. Ennek a technikának az a hatása, hogy megelőzi a prioritás visszafordulásának veszélyét jelentő jelenségeket, még akkor is, ha ez nem garantálja a tévedhetetlen biztonságot e jelenségekkel szemben.
A megszakítás pusztán hardveres mechanizmus, amelyet az utóbbi hajt végre és kezdeményez. A FreeRTOS csak a megszakítások kezelésére kínál módszert, és megszakításokat is kezdeményezhet egy hardveres utasítás meghívásával.
A FreeRTOS nem ír elő különféle stratégiát a fejlesztők számára a megszakítások kezelésére, de számos eszközt kínál, hogy a választott stratégia könnyen megvalósítható és fenntartható legyen.
A megszakítási rutinok (ISR) olyan funkciók, amelyeket maga a mikrovezérlő hajt végre, és amelyeket a FreeRTOS nem kezelhet, amelyek bizonyos problémákat okozhatnak. Ezért a megszakítási rutinok nem használhatják a szokásos FreeRTOS API függvényeket, amelyeket bármely más alapfeladat használhat. Azonban FreeRTOS meghatározza egy csoportja funkciók kifejezetten ISR, például egy ISR fogja használni a xSemaphoreGiveFromISR () függvény helyett xSemaphoreGive () , hasonlóképpen, akkor használja a xQueueReceiveFromISR () függvény helyett xQueueReceive () .
A megszakításkezelési házirend megadása és az ISR-specifikus kernelfunkciókhoz való hozzáférés kezelése érdekében a FreeRTOS állandókat határoz meg a FreeRTOSConfig.h konfigurációs fájlban :
Ennek a két állandónak a meghatározása lehetővé teszi az ISR kezelési politikájának meghatározását a prioritások szintje szerint:
A két előző konstans meghatározása az ISR-hez hozzáadja a megszakítások fészkelésének ( ang . Interrupt Nesting) sajátosságát is . A megszakítás fészkelése annak a lehetősége, hogy egy második megszakítás egyidejűleg történjen, amikor egy másik megszakítást egy ISR feldolgoz. Ez a második megszakítás megelőzheti az elsőt, ha magasabb prioritással rendelkezik.
Meg kell jegyezni, hogy a megszakítások prioritásait a mikrovezérlő architektúrája határozza meg. Ezek olyan hardverprioritások, amelyek nincsenek kapcsolatban a FreeRTOS feladatokhoz hozzárendelhető szoftverprioritásokkal.
Halasztott megszakításokAmint azt korábban meghatároztuk, az ISR-ek a mikrovezérlő által végrehajtott kódrészek, nem pedig a FreeRTOS által. Ez a kernel váratlan viselkedéséhez vezet. Ezért minimalizálni kell az ISR végrehajtási idejét. A végrehajtási idő csökkentésének egyik stratégiája a FreeRTOS által kínált bináris szemaforok használata. Bináris szemafor segítségével feloldhat egy feladatot, amikor egy adott megszakítás történik. Így az ISR-ben végrehajtott kódrész nagymértékben csökkenthető, és a megszakítás kezelése nagymértékben visszatér a fel nem oldott feladathoz. Így a megszakítási folyamatot egyszerű feladatra halasztjuk .
Ha a megszakítás kritikusnak bizonyul, akkor a megszakításkezelési feladat prioritása úgy határozható meg, hogy mindig megelőzze a rendszer egyéb feladatait.
A megszakítások felfüggesztéseA FreeRTOS lehetővé teszi, hogy a feladathoz tartozó kódrészeket megvédjük a kontextus bármilyen változásától, az ütemező működésétől vagy akár egy megszakítástól; ezeket a kódrészeket kritikus szakaszoknak nevezzük . A kritikus szakaszok alkalmazása hatékony lehet bizonyos utasítások atomosságának tiszteletben tartása szempontjából. Mindazonáltal ezeket a kritikus szakaszokat körültekintően kell használni, mert végrehajtásuk során a rendszer statikus és teljesen inaktív marad más kritikus feladatokkal szemben, amelyek blokkolva lennének, vagy pedig a kritikus külső események jelzésének megszakításakor.
Annak érdekében, hogy egy kóddarabot kritikus szakaszként definiálhassunk, elegendő a két kritikus kezdő és befejező szakasz utasítás közé csatolni : taskENTER_CRITICAL () és taskEXIT_CRITICAL () .
A FreeRTOS rendszermagnak dinamikusan kell lefoglalnia a RAM memóriát minden egyes feladat , sor vagy szemafor létrehozásakor. A hagyományos Malloc () és Free () módszerek használata továbbra is lehetséges, de bizonyos problémákat okozhat, mivel nem determinisztikusak, és túlságosan széttöredezett memóriában szenvedhetnek. Ezért két, ugyanazokat a prototípusokat alkalmazó módszer létezik a FreeRTOS-ban: pvPortMalloc () és vPortFree () .
Mindegyiket három különböző módon valósítják meg , amelyeket a Heap_1.c , Heap_2.c és a Heap_3.c fájlok írnak le , de a felhasználó szabadon meghatározhatja saját funkcióit.
A configTOTAL_HEAP_SIZE konstans a FreeRTOSConfig.h konfigurációs fájlban van meghatározva
Az első megvalósításEz a verzió nem határoz meg módszert a RAM memória felszabadítására.
A memória egy configTOTAL_HEAP_SIZE méretű tömbre van osztva (bájtokban), a "FreeRtos verem" elnevezéssel.
Amikor a kernelnek memóriát kell kiosztania, két szabad helyet foglal el ugyanarra a feladatra. Az elsőt a TCB-re használják, míg a másodikat a várólistára. Mivel a feladatokhoz szükséges memóriaterület soha nem szabadul fel, a verem addig telik, amíg a rendelkezésre álló hely el nem fogy.
A második megvalósításEz az ábrázolás abban különbözik az elsőtől, hogy van egy vPortFree () metódusa, amely felszabadítja a feladathoz rendelt memóriát, és újra lefoglalhatja egy másik feladat számára. Az új feladat memóriablokkjának méretének legfeljebb meg kell egyeznie a régi feladat blokkjának méretével.
A harmadik megvalósításEz csak a Malloc () és a Free () újradefiniálása, de ahol a biztonságot növelte azáltal, hogy az összes feladatot felfüggesztette a memória műveletének idejére.
Nagyon kicsi memóriaterületének és számos hardveres architektúrában lévő portjának köszönhetően a FreeRTOS-t főleg beágyazott operációs rendszerként használják. Mobileszközökön valósították meg, és gyakran használják ARM processzorokon.
Tisztán valós idejű operációs rendszerről, alkalmazás nélkül szállítva, gyakran alapul szolgál a specifikus és / vagy a saját API-k fejlesztéséhez. Ezért sok olyan területen használják, ahol a valós idejű kényszer erős, például: orvosi megfigyelő eszközök, szeizmikus és környezeti ellenőrző eszközök vagy akár ipari eszközök és robotok vezérlése. Feladatkezelési funkciói a legmagasabb prioritások alkalmazásával biztosítják a valós időben gyűjtött adatok integritását.
A műszaki terület, amelyben ezt a valós idejű rendszert használják a leggyakrabban, a hálózat, és különösen az adatok vezeték nélküli hálózatokon keresztül történő továbbítására. Nagyon nagy frekvenciájú hálózatoknál, mint például a WPAN , nagyon alacsony memóriakapacitású hardverarchitektúrák esetén túlcsordulási jelenségek fordulnak elő az egyhurkos rendszerek cseréje során. Ezeknek a cseréknek a különböző feladatok formájában történő megvalósítása azonban bonyolítja a fejlődést. Prioritáskezelésének és többfeladatos ütemezőjének köszönhetően a FreeRTOS kiküszöböli az ilyen típusú problémákat. Minden feladatnak van egy fenntartott blokkja, a túlcsordulási jelenség megszűnik, mivel az erőforrások hiánya miatt már nincs túlcsorduló memória.
Vezérlési alkalmazásokhoz, mint például szemkövetési alapuló fedélzeti hardver korlátozott erőforrásokkal FreeRTOS egy mag az alap rendszer kezelése a hardver, amely lehetővé teszi az adott alkalmazásokat hozzáadni. Itt is mindenekelőtt az ütemező, valamint annak feladatkezelési és prioritási rendszere elengedhetetlen az ilyen típusú alkalmazásokhoz. Ennek a mobil eszköznek a firmware-je három rétegből áll, a HAL, amely kezeli a hardver absztrakciós réteget, a LED, amely a processzor további összetevőit kezeli, és a TAL, amely a FreeRTOS-t kezelő feladatok része. Ez a fajta alkalmazás célja, hogy alkalmazkodjon a felhasználóhoz e szeme mozgásán keresztül észlelt reakcióknak megfelelően.
A FreeRTOS-t széles körben használják a hálózati verem megvalósításához is, és gyakran társul az uIP-hez. A mobil eszközökhöz, például a telefonokhoz, még videokezeléshez is megtalálható. Gyakran használják MAC hálózati réteg megvalósításokhoz is, mint például a vezeték nélküli érzékelő hálózatok széles körben használt 802.15.4 protokolljához. A FreeRTOS egyik erőssége a nyílt forráskódú aspektusa, valamint az a tény, hogy lehetővé teszi nagyon könnyű és könnyen hordozható IP hálózati rétegek, például uIP vagy lwIP megvalósítását.
Egy másik fő alkalmazási terület a vezeték nélküli érzékelő hálózat . Ezek a rendszerek szenzorokból állnak, amelyek adataikat egy csomópontra továbbítják, hogy esetleg egy központi rendszerbe küldjék őket. Ez a típusú hálózat az orvosi területen van jelen a betegek megfigyelésére, vagy a mezőgazdaságban a gazdaságok felkutatására és ellenőrzésére.
A FreeRTOS a valós idejű operációs rendszer ezen a területen mert az érzékelők nagyon kevés energiát fogyasztanak, és nagyon korlátozott a RAM-erőforrásuk.
Az áramfogyasztás szintén érv a FreeRTOS mellett. Mindenféle mobil eszközön ez az alapvető korlát van, és ez az operációs rendszer valós idejű feldolgozást tesz lehetővé, miközben biztosítja a minimális energiafogyasztást.
A különféle technológiák konvergenciájával és miniatürizálásával a FreeRTOS lehetővé teszi az egyszerű és hatékony hálózati akkumulátor-megvalósítás ötvözését az energiatakarékossági igényekkel. Az új mobil eszközök, például a telefonok, jó példa erre. Ez a szoftveres megoldás lehetővé teszi a gyártási költségek jelentős csökkentését is.
A FreeRTOS számos architektúrára összpontosított, és különösen a hálózati kártyákat integráló FPGA-n alapuló kártya fejlesztésével lehetővé teszi, hogy olyan rendszereink legyenek adaptált rendszerrel, amely lehetővé teszi a projekt végső céljaira való összpontosítást.
Ugyanakkor a GPL licenc alatt áll, még akkor is, ha lehetővé teszi a saját fejlesztésű alkalmazások fejlesztését, a forráskódjának nyitottnak kell maradnia, ezért a kutatás és az oktatás területén kiváltságos. Saját gyártású versenytársait, mint a QNX , az ipari világban választják leggyakrabban.
Az oktatás területén is sokféle felhasználási lehetőség van. A FreeRTOS az ütemező megvalósításának, a feladatkezelésnek és a moduláris programozásnak a tanulmányozására szolgál. Lehetővé teszi olyan alkalmazások fejlesztését az elektronika területén is, mint például a hőmérséklet-leolvasás és annak kijelzése.
A FreeRTOS nyitott kódjának, kis méretének, méretezhetőségének, valamint bővíthetőségének köszönhetően keretrendszereket is megszületett. Ezen keretek egy részét az autóiparban használják
A FreeRTOS projekt a valós idejű operációs rendszerek két verzióját hozta létre, amelyek a FreeRTOS kernelre épülnek: OpenRTOS és SafeRTOS.
OpenRTOSAz OpenRTOS a FreeRTOS kereskedelmi verziója, amely USB-illesztőprogramokat, FAT fájlrendszert, valamint TCP / IP-veremeket tartalmaz. A kereskedelmi licenc mentesíti az OpenRTOS felhasználókat a FreeRTOS kernelben tett módosításaik közzétételének kötelezettsége alól, és felajánlja számukra a teljesítményükhöz szükséges kereskedelmi támogatást és védelmet.
OpenRTOS által nyújtott globális mérnöki cég egy engedéllyel Real Time Engineers Ltd. .
SafeRTOSA SafeRTOS egy valós idejű operációs rendszer a kritikus rendszerek piacán . Ezt a WHIS (WITTENSTEIN nagy integritású rendszerek) fejlesztette ki a Real Time Engineers Ltd-vel együttműködve .
A SafeRTOS és a FreeRTOS ugyanazon ütemezési algoritmuson, ugyanazon API-n, ugyanazon RAM és ROM követelményeken alapul, és ugyanazon típusú mikrovezérlőkön futnak. Ezek azonban másképp és más célokkal kerültek kidolgozásra.
A FreeRTOS egy HAZOP- vizsgálat tárgya volt , amely számos funkcionális és viselkedési gyengeséget azonosított az API-val vagy az esetleges rendszerhasználói hibákkal kapcsolatban. E hiányosságok orvoslására a SafeRTOS-t egy IEC 61508 SIL 3. szintű fejlesztési cikluson keresztül fejlesztették ki, a SafeRTOS-t a német TUV (Technischer Überwachungs-Verein) tanúsító és szabványosító szervezet SIL3 tanúsítvánnyal rendelkezik.
A SafeRTOS egyik legnagyobb különlegessége a memóriamérete, amely nem haladja meg a 14 KB-ot, ami lehetővé teszi számára, hogy közvetlenül a mikrovezérlő ROM memóriájában tartózkodjon. Ezenkívül a ROM-ban megvalósítva a SafeRTOS kód csak az eredeti konfigurációban használható, és nem módosítható, ami kiküszöböli a felhasználói hibákkal kapcsolatos esetleges rendszerhibákat, és megkönnyíti a SafeRTOS kernel alapú rendszer tanúsítását és érvényesítését.
A SafeRTOS-t számos kereskedelmi rendszerben használják, köztük a Texas Instruments egyes Stellaris ARM mikrovezérlőiben .
SafeRTOS által nyújtott globális mérnöki cég egy engedéllyel Real Time Engineers Ltd. .