In my code I open a serial port and have lots of serial.prints - purely for debugging purposes and development.
I guess what I'll asking is does this code effect how the sketch runs in live and should they be commented out - as it makes sense to leave them in in case there is a need for debugging in the future?
Thanks
You could do this:
// comment next line out when you don't need to debug
#define DEBUG 1
void setup() {
// put your setup code here, to run once:
Serial.begin(9600);
Serial.println("this line will always print");
#ifdef DEBUG
Serial.println("this line only prints if DEBUG is not commented");
#endif
}
void loop() {
// put your main code here, to run repeatedly:
}
How about the best of both Worlds ?
Make the debug prints depend on the value of a variable (or a #defined value) so that you only need to change the value of the variable (or #define) in one place to turn debug printing on/off.
To save memory use the F() macro when printing text.
I was recently reading in one of my books that each time you use serialprint, it takes up something like 500 bytes of flash, so if you are getting close on memory size, that would also be a consideration (leaving them in). They will also slow the code down a bit if they are left in and each time the program encounters one it has to make a decision to print or not to print. The #define debug 1 option then commenting it out and re-compiling is probably the best option although it will also change the timing of your program since it no longer has to do the print thing - just something to be aware of.
gpsmikey:
I was recently reading in one of my books that each time you use serialprint, it takes up something like 500 bytes of flash,
I'd be interested to see that reference.
AWOL:
I'd be interested to see that reference.
Simon Monk "Programming Arduino - next steps, going further with sketches", pg 108 "Minimizing Flash Usage" down in the paragraph "Remove Unwanted Trace", he makes the comment "When debugging Arduino sketches, sprinkling the code with Serial.println ..... These commands actually use a fair bit of flash memory. Any use of Serial.println pulls about 500 bytes of library code into the sketch" It is not clear from reading that if he is talking about per instance or only the first instance with the others calling it (I wasn't completely awake when reading this section 
)
That's a one-off, and very easily verified.
#define debug = true
#include <Streaming.h> //Streaming | Arduiniana
// ......
Serial.begin(9600);
// .....
if(debug){
Serial << "Debug is on" << " Var1=" << Var1 << " Var2=" << _FLOAT(Var2, 2) << "\n\r";
}
#define debug = true
{cough}
arawire:
In my code I open a serial port and have lots of serial.prints - purely for debugging purposes and development.I guess what I'll asking is does this code effect how the sketch runs in live and should they be commented out - as it makes sense to leave them in in case there is a need for debugging in the future?
Thanks
The Serial functions left in will continue to be called, and will use memory, so it certainly does affect how the sketch runs. Serial printing takes time and that would likely be the only real affect on the sketch. If you have made the unfortunate decision to use String Class in your Serial debugging, well then you may want to axe that, as it can affect your long term execution.
Commenting it out is then a matter of personal preference, and you can see examples of how to do that (which you didn't ask about) above.
Professionally speaking, it can be EXTREMELY valuable to have access to debugging information on "production units in the field." Assuming that it fits, of course. And preferably, it should be possible to turn off and on, so as to minimize the performance impact on the running program. (If you have a spare pin, that'll work fine.)
But don't finish your debugging, turn off or remove the debug statements and then seal up the box. Too many times the code turned out to depend on the debugging and stopped working when debugs were removed. You must run a full suite of tests again after removing the debugs. Test every code path, even the ones that are supposed to produce error messages.
As westfw said, often the debug error messages turn out to be necessary in the production environment. For example when you've got the client on the phone on the other side of the world, asking them to do something like "Unplug the sensor and read me the error message" is necessary to make them go around the back of the unit to see that power wasn't plugged in.