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: 

Remplacement du CEM5530 pour Prophet VS & Studio 440.

Il y a quelques années de cela, j'ai réalisé un montage électronique en mesure de remplacer un composant essentiel au fonctionnement du Prophet VS ainsi que du Studio 440 de Séquential Circuit, le CEM5530. Ce composant ne se trouve plus que très difficilement et a hélas tendance à manquer de fiabilité. Un nombre assez important de machines utilisant ce circuit ne se trouvent plus en état de fonctionnement. La version 2 de la solution de remplacement à base de circuit intégré de chez Maximintegrated est disponible.

Le CEM5530 agit comme interface entre la partie processeur numérique et la partie génération sonore de type analogique, en ce sens qu'il 'mémorise' un certain nombre de tensions préalablement mémorisées sous forme numérique dans les paramètres du son, à destination du VCA et du VCF, entre autre. De façon schématique, chaque CEM5530 agit donc comme 30 potentiomètres commandés par le processeur. Le Prophet VS en possède deux pour un total de 60 signaux de commande, le Studio 440 n'en possède qu'un.

Le schéma du CEM5530 :

La partie de la carte analogique du Prophet VS utilisant ce CEM5530 :

Ce sont les circuits notés U449 et U425.

A l'origine, il avait été développé une carte s'enfichant directement à la place du CEM5530 d'origine. Cependant cette carte ne comportait pas toute la gestion des alimentations. Deux modifications mineurs étaient donc nécessaires sur la carte de synthèse du Prophet VS ou du Studio 440. La version 2 de ce circuit comble ce manque en fournissant directement toutes les tensions nécessaires de sorte qu'il suffit d'ôter le CEM5530 défectueux et de le remplacer tel quel par le circuit de remplacement pour que le synthétiseur refonctionne normalement.

La version 2 du remplaçant du CEM5530 :

Ce circuit doit être inséré en lieu et place du CEM5530 d'origine de la façon suivante sur un Prophet VS :

A noter que les supports de circuits intégrés utilisés dans le Prophet VS ne sont pas, non plus, très fiables. Ils sont de type double lyre et non pas tulipe, et ont tendance à avoir les pattes qui cassent au niveau des soudures. Sur cette photo, les deux supports de CEM5530 ont aussi été remplacés.

La ré-édition de la version 2 du circuit de remplacement se présente sous la forme suivante...

... en compagnie d'un CEM5530 d'origine et fonctionnel. Les deux composants sont présentés dans le même sens, pin n°1 en bas à gauche.

Cette deuxième édition de la version 2 est fonctionnellement identique à la première si ce n'est la couleur du circuit imprimé, et quelques arrangements de pistes. La voici au sein d'un Studio 440 :

Plus d'informations :