mardi 1 septembre 2015

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.

mardi 25 août 2015

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

jeudi 23 juillet 2015

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

mardi 7 juillet 2015

Carte de développement pour le système Micromite MKII.

En matière de programmation, il existe une multitude de langages disponibles. Suivant le matériel sur lequel devra s'effectuer le programmation, seuls certains d'entre eux seront disponibles. En effet, les ressources matérielles mais surtout systèmes, nécessaires à l'exécution d'un programme, peuvent être du tout au tout différentes.

Pour programmer un matériel simple, typiquement un petit processeur ou plus généralement un micro-contrôleur, il est possible de distinguer deux grands type de langages. Ceux nécessitant la présence d'un système d'exploitation, et les autres. Un langage interprété comme Phython par exemple ne fonctionne que sous environnement Linux (en général) et exploite largement les ressources fournies par ce système. Ce type de langage n'est donc pas imaginable sur un système simple.

Par contre, il existe d'autres langages dits évoluées qui permettent la programmation d'un tout petit système. Pascal, C/C++, Basic et autres du même type sont parfaitement adaptés à cet usage. Dans cette catégorie de langages, il est encore possible de différencier les langages compilés et les langages interprétés.

Un langage compilé sera en fait interprété une fois par un programme particulier, le compilateur, qui produira un fichier exécutable qui devra être écrit dans le petit système. Dans ce cas, le compilateur est exécuté sur une machine différente que celle sur laquelle devra s'exécuter le fichier exécutable.

Un langage interprété consiste en fait en un programme qui lit constamment des lignes de code et en exécute les instructions. C'est le cas du Basic, donc de l'interpréteur Basic. Ce type de solution peu paraître inefficace car même dans une boucle exécutant mille fois la même chose, l'interpréteur exécutera mille fois le décodage et l'exécution des mêmes instructions.

Le Basic Microsoft, omniprésent dans les années 80
Relativisons, même s'il semble évident qu'un programme écrit en Basic s'exécutera bien moins rapidement qu'un programme compilé, les ressources disponibles aujourd'hui permettent de ne pas trop avoir à se soucier de cet aspect des choses. D'une part on ne demandera jamais à un petit système à processeur de gérer des fichiers ou d'effectuer du traitement de signal comme peuvent le faire les 'gros' processeurs et les PC.

De plus, certains 'artifices' permettent d'augmenter artificiellement la vitesse d'exécution d'un programme écrit en Basic. Le procédé est simple, il suffit d'écrire dans un langage compilé, donc plus rapide, des bouts de codes particuliers et de les exécuter en les appelant depuis un programme écrit en Basic.

C'est exactement ce qu'est capable de faire l'interpréteur Basic Micromite MKII écrit par Geoff Graham.

Encore mieux, cet interpréteur laisse la possibilité à l'utilisateur, s'il maitrise bien la programmation en langage 'C' par exemple, de créer ses propres bouts de programmes compilés, de les insérer et de les exécuter dans un programme Basic. Si l'on rajoute à cela que l'interpréteur Basic dont il est question fonctionne sur un processeur rapide fonctionnant à quelques 50Mhz, on se retrouve assez éloigné des faibles performances des machines programmables en Basic des années 80 dont certaines ne fonctionnaient même pas à 1Mhz. Et pourtant, de belles choses furent réalisées avec ces anciennes machines comme avec le Commodore 64 et son Basic intégré, équipé d'un processeur 8 bits fonctionnant à 1,023Mhz :

Un des ordinateur de l'époque les plus vendu au monde!
J'ai déjà eu l'occasion de comparer la vitesse d'exécution du Basic de Geoff Graham avec celle de l'interpréteur présent dans le fameux PC1500 de Sharp. J'arrive à un rapport de 200! Pour fixer les idées, Micromite MKII exécute en 1 seconde, ce qui demande un temps de plus de 3 minutes au PC1500!

Le vénérable PC1500A de sharp
De plus, Micromite MKII fournit une interface complète et bien pensée pour divers composants électroniques comme des horloges temps réél, des décodeurs de télécommande infra-rouge etc etc...
Il devient alors très facile avec ce système, d'écrire des applications sophistiquées et faciles à maintenir, sous réserve toutefois que le programme ait été bien écrit et facile à comprendre.

Que dire des capacités? 80 Koctets sont disponibles en flash pour l'écriture des programmes ainsi que 52 Koctets en RAM pour les variables basic, soit environ 130 Koctets au total!. Evidemment à côté des gigas octets de mémoire dont sont équipés aujourd'hui nos PC, cela semble bien ridicule. Ne pas perdre de vue que la finalité du système n'est pas du tout la même. Allumer une ampoule avec un bouton ne requiert que quelques octets sur Micromite MKII, mais requiert des mégas octets sur un PC!
Le prix n'est pas le même non plus. Quelques dizaines d'Euros pour un système confortable basé sur Micromite MKII, des centaines d'Euros pour un PC, voire des milliers pour un Mac!

Et tout cela, dans ceci, pour quelques Euros :

Pour beaucoup de programmeurs, Basic est largement dépassé. A mon sens, cela ne veut strictement rien dire. D'un point de vue technique tout d'abord, un petit système programmable dans ce langage permet de réaliser très rapidement des applications fiables. Null besoin de posséder de grosses compétences en C#, en framework, en OS, et de posséder une grosse équipe de programmeur pour réussir, après des mois d'efforts et des dizaines de milliers d'Euros dépensés, à programmer une application somme toute tout juste à peu près convenable! Ensuite d'un point de vue plus philosophique, avec un tel système Basic, une seule personne peut être en mesure de réaliser de petites applications performantes en un minimum de temps et pour un cout minimum tout en restant totalement autonome sur les ressources et donc affranchi des contraintes de droit, de redevance, d'obligation de quoi que ce soit envers qui que ce soit. Seules, la compétence, l'autonomie et l'inventivité du programmeur, de la programmeuse, deviennent importantes.

Il semblerait d'ailleurs que Microsoft, qui après s'être nourri, devrais-je dire gavé, dans les années 80 de l'essor de la micro-informatique avec son Basic, et aillant contribué dès les années 90 à exploser le milieu pour tenter d'en devenir le seul maitre à bord, ait commencé à comprendre la situation actuelle ou de nouvelles compétences se développent, de nouveaux réseaux se montent, de nouvelles applications naissent, totalement en dehors de son contrôle. D'ou la très grosse opération actuelle de racolage tout azimut dans le petit monde de l'embarqué envers ceux qui étaient considérés il n'y à encore pas longtemps, comme des amateurs sans intérêt.

Incroyable non? Est-il vraiment aussi abordable que les premiers Basics?
N'adoptez JAMAIS les produits Microsoft! Le seul but de Microsoft est aujourd'hui de tenter de reprendre le contrôle des nouveaux écosystèmes naissants. Ne vous laissez pas faire. Microsoft ré-itérera ce qui s'est passé dans les années 90. Dès que vous serez pieds et poings liés avec lui, il vous explosera!!! Il n'a jamais été question pour cette entreprise de considérer un contrat gagnant/gagnant. C'est vous qui travaillez, c'est eux qui encaissent! J'ai à plusieurs reprise fait état de cette attitude désastreuse de Microsoft dans mon Blog... Je devrais aussi ajouter qu'il est nécessaire de se méfier de l'Education National, qui, loin de générer de l'autonomie en interne sur le sujet de l'informatique, se contente souvent de suivre la mode et la facilité en adoptant les ressources fournies 'gracieusement' par différents type de sociétés comme Microsoft!

Si vous souhaitez faire de l'informatique, veillez scrupuleusement à votre autonomie, cultivez VOS compétences, et ajoutez-y VOTRE façon de voire la chose!

C'est dans cet esprit que Geoff Graham a créé son superbe Basic! Je considère qu'il était presque de mon devoir, d'une part de l'utiliser, d'autre part d'en faire ici la 'publicité'!

Bien que toutes les informations nécessaires soient disponibles sur le site de Geoff, le montage d'un système minimal peut s'avérer un peu compliqué quand on ne possède absolument aucune compétence ne serait-ce que minimum en montage électronique. Il n'était pas question cependant de proposer une machine du type de celles disponibles dans les années 80 comme le commodore 64 précédemment cité, mais plutôt une carte d'étude se prêtant bien à de multiples expérimentations, facile à utiliser et peu onéreuse. Voici donc la carte que j'ai développé spécialement pour ce système Basic :

Le système, prêt a fonctionner.

Le processeur possède déjà l'interpréteur Basic. Il m'a été possible d'écrire le fichier programme de cet interpréteur dans le processeur après l'avoir téléchargé du site de Geoff puis transféré à l'aide de l'outil Pickit 3 de Microchip :
J'ai en effet implémenté sur la carte de développement, le connecteur permettant d'y raccorder le programmateur d'une façon simple et efficace. De ce fait, il sera possible à tout moment de reprogrammer le processeur avec une nouvelle version de l'interpréteur Basic. Il peut en effet arriver qu'un bug apparaisse au fil du temps, qui mérite correction, ou que l'ajout éventuelle de nouvelles fonctionnalités rende intéressante la mise à jour du processeur.

Configuration pour la programmation du firmware Basic

L'utilisation du programmateur Pickit 3 est simplifiée grâce au logiciel disponible en téléchargement sur le site de Microchip, le fabriquant du processeur. Bien que l'opération de programmation du processeur ne soit pas très compliquée, elle impose tout de même l'installation du logiciel Microchip,  MplabX,  sur un PC qui devra être assez moderne et fonctionner sous Windows. A titre indicatif, voici les opérations à suivre pour reprogrammer le processeur avec le fichier Micromite :

1- Dans la page principale du logiciel MplabX, demander l'importation d'un fichier hexadécimal :


2 - Une fenêtre apparaît alors ou il est nécessaire de renseigner l'endroit ou le fichier hexadécimal a été sauvegardé, ainsi que le type de processeur et de programmateur utilisé :


Le processeur est un PIC32MX170F256B.
Le programmateur est le PICkit3

3- Après validation de la fenêtre précédente, le logiciel revient sur sa page principale en affichant certaines informations :


A gauche, le logiciel à bien accepté le fichier ainsi que le type de processeur configuré.
En haut, l'icône de programmation vers le processeur est devenue active.

4- C'est sur cette icône qu'il faut cliquer pour lancer le processus de programmation. Ce processus démarre alors en faisant apparaître les différentes 'sortie' d'affichage du programme. J'ai agrandi vers le haut cette partie pour rendre lisible un maximum d'informations sur le processus de programmation :



J'ai sélectionné la 'tab' PICkit 3 pour suivre le déroulement du processus avec le programmateur. Tout semble bien se passer...

Au bout d'un certain temps, la programmation s'est effectuée :


5 - Il ne reste plus qu'à tester le système. Pour cela il faut retirer le programmateur PICkit 3 et appuyer sur le bouton RESET après avoir démarré un émulateur de terminal sur le PC, configuré sur le bon port de COM à 38400 baud. Le message suivant apparaît alors :


Pas de doute, le système fonctionne!

6- Il ne reste plus qu'à tester l'interpréteur Basic en tapant exactement l'exemple fourni dans la documentation du système :


Et la LED que j'ai installé à cet effet sur la carte de développement se met à clignoter.

Simple? Effectivement. Et maintenant, les ressource de ce Basic et de ce processeur étant assez complète, il ne reste plus qu'à envisager des application et à les développer, tout simplement!

Des remarques ou des suggestions :

dimanche 5 juillet 2015

ATmega168pb : la réalisation.

Après avoir publié quelques articles sur le processeur ATmega168pb de chez Atmel, et notamment le début de projet de création d'un thermostat un peu particulier, voici enfin le 'vrai' début de la réalisation concrète de l'appareil :

Le coté utilisateur.

L'envers du décor.
Voici donc le prototype du thermostat en cours d'étude. Sur la 'face avant', l'affichage trône en bonne place alors que l'on retrouve sur l'autre face, l'ensemble des composants précédemment testés, a savoir le processeur, le modem, le capteur de température et d'hygrométrie plus un superbe module de détection de CO2 de marque Senseair.

Pour élaborer cette carte, ainsi que toutes celles que je présente dans ce blog, j'utilise le logiciel gratuit et très facile d'accès : Kicad. Logiciel qui devrait être téléchargeable a cette adresse : www.kicad-pcb.org.

Je n'ai pas testé ce logiciel sur le PC équipé d'un Pentium III a 800Mhz et Windows 2000 que j'ai récupéré récemment, mais quelque chose me dit que cela devrait fonctionner étant donné que Kicad utilise des ressources de programmation libres. Un test que je me dois d'effectuer.

Un gros travail de programmation reste maintenant a effectuer sur cet appareil, en supposant qu'aucune erreur n'ait été commise lors du processus de développement et d'assemblage de la carte!

Pour une fois, je peux dire que la période des vacances tombe mal! Les projets en cours risquent de marquer un temps d'arrêt durant cette période, propice néanmoins au repos et a la réflexion...


samedi 4 juillet 2015

How to upgrade the programm memory of the prophet VS...

Like many devices of the late 80s, the parameters memory was often backuped by an internal battery. It is the case of the Prophet VS synthesizer. The 'patch memory', plus some of the internal parameters site in a couple of a static ram electricaly backuped by a lithium battery.

But after many years, the capacity of the battery become insufficient to ensure a proper backup of the SRAM when the Prophet VS is powered off. Worse, when the lithium battery is very 'out of date', it is possible to observe a leak of acid liquid witch spreads off the circuit board. It could be really catastrophic for the printed board.

So, since a few month, I create nonvolatile memory replacement for the standard SRAM in 2, 8, 16 or 32 Kbytes.
I decided to create a special edition for the Prohet VS. Special because I had to respect a protection against the potentially corruption of the data by writing wrong values at wrong addresses at the power on of the synthesizer. I had to create a special circuit board for that and replace the original SRAM with the new nonvolatile SRAM.

First, the main board of the prophet VS :


A very classical 68000 board!
As you can see, there are the two backuped SRAMs between the two ROMs. The first operation was to remove them :

Without SRAMs and without the battery.
Then, I also remove the internal battery. The next step was to place two supports for the new nonvolatile SRAM, then to put them into the supports like this :

A main board up to date !
As you can see, not only the two nonvolatile SRAM are in place, but the battery space in now empty. Furthermore, you can observe tiny connectors on the two nonvolatile SRAM.
No! You don't dream, this connectors will allow you to select ONE of the FOUR bank now availables!!!
Yes, it is possible because the original SRAM are 8 Kbytes capacity, but the new one have a 32 Kbytes capacity.

And the result :

One more improvement!

  • No more battery.
  • 400 programm capacity, into nonvolatile SRAM.
  • Two ELD5530, my CEM5530 replacement.

If it continues I will rebuild this Prophet VS by myself !!!

And, does it work? Yes, of course!

I have to reload my patches into one of the four ram bank, and to find a solution to select the four banks now availables. I don't have decided yet how to do that. I want to conserve the original look of my VS, so perhaps a kind of 'programmer' like the PG200 of the JX3P...


lundi 22 juin 2015

Impossible de résister au plaisir...

Mise en situation : je possède depuis quelques semaines un lecteur de bandes audio de type K7 de marque Luxman, modèle K250. Cette machine m'a été donnée lors d'un 'vide grenier' :

http://archiwumallegro.pl
Il ne s'agit pas ici de la machine en ma possession, mais d'une image récupérée sur le web. La mienne est en meilleur état cosmétique mais présente une panne un tantinet gênante.

Le compteur numérique ne fonctionne plus. Dans le cadre d'une utilisation standard cela ne doit pas poser de problème. En fait, si. Et même un gros problème! C'est aussi ce compteur qui gère l'arrêt de défilement de la bande, dans quelque mode que ce soit, dans les deux sens.

Et lorsque cette fonctionnalité disparait, et bien la machine ne s'arrête plus. Et le moteur, bien que la mécanique soit bloquée a cause de la butée de fin de bande, continue de tourner. La courroie de transmission fini par se détendre dans un premier temps puis, lorsque la tension de celle-ci n'est plus suffisante, l'axe du moteur fini par tourner dans cette courroie immobile jusqu'à l'user, puis la casser.
Ne reste alors plus que la partie cabestan qui fonctionne, ce qui a pour effet de 'bourrer' le tiroir de bande sortie de la cassette et non embobinée a l'intérieur pour cause d'absence de bobinage ou de rembobinage.

Se faisant, la platine cassette ne fait plus du tout défiler la bande : 'game over' !

La première étape a donc consisté a remettre une courroie de défilement en place. Ce qui fut fait facilement:

La nouvelle courroie de défilement est la plus petite.
La mécanique une fois remontée :

Rien de bien compliqué.
Ceci étant, j'ai quand même du passer un certain temps a 'dépoussiérer' cette mécanique car elle pressentait une grosse quantité de particules de caoutchouc en provenance de l'ancienne courroie dégradée.

Et maintenant? Le lecteur fonctionne parfaitement et procure un son tout a fait agréable et défini. Mais la mécanique ne s'arrête toujours pas toute seule! Il convient donc de refabriquer ce compteur parce que le circuit intégré qui gère cette fonction est introuvable sur le net, pas plus d'ailleurs, qu'une platine K250 en occasion!

Est-il intéressant de s'acharner sur une telle machine?  Si l'on considère le seul point de vue financier, non, bien évidemment. Cependant, ce point de vue me semble... un peu court!

D'une pat la machine est totalement fonctionnelle et procure une sonorité tout a fait digne d'intérêt. Elle est bien construite, même si le circuit imprimé n'est pas en époxy. Elle est équipée de trois têtes permettant de faire du monitoring. Elle a été bichonnée par son ancien propriétaire hélas aujourd'hui disparu. Plus un ensemble d'autres raisons suffisantes pour s'attaquer au problème, comme le simple 'challenge' consistant a redonner une nouvelle vie a un matériel passé de mode, certes, mais absolument pas obsolète!

Et voila un 'exercice de style' tout a fait trouvé pour la nouvelle carte de développement a processeur Zilog que je viens de développer. Je détaillerai plus tard tout le processus de création de ce compteur électronique a affichage fluorescent, lorsqu'il sera monté dans la machine.

Mais pour l'heure je ne peux résister a l'envie de présenter une petite démo. du 'proof of concept' du sujet :


Vidéo effectuée en basse lumière pour que les segments du tube soient visibles. Le programme du processeur se contente d'effectuer une boucle envoyant en série des données a un circuit prévu pour 'driver' des 'hautes' tensions. Un seul des trois digits est câblé.

Deux heures, temps de câblage et temps de programmation, pour arriver a ce résultat. Il est vrai que je n'avais pas programmé de microcontroleur Zilog depuis presque une dizaine d'années : quelle erreur d'avoir abandonné ces circuits...