However this get real messy real fast and can make the code all but impossible to read if there are a lot of them.
It's possible what you are suggesting will work, ie of you don't call Serial.begin all subsequent prints will do nothing. I would expect the Serial library to have something
if (not_inited) return;
At the start of all calls. In which case you are OK.
It's not all that kosher but may work as long as your application doesn't need to use the serial port.
Please correct me if I'm wrong. But isn't reply #3 just a preprocessor version of what I originally said?
No, because instead of writing
#if DEBUG
Serial.print (blah);
#endif
repeatedly, you just write DEBUGMSG(blah); wherever you want debug output.
If DEBUG is 0, then the prints simply don't exist, so no need for a runtime conditional - the preprocessor takes care of it all.
(I usually do it with "#ifdef DEBUG", but the principle is the same. If pushed, I'd probably write some PROGMEM macros for debug prints if I thought I'd need a lot of them)
The disadvantages of prints running into nowhere are:
The messages consume precious RAM
Even if they go nowhere, at 9600 baud, they delay your program by over 1ms per character.
I currently have over 120 serial.print lines for debugging and would like to put a lot more.
Thats a lot of debugging lines... I wonder did you make design for your sketch. What your sketch supposed to do and in what order? just with a pencil and paper and a pair of brains and a mug of coffee? One clear design prevents 100's of debug statements...
And beware, so much debug statements affect the behaviour of your sketch ...
BTW Another option to debug is using a spare pin with a LED, could be enough in many places and is very fast...
@SparksAlot
It's very unusual to have that many debug statements and also to leave them in the code.
I can think of one function where I have done so because it's quite complicated and for some time a new bug kept popping up so it was convenient to just re enable the debug statements rather than figure out what to print all over again. (no bugs for a year or so now, maybe I should clean it up :))
However in general a program should be modular with each module (normally a function) tested with test data then ticked off as working and all the debug dross removed.
I always say leave it where it is.
If you have a robust, generic and tested method of enabling and disabling test code, then the fewer times you edit a source file, the fewer chances there are for the inadvertent introduction of bugs.
The temptation of "I'm here to remove the debug code, but I'll just have a little tidy up while I'm at it" is too great for most tinkerers.
It's what we do in my day-job (many MLOCs).
Always be aware, however, that even if it isn't connected to anything, enabled debug code may be affecting performance and consuming resources like time and RAM.
enabled debug code may be affecting performance and consuming resources like time and RAM.
Stronger: enabled debug code ALLWAYS affect performance and resources, but it can also affect the logic/semantic of your application (esp real time behavior, e.g. IRQ's )
In my app, I was spending so much time dumping debug messages out the first serial port that it made the problem worse by delaying the app, causing me to miss bytes coming in to the other serial port.
The macro solution suggested earlier is a good one.
Too bad we don't have a source level debugger! That would save SO MUCH time!
The temptation of "I'm here to remove the debug code, but I'll just have a little tidy up while I'm at it" is too great for most tinkerers.
That's true. I guess all shops have different practices. In one place I worked the code had to be tested without any debug code (commented or #if'd out), then we had to remove all debug code and DIFF the file(s) against the originals. The lot was then peer reviewed by a colleague. No "tinkering" was allowed.
Another practice for small changes was to add initials and date on every changed line, something like
/rg12jul85/
It was quite common as the first debugging technique when a bug was reported to search for a couple of well-known initials (of people who had not lasted in the job) for suspect code
AWOL:
2) Even if they go nowhere, at 9600 baud, they delay your program by over 1ms per character.
If the USART Transmitter has not been enabled, then it will not spend any time shifting out any characters put into the Transmit register. The Data Register Empty and Transmit Complete flags will always be true. The only time that will get consumed is the write operation pushing characters into the Transmit buffer and waiting for the UDRE flag to get set (which will always be set). This still takes some time, but it'll be on the order of a few microseconds per character.
That being said, it's still a poor method of enabling/disabling debug messages. The method westfw presents is far better (and doesn't prevent you from using the serial port for other purposes as well).
By "nowhere", I meant that the code was enabled, but there was nothing hanging off the Tx pin.
The only time that will get consumed is the write operation pushing characters into the Transmit buffer and waiting for the UDRE flag to get set (which will always be set). This still takes some time, but it'll be on the order of a few microseconds per character
And when you send another character when there's one already being sent, like in a multi-character debug string?
Every time you go to write a new character, you have to wait until the last one has been clocked out, so every character (apart from the first, assuming it is more than a character period since the last string was sent) will consume, at 9600 baud, over 1 millisecond, whether or not there is something at the far end of the serial line/USB serial/taut string to receive it.
void HardwareSerial::write(uint8_t c)
{
while (!((*_ucsra) & (1 << _udre)))
;
*_udr = c;
}
