Unified print library

[Avamander]

Due to all the differences between different micro-controllers this library works on the current method of printing debug, warning and error messages is rather clunky and ugly (relatively speaking), often causing confusion. Because of that I propose that a universal serial printing wrapping library is created. (Also see nRF24/RF24#189 (comment))

I opened identical issue also in nRF24/RF24Network#103 nRF24/RF24Mesh#110

(This would also prove really useful for other RF24* libraries, maybe even for some other libraries too)

[wmarkow]

@Avamander, if I understand correctly that need to be some kind of abstraction which exposes some common/unified API methods. That common API could be used for logging purposes in general C/C++ code (so it would be portable). During the compilation it will "somehow" detect the target hardware and use the correct implementation to print to serial. Of course the unified library needs to provide the proper printing implementation for every supported hardware, right?

[Avamander]

Indeed. You are interested in implementing something of that sort?

[wmarkow]

I was just thinking that this library could be used for a logging purposes. Let me just one more question: would it be something similar to slf4j project for Java? slf4j is some kind of facade on different logging frameworks. The library could do the same (but with a lot of limitations - we are working with embedded devices). I imagine that with this library you could:

• provide a standard abstraction API that could be portable
• provide some methods to log messages at different level, like info, warn, error, debug
• configure what global logging level you want in your application; one of info, warn, error, debug
• choose what log appenders you can use:
  • DevNullLogAppender which will trash your logs. This could be a default implementation for platforms/devices that do not have any display, file system, or serial port (the code will compile but logging will not be available)
  • SerialPortLogAppender wich will output the logs to the serial port. This could be a default implementation for Arduino (for instance)
  • ConsoleLogAppender which will print the logs to the console. This could be useful for RaspberyPi platform.
  • FileLogAppender which will output the logs to file. This could be useful for RaspberryPi platform.
• when you implement a library you just use some standard API methods (info, warn, error, debug) to log
• when you implement the final application the default log appender would be info, warn, error, debug but you could register some other if you want

The library must provide a proper implementations for various platforms. I feel like the DevNullLogAppender would a common for all of supported platforms (even for those which are not yet supported). This appender will just do nothing. On unsupported platforms/devices the code will compile but logging will not be available.

The question is: would it be so simple as I described above or maybe I'm missing something that I'm not aware of (and the thing would not be so easy then)?
Second question: are we talking about C or C++ (or both)?

[Avamander]

It never is as simple, but it won't be hard either.
C and C++ wrapper seems reasonable?

Though I've been thinking, what about @TMRh20 making a GH RF24 organization and creating both this library's repository there and moving other RF24* under that organization too?

[wmarkow]

I have found something similar for C++. It is called plog. Its readme document is very nice especially this image.

@Avamander, are you talking about something similar? This plog may be to heavy for Arduino and embedded systems but at least we could learn something.
C and C++ wrapper sounds reasonable so somebody could choose what he need. On github repo for C version and another one for C++ wrapper?

[Avamander]

Indeed. Though I feel like the wrapper and library can be put into the same repository.

[TMRh20]

I'm not able to keep up with these discussions lately, but sounds like some good ideas. If anyone wants to take charge with RF24 org etc, feel free. I'll still contribute what I can. Thanks for keeping things going!

[Avamander]

@TMRh20 I made an organization, but your help is needed for migrating the repositories, sites.

[TMRh20]

Ok, I'll check that out soon. Not very familiar with it, so let me know if you need something specific.

[Avamander]

@TMRh20 To migrate a repository to an organization go to repository Settings->Transfer->Type in the name and the organization.

[2bndy5]

I'm picturing a StringStream type library to get things rolling. There are so many issues that get snagged on the printf() problem. I love the idea of adding logging levels, but people I've collaborated with in the past tend to inadvertently kill a project by setting goal(s) way too high before the code-base even gets a skeleton to build from. With that said, you can probably guess I'm a "don't re-invent the wheel" kinda guy.

@Avamander I assume you want to take the lead and start a new nRF24 repo in this regard. We could always merge the stable product into RF24 repo (maybe using submodule feature), but this idea clearly needs a home for incubation (evident by duplicate issues accross multiple repos).

@TMRh20 @Avamander @Oitzu @wmarkow Anyone opposed to starting a nRF24 github "project" so we can expedite efforts via Kanban board? I'd say let's form a Github "team", but without $$, this github org is limited to having only teams of 7 people (can't remember if multiple teams is also limited).

p.s I wish the org name wasn't the same name of the RF24 (core) repo. Can we address this now before it gets too confusing? It would require a owner's consent.

[Avamander]

I assume you want to take the lead and start a new nRF24 repo in this regard.

I can create one, yes.

Anyone opposed to starting a nRF24 github "project" so we can expedite efforts via Kanban board?

An issue would suffice.

Can we address this now before it gets too confusing?

It's nRF24 not RF24, and it's been like this for years. Changing would cause a lot of problems with little benefit.

[2bndy5]

years?! nevermind. oops I didn't see how old this thread was

[Avamander]

Oh you mean the display name, I changed that, it doesn't affect any URLs or anything.

[wmarkow]

I have found this:
https://github.com/thijse/Arduino-Log

I just took a quick look at this project.