Travaux de vacances...

La période estivale est souvent mise à profit pour effectuer quelques travaux domestiques. Pour ceux qui comme moi se passionnent pour l'électronique, un certain 'entassement' de matériels divers et de réalisations variées peut, au fil des ans, finir par encombrer certains espaces... vitaux.

Une chasse à l'inutile, au superflu, à l'irréparable, en un mot à l'inutilisable s'engage alors. Cela n'empêche que, motivé à l'extrême par l'envie de 'clarifier' certains endroits, il est toujours possible de tomber sur un truc dont il semble difficile de se débarrasser avant, au moins, de l'avoir testé.

'Home made' avec les moyens de l'époque, en 2001.

C'est le cas de cette carte à micro-contrôleur DS87C520. L'objectif de ce projet avait été de créer une carte programmable en MCS BASIC-52. Pour rappel, le Basic 52 était le 'fameux' interpréteur Basic qu'Intel avait créé dans les années 80 pour son micro-contrôleur 8052. Je ne vais pas en rajouter sur le sujet, le Net regorge d'informations à ce sujet.

Pourquoi parler de ce 'vieux' truc ici? Et bien parce que ce vieux truc n'est pas si obsolète que ça finalement. En effet, sur la carte en question, on peut constater qu'il ne s'agit pas d'un contrôleur Intel mais d'une version plus musclée fabriquée par feu Dallas, repris depuis par Maxim. La particularité de cette version est d'une part de posséder un cœur compatible 8052 mais amélioré en ce sens qu'environ un tiers de cycles d'horloges est nécessaire pour effectuer les même opérations que le cœur 8052 d'origine. D'autre part, la fréquence d'horloge est passée de moins de 12MHz à 33MHz. Le résultat est une vitesse d'exécution d'environ 10 fois supérieur au circuit d'origine.

Autre particularité, cette version Dallas possède aussi 1K octets de RAM interne ce qui, si la possibilité de programmation de la ROM interne avait été utilisée, aurait permis d'avoir une machine complète en un seul circuit.

Cela n'est pas ce qui a été implémenté sur cette carte puisque la ROM de l'interpréteur Basic est externe. Par contre, j'avais aussi implémenté un port parallèle de type 8255, fournissant jusqu'à 24 ports d'entrées/sorties.

Bien évidemment, j'avais du modifier quelque peu le Basic d'origine pour, d'une part adapter la détection automatique de la vitesse de la liaison série, et d'autre part valider le fonctionnement de la RAM interne.

Ayant par ailleurs récemment développé un petite carte de développement à base de processeur Microchip, programmée avec le superbe interpréteur Basic de Geoff Graham, j'ai donc décidé de faire exécuter le simplissime programme de test afin de comparer la vitesse d'exécution avec le processeur Microchip.

Carte Micromite réalisée avec les moyens de... 2015!

Et je dois dire que je n'ai pas été déçu. A 33Mhz, le processeur DS87C520 est capable d'effectuer le comptage de 0 à 100 000 en 75 secondes. Pour rappel, le processeur Microchip équipé de la dernière version de l'interpréteur Basic effectue ce test en 11 secondes. Le 'fameux' PC1500 de sharp, en 3000 Secondes.

Ce qu'il faudrait à ce Pocket, c'est quand même un processeur plus puissant!

Le plus inattendu maintenant : je n'ai pas pu m'empêcher de 'tenter' un quartz plus rapide sur ce DS87C520. Un quartz de 48Mhz m'a donné un temps d'exécution de 50 secondes au mieux, parfois plus. Il semblerait donc que le processeur ait bien fonctionné en interne à 48Mhz puisque j'obtiens en gros 45% de temps d'exécution en moins pour... 45% de fréquence quartz en plus!

A remarquer que pour faire ce test, j'ai largement outrepassé la fréquence maximale de fonctionnement garantie par le fabricant du processeur. Je n'ai pas non plus changé les condensateurs de filtrage des harmoniques. Ne parlons pas du blindage de la section quartz de la carte ni du temps d'accès minimum de la ROM, pipe-line oblige!

Ceci pour en arriver à la constatation que je ne suis 'que' 4,5 fois plus lent que le processeur Microchip mais quand même 60 fois plus rapide que le Sharp PC1500. Pas mal, non?

Oui, bien, et alors?

J'affectionne particulièrement la programmation en Basic parce que c'est simple. Comprendre qu'avec une idée en tête et un système suffisamment rapide, il est très facile de réaliser une tâche matérielle sans gaspiller de temps avec une foultitude de problèmes non liés DIRECTEMENT au problème à résoudre. Si vous me lisez régulièrement vous aurez deviné ou je veux en venir...

Dans les années 80, bon nombre de fonctions ont été gérées par ce type de système à micro-contrôleur et Basic intégré. Durant les années 90, le basculement sur des machines plus puissantes s'est effectué. Cela semblait une bonne idée. Avec ces nouvelles machines il devenait possible de programmer en 'langage évolué' tout en profitant d'une bonne puissance et de la disponibilité d'un système de fichier, voir d'embryon de réseau. Un bon PC équipé de MS-DOS et d'un compilateur Pascal (Borland de préférence) faisait parfaitement l'affaire, même si la structure en personnel devait suivre et s'étoffer quelque peu. Mais cela restait gérable.

Ah, ce bon vieux Deskpro...

Et puis vinrent Windows et le gouffre en ressources personnel. Ou comment faire en sorte qu'à peine 10% du temps de programmation ne soit réellement affecté à la résolution directe du problème posé. Le reste, perdu dans les arcanes de la surabondance de documentation inutile, de problème d'incompatibilités, de drivers, de type de système d'exploitation incompatibles les uns avec les autres, de langage de programmation, de framework. etc etc...

Langages C, C++, C#, C.net, Windows 1.0, Windows 95, Windows me, Windows Vista (le plus mieux de tous), Windows 8 pour les versions les plus insupportables, les versions NT, pas compatibles avec les autres etc etc etc...

Qui ne se souviendra pas avec plus ou moins de nostalgie de ses tentatives d'utilisation d'un port de communication série sous Windows, susceptible de fonctionner sous toutes les versions de Windows de l'époque!

Débrouille-toi avec ça!

Avec comme souvent suite à ces problèmes, la nécessité de  :

Peut-être la solution ultime!

Et la LED que je dois faire clignoter dans tout ça? Hum....

Bref, toute une industrie de la programmation 'artisanale' dans le bon sens du terme a donc fini par disparaître au milieu des années 90 pour le plus grand bonheur des actionnaires de Microsoft!

J'ai fabriqué ma carte compatible 8052 en 2001, 15 ans plus tard je rebranche le système et suis toujours en mesure de la programmer avec un simple terminal, fût-il sous Linux! Et ça pourrait durer encore comme ça un bon nombre d'années....

Les perspectives? Que manque-t-il à une telle carte pour être 'up to date'? Et bien pas grand chose. Il existe sur le Net des implémentation de systèmes de fichier sur carte SD. Les ports séries permettent de se connecter à un serveur léger élaboré autour d'une RaspBerry par exemple. Ce qui manquerait le plus en fait, c'est le système de sauvegarde de la mémoire programme et DATA, si le système doit collecter des informations.
Une majorité de ces systèmes étaient équipés de SRAM sauvegardées par pile. Évidemment, au bout de 10 ans, il est fort à parier qu'ils ne sont plus en mesure de supporter quelque coupure de courant que ce soit!

Des solutions existent comme des mémoires non volatiles qui se comportent de la même façon que des SRAM, voir mes système de remplacement de SRAM sauvegardées par pile.

De plus il existe des fabricants qui proposent toujours ces circuits de type 8052, 8032, 8051 ou 8031 avec des cœurs encore plus rapides. Je viens de découvrir la nouvelle série de processeur EFM8 de Silicon Labs. Certains de leur modèles sont capables de fonctionner à 50Mhz avec un cœur cette fois, en mesure d'exécuter une majorité d'instruction en seulement deux cycles d'horloge!

Il s'agit d'une vitesse apparente, parce qu'en réalité le processeur fonctionne bien moins vite mais le 'pipe-linage' permet d'arriver à cette apparence de vitesse d'exécution. Ce qui permet à ces processeur de consommer très peu. Il est bien tentant de tester ce type de produit.

J'oubliais, pour ceux qui souhaiteraient programmer ces circuits de type 805x et 803x en assembleur, ils sont très simples à utiliser...

Thermostat d'ambiance : ATmega168pb devient ATmega328...

Hum, quel lien entre la version 168 et 328 de l'ATmega et un thermostat?

Rappel des épisodes précédents :

• Tout commença par l'utilisation d'un kit de découverte de l'ATmega168pb vendu quelques Euros.
• Puis, vint l'idée de réaliser quelque chose de sympa avec cette petite bête. Pourquoi pas un petit thermostat?
• Les bases de l'application jetées il était temps de passer à la réalisation d'un premier prototype.
• Puis celui de son montage avec le relevé de quelques erreurs de conceptions sans conséquences pour un prototype.
• Le sujet de ce billet? Les premiers signes de vie de l'objet...

Restons modestes, pas question ici de concurrencer ce type d'appareils fabriqués par exemple par Momit. 

Publicité gratuite ;-)

Ici, pas de wifi, pas de réglage avec sa tablette (quoi-que le système étant ouvert, tout reste possible), par contre, une commande par deux fils uniquement, vers un récepteur placé à proximité de la chaudière, donc simple d'installation. Une commande par boutons dédiés qui 'devrait' permettre une utilisation sans besoin de notice à proximité...

Comme je l'ai évoqué dans un des articles précédents, le processeur ATmega168 est très bien, sauf qu'il ne possède quand même pas énormément de mémoire programme. Je me suis rendu compte lors des différents tests avant prototype que la librairie graphique occupait une place assez importante, susceptible de me poser des problèmes par la suite. Je suis donc passé au processeur au dessus, le 328. La compatibilité entre ces différentes versions de processeur est telle qu'il m'a suffit d'en changer le type dans le logiciel Studio 6 puis de re-compiler mes tests originaux pour en valider le fonctionnement sur la carte prototype.

Par contre, pour développer sans la carte 168pb Xplained mini, il est nécessaire de disposer d'un programmateur matériel permettant de charger le programme dans le processeur.

En ce qui me concerne, je n'ai rien acheté de spécial. Je disposais déjà d'un petit programmateur "mySmartUSB light" de myAVR disponible au prix exorbitant de 15,95€TTC (hors frais de port).

Encore de la publicité gratuite!

Ce type d'appareil ne peut pas prétendre fournir les mêmes fonctionnalités que les programmateurs fabriqués par Atmel. En particulier il n'est pas possible d'effectuer de session de débogage. La compatibilité STK500 ne permet pas non plus de 'remonter' la tension de fonctionnement du processeur. 

Ces petits inconvénients ne gênent 'pratiquement' pas le développement. En effet, la plupart des routines potentiellement gênantes ont déjà été programmée et déboguées avec la carte de découverte Atmel, notamment la gestion du bus I2C. Concernant l'absence de remontée de la tension du processeur, l'annulation du message fourni par la partie logicielle permet de continuer normalement l'upload du fichier exécutable dans le processeur.

Tout au plus le développement global est un peu moins pratique qu'avec un vrai débogueur matériel mais cela n'empêche absolument pas d'avancer, et d'autres moyens existent pour 'fliquer' ce qui se passe dans un programme....

Concernant les 'aides' matérielles dont il est 'relativement facile' de disposer pour mettre au point les parties logicielles, et notamment ce qui concerne le bus I2C, j'ai utilisé 'un oscilloscope de marque Rigol DS2072 disposant de la gestion du décodage I2C pour les tests préliminaires. Appareil pas très cher à l'achat et apte à rendre de bons services : 

Oui, je sais, encore de la publicité gratuite!

Il m'a permi non seulement de valider l'exactitude des informations envoyées et reçues, mais aussi l'état des signaux. Par la suite, j'ai utilisé un analyseur logique 'Logic Cube' de Zeroplus, lui aussi disponible à un prix 'amateur' qui, bien que ne travaillant que sur des signaux logiques, et donc incapable de visualiser la vraie forme des signaux, permet cependant de décoder un nombre sensiblement plus important de protocoles : 

Et ça recommence, je vais finir par demander des indemnités....

Cet appareil permet un affichage très pratique des échanges véhiculés sur le bus I2C. 

En voici un exemple : 

Conversation avec le capteur de température/hygrométrie avec un octet de trop demandé, pour voir...

En voilà terminé avec la partie matérielle qui m'a permis d'effectuer mes différents tests.

Concernant la partie logicielle, je dois citer le travail fourni par Adafruit Industrie concernant le portage de la bibliothèque graphique sur le circuit utilisé par le petit afficheur graphique. Il ne m'a fallu que quelques adaptations d'écriture pour coller au mieux avec la structure employée dans le développement de l'application générale.

Tout ceci pour un premier résultat des plus encourageant : 

En compagnie d'une précédente réalisation pour comparaison.

Deux remarques : 

• Sur le montage de droite, il a été utilisé des composants de grande précision. Les différences de valeurs mesurées sont uniquement dues au fait que le capteur du thermostat ne se situe pas au même endroit que sur le montage de droite.
• Le capteur utilisé sur le thermostat est de marque Honeywell et de type HIH6000. La particularité de ce capteur est une grande réactivité, notamment en ce qui concerne l'hygrométrie. Il s'avère bien plus réactif que le circuit de type SHT11 de Sensirion, pour une précision qui me semble assez identique et un prix bien moindre.

Il reste encore du travail de programmation à effectuer, notamment l'intégration du capteur de CO², la communication série et enfin l'application générale de contrôle...

Carte de développement pour le système Micromite MKII.

En matière de programmation, il existe une multitude de langages disponibles. Suivant le matériel sur lequel devra s'effectuer le programmation, seuls certains d'entre eux seront disponibles. En effet, les ressources matérielles mais surtout systèmes, nécessaires à l'exécution d'un programme, peuvent être du tout au tout différentes.

Pour programmer un matériel simple, typiquement un petit processeur ou plus généralement un micro-contrôleur, il est possible de distinguer deux grands type de langages. Ceux nécessitant la présence d'un système d'exploitation, et les autres. Un langage interprété comme Phython par exemple ne fonctionne que sous environnement Linux (en général) et exploite largement les ressources fournies par ce système. Ce type de langage n'est donc pas imaginable sur un système simple.

Par contre, il existe d'autres langages dits évoluées qui permettent la programmation d'un tout petit système. Pascal, C/C++, Basic et autres du même type sont parfaitement adaptés à cet usage. Dans cette catégorie de langages, il est encore possible de différencier les langages compilés et les langages interprétés.

Un langage compilé sera en fait interprété une fois par un programme particulier, le compilateur, qui produira un fichier exécutable qui devra être écrit dans le petit système. Dans ce cas, le compilateur est exécuté sur une machine différente que celle sur laquelle devra s'exécuter le fichier exécutable.

Un langage interprété consiste en fait en un programme qui lit constamment des lignes de code et en exécute les instructions. C'est le cas du Basic, donc de l'interpréteur Basic. Ce type de solution peu paraître inefficace car même dans une boucle exécutant mille fois la même chose, l'interpréteur exécutera mille fois le décodage et l'exécution des mêmes instructions.

Le Basic Microsoft, omniprésent dans les années 80

Relativisons, même s'il semble évident qu'un programme écrit en Basic s'exécutera bien moins rapidement qu'un programme compilé, les ressources disponibles aujourd'hui permettent de ne pas trop avoir à se soucier de cet aspect des choses. D'une part on ne demandera jamais à un petit système à processeur de gérer des fichiers ou d'effectuer du traitement de signal comme peuvent le faire les 'gros' processeurs et les PC.

De plus, certains 'artifices' permettent d'augmenter artificiellement la vitesse d'exécution d'un programme écrit en Basic. Le procédé est simple, il suffit d'écrire dans un langage compilé, donc plus rapide, des bouts de codes particuliers et de les exécuter en les appelant depuis un programme écrit en Basic.

C'est exactement ce qu'est capable de faire l'interpréteur Basic Micromite MKII écrit par Geoff Graham.

Encore mieux, cet interpréteur laisse la possibilité à l'utilisateur, s'il maitrise bien la programmation en langage 'C' par exemple, de créer ses propres bouts de programmes compilés, de les insérer et de les exécuter dans un programme Basic. Si l'on rajoute à cela que l'interpréteur Basic dont il est question fonctionne sur un processeur rapide fonctionnant à quelques 50Mhz, on se retrouve assez éloigné des faibles performances des machines programmables en Basic des années 80 dont certaines ne fonctionnaient même pas à 1Mhz. Et pourtant, de belles choses furent réalisées avec ces anciennes machines comme avec le Commodore 64 et son Basic intégré, équipé d'un processeur 8 bits fonctionnant à 1,023Mhz :

Un des ordinateur de l'époque les plus vendu au monde!

J'ai déjà eu l'occasion de comparer la vitesse d'exécution du Basic de Geoff Graham avec celle de l'interpréteur présent dans le fameux PC1500 de Sharp. J'arrive à un rapport de 200! Pour fixer les idées, Micromite MKII exécute en 1 seconde, ce qui demande un temps de plus de 3 minutes au PC1500!

Le vénérable PC1500A de sharp

De plus, Micromite MKII fournit une interface complète et bien pensée pour divers composants électroniques comme des horloges temps réél, des décodeurs de télécommande infra-rouge etc etc...
Il devient alors très facile avec ce système, d'écrire des applications sophistiquées et faciles à maintenir, sous réserve toutefois que le programme ait été bien écrit et facile à comprendre.

Que dire des capacités? 80 Koctets sont disponibles en flash pour l'écriture des programmes ainsi que 52 Koctets en RAM pour les variables basic, soit environ 130 Koctets au total!. Evidemment à côté des gigas octets de mémoire dont sont équipés aujourd'hui nos PC, cela semble bien ridicule. Ne pas perdre de vue que la finalité du système n'est pas du tout la même. Allumer une ampoule avec un bouton ne requiert que quelques octets sur Micromite MKII, mais requiert des mégas octets sur un PC!
Le prix n'est pas le même non plus. Quelques dizaines d'Euros pour un système confortable basé sur Micromite MKII, des centaines d'Euros pour un PC, voire des milliers pour un Mac!

Et tout cela, dans ceci, pour quelques Euros :

Pour beaucoup de programmeurs, Basic est largement dépassé. A mon sens, cela ne veut strictement rien dire. D'un point de vue technique tout d'abord, un petit système programmable dans ce langage permet de réaliser très rapidement des applications fiables. Null besoin de posséder de grosses compétences en C#, en framework, en OS, et de posséder une grosse équipe de programmeur pour réussir, après des mois d'efforts et des dizaines de milliers d'Euros dépensés, à programmer une application somme toute tout juste à peu près convenable! Ensuite d'un point de vue plus philosophique, avec un tel système Basic, une seule personne peut être en mesure de réaliser de petites applications performantes en un minimum de temps et pour un cout minimum tout en restant totalement autonome sur les ressources et donc affranchi des contraintes de droit, de redevance, d'obligation de quoi que ce soit envers qui que ce soit. Seules, la compétence, l'autonomie et l'inventivité du programmeur, de la programmeuse, deviennent importantes.

Il semblerait d'ailleurs que Microsoft, qui après s'être nourri, devrais-je dire gavé, dans les années 80 de l'essor de la micro-informatique avec son Basic, et aillant contribué dès les années 90 à exploser le milieu pour tenter d'en devenir le seul maitre à bord, ait commencé à comprendre la situation actuelle ou de nouvelles compétences se développent, de nouveaux réseaux se montent, de nouvelles applications naissent, totalement en dehors de son contrôle. D'ou la très grosse opération actuelle de racolage tout azimut dans le petit monde de l'embarqué envers ceux qui étaient considérés il n'y à encore pas longtemps, comme des amateurs sans intérêt.

Incroyable non? Est-il vraiment aussi abordable que les premiers Basics?

N'adoptez JAMAIS les produits Microsoft! Le seul but de Microsoft est aujourd'hui de tenter de reprendre le contrôle des nouveaux écosystèmes naissants. Ne vous laissez pas faire. Microsoft ré-itérera ce qui s'est passé dans les années 90. Dès que vous serez pieds et poings liés avec lui, il vous explosera!!! Il n'a jamais été question pour cette entreprise de considérer un contrat gagnant/gagnant. C'est vous qui travaillez, c'est eux qui encaissent! J'ai à plusieurs reprise fait état de cette attitude désastreuse de Microsoft dans mon Blog... Je devrais aussi ajouter qu'il est nécessaire de se méfier de l'Education National, qui, loin de générer de l'autonomie en interne sur le sujet de l'informatique, se contente souvent de suivre la mode et la facilité en adoptant les ressources fournies 'gracieusement' par différents type de sociétés comme Microsoft!

Si vous souhaitez faire de l'informatique, veillez scrupuleusement à votre autonomie, cultivez VOS compétences, et ajoutez-y VOTRE façon de voire la chose!

C'est dans cet esprit que Geoff Graham a créé son superbe Basic! Je considère qu'il était presque de mon devoir, d'une part de l'utiliser, d'autre part d'en faire ici la 'publicité'!

Bien que toutes les informations nécessaires soient disponibles sur le site de Geoff, le montage d'un système minimal peut s'avérer un peu compliqué quand on ne possède absolument aucune compétence ne serait-ce que minimum en montage électronique. Il n'était pas question cependant de proposer une machine du type de celles disponibles dans les années 80 comme le commodore 64 précédemment cité, mais plutôt une carte d'étude se prêtant bien à de multiples expérimentations, facile à utiliser et peu onéreuse. Voici donc la carte que j'ai développé spécialement pour ce système Basic :

Le système, prêt a fonctionner.

Le processeur possède déjà l'interpréteur Basic. Il m'a été possible d'écrire le fichier programme de cet interpréteur dans le processeur après l'avoir téléchargé du site de Geoff puis transféré à l'aide de l'outil Pickit 3 de Microchip :

J'ai en effet implémenté sur la carte de développement, le connecteur permettant d'y raccorder le programmateur d'une façon simple et efficace. De ce fait, il sera possible à tout moment de reprogrammer le processeur avec une nouvelle version de l'interpréteur Basic. Il peut en effet arriver qu'un bug apparaisse au fil du temps, qui mérite correction, ou que l'ajout éventuelle de nouvelles fonctionnalités rende intéressante la mise à jour du processeur.

Configuration pour la programmation du firmware Basic

L'utilisation du programmateur Pickit 3 est simplifiée grâce au logiciel disponible en téléchargement sur le site de Microchip, le fabriquant du processeur. Bien que l'opération de programmation du processeur ne soit pas très compliquée, elle impose tout de même l'installation du logiciel Microchip,  MplabX,  sur un PC qui devra être assez moderne et fonctionner sous Windows. A titre indicatif, voici les opérations à suivre pour reprogrammer le processeur avec le fichier Micromite :

1- Dans la page principale du logiciel MplabX, demander l'importation d'un fichier hexadécimal :

2 - Une fenêtre apparaît alors ou il est nécessaire de renseigner l'endroit ou le fichier hexadécimal a été sauvegardé, ainsi que le type de processeur et de programmateur utilisé :

Le processeur est un PIC32MX170F256B.
Le programmateur est le PICkit3

3- Après validation de la fenêtre précédente, le logiciel revient sur sa page principale en affichant certaines informations :

A gauche, le logiciel à bien accepté le fichier ainsi que le type de processeur configuré.
En haut, l'icône de programmation vers le processeur est devenue active.

4- C'est sur cette icône qu'il faut cliquer pour lancer le processus de programmation. Ce processus démarre alors en faisant apparaître les différentes 'sortie' d'affichage du programme. J'ai agrandi vers le haut cette partie pour rendre lisible un maximum d'informations sur le processus de programmation :

J'ai sélectionné la 'tab' PICkit 3 pour suivre le déroulement du processus avec le programmateur. Tout semble bien se passer...

Au bout d'un certain temps, la programmation s'est effectuée :

5 - Il ne reste plus qu'à tester le système. Pour cela il faut retirer le programmateur PICkit 3 et appuyer sur le bouton RESET après avoir démarré un émulateur de terminal sur le PC, configuré sur le bon port de COM à 38400 baud. Le message suivant apparaît alors :

Pas de doute, le système fonctionne!

6- Il ne reste plus qu'à tester l'interpréteur Basic en tapant exactement l'exemple fourni dans la documentation du système :

Et la LED que j'ai installé à cet effet sur la carte de développement se met à clignoter.

Simple? Effectivement. Et maintenant, les ressource de ce Basic et de ce processeur étant assez complète, il ne reste plus qu'à envisager des application et à les développer, tout simplement!

Des remarques ou des suggestions :

ATmega168pb : la réalisation.

Après avoir publié quelques articles sur le processeur ATmega168pb de chez Atmel, et notamment le début de projet de création d'un thermostat un peu particulier, voici enfin le 'vrai' début de la réalisation concrète de l'appareil :

Le coté utilisateur.

L'envers du décor.

Voici donc le prototype du thermostat en cours d'étude. Sur la 'face avant', l'affichage trône en bonne place alors que l'on retrouve sur l'autre face, l'ensemble des composants précédemment testés, a savoir le processeur, le modem, le capteur de température et d'hygrométrie plus un superbe module de détection de CO2 de marque Senseair.

Pour élaborer cette carte, ainsi que toutes celles que je présente dans ce blog, j'utilise le logiciel gratuit et très facile d'accès : Kicad. Logiciel qui devrait être téléchargeable a cette adresse : www.kicad-pcb.org.

Je n'ai pas testé ce logiciel sur le PC équipé d'un Pentium III a 800Mhz et Windows 2000 que j'ai récupéré récemment, mais quelque chose me dit que cela devrait fonctionner étant donné que Kicad utilise des ressources de programmation libres. Un test que je me dois d'effectuer.

Un gros travail de programmation reste maintenant a effectuer sur cet appareil, en supposant qu'aucune erreur n'ait été commise lors du processus de développement et d'assemblage de la carte!

Pour une fois, je peux dire que la période des vacances tombe mal! Les projets en cours risquent de marquer un temps d'arrêt durant cette période, propice néanmoins au repos et a la réflexion...

How to upgrade the programm memory of the prophet VS...

Like many devices of the late 80s, the parameters memory was often backuped by an internal battery. It is the case of the Prophet VS synthesizer. The 'patch memory', plus some of the internal parameters site in a couple of a static ram electricaly backuped by a lithium battery.

But after many years, the capacity of the battery become insufficient to ensure a proper backup of the SRAM when the Prophet VS is powered off. Worse, when the lithium battery is very 'out of date', it is possible to observe a leak of acid liquid witch spreads off the circuit board. It could be really catastrophic for the printed board.

So, since a few month, I create nonvolatile memory replacement for the standard SRAM in 2, 8, 16 or 32 Kbytes.
I decided to create a special edition for the Prohet VS. Special because I had to respect a protection against the potentially corruption of the data by writing wrong values at wrong addresses at the power on of the synthesizer. I had to create a special circuit board for that and replace the original SRAM with the new nonvolatile SRAM.

First, the main board of the prophet VS :

A very classical 68000 board!

As you can see, there are the two backuped SRAMs between the two ROMs. The first operation was to remove them :

Without SRAMs and without the battery.

Then, I also remove the internal battery. The next step was to place two supports for the new nonvolatile SRAM, then to put them into the supports like this :

A main board up to date !

As you can see, not only the two nonvolatile SRAM are in place, but the battery space in now empty. Furthermore, you can observe tiny connectors on the two nonvolatile SRAM.
No! You don't dream, this connectors will allow you to select ONE of the FOUR bank now availables!!!
Yes, it is possible because the original SRAM are 8 Kbytes capacity, but the new one have a 32 Kbytes capacity.

And the result :

One more improvement!

• No more battery.
• 400 programm capacity, into nonvolatile SRAM.
• Two ELD5530, my CEM5530 replacement.

If it continues I will rebuild this Prophet VS by myself !!!

And, does it work? Yes, of course!

I have to reload my patches into one of the four ram bank, and to find a solution to select the four banks now availables. I don't have decided yet how to do that. I want to conserve the original look of my VS, so perhaps a kind of 'programmer' like the PG200 of the JX3P...

Impossible de résister au plaisir...

Mise en situation : je possède depuis quelques semaines un lecteur de bandes audio de type K7 de marque Luxman, modèle K250. Cette machine m'a été donnée lors d'un 'vide grenier' :

http://archiwumallegro.pl

Il ne s'agit pas ici de la machine en ma possession, mais d'une image récupérée sur le web. La mienne est en meilleur état cosmétique mais présente une panne un tantinet gênante.

Le compteur numérique ne fonctionne plus. Dans le cadre d'une utilisation standard cela ne doit pas poser de problème. En fait, si. Et même un gros problème! C'est aussi ce compteur qui gère l'arrêt de défilement de la bande, dans quelque mode que ce soit, dans les deux sens.

Et lorsque cette fonctionnalité disparait, et bien la machine ne s'arrête plus. Et le moteur, bien que la mécanique soit bloquée a cause de la butée de fin de bande, continue de tourner. La courroie de transmission fini par se détendre dans un premier temps puis, lorsque la tension de celle-ci n'est plus suffisante, l'axe du moteur fini par tourner dans cette courroie immobile jusqu'à l'user, puis la casser.
Ne reste alors plus que la partie cabestan qui fonctionne, ce qui a pour effet de 'bourrer' le tiroir de bande sortie de la cassette et non embobinée a l'intérieur pour cause d'absence de bobinage ou de rembobinage.

Se faisant, la platine cassette ne fait plus du tout défiler la bande : 'game over' !

La première étape a donc consisté a remettre une courroie de défilement en place. Ce qui fut fait facilement:

La nouvelle courroie de défilement est la plus petite.

La mécanique une fois remontée :

Rien de bien compliqué.

Ceci étant, j'ai quand même du passer un certain temps a 'dépoussiérer' cette mécanique car elle pressentait une grosse quantité de particules de caoutchouc en provenance de l'ancienne courroie dégradée.

Et maintenant? Le lecteur fonctionne parfaitement et procure un son tout a fait agréable et défini. Mais la mécanique ne s'arrête toujours pas toute seule! Il convient donc de refabriquer ce compteur parce que le circuit intégré qui gère cette fonction est introuvable sur le net, pas plus d'ailleurs, qu'une platine K250 en occasion!

Est-il intéressant de s'acharner sur une telle machine?  Si l'on considère le seul point de vue financier, non, bien évidemment. Cependant, ce point de vue me semble... un peu court!

D'une pat la machine est totalement fonctionnelle et procure une sonorité tout a fait digne d'intérêt. Elle est bien construite, même si le circuit imprimé n'est pas en époxy. Elle est équipée de trois têtes permettant de faire du monitoring. Elle a été bichonnée par son ancien propriétaire hélas aujourd'hui disparu. Plus un ensemble d'autres raisons suffisantes pour s'attaquer au problème, comme le simple 'challenge' consistant a redonner une nouvelle vie a un matériel passé de mode, certes, mais absolument pas obsolète!

Et voila un 'exercice de style' tout a fait trouvé pour la nouvelle carte de développement a processeur Zilog que je viens de développer. Je détaillerai plus tard tout le processus de création de ce compteur électronique a affichage fluorescent, lorsqu'il sera monté dans la machine.

Mais pour l'heure je ne peux résister a l'envie de présenter une petite démo. du 'proof of concept' du sujet :

Vidéo effectuée en basse lumière pour que les segments du tube soient visibles. Le programme du processeur se contente d'effectuer une boucle envoyant en série des données a un circuit prévu pour 'driver' des 'hautes' tensions. Un seul des trois digits est câblé.

Deux heures, temps de câblage et temps de programmation, pour arriver a ce résultat. Il est vrai que je n'avais pas programmé de microcontroleur Zilog depuis presque une dizaine d'années : quelle erreur d'avoir abandonné ces circuits...

Prophet VS, mais pas que...

Ou, des ces pannes que l'on 'refuse' inconsciemment de prendre en compte!

Outre un Prophet VS, je possède aussi un studio440. Machine fantastique de l'époque, qui conserve encore aujourd'hui toutes ses qualités ou défauts, a l'instar d'une quantisation en 12 bits linéaires.

Dans cette machine, on retrouve toute la technologie de Sequential Circuit de l'époque, présente elle aussi, a l'intérieur du Prophet VS.

C'est une machine qui sonne et qui demeure, comme la SP12 d'EMU, toujours très prisée des producteur de hip hop par exemple. Je les comprends!

Et un incroyable look Vintage!

Or donc, outre une multitude de problèmes présents dans cette machine comme dans mon Prophet VS, comme j'imagine pour la majorité des productions de Sequential Circuit de l'Époque, celle-ci refuse (refusait) obstinément de gérer un disque externe SCSI.

Petite digression sur le matériel Sequential de l'époque :  de très bonnes idées, une bonne ergonomie, mais une approximation parfois déroutante dans le travail d'ingénierie, et surtout une réalisation assez médiocre et éloignée des standards industriels, même vis a vis de ceux de l'époque. Il ne me semble donc pas étrange que l'entreprise Sequential ait eu à ce moment-la d'énormes difficultés face aux productions nippones et ait fini par fermer les portes, juste pendant la mise en production du Prophet 3000. Prophet 3000 que je possède aussi et pour lequel j'ai réalisé un gros travail de correction mais qui demande encore à être complété. ...D'ou un très gros problème de fiabilité de ces matériels, problème qui a tendance a augmenter avec les années. Maintenir ces appareils en parfait état de fonctionnement  réclame une bonne dose d'humour, de patience et d'investigation!

Après avoir effectué une bonne série de tests, il m'était toujours impossible de faire reconnaitre le disque SCSI externe. Alors que j'y suis parvenu sur un autre Studio 440 pratiquement fonctionnel mais en moins bon état esthétique. Sur cette machine, donc, j'avais déjà constaté par le passé que l'alimentation 5V de la partie numérique était un peu... faiblarde. Mais bon, elle semblait fonctionner sans problème sous 4,6V, mis a part la gestion du SCSI.

Après de nouvelles investigations, je constate que la sortie d'alimentation, bien que présentant un potentiel de 5V, ne me permet d'obtenir QUE 4,6V sur l'entrée de la carte numérique. Comment ais-je pu passer a coté de ce phénomène!

Entre l'alimentation et la carte numérique : deux conducteurs et un connecteur. Les soudures sur la carte numérique étant bien réalisées, les fils d'alimentation étant de bonne section, il ne restait plus qu'a incriminer le connecteur. La mise en place d'une connectique initialement prévue pour les lecteurs de disquette 3 pouces 1/2 ne fera que confirmer mon diagnostic ;

La pose de ce nouveau câble d'alimentation permet en outre, d'ouvrir plus facilement la machine puisque l'ancienne liaison, trop courte, tirait sur le connecteur d'alimentation a chaque ouverture du boitier. Et on retrouve la encore, une des nombreuses médiocrités dans la construction de la machine.
Il est a supposer que très certainement, des investigations précédentes dues j'imagine a des pannes a répétition, ont fini par fragiliser le connecteur 'pince' sur le câble (le connecteur rouge visible sur la paire de fils blancs). Le résultat : un contact bien moins bon qu'a l'origine entre les fils et les bornes du connecteur rouge. Sans compter l'oxydation présente sur les parties dénudées et non soudées des fils qui ne doit pas améliorer la situation au niveau de ce connecteur. Ce qui eut pour effet d'augmenter artificiellement la résistance de cette connection. Qui dit résistance, dit différence de potentiel en fonction de l'intensité consommée. Différence de potentiel suffisante pour passer la tension arrivant sur la carte numérique de 5V a 4,6V.

Un cas d'école, qui m'a cause bien des soucis...

Mais le résultat est la, la carte numérique alimentée maintenant sous une tension d'alimentation réelle de 5V, le disque est enfin reconnu et fonctionne normalement :

Le bonheur!

J'en ai profité pour remplacer le CEM5530 d'origine, lui aussi parfois peu fiable, par un ELD5530 de ma conception , beaucoup plus 'costaud':

Avec le CEM5530 de l'autre Studio440, voici deux CEM5530 d'origine et parfaitement fonctionnels :

De quoi faire des envieux :