volevo sapere se in uno sketch es: con molti serial.print si possono considerare come se non esistessero se la porta usb viene scollegata,
oppure in qualche modo influenzano le "prestazioni" anche se non c'e nessun usb collegata,
L'Arduino utilizza un chip accessorio per comunicare con il PC o comunque via USB (il famoso Atmega8U2 o 16U2 a seconda dei modelli). Questo chip ha un buffer, che il chip svuota comunicando con il computer.
Se spedisci a raffica dati sulla seriale senza che l'Arduino sia connesso al PC, quel buffer si satura e la schedina si pianta. E' la classica situazione in cui si accende la lucina gialla RX fissa e la scheda, se la spedizione avviene fin dall'avvio dello sketch, va "in palla" arrivando a richiedere la famosa manovra d'emergenza per sbloccarla.
Ergo, consiglio di non spedire sulla seriale se non usi la seriale 
Sicuramente ti influenzano le prestazioni...ogni istruzione ha un suo tempo di esecuzione quindi il codice sarà piu lento...considerà anche che ogni stringa di cui fai il print occupa spazio in RAM secondo me...
tempo fa avevo visto una cosa del genere:
#define DEBUG 1
#if DEBUG
Serial.println("Debug version");
#endif
EDIT: Vedo che leo e' stato molto piu esaustivo di me 
...cmq puoi usare quel pezzo di codice che ti ho dato per evitare di commentare tutte le volte i print su seriale...devi modificare solo la variabile DEBUG
leo72:
L'Arduino utilizza un chip accessorio per comunicare con il PC o comunque via USB (il famoso Atmega8U2 o 16U2 a seconda dei modelli). Questo chip ha un buffer, che il chip svuota comunicando con il computer.
Se spedisci a raffica dati sulla seriale senza che l'Arduino sia connesso al PC, quel buffer si satura e la schedina si pianta. E' la classica situazione in cui si accende la lucina gialla RX fissa e la scheda, se la spedizione avviene fin dall'avvio dello sketch, va "in palla" arrivando a richiedere la famosa manovra d'emergenza per sbloccarla.Ergo, consiglio di non spedire sulla seriale se non usi la seriale
quindi anche se non è collegata l'usb tenta lo stesso di spedire, buono a sapersi,
allora d'avanti ai serial.print che "non servono nel progetto definivo " mettiamo due // davanti cosi lavorera meglio
GINGARDU:
quindi anche se non è collegata l'usb tenta lo stesso di spedire, buono a sapersi,
allora d'avanti ai serial.print che "non servono nel progetto definivo " mettiamo due // davanti cosi lavorera meglio
Sì, o commenti le righe, se sono poche, oppure adotti il metodo di Paolo, si tratta di una direttiva al compilatore.
"che influenza hanno" in termini tecnici .... un botto!! 
io li uso come debug e sono molto importanti, ma la memoria occupata da queste righe è spaventosa, il rallentamento altrettanto, quando le levo mi torna il sorriso 
pablos:
"che influenza hanno" in termini tecnici .... un botto!!
infatti trovo che siano molto utili per quello (assieme a i delay lunghi messi apposta per leggere bene)
paolo_fiorini3:
Sicuramente ti influenzano le prestazioni...ogni istruzione ha un suo tempo di esecuzione quindi il codice sarà piu lento...considerà anche che ogni stringa di cui fai il print occupa spazio in RAM secondo me...tempo fa avevo visto una cosa del genere:
#define DEBUG 1
#if DEBUG
Serial.println("Debug version");
#endif
EDIT: Vedo che leo e' stato molto piu esaustivo di me :P ...cmq puoi usare quel pezzo di codice che ti ho dato per evitare di commentare tutte le volte i print su seriale...devi modificare solo la variabile DEBUG
ma di preciso cosa fa e come si usa il codice che hai postato?
Istruisce il compilatore a compilare oppure no determinate porzioni di codice.
#define DEBUG 1
#if DEBUG
Serial.println("Debug version");
#endif
Crei una direttiva in cui dici al compilatore di sostituire tutte le istanze di DEBUG presente nel codice con il valore 1.
Poi dici: "se DEBUG (è vero)" quindi "se 1 (è vero)", compila anche il blocco seguente (fino all'endif). Siccome 1 è vero, viene compilato. Se tu mettevi #define DEBUG 0, tale controllo risultava falso e quel codice non veniva incluso nel tuo sketch.
si anche se metti DEBUG=0; resta sempre il confronto che rallenta, in compilazione occupano una montagna di memoria delle istruzioni inutili, se non ti servono un bel // risolve soprattutto un bel
//serial.begin(9600);
No, scusa. Le direttive servono proprio per non far passare nel compilato finale le porzioni di codice che non interessano. Non stiamo parlando di un if generico ma di un check condizionale per il compilatore.
Se metti:
#define DEBUG 1
(....)
if (DEBUG) {
Serial.Println("a");
}
Questo codice viene compilato e inserito nello sketch finale per cui ad ogni passaggio da quel punto l'Atmega esegue l'if.
Se metti
#define DEBUG 1
(....)
#if DEBUG
Serial.Println("a");
#endif
quel serial.println non viene inserito nello sketch finale SOLO se DEBUG ha valore 0.
si se hai delle direttive ok ... ma questo pezzo mi sfugge non l'ho capito
Se metti
#define DEBUG 1
(....)
#if DEBUG
Serial.Println("a");
#endifquel serial.println viene inserito nello sketch finale SOLO se DEBUG ha valore 0.
non dovrebbe essere inserito se valore DEBUG = 1?
ciao
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.
capito thx, comunque che non passassero dal compilato non lo sapevo ... mannaggia le sai tutte!! 
io le levavo e mi toglievo il dubbio ]
Non serve solo a questo, ad esempioi puoi inserire nel codice dei dati in base al micro che stai usando o al clock di sistema. Se guardi dentro la mia libreria swRTC vedi un massiccio uso delle direttive perché lì ho dovuto rendere il codice compatibile con una dozzina di micro differenti, ed ogni famiglia di micro ha i suoi registri: un codice unico non andava bene, gli if avrebbero appesantito tutto. In fase di compilazione invece sistemo lo sketch per lo specifico micro su cui poi andrà a girare effettivamente il programma.
leo72:
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?
Esatto. Non verranno inclusi nel firmware che poi verrà caricato sull'Arduino. Quindi esisteranno solo nel codice sorgente.
leo72:
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
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
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)