Hi Everyone!
I just discovered the logging classes that are available after a long time of just using Serial.print statements to output info from my application.
I was just curious… is there any pros or cons of using the logging functions over serial.print that we should know about? Is there best practice people use for using one vs. the other?
Thanks!
One thing is granularity.
You can easily filter for different log levels by just instantiating a log handler for the desired level without cumbersome if/#ifdef constructs.
You can also target different channels than just Serial by instantiating a different handler (e.g. UDP, TCP, Serial1, …)
Just beware that I have found some weird behaviour with the Log class that actually causes Kernel panic, whereas a Seriial.printf() in the exact same code position works fine.
Am yet to find an explanation for this.
That said, logging is the way to go, especially now with the addition of USBSeriial1. Associate the Logger class with this port and it frees up Serial for application use rather than debugging.
Update to my kernel panics for logging within some routines. The issue was within routines called within a timer callback. So beware!
Hi,
I have seen the same thing, SOS when using the logger from timmer routines.
So for anyone that may have run into strange behaviour when using Serial from within callbacks, this is one of the major pitfalls that I myself fell into many years ago. The temptation is to log when an event happened exactly when it happened but the best way to do it is to set a boolean flag and possibly save a timestamp and log from within your main loop. Things may appear to work fine at first but your whole program is doomed to fail if you print in an interrupt. My only guess at why this happens is that it has something to do with the program counter and interrupts literally jumping out of order and throwing a wrench into the logic of the serial class.