LOCODUINO

Parlons Arduino => Le logiciel DCC++ => Discussion démarrée par: Daniel075 le avril 22, 2020, 11:35:50 pm

Titre: Cohabitation DCCpp et Adafruit sur UNO
Posté par: Daniel075 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 ?.
Titre: Re : Cohabitation DCCpp et Adafruit sur UNO
Posté par: Thierry le avril 23, 2020, 09:49:00 am
DCCpp fonctionne comme toutes mes bibliothèques avec des options qu'il faut activer ou désactiver en fonction des besoins. Ces options sont configurables dans DCCpp.h et peut être que certaines d'entre elles ne sont pas utiles dans ton cas. Un gros consommateur de mémoire est l'option USE_TEXTCOMMAND qui peut être avantageusement remplacée par des appels aux fonctions directes, comme setThrottle() pour fixer la vitesse et le sens d'une loco plutôt qu'un '<T 3 50 0> à décoder.
Réduire le nombre de registres disponibles est aussi un moyen de gagner en mémoire vive. Dans comm.h il y a un #define MAX_MAIN_REGISTERS qui est à 12 pour un Uno, 21 pour un Mega et 41 pour un ESP32. Le minimum serait 2, pour un registre d'actions ponctuelles (accessoires) qui doit toujours être là, et un pour une loco.
Un autre piste plus pointue : les bibliothèques tentent souvent de cumuler des fonctionnalités et des interfaces pour être les plus universelles possibles. Mais cette polyvalence a un coût, et si quelque fois c'est le temps d'exécution qui en pâti, c'est plus souvent la mémoire qui paye un lourd tribu. Donc je te conseille de jeter un oeil à la bib adafruit et de retirer tout ce qui ne te sert pas : options pour d'autres matériels, fonctions inutilisées dans ton cas, buffers ou données statiques devenues inutiles ou surdimensionnées...
Titre: Re : Cohabitation DCCpp et Adafruit sur UNO
Posté par: Tony04 le avril 23, 2020, 09:57:40 am
Bonjour Daniel,

réponse peut-être idiote, mais as-tu essayer avec la librairie u8glib en limitant au maximum les polices: https://github.com/olikraus/u8glib.

Et après de nombreuses recherches voici un article qui pourrait t'intéresser, mais pas testé chez moi: http://riton-duino.blogspot.com/2019/11/afficheur-oled-ssd1306-comparons.html

Cordialement
Antoine

Titre: Re : Cohabitation DCCpp et Adafruit sur UNO
Posté par: msport le avril 23, 2020, 10:03:23 am
De même, encore plus réduite, la bibliothèque SSD1306Ascii :
https://github.com/greiman/SSD1306Ascii
Titre: Re : Cohabitation DCCpp et Adafruit sur UNO
Posté par: Tony04 le avril 23, 2020, 10:04:35 am
Bonjour Michel,

tu m'as pris de vitesse, j'étais entrain de rechercher cette adresse. L'as tu essayé chez toi ?
Titre: Re : Cohabitation DCCpp et Adafruit sur UNO
Posté par: msport le avril 23, 2020, 10:06:12 am
Bonjour Antoine,
c'est celle que j’utilise en général (mais les graphiques prennent de la place et nécessitent de se les faire à la main !) ...
Titre: Re : Cohabitation DCCpp et Adafruit sur UNO
Posté par: Daniel075 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 ?
Titre: Re : Cohabitation DCCpp et Adafruit sur UNO
Posté par: Thierry le avril 24, 2020, 01:27:39 pm
Oui, oui, ça marche. Ce n'est pas le plus élégant, mais ça marche. Sous Windows 10, il y a par exemple un petit éditeur de texte gratuit qui s'appelle CodeWriter et qui fait un peu mieux que le blocnote... Mais quantité d'autres comme SublimeText ou UltraEdit font encore mieux... Pour ma part, j'oscille entre SublimeText pour l'essentiel, c'est à dire tout ce qui est texte, et quelque fois CodeWriter.
Titre: Re : Cohabitation DCCpp et Adafruit sur UNO
Posté par: Tony04 le avril 24, 2020, 06:44:09 pm
Bonjour à tous,

sauf si j'ai mal compris la question (avec la fatigue du jardin ) voici un petit oublié pourtant très puissant et facilement personnalisable, Notepad++ dont je ne me séparerais plus.

Cordialement
Antoine
Titre: Re : Cohabitation DCCpp et Adafruit sur UNO
Posté par: Conchito le avril 25, 2020, 11:55:59 am
Bonjour,

En essayant de faire appel à de vieux souvenirs de programmeur, il me semble que la réservation dynamique de mémoire peut être pleine de surprises.
La fonction malloc() permet de réserver, lors de l’exécution du programme, de la mémoire par blocs. La mémoire réservée ne peut être que des adresses contiguës pour faciliter la gestion des tableaux et des structures de données par pointeurs.
La fonction de réservation dynamique de mémoire cale l'adresse de début du bloc créé sur un multiple entier de la longueur du bloc à créer. Ainsi un bloc de 512 octets ne commencera que sur une adresse en 0000H ou 0200H ou 0400H ou ....
La réservation de plusieurs blocs de tailles différentes peut amener à un gruyère de mémoire avec de nombreux trous perdus.

J'ai eu ce cas là en utilisant la bibliothèque Adafruit qui réserve, via malloc(), pour le buffer pour l'écran SDD1306, 64 x 128 bits soit 1ko.
Au départ, je créais d'abord le buffer tournant de la liaison série logicielle (SoftwareSerial.h). Un bloc de 128 octets était alors réservé. Ensuite, lorsque je réservais le buffer d'Adafruit , ce dernier était placé à partir de 0400H, ce qui correspond à la borne de 1ko  suivante. Compte tenu de la taille mémoire de 2ko, il ne restait plus rien pour les affectations suivantes et le programme plantait lamentablement.
Le problème a été résolu lorsque j'ai changé l'ordre des affectations. Dans la fonction setup(), j'ai commencé par initialiser le buffer d'écran par  Mydisplay.begin(SSD1306_SWITCHCAPVCC, 0x3C) suivi plus loin par l'initialisation de la liaison série logicielle  BTSerial.begin(9600).

L'ordre des réservations de mémoire est important sur des micros controllers avec peu de mémoire.

Je te propose d'essayer de mettre l'instruction de réservation des buffers de l'écran (ecran.begin()) dans les premières  lignes de setup() avant les autres réservations de mémoire telles que DCCpp.begin() et DCCpp.beginMain() ou autres .

Voila mon retour d'expérience sur ce genre de problèmes, si ça peut aider ...

Amitiés

Serge
Titre: Re : Cohabitation DCCpp et Adafruit sur UNO
Posté par: Pyk35 le avril 25, 2020, 09:00:23 pm
Daniel,

Je viens de développer une ihm pour le projet de box de Locoduino :

https://forum.locoduino.org/index.php?topic=922.210.

https://m.youtube.com/watch?v=ubl6p8n7N1U

Je n’ai pas tout saisi, ton problème est la flash ou la ram? Si tu as réduit l’affichage pour que ça marche, j’en déduis que c’est la ram mais j’ai un doute quand je lis ton message.

Je commence à bien pratiquer la lib d’adafruit et si ton problème est la flash, tu dois pouvoir sabrer sans trop de problème. Utilise notepad++ (Sous Windows), gratuit, et juste très efficace.
Par exemple, il y a le splash.h qui contient les 2 logos d’adafruit. Si tu modifies l’appel au splash dans le begin de la librairie, tu dois pouvoir gagner un peu.

https://github.com/adafruit/Adafruit_SSD1306/blob/master/splash.h

Voir fonction begin :

https://github.com/adafruit/Adafruit_SSD1306/blob/master/Adafruit_SSD1306.cpp

En gros, si tu n’as pas peur d’ouvrir la librairie, tu peux shooter toutes les fonctions dont tu n’as pas besoin t’il y en a des tones, notamment dans le librairie GLX.
Titre: Re : Cohabitation DCCpp et Adafruit sur UNO
Posté par: Pyk35 le avril 25, 2020, 09:36:06 pm
Je viens de vérifier, la librairie d’adafruit devrait consommer essentiellement le buffer de l’image soit :
if((!buffer) && !(buffer = (uint8_t *)malloc(WIDTH * ((HEIGHT + 7) / 8 ))))

Soit 1136 octets pour le 128x64. A ça il faudrait ajouter d’autres petites variables et c’est sur que sur les 2ko de ram, il ne faut pas que le reste ne consomme trop en effet. :(
Titre: Re : Cohabitation DCCpp et Adafruit sur UNO
Posté par: Daniel075 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