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 :

Work in progress.....

Cela va faire bientôt un mois que je n'ai pas publié d'articles sur un quelconque développement en électronique. Serait-ce a dire que le sujet des piles m'ait suffisamment épuisé pour m'être octroyé une longue période d'inactivité? Non, bien évidemment!

Au sujet des piles, vous pourrez en apprendre plus, ou tout simplement confirmer ce que vous avez appris tout au long de mes articles en visionnant ce sujet intéressant sur le blog de David L. Jones :

http://www.eevblog.com/2015/06/05/eevblog-751-how-to-debunk-a-product-the-batteriser/

ou il est question de se poser les bonnes questions au sujet d'un appareil censé pallier ce 'fameux' seuil de 1,2V des piles alcalines en permettant justement d'utiliser toute l'énergie encore disponible dans la pile alors que l'appareil alimenté devrait indiquer un défaut d'alimentation.

Il est intéressant de constater que durant cette vidéo, Dave teste la tension minimale de fonctionnement d'un lecteur DAT sony TCD-D8, et obtient une tension minimum de fonctionnement de 1,1V la ou, a vide, j'obtiens une tension résiduelle des pile de 1,285V, soit une différence de potentiel de pratiquement 0,2V. En connaissant l'intensité qu'absorbe le lecteur DAT, il serait facile de déterminer la résistance interne de la pile. Sous 100 mA (hypothese), elle 'serait' de R = U/I soit 0,2/0,1 soit 2Ohms! Je pense que c'est moins en fait parce qu'a 100mA, une pile fournit 1,2V minimum pendant environ 8h. Hors, des piles neuves permettent a ce Sony de fonctionner a peu près 3 heures. On peut en déduire une consommation d'environ 250mA soit une résistance interne d'environ 0,8Ohms. Plus l'intensité débitée est importante, plus cette résistance interne joue, d'une part en 'consommant' inutilement l'énergie de la pile, puis d'autre part en abaissant artificiellement la tension visible de la pile, la faisant passer a 1,1V alors qu'a vide elle présente une tension de  1.285V.
 
Bref, si l'utilisation de piles alcalines sous une intensité élevée est totalement contre indiquée, le consommateur lambda refusant l'élévation de son petit niveau de culture se verra offrir bientôt un autre 'fake' lui permettant de palier l'achat du 'fake' précédent, la pile alcaline.

J'attends de voire si ce produit sera disponible en France pour en faire le test. Il m'est a penser que ce 'truc' risque de fonctionner, mais sous faible intensité, forcément.

En fait, j'ai travaillé sur plusieurs projets :

Et encore, tout n'est pas sur cette image...

Dans l'ordre :

1. Carte de développement pour processeur LPC1114FN28 et LPC810 de NXP.
2. Carte de développement pour processeur Z8F6421 de Zilog.
3. Interface RS485/USB série isolée pour travailler avec l'automate Fidelix.
4. Couple de mémoires non volatiles pour Prophet VS avec capacité de 400 programmes.
5. Mémoire non volatile de  32ko.
6. Mémoire non volatile de 2ko.     

Explications :

1. Cette carte a déjà été testée avec succès depuis plusieurs mois. En fait j'ai mis en place un environnement de développement sous Linux se passant de la librairie CMSIS. L'intérêt? Et bien celui de maitriser plus directement le processeur utilisé, même s'il s'agit d'un ARM, le circuit NXP n'est pas très compliqué a appréhender, malgré quelques facéties du LPC1114!
   Et puis surtout, procéder de la sorte permet de créer un code vraiment compacte. J'avais prévu l'utilisation de ce processeur dans une petite application d'exemple, mais en fait, ce projet s'est étoffé au fil du temps. J'espère produire une application viable d'ici quelques semaines.
2. Même chose avec le processeur Zilog. Contrairement au processeur ARM 32 bits, il s'agit ici d'un processeur 8 bits a 20Mhz, tout simplement. L'intérêt de ce circuit, ou de cette famille de circuits, est l'extrême simplicité du composant allié a un outils de développement qui date bien d'une dizaine d'année maintenant mais lui aussi d'une extrême facilité d'installation et d'utilisation. Rien a voir avec l'usine a gaz d'Atmel et son 'Studio' que certains ne sont jamais parvenus a utiliser sur un windows. Je précise que j'utilise le logiciel Studio 6 d'Atmel sur un PC windows 7 sans problème.
   Certains gros constructeurs de micro-contrôleurs ont 'sponsorisé' a outrance leurs processeurs 32 bits a coups d'arguments parfois... discutables. Le but non avoué étant bien évidemment d'évincer toute une série de concurrents pourtant bien établis. Or, si l'on prend comme objectif le but, et non le moyen, ces processeurs Zilog sont réellement très intéressants.    
   Le pire dans l'histoire, c'est que le matériel se contente d'une liaison série, donc pas de drivers a installer, que le logiciel fonctionne très bien, même sur un PC de 15 ans équipée d'un processeur PIII a 866MHz sous windows 2000, et qu'enfin le débogueur temps réel est implémenté sur cette carte de développement pour dialoguer avec la seule patte dédiée au débogage du processeur. N'est-ce pas fantastique? A l'heure ou trouver un PC pour faire ce type développement devient de plus en plus difficile sur le marché du neuf...    
   Pour ce système j'ai aussi développé une application plutôt cossue. En fait, il s'agit d'un prototype réalisé il y a 10 ans, que je suis en train de remettre en service.
3. Pour travailler avec l'automate Fidelix (voire 'la solution possible' dans ce billet), je souhaitais m'équiper d'une interface série USB vers série 485. Et isolée galvaniquement si possible. Des interfaces de ce genre sont faciles a trouver en version non isolées. A prix très bas. Par contre la version isolée 'tape' systématiquement dans le professionnel, a un prix oscillant entre 100 et 200 Euros. Et encore, l'utilisation de l'appareil ne semble pas toujours évidente. Parce que suivant le type d'isolation mise en place, des restrictions importantes peuvent subvenir lors de la communication entre deux appareils, sans qu'il soit toujours facile d'en déterminer  les impacts réels en productions. Je ne connais que trop ce genre de problème et, ne souhaitant plus y être confronté, j'ai décidé de développer moi-même cette interface. J'ai donc utilisé un composant d'interface très particulier, introuvable en France, mais qui rempli très bien sa fonction, même a très haute vitesse! Peut-être un article sur son utilisation avec l'automate Fidelix.
4. Je n'ai pas encore testé ces deux mémoires dans mon Prophet VS. Ces mémoires, outre le fait de se passer de batterie pour retenir les données tout en se comportant quand même comme une mémoire statique conventionnelle, permettront de multiplier par 4 la capacité de stockage de programmes de la machine. J'ai en tête une autre modification pour permettre une sélection facile des 4 banques de mémoires, ainsi que l'amélioration de l'entrée des paramètres sur le panneau de commande du synthé. A suivre....  
5. Mémoire non volatile de 32Ko non encore testée.
6. Mémoire non volatile déjà testée avec succès dans mon JX-3P.

Et quoi d'autre? J'ai reçu le circuit imprimé de mon thermostat mais ne l'ai pas encore monté. Je travaille actuellement sur le portage de ce petit ordinateur d'étude de la belle époque : 

http://oldcomputers.net/micro-professor.html

dans un FPGA. Je possède toujours une petite imprimante se connectant a ce système :

http://www.old-computers.com

mais le prix aujourd'hui demandé pour un MPF1P justifie bien quelques réflexions pour réussir a l'intégrer dans un circuit a quelques Euros! Pour le moment, le moniteur fonctionne et j'en suis a l'écriture de l'interface entre l'affichage et un port série, afin d'être en mesure d'utiliser un PC avec émulateur de terminal en guise d'organe d'entrées/sorties. Et pourquoi pas utiliser un antique PC pour cette utilisation. De ces PC que l'on trouve parfois sur les trottoirs parisiens :

Un NEC PIII a 866Mhz tout a fait fonctionnel et en très bon état