Micromite Companion : construction du système.

Dans mon billet précédent traitant du système Maximite, j'ai détaillé la genèse du projet de Geoff Graham puis les différentes reprises du sujet par d'autres contributeurs, pour terminer sur une évolution intéressante qu'est le système Micromite accompagné d'une extension très pratique se présentant sous la forme du Micromite Companion. Avec au menu, le rajout d'une sortie VGA, d'une sortie audio, d'une entrée clavier type PS/2 et d'un lecteur de carte SD pour former le système suivant :

Du site http://propellerpowered.com

Mise en situation : pour quelle raison utiliser ce système plutôt que la version Maximite d'origine qui possède aussi toutes ces interfaces? J'y vois au moins une raison intéressante, le processeur PIC32 utilisé est très petit et très facile à souder avec son boîtier en version DIP. Cet ensemble devient dès lors une base de développement autonome très pratique. Une fois le programme Basic finalisé, il peut alors être implémenté dans le processeur d'application, lui même prenant place ne serait-ce que sur une carte d'expérimentation. Le développement de petits systèmes devient alors très facile.

Deuxième raison, les fonctionnalités offertes par le 'processeur graphique' permettent la créations d'application plus conviviales moyennant la programmation du bus I2C assurant le transfert de commande depuis le 'processeur central' vers le 'processeur graphique'.

Et peut-être, ou sans doute une troisième raison : comme le 'processeur graphique' est maintenant autonome, il peut se présenter sous différentes formes et offrir des modes graphique non supportés actuellement ouvrant ainsi de multiples possibilités tout en restant très simple à utiliser.
N'oublions pas d'autre part que Microchip, le fabricant du processeur PIC32 utilisé dans ce montage, à sorti en 2013 une version à 200Mhz référencé PIC32MZ et non plus seulement MX qui, outre une fréquence de fonctionnement bien plus élevée, semble être aussi plus performant dans l'exécution de ses instructions!

Mais avant de profiter de ce Micromite Companion, il est nécessaire de le construire parce qu'il est livré sous cette forme :

Avant de vous lancer dans un tel montage, si comme moi la curiosité vous pousse à essayer ce concept, notez que même si sa construction ne pose pas de problème pour une personne avertie, je le déconseille à ceux d'entre vous n'ayant jamais tenu un fer à souder en main. L'assemblage de la carte nécessite une petite pratique notamment en ce qui concerne le soudage du connecteur de carte SD, plus d'autres approximations du développeur nécessitant quelques acrobaties.

Ne pas perdre de vue qu'il s'agit d'un produit amateur et donc largement perfectible.
Le circuit imprimé n'est pas très bien réalisé :

Toutes les pistes ne sont pas au bon format, notamment certaines véhiculant non pas des signaux mais des tensions, qui devraient être plus larges.

Les résistances sont montées debout. C'est une très mauvaise idée, d'autant plus que celles fournies sont de type carbone (des type métal eussent été plus judicieuses) équipées de pattes très fines et très faciles à plier. Se faisant, il est relativement difficile de conserver l'alignement des séries de résistances qui ont, de plus, tendance à ce coucher sur le circuit imprimé si l'on n'y fait pas attention.
En agrandissant légèrement la taille du circuit et en agençant les composants de façon plus étudiée, il aurait été tout à fait possible de les implanter à l'horizontal.

Les résistances présentes face au connecteur du clavier doivent être implantées corps côté connecteur (comme conseillé pour celles face au connecteur VGA alors que ce dernier est en plastique) et non pas l'inverse comme présenté sur le circuit imprimé. En ce qui me concerne je les ai montées comme présenté sur le circuit alors que des commentaires d'amateurs ayant déjà réalisé ce montage conseillaient de faire l'inverse. Peu importe, je les ai placées correctement, les pattes ne touchent pas le connecteur métallique.

Le connecteur VGA possède un écartement des lignes de contact trop grand par rapport a celui fourni dans le kit. Heureusement, en forçant 'légèrement' il finit par se loger correctement.

Enfin, j'ai ôté à la scie à métaux les deux ergots présents sur la plaque d'expérimentation qui, même si l'auteur de ce système assure l'inverse, ne rentre pas facilement entre les rangées de connecteurs dédiés à cette plaque d'essais.

Malgré ces petit détails il est relativement aisé d'arriver au résultat final en suivant la procédure de montage, pour finalement obtenir ceci :

Quelques remarques utiles pour la première mise en service :

• Les deux processeurs sont fournis déjà programmés.
• La carte SD doit être formatée en FAT16 et être d'une capacité de 2Go max.
  
• Les fichiers nécessaires au 'boot' de l'appareil, ainsi que divers exemples sont hébergés sur DropBox. Je considère que l'emploi de ce service est une vraie bêtise. Il n'a pas été étudié pour ce genre d'utilisation. Ne soyez donc pas surpris de constater des lenteurs de navigation ni même des erreurs à la demande de téléchargement. Si tel est le cas, réitérez votre demande.

Tous ces préparatifs pour en arriver à :

Je le rappel, ce projet est un projet amateur. J'ai donc constaté quelques petits problèmes suite aux premiers tests.

Tout d'abord une broche du 'processeur graphique' est laissée en l'air. Il s'agit de la patte 10 notée BOEn du P8X32A (le 'processeur graphique' de type 'Propeller' du fabriquant Parallax).

 

Ceci à pour effet de redémarrer le P8X32A si l'on passe la main à proximité de cette patte. C'est plutôt gênant mais très facile à corriger en la connectant à la masse. En ce qui me concerne, j'ai effectué une connection directement sous le dessous du circuit imprimé à l'aide d'un bout de patte de résistance avec la patte 9 voisine notée VSS du processeur P8X32A comme vous pouvez le voir au centre le l'image :

Petite modification facile à réaliser.

Enfin, il semblerait que le 'processeur graphique' ne soit pas en mesure de soutenir la vitesse d'affichage des chaînes de caractères en provenance du processeur Micromite. En effet, ce simple programme devant afficher en continu un chiffre qui s'incrémente

BEGIN:
A = A + 1
PRINT A
GOTO BEGIN

génère des sauts d'incrément à l'écran ainsi qu'une aberration d'affichage à une fréquence régulière. D'après ce qu'il me semble avoir constaté, le buffer de réception du 'processeur graphique' déborde régulièrement et laisse donc passer un certain nombre de caractères. Ce problème sera donc à prendre en compte lors de l'affichage d'un grand nombre d'informations à l'écran, à moins qu'une prochaine version de firmware ne corrige ce problème.

Et puis il sera possible de regretter que ce système ne prenne en compte que le clavier anglais, même si l'on peut se douter que commencer à en gérer une multitude ne soit pas trivial.

LE MATCH

Le meilleur pour la fin : afin de me faire une idée plus précise de la 'puissance' de ce système, j'ai programmé un petit test qui consiste tout simplement à incrémenter une variable de 000 000 à 100 000 sans en afficher la valeur et à comparer le temps d'exécution avec le même programme exécuté sur mon antique TRS-80 PC-2. J'obtiens les résultats suivant :

Temps d'exécution de la boucle.

• 3 000 secondes pour le PC-2.
• 23 secondes pour le système Micromite Companion.

Soit un rapport de 130. Impressionnant, non? J'imagine mieux maintenant ce qu'il est possible de créer avec ce Micromite par rapport à ce que j'ai pu faire avec mon PC-2 qui était en sont temps, considéré comme une très bonne machine.

Neo computers : les Mites sont à l'œuvre!

Depuis quelques années, la 'révolution' Arduino est en marche... Vous en avez certainement entendu parlé tellement il est impossible d'y échapper. Dans le 'petit' monde de l'embarqué, ces systèmes sont devenus incontournables. A ce point que même de grands fondeurs de composants comme Intel, Texas Instruments, ST et bien d'autres, proposent diverses cartes de développement basées sur le même principe qui a fait le succès de la famille. A l'origine les cartes Arduino étaient, et le sont toujours pour la majorité, équipées de processeurs de type AVR du constructeur Atmel.

L'incontournable UNO, origine : du site officiel Arduino

Les cartes Arduino ou compatibles sont proposées à prix très bas en général inférieur à une centaine d'Euros, même équipées d'un puissant processeur ARM, et sont accompagnées d'un outil logiciel de développement gratuit qu'il suffit de télécharger. Ce logiciel produit du code binaire directement exécutable par le processeur à partir d'un langage 'C' 'simplifié' ou une grande partie des fonctionnalités disponibles est 'cachée' dans diverses librairies fournies. La puissance de ces petits systèmes est assez conséquente, même lorsque la carte est équipée d'un petit processeur AVR puisqu'ils exécutent du code non interprété, à la différence d'autres langages comme le Basic.

Ces systèmes souffrent tout de même d'un petit manque à mon sens, et ajoutent une contrainte que je trouve assez gênante. Tout d'abord, ils ne fournissent aucune possibilité native d'affichage. J'entends par la un affichage sur un écran standard de type VGA, même s'il est toujours possible d'y connecter des afficheurs LCD. De ce fait, certaines applications sont difficilement envisageables.

D'autre part, le principe 'Arduino' implique de disposer d'un ordinateur 'standard' sur lequel sera installée l'application de développement et de téléversement du code dans le processeur. Un PC sous Windows/Linux, ou un Macintosh est donc obligatoire.

Mise en situation : Sans obligatoirement aller chercher des cartes embarquées fonctionnant sous Linux, il existe depuis quelques temps (2011) un petit système autonome, programmable en Basic, et capable d'afficher des textes et des graphiques nativement sur un écran VGA : les 'trucs-mites'.

De quoi s'agit-il? A l'origine il s'agit d'un projet de Geoff Graham qui eût l'idée de porter le basic Microsoft MBASIC sur un processeur très puissant de la famille PIC32 de Microchip. L'idée fut publiée dans la revue Silicon Chip de mars à avril 2011 sous le titre "The Maximite", et se présente sous la forme d'une carte autonome comportant l'intégralité des fonctionnalités du système : la Maximite

Image provenant du site de Geoff Graham.

Et de base, le système est assez séduisant. Bien que reposant sur un interpréteur Basic qui, comme son nom l'indique interprète chaque ligne de texte du programme, la vitesse d'exécution de l'interpréteur associé à la rapidité du processeur de type RISC fonctionnant à 50Mhz, confère au système une rapidité d'exécution tout à fait surprenante. A titre indicatif, au début des années 80, je faisais mes premières armes avec un système de ce type doté d'un processeur de type CICS fonctionnant à moins d'un MHz :

Et revoici mon TRS80-PC2!

La comparaison n'a même plus de sens tellement il devient absurde de confronter un processeur de type Z80 avec un PIC32! Et pourtant, il m'est arrivé d'utiliser ce PC2 au travers de son connecteur d'entrées/sorties disponible sur le côté gauche de l'appareil pour commander un processus industriel assez complexe de gestion de moteurs de remplissage d'un château d'eau!

De base, le système Maximite offre la visualisation sur un moniteur VGA, dispose d'un éditeur en ligne pour le Basic intégré, d'un connecteur pour carte SD, d'une prise pour un clavier type PS/2, d'un port USB, et de différents signaux d'entrées/sorties, le tout très facilement accessible par le biais de commandes en Basic que Geoff Graham a eu la très bonne idée d'ajouter au langage d'origine.

En terme de performances et de flexibilité, le Maximite n'a plus rien à voir avec le PC2. Les capacités mémoires sont à l'avenant. Maximite dispose de 128K de RAM, le PC2 n'en disposait que de 1,8K!
Si l'on compare ces caractéristiques à ce que fût le PC d'origine, le contraste est tout aussi saisissant. Un processeur 16 bits (le PIC32 est un 32 bits) fonctionnant à moins de 5Mhz (4,77MHz), 64K de ram pour les premières versions, un lecteur de disquette poussif de 180K et un affichage monochrome non graphique!

Quelques exemples de produits compatibles Maximite de ce que j’appellerais 'la première vague', développés soit par Geoff Graham lui-même, ou disponibles chez d'autres éditeurs de cartes électroniques :

Le Maximite d'origine en sortie VGA monochrome :

http://archive.siliconchip.com.au/cms/A_112362/article.html

Le Maximite color :

Image provenant du site de Geoff Graham.

Un peu de la même façon que des cartes Arduino compatibles éditées par d'autres entités que les concepteurs originaux se sont vues affublées du terme 'duino' dans le titre, des 'quelques-choses-Mites' sont aussi apparues, éditées par Geoff Graham lui-même, ou par d'autres :

la Mini-maximite de Geoff Graham :

Image provenant du site de Geoff Graham.

La TFT-Maximite de Segor Electronics :

Image provenant du site de Segor Electronics.

La UBW32 de Brian Schmalz, qui ne comporte pas de 'mite' dans le titre :

Image provenant du site de Geoff Graham.

La CGMMSTICK1 - Maximite de CircuitGizmos : 

http://www.circuitgizmos.com.

La CGCOLORMAX2 - Color Maximite de CircuitGizmos :

http://www.circuitgizmos.com.

La DUINOMITE-MINI d'Olimex :

www.olimex.com.

La DUINOMITE-MEGA, toujours d'Olimex :

www.olimex.com.

Jusqu'à la Maximite BBX de Chuck Hellebuyck qui a récemment fait l'objet d'une campage de crowdfunding sur kickstarter :

Mais au fait, pourquoi s'intéresser à ce système simple programmable en langage Basic?

Outre les côtés très intéressants de la rapidité d'exécution des programmes et de la versatilité de la machine, ce système présente tout de l'ordinateur autonome et intuitif tels que le furent en leur temps les micros-ordinateurs de la fin des années 70 démocratisés par les fameux ZX80 et  ZX81, avant que tout ce microcosme bouillonnant d'idées et de ressources ne soit remis en cause par le très médiocre IBM PC (avis personnel qui est toujours le mien presque 30 ans plus tard).

Mais, pour être complet, cette base Maximite se doit d'évoluer vers une architecture générale plus complète. A mon sens, le coup de départ de la 'seconde vague' vient d'être donné par Bryan Cockfield par la création du 'Micromite Companion', le MMC :

http://propellerpowered.com

Quelle différence par rapport à la Maximite d'origine?

Sur ce système, le processeur principal n'est plus un circuit équipé d'une grande quantité de pattes d'entrées/sorties mais un processeur plus simple en terme d'interfaces extérieurs qui ne joue plus le rôle QUE de processeur central : le Micromite, toujours développé par Geoff Graham.

Dans le système Maximite  d'origine, c'est le processeur central qui gère l'interface vidéo. Cela ne pose pas vraiment de problème de ressources au processeur car elle à été développée pour effectuer sa fonction dans son coin en interférant le moins possible avec le cœur Basic du système.

Le circuit Micromite, lui, ne gère absolument pas la vidéo. Il ne peut être programmé que par l'intermédiaire de son interface série dédiée à la console. Or il existe plusieurs projets de réalisation d'un terminal type VT100 autonome, en mesure d'afficher les informations sur un écran VGA standard, dont celui de Geoff Graham lui-même : VT100. Son projet utilise toujours un PIC32 pour réaliser la fonction.

http://geoffg.net/terminal.html

Cependant il existe un autre type de processeur puissant et capable d'afficher sans problèmes, caractères et graphiques sur un écran VGA, le processeur Propeller de Parallax. Un bon exemple de ce type de réalisation est le terminal de Vince Briel de Brielcomputers, le PocketTerm :

Brielcomputer.

C'est justement ce type de processeur Propeller qui a été utilisé dans le projet MMC cité plus haut. Ce circuit joue dans ce cas, le rôle de co-processeur graphique avec des possibilités tout à fait étonnantes :

Il devient donc possible de considérer, avec cette nouvelle mouture de Micromite accompagné d'un co-processeur vidéo, que le système vient d'entrée dans une nouvelle phase d'améliorations substantielles, propres à procurer pour un coût réduit tant en terme d'achat de matériel que de temps de développement, des possibilités importantes dans divers domaines.

Pour l'instant, la définition vidéo peut paraître encore faible, mais d'une part la voie de l'amélioration est tracées, et d'autre part des systèmes bien plus complexes à programmer existent depuis longtemps pour afficher quantités d'informations statiques et dynamiques à l'écran.

Mais ce système Micromite offre aujourd'hui une alternative intéressante dans la réalisation rapide et efficace de certaines applications qui réclameraient à contrario de très gros investissements financiers en développement sur d'autres plates-formes.

La prochaine voie d'amélioration devrait sans conteste se focaliser sur la connectivité du système. Pour l'instant, seule une connection de type série est possible. Pour rendre Micromite visible depuis le net, une interface réseau semble être inévitable, qui décuplerait totalement les champs d'applications de ce petit ordinateur.

Perspectives :  Obtenir et tester ce système. Puis le déployer dans une véritable application... Et puis espérer qu'une communauté active naisse autour de ce projet, un peu de la même façon que ce qui s'est passé pour l'Arduino!

Sauvegarde des mémoires programme des synthétiseurs vintages et autres antiques Breloques électroniques...

Bien que le non de ce blog puisse le suggérer, force est de constater que je n'ai pas vraiment publié de sujet sur les synthétiseurs jusqu'à maintenant, mis à part ce billet de juin : Prophet VS et CEM5530

L'occasion donc d'évoquer ici un sujet récurent qui ne laissera, j'en suis (quasi) certain, pas grand monde indifférent.

Mise en situation : aux presque débuts de l'histoire des synthétiseurs, je fais ici référence à la période ou est apparu sur terre le règne des micro-processeurs dans les années mi-soixante-dix, ces machines et par extension beaucoup d'appareils électroniques se sont vus affublées du vocable 'programmable' ou 'full memories' ou que sais-je d'autre pour indiquer la merveilleuse nouvelle possibilité de sauvegarde des configurations. En d'autres termes, le progrès permettaient non seulement de programmer le son sur un synthétiseur mais aussi et surtout d'en conserver les paramètres même lors de son extinction.

Impossible de ne pas faire mention d'un des tout premiers synthétiseurs de ce type, le Prophet-5 de Séquential Circuit :

Image honteusement 'pompée' du web!

A cette époque, pas d'EEPROMs, flashs, SD-Cards clés USB, disques durs etc etc... Non, la plupart du temps il s'agissait d'une RAM statique communément appelée SRAM qui, alimentée par une source de tension de secours, conservait les précieuses données. Une SRAM étant statique, elle conserve d'elle-même ses données sans nécessité de rafraîchissement comme les DRAM (dynamique RAM), du moins tant qu'elle reste alimentée. La 6116 de 2K octets en est la digne et vénérable représentante :

Image honteusement 'pompée' du web! Mais estampillée MHS quand même

!

Et alors me direz-vous. Et bien ces SRAM, même si elles requièrent une très faible puissance pour retenir leur contenu, réclament tout de même une sauvegarde par pile ou batterie à même de palier l'arrêt d'alimentation générale. Et c'est la que se pose le vrai gros problème. Quand la pile ou la batterie est déchargée, outre le fait qu'à ce moment précis la SRAM et vous par la même occasion avez perdu toutes vos informations, elle a tendance à fuire, à couler et à oxyder les pattes des composants alentours ainsi que des pistes du circuit imprimé. Inutile de préciser qu'à ce petit jeux, il arrive un moment ou le synthétiseur peut présenter comme un léger dysfonctionnement. Un bon exemple provenant du site http://www.digplanet.com :

Joli travail!

Ne pourrais-t-on pas se passer de ces piles ou accus pour éviter ces problèmes?
Si, évidemment, on pourrait. Mais ça n'est pas si simple. Même s'il existe aujourd'hui d'autres composants capables de retenir l'information sans alimentation, ils requièrent tous un traitement algorithmique particulier pour mener à bien leur mission. Or, dans le cas qui nous intéresse, le circuit de remplacement doit fonctionner DE LA MÊME FAÇON que la SRAM d'origine. Ou en tout cas, en simuler parfaitement le comportement.

Il existe une solution viable : la FRAM. Initialement fabriqués par Ramtron, ces composants le sont depuis quelques mois par Cypress qui à apparemment acquis Ramtron. A noter que Cypress propose une autre solution de SRAM non volatile basée sur un autre principe : la sauvegarde pure et simple du contenu d'une SRAM classique dans une mémoire non volatile. L'opération s'effectuant sans la moindre intervention extérieur, à l'occasion de la disparition de la tension d'alimentation du composant.

Ces circuits FRAM se comportent exactement comme les SRAM mais, de technologie ferro-magnétique, ils ne perdent pas leur données même en cas de perte d'alimentation.
Et personne n'y a déjà pensé? Si, bien-sûr :

Ça se trouve ici : http://pinforge.com/6116.html

Tout va bien alors! Oui, c'est parfait, sauf que ce circuit FM1608 est obsolète (tiens j'aurais encore pu caser 'obsolescence programmée' dans le titre de ce billet) et de toute façon fonctionne (fonctionnait) en 5V.

Mais, Ramtron (Cypress) propose ce même type de circuit en technologie moderne, donc fonctionnant en 3,3V. Et la, ça ne va plus du tout. Inutile de tenter la connection d'un tel composant en environnement 5V, norme de toutes les machines dont il est question dans ce billet. Cela risque fort de ne pas plaire à la FRAM, pas plus qu'à Denis Bodor (des éditions Diamond).

Il faut donc adapter les signaux! Avant de présenter mon prototype sur la question, je tiens à préciser qu'il s'agit d'un prototype et que c'est en pleine conscience et possession de mes moyens que j'ai adopté les solutions présentées ici :

Tada!

Pour adapter les signaux du bus d'adresse, j'ai implémenté sur la face cachée du circuit ci-dessus, un ensemble de ponts diviseurs réalisés à partir de résistances cms en boîtier 603. Pour déterminer les valeurs des résistances, j'ai considéré la charge CMOS que cela pouvait présenter aux sorties du processeur, ainsi que la fréquence de coupure et donc la fréquence maximale atteignable par ce système en considérant la capacité d'entrée des signaux de la FRAM. Le tout pour obtenir quand même un rapport de division me permettant d'obtenir les 3,3V à partir du 5V. Petit jeux amusant mais digne du parfait hérétique!
Pour le bus de données, j'ai adopté un convertisseur standard de bus 3,3V <-> 5V.

La raison profonde de ce choix, en vrai, est qu'après avoir tenté la mise en place sur un circuit imprimé si petit, de composants logiques me permettant d'effectuer l'adaptation voulue de tous les signaux, je me retrouvais avec des caractéristiques de circuit imprimé difficilement réalisable par les fournisseurs standards, ou en tout cas, à un prix pas vraiment amateur!

J'ai donc tenté ma chance d'une autre façon. J'ai considéré que la plupart des synthétiseurs, enfin ceux que je possède, ne sont équipés que d'une très petite partie processeur. En général une RAM, une ROM et très peu de buffers de bus. D'autre part, ces systèmes fonctionnent à très faible vitesse et n'accèdent pas aux circuits à moins de 100ns. Ma solution devait donc convenir tant en terme de charge sur le bus d'adresses qu'en terme de fréquence de fonctionnement.

Et revoici le terminal Télémécanique XBT, dont j'ai en partie décodé le fonctionnement pour l'adapter à mes besoins, en l’occurrence tester mon prototype de FRAM. Ce terminal XBT ressemble très fortement à beaucoup de parties processeur des synthétiseurs 'de la belle époque', ça tombait bien...

La FRAM juste sous l'émulateur d'EPROM.

Le résultat est très probant. J'ai programmé le terminal pour écrire les 32K octets de la FRAM alternativement avec le code 0xAA et 0x55 avec lecture totale de la mémoire avant changement de code, et vérification de la donnée lue. Le tout en boucle continue. Cela fait quelques jours maintenant que le système fonctionne en permanence.

Je me contente d'afficher que le test est effectué lorsque je ne trouve aucune erreur à la suite d'une boucle complète d'écriture/lecture. Sinon, un message plus...laconique apparaît! Pour l'instant, j'obtiens plutôt ceci :

Avec un film plastique devant l'écran pour en améliorer le contraste

.

Perspectives : je laisse le système fonctionner de la sorte encore quelques jours et si tout se passe bien, je l'implémenterai dans un des synthétiseurs à ma disposition. Puis, si le fonctionnement s'avère concluant, j'étudierai un système plus 'orthodoxe' avec adaptateur de bus adéquate.

Update 18/10/2014

Les tests effectués à l'intérieur d'un JX3P n'ont pas été concluants. Après avoir retiré la RAM de la carte mère du synthétiseur, j'ai placé sur le circuit imprimé un support de circuit intégré pour y insérer le montage à FRAM, non sans avoir effectué les quelques adaptations de câblage nécessaires. La ram d'origine est une 6116 (ou équivalente) alors que le montage à FRAM possède le brochage d'une 62256. A la mise sous tension, le synthétiseur s'initialise correctement. Cependant par la suite, il ne réagit plus.

Testés à l'oscilloscope, les signaux de la carte mère semblent corrects mais pas obligatoirement aux bons niveaux. Comme le JX3P possède des bus d'adresses et de données plus étendus, avec beaucoup plus de composants que sur ma carte de test, la chute d'impédance du bus généré par les diviseurs de tension du montage FRAM perturbe la partie processeur.

C'est ce que je craignais. Je n'ai pas été déçu!
Une étude avec adaptation complète du bus d'adresse s'impose donc!

Pour la sauvegarde et la restauration des paramètres sonores de la machine, j'ai utilisé un enregistreur DAT portable Sony TCD-D8. Une fois les niveaux sonores réglés, le fonctionnement est parfait!

Update 04/02/2015

Nouvelle version fonctionnelle du projet NVSRAM.

Audio HiFi, développement durable et réparations : lecteur CD mission Cyrus DAD3 et DAC Q7

En matière de Haute fidélité, le choix en appareil se trouve aujourd'hui bien limité. Le cas des lecteurs de CD audio est assez représentatif de la situation. Il n'existe plus aujourd'hui que du matériel relativement bas de gamme incapable de concurrencer ce qui se faisait à une certaine époque dans le milieu de gamme, ou alors du très haut de gamme qui ne présente réellement que peu d'intérêt si l'on s'en tient à l'objectif simple d'une bonne reproduction sonore. Comme me le rapportait il y a peu de temps une amie désireuse de s'équiper en matériel digne de ce nom : "il n'y a plus de moyenne gamme". A cela je rajouterais que les quelques matériels disponibles ne sont en plus pas très esthétiques!

Il y a bien longtemps que j'ai constaté ce phénomène. Et puis, sur la simple envie de 'tenter' un appareil au design non conventionnel, j'ai craqué pour un lecteur au boitier atypique, un Cyrus Mission DAD3 que j'ai acquis pour la 'modeste' somme de 100€ en occasion... et en panne.

Le lecteur CD, une fois dépanné, non sans difficultés.

Mise en situation : d'après l'ancien propriétaire, le lecteur à commencé à présenter des problèmes à l'ouverture et la fermeture du tiroir CD. Ce phénomène s'était déjà présenté quelques années auparavant et avait été réglé. Mais cette fois, le service de dépannage n'a rien pu faire et pire, la situation s'est dégradée puisque la machine ne démarre plus du tout. Lors de la transaction d'achat, le vendeur me prévient donc que l'appareil est parti en dépannage, qu'il y a eu une assez grosse intervention à l'intérieur et que plus rien ne fonctionne. Je tente quand même le coup.

Je démonte la machine. Elle semble bien construite mais pas spécialement facile d'accès. Les nombreuses interventions que j'aurai à effectuer pour résoudre de façon définitive les différents problèmes ne feront que confirmer ma première impression.

Image prise en cours de dépannage.

La carte mère présente bien et se compose de quatre parties distinctes :

Blocs fonctionnels de la carte mère du lecteur.

Le module DAC se présente sous l'aspect d'un bloc compacte muni de connecteurs sous sa partie inférieur se logeant directement sur ceux de la carte mère. De ce fait, ce module peut être retiré pour un travail plus aisé sur le circuit imprimé principal.
Je démonte donc totalement la machine et dépose le circuit imprimé principal sur le plan de travail et commence mes investigations. Effectivement, mis à part le rétro-éclairage de l'affichage, rien ne se passe à l'écran!

La petite LED verte clignote de façon erratique passant par moment au rouge.

Le comportement général de la carte, et à la faveur du comportement étrange de la LED verte, me fait immédiatement penser à un fonctionnement sous l'emprise d'un processeur ayant largement abusé de substances alcoolisées! Commence alors un long moment de test à l'oscilloscope des signaux du processeur de type 68HC11 dont la documentation est très facile à trouver sur le Net. Certains signaux me semblent effectivement étranges, non pas en terme de forme, mais plus sur leur timing. Passé un certain temps à me questionner sur la raison de ce comportement, et ne voyant rien d'autre qu'un problème potentiellement grave, processeur défectueux, ROM défectueuse ou partiellement effacée, composants annexes posant problèmes, je décide de tenter la méthode Coué avant d'envisager les très gros travaux. Sachant qu'il s'agit d'une machine déjà assez âgée et après avoir vérifié que les tensions de la section processeur étaient correctes, je décide donc de faire subir quelques contraintes mécaniques au circuit, histoire de voire :

Bonne pioche?

En appuyant du côté du processeur, je constate que le système démarre. C'est un bon début. Muni d'un stylo de flux pour soudures, je refais les soudures des cinq circuit intégrés en boitier CMS constituant la partie gestion du lecteur. La machine semble fonctionner maintenant de façon correcte.
Je m'attaque donc à la partie gestion de l'ouverture/fermeture du tiroir. Facile, les précédentes personnes ayant œuvré sur la machine ont carrément retiré les quatre transistors constituant le pont en H de puissance, destiné à alimenter le moteur du tiroir.

Les quatre transistors manquant.

La solution la plus évidente pour régler le problème de ce pont en H aurait été de placer quatre nouveaux transistors à l'endroit d'origine. D'une part je ne savais pas de quel types de transistors il s'agissait, à la base sans doute de simples bipolaires NPN et/ou PNP, mais surtout s'agissant de composant CMS très petits, la difficulté potentielle de soudure et surtout de nouvelle intervention en cas de problème, m'a fait préférer une 'externalisation' de la fonction.
J'ai donc opté pour un circuit intégré de chez Rohm, le BD6210.

Ficher technique partielle du constructeur.

Ce circuit se présente en boitier SOP8 que j'ai placé sur un circuit imprimé prévu à cet effet provenant de chez SparkFun. Le tout, collé à l'aide d'un double face 'puissant', directement sur la partie fixe du tiroir CD.

L'alimentation (rouge et noir) et la commande du moteur (bleu et jaune).

De la même façon, j'ai 'tiré' des fils d'alimentation et de commande du moteur depuis la carte principale après avoir trouvé, sans grande difficulté, les 'points' de commande du sens du moteur à proximité de l'emplacement des transistors d'origine.

Du double face est utilisé pour solidariser les fils.

Je raccorderai définitivement ces fils avec ceux du tiroir CD lors du remontage final de la machine.

Les tests réalisés en raccordant tous ces brins sans les souder ont été concluants. Le tiroir fonctionne de nouveau normalement.
Avant le remontage final, j'en profite pour changer quelques condensateurs chimiques qui ont fuit, dont certains corrodant largement certaines pistes du circuit imprimé. J'avais constaté lors du test de la partie processeur que la machine souffrait de soudures plus ou moins bien réalisées.

Lors du changement des condensateurs, il m'est arrivé un 'évènement' auquel je n'avais encore jamais été confronté. Lors de la manipulation de la carte, j'entends le bruit de quelque chose qui tombe sur ma table de travail. Je constate que c'est un condensateur chimique cms. Je précise qu'à ce moment de la manipulation, tous les condensateurs que j'avais changé étaient correctement soudés sur la carte. En investiguant l'ensemble du circuit, je constate que c'est un composant placé sous le module DAC qui s'est 'décollé' du circuit imprimé. Et force est de constater qu'il était bien collé et non pas soudé, sans doute par le flux de soudure et non pas par la soudure elle-même!!!

Étonnant non?

Dès lors que tous les condensateurs à problèmes potentiels sont changés, j'effectue un dernier test de la machine avant remontage. C'est alors que s'engage entre ce lecteur CD et moi, une relation très très compliquée!!!

Le début des VRAIS problèmes!

Le lecteur montre de nouveau des signes de fonctionnement pour le moins... instables. Par moment le panneau de commande plante, ne répondant plus aux sollicitations des touches, à d'autres moments, le lecteur ne démarre plus mais fait de nouveau clignoter la LED et le rétroéclairage de l'afficheur ET, cerise sur le gâteau, fait sortir et rentrer le plateau CD de façon aléatoire, continuelle et vraiment TRÈS agaçante!
Je me demande même si ça n'est pas ce phénomène qui a conduit les précédentes personnes étant intervenues à l'intérieur de cet appareil à avoir dessoudé les transistors de commande du plateau.
Je sais que la n'est pas le problème mais qu'il s'agit encore de signaux défectueux concernant le processeur.
Ce dernier possède plusieurs modes de fonctionnement. Dans le lecteur, il est utilisé en mode 'microcontrôleur' MAIS avec mémoire ROM externe. Si le processeur plante, et en supposant que les composants ne soient pas défectueux, il ne reste plus qu'à soupçonner les liaisons entre le processeur et la ROM.
Me voilà de nouveau reparti en investigation à l'aide de l'oscilloscope. Je finis par en conclure qu'il y a un problème de sélection de la mémoire morte. Et effectivement, en testant la continuité du signal de sélection du boitier ROM vers la sortie du circuit intégré dont il émane, je constate une impédance non négligeable, de l'ordre de la centaine d'Ohm. Je soupçonne une piste défectueuse sur le circuit imprimé mais ayant son origine sous le circuit logique générant le signal de sélection, je me contente de 'ponter' le signal à l'aide d'un morceau de fil de wrapping.

Ce circuit positionne l'accès à la ROM suivant plusieurs signaux du processeur.

Et ça fonctionne! Tellement bien qu'au bout d'un certain nombre de jours de test, je me décide à remonter le lecteur.

Hélas, quelques semaines plus tard, le dysfonctionnement recommence, de la même façon : fonctionnement erratique et démarrage parfois aléatoire de la machine.

Cette fois cependant, à la faveur de ce que j'ai pu détecter comme problèmes autour du circuit intégré 'générateur de signaux' de sélection de la ROM et, en ajoutant que dès le départ c'est lorsque j'appuyais avec le doigt du côté de ce composant que la machine fonctionnait, je me décide à retirer ce composant du circuit imprimé parce que j'ai acquis la quasi certitude que c'est la que se situe depuis le départ, une partie importante des problèmes de cette machine.

La surprise du chef!!!

Mais quelle est donc cette substance noirâtre présente sous le circuit?
Un petit coup de nettoyage avec un coton tige...

Cela ne ressemble pas du tout à du résidu de soudage...

Je ne sais pas qu'elle est cette substance. J'en suis réduit à émettre des suppositions. En effet, dès la première ouverture du boitier de ce lecteur, j'avais été 'agréablement' surpris par une bonne odeur parfumée. Odeur bien éloignée de celle devant émaner d'un tel appareil de presque 20 ans d'âge. Je ne m'étais pas inquiété outre mesure de cette effluve. Et, de la façon dont est construit le boitier, je ne vois pas bien comment une substance telle que du parfum aurait pu se loger à cet endroit. A moins que lors de la toute première intervention...

Par contre, les dégâts infligés au circuit imprimé sous ce circuit intégré sont bien réels et tout à fait dramatiques pour le fonctionnement de la partie processeur :

Agrandir l'image pour constater les dégâts.

Dans le cercle bleu, une piste du circuit imprimé correspondant à la connection d'une des pattes du circuit intégré a complètement disparu. D’où l'amélioration constatée lors du premier pontage à l'aide d'un fil de cette patte du circuit vers la broche de sélection de la ROM.
Dans le cercle rouge, un via quasiment dissous par cette substance noire. Le contact avec l'autre face du circuit imprimé et l'autre patte du circuit intégré ne se faisant quasiment plus!

A la place du circuit intégré d'origine, j'ai donc ressoudé un circuit neuf (par précaution) et ai mis en place non plus une connection filaire, mais les deux nécessaires au bon fonctionnement de cette partie logique.

Et puis j'ai remonté la machine en laissant ces fils de la sorte sans même les coller. Inutile, l'ensemble est protégé par la partie mécanique. Depuis lors, ce lecteur CD fonctionne absolument sans problème ce qui me permet de penser avoir détecté et résolu le problème le plus important de ce Cyrus.

Conclusion : une telle construction de machine pouvait peut-être se justifier à l'époque (début des années 90) mais aujourd'hui, cela semble réellement incongru. Financer un temps de développement de carte contrôleur pour optique de lecture CD alors que des bundles mécanique/commande électronique existent. Mais sans doute pas dans un format permettant d'être inséré dans un boitier à la mode Cyrus. Et finalement, c'est la que réside pour moi, une grande partie de l'attrait de l'appareil. C'est du grand art, de l'orfèvrerie électronique qu'il eut été vraiment dommage de laisser partir à la poubelle.

Quelques problèmes de construction ont grevé la durée de vie de l'appareil (la soudure au bain sans doute pas très bien réalisée), mais presque vingt ans de fonctionnement est déjà tout à fait remarquable. Je remarque aussi que ces condensateurs chimiques en version cms sont véritablement une plaie. Ils ont tendance à fuire, surtout comme c'est le cas ici, quand la machine est constamment en fonctionnement.

Parce que question développement durable, ce lecteur n'est vraiment pas top. Le placer en mode veille consiste tout simplement à éteindre l'affichage, et encore, de façon logique. Toute la machine reste en permanence allumée. Aucun relais ou transistor de puissance n'est la pour couper l'alimentation des parties inutiles en mode veille. Se faisant, la durée de vie des condensateurs, composants les plus fragiles, s'en trouve considérablement réduite inutilement. Quant à la facture électrique...

Le Dac Q7 de ce lecteur fourni un son et retranscrit une ambiance très agréable, particulièrement sur du Jazz. La mécanique est silencieuse en fonctionnement. Le vendeur à eu la bonne idée de se procurer une télécommande avant la mise en vente de l'appareil. Je l'ai associé à une alimentation PSX Cyrus acquise pour 50€ en panne. Juste pour le côté esthétique de la chose. L'alimentation interne au lecteur étant largement suffisante.

Et dans la série 'les petites faiblesses du matériel Mission', cette alimentation PSX se mettait en défaut au bout d'un certain temps : le régulateur 5V générant la tension nécessaire à la partie commande de cette alimentation chauffait et finissait par déclencher sa protection thermique interne. J'ai donc changé ce circuit et l'ai coiffé d'un petit radiateur. Depuis tout va bien, même après des jours de veille (parce que cette alimentation, comme le lecteur CD, ne se coupe jamais même en mode veille!!!).

Quant au cout de réparation de ces deux matériels en composants? Une dizaine d'Euros, parce que j'ai changé les gros condensateurs de la partie alimentation du lecteur CD. Par contre, j'y ai passé un certain nombre d'heures justifiant largement les 300 à 400€ d'un DAD3 actuellement fonctionnel.

Du joli matériel reparti pour un bon moment.... Du patrimoine électronique conservé... De la matière grise et des ressources naturelles non gaspillées... Quoi de mieux!