Club robotique de Sophia-Antipolis

Accueil > Projets, études > Nos réalisations > Carte Numérique Polyvalente > Une mini-CNP pour module MR163 > Mini carte CNP

Mini carte CNP

dimanche 28 janvier 2007, par Eric P.

Avant toute chose, cette carte ne cherche pas à rivaliser avec notre CNP de course. Il s’agit juste d’une mini carte d’expérimentation pour faciliter l’utilisation des modules MR163 vendus par Lextronic (plus d’infos).

Le pourquoi du comment

Nous avions acheté ces modules lors de la construction des xPo, afin d’en faire le coeur. A cette époque, nous avions développé une mini carte mère dont la fonction n’était que de sortir les I/O de l’Atmega sur des headers mâles, afin de faciliter la connexion des divers capteurs et actionneurs supposés équiper le robot.

Avec le temps, et après avoir fait joujou avec une carte d’expérimentation EasyAVR4 de chez MikroE, le besoin de quelque chose d’intermédiaire s’est fait ressentir.

Cher Père Noël, je voudrais...

Le cahier des charges est donc :
 accueillir le module MR163 (c’est bien la moindre des choses)
 avoir une alimentation régulée à bord, pouvant être isolée du reste de la carte, et supportant toute erreur de branchement
 offrir un connexion facile aux diverses I/O
 disposer d’un connecteur I2C 4 fils , avec résistances de rappel intégrées, ligne d’alimentation déconnectable et jumpers d’isolation des signaux
 disposer d’un connecteur série TTL 3 fils dédié
 intégrer un convertisseur Série TTL/RS232 déconnectable

On retrousse les manches

Une petite séance d’Eagle plus tard, et on a le schéma :

ainsi que la carte :

Remarque : n’essayez pas de faire un typon à partir de cette image, car le résultat ne sera pas garanti, à cause de l’export. Faites-le plutôt à partir du fichier Eagle fourni en annexe. Il peut être ouvert et manipulé avec la version light d’Eagle, qui est gratuite.

Tant qu’on y est, une petite image virtuelle en passant par POVRay :

Gravure de la carte, perçage et soudage terminés, voici le résultat en fonctionnement :

Connecteurs

Ne vous posez pas de question concernant la polarité du connecteur d’alimentation : il n’y en a pas, pour éviter tout dégât suite à une inversion, et cela grâce au pont redresseur en tête de la section régulatrice. OK, c’est au prix d’une chute de tension supplémentaire, puisqu’on traverse 2 diodes au total, et qu’on perd donc 1,2V en bout de course. Si cela devait vous poser des problèmes (en cas d’alimentation par un pack d’accu en 7,2V par exemple), vous pouvez supprimer le pont redresseur et placer des straps de telle sorte que le plot central du jack de branchement de l’alimentation externe corresponde au +.

Quant au bornier à vis, il est tout simplement en parallèle du jack, et peut être utilisé pour des fils volants en provenance de votre alim de labo ou du pack d’accu.

La prise DB9 se passe de tout commentaire. Pensez juste à utiliser un câble croisé pour la relier à un PC.

Le connecteur blanc à 4 points est pour l’I2C. Reportez-vous au schéma électronique et au schéma d’implantation pour le brochage.

Le connecteur blanc à 3 points est la sortie série TTL.

Pour les différents jumpers, le mieux est de consulter les schémas, ce sera beaucoup plus simple et fiable qu’un long baratin ici.

Quant aux connecteurs 10 points des différents ports, même punition, même motif. Remarquez bien qu’en plus des 8 signaux de chaque port, ces connecteurs ont également un Vcc et une masse pour vous faciliter la vie au niveau de la connexion de périphériques.

Quelques galères au passage... et leur résolution

Cet article aurait pu se terminer ici, mais je me suis souvenu qu’à l’occasion d’une discussion lors d’une récente réunion d’assoc, un des membres de l’équipe a émis le souhait que soient détaillées les galères rencontrées par les uns et les autres. Non pas par pur sadisme et/ou voyeurisme, mais pour que soient expliquées les démarches utilisées pour investiguer les problèmes et les résoudre. Dont acte, et voici donc les miennes 😉

Lors des essais de la carte, et plus précisément de la partie RS232, j’ai écrit un programme de 3 fois rien pour envoyer des caractères sur la ligne série, et vérifier que la communication se passait bien, via un Hyperterminal en face. Tout aurait dû bien se passer, et pourtant... Ca m’a bouffé un dimanche, à ne voir s’afficher que des "n" et quelques "N" au lieu des messages envoyés. Le même programme fonctionne très bien sur la carte EasyAVR. A n’y rien comprendre.

Première étape : vérifier si le circuit est correct, à savoir si aucun composant n’a été branché à l’envers, ou s’il n’y a pas de court-circuit entre deux pistes. Vu la simplicité de la carte, c’est vite contrôlé, et il n’y a rien d’anormal de ce côté.

Nouveau symptôme : au bout de quelques essais, il n’y a plus moyen de télécharger le code sur le MR163, la vérification se soldant par un échec. Pendant un moment j’ai cru que le module avait fini par rendre l’âme. Dans ce genre de situation, on cherche d’abord à confirmer le diagnostic, en éliminant tout ce qui pourrait apporter du "bruit". En retirant du circuit la seule chose qui pouvait l’être, à savoir le MAX232, les choses rentrent dans l’ordre et le MR163 fonctionne à nouveau correctement. Ben zut : un MAX grillé ? Première fois que je vois ça, et pourtant il m’est arrivé d’en brancher un à l’envers, sans que ça ne lui soit fatal. Bon. Il y en a un autre en stock, et donc on remplace. Même punition, même motif. La probabilité de griller 2 MAX232 en 10 minutes étant quand même epsilonnesque, il y a forcément quelque chose d’autre.

On attaque au multi-mètre pour vérifier les tensions remarquables, ici les alimentations. Et là, il y a un truc : sur le Vcc du MAX232 il y a à peine 3V. Là ça fait tilt. Ce que je n’avais pas dit jusqu’à présent, c’est que j’utilise un programmateur ISP pour port USB, vu que ma nouvelle bécanne n’a plus de port parallèle. Je l’ai d’ailleurs présenté dans un article récent sur ce site. Or celui-ci a la possibilité d’alimenter le montage qu’il programme, via un jumper. Ca fonctionne très bien ordinairement, tant que le montage cible ne consomme pas trop, et surtout se contente de .... 3V (et non 4,5V comme indiqué incorrectement dans la doc). Notre problème est là : autant le MR163 peut se satisfaire de 3V et quelques, autant le MAX232 ne peut pas faire son boulot dans ces conditions. Et comme il pompe sur l’alimentation, du coup celle du MR163 s’en trouve perturbée, d’où les problèmes rencontrés lors de l’upload des binaires, et leur disparition dès que le MAC232 n’était plus en piste. Le remède est simple : on retire le jumper du programmateur qui permet d’alimenter le montage cible, et on connecte un quelconque adaptateur secteur sur le jack d’alimentation, sans oublier de positionner le jumper qui relie la partie alim au reste de la carte. Allélouia : la reprogrammation du MR163 fonctionne à nouveau comme un charme. Soulagement général.

Par contre, toujours le même dysfonctionnement côté transmission série. Je remarque alors qu’au lieu des "." attendus que j’envoie périodiquement sur la ligne, l’affichage ne contient que des "n". Or le code ASCII du "." est Ox2E, et celui du "n" 0x6E. Quant à celui du "N" observé par moment, c’est 0x4E. Curieuse coïncidence : les derniers bits du caractère sont les bons, et il y a un truc sur les autres. Petit test : et si on remplace le "." par autre chose ? Et bien, on observe alors le même phénomène avec le nouveau code ASCII. Ce genre de comportement est en général la preuve d’un problème de mauvais paramètres de transmission. Pourtant la vitesse est la même des deux côtés. D’ailleurs si on la modifie tant au niveau d’Hyperterminal que du programme de test, on se rend vite compte que le paramétrage actuel devrait être le bon (c’est à dire qu’il donne bien un caractère affiché pour un caractère envoyé).

Il faut donc chercher du côté du signal RS232 alors. On range le multimètre et on sort l’oscillo. Pas de chance, le signal est correct, avec des amplitudes largement dans les normes. Et qui plus est il est identique à celui que je relève sur la carte EasyAVR qui exécute le même code. Incroyable....

Enfin, quand je dis identique, c’est à quelques pouièmes près au niveau des durées des créneaux. Mon oscillo n’étant pas numérique, je n’ai malheureusement pas d’autre moyen de les mesurer qu’avec les curseurs (ce qui est mieux que sur mon vénérable HAMEG 2x5MHz où la seule solution était de compter les carreaux). Comme je ne peux pas superposer les courbes, vu qu’il faut brancher l’oscillo tour à tour sur chacune des cartes, on ne peut pas comparer de manière hyper précise, mais il y a néanmoins une petite différence, qui pourrait expliquer que la durée des créneaux ne donne pas les bonnes successions de bits.

Il est alors temps de se rappeler que la vitesse de transmission se règle sur un AVR en configurant un diviseur d’horloge dans l’un des registres de l’USART. Le datasheet donne la valeur de ce diviseur pour toutes les vitesses possibles et les fréquences d’horloge supportées. Celle qui est utilisée dans le programme de test est bien celle indiquée dans les tableaux, mais j’ai quand même envie de faire du "fine tuning" pour voir. Et là, grosse surprise : en faisant varier la valeur du diviseur petit à petit, je finis pas faire fonctionner correctement la transmission. La valeur magique serait-elle connue ? En bien oui, elle existe bien dans le tableau de la doc, et correspond à 9600 bauds (la vitesse à laquelle je voulais configurer la transmission), mais pour une horloge à 7,3728MHz. Et là tout s’éclaire. Cette valeur ésotérique n’est pas le fruit du hasard : il se trouve que par division, elle permet de tomber juste pour toutes les vitesses de transmission standard, ce que ne permet pas une horloge à 8MHz par exemple. Vous pouvez d’ailleurs le vérifier dans le tableau du datasheet, car c’est la seule fréquence d’horloge pour laquelle toutes les vitesses de transmission sont obtenue avec une erreur nulle. Pour les autres combinaisons, tant qu’on reste en-dessus de 0.5% d’erreur, ça va bien mais pas au-delà.

La conclusion suivante s’impose donc : contrairement à ce qui est écrit à maintes reprises dans la documentation du module MR163, le quartz qui est installé n’est pas un 8MHz mais un 7,3728MHz, sans doute pour permettre de tomber rond au niveau des transmissions séries. Or si on configure les devices comme si le micro tournait à 8MHz, il est clair que l’erreur introduite alors sort largement des tolérances. CQFD.

On modifie donc le makefile pour configurer la fréquence d’horlonge (variable F_CPU si comme moi vous travaillez sur la base des makefiles construits par WinAVR). Attention à bien entrer toutes les décimales, et non pas la valeur sur 3 chiffres utilisée dans le datasheet de l’ATMega163, car sinon ça ne marchera toujours pas. Et là, c’est le nirvâna : on retrouve bien nos données correctes sur Hyperterminal, et les caractères saisis sont récupérés sans erreur par le MR163. Yesseuuu 😄

Le mot de la fin

En conclusion, je bénis ces $%* !§** d’auteurs des différentes docs, grâce à qui j’ai bien cru devenir dingue, et grâce à qui j’ai passé un dimanche peu productif.

Quoique tout bien considéré, cela n’a pas été aussi improductif, car j’ai finalement pu vous faire profiter en prime de quelques tuyaux sur la manière de chercher les causes de mauvais fonctionnement d’un montage. Soyons positifs 🙂

Retenez donc ceci en prime :

 le programmateur USB décrit précédemment ne délivre pas du 4,5V comme dit dans la doc (et ils insistent bien dessus, en indiquant de bien vérifier que le montage cible supporte une telle tension)
 l’horloge des MR163 Microbot vendus pas Lextronic n’est pas à 8MHz contrairement à ce que dit la doc là encore.

Moralité : trust no one, comme aurait dit Mulder...

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 champ accepte les raccourcis SPIP {{gras}} {italique} -*liste [texte->url] <quote> <code> et le code HTML <q> <del> <ins>. Pour créer des paragraphes, laissez simplement des lignes vides.