Arduino, ATmega328pb, Raspberry Pi et le projet Arbalet.

Durant ma participation au MakerFaire de Nantes en juillet de l'année dernière (2016), j'avais Yoan Mollard en voisin de 'stand'.

Yoan est l'initiateur d'une surface pixelisée interactive opensource :

Vidéo de présentation   Vidéo de l'assemblage de la surface         

Il est bien-sûr possible de trouver de multiples sources de présentation de ce type d'étude sur Internet, mais le grand intérêt du travail de Yoan est que son projet est en cours d'industrialisation, ce qui permettra d'ici quelques mois d'offrir un kit de montage complet, et le plus simple possible.

Et moi, dans cette affaire? Et bien Yoan m'a contacté il y a quelques semaines pour développer certaines parties du projet et notamment une carte compatible Arduino directement insérable sur une carte Raspberry Pi. La carte Arduino qui se présente pour l'instant sous la forme d'une carte standard, sert à interfacer les commandes entre la Raspberry et les rubans de LEDs.

J'ai donc repris mon étude précédente à base de processeur ATmega328pb pour l'adapter aux nouveaux impératifs. En fait c'est assez simple, il a 'suffit' de retirer ce qui n'est pas utilisé comme le port RS485, l'alimentation à découpage etc etc... et d'adapter le PCB pour un assemblage sur une Pi. Après plusieurs réflexions sur la meilleur façon de faire, le résultat donne ceci : 

La carte 'Arduino' montée sur une Pi.

Tout le challenge de cette étude a consisté à implémenter le juste nécessaire de composants et de fonctionnalités pour répondre au cahier des charges, tout en permettant d'éventuelles extensions. Contrairement à ce que j'ai pu découvrir comme sujets équivalents sur le net, je ne me suis pas servi d'un des ports série de la Pi pour programmer l'Arduino de la carte d'extension.

• D'une part parce que dans le projet Arbalet, les deux ports séries de la Pi sont utilisés. Le port série matériel est utilisé par le module BlueTooth et le port série 'logiciel', devenu le port série 'standard' de la Pi, est présenté sur son connecteur d'extension.
• D'autre part parce que le port 'software' de la Pi, utilisé pour la communication avec la carte Arduino, impose de ne pas toucher à la fréquence de fonctionnement du processeur de la Pi. Sans compter qu'il aurait fallu aussi jongler avec les paramétrages de ce port pour tantôt programmer la carte Arduino, tantôt servir de lien de communication entre les deux systèmes.

Ayant eu par le passé, la possibilité d'expérimenter la programmation d'une carte Arduino en se basant sur un circuit d'interface FTDI FT230x très bon marché et de petite taille, j'ai choisi cette option pour simplifier les développements logiciels. 

D'autre part, cette carte d'extension comporte un connecteur de type industriel qui permet d'alimenter non seulement une partie de la carte Arduino, mais aussi la Raspberry Pi, ce qui règle le problème parfois épineux d'un branchement d'alimentation 'solide'.

De plus, pratiquement tous les ports non utilisées du processeur ATmega sont 'servis' sur deux connecteurs d'extension (dont je n'ai pas équipé la carte puisque inutiles dans le projet Arbalet initial), ce qui permettra d'utiliser ces 'extensions' pour d'autres projets.

Enfin, la simplicité de cette carte Arduino provient essentiellement de la disponibilité des DEUX ports série sur le processeur ATmega328pb. L'un d'entre eux est dédié à la programmation Arduino, via l'adaptation USB, l'autre sert de pont de communication avec la Raspberry.

Après le 'flashage' du bootloader compatible Arduino, le téléversement du 'fameux' sketch Blink fonctionne comme prévu. A la seule différence que je n'ai pas connecté la LED utilisateur sur la même broche du processeur que sur les cartes Arduino Uno, mais sur la pin n°7. Ce qui ne change rien à l'affaire...

C'est la reprise!

Mis à part quelques sujet sur des réparations/modifications d'instruments électronique de musique, je n'ai rien publié à la suite du MakerFaire de Nantes qui s'est déroulé début juillet.

Parce-que finalement, je n'avais rien de spécial à publier. Pratiquement quatre mois après ce MakerFaire, et malgré l'enthousiasme affiché par les 'passants' sur mes présentations, force est de constater que la multitude de contacts échangés à cette occasion n'a rien donné de particulier. Reste malgé tout cet incroyable moment passé à la rencontre de personalités très variées et intéressantes.

Je continue donc, seul, mes développements et diverses expérimentations électroniques.

Lors de ce MakerFaire nantais, j'ai présenté deux thématiques principales :

- l'automatisme dédié à l'habitation, basé sur l'environnement Arduino. Le matériel exposé se composait d'un automate commercial de type Controllino, d'une carte Arduino de type UNO de ma composition, mais possédant DEUX vrais ports série, et d'un écran graphique tactile permettant de commander le tout :

Les évolutions de ce système consistent en une carte d'interface que je développe actuellement pour la carte automate Arduino. Cette interface comportera un circuit industriel capable de gérer la commande de signaux numériques en 24V, ainsi qu'un certain nombre d'entrées analogiques acceptant du 10V et du 5V. tout ceci devant permettre de sécuriser la carte Arduino vis à vis du monde extérieur et permettra de se passer de l'automate commercial Controllino.
Quelques passages en FabLab à titre de conseil en développement de solutions électroniques m'ont permis de constater à quel point il est facile de détruire les entrées/sorties du processeur quand les 'expérimentateurs/trices" ne possèdent qu'une vague notion des grandeurs physiques utilisées.

D'autre part, le type d'écran tactile utilisé à subi une évolution. Ces écrans sont maintenant plus réactifs en affichage du fait d'un système à processeur intégré plus rapide. Ils possèdent aussi une plus grande capacité mémoire, ce qui permet une montée en 'raffinements' d'affichage. Ils possèdent aussi directement l'heure temps réel. Ce qui permet de libérer le port d'extension dédié de ma carte Arduino.

Le schéma théorique de l'interface industrielle est terminé. Il reste encore à créer le circuit imprimé, ce qui sera fait dans les semaines à venir.

- L'électronique dédié aux instruments numériques était la deuxième thématique présentée au MakerFaire. Avec deux présentations matérielles. D'une part un système permettant de prendre le contrôle d'une machine pour y effectuer des diagnostiques et réparations éventuelles. En l’occurrence ce système prend la forme d'un 'émulateur' de processeur Z80, utilisé en lieu et place du processeur d'origine d'une Drumulator :

Cet émulateur de Z80 n'émule pas réellement un Z80, évidemment, mais est en mesure de prendre le contrôle des différents bus du système, et ce, dans le but de commander les différents organes de la machines afin d'en évaluer le comportement. Le gros avantage de cette solution est qu'elle ne nécessite aucun composant externe pour fonctionner. Par le fait, il devient alors possible d'effectuer un DUMP de la ROM d'origine de la machine, et même de tester le bon fonctionnement des mémoires RAM.
Mon étude initiale comportait quelques 'bugs'. Afin de la finaliser, j'ai donc corrigé les erreurs et en ai aussi profité pour changer le connecteur mini-usb en optant pour un modèle vertical. De cette façon, l'émulateur n'occupe que la place d'origine du Z80 et ne déborde plus. Je pourrai remettre en place le potentiomètre que j'avais du retirer.

La nouvelle version est à gauche!

 

Côté pile.

Côté face.

La nouvelle version est bien plus 'propre' que l'ancienne et va me permettre de continuer à développer sereinement les algorithmes de test de la Drumulator.

Autre sujet développé dans cette thématique instruments numérique de musique, une 'nouvelle' liaison M.I.D.I. :

Ces deux modules relient mon clavier maitre K250 et un expandeur sur lequel j'utilise différents sons de piano depuis quatre mois maintenant. Je n'ai constaté aucune erreur de communication malgré une certaine 'rapidité' des notes jouées (je prends par ailleurs des cours de clavier, histoire de me servir aussi de ce que je fabrique!). La topologie de ma liaison M.I.D.I. n'étant plus la même que celle d'origine, je développe en ce moment un switch qui me permettra de non plus faire un simple point à point, mais de créer un vrai réseau de machines. Le PCB de ce switch est créé et ne requiert 'plus' que sa fabrication puis la programmation du système.

Le principe de mise en place de ce nouveau réseau devrait être assez 'ludique', agréable, et pratique, tout en conservant l'existant. Non? si si....

Cerise sur le réseau, avec tous ces développements et matériels disponibles, j'en profite pour développer un petit système de commande pour le Juno 2 que j'ai dépanné récemment. Ce système se comportera comme un PG300 mais à partir d'un des écrans tactiles évoqués plus haut. Il permettra aussi de faire l'interface entre le nouveau réseau M.I.D.I. et les 'anciennes' prises M.I.D.I. de la machine. L'interface graphique ressemblera à ceci :

Et d'ailleurs voici ce à quoi ressemble le circuit imprimé tout fraîchement arrivé de fabrication :

Pour ce montage j'ai choisi de passer sur un processeur de type ARM de chez ST. D'une part ces processeurs sont rapides, mais surtout l'ensemble des logiciels disponibles pour ces circuits est vraiment 'facile' à utiliser. CubeMX permet en effet de configurer de façon graphique les processeurs ST puis de générer le projet contenant toutes les initialisations nécessaires. Projet qu'il suffit d'ouvrir avec System Workbench for STM32 d'AC6 par exemple pour commencer à développer le code dans un environnement Eclipse. Cela fonctionne très bien, une très grande partie du travail fastidieux d' initialisation du processeur devenant automatique.

Carte montée : 28/10/2016

Pas du grand art, mais pour du prototype, ça ira bien!

Carte partiellement testée : 05/11/2016

Pour tester mon montage, j'ai réutilisé une petite carte d'affichage réalisée en 1992 il me semble. Cet affichage faisait parti d'un système de filtrage des canaux M.I.D.I. à destination d'un JX3P.
Insérée directement sur un port d'extension de la carte ARM, elle me servira à afficher des indications sommaires lors du développement logiciel de cette carte.

Et pendant que j'y suis : publicité gratuite pour ST. Je m'empresse de suite de préciser que mon intention n'est pas de dénigrer d'autres fondeurs proposant des processeurs compatibles ARM certainement très intéressants mais je n'ai jamais poussé les essais, la plupart du temps non pas à cause des circuits heux même, mais du fait du manque de logiciels de développement 'faciles d'installation/d'utilisation'. Ce qui m'a fait pencher pour les micro-contrôleurs ST est en tout premier lieux l'application CubeMX ou plus exactement STM32cubeMX. Ce logiciel permet tout simplement de configurer tous les aspects matériels du micro-contrôleur utilisé. Pour qui souhaite développer rapidement une petite application, cet outil est indispensable. Ensuite, vient évidemment la chaîne de développement Système Workbench for STM32 d'AC6. Il s'agit d'un IDE basé sur l'incontournable Eclipse. A ceci près, que l'installation complète de la chaîne de développement se fait de façon extrêmement simple. Ce qui n'était pas encore le cas mi-2015! Je rajouterai à cela que les processeur ST sont complets, rapides et d'un prix très faible. Inutile de plus d'acquérir un programmateur au prix exhorbitant. Pour ma part, j'utilise le STlink2 présent sur une carte Nucleo, qui me permet aussi d'effectuer du deboggage en temps réel : carrément le luxe!

Système quasi fonctionnel : 14/12/2016

Il m'aura fallu un peu plus d'un mois pour arriver à mes fins mais ça y est, l'afficheur graphique me permet de modifier en temps réel les paramètres du Juno 2. Pour l'instant je n'ai pas encore testé la connection au 'vrai' standard M.I.D.I. puisque j'en ai équipé ma carte processeur, mais 'me suis contenté' de faire transiter les informations par mon réseau compatible M.I.D.I. avec la mise en place d'un convertisseur vers l'ancien système M.I.D.I., directement connecté au synthétiseur. Pour imager la chose, je suis maintenant en mesure de modifier les paramètres du son du Juno en live avec l'écran tactile, tout en étant distant de presque 10m, longeur du câble qui relie l'écran au synthé. Et cela fonctionne superbement bien :-)
La fonctionnalité du système étant validée, il 'ne me reste plus' qu'à programmer l'ensemble de l'application et à trouver un boitier adéquate pour loger le tout! 

Je n'ai pas précisé, mais l'émulateur de Z80 est basé sur un processeur Atmel ATmega328pb, ainsi que les modules M.I.D.I. personnels, et évidemment la carte automate compatible Arduino. Pour le switch M.I.D.I. je vais utiliser un microcontrôleur de chez Microchip de la famille PIC32MX.

S'il est possible de débuter la programmation en 'jouant' de l'IDE Arduino sur les cartes du même nom, l'étape suivante qui consiste à programmer tel ou tel type de microprocesseur avec l'IDE du 'constructeur' et un programmateur dédié n'est finalement pas beaucoup difficile, à partir du moment ou les bons outils et le bon environnement informatique est utilisé.
  
Voilà, c'est tout pour l'instant. Encore que... D'autres sujets sont plus ou moins en cours d'étude, qui aboutiront peut-être... ou pas!

ARDUINO, ATmega328pb et FTDI FT230X.

Cela fait quelque temps que je n'ai rien publié sur des réalisations personnelles. Le dernier 'article' sur le sujet doit dater du 20 janvier 2016 et traitait de la mise en œuvre du Micromite MkII.

Il est donc temps d'évoquer ici la réalisation d'une carte compatible Arduino.

A l'origine je n'avais pas l'intention de créer à proprement dit un système compatible Arduino. L'objectif initial était de réaliser une interface capable d'interconnecter un automate et un écran graphique tactile. Bien que la connexion entre l'automate en question et l'écran soit possible en TTL, dès qu'il s'agit d'éloigner ces deux éléments, une autre interface électrique s'impose : le standard RS485.

L'écran et l'automate connectés en signaux TTL.

L'écran n'est pas en mesure de piloter nativement une interface RS485, il ne fournit pas le signal permettant de commuter les circuits d'interface entre émission et réception. La solution la plus simple consiste donc à utiliser un micro-contrôleur possédant DEUX ports séries permettant de recevoir les signaux RS485 depuis l'automate tout en les communiquant à l'écran au standard TTL.

Reste donc à choisir un micro-contrôleur. Plusieurs solutions sont possibles chez différents fabricants de circuits. Pour cette réalisation, un simple cœur de processeur 8 bits suffit. Le critère suivant a été tout simplement le prix. Et à ce 'petit jeux', le processeur ATmega328pb d'Atmel est très bien placé.

Le processeur en question.

Dans un premier temps j'ai opté pour la création d'une carte comprenant une interface RS485, l'interface pour l'écran graphique, une alimentation à découpage capable d'accepter une large gamme de blocs d'alimentations et une interface pour une horloge temps réel. J'y ai aussi rajouté un connecteur généraliste sur lequel il sera possible de connecter différents capteurs ou actionneurs. Pour programmer le tout, j'ai aussi implémenté une interface USB, ce qui rendra possible l'accès au processeur et à l'écran par un ordinateur externe grâce à une petite logique de sélection. Le résultat est une carte relativement petite :

Une fois le circuit imprimé réalisé et une carte montée, il ne restait plus qu'à passer à la programmation du micro-contrôleur. Ce ne fût pas la partie la plus simple.

En effet, il faut impérativement prendre en compte le fait que les drivers Jungo dont se sert Atmel pour établir la communication entre son logiciel de développement et les différentes cartes de programmation ne seront réellement installables QUE sur un Windows dont le système de signature des drivers aura été mis à jour.

Tant que cela ne sera pas fait, les drivers ne s'installeront pas correctement, ou en tout cas ne démarreront pas, rendant impossible toute communication entre le logiciel Atmel Studio 7 (celui en cours en mai 2016) et quelque carte de programmation que ce soit. Inutile de préciser que la mise à jour de Windows avec ce système de prise en compte des signatures de drivers pourra (comprendre que chez Microsoft s'il le peut, il le fera!) générer quelques soucis avec d'anciens drivers. Dans mon cas la clef W.I.F.I. USB  a définitivement cessé de fonctionner.

Les tentatives de mise à jour de ce driver de clef W.I.F.I. ont irrémédiablement rendu le système inopérant. A titre indicatif, le Windows 7 64 bits sur lequel je faisais l'intervention est parti en auto-destruction classique. La résolution d'un problème demandant la résolution d'un autre problème, lui-même dépendant du premier problème. Bref, un 'partage en vrille' comme sait si bien le faire Microsoft avec son système (je ne sais pas si cela est toujours d'actualité sous 8 ou 10). A remarquer aussi que si le système sur lequel l'installation du logiciel Atmel est tentée est trop ancien (version de Windows 7 non mise à jour depuis longtemps), une fenêtre indiquant l'impossibilité pour la procédure d'effectuer l'installation sur un système non pris en charge apparaîtra de façon impromptue!!!

Le mieux consiste donc à installer un système tout neuf et à jour sur un PC assez rapide parce que le logiciel de développement est énorme, en grande partir du fait de l'utilisation des ressources de Microsoft Studio. J'ai perdu pratiquement une semaine en essayant 'de bien faire' pour réussir à obtenir un système apte à travailler avec le logiciel Atmel. Non, le plus simple, vraiment : Un PC core I5 rapide, et disque SSD. Le tout sous un Windows tout neuf et à jour. Question faible coût des outils de développement, évidemment, on fera l'impasse sur 'ces effets de bord'!

Le tout, pour travailler justement avec la carte de programmation 'bas coût' d'Atmel, l'AVR Dragon :

Une fois l'installation correctement effectuée de tous les systèmes, la suite de développement Studio d'Atmel fonctionne très bien. Rien à signaler avec le programmateur Dragon, même si à une ou deux reprises, j'ai eu quelques pertes de connexion entre le logiciel et ce Dragon, mais rien de bien gênant.

Après quelques lignes de code en C natif, j'ai réussi sans problème à créer et faire exécuter le 'Hello world' de l'embarqué, à savoir le clignotement de quelques LEDs :

Et un processeur perdu à cause d'une mauvaise programmation de fusibles :-(

Relativement satisfait du travail accompli, c'est alors que je me suis dit que, ma carte possédant tout le nécessaire, il pourrait être intéressant de la rendre compatible Arduino. L'intérêt est assez évident. De la sorte, il ne serait plus nécessaire d'avoir recours à la suite de développement Atmel, ainsi qu'à un programmateur externe. De plus, cela permettrait de 'modifier' le code de cette carte à la demande, sur site par exemple, en utilisant les mêmes outils que ceux utilisés pour la programmation de l'automate, lui aussi compatible Arduino. Une belle cohésion d'ensemble en somme.

C'est alors qu'un autre travail de configuration assez important à démarré. Parce qu'au moment de l'écriture de ces lignes, il n'existe pas de version Arduino compatible avec ce nouveau processeur 328pb. Seuls pour l'instant (mai 2016) son gérées les versions 328 et 328p. Est-ce à dire que la 'chose' était impossible à réaliser? Non, évidemment. Internet et la communauté du libre aidant...

Sans rentrer dans les détails, les étapes se résument à :

• Installer dans le processeur un bootloader renvoyant la bonne signature du processeur au logiciel de programmation utilisé par le logiciel Arduino : Avrdude. Ecriture de ce bootloader grâce au programmateur AvrDragon et la suite Atmel Studio 7.
• Modifier certains fichiers de configuration du logiciel Avrdude pour la prise en compte de la signature du 328pb.
• A partir de la dernière version du logiciel Arduino (1.6.9 non officielle en mai 2016), remplacer les outils GCC par la version comprenant le 328pb directement récupérée du site d'Atmel.
• Modifier certains fichiers de configuration de la suite Arduino pour lui faire prendre en compte la nouvelle carte.
• Enfin, modifier certains fichiers de déclaration pour pallier les erreurs de compilations dues à des changements de noms de registres et autres incompatibilités ponctuelles de ce genre.  

Une fois ce travail réalisé, j'ai pu connecter l'écran graphique couleur comme prévu sur ma nouvelle carte, et lui faire exécuter pratiquement le même code que celui ayant préalablement été testé sur l'automate programmable. A ceci près que le code gérant l'heure temps réelle est différent puis que je n'utilise pas ici les bibliothèques fournies par le fabricant de l'automate, mais directement la bibliothèque wire de la librairie Arduino. A noter que les informations envoyées à l'afficheur passent par le nouveau deuxième port série du processeur :

La carte Atmel AVR Dragon en haut, qui a permis d'écrire le bootloader dans le processeur de la carte d'interface, en bas, avec l'écran couleur.

Et voilà une carte de conception personnelle répondant à des besoins particuliers, basée sur un système de développement gratuit et disponible a souhait sur le Web. Toute personne possédant un minimum de connaissances en programmation et ayant déjà 'touché' un tant soit à peu l'environnement Arduino, sera à même de se servir de cette carte pour l'adapter à des besoins spécifiques.

Il ne me reste plus qu'à tester la liaison RS485 avec l'automate programmable et l'ensemble des fonctions de cette carte sera validé :

Prêt pour les tests!

A comparer à ce que cela peut donner avec du matériel professionnel 'pas trop compliqué' à utiliser :

J'aurais quand même tendance à préfére ma solution...

Remarques de dernière minute pour ceux que cela intéresse :

Cette carte utilise un circuit FTDI FT230X en guise d'interface USB/série et non pas le classique FT232R.

Avec ce processeur, Atmel inaugure un nouveau design de son système d'oscillateur. Pour faire simple, il ne subsiste plus que la version basse consommation du circuit interne permettant de 'driver' un quartz externe. Atmel indique d'ailleurs qu'un quartz de 16MHz maximum doit être installé si cette option est choisie. Pour passer à 20MHz, il sera nécessaire d'utiliser un circuit oscillateur externe. Sur cette carte, le quartz de 16MHz utilisé permet un fonctionnement correct de l'oscillateur du 328pb. Attention quand même à l'élaboration du circuit imprimé à proximité des deux pattes concernées du processeur....

24 mai 2016 : j'ai effectué des tests de programmation de cette carte à l'aide de la version 1.6.9 de l'IDE Arduino, agrémenté du 'plugin' proposé par Elektor avec sa carte Arduino R4. Cela fonctionne à merveille!
Et voilà, une carte encore plus facile à utiliser!

06 juin 2016 : petit commentaire sur la 'perte' de processeurs ATMega328pb suite à une mauvaise programmation des fusibles.

Ayant travaillé depuis quelques semaines avec ce processeur, il m'est arrivé à plusieurs reprises au début, d'en rendre certains exemplaires irrécupérable par le programmateur Dragon du fait d'une mauvaise programmation des fusibles. En fait la plupart du temps, il s'agit d'une erreur de sélection du type d'oscillateur.

Il faut bien avouer que la façon de présenter les options en menu déroulant des différentes possibilités d'horloge dans l'interface de programmation du logiciel Atmel Studio ne facilite pas vraiment la discrimination.

Donc à un moment ou à un autre, le processeur sera configuré SANS la mise en fonction de son système d'amplificateur pour quartz externe. Le processeur n'aura donc plus aucune source d'horloge et ne répondra plus aux sollicitations du programmateur. La solution pour y remédier est simple et fonctionne bien. Il suffit de raccorder à la patte PB6 (pin 7 boitier TQFP32) du processeur la sortie d'un oscillateur de ce type :

J'en possède une version 16MHz que je conserve pour cet usage.

Dès lors, le processeur est à même de dialoguer de nouveau avec le programmateur Dragon, permettant ainsi le re-programmation des amplificateurs pour quartz externe.

J'ai soudé un fil de faible longueur de cet oscillateur directement sur le 'pad' cms du quartz du montage électronique correspondant à la patte PB6. La présence du quartz d'origine n'a pas perturbé outre mesure le fonctionnement du processeur.

En complément : 

Je développe en ce moment une petite interface M.I.D.I. un peu particulière ainsi qu'un système de diagnostic/débogage (un peu osé/trash/geek/oujenesaisquoidautre) pour anciennes machines équipées d'un processeur Z80 pour l'instant. Je compte exposer ces développements ainsi qu'une thématique Arduino au 'petit' Maker Faire de Nantes début juillet, si tout va bien... Si vous êtes intéressés par ce type de développement et n'êtes pas trop loin de Nantes, n'hésitez pas!

Enjoy!!!