Je cherchais une machine pour y tester un montage que je viens de développer : une SRAM non volatile en mesure de remplacer bon nombre de SRAM sauvegardées par pile ou batterie que l'on trouve dans beaucoup de synthétiseurs numériques des années 80/90. Comme je n'avais pas envie de 'bricoler' sur une machine fonctionnelle et risquer de la détériorer, je cherchais une alternative adéquate. La difficulté réside aujourd'hui dans le fait de trouver une carte à processeur fonctionnant en 5V. Or depuis une dizaine d'année voire plus, l'alimentation en 3,3V est devenue la norme haute d'alimentation des circuits numériques.
 | ||
| Terminal XBT-A70101. |
Le terminal Télémécanique répond à mon besoin en ce sens que toute la partie numérique fonctionne bien en 5V. Et, comble de la chance, ce terminal possède trois circuits mémoire dont deux sur support, l'EPROM du programme et une EEPROM qui devait être destinée à recevoir des 'plugins' par téléchargement. Cette EEPROM sera remplacée par mon montage d’émulation de SRAM non volatile, le support du circuit disposant de tous les signaux nécessaires.
L'idée consiste donc à écrire un programme simple pour le MCS51 dont le rôle sera d'écrire et de lire des données quelconques en mémoire non volatile et d'en vérifier l'intégrité par lecture. Le déroulement des opérations et éventuellement les indications d'erreur s'inscrivant sur l'afficheur intégré au terminal.
A noter que le 'design' de ce terminal est des plus basic en ce qui concerne l'utilisation du processeur MCS51. La ROM programme se trouve en espace ROM, la SRAM se trouve en espace données dans les 32 premiers ko et l'EEPROM, remplacée donc par la SRAM non volatile, dans les 32 derniers ko de l'espace mémoire. L'affichage est géré par un processeur spécialisé recevant ses instructions par liaison série synchrone sur deux signaux émanant des ports P1.0 et P1.1 du processeur. La aussi, que du classique.
Hack de la partie affichage du terminal :
La première tâche consiste donc à décoder les signaux nécessaires au processeur d'affichage. Je me suis servi de l'incontournable Openbench Logic Sniffer de Dangerous Prototype. Cet analyseur logique disponible à prix très bas n'en demeure pas moins un très bon outil d'analyse pour des investigations simples. En ce qui me concerne, et dans le cadre de l'utilisation que j'en ai faite sur le décodage de signaux fortement acycliques, la relative faible capacité mémoire de l'appareil peut cependant poser quelques problèmes d'interprétation. Fort heureusement, je savais à peu près à quelle chronologie de signaux m'attendre, ce qui a grandement facilité l'exploitation des résultats.
 | ||
| Open Bench Logic Sniffer. |
Le terminal est en mesure d'afficher plusieurs types d'informations. De simples messages de 16 caractères de long, fixes, et des messages de type 'warning' avec seulement quelques caractères clignotants, ou d'erreur ou c'est l'ensemble du message qui clignote. Je n'ai pas cherché à discriminer les paramètres de clignotement, la version message entier me convient très bien.
Le message est composé d'un préambule, indiquant le type de message, le corps du message en ASCII standard, et un postambule fixe de valeur 0xBF.
Préambule message normal : 0x87 0x8A 0xB8
Préambule message clignotant : 0xB8 0xC0 0xCF 0xE0
Particularité du point : il doit être suivi de la lettre dans laquelle le point est inséré. Par exemple, un 'A.' sera codé par 0x2E (le point) puis 0x41 (le A). Un point seul sera donc suivi du caractère espace : 0x2E puis 0x20.
Fort de ces informations, j'ai donc utilisé ma carte de développement à base de LPC1114FN28 pour valider ce fonctionnement. La facilité de développement offerte par l'environnement de développement Mbed étant dans ce cas tout à fait appréciable.
 | |
| Carte mère du terminal XBT en cours d'investigation. |
A noter que la carte de développement fournit des signaux en 3,3V alors que la carte XBT dispose d'une partie logique alimentée en 5V. Cela ne pose aucun problème dans ce sens puisque la norme TTL considère un niveau haut à partir de 2,4V.
Les codes 0x29 et 0x28 du troisième message correspondent aux caractères '>' et '<' du terminal. Ils ne correspondent pas aux caractères supposés équivalents du PC, raison pour laquelle ils sont présentés sous forme Hexadécimale. Ils n'appartiennent donc pas au préambule ni au postambule du message. La variable 'myplus' correspond à une patte du processeur placée à '1' permettant par l'utilisation d'un bouton poussoir dont l'état est lue par la variable Next, l'avancement de certaines phases du programme lors des tests préliminaires.
Même travail avec le processeur MCS51 embarqué :
Il s'agit de développer de façon adaptée sur du matériel 'vintage'. Pour ceux qui n'auraient pas connu la 'belle époque', il est temps de ressortir l'émulateur d'Eprom, l'effaceur d'UVPROM et le programmateur de 27CXXX...
Un aperçu de ce à quoi ressemble le système de développement :
Pour ce qui est du développement logiciel, j'ai choisi la facilité. Tout d'abord l'IDE Eclipse, il s'agit ici de la version Kepler, téléchargée début juin 2014. En suite, le compilateur 'C' choisi est l'indispensable SDCC, ici en version 3.4.0 RC1 en date du 15 mars 2014. Enfin, afin qu'Eclipse 'comprenne' qu'il doit générer du code en utilisant les outils SDCC, il est nécessaire d'installer le package 'eclipseSDCC Plug-in'. Tous ces outils se trouvent sans problèmes sur le Net.
Note importante pour ceux qui souhaiteraient s'essayer au développement sur MCS51 :
Le plug-in SDCC pour Eclipse semble dater suffisamment pour poser des problèmes lors de tentatives de compilation sous Windows 7, dans mon cas en version 32 bits. Après d'intenses recherches, il s'avère que le coupable est l'interpréteur de commande à la mode Unix : 'sh'. Cet interpéteur se trouve à cet endroit : ..\eclipse\plugins\net.sourceforge.eclipsesdcc.win32_1.0.0\os\win32\x86.
La raison est un plantage plus ou moins aléatoire dans le 'fork' que 'sh' effectue pour appeler les différents exécutables SDCC lors d'une demande de compilation émanant d'Eclipse.
Une solution simple consiste à installer un 'sh' récent en lieu et place de celui d'origine. Pour ce faire, j'ai installé le système Cygwin puis copié l'exécutable 'bash' dans le répertoire contenant le 'sh' d'origine. J'ai renommer 'bash' en 'sh' puis lancé cet exécutable afin de copier aussi les DLL nécessaires jusqu'à ce que l'exécutable n'en demande plus.
Deux ou trois autres détails permettant de faire fonctionner ce système :
- Sous Eclipse, modifier le nom de l'assembleur qui ne correspond pas au nom de l'exécutable fourni avec SDCC. Remplacer cette information par 'sdas8051'.
- Pour ne pas avoir les messages de warning continus sur le mode d'écriture des paths lors de la compilation, dans la console, créer la variable système 'CYGWIN' et lui affecter la valeur 'nodosfilewarning'.
- Enfin, démarrer Eclipse en mode administrateur.
Il resterait quelques détails à régler mais je n'y accorde aucune importance, j'utilise en effet les informations de compilation de SDCC disponibles dans la console d'Eclipse et non pas les indications du parser propre à d'Eclipse.
Bien que paraissant peut-être compliquée, une fois en place, cette solution permet de produire un fichier '*.hex' très rapidement qu'il suffit de copier dans l'émulateur d'EPROM.
En guise de premier test, j'ai repris le code d'exemple précédemment réalisé sur la carte LPC1114 à l'aide du compilateur en ligne Mbed, et l'ai recopié presque tel quel dans l'IDE Eclipse. La seule différence tient au fait que j'ai du recréer de façon artificielle le bus SPI à l'aide d'instructions de manipulation de bits et de temporisations adéquates sur les ports P1.0 et P1.1 du processeur.
Et le résultat :
 |
| En luminosité tamisée pour un meilleur affichage... |
