Liaison petit module fréquencemètre avec le P.C.
Heureux propriétaire du mini fréquencemètre approvisionné en ligne, vous avez soudé les composants sur les deux circuits imprimés et réuni le total avec des entretoises quelconques pour en faire un assemblage rigide.
Dès que l’on alimente l’électronique, l’afficheur s’illumine et le programme démarre, c’est un KIT sans histoire pour qui est capable d’effectuer des soudures propres. Deux prototypes ont été réalisés et assemblés par des entretoises de récupération, mais de la simple tige filetée de 2,5 mm ou 3 mm convient tout aussi bien avec en outre la faculté d’ajuster finement les écarts entre modules. Pour modifier à convenance le logiciel inclus dans l’ATmega328 il faut maintenant réaliser une ligne de « téléversement » entre l’IDE, (Système de développement de programme en langage C spécifique à l’ATmega328.) et le microcontrôleur en attente sur son support à 28 broches.
La chaîne de dialogue entre IDE et ATmega328
Assez logique à comprendre, la Fig.2 nous permet des lister la chaîne d’échanges d’informations à établir entre notre cerveau et la « puce » électronique du microcontrôleur. Le premier interprète est le langage C compréhensible par nous les humains, et par le compilateur de l’IDE. Notre pensée commence par translater l’instruction que nous désirons soumettre au microcontrôleur en une phrase codée avec rigueur dans une syntaxe précise nommée LANGAGE C.
Matériellement on fait intervenir un micro ordinateur désigné P.C. en 1 dans lequel « tourne » un programme IDE. Ce programme exploite les consignes de la souris et les textes frappés au clavier. Il intègre donc un éditeur de texte. Puis, le programme étant écrit, on le propose au compilateur.
Dans un premier temps ce dernier active un analyseur syntaxique pour vérifier que tout ce que nous avons écrit dans le code SOURCE respecte totalement les règles du langage C++ relatif à l’IDE. Si tout est bon, le code SOURCE est alors soumis au compilateur qui fait partie intégrante de l’IDE. Le compilateur transforme les instructions code SOURCE en un code OBJET binaire que pourra réaliser le microcontrôleur, seul « langage » qu’il connaisse. Il faut maintenant téléverser ce code binaire dans la mémoire de programme située dans une zone bien précise du microcontrôleur. Sur le P.C. le moyen actuel le plus utilisé pour établir des liaisons « à chaud » avec des périphériques quelconques consiste à utiliser à profusion des lignes dites USB.
Tout dialogue suppose un langage commun entre celui qui parle et celui qui écoute. Pour les lignes USB on utilise le vocable de protocole. Sur le P.C. les protocoles sont installés sous forme de DRIVERS, c’est transparent utilisateur. Mais sur le périphérique, c’est à son concepteur d’y inclure de l’électronique spécifique et des programmes de protocole. Notre mini fréquencemètre n’est pas pourvu de ligne USB et ne peut dialoguer avec l’extérieur. Il nous faut donc intercaler une électronique très compliquée 3 avec sa prise USB 2 intégrant le protocole incontournable. Ensuite on doit ajouter une ligne filaire 4 entre cette électronique compliquée 3 et le connecteur spécial prévu à cet effet 5.
Enfin, la ligne USB va échanger des données binaires, mais avec ses propres protocoles. Il faut donc entre l’IDE et le microcontrôleur un langage commun. C’est le but du bootloader 6 qui est déjà intégré dans l’ATmega328. OUFFFFFFFFFFFFF !
Heureusement pour nous, l’électronique compliquée 3 avec sa prise USB 2 et les protocoles d’échange existent « clef en main ». Il suffit d’utiliser une carte Arduino UNO spécialement conçue pour satisfaire ces contraintes. C’est l’IDE qui permet par des dialogues particuliers de téléverser un programme issu du compilateur dans l’ATmega328 via le bootloader. Les microcontrôleurs équipant Arduino sont déjà un peu modifiés puisqu’on y a programmé ce petit programme de dialogue bootloader. Il serait concevable d’enlever le microcontrôleur d’Arduino qui est sur un support, d’y placer celui qui sera dans le mini laboratoire. Puis programme au point d’effectuer l’échange. C’est avec cette approche que nous avons mis au point le laboratoire USB.
Mais dans notre cas une telle technique n’est pas du tout pertinente, car en version de base l’Arduino ne dispose pas d’afficheur LCD. De plus, dans un projet aussi élaboré que celui-ci, quand l’essentiel est déterminé, il est impératif de programmer directement « sur site », seule technique qui fait apparaitre les problèmes spécifiques au fur et à mesure du développement.
Extraire l’ATméga328 résidant sur la carte Arduino UNO qui se réduit alors à une électronique spéciale USB incluant des protocoles de dialogue à la fois USB, ça c’est la ligne « porteuse » et « IDE » associé au bootloader, constituant parleur et écouteur. Le dialogue est bilatéral. La Fig.3 présente notre nouvelle chaîne d’échanges d’informations entre P.C. et périphérique.
Possédant une carte Arduino UNO il ne nous reste plus qu’à réaliser la ligne filaire 4 qui va relier le petit connecteur d’Arduino à celui 5 du mini fréquencemètre. Il serait possible de se fabriquer une telle ligne « directe » comme expliqué sur la fiche nommée Téléportage externe d’un programme. Vous pouvez constater au passage qu’outre les six fils du petit connecteur ICSP il faut également relier D0 et D1.
Attention : Cette fiche est relative à une liaison entre une carte Arduino et un fréquencemètre non autonome. C’est Arduino qui alimente en +5Vcc. Par contre, quand le mini laboratoire sera équipé de sa propre alimentation il sera IMPÉRATIF de supprimer le fil reliant le +5Vcc pour ne pas mettre en « opposition » le régulateur de l’appareil de mesure avec l’énergie apportée par la ligne USB. Comme le précise la Fig.4 une dernière petite anticipation s’impose et l’on va pouvoir enfin concrétiser la ligne de dialogue entre « périphérique mini laboratoire » et IDE dans le P.C. :
Le mini fréquencemètre sera enfermé à son tour dans un beau petit coffret réalisé à ses dimensions. Il faut donc prévoir d’ouvrir la ligne 4 et de la munir d’un connecteur idoine. Personnellement j’utilise depuis des années des connecteurs de type DB car ils sont peu onéreux, très courants et fiables. En l’occurrence le prototype est équipé d’une DB9. Vous pouvez dans un premier temps fabriquer une ligne directe et alimenter votre module par la ligne USB. Il suffit de réaliser un câble deux fois trop long, puis de le couper le moment venu pour intercaler la DB9.
La Fig.5 montre la version définitive de notre limande de programmation sur site. Le mini laboratoire est vu coté droit sur lequel on trouve divers aménagements, les détails en seront donnés dans le chapitre relatif à la réalisation. La fiche Téléportage sur site d’un programme précise les divers branchements à effectuer pour ce câble de dialogue. Notez au passage que les traits pour représenter les fils sur la Fig.4 ne respectent pas le brochage réel de la DB9, ce n’est qu’un croquis imagé.
