Il y a certes de nombreuses raisons de financer telle ou telle cause dans le monde. Pour une fois, j'ai choisi de porter assistance, dans la mesure de mes moyens, à Frane Blanche. Je passe régulièrement sur sa chaine Youtube pour y découvrir ses expérimentations. Pour moi, elle est un peu la "Dave" Jones américaine.
La description de sa petite galère :
Et pour que la mondialisation soit vraiment heureuse il est possible, même de France, de lui faire directement un petit don :
Il arrive parfois que des personnes 'bien intentionnées' proposent à la vente du matériel en panne à prix décent, merci Théo.
Au delà de la 'mode vintage' qui fait grimper le prix des anciens matériels parfois au prix du neuf de l'époque, comme le Juno 60, d'autres matériels de la même époque ne conservent pas la même côte d'amour. Je laisserai de côté le débat numérique/analogique. Sur le site Audiofanzine, cette Yamaha REV5 est donnée pour un prix inférieur à 150€ d'occasion, entendu en état de fonctionnement.
A titre d'exemple, voici le graphe d'évolution du prix d'un JUNO 60 ces 10 dernières années :
Globalement, un prix multiplié par 3 en neuf ans pour en arriver à peu près au prix de vente de US$1795 en 1982. Le tout sans aucune garantie, évidemment, et surtout sans plus aucune source d'approvisionnement des composants en cas de problème. Il existe heureusement sur la planète (merci à la mondialisation heureuse) des personnes en mesure de re-fabriquer des composants identiques, ou compatibles.
J'ai donc acquis cette REV5 à prix très modique avec, comme indication de panne, plus aucune sortie de l'effet. La sortie du signal direct fonctionnant, quant à elle, très bien. Cette machine possédait donc la partie effet en panne.
Un effet numérique, ça n'est pas bien compliqué en théorie. Cela commence toujours par une conversion du signal audio analogique en numérique, puis exploitation des signaux numérique par un DSP fournissant les différents effets, puis, retour dans le monde analogique grâce à un convertisseur audio numérique vers audio analogique. Quand un effet ne fonctionne plus, c'est une de ces trois parties qui pose problème. Inutile de préciser qu'il vaut mieux que ce ne soit pas la partie DSP car équipée de composants Yamaha très spécifiques. On retrouve fort heureusement le schéma de principe de cette machine sur le NET :
Je fais un raccourci et n'expose que la partie intéressante de cette électronique. Hormis la partie DSP de cette REV5, le gros travail de la conversion est effectué par le circuit intégré IC124 de marque Yamaha et estampillé YM3901 : pas très rassurant de prime abord. Si ce composant est planté, il faudra en retrouver un et le remplacer. C'est du cms donc pas très aisé à dessouder.
Le rôle de ce YM3901 est très simple : il échantillonne le signal audio analogique en entrée et fourni les signaux numériques correspondant à la carte DSP. Il fournit aussi les signaux d'horloge au convertisseur de sortie, celui qui reconverti les signaux audio numériques en signaux audio analogiques, travail effectué par un PCM56P référence IC108. Le signal de donnée de ce PCM56P arrive directement de la carte DSP. Pour en revenir au gros circuit YM3901, le chef d'orchestre du traitement numérique/analogique, celui-ci s'occupe aussi du réglage automatique de l'offset ainsi que de la génération volontaire de bruit, dans le but de l'éliminer plus facilement par la suite, voir l'article Wikipédia sur la technique du Dither.
Le premier travail a donc consisté à sonder à l'oscilloscope les signaux de ce circuit YM3901. Tout semblait bien se passer, donc puisque l'effet ne fonctionne pas, partons de la fin du processus et regardons ce qui se passe à la sortie du convertisseur audio numérique vers analogique : rien! C'est un bon début. Les signaux de contrôle arrivent pourtant bien à ce circuit. Alors? son alimentation de -5V est à -3,2V. IC113, un simple régulateur -5V de type 79L05 serait en cause? Dessoudage puis test :
Voilà ce que donne ce régulateur négatif de 5V simplement alimenté. Il suffit de regarder ce qui se passe sur l'alimentation de laboratoire pour confirmer le diagnostic :
Alimenté en -12V, le régulateur consomme les 300mA programmés sur l'alimentation avec comme corollaire une chute de tension de plus de 10V de la tension d'entrée : le circuit est en court-circuit!
Remplacement du régulateur sur le circuit imprimé de cette REV5 et nouveaux tests : pas mieux.
A ce stade, cela devient carrément embêtant. Un régulateur neuf donne le même résultat que l'ancien, une fois la machine mise sous tension. Forcément, cela ne se passe pas bien derrière. Un composant dysfonctionne, mais lequel? Une capture d'écran à la caméra thermique dès l'ouverture de la machine ne m'avait pas permis d'identifier un point chaud suspect. Et c'est logique!
Petite astuce : le régulateur devant fournir le -5 V est alimenté en -12V. Pour évacuer la chaleur dégagée par la chute de tension, et comme le boîtier de ce régulateur n'est pas fait pour chauffer, et bien les ingénieurs de Yamaha ont placé une résistance de puissance juste devant le régulateur négatif. Et c'est elle qui chauffe, c'est une 150Ohms de 1W notée R295, en gros boitier, prévu pour évacuer une certaine chaleur. A l'aide de la caméra thermique, j'avais bien vu que cette résistance était légèrement chaude, mais pas de façon excessive, et après tout, elle est prévu pour cela!
Que faire maintenant? Le plus simple, enlever du circuit imprimé le composant le moins compliqué à dessouder et relié au -5V : Le convertisseur PCM56P justement. Il est au format DIP16 donc en principe facilement dessoudable. La belle erreur!!! Non seulement les pattes de ce PCM56P ressemblent à du Chamallow, mais le circuit imprimé, bien qu'en verre époxy se comporte comme du papier phénolique. Il me semble que je n'ai jamais effectué le retrait d'un simple circuit comme ce PCM dans de telles conditions. Le résultat : des pistes coupées et même des pastilles du circuit intégré décollées, bien qu'en double face à trous métallisés. Pour moi c'est du jamais vu!
J'étais à deux doigts de me résigner à confier cette machine aux bons soins de la benne à déchets électroniques... Mais au dernier moment, j'ai décidé de tenter quand même le coup, sachant que cela allait me demander un certain temps de bricolage. J'ai donc placé un support de circuits intégré :
Et y ai placé un PCM56P tout neuf. Il y a quelques années de cela, je m'étais amusé à contrôler plusieurs exemplaire de ce circuit à l'aide de FPGA. J'avais donc conservé une petite poignée de ces PCM :
Une chance parce que je ne sais pas ou j'aurais pu trouver ce type de circuits aujourd'hui. Internet est une bonne source de recherche, mais l'on tombe souvent sur de faux composants vendus par des personnes absolument pas scrupuleuses!
Voici à quoi ressemble la machine, une fois l'opération effectuée :
On y aperçoit le PCM56P juste au centre de l'image.
Et bien évidemment, il m'a fallu refaire les pistes coupées, et palier l'absence de pastilles sur certaines pattes du support de circuit :
En fait, cela ne m'a pas pris autant de temps que je me l'imaginais. Une petite heure de travail en tout et le circuit était correctement relié aux différentes pistes. Et cette fois, le test de la tension négative au multimètre me donnait bien -5V.
Je suis passé rapidement aux tests audio pour valider le bon fonctionnement de l'effet. Ce qui a été confirmé dès le raccordement de la machine à une source analogique. Restait cependant quelques petits soucis à régler comme ce problème d'affichage :
Ça recommence!!! Après le même type de problème sur le MKS30, me voilà de nouveau avec un potentiel problème d'afficheur à remplacer. Heureusement, après vérification de la petite carte support de cet afficheur, et quelques tests de diode au multimètre, il est vite apparu que c'était un problème de VIA corrodé qui générait le problème :
J'ai déjà rencontré ce genre de problème lors du dépannage d'un lecteur CD de marque Cyrus, mais sur ce lecteur c'était compréhensible étant donné le liquide noirâtre potentiellement corrosif que j'avais retrouvé sous le composant. Ici, rien de tout cela. Je n'ai vraiment aucune explication. Bref, me voilà à de nouveau faire de la couture de fil électrique :
Dépannage facile, au résultat attendu :
Avec le commentaire facile qui va avec : c'est mieux comme cela!
Me voilà arrivé au bout de la remise en état de cette REV5. Il ne reste plus qu'à remonter le boîtier tout en remplaçant les quelques vis abimées présentes deci-delà dans la machine, preuve qu'elle a déjà été démontée à plusieurs reprises :
J'en ai aussi profité pour dépoussiérer l'intérieur et nettoyer la face avant, une fois retirée.
Le remontage final nous donne ceci :
Conclusion : je ne sais pas si cette machine à un son 'vintage', mais toujours est-il qu'elle sonne vraiment bien. Qu'elle est facile d'accès et finalement plutôt robuste étant donné son âge, les stigmates du boitier, signe de quantité de déplacements, et la présence de circuits imprimés en papier phénoliques.
Il serait peut-être bon que je me décide à m'équiper d'un fer à air chaud pour déssouder de façon plus adéquate les circuits intégrés.
Je pourrais aussi peut-être m'équiper d'une petite caméra pour réaliser des vidéos avec le son, parce que la photo, ça n'est pas très parlant pour se faire une idée du fonctionnement, ou pas, d'un matériel audio!
Faisant suite au petit dépannage récent d'une Drumulator, j'ai pu constater que l'échange d'EPROM de sons n'était pas une opération spécialement triviale à effectuer par une personne non habituée à ce genre de 'bricolage'. Avec comme inconvénient majeur un fort potentiel de détérioration des EPROM, notamment de patte cassée.
Situation réelle rencontrée.
Il existait bien à l'époque des cartes d'extensions prévues pour accueillir un certain nombre de set de ROM. Ces cartes ne sont plus fabriquées, et étaient souvent de grosses extensions pas obligatoirement faciles à installer.
Extention JLCOOPER de l'époque.
En prenant en compte le fait que les supports de circuits installés à l'origine dans la Drumulator ne sont pas prévus pour subir régulièrement des changements de composants, qu'avec le temps les contacts se sont dégradés, j'ai pensé qu'il pouvait être utile de proposer une solution un peu plus moderne.
Le concept est simple : je propose donc un petit circuit imprimé prenant la place de certains des supports d'origine. Ce circuit acceptera deux PROMs contenant chacune un set STANDARD de sons pouvant être sélectionnés par un interrupteur. Pour l'instant donc, pas de sons au format ésotérique susceptible de réclamer une version adaptée de la ROM programme. Cette option verra peut-être le jour plus tard.
Voici ce à quoi devrait ressembler le circuit imprimé de la nouvelle solution :
Les deux faces du support d'EPROMs
Avant de lancer la production de ce petit circuit imprimé, il me faut vérifier techniquement que mon calcul d'espace des connecteurs est le bon. La carte ne devrait prendre que la place de trois supports d'origine sur les quatre.
D'autre part, les quatre ROMs seront condensées en une seule ce qui diminuera donc par quatre le risque de détérioration des composants. J'ai aussi réservé un peu plus d'espace pour un des supports qui pourra être de type ZIF ;
Support ZIF
Ce support ZIF devrait grandement faciliter le changement de set de sons. Le deuxième support sera un simple support, mais de qualité, qui recevra par exemple une copie des sons de base de la Drumulator.
Les quatre ROM nécessaires pour chaque set de sons...
...seront remplacées par une seule ROM de type 27512 :
Je continuerai ce billet au fur et à mesure de la réalisation de ce montage.
N'hésitez pas à m'envoyer vos commentaires au sujet de cette réalisation :
Ou comment faire de la même façon que ce que l'on fait depuis des années, mais avec du matériel récent. Je possède une carte HiFive1 depuis quelques mois sans pour l'instant avoir pris la peine d'essayer de la programmer.
https://www.sifive.com/boards
L'intérêt de cette carte de développement est qu'elle est basée sur un processeur Freedom E310. Bon, me direz-vous. Cela n'est pas faux. En fait c'est du RISC-V, un jeu d'instruction libre, c'est à dire qu'il peut être copié et implémenté à peu près ou l'on souhaite, donc dans du FPGA. Sur la carte HiFive, c'est une version 32 bits qui tourne à plus de 300MHz. Le tout dans un boitier dont la surface occupée correspond à peu près à celle d'un ATmega328p qui équipe les cartes Arduino, du 8 bits à 16MHz donc. Pour fonctionner ce petit processeur E310 à besoin d'une mémoire externe de programme. Sur la carte, c'est à une EEPROM qu'est dévolu ce rôle.
Le programme chargé dans la carte se contente de faire varier la couleur d'une LED RGB. C'est joli, ça prouve que ça fonctionne et... rien de plus. Il était donc temps d'au moins tester une suite de développement dédiée à ce type de processeur. Ça tombe bien, SiFive propose directement la suite Eclipse avec compilateur adapté. A remarquer que pour une fois, cette suite est fournie sans installation. On télécharge l'application, on 'click' sur l'exécutable et c'est prêt! Rien à voir avec d'autres fournisseurs dont la mise en place de la solution de développement requiert à elle seule une équipe de plusieurs personnes pendant un certain nombre d'heure...
Le test qui 'tue' : charger l'application en mode Debug, et effectuer une séance de débogage. Et bien, mis à part une ou deux étranges subtilités de la suite Eclipse fournie par SiFive, le test est rapide à mener et s'avère de suite concluant :
Alors non seulement ça fonctionne, mais en plus c'est rapide. Pour mes tests, j'ai utilisé un PC équipé d'un ancien processeur Core 2 Duo à 3GHz (un E7500) et de 4Go de mémoire sous Windows 7/64. Muni d'un SSD, la machine est suffisamment véloce pour une utilisation confortable de la suite logicielle. Point besoin donc d'un octo-core à 4 GHz, de 128Go de ram, et de l'infâme Windows 10!
Comme le système fonctionne, je suis allé au bout du concept et ai répondu favorablement à la question posée par les développeurs de chez SiFive :
D'autres exemples sont fournis par SiFive. Cette solution matérielle et logicielle semble donc facile à utiliser, tout du moins aussi facile qu'une carte Arduino. Je vais d'ailleurs effectuer des tests personnels avec les périphériques embarqués afin d'en savoir un peu plus sur ce processeur.
A noter qu'il existe aussi une 'distribution' Arduino pour cette carte mais uniquement utilisable sous Linux, le compilateur utilisable par le système Arduino ne semble pas être, pour l'heure, disponible sous Windows.
Et pour commencer, un peu de Forth. Je ne vais pas détailler ici ce langage avec sa syntax en polonaise inverse, mais vous trouverez un début de son historique sur Wikipédia : https://fr.wikipedia.org/wiki/Forth_(langage). La question que l'on peut se poser est de se demander sur quel type de plateforme matérielle il serait possible d'expérimenter ce langage. Je ne poserai pas non plus la question de l'intérêt d'un tel langage, sachant que tout passionné d'informatique y trouvera matière à découverte, expérimentation et... satisfaction!
Il y a quelques années de cela j'ai développé une petite carte d'expérimentation à base de processeur NXP LPC1114FN28 :
Cette carte propose tout ce qu'il faut pour mener diverses expérimentations électroniques sans avoir à se soucier du câblage minimum nécessaire à la mise en fonction du processeur. Un simple câble USB et un terminal série suffit pour développer du code sur ce matériel. Le processeur utilisé ici n'est malheureusement plus disponible. NXP ayant arrêté la fabrication de cette version en boitier DIP. Ce type de processeur à cœur ARM M0 existe bien évidemment sous d'autres formats de boitier.
Comme je possède un certain nombre de ce processeurs LPC1114FN28 mais aussi de LPC810FN8, voici donc l'occasion de corriger les quelques petites imprécisions du circuit, histoire de finaliser effectivement le concept :
Repris et modifié d'une ancienne version de Kicad vieille de quelques années, avec la nouvelle version 5 sortie il y a quelques semaines. L'occasion aussi de rencontrer quelques légers 'bugs' de jeunesse de cette nouvelle version de Kicad.
Matthias Koch a développé un interpréteur Forth pour une multitude de plateformes matérielles dont ce processeur LPC1114. Le fichier hexadécimal directement programmable dans ce processeur ARM se trouve sur https://sourceforge.net/projects/mecrisp/. Il y a quatre ans la version disponible était la 2.1.3. Nous sommes passés à la version 2.4.5. C'était donc l'occasion de vérifier le bon fonctionnement de cette nouvelle version.
Pour programmer cet interpréteur Forth dans le LPC1114FN28, il suffit d'utiliser le logiciel Flash Magic disponible à cette adresse : http://www.flashmagictool.com.
Une fois fait, le démarrage du système ne pose aucun problème. A noter qu'avec l'interface USB de tye FTDI utilisée sur la carte de développement, il est nécessaire d'effacer les signaux RTS et DTR qui sont positionnés par défaut. Cela se fait très facilement en utilisant le logiciel RealTerm par exemple :
Dès lors que ces deux signaux sont effacés, le message d'invite apparaît :
La première chose à faire par la suite, consiste évidemment à faire clignoter une LED, le fameux 'Hello World', de l'embarqué :
Le code source directement envoyé à l'interpréteur est le suivant :
\ Blink a LED on P0.3$4004402C constant IOCON_PIO0_3$50003FFC constant GPIO0_DATA$50008000 constant GPIO0_DIR
: blinky ( -- )
$00IOCON_PIO0_3! \ SetP0.3 as GPIO without Pullup/Pulldown.8GPIO0_DIR! \ SetP0.3 as Outputbegin8GPIO0_DATA!10000000doloop0GPIO0_DATA!10000000doloop
key? until
;
A noter que le source diffère quelque peu de celui fourni en exemple avec la distribution Forth de Matthias Koch en ce sens que la LED intégrée à la carte de développement n'utilise pas le même port.
Ici il ne s'agit pas du port PIO1_8, mais du port PIO0_3. Contrairement à mes tests effectués il y a quatre ans maintenant ou j'avais connecté une LED sur le port PIO1_8, j'ai cette fois directement modifié le code source pour coller directement avec la réalité matérielle. Cela consiste principalement à modifier l'adresse des trois registres du processeur afférant au port PIO0_3 :
Pour trouver facilement l'adresse des ces ports, il 'suffit' de rechercher un fichier 'include' sur le net du genre LPC11xx.h et de reconstruire les adresses à partir des données trouvées dans ce fichier. La plupart du temps, il s'agira d'une adresse de base à laquelle il suffit d'ajouter un offset.
Exemple de fichier de déclaration des ressources d'un processeur de type LPC11XX :
Le code ainsi modifié à fonctionné immédiatement. La LED clignote un peu plus rapidement qu'au Hertz malgré deux boucles d'un million d'itérations, soit 2 millions d'itérations par seconde. Pas mal pour un processeur qui fonctionne à à peine plus de 10MHz!
Remarque intéressante : il existe une instruction compiletoflash qui permet de rendre le code permanent. Quelques informations peuvent être trouvées au sujet de ce système sur le site de Jean-Claude Wippler https://jeelabs.org/2015/07/22/forth-on-a-dip/.
A tester, notamment la liaison série et un afficheur LCD par exemple.
A suivre...
UPDATE [01 novembre 2018] Autre plateforme de test.
La version DIP28 du LPC1114 fournie par NXP est dorénavant obsolète, cependant le LPC1114 existe toujours en version 28 pattes en boitier TSSOP (LPC1114FDH28/102) au prix de 2,13€ chez Mouser et en boitier LQFP48 (LPC1114FBD483021) au prix de 2,60€HT toujours chez Mouser (pub gratuite). Il y a quelques années de cela, j'avais acheté chez WaveShare une petite carte de développement à base de ce processeur LPC1114 en version 48 pattes LQFP :
Cette carte possède une interface de type SWD pour la programmation du processeur. J'avais bien envie de tester ce type de programmation mais cela implique l'achat d'une interface de programmation, parfois à prix élevé. Segger propose une interface assez simple à utiliser puisque se connectant au port USB d'un PC et proposant une interface multiple pouvant fonctionner en mode SWD, il s'agit de l'interface de programmation J-Link :
J'ai acquis cette interface il y a quelques années et, ne m'en étant jamais servi, j'ai pensé que sa mise en pratique sur cette carte de développement était bienvenue.
Le 'seul' petit problème de cette interface de programmation est qu'elle n'est pas prise en compte par le programme graphique J-Flash :
C'est bien dommage et frustrant. 50€ en gros pour cette version de J-Link et plus de 400€ pour finalement la même version mais programmée avec un firmware 'acceptable' par ce logiciel graphique, bof! Il va donc falloir utiliser l'appareil en ligne de commande, version 'old style' DOS :-(
Mais bon, cela fonctionne, et puis pour un besoin simple de programmation cela suffira. Il convient donc lancer une session 'DOS', de configurer le processus de programmation puis de lancer la programmation de la flash du processeur. Un compte rendu express d'une session typique de programmation peut se résumer à ceci :
En gros cela se résume à sélectionner le type d'interface de programmation de type SWD, à choisir le processeur ainsi que la vitesse de l'interface de programmation. Par la suite, la programmation se lance par la simple commande 'loadfile', suivi du fichier *.hex dans mon cas, ainsi que l'adresse flash ou doit se loger le programme, 0x80000000 dans le cas du LPC1114.
Photo du montage avec le programmateur J-Link :
Force est de constater que la programmation se déroule de façon très rapide et très efficace. Afin de préparer la petite carte à recevoir le logiciel Forth, j'y ai raccordé un câble USB/Série TTL de chez FTDI en version 3,3V. Une fois la programmation du processeur effectuée, une session terminale se déroule de la même façon qu'avec la carte de développement que j'ai développé :
J'y ai donc téléchargé le petit programme de clignotement d'une LED, cette fois sans l'adapter à l'une des quatre LEDs présent sur la carte. J'ai tout simplement connecté une LED externe munie de sa résistance de limitation au port PIO0_3 de la carte. le lancement du clignotement de la LED se fait tout simplement par la commande 'Blinky', invoquant le programme précédemment envoyé à l'interpréteur Forth. Et de nouveau, aucun problème, tout fonctionne comme prévu.
Conclusion n° 1(provisoire) : J'ai mis un certain temps à me décider à utiliser l'interface J-Link ainsi que cette carte de développement. En fait, arriver à un résultat concluant m'a pris moins de temps que celui nécessaire à la rédaction de cet update. Je suis toujours impressionné par la rapidité de ce Forth embarqué. J'avais prévu l'utilisation d'un afficheur LCD comme prochaine étape de ma découverte de ce langage de programmation. Je maintiens donc cet objectif suivant.
Conclusion n°2 : j'ai voulu tester la programmation de cette carte WaveShare par la méthode série et bootloader. Le câble FTDI ne fournissant pas l'ensemble des signaux nécessaires à cette configuration, j'ai donc récupérer l'ensemble du bus sur une de mes cartes de développement. Le bus est constitué des signaux TX, RX, DTR et RTS.
Photo du montage de programmation par liaison série et bootloader:
J'utilise donc cette fois le logiciel Flash Magic :
Cela me permet de vérifier le bon fonctionnement de l'ensemble. Une demande de signature de circuit me renvoi l'information suivante :
Cela semble se passer correctement. Il ne reste plus qu'à effacer le composant et à le programmer de nouveau avec le firmware Forth :
La programmation semble s'être bien passée. J'avais laissé la vitesse de communication à 9600 bauds par défaut. Les opérations de programmation et de vérification prennent donc significativement plus de temps qu'avec l'interface SWD de l'outil de programmation Segger J-Link. D'instantané, ou quasi, par le biais de la liaison série le processus complet prend presque 30 secondes à 9600 Bauds.
Après vérification, le firmware Forth est correctement installé dans le processeur. Le téléchargement du programme Blinky fonctionne aussi parfaitement :
Cette façon de faire est un peu plus artisanale, puisqu'un certain nombre de bouts de fils sont à connecter en l'air. Par contre, le coût de l'ensemble est très significativement moins élevé que la solution Segger. L'interface graphique fournie par FlashMagic est largement suffisante et bien plus pratique que le mode DOS imposé par Segger avec sa version EDU de l'interface J-Link.
A noter par contre, que l'interface Segger est en mesure d'effectuer du débogage temps réel avec le logiciel approprié, même en version EDU. Ce qu'est bien évidemment incapable de faire la solution de programmation par liaison série. Cela n'est d'ailleurs pas son objectif.
