Sauvetage d'un STUDIO 440.

Il y a quelques jours de cela j'ai reçu la demande d'un 'malheureux' propriétaire d'un Studio 440 pour un ELD5530, le clone de CEM5530 que j'ai réalisé.

Puis, quelques jours plus tard, la même personne me recontacte pour m'indiquer que malgré le remplacement du CEM5530, la machine ne sort toujours aucun son. Pire, lors de la procédure de diagnostiques internes, ceux concernant les test de la RAM d'échantillonnage (test n°2) et de son rafraîchissement (test n°0) indiquent que tous les circuits RAM sont en défaut.

Je propose donc de prendre en charge une tentative de dépannage de la machine.
Quelques jours plus tard, je reçois le Studio440 en question :

J'avais déjà retiré les capuchons des boutons avant de faire la photo.

La machine a du vécu, c'est sûr, mais se trouve dans un état esthétique plutôt correct. Comme de bien entendu, les switchs les plus utilisés sont pratiquement inopérants. C'est une caractéristique des machines Séquential de l'époque. Ces switchs sont de mauvaise qualité et ne supporte pas une utilisation intensive.

Mais, elle s'allume correctement. L'ayant branchée sur un disque dur externe de type Macintosh contenant une banque de son dont je connais bien le rendu, je constate que le chargement de la banque se passe correctement par la liaison SCSI : un bon début.

Par contre aucun son ne sort effectivement de la machine. Les tests de diag lancés, je constate que ceux afférant à la RAM d'échantillonnage sortent systématiquement en défaut.

J'ai donc du me plonger dans le schéma de la machine pour comprendre le mécanisme de chargement et de rafraîchissement de cette RAM. Je ne l'ai pas précisé, mais il s'agit de RAM dynamique, évidemment. Au milieu des années 80, les quelques centaines de mégas octets de mémoires n'étaient envisageables qu'en RAM dynamique.

Quels plaisantins, les concepteurs de l'époque chez Sequential. Je ne rentrerai pas dans les détails mais après plusieurs tests, j'en arrive à la conclusion qu'un des circuits custom est défectueux. Je le remplace donc par un circuit neuf :

Le deuxième à partir de la gauche, mais ça se voit à l'image, je pense ;-)

Puis, après avoir effectué quelques autres travaux autour de ce circuit, je redémarre la machine et lance de nouveau les tests de la RAM. Forcément, cela se passe beaucoup mieux :

J'aime bien la luminosité de l'afficheur VFD.

Notons que le test n°2, et le test n°0 concernant la RAM affichent le même message laconique lorsque ceux-ci se sont correctement déroulés.

Je recharge donc la banque de sons et constate que cela se passe bien maintenant. Après une série de tests, j'en arrive à la conclusion que la carte processeur de la machine est maintenant parfaitement fonctionnelle.
Ce qui n'est pas le cas de la carte analogique :
les premières constatations ne sont cependant pas catastrophiques. Une des huit voies audio émet un 'crachouillis', et une autre ne sort que sur le canal gauche.

La voie concernée par l'émission de bruit est la voie n°8. Un rapide test du CEM3389 m'indique qu'il n'est pas en cause. Je change quand même son support parce qu'il a vraiment été mal monté. Afin de tester rapidement le convertisseur numérique/analogique, je le dessoude de la carte et y place un support de circuit. Je remplace ce convertisseur par un équivalent fonctionnel et constate le même problème. L'examen à l'oscilloscope confirmera mes soupçons sur le fait que quelques bits sur la douzaine du bus de données se sont fait 'la malle'. Je découvre rapidement quel est le circuit logique responsable de ce problème. Il s'agit d'un CD40174.

De mémoire je n'ai jamais utilisé ces sextuples bascules D. Après m'en être procuré et avoir remplacé le spécimen défectueux de la machine, la voie n°8 fonctionne de nouveau correctement :

J'ai même retrouvé un circuit de marque RCA!

Petite digression sur cette recherche de composants. Par hasard de passage à Paris, je me dis que je pourrais mettre à profit quelques heures de temps libre pour cheminer dans la capitale à la recherche d'une boutique de vente de composants. Pour être honnête, il y a bien 15 ans maintenant que j'effectue d'habitude ce genre d'achat sur le NET.

Pour commencer, je passe chez Sélectronique, place de la Nation. Mauvaise pioche, ces gens-la vendent du Fisher Price (avis qui n'engage que moi!). Mais, un gentil vendeur qui, après m'avoir indiqué que sur place ils ne vendent pas de composants, en tout cas ceux que je recherche, m'indique une boutique située non loin de là, boulevard Diderot. Il s'agit de la boutique R.A.M :

Publicité gratuite et de bon coeur!

Ah, quelle joie de retrouver ce type de boutique. Un petit coup de nostalgie pour tenter de se remémorer quand fût la dernière fois ou je suis rentré dans un tel établissement à Paris. C'était avant les années 2000 et c'était boulevard du Montparnasse il me semble! Comment se fait-il que je ne sois jamais entré auparavant chez R.A.M : mystère!

L'authenticité chez R.A.M : devanture mal soignée qui rebute d'emblée les amateurs du dimanche. Non monsieur, ici c'est du sérieux! Je rentre, et effectivement le vendeur était en train de 'décourager' un jeune qui, semblait-il, tentait de travailler sur de l'Arduino, en lui proposant de faire plus sérieux en allant jouer sur de la PI. Hum... Un brin acariâtre le Monsieur, mais juste ce qu'il faut!

Bref : du bonheur. Ceux qui, comme moi, ont connu les 'belles' années de l'électronique comprendrons. J'adoptai donc le ton entendu et me fis remettre contre quelques euros, l'ensemble du stock de circuits 40174 : sept circuits! J'en eus pour mon argent avec des versions HEF, HCF, et... CD de chez RCA de surcroît. Et sans doute d'époque d'ailleurs. Ce qui va me permettre une restauration 'à l'identique', j'aime bien ça.

Je retournerai voir cette boutique, c'est sûr. Elle regorge de matériels neuf et anciens dont on ne saurait se passer quand on doit remettre en état de vieilles machines.

Pour en revenir au Studio 440 en cours de restauration, il me restait encore à trouver la raison pour laquelle une des autres voies ne sortait pas en stéréo. Encore une fois, les solutions adoptées à l'époque par Sequential et la piètre qualité des composants utilisés auraient pu être à l'origine du problème comme ce fut le cas sur un des mes 440. Mais non, il s'agissait 'simplement' d'un CEM3389 dont une des voies était muette. Par chance, le support de ce circuit étant correctement soudé à la carte, je n'ai eu qu'à le remplacer par un circuit fonctionnel que je possédais en stock.

Passons au lecteur de disquette. J'imagine qu'il y a vraiment un problème d'interférences électromagnétiques avec le câble en nappe reliant le contrôleur WD1770 au lecteur de disquette, ou avec le lecteur de disquette lui-même. Une solution pourrait être l'utilisation d'un émulateur de disquette comme l'émulateur HCX :

Le propriétaire du Studio440 dont il est question ici à fait cette démarche. Cependant malgré moult essais, je n'ai jamais été en mesure de faire reconnaître la carte SD par la machine. Ceci correspond cependant aux différents tests que j'ai moi-même effectué il y a quelques mois de cela avec cet émulateur. Je n'en sais pas plus pour l'instant mais il serait intéressant de creuser l'affaire à l'occasion puisqu'il 'semblerait' que cela fonctionne. A noter que j'ai installé cet émulateur dans un QX1 Yamaha qui l'a reconnu dès le départ sans aucun problème!

http://www.matrixsynth.com/2014/07/yamaha-qx1-digital-sequence.html

Malgré cela, ce Studio440 fonctionne correctement, tout du moins pour ses fonctions vitales. Après plusieurs manipulations, je constate que le potentiomètre de panoramique n'est pas fonctionnel. Il doit s'agir du potentiomètre lui-même car toutes les autres entrées du convertisseur CAN associé fonctionnent. Il reste aussi au propriétaire à changer les switchs fatigués de la machine. Une fois ces dernières interventions effectuées, ce studio 440 sera une super B.A.R. au look rehaussé grâce à l'afficheur VFD (j'en ai aussi commandé un, du coup).

21 Avril 2016 : CONNECTEURS DE L'ALIMENTATION A DECOUPAGE D'ORIGINE

Il s'agit des connecteurs J2-J3-J4. Présenté machine ouverte normalement c'est à dire connecteurs à gauche, nous avons le brochage suivant :

+5V

GND

+15V

-15V

Ce brochage est VALABLE POUR LES TROIS CONNECTEURS.

En image voici ce que cela donne :

Il s'agit d'une alimentation de marque Cherokee International / Ref : QF1G1 (merci Jamal) de taille 15 X 10 cm.

Forth pour LPC1114FN28

Il y a quelques jours, en parcourant les news du site http://hackaday.com, je suis 'tombé' sur une nouvelle intéressante concernant le portage du langage Forth sur le processeur LPC1114FN28 de chez NXP. Ce superbe travail a été effectué par Matthias Koch. Nouvelle intéressante car j'ai développé une carte d'expérimentation pour ce circuit. Je pensais donc être en mesure d'obtenir rapidement un système autonome et assez efficace. Ce fût le cas.

La carte de dev LPC en compagnies de quelques cartes sœurs.

Pour rappel, la carte de développement Micromite (autre carte développée par mes soins) contient, elle, un interpréteur Basic extrêmement efficace. Mais il s'agit d'un interpréteur. Dans le cas du Forth, il s'agit plus d'un compilateur qui traduit directement les lignes de code entrées par le port série, en code natif, d'ou une exécution extrêmement rapide des programmes. A noter que cette implémentation Forth fonctionne dès 512 octets de RAM et est en mesure de générer le code soit en RAM, soit directement en Flash, un peu à la manière du Micromite.

La procédure d'implémentation de ce compilateur Forth est on ne peu plus triviale. Il est nécessaire de télécharger la version mecrisp-stellaris-2.1.3.tar.gz (version 2.1.3 à la date de ce billet) disponible sur le site Sourceforge.net. La décompression de cette archive permettra de trouver le fichier 'mecrisp-stellaris-lpc1114fn28.hex' dédié, on s'en douterait, au processeur LPC1114FN28! 

Ce fichier 'hex' doit être programmé dans le LPC à l'aide de la carte de développement que j'ai développé (la programmation peut aussi se faire sur plaque d'essais en fil volants, mais c'est moins pratique), et par exemple le logiciel FlashMagic : 

Il n'y a plus qu'a user du bouton 'start'!

Avec le message de fin de programmation si la procédure s'est déroulée correctement. Il n'y a pas de raison qu'il en soit autrement avec la carte de développement :

Ready!

Il ne reste plus qu'à utiliser un émulateur de terminal série pour vérifier le bon fonctionnement du système. Ici encore, la flexibilité de la carte de développement permettra de travailler directement en USB sur n'importe quel PC. En ce qui me concerne, j'utilise couramment le logiciel Realterm, facilement trouvable sur Internet. Il convient cependant de configurer cet émulateur de terminal pour un résultat optimal.

Tout d'abord le type d'émulation :

Puis le port série concerné et la configuration nécessaire à la communication avec Forth à savoir 115200, 8, N, 1 : 

Enfin, il est nécessaire de désactiver les broches RTS et DTR de l'interface série sinon le processeur reste constamment en mode RESET :

Il ne reste plus qu'à appuyer sur le bouton RESET de la carte pour obtenir l'invite du compilateur Forth : 

J'aime qu'un plan se déroule sans accrocs ;-)

Et maintenant? Impossible de ne pas tenter l'inévitable "Hello World" de l'électronique, à savoir la LED qui clignote. Très sympa, l'auteur de ce compilateur Forth, non content d'avoir eu la bonne idée de prévoir une implémentation du Forth sur le LPC1114, a aussi prévu quelques programmes de test dont l'inévitable Blinky dont je reproduis ci-dessous le code :

\ Blink a LED on P1.8

$40044014 constant IOCON_PIO1_8
$50013FFC constant GPIO1_DATA
$50018000 constant GPIO1_DIR

: blinky ( -- )
  $C0 IOCON_PIO1_8 ! \ Set P1.8 as GPIO without Pullup/Pulldown. $C0 are reserved bits that must be set.
  256 GPIO1_DIR    ! \ Set P1.8 as Output

  begin
    256 GPIO1_DATA !
    1000000 0 do loop
      0 GPIO1_DATA !
    1000000 0 do loop
  key? until
;

Ce code se passe de commentaire... Si ce n'est que, bien que la carte de développement possède une LED dédiée à ce type d'exercice, je ne souhaitait pas modifier le programme de l'auteur car sur la carte, la LED ne se trouve pas sur le port P01_8. J'ai donc câblé une LED 'externe' directement sur le PORT P01_8 :

Le système utilisé avec la LED jaune reliée sur le connecteur externe.

L'étape suivante consiste donc à 'envoyer' ce fichier à la carte de développement à l'aide de l'émulateur de terminal. Afin de laisser le temps au noyeau Forth de décoder les lignes envoyées et de les gérer, j'ai inséré quelques milli-secondes d'attente après chaque lignes. Realterm permet d'effectuer ce type d'action très facilement : 

Juste avant d'appuyer sur 'Send file'....

La carte a correctement reçu le programme :

Il suffit dès lors de taper la commande 'blinky' pour lancer l'application et constater le clignotement de la LED : 

Et voilà!

Remarque : la rapidité d'exécution de ce système est remarquable. Une boucle vide telle que le 'programme' suivant : 

: delay 0 do loop ;  ok.

10000000 delay  ok.

s'exécute en à peu près 4 secondes. Pour rappel, le Micromite version 2 exécute une boucle basic vide en 11 secondes. Une carte à 8051 basic rapide, en 50 secondes et le vénérable Sharp PC1500 en 3000 secondes. Nous sommes donc plus de 700 fois plus rapide que le PC1500.

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 :