A few days after having ordered the realization of my printed circuit board, it has just arrived:
A very easy to assemble midi merge box
Unlike usual, I chose not to use SMD components but only through hole components. This will make it easier to assemble the circuit. I could even offer the circuit to be assembled as a kit if that interests some...
I am still waiting for the components, especially the switches and connectors, to carry out the first tests.
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!
Un petit article 'vite fait pour le fun', histoire de garder le rythme ;-)
En effet, je suis plutôt 'à fond' en ce moment comme l'on dit. Avec plusieurs développements en cours et quelques interventions en FabMake...
Un de mes développements actuels concerne la liaison M.I.D.I. J'en ai assez de voir tout ces paquets de fils aux prises pas pratiques du tout me parasiter mon environnement. Cela n'est pas nouveau, mais même si j'ai depuis de nombreuses années eu envie de mettre en pratique les quelques idées perso. sur le sujet, l'occasion de le faire ne s'était pas vraiment présentée. Le moment semble venu...
L'idée première consiste donc à s'attaquer à la topologie physique de ce pseudo réseau. J'ai donc pris la décision de faire parler la rationalité. Plus question de se prendre la tête avec des prises IN et THRU, sans parler de la OUT! Et oui, j'ai choisi la RJ45 et son câble catégorie 5. MAIS pas question d'Ethernet ici. Non, on reste sur du réseau standard. Ce câble véhiculera les DEUX sens de la liaison. Il sera par contre OBLIGATOIRE de disposer à minima d'un hub sur lequel brancher tous les matériels MIDI. De toutes façon, il n'y a pas vraiment d'autre solution. Surtout si l'on garde à l'esprit la nécessité d'être le PLUS POSSIBLE COMPATIBLE avec la norme M.I.D.I. existante, sans rien devoir casser. Bref, faire en sorte que la solution apporte un plus réel...
En image :
C'est ça?
Oui, c'est bien ça. Petite explication : ce sont deux modules identiques mais un joue le rôle de hub mono-port à relier à un clavier maître par exemple, et l'autre joue le rôle d'adaptateur M.I.D.I. à relier à un module sonore, typiquement.
- Comment cela se passet-t-il? Réponse : comme avant.
- La différence? La liaison entre le clavier maître et le module sonore s'effectue à l'aide du câble jaune, un câble standard Ethernet.
Ah oui, les alimentations? Je vous attendais sur le sujet! Le module maître est alimenté par une alimentation de laboratoire sur la photo, et transmet l'énergie à l'autre module par le biais de ce même câble Ethernet : simple et efficace.
Pour réaliser ce système, j'ai utilisé les 'nouveaux' processeurs ATmega328pb en profitant de leur deux ports série. Et comme si cela ne suffisait pas, j'en ai profité pour augmenter le débit série sur le câble Ethernet pour passer de 31 250 bauds à 125 000 bauds, soir 4 fois plus rapide. Cette augmentation a été rendue possible grâce à l'utilisation de la RAM interne du processeur pour buffériser les données dans le sens rapide vers lent.
Les premiers tests sont concluants. Je vais utiliser le système durant quelques semaines et passerai à la construction d'un HUB simple et multi-ports capable d'irriguer un 'certain nombre' de machines. Ce système me plait bien. En plus, il est possible de trouver des câbles Ethernet de différentes couleurs, jaune, rouge, vert, bleu, gris : pratique pour 'thématiser' facilement les liaisons!
Update 26 juin 2016 :
Après quelques jours d'utilisation, forcément, de 'petits' soucis n'ont pas manqué d'apparaître!
Et notamment sur la rapidité de transmission de 'gros' paquets de données. J'utilise la version moderne de l'Atari ST, le M.I.S.T. avec un logiciel d'édition graphique pour le synthétiseur TG77 de Yamaha. Le problème s'est présenté lors du transfert de l'ensemble des sysex (bulk dump) d'une banque de son vers le TG. J'ai eu le droit à l'affichage d'erreur de checksum M.I.D.I. et de buffer de réception plein de la part du TG.
Après étude du problème, je me suis rendu compte qu'en fait l'ordinateur M.I.S.T. étant plus rapide que le ST d'origine, celui-ci envoi les patchs à une vitesse trop élevée pour le TG. Plus précisément, le temps entre la fin d'envoi d'un patch et le début de l'envoi du suivant est trop faible pour permettre au TG d'effectuer son travail interne et donc de se trouver prêt pour la réception du patch suivant. Impossible de modifier le M.I.S.T. pas plus que le TG77. Et comme l'indigence du protocole M.I.D.I. de permet pas un contrôle précis du transfert par un vrai hand-cheking par exemple, il ne me restait plus qu'à trouver une solution externe, donc d'implémenter une fonctionalité permettant de résoudre ce problème au sein même de mes modules M.I.D.I. rapides.
La solution est simple : un buffer circulaire de données. Ou plus précisément, un buffer 'glissant'. En effet, il n'est pas question de réceptionner l'ensemble d'une banque de données, de la buffériser dans un module M.I.D.I. puis de l'envoyer 'tranquillement' par la suite au TG77. Les 2Ko de mémoire de l'ATmega328pb est incapable de contenir l'ensemble des données d'un Bulk mémoire. Non, ce qui est fait, c'est la mise en place d'une petite temporisation de quelques ms après chaque patch pour laisser le temps au TG77 de le digérer, tout en continuant à recevoir les données M.I.D.I. et à les stocker dans le buffer temporaire. Le tout étant de trouver, si possible, l'adéquation entre le temps minimum nécessaire au TG77 pour faire son travail, et la quantité de retard d'évènements M.I.D.I. qui peut être géré sur l'ensemble de la transmission des données. A vrai dire, je ne sais pas quel est ce temps nécessaire au TG77. Après quelques tests, j'ai fini par 'tomber' sur une configuration fonctionnelle. La situation devait être donc fonctionnelle, sauf que...
Le TG77 envoi régulièrement des paquets de présence, des 'active sense' au code hexa 0xFE, au plus toutes les 300ms. Bien ce truc! Non seulement ça ne sert à rien dans l'implémentation M.I.D.I. de base puisqu'un seul OUT peut rentrer dans un ordinateur par exemple, et donc que si ça la communication ne fonctionne plus, il n'y a pas à chercher bien loin, mais en plus cela perturbe le réseau M.I.D.I. lorsque l'on tente de faire moins 'idiot' comme réseau de communication.
J'ai donc tout simplement filtré et interdit à ce code M.I.D.I. de remonter vers l'ordinateur, en l’occurrence le M.I.S.T. Et la, plus de problème du tout. Le transfert du TG77 vers/depuis le M.I.S.T. fonctionne très bien. Il est même 'intéressant' de constater que le synthétiseur continue à recevoir et à traiter des données M.I.D.I. alors que l'ordinateur à fini son travail d'envoi depuis quelques ms.
Donc, non seulement 'ma liaison informatique' fonctionne plus rapidement que la liaison M.I.D.I. de base, simplifie son câblage, mais permet aussi à d'anciens matériels de pouvoir continuer à fonctionner avec du matériel plus récent!
Evidemment, je n'ai pas regardé les solutions de type iPad. De toute façon ces solutions ne m'intéressent pas puisque qu'elles ne tentent même pas de résoudre ce problème plus global de topologie réseau, pas plus que de l'améliorer alors...
