061208
lenteur en temps réel.
Une question de synchronisation / désynchronisation dans un système numérique :
Time Eater et On Time
Le réveil amoureux, une horloge toute bête.
00:00 01:01 02:02 03:03 04:04 05:05 06:06 ...
J'ai réalisé pour Sophie Urbani un réveil dit amoureux ou les minutes et les heures sont toujours identiques. 00:00 reste affiché jusqu'à ce qu'il soit 01:01 et ainsi de suite.
J'ai construit le circuit electronique permettant de gérer l'horloge elle même, l'affichage, l'alimentation et le contrôle par un bouton.
J'aimerais revenir sur la logique employée dans cet objet banal. La puce qui permet la gestion de toutes ces fonctions est un microcontrolleur 8 bits Scenix SX28, programmé en Assembleur.
L'Assembleur est un langage très proche du langage machine, c'est à dire de la manière dont les informations sont codées dans la mémoire de la machine (des paquets de 0 et de 1).
Pour écrire un programme en Assembleur, il faut prendre en compte la structure de la mémoire et la vitesse à laquelle le processeur traite les données. La vitesse du processeur dépend de sa structure et de l'oscillateur, une base de temps, qui scande les opérations.
Dans le cas du circuit qui nous intéresse, la base de temps est un résonateut céramique qui vibre à une fréquence de 50 mégahertz, c'est à dire qu'il produit 50 000 000 d'impulsions par seconde. A chaque impulsion, le processeur (le SX28) éxécute une opération simple. Cette opération se limite souvent à la copie d'un registre de mémoire vers un autre. Nous avons donc un processeur qui execute une opération toute les 1/50000000e de seconde soit 0,00000002 seconde (20 nanosecondes), c'est rapide.
Le problème de cette vitesse, dans l'idée de fabriquer une horloge, c'est qu'elle est 50 millions de fois trop rapide.
C'est là qu'intervient des bouts de programme que l'on appelle des Time Eater, littéralement "mangeurs de temps". Il s'agit tout simplement de compteurs à débordement, structurés en chaîne pour obtenir le déclenchement d'un événement moins fréquent.
Dans cette puce, les registres (les zones de mémoire) peuvent contenir 8 bits, de 00000000 à 11111111, ce qui nous donne en décimal de 0 à 255 ou en héxadécimal de 00 à FF.
Chaque compteur ne peut donc compter que jusque 255, soit 256 valeurs.
Voici la boucle programmable pour obtenir un événement par seconde :
faire a = a + 1
faire b = b + 1
faire c = c + 1
faire d = d + 1
jusqu'à d = 4
d = 0
jusqu'à c = 200
c = 0
jusqu'à b = 250
b = 0
jusqu'à a = 250
fin
d va compter juqu'à 4 puis va se remettre à zéro passant à la suite du programme où c augemte de 1 puis re vient à la boucle d, etc...
Quand toutes les opérations se seront déroulées entièrement, il se sera passé une seconde et le programme s'arrête.
Ce qu'il faut comprendre, c'est qu'un processeur ne peut pas changer sa vitesse de lui même (sauf sur des systèmes évolués) et qu'il est donc condamné à calculer toujours à une vitesse inadaptée au travail qu'il a a éxécuter. Le principe des Time Eater est au coeur de l'adaptation du processeur à son environnement.
un exemple simple :
Lorsqu'on tape sur un clavier d'ordinateur, on enfonce des touches qui déclenchen des contacts. Ces contacts sont connectés par un réseau de pistes conductrices à une puce, un microcontroleur qui possède la capacité de détecter la présence ou non d'un contact. Ce processeur simple tourne - comme on dit - à une vistesse de 4Mhz. Ce qui revient à une opération chaque 0,00000025 seconde (250 nanosecondes). Si on n'utilisait pas de système de perte de temps, quand une touche est enfoncée - en moyenne 10 ms - , il parvient à la puce 40000 états 'enfoncé', ce qui pourrait ce traduire à l'écran par 40000 fois la même lettre à chaque touche enfoncée.
Le clavier serait inutilisable.
Pour aller plus loin, le processeur est assez rapide pour identifier différents moments dans ce qui n'est pour nous qu'un instant : le moment du contact n'est jamais franc, il y a toujours une petite vibration mécanique due à notre geste. Cette vibration se solde par une oscillation bouton enfonce/ bouton non enfoncé qui serait immanquablement enregistrée par la puce.
En deux mots, le programme qui est éxécuté dans la puce palie à ces problèmes en se rendant sourd la plupart de son temps et en écoutant à intervalles réguliers. Il scanne chaque contact,l'un après l'autre, en permanence et à une vitesse réduite. Quand est mesurée plusieurs fois d'affilée un état en foncé, il considère que la touche est véritablement enfoncée, et envoie le code de la touche au processeur de l'ordinateur qui lui traite cette information et est encore capable de ralentir les effets
(On peut toujours régler dans un système la sensibilité du clavier et la vitesse de répétition d'une touche laissée enfoncée.).
Nous sommes en entourés de dispositifs rapides, trop rapides, qui jouent à se mettre à notre rythme. Les nécessités du calcul numérique ont produit des machines où la grande vitesse est la norme. Les machines conçues dans un monde de vitesse passent leur temps à ralentir leurs processus dans l'attente d'une action. La gestion de cette attente en programmation détermine l'ergonomie d'une interface.
Le ralentissement fabriqué par les boucles de Time Eater peut être considérer comme une lenteur en tant qu'il y a ajustement d'une vitesse sur une autre. En déroulant ses opérations à pleine vitesse, la puce perd prise avec le monde.
Le rapport des dispositifs en temps réel aujourd'hui s'inverse. Après une période où on courait après le temps réel, où les machines n'étaient jamais assez rapides pour le réaliser, nous voici dans un monde où les machines doivent réguler leur vitesse pour qu'on puisse entretenir un rapport avec elles.
Ce synchronisme apparent produit des accidents. On les appelle des bugs (bogues). Apparemment imprévisibles, ils découlent souvent de la forêt d'événements discrets advenant dans les dispositifs numériques.
Le plus fréquemment, ces bugs ne sont pas le fruit d'une erreur majeure de conception, mais plutôt la marque d'une coïncidence entre les cycles de la machines et le geste de l'utilisateur.
retour vers lenteur