Fonctionnement
  de QuickStep

L'horloge

Pour envoyer régulièrement des pas à un moteur pas à pas, il y a plusieurs méthodes qui ont chacune leurs avantages:
- on utilise une fonction bloquante qui envoie les ordres, c'est ce qu'utilise la bibliothèque Stepper
- on appelle régulièrement une fonction run() qui fait avancer si besoin le moteur. La bibliothèque AccelStepper utilise ce procédé. L'avance d'un moteur n'est pas bloquant, par contre loop() ne doit pas l'être car il faut appeler plus souvent la fonction run()
- on utilise une interruption qui fait avancer les moteurs, ainsi même loop() peut être bloquante. QuickStep profite de cette solution.

QuickStep utilise par défaut le timer 2, afin de laisser le ou les timers 16 bits à d'autres applications. Mais on peut utiliser n'importe quel timer. Il est possible d'utiliser le timer 0 qui est aussi utilisé par delay(), millis() et micros() sous quelques réserves.

Le temps de base se choisit automatiquement ou par quickStepBaseDeTemps(). Un moteur peut ainsi recevoir des changements de pas entre 1,00 et 255,00 fois ce temps de base (par incréments de 1/256). Avec un timer 8 bits, la base de temps peut être choisie entre 12µs (en dessous la bibliothèque passera tout son temps à calculer les interruptions) et 16ms. Avec un timer 16 bits, le temps de base peut aller jusqu'à 4s (on peut donc avancer d'un pas toutes les 1000s environ).

Plus le temps de base est grand, moins on passe de temps dans les interruptions. Il est donc conseillé de prendre comme temps l'écart le plus petit entre deux pas (ou deux micro-pas) pour tous les moteurs et pour les vitesses maximales de chacun d'eux. Cela se fait automatiquement si on définit les vitesses maximales dans le fichier de configuration.

Si on demande à un moteur de tourner plus vite ou moins vite que ce que permet le timer, il tournera à la vitesse permise la plus proche

La pile des ordres

Une pile FIFO (first in first out) permet de donner des ordres à l'avance. La pile peut contenir de 1 à 255 ordres utiles. Plus la pile est importante, plus on peut donner de mouvements à l'avance, mais plus cela utilise de place dans l'espace des données. Pour 5 moteurs ayant chacun une pile de 255 ordres, cela occupe au moins 4octets*5moteurs*255ordres soit 5ko. Une Uno n'en a que 2, et cela occupe plus de la moitié des 8ko d'une Mega.

Si la pile ne contient qu'un ordre, on ne peut pas enchaîner deux mouvements sans un temps d'arrêt. Si on ne souhaite pas enchaîner les ordres, la plus petite taille peut convenir.

Si il y a de la place dans la pile, les ordres y seront rangés. Si il n'y a plus de place, la fonction qui demande le mouvement devient bloquante car il faut qu'elle attende qu'une place se libère.

Les accélérations

Les accélérations se font par paliers de vitesse. Par exemple, on tourne 100 pas à V_MAX/4,12, puis 100 pas à V_MAX/2,92, 100 pas à V_MAX/1,73...

On peut choisir entre 1 et 255 paliers. Un palier est équivalent à un ordre de rotation. Plus le nombre de paliers est important, plus l'accélération est douce et plus elle démarre lentement. Mais une accélération sur N paliers va prendre N ordres dans la pile. C'est exactement pareil pour les décélérations. L'ordre de rotation global ne sera pas bloquant si tous les ordres des palier entrent dans la pile. Si on souhaite accélérer avec A paliers et décélérer avec D paliers, pour ne pas être bloquant (ce n'est pas une obligation!), il faut au moins une pile de A+D+1 ordres (A plus D plus 1 pour le palier à vitesse constante).

Fichier de configuration

Pour pouvoir avoir des vitesses élevées, au lieu d'accéder aux ports par des variables, l'accès se fait en dur. Il faut donc que les valeurs des ports se fasse à la compilation. C'est pour cela qu'il y a un fichier de configuration et pas une déclaration à l'exécution. Cela implique de mettre tous les fichiers de la bibliothèque dans le répertoire de travail. Pour faire un programme il faut donc ajuster les paramètres via le fichier de configuration et écrire son programme .ino