jeudi 21 décembre 2017

Ah, la propagande 'à la française'. Ou l'art d'amuser la gallerie à 5 millions d'Euros! (bis)

Il y a maintenant un an de cela, je publiais sur ce même blog une prestation vidéo de David L. Jones au sujet de la route solaire développée par l'entreprise de travaux publics Colas, et présentée en grande pompe par la ministre de l'écologie de l'époque, l'inimitable Ségolène Royal.

Pour rappel :


Après la mise en service de cette route, puis 11 mois d'exploitation, voici venu le temps d'un petit compte rendu par notre cher Dave :


Ce qui est bien avec Dave, c'est que non content d'avoir critiqué la démarche, il présente ici les résultats de cette hérésie bien française, chiffres à l'appui.

Sans doute un très joli coup de pub pour notre 'macadamiseur' national, financé avec l'argent du 'bon peuple' français, et sponsorisé par une ministre (malgré le haut degré de ridicule que peu dégager cette personne) en VRP de l'excellence (à la) française. Au delà de l'aspect totalement idiot d'un point de vue pratique d'une telle démarche, que penser du fabuleux Green Washing que présente ce genre d'initiative. Je vous laisse juge :


Oui, mais bon, c'est bien d'avoir tenté la chose pour montrer qu'on pouvait le faire. On peut le voir de cette façon. Les ingénieux ingénieurs français pourraient sans doute être 'utilisés' à meilleur escient...

A n'en pas douter, la France est une démocratie, dans le principe en tout cas. Après, tout se discute. Argons que la constitution française mise en place en 58 pour en définir et restreindre le strict exercice, n'en est encore qu'à ses débuts, et que l'heure de la maturité n'a pas encore sonné!

Et à propos de totem de l'excellence, en voici un qui trône en ce moment quelque part sur du macadam non 'photovoltaïsé' par Colas, qui à fonctionné une quinzaine d'années sur le bon vieux réseau nucléaire/charbon du pays. Restes d'un ancien abris bus Clear Channel en cours de remplacement par l'autre, le J.C. Entretien, rénovation? Mais non voyons : gaspillage, gaspillage, gaspillage, à unique but commercial. Il est vrai que je n'ose même pas me poser la question du recyclage!


vendredi 15 décembre 2017

DOMOTIQUE et PLCs en ARDUINO.

Petite brève,

Il y a quelques mois de cela, j'ai reçu commande pour la mise en place d'un système de surveillance permettant d'une part la réalisation de petits automatismes locaux ainsi que l'avertissement des actions menées, notamment par GSM.

Après avoir testé diverses solutions commerciales, tant en provenance du milieu de la sécurité que de celui de l'automatisation plus 'dure', je n'ai pas été en mesure de trouver le système adéquat.

Plusieurs raison à cela, dans le désordre : le prix, la flexibilité, la simplicité de câblage, l'adaptabilité, les interfaces disponibles, le facilité de maintenance et de suivi etc etc...

Au départ de ma réflexion j'avais testé un système personnel basé sur une compatibilité Arduino Uno. Bien qu'étant arrivé assez facilement à  résoudre la problématique de base, le système s'est avéré largement insuffisant lorsqu'il s'est agit d'incorporer divers autres éléments.

J'ai donc repris mon étude de base mais cette fois sur une compatibilité Arduino Mega 2560. Le processeur dans ce cas possède suffisamment de broches additionnelle pour gérer 'mes' entrées/sorties tout en fournissant la possibilité de disposer de l'ensemble des ports pour un shield standard, notamment le shield GSM.

Le résultat est un type d'automate vraiment prévu pour l'application envisagée, au moins sur le plan matériel. La programmation à l'aide de l'IDE Arduino devrait permettre un développement relativement aisé de l'application. Sous réserve bien entendu des limitations propres à la philosophie Arduino. Mais cet appareil n'aura pas à réagir sous de fortes contraintes de temps réel.

Voilà ce que donne le schéma général :


Plus de 170 composants pour cette carte électronique. J'espère que le PCB ne sera pas trop difficile à réaliser.

Evidemment, ce circuit ne correspond à aucune norme. La conception respecte cependant les règles de sécurités électrique et de protection contre les différent types de surcharges. La programmation ne respectera non plus aucun norme 'officielle' d'automatisme en ce sens ou se sera donc... du 'C' standard. Mais, avec cette solution, j'espère arriver à un système fonctionnel et le plus adapté possible aux besoins.


mercredi 29 novembre 2017

RETRO-COMPUTING, Minipro TL866A and The Wichit Sirichote Z80 MICROPROCESSOR KIT

Petite information que je pense pouvoir être utile à ceux qui, comme moi, travaillent à l'occasion sur des anciennes machines équipées de composants programmables du type GAL.

Se procurer un programmateur de type professionnel est la plupart du temps d'un prix disproportionné par rapport au besoin. S'il est encore relativement aisé de se procurer un programmateur d'UVPROM digne de ce nom à pris correct, il n'en va pas du tout de même pour ces composants de type GAL.

Je possède depuis un peu plus d'un an ce type de programmateur assez connu qu'est le Genius 540 :


 Soyons clair : il est à déconseiller fortement. Plusieurs raisons à cela.

  • Le logiciel n'est plus mis à jour depuis longtemps.
  • Il ne fonctionne à peu près bien qu'avec des PC relativement lents.
  • La programmation des GAL plante lamentablement.
Je pense d'ailleurs que le protocole de communication USB n'est pas fonctionnel, ce qui a pour effet j'imagine, de ne pas respecter les temporisations minimum pour la programmation lorsque le PC est en mesure de délivrer trop rapidement les données. En ce qui me concerne, je n'arrive à programmer les UVPROM standards que sur un PC portable de dix ans d'âge. J'ai essayé sur trois autres machines plus récentes en obtenant un pourcentage d'erreur de programmation de plus de 90%. Et bien entendu la programmation de GAL plante, même sur le portable avec lequel cela se passe le mieux.

Après avoir lu un bon nombre de commentaires à son sujet, j'ai fini par adopter le 'fameux' Minipro TL866A pour une soixantaine d'Euros. 


A ce prix-là, il est intéressant de tenter le coup. Je n'ai pas encore testé la programmation d'UVPROM, mais je peux déjà indiquer que la programmation de GAL se passe effectivement très bien : 


Le message est clair. De plus, et de ce que j'ai pu constater, le fonctionnement en liaison avec le PC semble beaucoup moins hésitant qu'avec le Genius. J'ai lu par ailleurs que la programmation des GAL était fonctionnelle depuis la version 6.5 du logiciel. J'ai installé la version 6.60 disponible ici et ai pu constater le bon fonctionnement de la programmation d'une GAL de marque Lattice 16V8A.



L'objectif de cet achat, outre le fait de pouvoir travailler sur d'anciens équipements, était d'être en mesure de mettre à jour les fonctionnalités du Kit à Z80 de Wichit Sirichote


pour le rendre compatible avec le µPF--1 : 


qui, à la base, ressemblait à ceci : 


L'objectif est donc presque atteint. Il me reste à programmer une ROM avec le nouvel interpréteur de commande compatible µPF1 et ce sera chose faite.

Et donc, à moins que je rencontre des problèmes dans mes futurs opérations avec ce TL866A, je conseille fortement ce programmateur qui semble se comporter de façon correcte et dont le logiciel PC d'exploitation est toujours mis à niveau.

01 décembre 2017 : voilà la chose faite! Avec ce Minipro TL866A, j'ai pu programmer sans difficulté une nouvelle mémoire de type AM27C256 avec le nouvel interpréteur de commande créé par Wichit Sirichote :



Avec la GAL16V8A précédemment programmée par ce même TL866A, voici le résultat final :


Et de plus près :


Ce kit de développement est tout autre chose que la plateforme Arduino, l'approche est plus 'Hold Style' mais aussi plus fidèle à l'Esprit d'origine de la micro-informatique. Avec un bon compilateur SDCC, il devient de fait très facile d'expérimenter l'assembleur, même en ligne dans du source 'C'. Le connecteur présent sur la carte permet en outre bon nombre d'extensions. Donc, pour qui souhaite se familiariser au fonctionnement de base du microprocesseur, avec des circuits simples à comprendre et à programmer, ce type de kit est idéal.

Concernant le programmateur TL866A : durant son utilisation, j'ai pu constater que lors d'un chargement de fichier HEX dont une adresse se situe en dehors de la capacité d'adressage du composant sélectionné, le programme indique clairement le problème. Ce qui n'est pas le cas du programme du Genius 540. De même, l'application du TL866A retrouve et affiche les 'ID's des composants placés sur le support de programmation et en effectue la comparaison avec celle sélectionnée dans l'interface graphique. En cas d'erreur, le problème est signalé et permet donc d'éviter de détruire un composant avec une tension de programmation inappropriée, ce qui n'est pas le cas avec le G540. Je n'ai pas testé pléthore de composants avec ce TL866A mais au moins les opérations effectuées se sont toutes déroulées à leur terme, sans problème ni ambiguïté, ce qui n'est évidemment pas du tout le cas du G540 : c'est définitivement dit!

A noter que Wichit Sirichote propose nombre de kit de ce type basés sur différents processeurs dont le fameux 6502 ayant équipé l'Apple I et la famille des Apple ][. La description de ce kit peut être trouvée ici. La page générale de Wichit se trouvant à cet endroit : http://www.kswichit.com, et la disponibilité de tous ces matériels sur eBay...

Bonnes expérimentations.


mardi 28 novembre 2017

Changement d'adresse mail de contact.

Parce qu'à un moment il faut quand même se résoudre à quitter le service mail de Yahoo pour quelque chose d'un peu plus efficace, j'ai donc ouvert une nouvelle boîte mail chez netcourrier.com :





lundi 6 novembre 2017

JX10P, MKS70...

Ceci n'est pas un article à proprement parlé mais juste un petit 'pense bête' concernant le synthétiseur Roland JX10P : 




J'ai eu l'occasion par le passé, de m'intéresser à cette machine lors de la remise en état de l'exemplaire que je possède, et force est de constater qu'il y a aujourd'hui un bon nombre de nouvelles améliorations disponibles. Elles sont assez bien résumées sur cette page, que je mets donc en référence http://super-jx.com :

http://super-jx.com

ou ici pour les dernières nouveautés JX10P News.

RETROAKTIV PG-800 MINI Bare PCB & Overlay Kit for JX-8P & Super JX :


samedi 21 octobre 2017

Ecran tactile pour PLC. Episode 2

Après la réalisation matérielle de ce type de projet, et les inévitables séances de débogage, vient le temps de la programmation. A noter que ce montage simple n'a présenté aucun défaut de conception, si ce n'est un petit souci que j'évoquerai plus bas.

Je n'ai pas souhaité rendre ce montage compatible Arduino, c'est donc avec l'outil d'Atmel, Studio 7, et le programmateur AVR Dragon que j'ai effectué la totalité la programmation. Rien de bien compliqué ici sachant que son rôle consiste 'juste' à transmettre des données reçues en RS485 avec une vitesse de 2400 à 115200 Bauds, à un écran 'intelligent' réglé à une vitesse de communication de 115200 Bauds. Le gros principe de l'application étant juste la gestion de buffers circulaires de mise en tampon des donnés.

Les premiers test ce sont effectué en situation presque réelle :


Un écran intelligent est connecté sur le module de conversion de vitesse et de type d'interface, ce module étant relié en RS485 à un automate Controllino. L'automate est alimenté par son port USB directement sur le PC de développement. Le module de conversion et l'écran sont reliés à une alimentation de 12V.


Le bouton de droite 115200 permet de configurer la vitesse de communication de l'écran à 115200 Bauds. Le bouton Display... permet d'afficher la valeur en cours du Baud rate. Plusieurs informations en provenance de l'automate en 19200 Bauds sont retransmises à l'afficheur en 115200 Bauds. Il s'agit de l'heure et de la date qui sont transmises au début de l'application, puis de la valeur de comptage qui est simplement incrémentée dans la boucle principale du programme de l'automate :

#include <Controllino.h>

  int ledPin = 13;
  unsigned char Buffer[32];
  unsigned char EndBuffer[] = {0xFF, 0xFF, 0xFF, 0x00};
  unsigned char NumberBuffer[8];
  unsigned int  NumberTest = 0;

void setup() {
 
  DDRJ = DDRJ | B01100000;
  PORTJ = PORTJ & B10011111;
  PORTJ = PORTJ | B01000000;
  pinMode(ledPin, OUTPUT);
  Serial.begin(19200);
  Serial3.begin(19200);
  strcpy(Buffer, "rtc3=17");
  strcat(Buffer, EndBuffer);
  Serial3.print((char *)Buffer);
  strcpy(Buffer, "rtc4=36");
  strcat(Buffer, EndBuffer);
  Serial3.print((char *)Buffer);
  strcpy(Buffer, "rtc5=00");
  strcat(Buffer, EndBuffer);
  Serial3.print((char *)Buffer);
  strcpy(Buffer, "rtc2=21");
  strcat(Buffer, EndBuffer);
  Serial3.print((char *)Buffer);
  strcpy(Buffer, "rtc1=10");
  strcat(Buffer, EndBuffer);
  Serial3.print((char *)Buffer);
}

void loop() {

  delay(1000);
  digitalWrite(ledPin, HIGH);
  strcpy(Buffer, "n6.val=");
  itoa(NumberTest++, NumberBuffer, 10);
  strcat(Buffer, NumberBuffer);
  strcat(Buffer, EndBuffer);
  Serial3.print((char *)Buffer);
  Serial.print((char *)Buffer);
  delay(1000);
  digitalWrite(ledPin, LOW);
}

Programme de test réalisé sans aucune volonté de perfection...

Les instructions
DDRJ = DDRJ | B01100000;
PORTJ = PORTJ & B10011111;
PORTJ = PORTJ | B01000000;
servent 'juste' à configurer les pattes /RE et DE du tranceiver interne du Controllino afin que les données émises sur le port série n°3 partent bien en RS485.
La variable EndBuffer initialisée à {0xFF, 0xFF, 0xFF, 0x00} est obligatoire car toute instruction transmise à l'écran doit se terminer de la sorte. Les différentes variables rtcx correspondent à l'initialisation des différentes variables de l'heure et de la date qui sont mises à jour automatiquement par l'afficheur lui-même. Enfin n6, correspond à la variable affichée au milieu de l'écran, mise à jour toutes les secondes par l'automate.

Les premiers tests s'avèrent concluants. Même avec une communication RS485 en 2400 Bauds, l'écran répond correctement en 115200 Bauds. Ne connaissant pas la façon dont est effectué la gestion de la communication série au sein de l'écran, il était en effet possible qu'un time-out un peu trop 'serré' à la réception de caractères empêche ce dernier de considérer une trame correcte,  valide. Mais il n'en est rien, à ma grande satisfaction.

Que reste-t-il à faire? D'un point de vue programmation, il reste à gérer la manipulation en temps réel du bloc de switchs afin de configurer le ports série du processeur qui gère le port série RS485 en temps réel.

D'un point de vue matériel, la partie alimentation à découpage implémentée sur cette carte d'interface est un peu trop juste pour l'écran de 7". La puissance demandée par les écrans de taille inférieur ne pose pas de problème au régulateur à découpage, mais le 7", avec ses 500mA de consommation, arrive en limite de ce qu'est capable de débiter l'alimentation. Dans ce cas, le régulateur ainsi que la self montent déjà un peu trop en température. Il faudra donc envisager une solution d'alimentation un peu plus cossue.

26 octobre 2017 : Après avoir implémenté la gestion des erreurs de communication, l'heure du bilan à sonné. Un peu de la même façon que ce qui est arrivé avec le switch MIDI (qu'il faut que je continue de développer d'ailleurs) et le processeur PIC utilisé au départ, puis remplacé par la suite par un processeur ARM de chez ST, je vais étudier une nouvelle version équipée elle aussi d'un processeur ARM de ST.

La raison principale de ce choix est, la aussi, un manque de flexibilité des processeurs de type ATmega. Sur ces derniers, il est difficile d'effectuer un débogage en temps réel. Or, avec le peu de temps dont je dispose pour mes développements, il m'arrive souvent de tester des petits bouts de code sur un montage laissé de côté depuis un certain temps. Ne me souvenant plus de tous les détails, il devient alors compliqué de comprendre la raison du non fonctionnement du code en test.
Pouvoir jeter un œil sur un registre devient alors primordial. Et puis l'IDE Atmel est lourd, vraiment trop lourd. Installer des centaines de méga pour du processeur 8 bits... Allez donc voir ce que propose Zilog depuis des décennies avec le ZDSII. Si seulement Zilog avait eu la bonne idée de rajouter un peu de RAM dans ses micro-contrôleurs. Mais ceci est une autre histoire.....

Je vais aussi en profiter pour améliorer un peu le concept de cette carte en y ajoutant quelques fonctionnalités qui me semblent intéressantes afin de la rendre un peu plus versatile que ce qu'elle est aujourd'hui. Un port RS232 me semble une option valable. Il y a en effet quantité de matériels 'anciens' qui fonctionnent avec ce type d'interface. Pouvoir les passer en 485 opto-isolé me semble être une bonne idée.

A suivre... 

01 décembre 2017 : après avoir cherché des solutions d'alimentations à découpage qui ne soient pas trop complexes à implémenter sur une petite carte, d'un prix 'acceptable' et d'une capacité en courant suffisante, j'ai décidé de tester une solution à base de LM2596. Pour effectuer des tests sans avoir à développer quoi que ce soit, j'ai acquis sur eBay quelques modules de ce type pour quelques Euros :


Ce qui est intéressant avec ce type de module, c'est qu'en plus de la plage de tension d'entrée qui peut monter à 40V, la sortie réglable de quelques volts à plus de 30V sous 3A max permet de s'en servir en petite alimentation d'appoint pour effectuer quelques tests. A noter que ce type d'alimentation ne peut guère servir en alimentation définitive sur du long terme vu le type et la qualité des condensateurs chimiques.

Et à propose de test, j'ai pu vérifier le fonctionnement correct de l'écran tactile en version grand format de 7 pouces :



Après une petite heure de fonctionnement, les éléments du module d'alimentation sont à peine tiède pour un débit d'environ 500mA, ce qui me semble plus pertinent comme solution que celle adoptée en premier lieu sur ma carte de développement. Je vais quand même sortir l'oscilloscope pour vérifier à minima l'allure de l'alimentation ainsi que son bruit.


mercredi 11 octobre 2017

PC : les ventes baissent toujours.

Ah, il est vraiment fini le temps ou l'ordinateur représentait un potentiel de développement et de créativité personnel. Les machines à publicité qui nous sont vendues aujourd'hui, ne servent finalement qu'à faire du Minitel évolué ou à faire fonctionner des applications de gestion globalement mal développées. C'est sur, le PC n'a plus la côte!

Je n'ai pas demandé l'autorisation à Reuters...
Il y a quelques années encore, l'arrivée d'un Linux un peu plus ergonomique, notamment avec l'initiative Ubuntu (Canonical), aurait pu faire penser à du mieux. Hélas, depuis 10 ans, que dire de l'évolution de Linux pour PC. A se demander si des 'taupes' de Microsoft ne travaillent pas chez les contributeurs de Linux pour l'empêcher d'évoluer vers un 'vrai' système pour les utilisateurs.

C'est sans doute une des raisons de l'engouement actuel pour le rétro-computing. Elles étaient finalement sympa ces petites machines qui permettaient de créer plein d'applications, soi-même, sans grandes connaissances en programmation.