Proposal: Support reading from multiple RTT channels

[mattico]

My application requires fast responses to certain interrupts, so I need to minimize the amount of time that interrupts are disabled. To this end I created an RTT logger which allocates a separate Up channel for each execution thread priority so each thread can write in a lock-free manner. The channels >0 are left in nonblocking mode and I rely on the rzcobs framing to recover from buffer overruns. This method works very well to transmit a large amount of tracing data using a fast probe. probe-run is modified to read from all available Up channels, so it continues working with single-channel uses as normal.

This PR currently includes all the changes from my branch. I wanted to first open this as a discussion to see if there's interest in supporting this before putting the time in to clean it up for merging.

Things to consider:

• This branch includes features to write data to a file and filter which messages are displayed on stdout. These could be considered separately.
• Currently channel 0 is always set to blocking and the rest of the channels are not. This works for my use case but maybe someone would want it to be configurable?
• This should probably be disabled for defmt's raw wire format.
• This should probably be disabled or use line-buffering for non-defmt data.

[Urhengulas]

Hi @mattico, we are currently busy with finishing up the defmt 0.3 release. Afterwards we will evaluate what useful next steps are and will come back to you.

[mattico]

Here's an example Multi-RTT Logger implementation: https://gist.github.com/mattico/b2abbf63cb4bc2f434a81744d023add2

It would be pretty neat to have a macro create a logger implementation from a user-supplied memory and priority configuration. In practice I don't think it's a huge burden for those who need the Multi-RTT performance to copy the implementation into their project and change the buffers and priorities as required.