Réparation : lecteur CD Arcam Delta 70.2

Il s'agit d'un lecteur CD équipé du 'fameux' TDA1541, considéré comme un des meilleurs convertisseurs audio numérique/analogique. J'ai trouvé ce lecteur en vente dans un état non fonctionnel. Je me suis laissé tenté par l'envie d'entendre ce convertisseur.

Image récupérée sur le net.

La présentation de la machine est on ne peut plus sobre. Le boitier tout en aluminium épais est de bonne facture et s'assemble très facilement. Les touches de la face avant sont assez grandes et précises pour permettre une manipulation aisée. La luminosité de l'afficheur peut être réglée à éteint, semi-luminosité et bien évidemment, pleine luminosité. Cela peut sembler être un raffinement superflu. Il n'en est rien. En semi-luminosité, les indications deviennent bien moins agressives qu'en luminosité maximale et plus lisibles en ambiance 'nocturne'.

J'ai acheté cet appareil avec le défaut annoncé : le moteur du CD fonctionne mais l'appareil ne lit plus les disques optiques.

Au démontage de la machine, la première chose évidente constatée est un problème concernant le détecteur de fermeture du tiroir. Il semble en manquer un bout. Après avoir secoué la machine, 'tête en bas', je découvre sur le plan de travail, la petite pièce mécanique manquante :

L'interrupteur type fin de course et son doigt palpeur cassé.

Il y aurait à dire sur ce contact de fin de course. La partie gauche fait office de palpeur, et est moulée dans le corps du contact. Ce palpeur bouge en fonction de la présence ou non du tiroir. Il y a donc notion d'axe. Et quel est l'élément qui joue ce rôle d'axe? La petite partie fine à droite sur le palpeur, soit, la torsion du plastique!!! Ce n'est pas ce que je considère être une mécanique à toute épreuve. Naturellement, avec l'âge et les contraintes répétées, cette partie se devait de céder.

Sans la détection de tiroir fermé, la logique du lecteur continue à faire fonctionner le moteur de fermeture, tout en empêchant la poursuite de la procédure, à savoir la mise en rotation du disque et la lecture de la T.O.C. Pour effectuer les premiers tests de fonctionnement, j'effectue donc la simulation de fermeture du tiroir en actionnant moi-même ce contact de fin de course à la main.

Et mauvaise surprise : pas de son. Je décide de suspecter en premier lieu la partie conversion audio du lecteur et non pas la  partie contrôle de la mécanique. En effet, la T.O.C étant correctement lue, puis un appui sur la touche 'play' lançant la machine en lecture, je suppose que toute la partie numérique fonctionne.

Pour commencer, je teste les alimentations de la carte de conversion. Pas difficile, le -15V et le -5V du convertisseur TDA1541 sont à 0V. Un rapide coup d'œil aux pistes du circuit imprimé me conduisent à un régulateur négatif de type LM337 qui ne reçoit pas sa tension négative d'entrée. Et pour cause. Juste à côté de ce régulateur, je trouve une petite résistance complètement calcinée :

La résistance en compagnie de 'son' régulateur et des condensateurs de filtrage.

La résistance est non pas coupée, mais présente une résistance de plusieurs dizaines de KOhms, incapable de laisser passer les milli-Ampères nécessaires au fonctionnement du régulateur et du TDA1541. Le code couleur de celle-ci n'est plus lisible, et sa mesure est forcément... fausse! Pour la remplacer, je considère arbitrairement que 200mA doivent suffire au fonctionnement du TDA puisque celui-ci consomme environ 100mA au total et que cette alimentation négative n'alimente QUE lui. Sous 12V de tension à faire chuter, la tension négative non régulée étant de -22V, cela donne une résistance d'une soixantaine d'Ohms. Je mets donc la main sur une résistance standard de 68Ohms mais cette fois en version 1/2 Watt et non plus 1/4 Watt.

J'en profite pour changer le régulateur. Au prix de ce composant, il est plus rentable de le changer que de tester celui qui est en place. Je change aussi les deux condensateurs de filtrage. En un mot, je change tout ce qui aurait été susceptible de générer un gros appel d'intensité, propre à faire 'fumer' la résistance, à moins que ce soit le TDA lui-même qui soit en défaut, mais dans ce cas, il me faudra trouver un nouveau circuit!

La résistance, le régulateur et les deux gros condensateurs changés.

Après cette intervention mineur et le remontage partiel de la machine, la sortie audio est de nouveau opérationnelle. Quelques heures de fonctionnement me permettront de valider la réparation, et de constater que la résistance chauffe bien un peu, mais sans plus, maintenant.

La carte de conversion dans son intégralité.

Il ne reste plus qu'à s'occuper du capteur de fermeture du tiroir pour finaliser la remise en état du lecteur. Je commande donc ce type d'interrupteur chez Farnell en prenant bien soin d'en choisir une version équipée d'un galet. Je ne sais pas encore de quelle façon je vais pouvoir adapter un tel interrupteur sur la mécanique du tiroir. Mais je me dis que je devrai plier son bras pour trouver le bon angle de détection. Je préfère donc commander de suite un système qui risquera le moins possible d'accrocher et de se bloquer.
Je commande donc ceci :

Il ne reste plus qu'à adapter ce 'truc' sur le mécanisme du tiroir.

Massacre à la tronçonneuse!!! Pour reprendre un titre bien connu... Après avoir trouvé ce qui me semblait être une bonne position pour ce contact, il m'a fallu retirer une partie en plastique sur le châssis du tiroir :

Il paraît que la série Mac Gyver devrait revenir sur les écrans!

Vous remarquerez aussi la courbure que j'ai fait prendre au levier de l'interrupteur, et de l'importance du galet notamment quand le tiroir s'ouvre!
Quelques points de colle à la cyanolite sur le support de l'ancien contact m'a permis de fixer très solidement ce nouveau détecteur. Après avoir ressoudé les fils concernés par l'opération, le mécanisme est de nouveau totalement fonctionnel. Histoire sans parole :

Et avec les bruits parasites magnifiés par le micro de l'appareil photo 'pas prévu pour ça'!

Pour ceux que cela intéresserait, une prise de vue de la mise en place de ce 'capteur de fin de course', effectuée sur le devant du lecteur CD :

Et maintenant... Il resterait à remettre en état la sortie audio à niveau réglable parce que celle-ci est en saturation complète. Mais je ne le ferai pas. La raison principale est que ce circuit se 'contente' de connecter un réseau de résistances d'atténuation au travers de switchs électronique CD4051. Quand on passe par des NE5532 pour traiter la sortie normale, il semble déraisonnable de 'bruiter' le signal audio au travers de circuits CMOS standards, on est censés être dans le domaine de la haute fidélité ici!

De plus, le circuit d'atténuation est monté sur un support céramique aux résistances 'imprimées'. Non, décidément, il est tout à fait inutile de s'occuper de cette sortie :

La machine est remontée et fonctionne maintenant parfaitement. Elle va remplacer un CD104 de Philips que j'avais précédemment réparé en remplaçant simplement la courroie d'ouverture/fermeture du tiroir et effectué quelques autres travaux de maintenance sans grande conséquence. Si cela vous intéresse, ce CD104 est en vente ici (à la date du 7 octobre 2015).

Et maintenant, un peu d'auto-publicité!

Parce qu'il m'arrive parfois d'avoir des questions sur les raisons de ce blog, de cet intérêt pour l'électronique et particulièrement l'électronique audio. A question compliquée, réponse simple : la passion.
A décorréler de préférence avec les études suivies et l'expérience professionnelle, même si ces deux aspects ne sont forcément pas très éloignés de mes centre d'intérêt.

L'audio numérique m'a amené à créer, par exemple, il y a déjà quelques décennies ce type d'appareil :

Home made...

Un convertisseur audio numérique 20bits. C'était en 1994, avec les moyens du bord, à une époque ou Orcad sans auto-routeur coutait une fortune et ou faire fabriquer ses circuit imprimés à l'unité en double face trous métallisés en France n'était pas donné!

Avec une alimentation séparée pour chaque étage!

Du haut de gamme de l'époque, toujours aussi réputé : DF1700P, YM3623B et DAC AD1762N. Je n'ai jamais testé la machine avec la version JN des AD1762. 21 ans plus tard, cet appareil fonctionne toujours, sans jamais avoir posé le moindre problème! Je vais pouvoir le comparer avec ce nouveau lecteur CD...

Bien choisir sa formation...

En pérégrination dans un département étranger, je suis tombé par hasard sur une situation que je trouve assez représentative de la différence entrepreneuriale d'une part, et philosophique d'autre part, qu'il peut y avoir entre les U.S.A. et la France, notamment sur le sujet des hautes technologies et plus particulièrement celles d'avenir concernant l'énergie :

Il me fallait absolument savoir qu'elle était la borne électrique qui chargeait cette Tesla :

Il faut être franc, je me doutais de ce que j'allais découvrir : 

Evidemment : une Legrand!

Loin de moi l'idée de faire du 'France bashing'. Bien au contraire!!! 

Qu'il est rassurant de constater que l'innovation dans la haute technologie permet à la France d'être présente aussi sur ce créneau.

Et qui d'autre que Legrand aurait pu investir financièrement dans une telle technique?

Si vous êtes tenté par ce créneau pour vos études, au moment crucial choisissez bien votre voie. Ici, deux concepts d'entreprise et surtout deux organisations de société civiles se font face : à vous de voir!

21 mars 2016 : la rente sur la mobilité électrique se met doucement mais surement en place en France! 

Spie va installer 882 bornes de recharge de véhicules électriques dans 5 départements.

Source boursier.com 21 mars 2016.

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...