Salut Nadar,
J'ai pas mal bossé sur la gestion des moteurs pas à pas, et je me dis que je peux peut-être t'apporter mon expérience.
Dans ta boucle, où tu utilises micros(), personnellement, je la modifierai un peu. Evidemment, la première fois, je l'avais fait de la même manière, mais avec le temps, j'ai pu réaliser certaines améliorations...
Mes drivers (en 1/4 ou 1/8 pas, je ne me souviens plus) et moteurs supportent des impulsions tous les 900ns (et non 1200), et de même, je peux me permettre de ne pas mettre de delaymicros(x) entre l'état haut et bas de l'impulsion envoyée. Cela n'est en rien si important, mais dans ce que je vais rajouter après, cela peut influer légèrement:
Pour les pas à pas, tu le sais autant que moi, on cherche à obtenir le meilleur compromis vitesse/tenue de route.
Et pour obtenir une parfaite qualité de déplacement, j'en ai déduit après de nombreux tests qu'il fallait que j'applique sur mes moteurs pile poil 900ns (à Vmax) entre 2 impulsions (à 4ns près), et non 924ns une fois, puis 904... puisque par moment, on peut interroger les capteurs, cela influant sur les délais.
Pour cela, j'ai utilisé l'expression équivalente à
"if ((micros()-_lastTime) >=_Pa)" au tout dernier moment juste pour lancer l'impulsion, les conditions d'acc, de vitesse constante et décélération ainsi que tout calcul sont à éviter dans cette condition (y compris les capteurs).
Et enfin, l'expression
"_lastTime = micros();", je la place tout comme toi dans cette dernière condition juste après l'impulsion envoyée qui chez moi peut durer parfois 4ns ou 8ns selon.
Bon, je chipote un peu, mais j'ai pu constater que chez mes robots, cela a sensiblement améliorer la tenue de route et la qualité de déplacement.
Après, utilisant des codeurs, j'ai finalement rendu, dans ma boucle, indépendant les impulsions envoyées à la roue gauche de celles envoyées à la roue droite. Ainsi les deux roues ne tournent pas (plus) systématiquement en même temps, et n'ont (peut être) même plus le même nombre d'impulsions puisque cela tient compte de la distance réelle parcourue, et non plus de celle théorique, et l'ordre de départ de n impulsions est rarement identique de celui obtenu à la fin.
Avec ce principe, un robot pas à pas obtient les mêmes comportements de déplacement qu'un robot en moteur cc, ajouté que les déplacements circulaires sont tout simplement plus facile, et peut être un chouia plus propre théoriquement, reste à voir sur un robot similaire, si cela serait vérifié, ce que j'ai hâte de faire prochainement dans mon nouvel atelier... (encore quelques mois de patience).
Après, je salue le travail de partage
où le code est compréhensible "tout public" et facilement modifiable/paramétrable et sympa pour ceux qui sont à la bourre.
A bientôt, et au plaisir de voir les matchs !