The title is misleading, because defmt is not a debugger, but a logger (with a twist). A better title would be "Cheap Logging with Embedded Rust", or something like that.
The cool thing about defmt is that it doesn't do string formatting in the program itself. The problem with logging is that many formatting operations - like formatting floats as strings - can be very expensive on small embedded microcontrollers, both the runtime cost as well as a big increase in binary size. Instead, defmt sends the memory representation of the logged values to the host (over an arbitrary transport like UART or RTT). The formatting / visualization of the logs is then handled on the host side.
This has the downside that you cannot simply connect a random serial console to your microcontroller for logging, because defmt uses its own non-plaintext format. But it has the huge advantage that you can do very efficient logging in the microcontroller firmware, and then visualize all those logs on your host with an appropriate client.
I've built such systems in C++ before, and they really are extremely useful. You get much more efficient logging (in terms of CPU time, code size, and bandwidth on the wire), and it's automatically structured. printf style logging seems extremely primitive in comparison. It also pairs very well with asynchronous logging (just sticking the logged data into a ringbuffer to be transferred in bulk later), since then you can stick logs statements practically anywhere, often including interrupts and whatever mechanism you are using the transmit the logs.
This article doesn't even get into the awesomeness of `cargo build` and `rtt-target` or `probe-rs`! I use these things in my Riskeyboard 70 hall effect keyboard firmware to provide a full-screen debugging interface that gives me real-time output of basically everything that's going on in the keyboard.
It has "channels" and each channel gets its own tab in the built-in interface. It's so sweet! Check it out (I'm typing F1 through F7 to go through all the channels):
To get to that interface I just ran `cargo build --release` and it comes up automatically :D
The values output in the various "AM<num>" tabs are the readings from the hall effect sensors (in millivolts). So I can see that I had a lot of work to do on voltage wobble, haha. We'll see how well I did in fixing it with the next revision of the PCB (which I can't order because everywhere is out of stock of the hall effect sensors I need! SOT-23 "49e" sensors if you're curious which sensor).
Though not yet clear to me how to do this, apparently those tabs (as in your case, with the wobbling millivolts) can be mapped to graphical output, like a scope view. That would be a true step up for embedded debugging. Awesome.
In this chat they map (what I presume to be) a channel to colors: https://youtu.be/BZqt187RWTw?t=506. Haven't had the time to look at it in detail yet.
The cool thing about defmt is that it doesn't do string formatting in the program itself. The problem with logging is that many formatting operations - like formatting floats as strings - can be very expensive on small embedded microcontrollers, both the runtime cost as well as a big increase in binary size. Instead, defmt sends the memory representation of the logged values to the host (over an arbitrary transport like UART or RTT). The formatting / visualization of the logs is then handled on the host side.
This has the downside that you cannot simply connect a random serial console to your microcontroller for logging, because defmt uses its own non-plaintext format. But it has the huge advantage that you can do very efficient logging in the microcontroller firmware, and then visualize all those logs on your host with an appropriate client.
More details can be found in the article itself.