Closed phrxmd closed 5 years ago
HI, I agree that, and I will work in one solution
Hi, I just upload a new version: 1.5.8 New macros to compatibility with SerialDebug (can use RemoteDebug or SerialDebug) As SerialDebug is based in macros and RemoteDebug is based in C++ class, due this functionality, not is possible 100% compatibility, I sugest that use #defines to use one or another library, example:
and:
// RemoteDebug
RemoteDebug Debug;
// Initialize RemoteDebug
initializeRemoteDebug();
// SerialDebug
// Add Functions and global variables to SerialDebug
// Add functions that can called from SerialDebug
//debugAddFunctionVoid(F("function"), &function); // Example for function without args
//debugAddFunctionStr(F("function"), &function); // Example for function with one String arg
//debugAddFunctionInt(F("function"), &function); // Example for function with one int arg
// Add global variables that can showed/changed from SerialDebug
// Note: Only global, if pass local for SerialDebug, can be dangerous
debugAddGlobalUInt16_t("motorSpeed[0]", &mMotorControl.mMotorSpeed[0]);
debugAddGlobalBoolean("motorForward[0]", &mMotorControl.mMotorForward[0]);
debugAddGlobalUInt16_t("motorSpeed[1]", &mMotorControl.mMotorSpeed[1]);
debugAddGlobalBoolean("motorForward[1]", &mMotorControl.mMotorForward[1]);
This looks very nifty!
What I find inconvenient, however, is that the library uses a different interface than your own
SerialDebug
library. There we haveDebugV()
,printlnD()
,debugHandle()
etc., here we haveDebug.printf()
,rprintlnD()
,Debug.handle()
etc.. Because of this inconsistency neither library is a drop-in replacement for the other and you have to keep modifying your code if you want to change the debugging target.Personally I think I prefer the way it is done here (through a
Debug
object and macros that refer to it). But I think either way would be fine, as long as they're consistent.