Caricamento sketch e Serial.print()...

Salve,
ultimamente ho avuto qualche difficoltà a caricare gli sketch su una scheda sulla quale era già caricato uno che eseguiva dei Serial.print() in fase di setup() e poi nel loop() ma limitati ad un paio di stringhe ogni 5 minuti.
Usando google ho letto che sarebbe meglio inserire nel setup() come prima istruzione un delay() pari a 1s o 2s per evitare problemi e questo l'ho fatto, è una soluzione definitiva? Oppure è meglio rimuovere le Serial.print() dal mio sketch? Tra l'altro io non faccio uso della scheda collegata al PC ma la programmo e poi la scollego e la sistemo nella suo contenitore con alimentazione esterna, quindi a me non sono utili perchè non ho il collegamento USB durante l'esecuzione dello sketch. Le ho lasciate pensando di condividere il mio sketch con altri utenti che magari potevano trovarle utili, secondo voi è solo uno spreco di risorse oppure gli utenti normalmente visualizzano l'output su monitor seriale? Nel mio caso, l'interazione con Arduino avviene tramite web.

se non ti servono ( e di solito servono solo in fase di debug) ti conviene togliere le print inutili ovviamente. In quanto alla difficoltà di caricare un programma in relazione a delle print.... non credo che centri molto. L'unico problema che ogni tanto ho è se quando l'ide sta per cominciare a scrivere il programma apri il monitor seriale in qual caso ogni tanto fallisce la scrittura ma è normale in quanto c'è il reset della scheda

Diciamo che non sono proprio print inutili, mostrano dei dati di inizializzazione (di rete, SDCard ed RTC) e poi delle stringhe che vengono inviate comunque tramite web (e queste magari potrei toglierle).
Grazie per la tua risposta!

Alcuni suggerimenti ...

  1. all'inizio del setup() metti un delay(500) ... sono già un'enormità per quello che deve accadere (il bootloader che prende il controllo) e non disturbano particolarmente all'avvio :wink:

  2. Usa pure tutte le Serial.print() che ti servono, riempi pure il programma, MA, quelle che ti servono per fare solo il debug e NON sono poi necessarie durante la normale esecuizione del programma, racchiudile in un #ifdef tipo:

#ifdef DEBUG
  Serial.print(.......);
#endif

In questo modo, SE in testa al programma comparirà la riga:

#define DEBUG

... quelle righe verrano regolarmente compilate ed eseguite; se, alla fine del debug, commenti quella riga, tutte le Serial.print() (o qualsiasi altra cosa) che avrai messo tra il #ifdef DEBUG e il #endif verrà eliminato prima della compilazione come se tu avessi cancellato le righe, con il vantaggio che, se ti dovessero riservire, basta togliere il commento a quella prima riga e ritornano ad essere usate :smiley:

Guglielmo

Ottimo consiglio. In effetti ho già utilizzato un bel po’ di istruzioni #ifdef per altri scopi all’interno dello sketch, ne aggiungerò altre per questo. Grazie.

gpb01:
2. Usa pure tutte le Serial.print() che ti servono, riempi pure il programma, MA, quelle che ti servono per fare solo il debug e NON sono poi necessarie durante la normale esecuizione del programma, racchiudile in un #ifdef tipo:

#ifdef DEBUG

Serial.print(.......);
#endif



In questo modo, **SE** in testa al programma comparirà la riga:



#define DEBUG



... quelle righe verrano regolarmente compilate ed eseguite; se, alla fine del debug, **commenti quella riga**, tutte le Serial.print() (*o qualsiasi altra cosa*) che avrai messo tra il #ifdef DEBUG e il #endif **verrà eliminato** prima della compilazione come se tu avessi cancellato le righe, con il vantaggio che, se ti dovessero riservire, basta togliere il commento a quella prima riga e ritornano ad essere usate :D

Guglielmo

Geniale! Me lo ricorderò, grazie.

Silente:
Geniale! Me lo ricorderò, grazie.

Emmm ... grazie, ma, in verità, la giusta definizione è "banale" e cosa normalmente usata da chi sviluppa codice per mestiere :wink:

Guglielmo

gpb01:
cosa normalmente usata da chi sviluppa codice per mestiere :wink:

Ma anche no, basta avere una certa esperienza in programmazione in generale, ed in C/C++/C# et similia per restare nella stessa sintassi (ma ci sono cose equivalenti anche in altri)... :wink:

Non capisco comunque il problema
Se non riesce a sovrascrivere il programma, non dipende dal programma, in particolare non dal programma che “scriverà” togliendo, in qualunque maniera, le print
Dipende dal bootloader, o magari dal circuito di reset dell’arduino

Leggendo dei post trovati con google suggerivano che potessero appunto esservi interferenze tra il bootloader ed eventuale traffico sulla seriale generato dallo sketch precedente a quello che si va a caricare e che in quel momento è in esecuzione sulla scheda. Io non sono un esperto di queste cose, perciò ho chiesto qui, dato che comunque non ho trovato risposte esaustive e certe per conto mio...