Loading AI tools
système d'exploitation temps réel De Wikipédia, l'encyclopédie libre
FreeRTOS est un système d'exploitation temps réel (RTOS) faible empreinte, portable, préemptif et Open source pour microcontrôleur. Il a été porté sur plus de 40 architectures différentes. Créé en 2003 par Richard Barry et la FreeRTOS Team, il est aujourd’hui parmi les plus utilisés dans le marché des systèmes d'exploitation temps réel.
| FreeRTOS | |
| |
| Famille | Système d'exploitation temps réel |
|---|---|
| Type de noyau | Micronoyau |
| État du projet | En développement |
| Dépôt | github.com/FreeRTOS/FreeRTOS |
| Plates-formes | 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 series, Fujitsu MB96340 series, Nios II (en) |
| Entreprise / Développeur |
Amazon, Richard Barry et FreeRTOS Team |
| Licence | MIT, précédemment GNU GPL modifiée |
| États des sources | Logiciel libre pour système embarqué |
| Écrit en | C |
| Dernière version stable | 202212.01 ()[1] 202210.01-LTS ()[2] |
| Site web | www.freertos.org |
modifier  |
|
FreeRTOS est disponible gratuitement sous une licence MIT depuis le 29 novembre 2017[3]. Les versions précédentes étaient disponibles sous licence GPL modifiée et utilisable sans paiement de redevances, cette licence n’oblige pas les développeurs à publier le code de leurs logiciels applicatifs mais impose de garder le noyau de FreeRTOS Open Source. Une licence commerciale avec le support ad hoc (OpenRTOS) est également proposée par la société High Integrity Systems.
Le nombre de tâches exécutées simultanément et leur priorité ne sont limités que par le matériel. L'ordonnancement est un système de file d'attente basé sur les Sémaphores et les Mutex. Il est basé sur le modèle Round-Robin avec gestion des priorités. Conçu pour être très compact, il n'est composé que de quelques fichiers en langage C, et n'implémente aucun pilote matériel.
Les domaines d'applications sont assez larges, car les principaux avantages de FreeRTOS sont l’exécution temps réel, un code source ouvert et une taille très faible. Il est donc utilisé principalement pour les systèmes embarqués qui ont des contraintes d'espace pour le code, mais aussi pour des systèmes de traitement vidéo et des applications réseau qui ont des contraintes de temps réel.
FreeRTOS un système d'exploitation temps réel libre et open source[4] originellement développé par Real Time Engineers Ltd[5].
En 2017, le projet et son équipe de développeurs ont été acquis par Amazon[6]. Une version spécifique de FreeRTOS appelée Amazon FreeRTOS a d'ailleurs été créée, incluant une série de librairies facilitant l'intégration avec le cloud Amazon AWS.
Il a été porté sur plus de 40 architectures et 15 chaînes de compilation différentes[7]. En 2019, il a été téléchargé plus de 185 500 fois[7].
Sa conception est volontairement minimaliste pour qu'il puisse être installé sur de petits systèmes. L'image binaire du noyau pèse entre 4KB et 9KB[8] (4,3 KB compilé sur ARM7). Le kit minimal ne compte que quelques fonctions pour gérer les tâches et la mémoire[4]. De plus, les files d'attente, les sémaphores et les mutex sont implémentés[4].
Le noyau de la version 7.3.0 n'est composé que de cinq fichiers codés en langage C. Des sections en Assembleur permettent d'assurer la compatibilité de FreeRTOS avec les différentes architectures matérielles.
Un nombre illimité de tâches peut être exécuté simultanément et sans contrainte[4].
FreeRTOS a été conçu pour être très léger, de 4 kio à 9 kio[8] pour une image binaire classique du noyau RTOS. Le noyau lui-même n'est composé que de trois fichiers source écrit en langage C.
L'ordonnancement des tâches a pour but principal de décider parmi les tâches qui sont dans l'état « prêt », laquelle exécuter. Pour faire ce choix, l'ordonnanceur de FreeRTOS se base uniquement sur la priorité des tâches[9].
Les tâches en FreeRTOS se voient assignées à leur création, un niveau de priorité représenté par un nombre entier. Le niveau le plus bas vaut zéro et il doit être strictement réservé pour la tâche Idle[10]. L'utilisateur a la possibilité de surcharger ce niveau avec une priorité personnalisée en modifiant la constante : tskIDLE_PRIORITY. Le nombre maximum de niveaux de priorités est défini par la constante : tskMAX_PRIORITIES. Plusieurs tâches peuvent appartenir à un même niveau de priorité[11].
Dans FreeRTOS Il n'y a aucun mécanisme automatique de gestion des priorités. La priorité d'une tâche ne pourra être changée qu'à la demande explicite du développeur[10].
Les tâches sont de simples fonctions qui généralement s’exécutent en boucle infinie[12] et qui suivent la structure générique suivante :
void vATaskFunction( void *pvParameters )
{
for( ;; )
{
-- Ajouter le code de votre tâche ici --
}
}
Dans le cas d'un micro-contrôleur possédant un seul cœur, il y aura à tout moment une seule tâche en exécution[13]. L’ordonnanceur garantira toujours que la tâche de plus haute priorité pouvant s’exécuter sera sélectionnée pour entrer dans l'état d’exécution[9]. Si deux tâches partagent le même niveau de priorité et sont toutes les deux capables de s'exécuter, alors les deux tâches s'exécuteront en alternance par rapport aux réveils de l’ordonnanceur (round robin)[9].
Afin de choisir la tâche à exécuter, l'ordonnanceur doit lui-même s'exécuter et préempter la tâche en état d'exécution. Afin d'assurer le réveil de l'ordonnanceur, FreeRTOS définit une interruption périodique nommé la "tick interrupt"[9]. Cette interruption s'exécute infiniment selon une certaine fréquence qui est définie dans le fichier FreeRTOSConfig.h par la constante :
configTICK_RATE_HZ /* Fréquence d’exécution de la "tick interrupt" en Hz. */
Cette constante décrit alors la période de temps allouée au minimum pour chaque tâche ou expliqué autrement, l'intervalle séparant deux réveils de l’ordonnanceur[9].
Comme décrit dans cette section, FreeRTOS est donc un RTOS qui utilise un ordonnancement préemptif pour gérer les tâches. Néanmoins il peut aussi utiliser optionnellement (si la directive lui est donnée) l'ordonnancement coopératif[14]. Dans ce mode d'ordonnancement, un changement de contexte d’exécution a lieu uniquement si la tâche en exécution permet explicitement à une autre tâche de s’exécuter (en appelant un Yield() par exemple) ou alors en entrant dans un état de blocage[14]. Les tâches ne sont donc jamais préemptées. Ce mode d’ordonnancement simplifie beaucoup la gestion des tâches malheureusement il peut mener à un système moins efficace et moins sûr.
FreeRTOS peut aussi utiliser un ordonnancement hybride, utilisant l'ordonnancement préemptif et l’ordonnancement coopératif[14]. Dans ce mode, un changement de contexte d’exécution peut aussi avoir lieu lors de l’événement d'une interruption.
Dans FreeRTOS, la tâche de plus haute priorité prête à s'exécuter sera toujours sélectionnée par l'ordonnanceur. Ceci peut amener à une situation de famine[15]. En effet, si la tâche de plus haute priorité n'est jamais interrompue, toutes les tâches ayant une priorité inférieure ne s’exécuteront jamais. FreeRTOS n’implémente aucun mécanisme automatique pour prévenir le phénomène de famine[9]. Le développeur doit s'assurer lui-même qu'il n'y ait pas de tâches monopolisant tout le temps d’exécution du micro-contrôleur[16]. Pour cela, il peut placer des événements qui interrompront la tâche de plus haute priorité pour un temps déterminé ou jusqu'à l’avènement d'un autre événement et laissant ainsi le champ libre aux tâches de priorités inférieures pour s’exécuter.
Afin d'éviter la famine, le développeur peut utiliser l'ordonnancement à taux monotones (RMS)[14]. C'est une technique d'assignation de priorité qui attribue à chaque tâche une unique priorité selon sa fréquence d’exécution. La plus grande priorité est attribuée à la tâche de plus grande fréquence d’exécution et la plus petite priorité est attribuée à la tâche de plus petite fréquence. L'ordonnancement à taux monotones permet de maximiser l'ordonnançabilité des tâches mais cela reste difficile à atteindre du fait de la nature des tâches qui ne sont pas totalement périodiques[14].
Un micro-contrôleur doit toujours avoir quelque chose à exécuter[17]. En d'autres termes, il doit toujours y avoir une tâche en exécution. FreeRTOS gère cette situation en définissant la tâche Idle qui est créée au lancement de l’ordonnanceur[17]. La plus petite priorité du noyau est attribué à cette tâche. Malgré cela, la tâche Idle peut avoir plusieurs fonctions à remplir dont :
Dans FreeRTOS, chaque tâche est décrite par un TCB (Task control Block) qui contient toutes les informations nécessaires afin de spécifier et de représenter une tâche[18].
| Variables | Description |
|---|---|
| pxTopOfStack | Pointeur vers le dernier élément placé en haut de la pile |
| xGenericListItem | Élément (xListItem) de la liste utilisé pour placer la TCB dans une liste d'états (Prêt, bloqué ou suspendu). |
| xEventListItem | Élément (xListItem) de la liste utilisé pour placer la TCB dans une liste d’événements. |
| uxPriority | Priorité de la tâche |
| pxStack | Pointeur vers le début de la pile du processus |
| pxEndOfStack | Pointeur vers la fin de la pile du processus |
| uxTCBNumber | Taille de la pile en nombre de variables |
| pcTaskName | Nombre s'incrémentant à chaque fois qu'une TCB est créée (utilisé pour le débogage) |
| uxBasePriority | La dernière priorité assignée à la tâche |
| ulRunTimeCounter | Calcule le temps passé par la tâche dans un état d’exécution |
| pxTaskTag | Permet d'ajouter un Tag à une tâche. Le Tag s'utilise pour réaliser des Log via les sorties analogique ou digitales grâce à la fonction traceSWITCHED_IN(). |
| uxCriticalNesting | Permet de sauvegarder la profondeur d'imbrication des sections critiques de cette tâche. À chaque fois que la tâche entre dans une section critique, la variable est incrémentée, elle est décrémentée dès que la tâche sort d'une section critique.
Cette variable est nécessaire, car il est possible que la tâche rende la main pendant qu'elle est en section critique. |
Les tâches sous FreeRTOS peuvent exister sous 5 états : "supprimé", "suspendu", "prêt", "bloqué" ou "en exécution"[18].
Dans FreeRTOS, il n'y a aucune variable pour spécifier explicitement l'état d'une tâche, en contrepartie FreeRTOS utilise des listes d'états. La présence de la tâche dans un type de listes d'états détermine son état (prêt, bloqué ou suspendu). Les tâches changeant souvent d'état, l’ordonnanceur n'aura alors qu'à déplacer la tâche (l'élément (xListItem) appartenant à cette même tâche) d'une liste d'états à une autre[18].
À la création d'une tâche, FreeRTOS crée et remplit la TCB correspondant à la tâche, puis il insère directement la tâche dans une "Ready List" (Liste contenant une référence vers toutes les tâches étant dans l'état "Prêt")[18].
FreeRTOS maintient plusieurs "Ready List", une liste existe pour chaque niveau de priorité. Lors du choix de la prochaine tâche à exécuter, l’ordonnanceur analyse les "Ready list" de la plus haute priorité à la plus basse[18].
Plutôt que de définir explicitement un état "en exécution" ou une liste associée à cet état, le noyau FreeRTOS décrit une variable "pxCurrentTCB" qui identifie le processus en exécution. Cette variable pointe vers la TCB correspondant au processus se trouvant dans l'une des 'Ready list'[18].
Une tâche peut se retrouver dans l'état "bloqué" lors de l’accès à une file en lecture/écriture dans le cas où la file est vide/pleine. Chaque opération d'accès à une file est paramétrée avec un timeout (xTicksToWait), Si ce timeout vaut 0 alors la tâche ne se bloque pas et l'opération d'accès à la file est considérée comme échouée. Dans le cas où le timeout n'est pas nul, la tâche se met dans l'état 'bloqué' jusqu'à ce qu'il y ait une modification de la file (par une autre tâche par exemple). Une fois l'opération d'accès à la file possible, la tâche vérifie que son timeout n'est pas expiré et termine avec succès son opération[18].
Une tâche peut être volontairement placée dans l'état "suspendu", elle sera alors totalement ignorée par l’ordonnanceur et ne consommera plus aucune ressource jusqu'à ce qu'elle soit retirée de l'état et remise dans un état "prêt"[19].
Le dernier état que peut prendre une tâche est l'état "supprimé", cet état est nécessaire car une tâche supprimée ne libère pas ses ressources instantanément. Une fois dans l'état "supprimé", la tâche est ignorée par l'ordonnanceur et une autre tâche nommée "IDLE" est chargée de libérer les ressources allouées par les tâches étant en état "supprimé"[18].
La tâche 'IDLE' est créée lors du démarrage de l'ordonnanceur et se voit assigner la plus petite priorité possible ce qui conduit à une libération retardée des ressources lorsque aucune autre tâche est en exécution[20].
Les listes sont les structures de données les plus utilisées dans FreeRTOS. Elles sont utilisées pour organiser et ordonnancer les tâches, ainsi que pour l’implémentation des files[18].
FreeRTOS définit plusieurs structures afin de représenter les listes :
La structure xLIST est définie comme suit :
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;
La structure xLIST_ITEM est définie comme suit :
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. */
};
Les files sont les mécanismes principaux qui permettent de faire communiquer et synchroniser les tâches entre elles[18].
La structure basique d'une file est décrite comme suit :
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;
Une file contient un nombre fini d'éléments de taille fixe[21]. La taille physique d'une file est déterminée par le nombre maximum d'éléments qu'elle peut contenir (uxLength) multiplié par la taille en octet de chaque élément (uxItemSize).
Dans FreeRTOS, l'écriture ou l'envoi de données dans une file est effectuée en copiant octet par octet et quel que soit son type[21],[18] car la durée de vie de l'élément sauvegardé est bien souvent inférieure à la durée de vie de la file[18]. À l'instar de l'opération d'écriture, la lecture ou réception de données est également effectuée en copiant octet par octet la donnée qui sera supprimée de la file[21].
Les files sont des objets indépendants, il n'y a aucune assignation ou appartenance à une tâche[21]. Elles sont les structures qui permettent aux tâches de communiquer entre elles. De ce fait, elles peuvent avoir plusieurs tâches en lecture et en écriture simultanément.
Les opérations d'écriture ou de lecture sur les files peuvent être bloquantes ou non-bloquantes. Les opérations non-bloquantes retournent directement le statut réussi ou échoué sur la file. Les opérations bloquantes sont paramétrées avec un timeout qui leur permet de se bloquer et qui détermine le temps maximum pendant lequel elles peuvent rester dans cet état[18].
FreeRTOS utilise les files comme moyen de communication entre les tâches. Cependant, les files gèrent aussi la synchronisation et la concurrence entre les tâches[18]. De ce fait, cette structure est l'élément de base pour la gestion des ressources dans FreeRTOS.
FreeRTOS synchronise les tâches en utilisant principalement deux mécanismes : les Sémaphores et les Mutex[18].
FreeRTOS permet la création et l'utilisation de Sémaphores à plusieurs éléments[22]. Les sémaphores sont implémentés sous forme de file tel que le nombre d'éléments du sémaphore représente le nombre d'éléments maximum que la file peut contenir. La file représentant le sémaphore ne sauvegarde aucune donnée, elle s'occupe uniquement d'enregistrer le nombre de ses entrées actuellement occupées[18]. La taille des éléments de la file est donc nulle (uxItemSize=0). Un accès au Sémaphore ne fait qu'augmenter ou diminuer le nombre d'entrées occupées dans la file et aucune copie d'élément n'est effectuée[18].
L'API offerte par FreeRTOS pour la gestion des sémaphores fait une différence entre les sémaphores à N éléments et les sémaphore binaires[23]. Les Sémaphores binaires peuvent être vus comme des files ne pouvant contenir qu'un seul élément. Un Sémaphore binaire ne pourra donc être pris qu'une seule fois avant qu'il ne devienne indisponible contrairement au Sémaphore à n éléments qui pourra être pris à plusieurs reprises ce qui permet par exemple, de définir un nombre de ressources disponibles ou alors de compter le nombre d'événements qui doit être encore exécuté[24].
Un Mutex est utilisé afin de protéger une ressource partagée.
L’implémentation des Mutex dans FreeRTOS est similaire à celle des Sémaphores binaires (sous la forme d'une file)[25] sauf que la tâche qui prend le Mutex doit obligatoirement le rendre. Cela peut être vu comme l'association d'un jeton à une ressource, une tâche prend le jeton et utilise la ressource puis rend le jeton à la fin, au même moment aucun autre jeton supplémentaire ne pourra être associé à la tâche.
Une autre différence majeure entre les Mutex et les Sémaphores binaires dans FreeRTOS est le système d'héritage de priorité. Quand plusieurs tâches demandent à prendre un Mutex, la priorité du détenteur du Mutex est fixée momentanément à la valeur de la plus haute priorité parmi les tâches qui attendent sa libération. Cette technique a pour effet de prévenir les phénomènes à risques d'inversion de priorité même si cela ne garantit pas une sécurité infaillible face à ces phénomènes.
Une interruption est un mécanisme purement matériel qui est implémenté et lancé par ce dernier. FreeRTOS ne fait que fournir des méthodes servant à la gestion des interruptions et il peut également lancer des interruptions par appel à une instruction matérielle[26].
FreeRTOS n'impose aux développeurs aucune stratégie spécifique pour la gestion des interruptions mais il offre plusieurs moyens pour que la stratégie choisie puisse être implémentée et maintenue facilement.
Les routines d'interruptions (ISR) sont des fonctions exécutées par le micro-contrôleur lui-même et qui ne peuvent être gérées par FreeRTOS[27], ce qui peut poser certains problèmes. Pour ces raisons, les routines d'interruptions ne peuvent pas utiliser les fonctions habituelles de l'API FreeRTOS que toute autre tâche basique peut utiliser. Néanmoins FreeRTOS définit un groupe de fonctions spécialement conçues pour les ISR, par exemple, une ISR utilisera la fonction xSemaphoreGiveFromISR() plutôt que xSemaphoreGive(), de la même manière, elle utilisera la fonction xQueueReceiveFromISR() plutôt que xQueueReceive().
Afin de spécifier une politique de gestion des interruptions et de gérer l'accès aux fonctions du noyau spécifiques aux ISR, FreeRTOS définit des constantes dans le fichier de configuration FreeRTOSConfig.h :
La définition de ces deux constantes permet de spécifier une politique de gestion des ISR selon leur niveau de priorités :
La définition des deux constantes précédentes ajoute aussi aux ISR la particularité d'imbrication d'interruptions (ang. Interrupt Nesting)[29]. L'imbrication d'interruptions est la possibilité qu'une deuxième interruption ait lieu au même moment que le traitement d'une autre interruption par une ISR. Cette deuxième interruption peut préempter la première si elle dispose d'une priorité plus élevée.
Il est à noter que les priorités des interruptions sont définies par l'architecture du micro-contrôleur. Ce sont des priorités matérielles qui n'ont aucune relation avec les priorités logicielles que l'on peut attribuer aux tâches grâce à FreeRTOS[29].
Comme spécifié précédemment, les ISR sont des sections de code exécutées par le micro-contrôleur et non par FreeRTOS. Ce qui amène à des comportements inattendus du noyau. Pour cette raison, il est nécessaire de réduire au maximum le temps d’exécution d'une ISR. Une stratégie pour réduire le temps d’exécution est d'utiliser les Sémaphores binaires offerts par FreeRTOS. Un Sémaphore binaire peut être utilisé afin de débloquer une tâche à chaque fois qu'une interruption particulière a lieu. Ainsi la partie de code exécutée dans l'ISR pourra être très largement réduite et la gestion de l'interruption reviendra en grande partie à la tâche débloquée. On aura ainsi différé le processus d'interruption vers une simple tâche[30].
Si l'interruption s'avère être critique, alors la priorité de la tâche de gestion de l’interruption pourra être définie de manière à toujours préempter les autres tâches du système[30].
FreeRTOS permet de protéger des sections de code appartenant à une tâche de tout changement de contexte, d'opération de l’ordonnanceur ou même d'une levée d'interruption, ces portions de code sont appelées sections critiques. L'utilisation de sections critiques peut être efficace pour respecter l'atomicité de certaines instructions. Néanmoins ces sections critiques sont à utiliser avec précaution car pendant leur exécution, le système reste statique et totalement inactif envers d'autres tâches critiques qui seraient bloquées ou alors envers des interruptions signalant des événements extérieurs critiques.
Afin de définir une partie de code comme étant une section critique, il suffit de l'englober entre les deux instructions de début et de fin de section critique : taskENTER_CRITICAL() et taskEXIT_CRITICAL()[31].
Le noyau FreeRTOS doit allouer dynamiquement la mémoire RAM à chaque fois qu'une tâche, une file ou un Sémaphore est créé[32]. L'utilisation des traditionnelles méthodes Malloc() et Free() est toujours possible mais elle peut poser quelques problèmes car elles ne sont pas déterministes et elles peuvent souffrir d'une mémoire trop fragmentée. De ce fait, deux méthodes reprenant les mêmes prototypes existent dans FreeRTOS : pvPortMalloc() et vPortFree()[32].
Chacune d'elles est implémentée de trois manières différentes décrites dans les fichiers Heap_1.c, Heap_2.c et Heap_3.c mais l'utilisateur est libre de définir ses propres fonctions[32].
La constante configTOTAL_HEAP_SIZE définie dans le fichier de configuration FreeRTOSConfig.h
Cette version ne définit pas de méthode pour libérer de l'espace mémoire RAM[32].
La mémoire est divisée en un tableau de taille configTOTAL_HEAP_SIZE (en octets) nommé "la pile FreeRtos"[32].
Lorsque le noyau a besoin d'allouer de la mémoire, il réserve deux espaces libres pour une même tâche. Le premier est utilisé pour la TCB alors que le second représente la file[32]. Dans la mesure où l'espace mémoire des tâches n'est jamais libéré, la pile se remplit jusqu'à épuisement de l'espace disponible.
Cette représentation se différencie de la première par le fait qu'elle dispose d'une méthode vPortFree() qui libère la mémoire allouée pour une tâche et peut l'allouer de nouveau à une autre tâche[33]. Il faut que la taille du bloc mémoire de la nouvelle tâche soit au maximum égale à la taille du bloc de l'ancienne tâche.
Il ne s'agit ici que d'une redéfinition de Malloc() et Free() mais où la sécurité a été augmentée en suspendant toutes les tâches pendant la durée de l'opération sur la mémoire[34].
Grâce à son très faible encombrement mémoire et son portage sur de nombreuses architectures matérielles, FreeRTOS est principalement utilisé comme système d'exploitation embarqué[35]. Il a été implémenté sur des périphériques mobiles et est souvent utilisé sur les processeurs ARM.
Étant un système d'exploitation purement orienté temps réel et livré sans application, il sert souvent de socle pour le développement d'API spécifiques et/ou propriétaires. Il est donc utilisé dans des domaines très variés où la contrainte temps réel est forte comme par exemple : les appareils de surveillance médicale, les outils de contrôle sismique et d'environnement ou encore le pilotage d'appareils et de robots industriels[36]. Ses fonctionnalités de gestion des tâches permettent de garantir l'intégrité des données collectées en temps réel par l'utilisation des plus hauts niveaux de priorités[36].
Le domaine technique dans lequel ce système temps réel est le plus utilisé est le réseau, et plus particulièrement pour la transmission de données sur des réseaux sans fils. Pour des réseaux à très haute fréquence comme le WPAN, sur des architectures matérielles à très faible capacité mémoire, des phénomènes d'overflow interviennent durant les échanges pour des systèmes à boucle unique. Cependant l'implémentation de ces échanges sous forme de différentes tâches complique le développement. Grâce à sa gestion des priorités et son ordonnanceur multitâche, FreeRTOS permet d'éliminer ce type de problèmes[37]. Chaque tâche ayant un bloc réservé, le phénomène d'overflow est supprimé car il n'y a plus de dépassement mémoire par manque de ressources.
Pour les applications de contrôle comme l'eye-tracking à base de matériel embarqué à ressources limitées, FreeRTOS fournit un core pour le système de base gérant le matériel permettant d'y ajouter des applications spécifiques[38]. Là encore c'est surtout l'ordonnanceur et son système de gestion et de priorité des tâches qui est primordial pour ce type d'application. Le firmware de ce périphérique mobile est composée de 3 couches, la HAL qui gère la couche d'abstraction matérielle, la DEL qui gère les composants additionnels au processeur et la TAL qui est la partie tâches qui gère FreeRTOS. Ce type d'application est destinée à s'adapter à l’utilisateur en fonction de ces réactions perçues au travers des mouvements de ses yeux.
FreeRTOS est très utilisé aussi pour l'implémentation de pile réseau et est souvent associé à uIP. Pour les périphériques mobiles comme les téléphones, on peut même le retrouver pour la gestion de la vidéo[39]. On l'utilise aussi souvent pour des implémentations de couche réseau MAC comme le protocole 802.15.4 très utilisé pour les réseaux de capteurs sans fil[37]. Une des forces de FreeRTOS est aussi son aspect open-source et le fait qu'il permet l'implémentation de couches réseaux IP très légères et facilement portable comme uIP ou lwIP[40].
Un autre grand domaine d'application est le réseau de capteurs sans fils. Ces systèmes consistent en un ensemble de capteurs transmettant leurs données à un nœud pour éventuellement les envoyer à un système central. Ce type de réseau est présent dans le domaine médical pour monitorer les patients ou dans l'agriculture pour localiser et surveiller les élevages[41].
FreeRTOS est le système d'exploitation temps réel de prédilection dans ce domaine[réf. nécessaire] car les capteurs consomment très peu d’énergie et disposent de ressources RAM très limitées[42].
La consommation électrique est aussi un argument en faveur de FreeRTOS. Les périphériques mobiles de toutes sortes ont en commun cette contrainte essentielle, et ce système d'exploitation permet un traitement temps réel tout en garantissant un minimum de consommation électrique[43].
Avec la convergence des différentes technologies et leur miniaturisation, FreeRTOS permet d'allier des implémentations de piles réseau simples et efficaces aux besoins d'économie d'énergie. Les nouveaux périphériques mobiles comme les téléphones en sont un bon exemple[40]. Cette solution logicielle permet aussi d'abaisser fortement les coûts de fabrication[44].
Ayant été porté sur beaucoup d'architectures et avec le développement de carte notamment à base de FPGA intégrant des cartes réseau, FreeRTOS permet d'avoir des systèmes avec un système adapté permettant de se focaliser sur les objectifs finaux du projet[45],[46].
Cependant étant sous licence GPL, même s'il permet le développement d'applications propriétaires, son code source doit rester ouvert et il est donc privilégié dans le domaine de la recherche et de l'enseignement[47]. Ses concurrents propriétaires comme QNX sont le plus souvent choisis dans le monde de l'industrie.
Dans le domaine de l'enseignement là aussi, les différentes utilisations sont nombreuses. FreeRTOS est utilisé pour étudier l'implémentation d'ordonnanceur, la gestion de tâches et la programmation modulaire[48]. Il permet également de développer des applications dans le domaine de l'électronique comme la lecture de température et son affichage[49].
FreeRTOS a aussi fait naître des frameworks grâce à son code ouvert, sa faible taille, ses possibilités de mise à l'échelle ainsi que son extensibilité[50]. Certains de ces frameworks sont utilisés dans le secteur automobile[51]
Le projet FreeRTOS a donné naissance à deux versions de systèmes d'exploitation temps réel basés sur le noyau FreeRTOS : OpenRTOS et SafeRTOS.
OpenRTOS est une version commerciale de FreeRTOS, qui inclut une suite de pilotes de connexion USB, un système de fichier FAT ainsi qu'une pile TCP/IP. La licence commerciale libère les utilisateurs de OpenRTOS de l'obligation de publier leurs modifications du noyau FreeRTOS et leur offre le support commercial et les protections nécessaires pour leurs réalisations[52].
OpenRTOS est fourni par A global engineering company sous licence de Real Time Engineers Ltd[7].
SafeRTOS est un système d'exploitation temps réel destiné au marché des systèmes critiques. Il a été développé par la société WHIS (WITTENSTEIN high integrity systems) en partenariat avec Real Time Engineers Ltd[53].
SafeRTOS et FreeRTOS partagent le même algorithme d'ordonnancement, la même API, les mêmes exigences en matière de RAM et de ROM et fonctionnent sur les mêmes types de micro-contrôleurs. Cependant ils ont été développés différemment et avec différents objectifs[54],[55].
FreeRTOS a été le sujet d'une étude HAZOP qui a identifié plusieurs faiblesses fonctionnelles et comportementales liées à l'API ou à de possibles erreurs de l'utilisateur du système. Afin de résoudre ces faiblesses, SafeRTOS a été développé à travers un cycle de développement CEI 61508 SIL de niveau 3[55]. SafeRTOS est certifié SIL3 par l'organisme allemand de certification et de normalisation TUV (Technischer Überwachungs-Verein)[56].
Une des grandes particularités de SafeRTOS est son empreinte mémoire ne dépassant pas les 14KB ce qui lui permet de résider directement dans la mémoire ROM d'un micro-contrôleur[55]. De plus, lors de son implémentation en mémoire ROM le code de SafeRTOS ne peut être utilisé que dans sa configuration initiale et ne peut plus être changé, ce qui élimine les possibles défaillances du système liées aux erreurs d'utilisateur et facilite la certification et la validation du système basé sur le noyau SafeRTOS[57].
SafeRTOS est utilisé dans plusieurs systèmes commerciaux, notamment dans certains micro-contrôleurs Stellaris ARM de Texas Instruments[58].
SafeRTOS est fourni par A global engineering company sous licence de Real Time Engineers Ltd[7].
Seamless Wikipedia browsing. On steroids.
Every time you click a link to Wikipedia, Wiktionary or Wikiquote in your browser's search results, it will show the modern Wikiwand interface.
Wikiwand extension is a five stars, simple, with minimum permission required to keep your browsing private, safe and transparent.
