See What does the c precompiler do with macros defined as (void)0 What does the c precompiler do with macros defined as (void)0 - there are subtle issues with using an empty define compared to void(0).
See What does the c precompiler do with macros defined as (void)0 - there are subtle issues with using an empty define compared to void(0).
See What does the c precompiler do with macros defined as (void)0 - there are subtle issues with using an empty define compared to void(0).
Semicolon is not part of the macro, so it will be expanded into:
if (something) ;
See What does the c precompiler do with macros defined as (void)0 - there are subtle issues with using an empty define compared to void(0).
For example:
Serial.println ("hi there"), LOGLN ("debugging");
That fails to compile (with the empty define) if debugging is off. The void(0) version does compile. Admittedly it's an edge case, but nevertheless ...
Semicolon is not part of the macro, so it will be expanded into:
if (something) ;
See What does the c precompiler do with macros defined as (void)0 - there are subtle issues with using an empty define compared to void(0).
For example:
Serial.println ("hi there"), LOGLN ("debugging");
That fails to compile (with the empty define) if debugging is off. The void(0) version does compile. Admittedly it's an edge case, but nevertheless ...
A quick test shows that not doing a Serial.begin makes things run 10 times as fast. For example:
void setup ()
{
Serial.begin (115200);
pinMode (13, OUTPUT);
} // end of setup
void loop ()
{
digitalWrite (13, HIGH);
for (byte i = 0; i < 100; i++)
Serial.println ("But does it get goat's blood out?");
digitalWrite (13, LOW);
delay (500);
} // end of loop
That took 292 ms to do 100 x of those prints on my Uno. If I comment out the Serial.begin call it takes 29 ms. So, faster but not incredibly fast.
On my page about debugging I have suggested code to turn on or off debugging prints. The basic idea is to have a Trace define that lets you output stuff if debugging is on, like this:
#define DEBUG false
// conditional debugging
#if DEBUG
#define beginDebug() do { Serial.begin (115200); } while (0)
#define Trace(x) Serial.print (x)
#define Trace2(x,y) Serial.print (x,y)
#define Traceln(x) Serial.println (x)
#define Traceln2(x,y) Serial.println (x,y)
#define TraceFunc() do { Serial.print (F("In function: ")); Serial.println (__PRETTY_FUNCTION__); } while (0)
#else
#define beginDebug() ((void) 0)
#define Trace(x) ((void) 0)
#define Trace2(x,y) ((void) 0)
#define Traceln(x) ((void) 0)
#define Traceln2(x,y) ((void) 0)
#define TraceFunc() ((void) 0)
#endif // DEBUG
void setup ()
{
beginDebug ();
pinMode (13, OUTPUT);
} // end of setup
void loop ()
{
digitalWrite (13, HIGH);
for (byte i = 0; i < 100; i++)
Traceln ("But does it get goat's blood out?");
digitalWrite (13, LOW);
delay (500);
} // end of loop
Now in this case, with DEBUG defined as false, the time taken with pin 13 high is now only 5 μs - a substantial speed-up.
If you define DEBUG to be true, then it is much slower - 290 ms as in the first test.
The suggestion made by KIIV will fail if you have if statements:
#ifdef NDEBUG
#define LOG(...)
#define LOGLN(...)
#else
#define LOG(...) Serial.print(__VA_ARGS__);
#define LOGLN(...) Serial.println(__VA_ARGS__);
#endif
For example:
if (something)
LOG ("something is true");
digitalWrite (8, HIGH);
Imagine that debugging is off. Now the empty define makes the code look like:
if (something)
digitalWrite (8, HIGH);
So you have a side-effect that the code behaves differently if debugging is off.