superp:
GINGARDU:
superp:
Io li uso per differenziare i tipi di messaggi di debug, definisco per esempio DEBUG_485 per quel che riguarda la comunicazionie RS485, o DEBUG_LCD o semplicemente DEBUG. Si potrebbe anche usarli per differenziare la gravitá del messaggio di debug implementando INFO 0, WARNING 1, ERROR 2, SEVERE 3 poi spargerli, attorno ai serial.print, lungo il codice e definire un valore per DEBUG compreso tra 0 e 3.
Credo possa funzionare"ottimo" solo che non ho compreso nulla
se fai esempi reali con spezzoni di sketch con spiegazioni per chi è a digiuno fai cosa gradita 8)
Riguardo il fatto di poter implementare diversi livelli di gravitá non ne sono tanto sicuro, era solo un'idea...aspettavo qualcuno che avesse già avuto una pensata simile
Per la prima parte le mio post invece le cose sono molto semplici. Se nel tuo sketch usi una sola direttiva DEBUG hai la possibiltà di attivare o disattivare TUTTI la serial.print ponendo DEBUG a 0 o a 1.
Ma se il tuo sketch è molto grande, magari usi più librerie e hai pezzi di codice che si occupano di cose differenti, puoi gestire il debug di ogni pezzo con più direttive debug da attiavre a tuo piacimento:#define DEBUG 1 // messaggi generici di debug
#define DEBUG_LCD 1 // mesaggi di debug inerenti al solo codice che gestisce l'lcd
#define DEBUG_485 1 // mesaggi di debug inerenti al codice che gestisce la comunicazione RS485
[....]
void changeToReceiveMode(){
#ifdef DEBUG_485
Serial.println('ascolto il bus 485)
#endif
[....]
}
È solo un esempio il "succhio" del discorso (come dice un consigliere comunale del mio paese :fearful:) è che in fase di sviluppo puoi gestire debug differenti senza appesantire troppo il codice con i serial.print. Spero di essere stato chiaro e non aver confuso le idee. N
sei stato chiaro e utile (almeno per me) quindi all'atto pratico es:
posso fare un debug per non includere i serial print e un debug per non includere i delay
a mio piacimento o uno o l'altro o tutti e 2 semplicemente modificando l'uno con lo zero