Salut,
ma remarque ne concernait absolument pas le C++, même si je connais des spécialistes qui n'en pensent pas beaucoup de bien. Mais c'était suite au post de Simon74 qui disait ne plus utiliser C ou C++, je n'ai pas compris en quoi il programmait. Là n'est pas la question.
Je viens de relire ses posts, et je pense que c'est simplement une incompréhension, il dit que lui ne code plus trop en C/C++, pas qu'il ne faut plus les utiliser (encore un qui à basculer du côté obscur et qui fait du JS j'imagine
mais sur PC).
Sur STM32 il n'y a pas vraiment d'alternative au C/C++ ... il y a bien eu des STM32 qui faisaient tourner du java, mais la bonne blague est terminée.
On peut rajouter des surcouches type python, mais le moteur d'exécution reste bien en C/C++.
Et sinon j'invite cordialement ces spécialistes à la formation qu'on prépare sur le sujet avec ST, ils devraient apprendre beaucoup de choses.
Pour revenir au sujet initial:
- c'est un codeur incrémental sur une broche ?
- quel CPR, et quelle vitesse de broche max ?
- quel but final ? Si je comprend bien c'est pour du filetage, donc il faut synchroniser l'avance sur la rotation de la broche ?
Du coup ce n'est pas une question de vitesse (qu'on peut calculer séparement pour l'affichage), mais plutôt de position.
Quelle est l'erreur admissible sur la synchro (idéalement en nombre de pas du PaP de sortie) ?
Si tout ça est bon, on pourrait envisager:
- un timer en entrée en mode encodeur, qui va calculer la position comme un grand (A et B), attention à prendre plutôt TIM2 ou TIM5 qui sont sur 32 bits (les autres sont sur 16 bits), ça évitera d'avoir à gérer les dépassements.
- un timer (Systick) qui déclenche à intervalle régulier (1ms par exemple), qui prend la valeur de l'encodeur, applique un facteur (calcul entier), et en déduit la position attendue en sortie
- un timer (heureusement qu'il y en a beaucoup sur les STM32 !!!) en sortie, dont le ARR et le pulse count aura été réglé de sorte à générer le bon nombre de pulses (différence entre position actuelle et position que l'on vient de calculer) sur 1ms.
De cette façon on a toujours 1ms de décalage fixe entre l'entrée et la sortie (à voir en fonction de l'erreur admissible), pas d'accumulation d'erreur, et le MCU n'a quasiment rien à faire (en tout cas pas à gérer les timings précis, c'est les timers qui vont s'en charger).
[EDIT] et surtout la sortie sera suffisamment lissée (pour ne pas envoyer un paquet de pulses d'un coup, que le pas à pas soit bien propre et ne donne pas d'à coup).
Et tout les 100 cycles de calculs (donc à 10Hz), on fait le delta global de position en entrée, on multiplie par 10 et on a la vitesse (en CPR/s, reste à convertir en RPM pour l'affichage).
Thomas.