Timer hardware ou les 55 cycles manquant...
Je ne sais pas pour vous mais c’est plus fort que moi: Quand quelque chose ne se passe pas comme prévu j’ai besoin de comprendre le « pourquoi? ». Lors de l’écriture de la librairie RunLoop pour Arduino, j’avais constaté à l’époque un décalage sur les timers hardware entre la période demandée par le programme et la périodicité réellement constatée en sortie avec l’analyseur logique.
Le problème c’est que toutes les librairies testées avaient le même décalage que moi: un peu plus de 3us!!! Cela peut paraitre ridicule vu de loin mais pour des fréquences dépassant le KHz, l’erreur est de plus en plus problématique si l’on a besoin de précision. Hors en astronomie, pour le pilotage des moteurs pas à pas, la précision est de rigueur. A l’époque, j’avais donc intégré ce décalage dans RunLoop en l’estimant de manière empirique autour des 3,3us.
Et voilà qu’aujourd’hui, je viens de tomber sur l’excellentissime blog de Bill Grundmann! Si vous lisez l’anglais, c’est par ici que cela se passe:
The overhead of Arduino Interrupts
Pour résumer: il a étudié le phénomène à l’oscilloscope et décortiqué le code assembleur de la librairie Arduino. Et effectivement, la levée d’interruption entraine un surcout de 55 cycles! Soit 55*0,0625 = 3,4375us précisément!!! Hors faute de le savoir, les librairies qu’on trouve sur le net n’en tiennent pas compte. Et bim!
J’ai donc le plaisir de vous annoncer que je viens d’en profiter pour affiner encore un peu plus le code de RunLoop et de le publier sur mon github. Un test à 20Khz, montre maintenant une périodicité quasi parfaite à +-40ns près d’après l’analyseur logique (hors avec ses 12MS/s max on est dans la limite de précision d’échantillonnage donc même pas sûr que la variation résiduelle soit réelle).
Note: en toute logique, le phénomène constaté n’est présent que pour des timers hardware levant une interruption au niveau logiciel. Je ne pense pas qu’un usage en PWM soit concerné.
Veni, vidi, vici et big up à Bill! :)
Démo d'avancement du goto prédictif...
L'ATmega2560 de la MKS MINI au taquet...
Interprétation de la mesure à l’analyseur logique:
Le code exécuté dans l’interruption en elle même prend 3,375us (remise à zéro du compteur du timer comprise) avec une périodicité d’à peine 8us soit plus de 123 000 impulsions par seconde!!! On arrive ici à la limite extrême en se limitant à un seul moteur. En prenant un peu de marge cela signifie qu’en déplacement bi moteurs (A.D. et déclinaison en simultané) pour du goto on peut sans complexe espérer atteindre les 50Khz avec encore un peu de temps CPU pour le reste du programme.
Pour atteindre de telles performances, le code des interruptions moteur a été réduit à sa plus simple expression (comptage de pas + envoi impulsion moteur). Toutes les fonctions d’écriture -digitalWrite()- ont été optimisées avec l’excellente librairie Arduino-GPIO. Enfin, la gestion des accélérations/décélérations, changement de direction, activation/désactivation moteur, ont été dévolues à un timer dédié servant de « modulateur de fréquence » comme le montre cette capture...
Les avantages:
- Le fonctionnement des moteurs à vitesse constante est très peu gourmand en temps processeur.
- Cela ouvre la porte pour faire sans souci du goto en microstepping 1/16 là où d’autres projets sont contraints de basculer à la volée en 1/2 pas voire même en fullstep pour tenir la cadence.
- L’intégration du rattrapage de jeu et la correction d’erreur périodique pourront se faire au niveau du timer d’accélération sans impacter les performances des interruptions moteur.
Présentation vidéo de l'analyseur logique 24MHz 8CH Saleae...
Analyseur logique Saleae à moins de 15€
Le clone est parfaitement compatible avec le logiciel proposé par Saleae qui est on ne peut plus simple d’usage. Mon Mac adore et moi tout autant...
Du coup, je me suis amusé à pousser mon Arduino dans ses retranchements juste pour le fun histoire de voir si l’analyseur suivait. Aucun problème, le Arduino décroche bien avant lui. 8Mhz semble sa limite (optimisation max avec suppression du loop et écriture direct sur les ports d’entrées/sorties) soit 0,125us*2 = 0,250us de largeur de période d’impulsion. Largement de quoi faire clignoter une led quoi… Lol
La mesure de gauche (0,25us) montre le rebouclage de la boucle infinie while.
On voit encore mieux en dézoomant: 16 périodes du fait de la redondance de code dans la boucle sur 3,875us puis un trou lié au rebouclage…
Et voici un lien vers le code source pour les curieux…
arduino_max_blink.zipJe pense que j’en ferais un article détaillé à l’occasion car cela va être un outil précieux pour une calibration optimale de mes moteurs pas à pas par rapport à la vitesse sidérale.
Edit: non en fait on peut encore mieux faire et monter à 8Mhz par période. On en reparle un peu plus tard. :)