Nonblocking rtt

[usbalbin]

Hi :)

I am using defmt_rtt to log data in a rtic realtime application where there are quite tight timing requirements. The code runs on an stm32g474. I have noticed that sometimes the entire program is frozen for several milliseconds when having the logging active, the problem goes away when disabling the logging. I have tried doing the defmt-stuff (defmt::info!, defmt::error! etc) in the idle task using channels to send the data from the high prio interrupt, but that still locks up everything including the high prio interrupts. Same thing here when disabling logging, everything works fine.

I read in the doc that defmt_rtt will be run in blocking mode. Is there any way to avoid that? I am fine with losing data(I am using it to plot graphs, losing some data points is ok) however it can not under any circumstance lock up the high prio interrupts more than a few µs or chances are the magic smoke will be released (or watchdog timeout).

[usbalbin]

I am happy to give implementing this a go if you think this would be a useful feature and anyone could give some sort of pointers as how/where this should be done.

Sorry if sounding grumpy, I am really happy with defmt in my more normal projects :), but I am having a hard time seeing how to solve my niche use case here. Would some nb::Error::WouldBlock type of API be possible?

And/or having the option of not using defmt in the log-like global way but instead passing around some sort of handle. However I understand if this would not be possible/compatible with how things work today. But then I am not supposed to make a 3rd party crates depending on the defmt for compressing the data either so I can not do that either, right?

[usbalbin]

I suppose this is also/could be related to #718

[usbalbin]

Related/duplicate of #133?

[ArXen42]

Just today I was debugging why my interrupt-based USART was consistently having overrun error flag and realized that this is due to defmt-rtt using critical section and therefore causing my 8MHz MCU to miss characters due to disabled interrupts (whenever I added logging in the embassy task doing the reading).

Not sure what would be good solution for this, but the issue is definitely noticeable.

[jonathanpallant]

Having the RTT buffer being blocking or non-blocking is a choice that the host can make (by setting a bit in the flags register).

However, how we have #915 for overriding what your host chooses to do.