Introduction

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.