Noyau temps réel
Choix d’un noyau temps réel
Après avoir commencé l’analyse du code de manière ‘classique’, je me suis intéressé à des noyaux RTOS (Real Time Operationg System) qui permettent de faire tourner plusieurs tâches de manières indépendantes. Le principe est de découper le code en grands groupes fonctionnels qui seront exécutées en paralléle. On peut par exemple imaginer créer les tâches suivantes :
- Gestion de l’afficheur LCD
- Gestion de la liaisons série avec le module ultrason
- Gestion de la mesure de distance
- Gestion général du robot
Chaque tâche se programme sous forme d’une boucle infinie ayant une structure du type :
while (1) {
attente_evenement();
actions() ;
}
Il existe deux grandes famille de noyaux temps réels :
- Les RTOS préemptifs
- Les RTOS coopératifs
Dans le mode préemptif, le cadenceur du noyau se charge de faire exécuter les tâches en leurs répartissant le temps de traitement, éventuellement en fonction des priorités que l’on peut affecter à chaque tâche. Une tâche dont l’exécution est longue va donc être interrompu en cours de traitement pour permettre à une autre tâche de se lancer. La tâche interrompu continuera son traitement la prochaine fois que le cadenceur la réactivera.
Dans le mode coopératif, le cadenceur n’agit pas de manière intrusive. Les tâches ne sont pas interrompues et doivent donc éviter de rester actives trop longtemps, ce qui bloquerait les autres tâches du système.
Ce type de RTOS peut sembler plus contraignant pour la programmation car il faut s’assurer qu’une fonction ne prend pas trop de temps à s’exécuter et qu’elle « rend bien la main » au noyau de manière régulière.
Dans la pratique, c’est assez simple à mettre en œuvre. La plus part du temps les tâches sont en attente d’un événement (un résultat de mesure, un message à afficher, un obstacle détecté, une fin de temporisation, …), ce qui permet au superviseur d’activer d’autres tâches et donc de répartir les traitements. Si on sait qu’une boucle va prendre beaucoup de temps, il suffit d’intercaler des appels au superviseur pour activer les autres tâches.
Ce type de RTOS plus ‘simpliste’ présente habituellement une taille de code pour le noyau plus faible et une consommation mémoire pour ses besoins internes plus réduite.
Une étude des différents RTOS pour PIC 18F sur le Web m’a fait retenir (et essayer) les systèmes suivants :
- Salvo RTOS de Pumpkin (http://www.pumpkininc.com/). C’est un RTOS préemptif d’un bon niveau possédant de nombreuses fonctions de messages et de synchronisations inter-tâches. C’est un RTOS payant et la version gratuite est limitée en nombre de tâches que l’on peut déclarer.
- PicOS18 (http://www.picos18.com/). C’est également un RTOS préemptif écrit pour fonctionner sur des micro-controleurs de type PIC 18Fxxxx. Après quelques essais, je n’ai pas été convaincu par ce RTOS et son principe de déclaration des tâches par tableaux. J’ai également été assez rapidement limité par le nombre de tâches pouvant êtres déclarées. De plus, le développement de ce noyau n’a pas l’air très actif et la version courante semble dater un peu.
- OSA (http://pic24.ru/doku.php/en/osa/ref/intro). C’est un RTOS de type coopératif qui n’utilise que peu de mémoire et ne rajoute que peu de code pour son noyau. Il possède des fonctions de messages et de synchronisations entre tâche. Il faut cependant bien lire la documentation pour savoir dans quel contexte les fonctions peuvent être appelées. Le projet OSA est très actif. Lors de la mise au point de mon code, j’ai été amené à contacter les développeurs et nous avons eu des échanges très constructifs avec des temps de réaction très rapides pour l’obtention de réponses.