ATMega328pb, double port série et liaison MIDI.

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...