Go Down

Topic: i serial.print nello sketch "che influenza hanno" (Read 2797 times) previous topic - next topic

gingardu


Sì, scusa ho sbagliato. Volevo scrivere: "non viene inserito... ecc...". Ora correggo.
Stavamo comunque parlando di direttive, quindi se la direttiva è falsa, il codice non viene inserito. Non appesantisce quindi l'esecuzione dello sketch.


allora vediamo se ho afferrato il senso pratico 8)    se metto all'inizio dello sketch  :

#define DEBUG 1


e ogni Serial.println  non necessario tra  #if DEBUG    e      #endif       

    poi  modificando  solo il numero 1 in 0   non vengono nemmeno caricati

giusto cosi?
Le cose si possono considerare facili in due casi: quando le si conosce bene o quando non le si conosce affatto...

leo72

Esatto. Non verranno inclusi nel firmware che poi verrà caricato sull'Arduino. Quindi esisteranno solo nel codice sorgente.

gingardu

#17
Jun 21, 2012, 07:05 am Last Edit: Jun 21, 2012, 08:09 am by GINGARDU Reason: 1

Esatto. Non verranno inclusi nel firmware che poi verrà caricato sull'Arduino. Quindi esisteranno solo nel codice sorgente.


ma la stessa regola vale anche  es:  per i delay e per qualsiasi  "altra cosa"   messa tra   #if DEBUG    e      #endif   ?



okkkkkkkk    RISOLTO   FATTO LE PROVE   BELLISSIMO " STRUMENTO"  CAMBIANDO SOLO UN NUMERO DA 1 A 0  PUOI EVITARE DI INCLUDERE TUTTE LE PORZIONI DI CODICE   SENZA STAR LI A FARE TUTTO A MANO
Le cose si possono considerare facili in due casi: quando le si conosce bene o quando non le si conosce affatto...

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
"The question is not whether intelligent machines can have emotions, but whether machines can be intelligent without any emotions"

gingardu


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  :smiley-eek:

se fai esempi reali con spezzoni di sketch con spiegazioni per chi è a digiuno fai cosa gradita  8)
Le cose si possono considerare facili in due casi: quando le si conosce bene o quando non le si conosce affatto...

pitusso

ciao,
un discorso a parte ma che comunque ha la sua rilevanza: una serial.print impegna risorse ram, quindi se ne utilizzi molti rischi di saturarla e di ottenere un freeze o comportamenti anomali.

Puoi usare in tal caso questa sintassi (notare F()):

Code: [Select]
Serial.print(F("Hello World"))

Direttamente da http://arduino.cc/it/Serial/Print:

Quote
You can pass flash-memory based strings to Serial.print() by wrapping them with F().


(è una feature presente dall'IDE 1.0)

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  :smiley-eek:

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:
Code: [Select]

#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  :smiley-eek-blue:) è 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

"The question is not whether intelligent machines can have emotions, but whether machines can be intelligent without any emotions"

gingardu




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  :smiley-eek:

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:
Code: [Select]

#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  :smiley-eek-blue:) è 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
Le cose si possono considerare facili in due casi: quando le si conosce bene o quando non le si conosce affatto...

Testato


Esatto. Non verranno inclusi nel firmware che poi verrà caricato sull'Arduino. Quindi esisteranno solo nel codice sorgente.

Thanks  :)
- [Guida] IDE - http://goo.gl/ln6glr
- [Lib] ST7032i LCD I2C - http://goo.gl/GNojT6
- [Lib] PCF8574+HD44780 LCD I2C - http://goo.gl/r7CstH

lesto

la seriale in genereale nel codice lo rallenta un sacco. l'uso di ram è costante, ci sono 2 buffer, uno di entrata che se non c'è spazio riscrive se stesso, e uno in uscita che se non c'è spazio ti blocca finchè non scrive qualcosa e poi ti lascia andare. anche se il buffer di uscita è mezzo vuoto, ti rallentano gli interrupt della seriale
sei nuovo? non sai da dove partire? leggi qui: http://playground.arduino.cc/Italiano/Newbie

Go Up