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.