Petit préambule, histoire d’éviter tout malentendu
Bon, soyons réalistes et honnêtes : ce à quoi nous allons nous intéresser dans cette rubrique ne mérite pas entièrement le qualificatif de temps-réel.
En effet, cette dénomination et réservé aux systèmes qui peuvent garantir de manière déterministe l’instant auquel une tâche va s’exécuter. En d’autres termes, garantir que si le programmeur a décidé qu’un traitement doit être exécuté toutes les 10 milli-secondes, il sera effectivement exécuté toutes les 10 milli-secondes, à une erreur minime près qui est d’ailleurs précisée dans les spécifications du dit système.
Les systèmes concernés dans cette rubrique doivent plutôt être appelés noyaux multi-tâches, en ce sens qu’ils fournissent des services permettant l’exécution parallèle de plusieurs tâches, leur contrôle, ainsi que les communications entre elles.
Alors, pourquoi certains des systèmes vus ici utilisent-ils le qualificatif de temps-réel ? Parce que ça fait plus classe tout simplement 😉 Mais ne me faites pas dire ce que je n’ai pas dit : cela ne retire en rien de leurs qualités et de leur utilité. C’est juste qu’il vaut mieux savoir de quoi on parle.
Pourquoi utiliser ce genre de noyau sur un micro-contrôleur ?
Une première raison, totalement indiscutable : pour le fun. Histoire de voir ce que ça donne.
Mis à part cette motivation de pur geek, si l’application concernée ne consiste qu’à faire clignoter des LEDs ou bouger des servos, pas la peine de s’embarrasser avec. Autant faire les choses directement, comme cela est montré dans la série des tutoriaux de la rubrique Les micro-contrôleurs sans ta mère
Par contre, si vous commencez à vous intéresser au programme de contrôle d’un robot, qui aura par conséquent à :
– lire des capteurs
– générer des commandes moteurs
– contrôler des servos
– afficher des informations sur un LCD ou des LEDs
– lire des interrupteurs
– gérer différents timers
ça commence à être d’actualité. En effet, une première solution est de passer par l’utilisation de machines à états finis (FSM pour les connaisseurs). Ca marche très bien, mais ce n’est pas forcément très intuitif, et dès que les fonctions se complexifient, la complexité de l’automate, et donc du code, devient exponentielle.
L’approche multi-tâches permet de son côté de considérer chaque action individuellement comme si elle était seule à s’exécuter et de la programmer comme telle (aux besoins de communication entre tâches près), puis de mettre tout le monde ensemble ensuite.
Vous allez me dire alors : "mais puisque c’est si magique, pourquoi se poser la question ?"
Parce que ce n’est pas gratuit. En effet, il y a un prix à payer pour utiliser les bénéfices d’un noyau multi-tâches :
– les services apportés entrainent un overhead de temps d’exécution
– ils augmentent la taille du code
– c’est plus difficile à debuger que du code linéraire (mono-tâche)
– il faut apprendre à utiliser le noyau sélectionné
Comme toujours dans la vie, c’est donc une affaire de compromis. A vous de juger par conséquent.
Vos commentaires
# Le 22 octobre 2008 à 11:33, par george En réponse à : rtos
je veus constuire un robot muni d’une caméra
je veux savoir l’architecture d’un rtos ainsi que les critères de choix d’un rtos
# Le 22 octobre 2008 à 18:29, par Eric En réponse à : rtos
Bonsoir,
Expliquer l’architecture d’un RTOS en réponse ici est impossible, car trop complexe. Il y a des livres entiers sur le sujet. De plus chacun à la sienne propre, le point commun étant qu’on trouve un scheduler qui va gérer l’activation et la mise en sommeil des tâches. Mais dans la pratique, il y a bien plus de choses. Je conseillerais une petite recherche Google sur le sujet, et je suis certain que Wikipedia doit contenir égelement des articles utiles à consulter.
La question à se poser maintenant est : a-t-on réellement besoin d’un RTOS dans le cas de figure du robot avec une caméra ? Pour commencer, le fait d’avoir une caméra n’implique pas un RTOS. En fait ça ne sert carrément à rien dans ce cas. Le côté RT est nécessaire si on veut piloter des signaux par exemple avec un besoin de grande précision temporelle. Pour superviser un robot, ce n’est absolument pas nécessaire. Sauf à la limite si on veut générer les pulses de contrôle de moteurs pas à pas. Mais dans ce cas je conseillerais plutôt de dédier un micro-contrôlleur à cette tâche, en utilisant ses timers pour la génération des pulses et en le faisant communiquer avec le système de supervision en I2C, SPI, ou n’importe quelle autre option, afin d’en recevoir les directives de vitesse et ses des moteurs.
Donc en conclusion, la question est bcp trop vague pour qu’on puisse y répondre, et il faudrait de toute manière commencer par identifier les raisons pour lesquelles on a réellement besoin d’un RTOS.
Une dernière remarque : puisque tu mentionnes l’utilisation d’une caméra, ne confonds-tu pas RTOS avec "système de traitement suffisamment puissant" ?
Répondre à ce message