Voir les contributions

Cette section vous permet de consulter les contributions (messages, sujets et fichiers joints) d'un utilisateur. Vous ne pourrez voir que les contributions des zones auxquelles vous avez accès.


Messages - Daniel075

Pages: [1] 2
1
Voici une procédure permettant d disposer de différentes polices de caractères avec l’écran Elegoo 2.8 inch (320x240) ili9341 (connecté en 8bits //) :
1 - Ne pas utiliser les bibliothèques Elegoo_GFX.h et Elegoo_TFTLCD.h  livrées avec l’écran.
2 - Mettez à la place Adafruit GFX Library  et Adafruit TFTLCD Library ainsi que TouchScreen, plus le ou les fichiers de polices de caractères souhaités ( puisés dans le répertoire Fonts de Adafruit_GFX) . Par exemple :  FreeMonoBoldOblique9pt7b.h
3- Pour appeler une police, utiliser l’instruction : tft.setFont(&FreeMonoBoldOblique9pt7b)
Ci-aprés qqs lignes du prgm pour illustrer la démarche.

#include <Adafruit_TFTLCD.h>  //  bibliothèques chargées avec Adafruit TFTLCD Library
#include <pin_magic.h>
#include <registers.h>

#include <Adafruit_GFX.h>     //   bibliothèques chargées avec Adafruit GFX Library
#include <Adafruit_GrayOLED.h>
#include <Adafruit_SPITFT.h>
#include <Adafruit_SPITFT_Macros.h>
#include <gfxfont.h>

#include <TouchScreen.h>
#include <Fonts/FreeMonoBoldOblique9pt7b.h>

************
***********
Adafruit_TFTLCD tft(LCD_CS, LCD_CD, LCD_WR, LCD_RD, LCD_RESET);

void setup(void) {
    Serial.begin(9600);
     tft.reset();
 
     uint16_t identifier = tft.readID();
     identifier=0x9341; 
     tft.begin(identifier);

     tft.setRotation(3);
     tft.fillScreen(BLACK);

   tft.setFont(&FreeMonoBoldOblique9pt7b);
    tft.setCursor(40,15); tft.setTextSize(1) ; tft.setTextColor(WHITE) ;
   tft.print("Choisir le mode") ;


2
J’ai effectivement trouvé dans Elegoo_GFX.cpp un appel «  #include "glcdfont.c" » et le fichier glcdfont.c a effectivement la structure d’un fichier de police de caractères. Ce fichier doit être connu car il est mentionné sous la library Adafruit (et correspond suivant les commentaires au standard ASCII 5x7 font).  Tout ceci m’amène un peu au delà de mes compétences, et sans une procédure précise je vais rester sur cette solution. Concernant d’autres écrans tactiles, merci de m’avoir fait connaître le site ebay que je n’utilisais pas (plus habitué à Aliexpess ou Amazon). J’ai également noté vos suggestions sur la communication entre les deux processeurs. J’ai utilisé I2C pour mon précédent projet (liaison à l’écran oled SSD1306) l’écran Elegoo qui s’enfiche sur la carte Arduino UNO masque les fils de liaison (SDA A4 et SCL A5). Je n’ai par ailleurs pas d’expérience dans l’utilisation de la liaison série TX et RX (D1 et D2) que j’ai tjrs laissées libres pour ma connexion PC. La solution d’un circuit NANO me semble d’une gestion plus simple (probablement une partie en assembleur), mais je n’en suis pas encore là.

3
Merci pour ce retour, L'article "Ecran couleur Tactile Kuman" de Christian ne m'avait pas échappé, Il est cependant trop grand pour ma petite boite . Concernant  les ressources machines, mes précédentes réalisations m'ont conduit à des programmes plus importants coté interface utilisateur que l'automatisme par lui-même incluant DCC++. Mon projet utilise une carte UNO pour gérer l'écran et l'interface utilisateur, Un NANO où seront implémentés en boite noire le logiciel DCC++ et les automatismes et un second NANO qui gérera la communication entre les deux .

4
Vos projets / Ecran Elegoo 2.8pouces pour boitier de commande DCC
« le: mai 31, 2021, 01:22:18 pm »
Je projette d’effectuer un bond techno avec mon boitier de commande DCC et notamment substituer la face avant (oled 0.9 pouce et des boutons) par un écran tactile 2.8pouces Elegoo (ili9341).
Ce boîtier de pilotage analogique ou digitale (merci aux réalisateurs de DCC++) tout intégré fonctionne avec ou sans automatisme de va et vient, actionne les fonctions, enregistre les adresses des locomotives et je vais lui ajouter la possibilité de modifier les CV. L’article « Réalisation d’un va et vient automatique et réaliste » par Dominique (rubrique Projet 16 fev 2016) décrit une réalisation très similaire.
Je m’interroge sur le choix du Elegoo 2.8 . Pas trop cher (15€) bonne luminosité, rafraichissement convenable (mise à jour de 5 à 6 valeurs numériques en une cinquantaine de millisecondes). Il ne dispose cependant pas de liaisons externes (tous les i/o de la carte UNO sont utilisés) et je dois  détourner les 4 liaisons vers la carte micro-SD  (inutile pour mon projet) pour communiquer. Par ailleurs la bibliothèque Elegoo fournie avec l’écran intègre une seule police de caractères.
Auriez vous d’autres expériences d’écran tactile (environ de même taille) , comment vous communiquez, et comment ajouter une police de caractère ?

5
Le logiciel DCC++ / Re : DCCpp 1.4.2
« le: décembre 08, 2020, 07:29:20 pm »
Bonjour, J’ai installé DCCpp1.4.2 dans mon logiciel qui s’appuyait jusqu’à aujourd’hui sur la version 1.3.6. Je rencontre un comportement incorrect avec les commandes de fonctions (j’obtiens un signal impulsionnel sur les leds de mon banc de test, une fraction de seconde sur une sortie et parfois même sur deux sorties à la fois). Le reste, lecture de l’adresse loco et commandes de mouvement fonctionne. Pour la commande des fonctions mon logiciel utilise l’approche présentée dans les exemples :
void commandeFonction(bool l) {         
    if (l)  { gLocoFunctions.activate (num_funct) ; }
       else { gLocoFunctions.inactivate (num_funct) ; }
       DCCpp::setFunctionsMain (num_register, adresse_dcc , gLocoFunctions ) ;
    }
Avec num_funct un entier, le numéro de la fonction et num_register=0, La commande est envoyée 5 fois à intervalle de 100ms. Tout ceci a parfaitement marché jusqu’à aujourd’hui et sur différents décodeurs. Je suis revenu en version 1.3.6 et j’ai retrouvé le fonctionnement correct  auquel j’étais précédemment habitué. Auriez-vous une piste?

6
Le logiciel DCC++ / Re : Cohabitation DCCpp et Adafruit sur UNO
« le: avril 28, 2020, 06:51:13 pm »
J’ai finalement expérimenté les différentes pistes qui m’ont été suggérées. Voici les résultats :
La bibliothèque u8g2 est tout à fait similaire  à celle d’Adafruit. Mêmes fonctionnalités, voire plus, et implantations en mémoire similaires. Sur une carte UNO, l’installation d’un écran 128x64 n’a pas plus été possible que sous Adafruit. En se limitant à 128x32, la déclaration de ce que le site u8g2 appelle le construteur, en tête de programme,  ajoute 6 à 800 octets RAM portant à 1600 mon espace réservé par le compilateur qui commençait à proférer des menaces. Notons que réduire à 32 l’ordonné Y affecte très peu l’aspect visuel. J’ai pu poursuivre l’écriture des 10 écrans de mon projet. Ce qui m’a pris 2 jours. J’ai également mis en pratique le conseille de Thierry et dans l’espace des librairie j’ai été modifier : sur Config.h   MAX_MAIN_REGISTER à 5 et MAX_PROG_REGISTER à 2 (je n’utilise pas de voie de programmation) . dans DCCpp. j’ai mis en commentaire les lignes concernant TextCommand. Ces deux dernières actions n’ont pas montré un résultat immédiatement probant, la vérification sous IDE indiquant rigoureusement les mêmes valeurs en occupation RAM et Programme. C’est au lancement du programme qu’apparaît la différence. Avant la modification, le programme ne se lançait plus. Après, il est reparti. Au terme de mon développement j’étais à 1800 en espace RAM. Le compilateur ne cessait de me menacer mais continuait toujours à faire son job. Au final, j’ai pu lancer le programme, mais son comportement  a été  incohérent dés l’envoi de la première commande Digitale. J’avais perdu 2 jours mais j’étais satisfait. D’une part avoir un produit à la limite de ses possibilités n’est technique pas un bon choix . D’autre part le fait d’intervenir sur les librairies me dérangeait d’un point de vu de la maintenance du programme . Je préfère garder ces librairies comme des boites noires sur lesquelles je peux compter sans m’en soucier davantage. Je suis à un âge où ma curiosité se doit d’être pragmatique. Je n’en remercie pas moins Thierry sur l’éclairage qu’il m’a apporté sur ces points techniques. Il me restait la piste Greiman. Je n’ai pas trouvé de documentation claire concernant l’usage de cette bibliothèque . Le site probablement peut fournir des informations , mais sa lecture est désagréable. Je n’ai par exemple pas trouvé la liste des commandes , l’équivalent d’un dossier Référence. Et puis, quelle confusion ! entre les suffixes oled. figurant dans les exemples donnés sur le site et le suffixe display de l’exemple désigné par Antoine :  http://riton-duino.blogspot.com/2019/11/afficheur-oled-ssd1306-comparons.html   C’est malgré tout ce dernier exemple qui m’a incité à aller plus avant. Les objets et la qualité de l’affichage, 128x64 sans scintillement , démontraient la faisabilité de l’usage de cette bibliothèque pour mon projet. Il y deux choses à savoir en utilisant cette librairie. La première, ne pas chercher à rafraichir l’écran , Les commandes clear font apparaître un scintillement rédhibitoire. Il faut écrire des espaces blancs  sur les zones à effacer ,  print(" ..... " ). Dans cet ordre d’idée,  afficher une variable, par exemple de type  entier, . print(entier ) fait apparaître une rémanence des caractères. Par contre la succession des deux instructions . print(" ..... " ) ; . print(entier ) donne un résultat correct. La deuxième chose à savoir concerne l’adressage de l’écran, setCursor(x,y). x est l’abscisse exprimé en pixel (128) .y est le numéro de la ligne  sur laquelle on veut écrire. Les polices que j’ai utilisé me permettaient de disposer de 6 lignes sur les 64 pixels de la hauteur d’écran. Le travail de création de mes 10 écrans m’a pris là encore 2 jours.
Mon projet sur sa partie informatique touche à sa fin. Je dispose d’un logiciel portable indifféremment sur MEGA ou sur UNO . L‘espace requis pour le programme frise les 30K pour la partie mémoire flash programme et 1K pour les RAM. Il me reste à réaliser la carte électronique d’interface, Elle sera bien sûre compatible MEGA et UNO, j’utilise pour cela. Kicad un logiciel que je recommande, freeware également Mais,...  c’est un autre sujet. Merci pour votre aide- Daniel

7
Le logiciel DCC++ / Re : Cohabitation DCCpp et Adafruit sur UNO
« le: avril 24, 2020, 11:40:31 am »
Merci Thierry, Tony04, msport pour vos réponses. Une nouvelle fois je constate la puissance d’un site spécialisé et bien tenu. Je vais essayer vos pistes. Il y a cependant une chose que je n’ai pas osé faire à ce jour, c’est entrer dans le logiciel des bibliothèques. Je sais parfaitement où elles s’implantent, .../Arduino/libraries/ ... Lorsque je clique pour ouvrir l’un des fichiers, par exemple DCCpp.h , il s’ouvre avec l’application Bloc-notes, ce qui permet de le lire (et de le modifier). Mais est-ce la démarche de modification de ces librairies ?

8
Le logiciel DCC++ / Cohabitation DCCpp et Adafruit sur UNO
« le: avril 22, 2020, 11:35:50 pm »
En cette période de confinement, du temps m’est donné pour avancer dans mes automatismes. J’ai remplacé quelques diodes (des signalements d’alarme et d’indication de certains états système) par un écran oled SSD1306. Disposer d’une information en clair sur ce qui se passe, là où il fallait se référer à un guide de fonctionnement pour connaître la signification du clignotement de telle diode est d’un confort considérable (voir photo 1). J’utilise la librairie « Adafruit ». Elle est d’un usage simple avec la liaison I2C. J’ai installé le montage de test sur une carte Mega. Mon confinement aurait donc été une période tranquille si je n’avais pas souhaité migrer ce montage sur une carte UNO. Du point de vue I/O, les implantations nécessaires sont respectées et du point de vue mémoire, je n’ai pas atteint les 32K d’espace programme ni les 2K RAM. La librairie Adafruit est cependant gourmande et nécessite à elle seule 15K. La cohabitation des répertoires <DCCpp.h> et Adafruit_GFX et SSD1306 + Wire.h pour avoir une simple exécution des premières lignes du programme m’a obligé à réduire l’espace d’affichage de l’écran oled à 32 x 128 (pour un composant qui dispose de 64x128 pixels). Mais pour avoir un fonctionnement complet de l’automatisme (DCCpp.begin et DCCpp.beginMain), j’ai du réduire à 16x128. Ce qui limite et dégrade bien évidemment l’affichage. Seule la moitié inférieure de l’écran est accessible (voir photo 2). Bien sûr j’ai toujours la possibilité de rester avec une carte Mega (2€ de plus) mais ...  peut être suis-je passé à coté de quelque chose ?.

9
Composants / Re : Alternative aux circuits MAX471 défectueux
« le: mars 20, 2020, 12:52:14 pm »
Merci de me faire connaître l'ACS712. Le découplage galvanique surtout pour une mesure de courant est un élément important. Sa sensibilité de mesure (185mV/A dans sa version 5A) reste à tester avec le logiciel DCC. La lecture des CV avec leMAX471, plus sensible (1V/A) , est toujours un sujet de questionnement dans le forum.
Grand merci pour votre message - cordialement

10
Composants / Alternative aux circuits MAX471 défectueux
« le: mars 19, 2020, 02:55:32 pm »
Ceux qui ont eu à acheter un circuit MAX471 en 2019 l’ont constaté. Les livraisons ont  été dans la majorité des sources (aussi bien asiatiques qu’occidentales) des produits défectueux. Le défaut est toujours le même, la résistance entre Rs+ et Rs-, normalement très faible, c’est un shunt de 0.033mohm, s’avère être un circuit quasi ouvert. De plus, le fabriquant américain, Maxim Integreted, fait savoir sur son site qu’il ne produira plus ce circuit. Quoiqu’il en soit il m’a fallu trouver un montage de remplacement.
Je vous propose le circuit INA169, tout à fait similaire au MAX 471. Son montage est très simple, la résistance de shunt (Rs) est extérieure ainsi que la résistance de charge (RL) qui fixe la dynamique de mesure. Pour simplifier le montage on relie V+ (pin5) à Vin+ (pin3). La tension de sortie de mesure de courant « I » s’exprime ainsi V = Ix (RsxRL/1K). Le fait de pouvoir choisir Rs et RL permet de rester maître de la dynamique de mesure, ce que ne permettait pas MAX471. Ne pas oublier que la puissance dissipée dans la résistance de shunt est un carré de l’intensité (RsxIxI). Pour une résistance  Rs de 1W  0.01 ohm , vous devrez ne pas excéder un courant de 10 A.J’utilise personnellement un shunt de 1W 0.05ohm.

11
Le logiciel DCC++ / Problème avec la version DCCpp1.3.7
« le: février 21, 2020, 11:41:47 pm »
Je rencontre un problème avec la version d’août dernier 1.3.7. Pas le même que celui signalé par Fabien73 il y a qqs mois. Avec les versions antérieures 1.3.5 et 1.3.6, les deux décodeurs Hornby R8249 que j'utilise pour mes tests fonctionnaient parfaitement .  En chargeant la version 1.3.7 les commandes DCCpp::identifyLocoMain() et DCCpp::readCvMain() restent systématiquement infructueuses (retournent -1) et ceci quelques soient les valeurs entrées DCCpp::ackThreshold. C'est en fait pour l’accès à ce dernier paramètre que j'avais chargé cette version. J'ai bien sûr fait marche arrière. Quelqu'un aurait-il des infos sur ce point,   

12
Merci à Thierry et à Dominique  pour vos réponses. Je reste attentif à la suite de vos essais.  - Daniel

13
Bonjour , Une question de néophyte qui cherche à s'améliorer. MCPA (Philippe d'après la signature) mentionne la modification de ACK_SAMPLE_THRESHOLD. Mais comment effectuer cette modification  lorsque pour toute relation avec le logiciel DCC++ , on ne dispose que de  la visibilité #include<DCCpp.h>. Cette partie du logiciel nous est inaccessible.
Par avance merci - Daniel

14
Le logiciel DCC++ / Re : La brutalité de la commande identifyLocoMain()
« le: novembre 01, 2019, 04:56:54 pm »
Merci pour cette piste de réflexion, je vais creuser un peu de ce coté
Cordialement

15
Le logiciel DCC++ / Re : La brutalité de la commande identifyLocoMain()
« le: octobre 30, 2019, 06:17:14 pm »
Il n'y a rien de pervers dans mon silence. Je n'ai tout simplement pas eu la possibilité de regarder à l'oscilloscope le signal aux bornes du moteur sur une commande du lockPilot ECOS et je suis, je l'avoue peu régulier dans la lecture de mes messages. Le problème reste cependant important. Certaines machines en zéro sont malmenées par cette interrogation d'adresse. Notamment une 141F de AMJL équipée d'un décodeur Lock V4XL. Les pignons de cette machine sont mis à rude épreuve sur une commande identifyLocoMain(). La commande équivalente ECOS est à peine perceptible et plus rapide.  Ce qui me surprend, c'est que personne ne se soit joint à moi dans cette observation.  Mon électronique, décrite dans mon premier message et le logiciel utilisé (DCCpp), s'inscrivent tout à fait dans les préconisations de ce site et fonctionnent parfaitement bien ( Mes remerciements au passage pour les rédacteurs des différents articles sur lesquels je me suisappuyé) .  Je ne suis sûrement pas la seule personne à avoir noté ce point.

Pages: [1] 2