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.
