knurling-rs
Proposal: Support reading from multiple RTT channels
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.
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.
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.