[résolu] Problème pour compiler un projet instructable

Bonjour à tous;

Je cherche à reproduire ce projet :

Tout est ok sauf une chose : quand je récupère le code sur la page ( qui a été écrit et compilé pour Arduino nano ) et que je tente de le compiler, j'ai une erreur d'espace mémoire :

"Le croquis utilise 25068 octets (81%) de l'espace de stockage de programmes. Le maximum est de 30720 octets.
Les variables globales utilisent 2729 octets (133%) de mémoire dynamique, ce qui laisse -681 octets pour les variables locales. Le maximum est de 2048 octets."

Je n'essaye pas de rentrer dans le code pour optimiser, puisqu'à priori, il a déjà été compilé pour le même matériel ... Est-ce que quelqu'un a une piste pour répondre à la question "pourquoi ça passe chez lui et pas chez moi" ?

Merci d'avance !

peut-être qu'une des bibliothèques a changé entre temps et est plus conséquente ou vous avez chargé une bibliothèque différente de celle attendue

#include <rgb_lcd.h>
#include "HX711.h"
#include <avr/sleep.h>
#include <avr/power.h>
#include <Bounce2.h>

➜ il ne précise pas les versions

Ni l'origine des librairies.

Mais je ne pense pas que l'origine du problème soit là.
Le sketch est compilable sur MEGA, et on peut donc obtenir un fichier MAP.
La majorité des variables .bss provient de l'utilisation à outrance de PRETTY_FUNCTION pour du debug.

En ajoutant ceci au début du sketch, ça passe.
#define __PRETTY_FUNCTION__ ""
Les variables globales utilisent 1425 octets (69%) de mémoire dynamique, ce qui laisse 623 octets pour les variables locales. Le maximum est de 2048 octets.

OK donc il avait sans doute compilé son programme pas en mode debug

toutes ces strings prennent aussi plein de SRAL

// display messages
#define ARROWSCALETITLE                 "Spine Tester"
#define ARROWSCALEVERSION               "SW Version 2.3.2"
#define READYMESSAGE                    "Position arrow; press ok"
#define REMOVEWEIGHT                    "Remove weight; press ok"
#define ZEROINGSCALE                    "Zeroing the scale..."
#define ZEROFACTOR                      "Zero factor"
#define PLACE1KGWEIGHT                  "Position 1kg weight; press ok"
#define CALIBRATINGSCALE                "Calibrating the arrow scale..."
#define CALIBRATINGGAUGE                "Calibrating gauge %d"
#define CALIBRATION                     "Calibration"
#define CHECKINGSCALE                   "Checking scale..."
#define KILOGRAMREADING                 "1kg reading"
#define GRAMS                           "g"
#define CALIBRATIONCOMPLETE             "Calibration complete"
#define ARROWSPINE                      "Arrow spine:"
#define ASTMAT28SHORTSTRING             "ASTM@28"
#define AMOAT26SHORTSTRING              "AMO@26"          
#define AMOLBSAT26HORTSTRING            "lbs@26"          
#define GRAMSAT28HORTSTRING             "grams@28"          
#define ASTMAT28STRING                  "ASTM spine measured @28\""
#define AMOAT26STRING                   "AMO spine measured @26\""
#define AMOLBSAT26STRING                "AMO poundage measured @26\""          
#define GRAMSAT28STRING                 "Grams force measured @28\""          
#define ASTMAT28UNITS                   ""
#define AMOAT26UNITS                    "" 
#define AMOLBSAT26UNITS                 "lb"          
#define GRAMSUNITS                      "g" 
#define AVERAGESPINESTRING              "Avg spine %s%s max %s%s @ %i%c"
#define DEGREESYMBOL                    223
#define WEIGHT                          "Weight:"
#define FOC                             "F of C:"
#define FOCUNITS                        "%" 
#define GRAINSUNITS                     "gn"
#define ARROWLENGTH                     "Arrow length:"

il aurait fallu les mettre en flash sans doute...

Ouhao top, merci beaucoup, ça fonctionne.

fichier MAP, .bss, pretty_function ... Je suis largué, je ne sais pas par où commencer pour comprendre pourquoi ça fonctionne. Si quelqu'un a une piste ...

En tout cas, j'avance le projet. Merci encore.

Cette ligne permet de remplacer les noms des fonctions, qui apparaîtront sur le moniteur série, par une chaîne vide, donc on gagne de la mémoire RAM.

J'ajouterais que __PRETTY_FUNCTION__, par rapport à __func__, inclut le prototype complet de la fonction, donc c'est pire.

Si je comprends bien, à chaque fois qu'une mention est faite à PRETTY_FUNCTION, ça charge un tableau de caractères dans la mémoire flash.
N'y a t il pas moyen de passer ça dans la mémoire du programme ? J'ai essayé avec F(), avec des déclarations explicites avec PROGMEM, mais je n'ai aucun résultat.

avez vous vraiment besoin du debug?

Non, plutôt en mémoire RAM.
A ma connaissance on ne peut pas agir sur le placement des signatures de fonction effectué par __PRETTY_FUNCTION__
Au pire, afficher les informations de debug sans les signatures de fonctions n'est pas dramatique.

Ok merci. Non, je n'ai pas besoin du debug à tout prix, c'est par curiosité et pour comprendre mieux la gestion de la mémoire. Je cherche à comprendre pourquoi le créateur du programmeur peut compiler ça, et moi pas. Je lui ai posé la question, lui dit qu'il a comme message :

Sketch uses 25619 bytes (52%) of program storage space. Maximum is 49152 bytes.

Global variables use 743 bytes (12%) of dynamic memory leaving 5421 bytes for local variables. Maximum is 6144 bytes.

Ce ne sont ni les mêmes tailles de contenant (alors qu'il utilise également une nano), ni la même occupation mémoire.

Impossible. Une NANO n'a que 32K de FLASH et 2.5K de RAM.

49152 bytes de FLASH et 6144 bytes de RAM : cela peut être une NANO EVERY.
Et cela correspond bien à ce que je vois sur la photo.

Et quand je compile pour une nano every, j'ai le même résultat que lui - manifestement, dans ce cas là, les appels à PRETTY_FUNCTION n'occupent pas de place en RAM.
Ca n'explique pas tout, mais ça me suffira pour avancer sur le projet :slight_smile:
Merci bcp !

Si, mais la NANO EVERY a beaucoup plus de RAM que la NANO.

J'ai posté un commentaire lui demandant de modifier sa liste de courses :wink:

Non, c'est pas ça. C'est que la Nano Every dispose de plus de RAM donc les données tiennent en mémoire.

Bah à priori non. Compilation pour la nano every :
Les variables globales utilisent 743 octets
Compilation pour la nano :
Les variables globales utilisent 2729 octets

Effectivement. L'explication est probablement que les signatures de fonctions sont placées en FLASH dans le cas de la NANO EVERY.
Il faut dire que l'ATMEGA328 a une gestion particulière des chaînes constantes.
__PRETTY_FUNCTION__ déclare certainement les signatures de fonction comme const char *, qui occupent de la place en FLASH et en RAM sur un ATMEGA328P, alors que sur un processeur normalement constitué, elles sont placées directement en FLASH, avec un accès possible en direct, sans passer par PROGMEM.

il me semble avoir lu que le ATmega4809 avait une Harvard architecture modifiée qui permettrait d'avoir un seul espace d'adressage pour la flash et la sram.

Si c'est le cas, ça permet au compilateur de ne pas avoir à gérer deux mémoires et le compilateur peut mettre les const char * en flash alors que sur un nano d'origine il sont en SRAM (parce qu'il faut bidouiller avec PROGMEM pour les mettre en flash et ensuite l'accès est malaisé il faut utiliser des fonctions spéciales pour lire ces pointeurs).

Oui et cette particularité m'a fortement perturbé à mes débuts dans le monde AVR, ayant travaillé auparavant exclusivement avec ARM et MSP430.

Pour le plaisir de cloturer proprement le fil de discussion, voici le projet fini !


Un excellent projet pour archers, assez simple. Malheureusement, pour une raison que j'ignore, l'affichage bug après l'affichage de la moyenne d'une mesure, ce qui oblige à redémarrer - mais ça ne l'empêche pas de fonctionner. A l'occasion, je passerai sur l'arduino Every.
Encore merci pour votre coup de main !