You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm working on a project to multiplex debug logs, companion CLI, and bridge packets over a single connection (specifically Serial or one of the HardwareSerials from the Arduino core). I might look to extend that to a single BLE or WiFi connection as well.
How various types of logging are done across the MeshCore firmware currently is pretty sporadic. Sometimes the "project wide" (MeshCore.h) macros like MESH_DEBUG_PRINT or BRIDGE_DEBUG_PRINTLN are used. Sometimes helpers/libraries like ESPNow define their own macros. Sometimes code will be #ifdef'd on MESH_DEBUG but then use the Arduino Serial instance directly. And some code will just unconditionally use the Arduino Serial instance directly.
It would be great to have a logging abstraction with a sane default but easily customizable implementation. I’m willing to do all the initial work to transition the codebase over to such an abstraction (including code that’s currently commented out), but going forward it would require buy-in from maintainers not to accept PRs which bypass/break whichever abstractions we come up with.
How?
The PR linked below is what I’ll call a “back-of-the-envelope” proposal for what an abstract logging interface in MeshCore could look like. I’m not emotionally invested in any part of it, I suggest only that we should decide on a unified way to talk to “the outside world” which isn’t tied to a specific communication peripheral at place of use.
MESH_DEBUG_PRINT is already such an abstraction. It’s just not universally used, and things like bridge implementations or packet logging probably deserve separate consideration. I think MESH_DEBUG_PRINT and similar macros could (and should) continue to exist so that it’s easy to include/exclude various categories of debug logs at compile time. However when they are enabled, they should generate code which calls into a logging abstraction rather than talking to communication peripherals directly.
I do have a local branch where I've gone through the rest of the code in the MeshCore repo and converted it to use these abstractions where necessary. However I won't put that up as a PR until the final design is hashed out.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Why?
I'm working on a project to multiplex debug logs, companion CLI, and bridge packets over a single connection (specifically
Serialor one of theHardwareSerialsfrom the Arduino core). I might look to extend that to a single BLE or WiFi connection as well.How various types of logging are done across the MeshCore firmware currently is pretty sporadic. Sometimes the "project wide" (
MeshCore.h) macros likeMESH_DEBUG_PRINTorBRIDGE_DEBUG_PRINTLNare used. Sometimes helpers/libraries like ESPNow define their own macros. Sometimes code will be#ifdef'd onMESH_DEBUGbut then use the ArduinoSerialinstance directly. And some code will just unconditionally use the ArduinoSerialinstance directly.It would be great to have a logging abstraction with a sane default but easily customizable implementation. I’m willing to do all the initial work to transition the codebase over to such an abstraction (including code that’s currently commented out), but going forward it would require buy-in from maintainers not to accept PRs which bypass/break whichever abstractions we come up with.
How?
The PR linked below is what I’ll call a “back-of-the-envelope” proposal for what an abstract logging interface in MeshCore could look like. I’m not emotionally invested in any part of it, I suggest only that we should decide on a unified way to talk to “the outside world” which isn’t tied to a specific communication peripheral at place of use.
MESH_DEBUG_PRINTis already such an abstraction. It’s just not universally used, and things like bridge implementations or packet logging probably deserve separate consideration. I thinkMESH_DEBUG_PRINTand similar macros could (and should) continue to exist so that it’s easy to include/exclude various categories of debug logs at compile time. However when they are enabled, they should generate code which calls into a logging abstraction rather than talking to communication peripherals directly.I do have a local branch where I've gone through the rest of the code in the MeshCore repo and converted it to use these abstractions where necessary. However I won't put that up as a PR until the final design is hashed out.
Pull Request
Beta Was this translation helpful? Give feedback.
All reactions