Audio HiFi, développement durable et réparations : HK3490.

Pour continuer sur la série des réparations : Retour à une vie normale pour un amplificateur intégré modèle 3490 de marque Harman Kardon.

Mise en situation : la machine s'est arrêtée de fonctionner suite à un dégât des eaux. Je constate de visu qu'il y a effectivement quelques traces d'eau chargée de matière calcaire sur le capot de l'appareil ainsi que sur un circuit imprimé dont je perçois en outre des tâches 'oranges' annonciatrices  de problèmes potentiellement très ennuyeux.

J'ai retiré quelques nappes pour établir un premier diagnostic.

La machine possède un superbe transformateur susceptible de fournir un bon nombre de tensions différentes sous un bon ampérage. Le fond de l'appareil contient la partie amplificateur avec les transistors de puissance de marque Sanken, fixés sur un radiateur en aluminium de très bonne taille. La carte n°1 contient la partie entrée audio numérique. La n°2 concerne les entrées/sorties analogiques ainsi que la partie processeur. La n°3 est le tuner FM et PO/GO. La n°4 est dédiée entre autre à la mise à jour éventuelle du firmware du processeur.

Nous sommes en présence d'une machine plutôt bien construite, mais mis à part les transistors de puissance qui sont des modèles spécialement prévus pour une utilisation en haute fidélité, le reste du matériel et des solutions adoptées relèvent plutôt du bas de gamme. De l'extérieur tout semble fonctionner. L'afficheur fonctionne et répond aux sollicitations des touches de la face avant. Par contre aucun son ne sort, si ce n'est des crachotements!

Avant toute décision, la première étape consiste à évaluer les dégâts causés par l'eau :

A l'évidence, le point le plus sensible concernera l'intérieur du rond rouge central, situé sur la carte processeur et entrées/sorties analogiques. Une recherche rapide sur Internet me permet de constater qu'il ne sera pas évident de trouver une telle carte en état de fonctionnement et que si je souhaite tenter une remise en état, il va falloir s'attaquer aux problèmes.

Je démonte donc la carte la plus endommagée et en retire quelques composants pour me faire une idée plus précise des dommages :

Impressionnant!

Qu'en est-il des pistes du circuit imprimé? Heureusement il s'agit d'un circuit à seulement deux faces. Au pire des cas, il sera à peu près possible de suivre 'à la trace' celles qui sont endommagées et les reconstruire au besoin!

Après un sévère nettoyage, on y voit déjà un peu plus clair. Dans le cercle rouge du 'haut', une des pattes du circuit intégré IC36 semble en très mauvais état. Après test de continuité, la patte n°8 de ce circuit est toujours 'à peu près' soudée au circuit imprimé, par contre elle n'est plus reliée au boitier du circuit, la corrosion en ayant fait disparaître la moitié. Après recherche d'informations sur le Net, il s'agit d'un amplificateur opérationnel dont la patte n°8 sert à l'alimentation positive. Il est clair que ce circuit n'est plus correctement alimenté.

Dans le rond du dessous, apparaît une diode notée D310 dont les pattes ont totalement disparues. Pire, les plots du circuit imprimé ou elle était soudée ont eux aussi totalement disparus. Se faisant, l'alimentation en 15V d'une partie des autres composants n'est plus disponible!

Je décide de commencer par évaluer la faisabilité du remplacement du circuit intégré IC36. Il s'agit d'un circuit de la marque Japonaise JRC, un NJM2068D relativement difficile à trouver. Mais le tableau d'équivalence donné par le constructeur indique un possible remplacement par un LM833D. Ce circuit est disponible chez Farnell au prix exorbitant de 0,42€ HT! Nous ne sommes réellement pas dans le haut de gamme!

Je commande...

Image floue :-( mais le LM833D à gauche et le NJM2068D retiré de la carte, à droite.

Et j'effectue les premières réparations :

Il m'a fallu 'jouer' avec la patte n°8 du circuit intégré en la tordant quelque peu pour effectuer une soudure viable sur le peu de piste qui restait encore sur le circuit imprimé. L'oxydation de la diode D310 ayant eu pour conséquence la coupure d'une piste principale d'alimentation, je rétablis la liaison avec un morceau de patte de résistance 'qui trainait par la'.

Je n'ai pas cherché à remonter une diode en remplacement de celle disparue. J'ai tout simplement connecté un fil de liaison sur l'autre face de la carte, avec une alimentation correspondante.

D'autre part, le condensateur noté C397 sera placé, lui aussi, sur l'autre côté du circuit imprimé. Je n'en possédait pas en version chimique mais uniquement en MKT dont le boitier ne correspond pas du tout à l'empreinte initiale.

Après les premiers tests de fonctionnement, j'ai constaté qu'une seule des voies était fonctionnelle. Un rapide examen me permis de découvrir que la borne  '+' du condensateur C375 n'était plus relié à la piste menant aux pattes 6 et 7 de l'amplificateur opérationnel référencé IC36 que je viens de changer. Logique, cette partie de l'ampli-op est visiblement monté en 'suiveur' et sa sortie est donc de fait coupée. Un examen visuel ne m'a pas permis de suspecter un tel problème.

Un rapide 'grattage' de la piste, puis un trait de soudure aura vite fait de rétablir la liaison. A ce stade, les entrées de la carte n°2 ont été traités et fonctionnent. Par contre, il m'est toujours impossible d'écouter la radio dont le réglage semble poser problème d'après les indication incohérentes de l'afficheur. Quelques instants ont suffit pour en arriver à la conclusion que le module radio, la carte n°3, n'est pas alimenté.

Pour rappel : le point à problème potentiel déterminé en début d'article.

Après un rapide test des points de connexion, il s'avère que la patte du connecteur véhiculant l'alimentation vers le module radio à du subir le même sort que celle du circuit intégré mentionné plus haut. Ici, pas question d'envisager un tel remplacement. Je ne suis même pas sur de trouver ce type de connecteur. Et de plus, il n'y a que la broche correspondant à l'alimentation qui est rompue. Je décide donc de souder un fil 'rouge' de l'autre côté du circuit imprimé sur la piste concernée, et d'amener le +15V directement par ce fil jusqu'à la carte tuner.

Et voici le résultat une fois la carte remontée dans l'appareil :

En plus du circuit intégré et du 'pont' de câblage dont j'ai fait mention précédemment, on remarque sur cette image les trois condensateurs neufs, version bleu clair, montés en bonne place. Le quatrième se situant de l'autre côté du circuit, et le fil rouge véhiculant le +15V à la carte tuner. A remarquer que la carte tuner n'a présenté aucun problème. Un simple nettoyage des traces de dépôt calcaire à suffit.

Tout fonctionne! J'ai passé environ 3 heures en incluant les périodes de diagnostic, de recherches sur Internet, de commande, de réparation. Le coût en composants est totalement symbolique car ne correspond même pas à 1€.

Conclusion : J'ai connecté cet amplificateur sur une paire de petites enceintes Eltax. Le rendu est très bon et ne suis pas déçu du dynamisme sonore, pas plus que du spectre retranscrit malgré une taille d'enceintes pas nécessairement optimale pour une reproduction de qualité.

Cet ampli, comme je le faisais remarquer en début d'article, présente des solutions techniques assez éloignées des canons de la haute fidélité. On notera une chaîne de sélection et un réglage du volume traité par des circuits intégrés, alors qu'il est considéré à juste titre que moins le son ne traverse de circuits actifs, moins il est susceptible d'être pollué. De plus, la totalité du signal sonore passe au travers de condensateurs chimiques et non pas, au minimum, de composants de type MKT. Enfin, l'ensemble des amplificateurs opérationnels sont du type JRC NJM2068D, même celui effectuant la pré-amplification pour platine vinyle, ou il aurait été largement plus logique d'y trouver à minima un NE5532. Quant à la conversion Numérique/Analogique, carte n°1, elle est du type 'travail minimal'. Je ne l'ai pas testée mais j'imagine qu'elle fait correctement son office, même si aujourd'hui il est certainement possible de trouver pour une somme tout à fait correcte, une telle fonction de conversion de meilleur facture. Quant à la partie amplificateur, elle me semble de très bonne qualité, tant en rendu sonore qu'en fabrication. Force est donc de constater que cet intégré rempli très bien son office...

Le plaisir d'avoir remis en état une telle machine, plutôt que de la voire terminer son existence au mieux, au fond d'une benne à ordure, est totalement incommensurable.

Informatique, développement durable et réparations.

Tout Blog sérieux se doit de contenir un certain nombre d'articles sur le vaste sujet qu'est le dépannage de matériels divers et variés. Puisqu'il s'agit d'un blog plus spécialement dédié à l'électronique, commençons donc par un dépannage trivial : un écran d'ordinateur.

Mise en situation : comme chaque année, la saison de la mise au rebut des matériels obsolètes est arrivée. Comme chaque année, je me poste sur le trajet menant de notre salle de stockage vers les containers appartenant à l'entreprise censée gérer la gestion de ces déchets électroniques pour tenter d'intercepter ce qui peut être sauvé d'un funeste destin.

D'un point de vue philosophique, nous ferons l'impasse sur ce qu'il advient de ces déchets électroniques. Arte propose suffisamment de reportages sur le sujet pour ne pas être sans savoir qu'une relative faible quantité d'entre eux est réellement traitée. Qu'une mafia mondiale s'est mise en place, qui revend ces 'détritus valorisables' à des pays d'Afrique ou d'Asie ou les normes environnementales pénalisantes ne sont pas respectées, et ou les salaires étant ce qu'ils sont, la main d’œuvre nécessaire au traitement de ces appareils est réduite au coût minimum.

Nous passerons aussi sur la définition qui est donnée chez nous, d' un appareil obsolète pour constater que depuis 30 ans d'évolution des PC, et pour reprendre un bon mot littéraire, la révolution qui a consisté à insérer une machine à écrire dans un écran de télévision n'a pas évolué. Ou si peu depuis avec l'intégration d'un 'minitel'. C'est hélas ce à quoi correspond toute cette débauche de technologie pour la majorité des utilisateurs.

Bref, je tombe sur un écran Samsung SyncMaster 206BW qui ne s'allume plus. Bel écran à la surface d'affichage et à la résolution tout à fait correcte. Manufacturé en 2007 il s'avère tout à fait intéressant.

Évidemment, il est impératif de suspecter en premier lieu un défaut d'alimentation. Après avoir branché l'appareil, je constate que la dalle affiche une fraction de seconde l'image émanant d'un PC puis s'éteint. Ce phénomène se produisant périodiquement. Le diagnostique tombe presque de lui-même : l'alimentation à découpage ne fournit plus les valeurs nécessaires au fonctionnement normal de l'écran.

Le démontage de l'ensemble est très facile. Juste quelques vis à retirer sur le dos de l'écran et il s'ouvre facilement. En 5 minutes, j'en suis à démonter la partie alimentation.

 

Une inspection de routine de celle-ci me permet de constater une déformation anormale sur trois des condensateurs de filtrage des tensions continues.

En rouge, les condensateurs défectueux, en bleu les bons...

A noter que le gros condensateur de ligne est en bon état. Les trois condensateurs posant problème ont le haut du corps bombé, laissant supposer que le diélectrique à chauffé et s'est dilaté pour en arriver à fuir comme sur celui du haut de l'image. Inutile de préciser que ces composants ne présentent plus leur capacité initiale, raison très probable pour laquelle l'alimentation ne fournit plus la stabilité et la valeur des tensions nécessaires.
Ce sont des condensateurs de 1000µF et 470µF en 25V.

On enlève :

Et on repeuple, mais cette fois avec des condensateurs de 35V. J'ai vérifié que la hauteur des nouveaux composants de 1000µF ne dépassait pas l'encombrement initial de la carte.

Les nouveaux condensateurs neuf présentent un dessus de boitier bien plat!
Le remplacement des composants défectueux m'a pris moins de 10 minutes.

Le remontage est aussi facile que le démontage.

L'opération finale : le test...

Bon pour le service!

Conclusion : le coût en composant de cette réparation peut s'estimer à moins de 3€. Le remontage m'a pris moins de 10 minutes soit un total d'intervention d'environ 20 minutes, estimable à une quarantaine d'Euros. L'opération n'est pas vraiment rentable puisqu'il est possible de trouver ce genre d'écran fonctionnel en occasion à ce prix.

Mais le calcul est mauvais. Si l'on considère l'énergie, la pollution, le gaspillage des ressources pour créer cet appareil et son remplaçant, que l'on y ajoute les 250€ de l'époque pour l'acquérir, les 130€ qu'il faudrait aujourd'hui pour se procurer un 24 pouces neuf, etc... Les 40€ que représentent le coût de ce dépannage sont extrêmement rentables. Seraient-ils estimables à moins de 10% de la facture totale dans le cadre du remplacement pur et simple de l'appareil? Oui mais voilà, cela n'est pas rentable pour tout le monde...

Pour l'utilisateur final, ça l'est, indiscutablement. De façon directe, Il n'a pas à effectuer de nouveaux investissements. Et indirectement, toute la pollution, le gaspillage etc... joue par rebond sur sa qualité de vie. C'est un choix!

TELEMECANIQUE XBT-A70101 (SUITE) & D.P. BUS PIRATE

Après avoir décodé les signaux de l'afficheur de ce terminal Télémécanique (voir sujet plus bas), et à peu près déterminé les séquences à envoyer au contrôleur d'affichage grâce à ma carte à base de processeur NXP LPC1114FN28 (voir aussi plus bas), je souhaitais en savoir plus sur le protocole de commande pour me permettre, par exemple, de faire clignoter certains caractères.

Ce complément d'information ne m'est pas nécessairement très utile, mais j'y voyais l'occasion de tester ce très populaire outil qu'est le Bus Pirate, édité par Dangerous Prototypes.

L'outil en question en version 3.6 :

Le câblage entre le Bus Pirate et le terminal Télémécanique se résume à sa plus simple expression puisque seulement un signal de donnée et un signal d'horloge sont nécessaires. La synchronisation du transfert avec le contrôleur d'affichage est réalisée par un octet particulier de démarrage, et un autre de fin de transmission. Entre ces deux bornes, une 'syntaxe' particulière est utilisée pour configurer l'interprétation du message à afficher.

Le système de test :

La liaison noire est la masse, la jaune les données, et la rouge l'horloge.
A l'affichage, le message généré par le Bus Pirate. A noter que les deux étoiles clignotent à environ un hertz, effet difficile à présenter sur une image statique!

L'utilisation du Bus Pirate est très simple. Après s'y être connecté à l'aide d'un terminal TTY classique en 115200 bauds 8 N 1, il suffit de le configurer dans le bon mode, dans mon cas le mode SPI (choix 5).

La configuration des paramètres du bus SPI se fait dans la foulée et, pour être en mesure de communiquer correctement avec le processeur de l'afficheur du terminal, ils doivent être positionnés de la façon suivante :

- Speed : 30KHz
- Clock polarity : Idle high
- Output clock edge : Idle to active
- Input sample phase : Middle
- CS : /CS *default (non utilisé dans cette application)
- Select output type : Normal (H=3.3V, L=GND)

A noter que de la même façon que pour ma carte à processeur LPC1114FN28, les signaux fournis par le Bus Pirate sont en 3,3V. Cela ne pose pas de problème au contrôleur d'affichage dont les seuils, compatibles au niveau TTL, s'accommodent très bien de ces niveaux.

Le gros avantage du Bus Pirate est qu'il est possible d'envoyer en chaîne et de façon dynamique une série d'octets sur le bus SPI. La série envoyée sera la suivante : 0x8d,0xc2,0xc2,0xcd,0xcd,0xe2,0x2a,0x42,0x55,0x53,0x20,0x50,0x49,0x52,0x041,0x54,0x45,0x2a,0xbf

Et le processus sur le Bus Pirate :

Il a suffit d'effectuer un copier/coller depuis un Wordpad de base dans la fenêtre de l'émulateur de terminal pour que la série d'octets soit prise en compte par le Bus Pirate et envoyée de suite sur le bus SPI à destination de l'afficheur. Le résultat de cette commande correspond à l'affichage *BUS PIRATE* avec les deux caractères '*' clignotants, comme présenté sur le système de test.

Explication du protocole d'affichage :

- Premier octet : 0x8D => le digit de poids faible est la vitesse de clignotement. En dessous de 8, modifie l'intensité d'affichage. 0x8F fera clignoter à peu près au Hertz.

- Paire d'octets suivants : 0xC2, 0xC2 => Zone de clignotement du deuxième caractère au... deuxième caractère.

- Paire d'octets suivants : 0xCD, 0xCD => Zone de clignotement du treizième caractère au... treizième caractère.

- L'octet 0xE2 : fait démarrer le message à partir de la position du digit de poids faible, soit la troisième position, 0..1..2!

- Les octets suivants représentent le message *BUS PIRATE*

- Le dernier octet, 0xBF, indique la fin de transmission.

Voilà, c''est tout et cela a été très facile à déterminer avec le Bus Pirate!

En complément, un lien intéressant sur la configuration et l'utilisation du Bus Pirate sur Skyduino .

Maker Faire Paris 21 et 22 juin au CentQuatre.

Après le mini 'Maker Faire' de Saint Malo qui s'est déroulé en 2013, le CentQatre accueillait à Paris la première réunion d'envergure de ce genre les 21 et 22 juin. Pour la petite histoire, il est amusant de se remémorer que le CentQuatre, devenu depuis sa réhabilitation la place d'un dynamisme culturel fortement encré dans l'actuel, fût de 1874 à 1998 un haut lieu des Pompes Funèbres!

Je passerai sur l'organisation de la manifestation qui m'a semblé tout à fait correcte, et les différents ateliers proposés, permettant à un large public d'y trouver son compte. L'impression 3D y était bien évidemment largement représentée ainsi que la plateforme Arduino, omniprésente, mais pas que. Des ateliers divers tant dans la forme que dans l'activité proposée ont sans doute permis à bien des visiteurs de se découvrir un intérêt pour le faire soi-même. Démystifier le sujet fait sans aucun doute parti des missions de ce genre de manifestation. L'inévitable atelier soudage était donc bien présent. Au delà du côté anecdotique que peut présenter l'assemblage de deux diodes et d'une pile sur un morceau de circuit imprimé, l'aspect gratifiant d'un montage réalisé et fonctionnel pour qui n'a jamais été confronté qu'à la surface tactile de son 'smart phone' permet au moins d'appréhender ce qui peut pousser les 'Makers' à faire...

En ce qui me concerne, parmi la multitude de produits proposés j'en ai sélectionné trois qui me semblent tout à fait intéressants pour qui souhaite non pas acquérir un produit fini, mais développer sa propre solution.

Le premier produit concerne la commande de machines de type CNC ou imprimante 3D ou pourquoi pas de lignes automatiques quelconques puisqu'il s'agit de commander de façon générale des moteurs pas à pas selon un script bien précis. J'ai donc nommé la Smoothie Board.

Cette carte est en mesure de piloter jusqu'à 5 axes plus d'éventuels autres actionneurs de forte puissance. Elle comporte moult accessoires permettant sa commande, un port Ethernet, une carte SD, un port USB, etc... Les informations détaillées sur ce produit se trouvent à cette adresse : http://smoothieware.org/smoothieboard .
Il s'agit d'un produit Français, développé en partie par Arthur Wolf avec lequel j'ai pu échanger lors de mon passage sur son 'stand'. Je possède depuis fort longtemps une fraiseuse Profiler d'Elektor que je n'ai jamais mise en fonction. La partie commande de cette fraiseuse amateur est totalement propriétaire et hors date. La perspective de donner vie à cette machine avec une carte Open Source permettant de surcroît l'utilisation de logiciels de commande eux-aussi Open Source et 'Up to Date' me semble tout à fait intéressante.

Les deux produits suivants concernent l'Internet des Choses... Pour résumer de façon simple ce concept, on peut dire que l'objectif de ce type de produit est de permettre la commande de systèmes distants par l'intermédiaire du réseau Ethernet et, par extension, du réseau Internet.
Depuis très longtemps, les machines automatiques sont en mesure de communiquer entre-elles. Le plus souvent par l'intermédiaire de réseaux simples et plus ou moins propriétaires. La démocratisation de la technologie, associée à un prix de production devenu très bas, permet aujourd'hui d'étendre de façon importante le champ d'applications de ce type de produit. Et notamment pour tout ce qui concerne l'automatisation des bâtiments et le 'reporting' de mesures.

Passer d'un réseau propriétaire simple sur du RS485 au réseau Internet n'est pas une mince affaire. Vient s'inviter dans le processus de développement, le protocole TCP/IP et la 'fameuse' pile associée. Cette 'pile' n'est en fait qu'un ensemble de bouts de programmes qui se parlent entre-eux de façon verticale. Un bout de code produisant un résultat qui sera exploité par un autre bout de code placé au dessus et ainsi de suite jusqu'à l’obtention des données réelles à exploiter par l'application, d’où la dénomination de 'pile'. Précisons pour ne pas être que simpliste, que cette pile répond aux spécifications du modèle OSI et qu'elle est tout sauf simple à développer.

La tendance actuelle consiste donc à utiliser un ensemble de logiciels contenant cette pile déjà programmée apte à fournir tous les services de transport de l'information. Et si ces logiciels peuvent, de plus, offrir un cadre d’exécution permettant l'utilisation de ces ressources réseau, pourquoi hésiter. Linux offre toutes ces possibilités sous la forme d'un système d'exploitation 'prêt' à l'emploi.

Tout n'est pas si simple. Pour implémenter une version de Linux, il convient de disposer d'un matériel suffisamment puissant et disposant des ressources mémoire nécessaires. Il faut souvent adapter le noyau Linux à la plateforme processeur utilisée et développer un mécanisme simple pour commander des entrées/sorties physiques, Linux n'étant pas vraiment prévu pour cela à la base. Mais le prix du matériel, l'adaptabilité du noyau Linux et son système d'entrées/sorties sur fichier, ainsi que la compétence de développeurs souvent issus du milieu du libre, ont permis d'arriver à des solutions devenant viables et peu onéreuses. Soyons clairs, ces systèmes ne seront 'jamais' aussi simples à utiliser qu'une carte Arduino de base, mais avec un peu de bonne volonté et de patience, cela devient aujourd'hui tout à fait réalisable.

Première solution éditée par la société Suisse Dog Hunter, le système de développement Linino One dont le concept semble se rapprocher très fortement de la carte Arduino Yum, carte à laquelle la société à contribué au développement. Le système est composé d'une carte principale dotée d'un processeur d'entrées/sorties ATmega32u4, connecté à un système fonctionnant sous OpenWRT, une version particulière de Linux sur processeur Qualcomm d'architecture Mips.

Décodage : L'ATmega32u4 est un processeur 8 bits de la société Atmel, compatible avec les processeurs du même constructeur que l'on trouve sur la première carte Arduino, la UNO. OpenWRT est le système d'exploitation Linux mais adapté à l'embarqué. Qualcomm est le fabricant du processeur dédié ici au système OpenWRT et enfin Mips est l'architecture de processeur sur laquelle est basée le circuit Qualcomm.

Une offre 'spéciale salon' était pratiquée par Dog Hunter incluant la carte Linino One accompagnée de ses accessoires DogRJ45 et DogUSB. Je n'ai pas résisté à la tentation : 

L'offre 'spéciale' MakerFaire.

Les objets Linino + DogRJ45 + DogUSB.

Le tout assemblé.

Il ne reste plus qu'à expérimenter sur le sujet...

Deuxième solution, cette fois éditée par l'agence d'innovation Nodesign.net. Il s'agit du projet WEIO. Je n'ai pas pu pour l'instant, obtenir plus d'informations techniques sur le contenu de la carte, mais celle-ci, contrairement à beaucoup d'autres solutions du même type, semble intégrer directement un serveur HTML fournissant, par l'intermédiaire de pages WEB, tout le nécessaire pour programmer l'appareil, notamment par la mise à disposition d'un environnement complet de développement en ligne, le Web Dev. Le système se programme en HTML5 et Python.

La carte WEIO semblerait contenir, outre un module wifi basé sur un processeur Qualcomm AR9331, le même type de processeur que celui du projet Dog Hunter présenté ci-dessus, un circuit s'occupant des entrées/sorties, visiblement de la famille LPC11uXX de chez NXP. Il s'agit d'un processeur de type ARM Cortex-M0 en 32 bits et 50Mhz, contrairement au processeur 8 bits d'Atmel pour la solution Dog Hunter. Il est possible d'obtenir plus d'informations sur ce produit à cette adresse : we-io.net. A noter que WeIO va lancer une campagne de crowd funding durant le mois de juillet. Il est prévu la disponibilité des cartes WeIO pour le mois de septembre.

Cette plateforme de développement semble prometteuse tant en terme de fonctionnalités qu'en ergonomie de développement et mérite de s'y intéresser. Il s'agit d'un projet développé en France...

Le côté sombre de la force.

Lors de ce Maker Faire, d'autres acteurs, moins 'friendly' étaient présents, notamment Intel avec la promotion de la plateforme Galiléo.

Il s'agit ici d'un avis personnel, mais je ne peux m'empêcher de regarder avec grande méfiance l'arrivée de cet acteur dans le milieu du 'DIY'. Non pas qu'il ne soit pas intéressant qu'Intel propose tout son savoir faire et son expertise en terme de processeur, cela pourrait être à la limite regrettable qu'il ne le fasse pas, mais la force commerciale et l'artillerie technique que serait à même de mettre en place cette société pour très rapidement truster le marché et tuer tout ce qui fait l'âme du DIY, à savoir la compétence personnelle et le foisonnement actuel d'idée et de réalisations est à prendre en grande considération.

Pour ne pas brusquer les âmes sensibles, rien de tel que de se présenter masqué :

Les 'connaisseurs' reconnaitront sur la table un TRS80 modèle 100 et sur le trépied une carte Galiléo. Cette photo a été prise, comme la précédente, sur le 'stand' Intel. Certes le TRS80 fait parti des machines mythiques des années 80 (année de sortie en 1983). Il était équipé d'un processeur Intel 80C85, un très bon produit de l'époque. Mais n'oublions pas qu'au même moment, était déjà sorti l'IBM PC qui, associé très tôt à Microsoft, à détruit en l'espace de quelques années tout le foisonnement informatique du début des années 80. Pour le bien de tous? Pas sur.

Nombre de concepteurs, d'inventeurs, de bidouilleurs ont vu disparaître toute possibilité d'activité professionnelle et ont été contraints à accepter des postes subalternes sous payés, voire de tout abandonner pour aller 'planter des choux' au fin fond de je ne sais ou. Tout le monde n'a pas été perdant, le commerce de là haute technologie inutile, puérile, avilissante ne s'est jamais aussi bien porté qu'aujourd'hui. Intel et Microsoft valent des milliards de dollars. Et vous? De quoi vivez vous?

Vous êtes prévenus. Si vous souhaitez reproduire le modèle actuel, arrivé à son terme, de l’ingénierie informatique ou le diplôme fait loi, ou la standardisation des matériels n'apporte plus qu'ennui et lassitude, et ou finalement, déclassé par une technologie dont vous n'êtes pas acteur, vous vous réfugiez dans la fonction publique en solution de dernier secours, n'hésitez pas!

Et Elektor dans tout ça?

Et bien non. Force est de constater qu'Elektor n'était pas présent à cette Maiker Faire. Par contre, j'ai pu discuter avec Denis Bodor, le rédacteur en chef de la revue Open Silicium et de la toute récente parution : Hackable Magazine, dont le premier numéro était disponible en avant première! A mon humble avis, ces deux revues forment un duo très intéressant pour qui veut débuter et évoluer dans le monde de l'électronique numérique créative.

Conclusion?

Tout un nouveau marché semble être sur le point d'émerger. Les grands acteurs de l'électronique numérique s'en sont, eux aussi, rendu compte. Ce marché ne va pas être simple, sans doute. La concurrence va jouer. Mais que ce soit celle des idées et non pas uniquement celle de la puissance économique.

Les prochains Maker Faire?

Du 5 au 6 juillet à Hanovre.
Du 3 au 5 octobre à Rome.

Bon voyage.

LPC1114FN28, MCS51, TELEMECANIQUE XBT-A70101

Le titre de ce billet peut paraître étrange. Que font ensembles, un processeur de type ARM, une antiquité 8 bits de chez Intel et un terminal industriel de saisie de marque Télémécanique? Très simple : détournement de fonctionnalité du terminal, équipé d'un processeur MCS51, pour une utilisation toute autre. Utilisation du LPC1114 pour le test de l'affichage intégré de ce terminal.

Je cherchais une machine pour y tester un montage que je viens de développer : une SRAM non volatile en mesure de remplacer bon nombre de SRAM sauvegardées par pile ou batterie que l'on trouve dans beaucoup de synthétiseurs numériques des années 80/90. Comme je n'avais pas envie de 'bricoler' sur une machine fonctionnelle et risquer de la détériorer, je cherchais une alternative adéquate. La difficulté réside aujourd'hui dans le fait de trouver une carte à processeur fonctionnant en 5V. Or depuis une dizaine d'année voire plus, l'alimentation en 3,3V est devenue la norme haute d'alimentation des circuits numériques.

Terminal XBT-A70101.

Le terminal Télémécanique répond à mon besoin en ce sens que toute la partie numérique fonctionne bien en 5V. Et, comble de la chance, ce terminal possède trois circuits mémoire dont deux sur support, l'EPROM du programme et une EEPROM qui devait être destinée à recevoir des 'plugins' par téléchargement. Cette EEPROM sera remplacée par mon montage d’émulation de SRAM non volatile, le support du circuit disposant de tous les signaux nécessaires.

L'idée consiste donc à écrire un programme simple pour le MCS51 dont le rôle sera d'écrire et de lire des données quelconques en mémoire non volatile et d'en vérifier l'intégrité par lecture. Le déroulement des opérations et éventuellement les indications d'erreur s'inscrivant sur l'afficheur intégré au terminal.

A noter que le 'design' de ce terminal est des plus basic en ce qui concerne l'utilisation du processeur MCS51. La ROM programme se trouve en espace ROM, la SRAM se trouve en espace données dans les 32 premiers ko et l'EEPROM, remplacée donc par la SRAM non volatile, dans les 32 derniers ko de l'espace mémoire. L'affichage est géré par un processeur spécialisé recevant ses instructions par liaison série synchrone sur deux signaux émanant des ports P1.0 et P1.1 du processeur. La aussi, que du classique.

Hack de la partie affichage du terminal :

La première tâche consiste donc à décoder les signaux nécessaires au processeur d'affichage. Je me suis servi de l'incontournable Openbench Logic Sniffer de Dangerous Prototype. Cet analyseur logique disponible à prix très bas n'en demeure pas moins un très bon outil d'analyse pour des investigations simples. En ce qui me concerne, et dans le cadre de l'utilisation que j'en ai faite sur le décodage de signaux fortement acycliques, la relative faible capacité mémoire de l'appareil peut cependant poser quelques problèmes d'interprétation. Fort heureusement, je savais à peu près à quelle chronologie de signaux m'attendre, ce qui a grandement facilité l'exploitation des résultats.

Open Bench Logic Sniffer.

Le terminal est en mesure d'afficher plusieurs types d'informations. De simples messages de 16 caractères de long, fixes, et des messages de type 'warning' avec seulement quelques caractères clignotants, ou d'erreur ou c'est l'ensemble du message qui clignote. Je n'ai pas cherché à discriminer les paramètres de clignotement, la version message entier me convient très bien.

Le message est composé d'un préambule, indiquant le type de message, le corps du message en ASCII standard, et un postambule fixe de valeur 0xBF.

Préambule message normal : 0x87 0x8A 0xB8
Préambule message clignotant : 0xB8 0xC0 0xCF 0xE0

Particularité du point : il doit être suivi de la lettre dans laquelle le point est inséré. Par exemple, un 'A.' sera codé par 0x2E (le point) puis 0x41 (le A). Un point seul sera donc suivi du caractère espace : 0x2E puis 0x20.

Fort de ces informations, j'ai donc utilisé ma carte de développement à base de LPC1114FN28 pour valider ce fonctionnement. La facilité de développement offerte par l'environnement de développement Mbed étant dans ce cas tout à fait appréciable.

Carte mère du terminal XBT en cours d'investigation.

J'ai tout simplement utilisé la fonctionnalité SPI du processeur LPC. Quelques lignes de codes en 'C' standard ont suffit à valider un fonctionnement 'minimum' de l'affichage. La carte LPC fournit le signal d'horloge des informations ainsi que le signal des données séries. La carte XBT alimente la carte de développement (le fil rouge), et la masse commune est reliée par le fil noir.
A noter que la carte de développement fournit des signaux en 3,3V alors que la carte XBT dispose d'une partie logique alimentée en 5V. Cela ne pose aucun problème dans ce sens puisque la norme TTL considère un niveau haut à partir de 2,4V.

Les codes 0x29 et 0x28 du troisième message correspondent aux caractères '>' et '<' du terminal. Ils ne correspondent pas aux caractères supposés équivalents du PC, raison pour laquelle ils sont présentés sous forme Hexadécimale. Ils n'appartiennent donc pas au préambule ni au postambule du message. La variable 'myplus' correspond à une patte du processeur placée à '1' permettant par l'utilisation d'un bouton poussoir dont l'état est lue par la variable Next, l'avancement de certaines phases du programme lors des tests préliminaires.

Même travail avec le processeur MCS51 embarqué :

Il s'agit de développer de façon adaptée sur du matériel 'vintage'. Pour ceux qui n'auraient pas connu la 'belle époque', il est temps de ressortir l'émulateur d'Eprom, l'effaceur d'UVPROM et le programmateur de 27CXXX...

Un aperçu de ce à quoi ressemble le système de développement :

Petit tour du propriétaire. Le signal de RESET de l'émulateur d'EPROM est relié une 'entrée' RESET de la carte. Cet émulateur a pris place sur le support d'EPROM d'origine. Juste en dessous, se trouvent le module SRAM non volatile en cours de développement, ainsi que les quelques ko de SRAM d'origine, directement soudés sur le circuit imprimé. Le contrôleur d'affichage est le gros circuit en haut à droite de la carte.

Pour ce qui est du développement logiciel, j'ai choisi la facilité. Tout d'abord l'IDE Eclipse, il s'agit ici de la version Kepler, téléchargée début juin 2014. En suite, le compilateur 'C' choisi est l'indispensable SDCC, ici en version 3.4.0 RC1 en date du 15 mars 2014. Enfin, afin qu'Eclipse 'comprenne' qu'il doit générer du code en utilisant les outils SDCC, il est nécessaire d'installer le package 'eclipseSDCC Plug-in'. Tous ces outils se trouvent sans problèmes sur le Net.

Note importante pour ceux qui souhaiteraient s'essayer au développement sur MCS51 :

Le plug-in SDCC pour Eclipse semble dater suffisamment pour poser des problèmes lors de tentatives de compilation sous Windows 7, dans mon cas en version 32 bits. Après d'intenses recherches, il s'avère que le coupable est l'interpréteur de commande à la mode Unix : 'sh'. Cet interpéteur se trouve à cet endroit : ..\eclipse\plugins\net.sourceforge.eclipsesdcc.win32_1.0.0\os\win32\x86.
La raison est un plantage plus ou moins aléatoire dans le 'fork' que 'sh' effectue pour appeler les différents exécutables SDCC lors d'une  demande de compilation émanant d'Eclipse.

Une solution simple consiste à installer un 'sh' récent en lieu et place de celui d'origine. Pour ce faire, j'ai installé le système Cygwin puis copié l'exécutable 'bash' dans le répertoire contenant le 'sh' d'origine. J'ai renommer 'bash' en 'sh' puis lancé cet exécutable afin de copier aussi les DLL nécessaires jusqu'à ce que l'exécutable n'en demande plus.

Deux ou trois autres détails permettant de faire fonctionner ce système :

- Sous Eclipse, modifier le nom de l'assembleur qui ne correspond pas au nom de l'exécutable fourni avec SDCC. Remplacer cette information par 'sdas8051'.
- Pour ne pas avoir les messages de warning continus sur le mode d'écriture des paths lors de la compilation, dans la console, créer la variable système 'CYGWIN' et lui affecter la valeur 'nodosfilewarning'.
- Enfin, démarrer Eclipse en mode administrateur.

Il resterait quelques détails à régler mais je n'y accorde aucune importance, j'utilise en effet les informations de compilation de SDCC disponibles dans la console d'Eclipse et non pas les indications du parser propre à d'Eclipse.

Bien que paraissant peut-être compliquée, une fois en place, cette solution permet de produire un fichier '*.hex' très rapidement qu'il suffit de copier dans l'émulateur d'EPROM.

En guise de premier test, j'ai repris le code d'exemple précédemment réalisé sur la carte LPC1114 à l'aide du compilateur en ligne Mbed, et l'ai recopié presque tel quel dans l'IDE Eclipse. La seule différence tient au fait que j'ai du recréer de façon artificielle le bus SPI à l'aide d'instructions de manipulation de bits et de temporisations adéquates sur les ports P1.0 et P1.1 du processeur.

Et le résultat :

En luminosité tamisée pour un meilleur affichage...

LPC1114FN28, LPC810FN8, MBED et Flash Magic.

La particularité de ces deux circuits de la famille LPC, outre le fait d'être des processeurs assez puissants de la famille ARM Cortex-M0, est de se présenter dans des boitiers DIP standards faciles à manipuler et à souder.

Après recherches sur le Net j'ai bien trouvé, soit des cartes de développement à base de LPC1114 en version cms chez Olimex avec la carte LPC-P1114 ou la carte Port1114 chez WaveShare, soit des cartes comportant bien une version de processeur en boitier DIP, mais dans un format pas très facile à utiliser comme la carte mbed LPC1114FN28. Je n'ai pas trouvé de solution me permettant de manipuler facilement un processeur LPC1114FN28 sur sa carte de développement et d'en assurer de façon simple et pratique la fonction programmateur.

Une solution plus adaptée a donc été développée :

Cette carte comporte un port série USB géré par un convertisseur standard de chez FTDI. Cette approche est avantageuse car sous Windows, les drivers sont accessibles très facilement sur le site de FTDI. Sous Linux c'est encore plus simple, les circuits FTDI sont automatiquement reconnus. La carte comporte aussi deux connecteurs 20 broches donnant accès à l'ensemble des pattes du processeur.

Concernant la programmation, deux boutons permettant le basculement du processeur dans ce mode ont été implémentés. Ces boutons sont aussi connectés aux broches DTR et RTS du circuit FTDI pour une commande possible par l'intermédiaire du port série USB.

La fonctionnalité de programmateur est assurée par la présence d'un support ZIF 40 broches permettant l'insertion d'un boitier 28 broches OU d'un boitier 8 broches, ainsi que d'un interrupteur d'alimentation du processeur. Se faisant, il est possible d'insérer un nouveau composant dans le montage sans devoir déconnecter la carte du PC. Cette approche est aussi nécessaire pour faire sortir la version 8 pattes du processeur du mode programmation.

Petit plus : une led RX et une autre pour TX sont présentes sur le port série. Il n'y a rien de plus agaçant que de ne pas avoir ces simples indications quand il s'agit de faire communiquer un tel montage avec un PC. En cas de dysfonctionnement, ces leds permettent un premier diagnostic d'un simple coup d’œil. Dans le même genre d'idée, une autre led est connectée sur une des broches du processeur, permettant ainsi la validation globale du fonctionnement du système par un simple 'Hello World'.

Outil de développement :

Il existe plusieurs solutions pour développer sur ces micro-contrôleurs. Une solution libre basée sur GCC, une solution payante basée par exemple sur l'outil de développement MDK µVision de Keil, ou la version en ligne du compilateur fournie sur le site mbed.org, elle aussi gratuite.

J'ai eu l'occasion d'expérimenter avec le produit en version limitée de Keil. Il fonctionne très bien, est très facile à utiliser mais réclame un travail préparatoire de mise en place du bon environnement pour la cible utilisée, notamment les bons codes de startup, les bonnes bibliothèques etc... Les auteurs responsables du support de la cible LPC1114FN28 sur le site mbed ont effectué tout ce travail préliminaire de sorte que développer du code devient une tâche presque accessoire.

Loin de moi l'idée de n'accorder que peu d'importance au code. Mais, dans certaines situations, cet aspect du développement d'un projet peut être relégué au second plan. Notamment quand l'utilisation prévue du processeur consiste en une tâche très accessoire. Dans ce cas, la solution mbed permet de produire pratiquement dans l'instant une application spécifique simple.

A titre d'exemple, j'ai utilisé cette solution pour produire un code capable d'envoyer des informations sur le bus SPI du LPC1114 à destination d'un contrôleur d'affichage fluorescent, dans le but d'en valider le fonctionnement. Ne possédant pas pour l'instant de 'Bus Pirate'  tel que le site Dangerous Prototype en propose pour envoyer des informations sur un bus SPI, j'ai utilisé ma carte de développement pour le faire.

'Hello World' version mbed :
 

 

L'équivalent en version µVision 4 de Keil :

Programmation de la cible :

Il existe une solution gratuite, de qualité, et facile à utiliser. Il s'agit de l'application FlashMagic. Cette application à de plus, le bon goût de gérer la mise en mode programmation du micro-contrôleur, puis le reset de la cible une fois la programmation effectuée. Programmer un LPC1114FN28 se résume pratiquement à un clic de souris!

Ce logiciel est prévu pour fonctionner sous Windows. Personnellement j'utilise Windows 7 en version 32 bits. Il existe bien évidemment d'autres solutions permettant la programmation du composant en environnement libre comme l'application lpc2lisp sous Linux.

 Flash Magic ayant récupéré les information du micro-contrôleur:

Flash Magic prêt à programmer l'application 'Hello World' générée avec µVision :

Configuration de Flash Magic pour le pilotage du mode programmation du microcontrôleur :

Note importante :

Le logiciel Flash Magic n'accepte qu'un fichier de type hexadécimal comme fichier de programmation. Or, si le logiciel µVision de Keil fournit bien ce type de fichier, le site mbed en ligne propose, une fois la compilation effectuée avec succès, de télécharger le fichier binaire résultant.
Il convient donc de convertir ce fichier binaire en fichier hexadécimal propre à être accepté par Flash Magic.

L'utilitaire DOS bin2hex, que l'on peut trouver facilement sur Internet, permet d'effectuer cette opération. Le fichier de type HEX ainsi généré peut dès lors être chargé dans l'outil de flashage du microcontrôleur.

Bug connu : Imprécisions sur le marquage de certaines informations sur la carte.
Lire LPC1114FN28 et non pas LPC114FN28.
Lire LPC810FN8 et non pas LPC810FN28.

Update 16/12/2014

La version du logiciel Flash Magic utilisée lors de l'élaboration de ce billet était la 8.11.3603. A la date de l'update, la version 8.61.3770 ne fonctionne pas correctement. La lecture du LPC810FN8 ne s'exécute plus. Le fonctionnement reste cependant correcte avec le processeur LPC1114FN28. Après avoir tenté de modifier les différentes options supplémentaires de cette version, il demeure impossible de lire le LPC810FN8, pas plus que d'en vérifier la programmation : c'est gênant!

The Flash Magic software used in this post was the 8.11.3603 version. At the time of this update, the 8.61.3770 version don't works correctly. It is imposible now to read the LPC810FN8. It still work fine with the LPC1114FN28 processor. After trying to change the various additional options in this new version, it remains impossible to read the LPC810FN8, nor to verify the programmation : it's embarrassing!

Fin de l'update.

Update 18/12/2014

J'ai envoyé un mail concernant le problème rencontré avec le logiciel Flash Magic et le processeur LPC810FN8 le 16/12/2014. J'ai reçu ce jour une réponse d'Andrew Ayre de Esacademy me demandant de tester la dernière version 8.62.3777 ou le bug a été corrigé. J'ai testé et cela fonctionne de nouveau très bien, que ce soit avec le processeur LPC810FN8 ou le LPC1114FN28. Moins de 2 jours pour traiter le problème : bravo!

I sent an email regarding the problem with the Flash Magic software and the processor LPC810FN8 at the date of the previous update. I received today an response of Andrew Ayre of  Esacademy asking me to test the latest version 8.62.3777 where the bug has been fixed. I tested it and it works very well again, either with the LPC810FN8 or LPC1114FN28 processor. Less than 2 days to address the problem: bravo!

Fin de l'update.

Vous pouvez acquérir un ou plusieurs exemplaires de cette carte équipée d'un LPC1114FN28 au prix de 57,00€ hors frais de port, dans la limite du stock disponible: