Contraintes, temps réel et microcontrôleur

Systèmes embarqués : contraintes et architecture

1. Ce qui change quand la mémoire vaut quelques kilo-octets

   Un logiciel embarqué s'exécute sur une machine dont les ressources ne sont pas négociables. Ce n'est pas une version réduite du logiciel classique : c'est une autre discipline.

   Les quatre contraintes simultanées

   1. la mémoire : quelques kilo-octets à quelques mégaoctets de RAM, contre des centaines de mégaoctets sur un poste de travail ;
   2. l'énergie : la cible est souvent une batterie, et la durée de vie se mesure en mois ou en années. Chaque cycle de réveil coûte ;
   3. le temps réel : une réponse trop tardive est une défaillance, pas un simple retard ;
   4. la sûreté de fonctionnement : une panne redémarre l'appareil ; un défaut physique, dans une voiture ou un dispositif médical, met en jeu des vies.

   Ces quatre contraintes sont simultanées et antagonistes : réduire la mémoire allonge le temps d'exécution, donc la consommation ; augmenter la fréquence consomme plus. Chaque décision est un compromis, et c'est ce qui distingue l'ingénierie embarquée.

   L'erreur de démarrage : la pile dynamique

   La différence la plus concrète avec du logiciel classique est l'absence d'espace pour une pile d'appels qui grandit à l'exécution. Sur un poste de travail, la pile est un problème de performance ; sur une cible contrainte, c'est une source de débordement qui corrompt la mémoire voisine sans aucun message : le système continue de fonctionner, avec des données aberrantes.

   La parade : mesures systématique de la consommation mémoire, et une discipline d'exploration des appels qui ne dépend pas de l'implémentation de la bibliothèque standard — parce que cette bibliothèque est précisément ce qui est volumineux.

   La question qu'on se pose avant de coder

   « Puis-je utiliser une bibliothèque ? » est une question d'ingénierie, pas de convenance. Les bibliothèques d'usage général contiennent presque toujours des fonctions jamais appelées, qui embarquent leur texte, leurs structures et leur logique d'erreur. Sur une cible de 64 kilo-octets, la taille de la bibliothèque importe plus que la complexité du code écrit.

2. Temps réel : avoir raison, et à l'heure

   Le temps réel ne signifie pas « rapide » mais « prévisible ». Un système peut être lent et rester temps réel ; un système rapide et imprévisible ne l'est pas.

   Temps réel souple et temps réel dur

   • souple : un dépassement de l'échéance est une gêne, pas une panne. Un lecteur vidéo, une imprimante, un objet connecté ;
   • dur : le dépassement constitue un défaut. Un contrôleur de frein, un système de sécurité, une boucle de régulation industrielle.

   Choisir du temps réel dur sans justification est un coût disproportionné : il interdit les bibliothèques utiles, impose des contraintes de conception, et réduit l'équipe disponible. La question à se poser est « que se passe-t-il si je rate ? ». Si la réponse est « rien de grave », le temps réel souple suffit et coûte beaucoup moins cher.

   L'inversion des priorités

   La plupart des systèmes temps réel utilisent un ordonnanceur à priorité préemptive : une tâche de priorité élevée reprend la main dès qu'elle est prête, et la tâche de faible priorité peut être interrompue indéfiniment. La conséquence est un risque classique et réel : une tâche de priorité moyenne ne s'exécute jamais si la charge des tâches haute et moyenne dépasse la capacité totale.

   La parade est structurelle : garantir que les tâches haute priorité laissent de la place aux autres — par des budgets d'exécution, par une conception en à-coups plutôt qu'en occupation permanente. Ce défaut ne se voit pas en développement : l'environnement de test est presque toujours inchargé.

   Interruptions, et le piège de la section critique

   Une interruption s'exécute en plein milieu de n'importe quelle instruction, y compris au milieu d'une écriture d'état. Partager une variable entre le code principal et une routine d'interruption sans section critique produit une lecture à moitié mise à jour : la valeur est incohérente, et non simplement ancienne. Sur un octet, c'est invisible ; sur une structure de plusieurs champs, c'est un comportement imprévisible.

   Et l'erreur inverse, plus coûteuse au développement : une interruption qui dure trop longtemps. Une interruption de traitement d'image bloque l'ordonnanceur pendant l'opération, et le système devient inutilisable alors que tout semble fonctionner sur un banc de test peu chargé.

3. Le microcontrôleur : registres, interruption, dialogue matériel

   Un microcontrôleur réunit sur une puce le processeur, la mémoire et les périphériques. Il n'y a pas de système d'exploitation en dessous : le programme est aux prises avec le matériel.

   Registres et registres à bits

   Un microcontroleur n'a pas de variables : il a des registres, des cases mémoire de taille fixe, chacune avec un rôle défini par le constructeur. Écrire dans le mauvais registre ne provoque pas une erreur, il produit un comportement arbitraire. C'est la différence structurelle avec un programme classique : la logique des causes et des effets disparaît.

   Le dialogue avec le matériel : le protocole

   Communiquer avec un capteur ou un actionneur est presque toujours un échange séquencé : une commande, un délai, une attente d'un signal prêt, une lecture de la donnée, une confirmation. Deux erreurs classiques :

   • lire avant que la donnée soit prête. Le délai est le paramètre le plus difficile à déterminer, parce qu'il dépend de la température, de la tension et de l'unité elle-même ;
   • ignorer le code d'erreur. La plupart des capteurs signalent un échec par un bit d'état ou une valeur particulière, et le programme qui n'en tient pas compte traite des mesures de secours comme des mesures réelles.

   La parade est identique dans les deux cas : lire un état et le tester, au lieu de supposer que l'opération a réussi.

   Le bus et les straps : ce qui n'est pas écrit dans le code

   Sur une carte cible, des cavaliers ou des straps selects à la compilation sélectionnent des variantes du même programme — le kristal d'horloge, la tension de fonctionnement, la source de démarrage. Deux engineers qui compilent le meme code pour deux cartes different obtient deux comportements, sans qu'aucune ligne de code diffère.

   C'est la raison pour laquelle toute configuration matérielle doit être décrite dans le dépôt, dans un fichier versionné. Un projet embarqué dont la configuration de la carte vit dans la mémoire de l'ingénieur n'est pas reproductible — et il devient impossible à maintenir dès que l'équipe change.