Le dSPIN de ST-Micro : un driver évolué pour moteur pas à pas

Avant-propos

Des contrôleurs de moteurs pas à pas, nous en avons déjà utilisé un stock. Et vous aussi certainement. Mais tous ont pour point commun de se piloter avec deux signaux, la direction et la clock. A charge donc pour le micro-contrôleur de générer le signal de clock de manière appropriée, afin de gérer (entre autres) les accélérations et décélérations optimales. OK, ça marche me direz-vous, mais que de lignes de code et de cycles processeurs engloutis dans ces tâches de bas niveau :/

Fort heureusement, STMicro a dû entendre notre grande souffrance, et propose un chip miracle, répondant au doux nom de L6470, ou plus familièrement dSPIN. Il s’agit d’un driver de moteur pas pas qui se configure et se pilote tout simplement en SPI, en gérant lui-même les vitesses maximales, accélérations, décélérations, limitation de courant,... le tout en micro-pas et avec optimisation des effets de FCEM du moteur. Bref, que du bonheur :)

Le bidule est comme il se doit de nos jours un CMS avec des pattes toutes rikiki, mais par chance, Sparkfun propose un breakout board permettant de mettre ce joujou en oeuvre sans piquer une crise.

Cet article est une rapide présentation de la bête, au travers de son utilisation via un mBed (ça aussi c’est une nouveauté pour moi).

Le L6470

Comme dit plus haut, son nom de code est dSPIN. Ne me demandez pas ce que cela signifie, si ce n’est que "spin" se traduit par "tourner sur soi-même", ce qui pour un moteur n’est pas quelque chose de totalement incongru.

Je ne vais pas recopier ici la datasheet de la merveille, vous la trouverez en document joint à cet article. Quelques caractéristiques de base cependant, histoire de savoir à qui nous avons affaire :

Autre caractéristique intéressante : le dSPIN génère lui-même sa tension pour la logique à partir de la tension pour les moteurs. Ainsi plus besoin de deux alimentations, et du respect scrupuleux de la séquence de mise sous tension imposée par certains chips, faute de quoi ils se transforment en générateurs de fumée.

Et pour finir l’énumération :
– une entrée logique est disponible, pouvant permettre le contrôle du moteur (rotation du moteur jusqu’au changement d’état de l’entrée), utile pour une prise d’origine par exemple
– un ADC 5 bits est également disponible, pouvant servir un asservissement en fonction d’un signal analogique externe
– un compteur pour le stockage de la position courante
– une mémoire de position (MARK)
– un signal BUSY permettant de savoir si la commande a fini d’être exécutée
– un signal FLAG de notification d’événements configurables
– TTL 5V compliant : il suffit de relier le 5V à l’entrée VDD du dSPIN (je n’en ai pas eu besoin ici car on fonctionne en logique 3V3 des deux côtés)

Il y aurait encore plein d’autres choses à raconter, mais je vous laisse les découvrir en lisant la documentation (chacun son tour).

Le mBed

Avant toute chose, ceci n’est pas un article sur le mBed. Consultez plutôt cet article.

Les principales raisons pour lesquelles il entre en piste sont les suivantes :
– c’est un micro-contrôleur de puissance respectable (bien au-dessus de ce dont on a besoin ici),
– on peut le programmer facilement, grâce l’utilisation du C++ (le vrai), l’existence d’une bibliothèque bien fournie, et au fait qu’il se présente comme une mémoire de masse sur laquelle il suffit de copier le (ou les) binaire(s) exécuter
– je cherchais une occasion de l’essayer

Ceux qui en ont déjà entendu parler savent sans doute qu’ la base l’IDE propos par NXP est une application en ligne. Bon, ce n’est pas trop mal fait et ça marche assez bien, mais personnellement le principe m’a perturbé au niveau du vécu dès que je l’ai su (cela bien avant d’avoir un exemplaire de mBed). Deux raisons à cela :
– dépendance d’une connexion Internet (et Murphy adore faire tomber le serveur dont vous avez besoin comme par hasard ce moment-là)
– malgré les normes progrès faits par les appli Web, on est encore loin du confort d’un Eclipse ou même d’un bon éditeur (comme Vi par exemple ;)

Conclusion (qui n’engage que moi) : l’IDE en ligne c’est bien la première heure pour jouer avec un programme de 10 lignes qui fait clignoter une LED, mais pour du travail sérieux, on oublie.

Heureusement, les informations pour installer une chaîne de cross-compilation off-line ne manquent pas, et le site NXP est très bien fourni sur ce sujet. Mettre en place sur sa machine l’outillage nécessaire n’est donc que l’affaire d’un petit quart d’heure. A noter que plusieurs options sont disponibles, commencer par le compilateur (performant, mais payant et cher) utilisé par l’IDE en ligne, jusqu’à la bonne vieille chaîne gcc. C’est cette dernière option qui a bien entendu retenu mes faveurs :)

L’installation de gcc pour le mbed consiste en gros à installer la toolchain croisée pour l’ARM de l’mbed, mais également à patcher les headers de la libraire. En effet, un certain nombres de constructions semblent ne pas adhérer à 100% à la norme, et cela donne des erreurs de compilation du genre "use of enum ’...’ without previous declaration".

Heureusement, des pionniers ont préparer le terrain, et la procédure à suivre est détaillée clairement ici

Le paragraphe est en cours de révision
Sans entrer dans les détails (encore une fois, une rubrique sur le mbed s'en chargera), la procédure consiste à : - télécharger le [cross compilateur->https://launchpad.net/gcc-arm-embedded/4.6/2011-q4-major]. Attention, ce lien pointe sur la version en date de rédaction de cet article.Celle-ci peut évoluer et donc le lien en être modifié en conséquence. Dans ce cas, le mieux est de consulter la page relative à l['export d'un projet->http://mbed.org/handbook/Exporting-to-GCC-ARM-Embedded] vers GCC sur le site mbed. - il nous manque les libs mbed. Pour les récupérer, c'est simple : -* lancer l'IDE en ligne {(promis, c'est la dernière fois)} -* créer un projet bidon {(genre hello-world à 2 balles)} sur le site en ligne -* l'exporter via un click droit sur le projet dans le volet "Program Workspace" -* récupérer le sous-dossier LPC1768 dans l'archive obtenue : il contient les libs binaires et les includes associés -* placer le tout là dans un répertoire qui sera référencé dans les Makefiles au niveau des options d'include et de link
(explications relatives aux librairies en cours de rédaction...)

Outre la récupération du contexte de compilation et de link, l’avantage de cette méthode est qu’on récupère un Makefile qui servira ensuite de template pour les autres projets. Il suffira alors d’initialiser le layout des répertoires et d’y placer une version customisée du Makefile, sans plus avoir besoin de se connecter sur l’IDE en ligne.

Nous voici donc aux commandes d’un Eclipse équipé du plugin CDT et de la chaîne gcc pour le mBed installée sur notre machine.

Le dSPIN

J’en ai pratiquement tout dit au début de cet article. Le mode opératoire consiste à :
– utiliser divers registres pour le configurer (vitesse mini, vitesse maxi, accélération, décélération,...), y compris pour des paramètres très pointus lui permettant d’optimiser et de gérer les effets dus à la FCEM du moteur, en fonction des caractéristiques de ses bobines (résistance, inductance), de la tension de service, du PWM souhaité,...
– envoyer des commandes de mouvement : absolu, relatif, arrêt soft, arrêt immédiat, retour origine, rotation jusqu’au changement d’état de l’entrée logique,...
– utiliser le signal busy pour savoir si la commande en cours est terminée on non
– consulter divers registres d’état : position courante, alarmes, indicateurs divers,...

Et c’est tout.

Tout cela se fait en SPI comme déjà mentionné, via un protocole très simple : 1 octet de commande suivi par 0 à 3 octets de données selon la commande.

Petite particularité du SPI de notre dSPIN : la ligne chip select doit être pulsée entre chaque octet du message, et non simplement relâchée en fin de communication comme habituellement. Si vous omettez cela, eh bien il ne se passera rien. En effet (et c’est bien précisé dans le datasheet), le processeur interne traite chaque octet au moment où on relâche CS. Si on ne le fait qu’à la fin, seuls les 8 derniers bits reçus seront pris en compte.

Un autre "détail" qui m’a fait perdre un peu de temps : avec le mBed, il semble nécessaire de mettre une pull-up (10k par exemple) sur la ligne MISO (SDO du dSPIN). Avec d’autres MCU, la pull-up interne doit convenir également (et peut-être même peut-on en faire autant sur le mBed, mais la classe DigitalIn fourni ne donne aucune option en ce sens et je n’ai pas cherché plus loin pour le moment)

Dispositif expérimental

Une petite photo vaut mieux qu’un long discours :

Pas grand chose en dire :
– en haut, le mBed
– en bas, le dSPIN sur sa breakout board Sprakfun
– entre les deux la filasse des signaux du SPI, du chip-select, du busy et du standby (utilisé pour le reset du dSPIN)
– entre les deux également :
— la pull-up pour MISO (cf plus haut)
— la pull-up pour BUSY (dont j’aurais pu me passer, en reliant le 5V de l’alimentation du mBed à l’entrée 5V de la carte Sparkfun, et utiliser ainsi la pull-up incluse)
– la filasse qui part vers la droite sont les sondes de l’analyseur logique que j’ai utilisé pour vérifier les transmissions SPI

Le code

Ci-après une archive qui contient :
– les sources de la classe DSpin que j’ai développée pour simplifier l’utilisation du bidule
– le programme de test
– le Makefile

Le programme principal gère un prompt de commande pour activer à volonté les différentes actions programmées. Les 4 LEDs du mBed sont utilisées comme affichage de statut :
– les 3 premières s’allument au fur et à mesure de la complétion avec succès des différentes initialisations du programme. En cas d’erreur à une de ces étapes, la LED correspondante reste en mode clignotant (et un message est affiché sur la console série)
– la 4ème est allumée en synchronisation avec le signal BUSY. Vous remarquerez dans les sources l’utilisation de la classe Ticker incluse dans la librairie mBed, qui permet d’implémenter très simplement des tâches de fond récurrentes.

A noter que le code de la classe est commenté en Doxygen, et que le makefile contient une target pour générer la documentation HTML et PDF (on est sympa, pas vrai ?).

La classe DSPin a été développée au départ en transcrivant pour mBed le code Arduino disponible sur le site Sparkfun. A noter que ce code est compliqué sans raison évidente, et que vous pourrez noter si vous faites la comparaison qu’il y a une différence assez notable avec celui que je propose. Il contient même des bugs (l’original, pas le mien... enfin j’espère).

Il existe également une classe du même genre disponible sur le repository mBed, mais je l’ai trouvée moins complète. Peut-être soumettrai-je la mienne lorsqu’elle sera stabilisée.

Cette classe peut bien entendu être enrichie (et elle le sera, donc revenez faire un tour ici de temps en temps), par exemple avec des fonctions permettant de paramétrer plus facilement les aspects pointus, car pour l’instant il faut en calculer les valeurs à placer dans les registres au moyen de l’utilitaire (Windows only :() fourni par STMicro sur son site Web.

Le résultat

En vidéo pour être plus parlant (bien qu’il n’y ait pas de bande son) :

L’interface de commande utilise la liaison série du mBed, au travers de sa connexion USB. On y accède via un simple émulateur de terminal (screen dans la vidéo).

Vous pourrez noter :
– la souplesse des mouvements (accélérations et décélérations), et ce sans aucune prise en charge par le programme (cf les sources)
– la précision de positionnement : la dernière commande fait revenir le moteur à la position initiale du début de l’expérimentation

Il est de plus évident que la commande du moteur n’est pas optimisée pour le moment, car n’ayant pas la valeur de l’inductance des bobines je n’ai pas pu paramétrer le dSPIN en conséquence et les valeurs pas défaut sont employées. On doit donc pouvoir gagner en couple et en vitesse sans problème.

Je vous invite sur ce point à lire cet article complémentaire, qui présente une méthode de mesure des caractéristiques requises.

Enjoy ;)