Petit dépannage et modification d'un Roland Alpha Juno 2.

Les Alpha Juno 1 & 2 sont de petits synthétiseurs que personnellement je trouve assez amusants. Ce sont des claviers très bas de gamme mais en mesure de procurer des sons variés notamment des graves assez 'gras' très typés analogique avec pourtant un seul DCO par voix, même si mis à part la section VCF, le reste de l'architecture est digitale.

Deux versions : 49 touches pour le modèle 1, 61 pour le modèle 2. Plus d'informations ici.

Ayant visité il y a quelques années le musée de la Poste à Paris, j'avais découvert à cette occasion à la 'rubrique' dessins animés et bruitages, un Alpha Juno 1 exposé en vitrine. Je m'étais dit, à l'occasion....

Et l'occasion s'est présentée. Une petite annonce d'un Alpha Juno 2 à prix très bas pour cause de clavier présentant quelques dysfonctionnement de touches.

Ce petit synthétiseur m'a été, la aussi, expédié par la poste. A la réception j'ai pu découvrir les dégâts infligés à l'appareil par cette 'médiocre institution'. Les bords inférieurs gauche et droit étaient enfoncés, la tôle de l'appareil carrément emboutie malgré un empaquetage très correcte. A l'évidence, le paquet à subi une chute, sinon des chutes, d'une hauteur certaine. J'ai cependant pu rétablir à peu près la situation, il ne subsiste qu'une légère trace de plastique cassé sur le bord droit.

La réparation du clavier n'a présenté aucune difficulté. Il s'agit d'un problème bien connu qui nécessite le démontage complet de toutes les touches et le nettoyage du système de contact, avec remise en bonne place de la bande de caoutchouc.

http://studiorepair.com

Et c'est tout?

Effectivement, quel intérêt de présenter un tel sujet disponible à l'envie sur Internet! Et bien parce que l'histoire continue...

Et l'histoire, c'est celle de la pile. Parce qu'elle ne semble pas avoir été remplacée. Et après 30 années de service, il n'est pas incongru de penser qu'il se pourrait bien qu'une fuite d'électrolyte ne vienne perturber, à terme, le bon fonctionnement de l'appareil. Je la retire donc :

Le côté visible ne semble pas....

Alors que l'autre face présente de belles traces blanches de début de fuite.

Avec ce genre d'appareil électronique, c'est souvent la même histoire. Une pile conserve la mémoire de donnée, présente sous la forme d'une ou de plusieurs RAM statiques de 2, 8 ou 32Koctets. Ici, c'est un seul boîtier RAM de 2Koctets :

Une TC5517APL de 2Koctets de Toshiba.

Évidemment, il 'serait' simple de remplacer cette pile. Je pense que lorsqu'il est possible de faire mieux, autant le faire. Je décide donc de remplacer cette RAM de 2Koctets par une version auto-sauvegardée et totalement compatible avec le type de mémoire d'origine. Pour cela j'ai développé il y a déjà quelques mois, un ensemble de circuits de substitution :

Version 2 et 32Ko.

Pour commencer, il convient donc de retirer le circuit RAM d'origine et de le remplacer par un support de circuit :

Ça, c'est fait!

Puis, d'y placer le circuit de RAM auto-sauvegardée :

Il n'y a plus qu'à tester...

Tester de suite? Pas encore. La RAM statique de substitution réclame réellement une alimentation de 5V pour fonctionner correctement. Plus exactement, et du fait du système de sauvegarde employé sur cette nouvelle RAM, pour effectuer sa sauvegarde. La présence de deux diodes sur le circuit imprimé suggère un système classique d'alimentation par deux sources, la batterie OU l'alimentation principale de 5V, ce que confirme le schéma :

J'ai donc relié la patte d'alimentation de la RAM directement au 5V, en court-circuitant la diode D14. Et voilà!

Après avoir rechargé la RAM avec un PC en sysex, j'ai retrouvé les sonorités précédemment sauvegardées de cet Alpha Juno 2.

Note possiblement importante :  Chaque démarrage de l'Alpha Juno avec la nouvelle RAM fraîchement installée, et donc vierge, provoque le message suivant sur son afficheur : "Check Battery". Un RESET du système doit être effectué. L'opération consiste en (copié des commentaires du site de Jim Atwood) :

1) The Alpha Juno 2 must be powered off.
2) The Memory Protect switch must be off.
3) While holding down the PORTAMENTO and DATA TRANSFER buttons, turn on the power.
4) Release the buttons.
5) The display will show something like “Initlz Funct RAM”
6) Turn the power off.
7) Turn the power on.

Une traduction en français ne s'impose pas j'imagine ;-)

Au remontage physique de l'Alpha Juno : pas de chance, la nouvelle RAM installée sur le support de circuit intégré dépasse la hauteur de la ROM de 2 à 3mm. Ce qui provoque non seulement le contact entre les broches du circuit imprimé de la RAM et le châssis métallique du clavier, mais aussi une flexion du circuit imprimé.

Une solution simple pour remédier à ce problème eût été de coller un bout de carton sur le circuit additionnel. J'ai préféré dessouder le support de circuit intégré de la carte du Juno et y souder directement le circuit de la nouvelle RAM. Dès lors le remontage s'est effectué normalement.

Que reste-t-il à faire sur ce synthé? Le changement de son afficheur. Le rétro-éclairage d'origine ne fonctionne plus. J'ai donc commandé le même type d'afficheur, mais à rétro-éclairage LED. 'Normalement' ce nouvel afficheur 'devrait' être compatible avec l'ancien. Sinon, il risque d'y avoir le même problème que celui rencontré par Jeroen Oldenhauf lors du remplacement de l’afficheur d'origine pas un modèle OLED en principe compatible!

Et pour finir ce billet :  les machines développées jusque pendant les années 80 étaient habituellement fournies AVEC le schéma du système l'électronique et mécanique. Heureusement car aujourd'hui il serait souvent bien difficile de les maintenir en état de marche. Et pourtant, le concept même d'Open Hardware n'existait pas. Tout pouvait donc être copié. Des idées étaient certainement reprises mais est-ce un mal? non sans doute parce que cela oblige à toujours plus d'inventivité. Les constructeurs qui ont fermé leur porte ont été poussés à la sortie certainement pour d'autres raisons qu'une copie illicite ayant cassé leur marché.

Plus significatif encore, le fait d'avoir publié les schémas et parfois les caractéristiques des systèmes logiciels à permis et permet toujours à des passionnés de créer des modifications matérielles et/ou logicielles dont le but est d'améliorer les caractéristiques d'origine des appareils. Et oui, tout cela à bien changé. Que faire de ce super téléphone acheté fort cher, dont la batterie n'est même pas remplaçable sans détérioration de l'appareil? Il ne s'agit même plus d'obsolescence programmée mais de fabrication et donc d'achat de déchets neuf! Quelle valeur peut avoir un déchet neuf, hein, monsieur Apple ou monsieur Samsung?...

A suivre pour la mise en place du nouvel afficheur...

Quelques jours plus tard...

J'ai reçu un 'certain nombre' d'afficheurs en version 1 ligne de 16 caractères. Afin de tester un de ces exemplaires sur l'Alpha Juno 2, il bien il convient de commencer par retirer 'l'ancien' système d'affichage.

Il faut donc retirer l'afficheur, évidemment, mais aussi la partie génération de la haute tension du rétro-éclairage par film qui ne sera plus nécessaire puisque le nouvel afficheur possède un rétro-éclairage à LED, ainsi que la résistance qui fixe la tension de polarisation du LCD. Une fois le tout retiré, cela donne tout d'abord ceci :

Sur cette image est aussi présent le transistor oscillateur nécessaire à la mise en fonction du transformateur haute tension. Je lui ai pris deux pattes pour effectuer un pont sur la carte d'alimentation. En partie basse, le nouvel afficheur.

J'ai dessoudé aussi de l'ancien afficheur le connecteur pour câble plat, et l'ai ressoudé sur le nouvel afficheur. Ce qui m'a permis de monter le nouvel écran directement sur l'Apha Juno puisque les quotes sont identiques. Sauf l'épaisseur. Le rétro-éclairage LED demande plus de place que celui par film. J'ai donc du trouver quatre vis un peu plus longues pour fixer l'écran :

Il est juste nécessaire de ne pas visser trop fort les vis. Le modèle choisi, auto-taraudeuse, se bloque sans risque de dévissage : parfait. J'ai aussi réutilisé le câble du rétro-éclairage pour le connecter au nouvel afficheur. Sur l'alimentation, les modifications nécessaires sont peu nombreuses et faciles à réaliser :

Le transformateur haute tension a disparu, ainsi que son transistor de commande, situé juste en dessous. Accessoirement, le Juno ne produira plus non-plus ce bruit strident d'alimentation à découpage. Ça n'est pas un mal! Le connecteur CN2 ne transporte plus la haute tension, mais le 5V. Pour des raisons de commodité, le fil noir véhicule le +5V alors que le blanc est maintenant la masse. En fait, la broche du fil blanc est déjà connectée à la masse sur l'alimentation. Je me suis juste servi des deux pattes du transistor pour relier le +5V passant à proximité à la deuxième broche du connecteur, celle ou s'enfiche le fil noir.

Vient le moment tant attendu : le test...

Quasiment comme l'original! Et du plus bel effet sur ce synthétiseur. En fait je triche un peu. Le 'vrai' premier test s'est soldé par un afficheur n'affichant rien. Avant de soupçonner une erreur de ma part (j'avais quand même bien tout vérifié avant), ou un problème de protocole, j'ai décidé de m'occuper de la tension de polarisation. J'avais dans l'idée qu'elle ne devait pas être correcte pour ce nouvel afficheur. Voici ce que dit le schéma de l'appareil :

C'est une résistance de 5,6KOhms qui règle la tension de polarisation du système d'origine. Système un peu 'baroque' puisque c'est en fonction de l'intensité réclamée par le système de polarisation de l'ancien afficheur, que la résistance a été calculée. Bref, pour faire simple, j'ai ôté cette résistance, référencée R66 sur le circuit imprimé, et l'ai remplacée par un trimer 10 tours de 10KOhms. Une des pattes de ce trimmer est directement relié au pad GND ou était auparavant la résistance, le 'curseur' du trimmer relié lui, à l'autre côté de la résistance d'origine, directement à la patte 55 du connecteur LCD de la carte mère. Quant au +5V, je l'ai pris sur la patte d'alimentation d'un circuit intégré logique, et l'ai relié à la troisième patte du trimmer, comme ceci :

Le système n'est pas inesthétique et la vis du trimmer m'a permis de régler avec précision le contraste du nouvel afficheur. En fonctionnement normal, il n'y a aucun problème d'affichage. cet afficheur semble donc parfaitement compatible avec celui d'origine :

Voilà, tout simplement! ATTENTION : la source lumineuse de la LED sur le côté droit de l'afficheur ne se distingue absolument pas en utilisation normale. L'effet d'intensité sur l'image est du au capteur de l'appareil photo.

En résumé, sur cet Alpha Juno 2 les opérations effectuées ont été les suivantes :

- Effacement (réussi) des dégâts infligés à la caisse par la poste (~30mn).
- Nettoyage du clavier, ce qui implique son démontage/remontage total (~90mn).
- Remplacement (démontage/remontage) de la RAM statique d'origine et suppression de la pile (~90mn).
- Remplacement de l'afficheur (~90mn en comptant aussi le temps passé sur Internet pour trouver un modèle adéquate).
- Démontage/remontage de la machine (~25mn).

Cela représente plus de cinq heures de travail sur la machine, et 'thanks to' le système redistributif dont est pourvu le pays et les ponctions obligatoires auquel le travail est sujet pour proroger sa survie, cela revient à un coût 'réel' de 300 à 400€ pour une rétribution net d'à peu près 15€ de l'heure. La cote d'un tel Alpha Juno est d'environ 250€ en état de fonctionnement. Seule la réparation des touches défectueuses du clavier et le simple remplacement de la pile semblent donc être des opérations pertinentes. Les améliorations apportées, bien que très intéressantes ne sont clairement pas rentables d'un point de vue économique. Dommage, la machine est maintenant plus 'robuste' qu'avant, et ce doublement de temps de travail pourrait générer des emplois. Question de choix de société!

30 Août 2016 : Après quelques jours d'utilisation, je trouve ce petit synthétiseur vraiment sympa à utiliser, et capable de produire des son très intéressants. Mais, comme souvent avec ce que je considère être la 'mauvaise' utilisation du numérique, programmer cet appareil n'est vraiment pas pratique. Trouver un PG300 à prix 'raisonnable' n'étant pas simple non plus, j'ai décidé de tenter la création d'un programmateur externe dédié à l'aide d'un afficheur graphique tactile. L'interface graphique devrait ressembler à ça :

J'ai déjà pu transférer cette interface dans l'afficheur et tester le fonctionnement des différents curseurs avec succès. Il me faut maintenant développer une petite carte processeur d'adaptation pour convertir les données de cette interface en Sysex sur liaison M.I.D.I. Peut-être l'occasion d'utiliser un processeur ARM équipé d'un nombre suffisant de ports série.

Touche finale : je possède quelques afficheurs neufs pour ce type de synthés. Si un exemplaire vous intéresse :

Un Alesis QS6 revient à la vie, mais avec de grosses séquelles : La Poste et le 100% médiocrité!

Quelques exercices d'assouplissement après pratiquement deux mois de travail intensif pour préparer les sujets que j'ai présenté au MakerFaire de Nantes ce week-end du 9-10 juillet. Je reviendrai sur cet évènement dans un prochain billet...

Quoi de mieux pour se détendre que d'entreprendre le sauvetage d'une machine sans intérêt, mais... à la signature sonore intéressante. Je viens d'acquérir ce QS6 au prix astronomique de 80€, frais de port compris, avec un gros problème de génération sonore.

le QS6 en image :

Image récupérée sur le Web.

Le symptôme est assez simple. L'appui d'une touche du clavier génère une espèce de séquence de divers instruments à diverses fréquences. J'ai simplement pressé une note aigüe et plus grave pendant environ 30s chaqu'une :

Intéressant n'est-ce pas?

Serait-ce le processeur de la machine qui perd les pédales?
Sans doute pas, le fonctionnement général du panneau de contrôle ne présente aucun problème.
Il convient alors d'étudier de près la carte électronique du synthé :

Rien de compliqué sur cette carte. Les différentes sections sont très faciles à identifier. A noter que la section 'génération sonore' comporte la batterie de ROM d'échantillons sur l'autre face, juste sous le connecteur de carte d'extension.

Récapitulatif :

• La section effet fonctionne. Le rajout d'effet rajoute des effets, et c'est tout!
• La partie processeur fonctionne. Je ne la met pas en cause.
• La section de gestion des 'organes de commande' fonctionne aussi.
• Et de toute façon si c'est le gros circuit avec sa pastille rouge qui est en cause, je ne pourrai rien faire de plus. Mais je ne pense pas. Les circuits de chez AMI sont 'forcément' fiables.

Ne reste donc plus que la génération sonore à tester. Les soudures de la banque de ROM ont déjà été refaites. Je ne mets de toute façon pas ces circuits en cause, le rendu sonore serait différent :

Belle couche de décapant!

Que reste-il à vérifier?

Et oui, un 'vulgaire' décodeur logique de type 138 en version AC, un 74AC138 de chez Fairchid :

Un rapide coup d'œil aux différents signaux confirme mes doutes :

Entrée E3

Au repos, la seule patte active de ce 138 est la patte n°6 nommée E3 :

Pour faire simple : toutes les sortie Y0 à Y7 sont à '1' quand AU MOINS une des entrées de sélection de ce circuit est INACTIVE. E1 et E2 sont câblés à '0', ces entrées sont actives. C'est alors E3, seul, qui sert de signal de validation des sorties. E3 est très majoritairement à '0' donc inactive, avec de très petits pics de sélection à une fréquence de 48KHz (voir image du signal au dessus).

En conséquence de quoi, je devrais avoir toutes les sorties à '1' sauf une d'entre elles qui devrait présenter le même genre de pic, mais vers le '0'. Les entrées à décoder A0 à A2 sont stables et à '0'. Il ne devrait donc y avoir que la sortie Y0 à changer d'état à une fréquence de 48KHz.

En réalité, toutes les sorties restent à '1' SAUF la sortie Y1 'scotchée' irrémédiablement à '0'. Or, les sorties de ce décodeur servent à sélectionner les ROM d'échantillon. Le doute n'est plus permis, je retire ce composant :

En tout les cas, cela confirme bien le fait que ce circuit 74AC138 sélectionne les ROM d'échantillons.

Ne reste plus qu'à le remplacer. J'ai retrouvé sans problème le même type de circuit chez Farnell au prix de 0,342€HT à l'unité (code commande : 2453170). J'en ai profité pour acquérir aussi d'autres composants, histoire de rentabiliser les frais de commande chez Farnell.

Une fois ce circuit remplacé, cela donne cici :

Forcément : c'est beaucoup mieux!

Que reste-il à faire sur cette machine?
En fait plus grand chose au niveau électronique. Nettoyer les traces précédentes d'intervention et remettre en place une pile de sauvegarde de 3V.

Le panneau de commande du synthé est en bon état, il ne requiert qu'un léger nettoyage.

LA POSTE :

Par contre j'en profite pour adresser un niveau 100% médiocrité à la poste. J'ai reçu très récemment un Alpha Juno2 en panne, lui aussi à prix très bas. Les angles de la caisse étaient bien abîmés. J'ai pu redresser le tout avec un résultat visuel très satisfaisant. Évidemment, sur ce genre de synthé, 'bas de gamme', la tôle de la caisse ne ressemble pas a celle d'une machine de chez Séquential, mais quand même... Pour ce QS6, j'ai eu droit à une partie du clavier explosée :

Joli travail La Poste!!!

J'ai bien noté aussi le petit commentaire du livreur : l'expéditeur à effectué un très bon emballage!
Ce qui pour moi raisonnait de suite comme grosse source de problèmes à venir, je n'ai pas été déçus!!!

LA POSTE : NE PRENEZ PAS EN CHARGE DES ENVOIS QUE VOUS N'ETES PAS CAPABLES DE GÉRER CORRECTEMENT!!!

Arguons qu'il s'agit certainement d'un problème de manque de personnel ou de chaîne de tri vétuste!!!
En sachant, évidemment, que les centres de tris actuels sont sur-équipés en matériels modernes et en personnels disons, hyper motivés et impliqués :

Je vais tenter une opération de sauvetage du clavier de ce QS6. Je verrai bien si ça aboutit. Toujours est-il que le générateur sonore fonctionne parfaitement, c'était quand même ça le 'jeu', à la base.

Le clavier est forcément difficilement utilisable, mais heureusement il reste la solution M.I.D.I.
Et maintenant que j'ai réalisé des convertisseurs me permettant la mise en place d'une liaison M.I.D.I. beaucoup plus pratique, je peux 'planquer' ce synthé un peu à l'écart...

Une semaine avant le MakerFaire de Nantes...

Forcément, la densité de travail nécessaire aux présentations que j'ai prévu pour cette manifestation augmente de façon exponentielle. Mais quand c'est pour avancer dans le bon sens... Dernière évolution en date : mon système de diag in-situe.

De quoi s'agit-il?
D'un système capable de diagnostiquer le bon (ou mauvais) fonctionnement de cartes électroniques jugées défectueuses. La cible visée est bien évidemment les anciennes machines à base des processeurs de l'époque à savoir le Z80, le 6809 et le 6502.

La machine de test idéal pour le développement de ce système a été une carte mère plus ou moins fonctionnelle d'une boîte à rythme de chez EMU du début des années 80, la Drumulator :

Image publicitaire.

Vénérable machine s'il en est qui, suite à quelques tentatives de modifications/réparations hasardeuses, se comporte maintenant de façon... erratique!
L'expérience de dépannage de ce type de machine me laisse entrevoir de très longues heures de test de signaux à l'aide de l'oscilloscope et certainement de l'analyseur logique. Or j'avais depuis longtemps envie de développer un outil d'aide au dépannage qui soit un peu plus... pratique. L'occasion me semblait trop belle pour ne pas tenter l'aventure!

L'idée générale est simple : se substituer au microprocesseur d'origine afin de prendre la main sur les composants principaux de la carte électronique à tester, Les avantages sont nombreux dont le principal étant dans un premier temps de pouvoir se passer autant que faire se peut d'outils de tests onéreux,

J'ai donc développé un ersatz de Z80 à l'aide d'un processeur Atmel, un ATmega328pb, le même composant que j'utilise dans ma thématique Arduino. Une fois le projet réalisé et mis en place du Z80 d'origine de la Drumulator, ça donne ceci :

Le prototype du projet, visible sur la droite de la carte.

Pour faire bonne mesure, j'ai rajouté un port USB au système de diagnostic, permettant d'interagir avec le logiciel de test, tant pour avoir les résultats directement sur l'écran d'un PC, que pour lancer les différents types de tests, toujours depuis le PC, ou un terminal série quelconque d'ailleurs muni d'un port USB.

L'envers du décor :

Aucune modification n'est nécessaire sur la carte en test. Même si sur cette Drumulator j'ai du enlever le potentiomètre rectiligne qui gênait la mise en place de la carte de diagnostic : bien peu de chose.

Une fois le système de diagnostic opérationnel et en fonctionnement, il devient possible de suivre le déroulé des opérations effectuées, directement sur l'écran du PC :

Tout simplement...

Et une petite vidéo réalisée rapidement sur le sujet :

Je reparlerai certainement de ce projet qui demande encore quelques temps de programmation pour être en mesure de tester les parties les plus importantes de cette Drumulator.

A suivre...

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

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

Maker Faire, EMU Drumulator, le nouvel Atmel ATmega328pb sous Arduino ... OUTATIME!

Hou là, pratiquement un mois sans publication!
Le temps passe vraiment vite....

La foire de Paris bat son plein en ce moment. Le Maker Faire y a élu domicile depuis l'année dernière, ce qui impose l'achat du billet d'entrée à la foire pour pouvoir y assister. En même temps, il faut bien louer les infra-structures et payer les 3000€ (ou dollars je ne sais plus bien) réclamés par la boîte américaine qui coordonne les Maker Faire de la planète!

Personnellement je n'y ai pas retrouvé l'ambiance de l'édition 2014 au 104. Le 'milieu' se 'professionnalise' comme cela était prévisible et devient petit à petit un salon 'avant vente' d'entreprises plus ou moins établies. Même si j'ai réussi à dénicher quelques 'amateurs', mais rien de fantastique. L'esprit n'y est plus.

Pour cela, je vous conseille de vous tourner vers les OBC, les Open Bidouilles Camp, qui eux, conservent plus l'esprit débrouillardise et entraide et ou ni les grandes entreprises, ni la puissance publique n'a pour l'instant imposé sa doctrine : pour votre bien et votre sécurité.

Pour imager la chose :

Intel, à la mode Microsoft : ambiance jeune et dynamique, avec beaucoup de bruit.

L'important est de se montrer et de marquer les esprits. Intel en pleine recherche de débouchés aujourd'hui, s'étant fait voler le marché des 'smart'-bidules ou l'architecture ARM et les fondeurs chinois ont raflé la mise (voilà ce que c'est quand on s'endort sur ses lauriers et que l'on se contente de faire des acquisitions/développements à seuls but destructeur de concurence à la mode Microsoft!), après avoir officiellement laissé tomber le marché des PC de bureau (si si, je vous assure. Fallait prendre des actions AMD, maintenant c'est déjà trop tard!) essaie d'investir le monde de l'IOT (l'Internet des trucs!) :

Hum, plein de bidules amusants, programmables à la mode Arduino. En fait un assemblage d'éléments disparates de techno. Intel, pas prévu pour ça à la base, mais mis ensembles pour faire croire que... Évidemment, le bidouilleur en herbe sera tenu bien à l'écart de la technologie propriétaire utilisée pour arriver au résultat apparent.

Mais bon, le but n'est pas de faire plaisir au Vulgum, mais de pénétrer les nouveaux marchés. Rien de tels que du bon vieil entrisme au sein de l’Éducation National, toujours à la mode Crosoft :

Vous voyez ce que je veux dire?

Et d'ailleurs, un de nos grands bâtisseur national était aussi présent avec ce slogan :

Hum : du béton, des tours, des grues... et encode du béton. En pleine crise et séquence économique planifiée associée sur le développement durable, les bâtisseurs écrivaient : "on ne pourra plus construire comme avant" (le moniteur). Non, c'est sur! Finissons-en avec l'artisanat, il faut voire les choses en grand maintenant!

Séquence publicitaire pour la ville de... :

Vous avez reconnu? Non? Mais si, les machines de l'île. Comment ça, vous n'êtes pas allé à Nantes? Hum.....

Bref : quelques 'amateurs' quand même :

Sur le thème instrument de musique : un clavier portable de faible poids mais largement jouable (j'ai essayé) fabriqué en imprimante 3D.

Et puis un amateur pur et dur :

En fait, une machine analogique utilisant une RaspBerry PI en guise d'interface numérique associée à quelques potentiomètres électroniques pour réagir aux commandes M.I.D.I. Le type fait ça pour son plaisir, avec même pas une intension de commercialisation!

Et sinon? A l'atelier est arrivée récemment une Drumulator :

Je me suis dit que cela pourrait être une bonne compagne pour l'Emulator 1.
La machine plante mais au moins elle démarre. Un petit coup d’œil à l'intérieur m'indique que cette boîte à rythme a été ouverte et 'bidouillée' 'un certain nombre' de fois. C'est sur, il y aura un peu de travail pour la refaire partir normalement!

Et puis question développement, j'en suis à la phase des premiers tests d'une interface intelligente destinée à s'intercaler entre un automate de type Controllino et un écran LCD couleur graphique tactile  :

Avec au premier plan, un processeur mort au champ de bataille!

J'ai choisi un processeur Atmel de type ATmega328. Et, pour satisfaire mon objectif, j'ai opté pour la toute nouvelle version de ce processeur, à savoir la version 'pb', équipée d'un double port série.

Je souhaiterais que ce montage soit programmable avec l'interface Arduino, comme l'est l'automate Controllino. Histoire de proposer un ensemble cohérent.

La chaîne de développement est classique : Atmel Studio 7.0 et carte de programmation AvrDragon.

Écrit comme ça, cela paraît simple! ERREUR!!! L'installation du logiciel Atmel peut ne pas être simple du tout et causer bien des problèmes, notamment si le Windows utilisé ne possède pas les bonnes mise à jour.

Le processeur 328pb inaugure aussi une nouvelle implémentation de la circuiterie d'oscillation, et plus particulièrement celle dédiée à l'oscillateur externe. De nouvelles limitations et de nouvelles précautions de design doivent être prises en compte!

Mais bon, au bout d'un certain temps, le 'Hello World' embarqué fonctionne avec un quartz externe de 16MHz:

Ca ne se voit pas comme ça, mais la LED verte en bas à gauche clignote bien ;-) Et en bonus celle d'en bas à droite aussi, mais cette LED est l'indication d'émission série. Parce qu'en plus mon montage émet quelques caractères à 9600 bauds. Méthode fiable pour vérifier que le processeur fonctionne bien à 16MHz!

Update 13/05/2016 : Après quelques tests et modifications, j'ai réussi à faire fonctionner cette carte sous l'environnement de développement Arduino. Pour l'instant il n'y a rien d'officiel à ce sujet sur le site Arduino, mais après avoir effectué quelques recherches sur Internet, j'ai pu trouver le bootloader adapté à ce processeur ATmega328pb.

Après quelques adaptations de fichiers pour faire reconnaitre cette carte dans l'environnement Arduino, et le remplacement du compilateur GCC par une version plus récente supportant ce processeur, le système fonctionne normalement et se programme comme d'habitude sous l'environnement Arduino (uniquement Windows pour l'instant), de la même façon que l'automate Controllino : cool!

Bon, ça n'est pas tout ça, mais il faut s'y remettre :

N'est-ce pas Dave?