Club robotique de Sophia-Antipolis

Accueil > POBOTpedia > Autres constituants d’un robot > Les circuits spécialisés > Les contrôleurs de moteur > Le dSPIN de ST-Micro : un driver évolué pour moteur pas à pas

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

mercredi 11 juillet 2012, par Eric P.

 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 :

Tension de service8-45V
Courant max.3A en continu, 7A en pointe
Micro-pasjusqu’au 1/128ème
Détection de blocagesans capteur
Protection sur-intensitéoui
Protection surchauffeoui
Détection de sous-tension moteuroui
CommunicationSPI jusqu’à 5Mbit/s
Horloge processeurinterne <= 16MHz ou externe <= 32MHz

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 :

JPEG - 259.3 ko
Dispositif d’expérimentation

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

Zip - 27.8 ko
Sources classe dSPIN et démo
version du 22/07/2012

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 ;)

Vos commentaires

  • Le 12 juillet 2012 à 16:17, par Esprit En réponse à : Driver évolué pour moteur pas à pas

    Merci pour cet article. Il est, comme toujours, très intéressant et ça servira peut-être un jour. ;-)

    • Le 22 juillet 2012 à 10:11, par Eric P. En réponse à : Driver évolué pour moteur pas à pas

      Merci pour le compliment ;) Ca fait toujours plaisir.

      L’article va certainement évoluer car j’ai déjà fait quelques évolution à la classe fournie.

    Répondre à ce message

  • Le 22 juillet 2012 à 10:45, par Eric P. En réponse à : Driver évolué pour moteur pas à pas

    Article et programme de démo mis à jour.

    Change log :
    - corrections de bugs d’unités dans la lib (steps-per-sec vs. steps-per-tick)
    - mise à jour documentation du source
    - prompt de commande simplifié
    - ajout d’une fonction d’aide listant les commandes disponibles

    Répondre à ce message

  • Le 27 janvier 2014 à 20:36, par lepro En réponse à : Le dSPIN de ST-Micro : un driver évolué pour moteur pas à pas

    Bonjour,
    je suis intéresser par ces cartes de contrôle j’ai pour projet de fabriquer une cnc à l’aide d’Arduino.
    J’ai un problème sur le site sparkfun où est vendu ces cartes ils donnent une librairie mais je ne l’ais pas très bien comprise, je ne sais pas quoi paramétrer. si vous avez une idée pour m’éclairer.
    cordialement.

    • Le 5 février 2014 à 07:43, par Julien H. En réponse à : Le dSPIN de ST-Micro : un driver évolué pour moteur pas à pas

      Bonjour,

      Ces cartes sont destinées à des utilisateurs ayant déjà une bonne connaissance des contrôleurs, notamment pour gérer tous les paramètres. Si la réponse n’est pas dans nos articles sur les dSpin, merci de nous décrire quels paramètres vous posent problème. S’il s’agit d’une incompréhension globale sur l’ensemble de la carte, avez-vous déjà testé avec des contrôleurs plus simples, comme les boitiers pour CNC que l’on trouve chez http://www.soprolec.com ?

    • Le 5 février 2014 à 19:50, par Eric P. En réponse à : Le dSPIN de ST-Micro : un driver évolué pour moteur pas à pas

      Compte-tenu du manque d’expérience que vous semblez avoir sur le sujet (si j’en juge par le contenu du message), je ne conseille pas d’utiliser ce type de module mais des modules plus simples comme Julien le suggère.

      La difficulté pour une CNC est d’être certain de ne pas "rater" de pas, à cause d’une accélération trop forte, où d’un mauvais contrôle du courant. Le dSpin permet de gérer tout cela, mais il faut le paramétrer en conséquence pour qu’on soit certain ensuite que les commandes envoyées seront exécutées au micro-pas près.

      Si votre projet est de piloter la CNC par une Arduino, il vaut mieux opter pour une solution où vous allez générer directement les signaux clock et dir pour attaquer un driver comme celui que Julien mentionne. A vous de gérer les accélérations "manuellement", mais c’est accessible. Ce sera peut-être moins fluide et moins efficace mais ça permettra de débuter et d’obtenir des premiers résultats.

      Ceci étant, j’espère que vous avez mesuré la complexité du problème. Pour information, un petit boitier comme l’Axe Motion qui équipe notre CNC (cf autres articles de notre site) est basé sur un ARM 32 bits. Il faut cela pour effectuer suffisamment rapidement les calculs de cinématique requis pour convertir les ordres reçus (du GCode généralement) en contrôle temps réel des moteurs. Sauf si vous vous limitez à des mouvement très simples, je ne suis pas du tout certain qu’une Arduino soit capable de cela.

    Répondre à ce message

Un message, un commentaire ?

modération a priori

Attention, votre message n’apparaîtra qu’après avoir été relu et approuvé.

Qui êtes-vous ?

Pour afficher votre trombine avec votre message, enregistrez-la d’abord sur gravatar.com (gratuit et indolore) et n’oubliez pas d’indiquer votre adresse e-mail ici.

Ajoutez votre commentaire ici
  • Ce formulaire accepte les raccourcis SPIP [->url] {{gras}} {italique} <quote> <code> et le code HTML <q> <del> <ins>. Pour créer des paragraphes, laissez simplement des lignes vides.

Ajouter un document