Bonjour,
Faut il supprimer les traces (Serial.print) lorsque l'Arduino Mega n'est plus relié a une console via la prise USB?
J'ai une carte SIM900 pour des echanges SMS , et lorsque mon PC passe en veille (prise USB toujours alimenté) j'ai des perturbations sur les échanges avec ma carte SIM900 (la carte SIM a sa propre alimentation).
J'ai supprimé tous les Strings pour n'utiliser que les chaines de caractères, pensant que le problème venait de la.
Tu peux passer par un artifice en définissant un booléen appelé par exemple DEBUG
#define DEBUG 1
et remplaçant Serial.print par
if (DEBUG) Serial.print
Lorsque tu n'as plus besoin de la console, tu passe DEBUG à 0.
J'utilise souvent cela:
#define DEBUG // A COMMENTER QUAND ON VEUT ENLEVER LE DEBUG
#ifdef DEBUG
#define D_SerialBegin(...) Serial.begin(__VA_ARGS__);
#define D_print(...) Serial.print(__VA_ARGS__)
#define D_println(...) Serial.println(__VA_ARGS__)
#else
#define D_SerialBegin(bauds)
#define D_print(...)
#define D_println(...)
#endif
par exemple on fait:
#define DEBUG // A COMMENTER QUAND ON VEUT ENLEVER LE DEBUG
#ifdef DEBUG
#define D_SerialBegin(...) Serial.begin(__VA_ARGS__);
#define D_print(...) Serial.print(__VA_ARGS__)
#define D_println(...) Serial.println(__VA_ARGS__)
#else
#define D_SerialBegin(bauds)
#define D_print(...)
#define D_println(...)
#endif
void setup()
{
D_SerialBegin(115200);
D_println("HELLO");
D_println(F("F HELLO"));
D_println(123.456, 2);
D_println((uint32_t) 3735928559UL, HEX);
}
void loop() {}
je trouve que c'est plus lisible et on ne dépend pas de l'optimisateur de code pour virer tout ce qui se rapporte à DEBUG. Comme on utilise __VA_ARGS__, ça veut dire aussi que la Marco supporte les différentes formes supportées par print() ou println()
Attention si vous utilisez le port série pour autre chose que le debug alors ne pas utiliser D_SerialBegin car il sera enlevé quand vous enlèverez le mode debug.
Bonsoir,
Je déterre ce fil car je souhaite utiliser cette méthode pour désactiver proprement les divers print() dans mes programmes
J'avoue que je ne me suis jamais posé la question de la présence des nombreux print() dans mes programmes en fonction.
D'oû ma question, quelles sont les conséquences de les maintenir ?
Merci d'avance
Ça occupée de la mémoire dont vous. Pourriez avoir besoin pour autre chose
Merci,
C'est bien ce que je craignais, je vais corriger tout ça...
voilà c'est corrigé sur un programme et effectivement j'ai un petit gain en espace mémoire et c'est plus propre conceptuellement.
J'ai une question encore, si on laisse une flopée de print() alors qu'il n'y a pas de connexion série, peut-il y avoir des risques de bugs le système interrogeant en permanence une entrée inexistante (en particulier quand on alimente par l'entrée USB) ?
En fait l'entrée n'est jamais inexistante, il n'y a rien au bout c'est tout donc les pins ne voient pas d'activité en entrée. ça ne va pas faire un bug, mais ça occupe le processeur pour rien.
Sur un UNO comme la partie USB est gérée par une puce à part, si vous écrivez sur le port Serial, vous verrez de l'activité sur la pin digitale 1 (Tx).
Sur les Arduinos qui utilisent un chip USB embarquée comme le Micro par exemple (ATmega32U4) la définition de l'instance Serial fait référence à la partie communication USB CDC et celle ci ne sera pas établie s'il n'y a pas eu un handshake avec un appareil distant pour établir la liaison USB. C'est pour cela qu'avec ces Arduinos qui ont une couche USB CDC on fait unwhile (!Serial); // attente du handshake natif USB
Mais si vous utilisez Serial1 alors vous basculez en UART TTL (Série 5V) sur les pin 0 et 1 et donc un Serial1.print() va utiliser la pin 1 (Tx)
Merci,
C'est clair
Cordialement
Salut ,
avec le
#define DEBUG
ne peut on pas carrement desactiver l ' initialisation serie et tous les appels a Serial.print ?
par exemple :
void setup() {
if (DEBUG) Serial.begin(115200);
}
ca serait encore plus econome en memoire ?
iznobe:
Salut ,avec le
#define DEBUGne peut on pas carrement desactiver l ' initialisation serie et tous les appels a Serial.print ?
par exemple :void setup() {
if (DEBUG) Serial.begin(115200);
}
ca serait encore plus econome en memoire ?
non car défini comme cela DEBUG n'est remplacé par rien à la compilation.
il faudrait faire
#ifdef DEBUG
Serial.begin(115200);
#endif
mais notez que plus haut j'ai aussi proposé un
#define D_SerialBegin(...) Serial.begin(__VA_ARGS__)
donc au lieu de faire Serial.begin(115200);vous faitesD_SerialBegin(115200);et il sera viré aussi automatiquement si DEBUG n'est pas défini
bon , sur mon programme serveur relais volet + arrosage voir ici pour ceux que ca interresse
avec cette " astuce " je suis passe de 18 % de memoire utilise par les variables globales a 16 % et de 10 % a 9 % sur la place occupe par le binaire tout de meme non negligeable ! 
Gagner de la mémoire ça ne sert que pour un programme qui fait de l'allocation dynamique, non ?
Si le prog se charge en mode DEBUG, pourquoi le toiletter ensuite ?
Certes on peut aussi gagner quels ms par cycle, si on en a besoin.
J'ai aussi le cas d'un ESP32 qui utilise sa LNS pour commander un autre circuit. En mode programmation/test il faut activer le débogage par Serial, et le couper en mode d'exploitation.
ca peut aussi servir quand ca devient un peu juste en fonction du programme utilisé .
si dans plusieurs fonctions il y a des variables locales , il lui faudra de la memoire pour stocker cela pendant l' execution quelquepart je suppose , et si il y a deja 80 % de memoire utilisé par les variables globales , ca risque de coincé a un moment .
un peu comme un ordi , avec 2 Giga , si l ' OS en prend deja 1.6 , pour faire du traitement de texte ca ira , apres avoir lancé firefox , ca va etre plus lent , et si y a 10 onglets ouverts , ca va ramer , si on fait de la retouche photo et ou video , il y aura fort a parier que ca va swapper et ramer a fond .
sur un arduino , y a pas de swapp ( a ma connaissance )
Apres je dis ca mais je ne suis pas certain de comment le compilateur fait , ni comment il va gerer la memoire .
Je dirais donc qu ' a partir de 60 % de memoire utilisé par les variables globales , ca devrait etre utile pour ne pas perdre en reactivité , mais ce ne sont que des suppositions et tout depend de ce que l ' on fait .
sur un arduino , y a pas de swapp ( a ma connaissance )
Sans disque dur : difficile ... 
Et il faut un processeur gérant la mémoire virtuelle.
ca peut aussi servir quand ca devient un peu juste en fonction du programme utilisé .
Oui mais si tu actives le DEBUG et que cela ne passe plus en mémoire cela veut dire que le debug devient inutilisable.
Tu peux éventuellement t'en sortir en activant le DEBUG sur une partie de ton logiciel mais pour cela il faut le découper en plusieurs .cpp comme je l'ai déjà expliqué :
https://forum.arduino.cc/index.php?topic=493039.msg4559468#msg4559468
https://forum.arduino.cc/index.php?topic=493039.msg4559823#msg4559823
Ok Henry , je comprends mieux l ' interet du decoupage maintenant , sans parler des gros programmes bien sur .
Merci pour ces precisions 
iznobe:
si dans plusieurs fonctions il y a des variables locales , il lui faudra de la memoire pour stocker cela pendant l' execution quelquepart je suppose , et si il y a deja 80 % de memoire utilisé par les variables globales , ca risque de coincé a un moment .
On parlait de désactiver les message de debug par Serial...
Ceci dit, je suis pas bien d'accord, l'Arduino est très différent d'un système multitâche avec un utilisateur imprévisible aux commandes.
Si ça passe une fois avec 80% occupés, y'a toutes les chances que ça passe toutes les fois.