defmt VS tracing

As someone who had only done embedded programming in the Arduino IDE, utilizing the defmt crate for logging with OpenOCD and GDB was an amazing experience. Although I still had no idea on to implement USB-HID for actually sending the key reports, until I discovered the usbd-human-interface-device crate and everything became so much easier. I just needed to create an iterator over Keyboard events and the crate would handle the rest as an added benefit the crate also supports multiple devices, so adding mouse support was as easy as creating a separate iterator over WheelMouseReport.

I think I want to use the QEMU emulator (as suggested in the Embedded Rust Book) and tests created with defmt-test. But I can't figure out how to get them to work together.

On embeded defmt is often used https://github.com/knurling-rs/defmt

defmt is a great framework for general logging.

Great writeup! The defmt logging crate uses a linker script to extract debug symbols so that you get nicely formatted stack traces on embedded systems. It works on linux, macos and windows. I wonder if the same technique can be applied to this project. It needs a runner though so may not be the right approach.

https://github.com/knurling-rs/defmt

Just played with embedded stuff today. defmt can be used for logging instead of println since there's not really a stdout when running on bare metal.

yYeah. For example, instead of printf("Variable X = %d, y=%f", x, y), where the micro then formats the string and pushes it out a serial port, blocking until its sent, I can write LOG("Variable X = %d, Y=%f, x, y), and what actually happens is a unique pointer to the string, and a tagged raw int and float get pushed onto a buffer, which takes about 15 instructions and takes up 16 bytes in the buffer. The buffer is then asynchronously sent out over the serial port, and the PC knows how to map the string ID to the actual string (this can by dynamically fetched from the micro or stored like debug info if there's not enough flash for the strings), and applies the formatting. There's an added bonus that it's super easy to take any variable which is logged and plot it live over time. There's also stuff like if the system crashes and the watchdog resets it, the buffer can be read out from memory to catch anything which wasn't sent out yet. It's a bit more of a complex system to set up but it really makes printf feel like the stone age when you get to using it. For an example of a similar system in rust, https://github.com/knurling-rs/defmt is implementing the same ideas (I don't know of any publicly available equivalent in C or C++, but you can implement it the same, though C++ is easier and it helps to know your way around a linker script to make something properly ergonomic).

If the build constraints are amenable for your project, you might also enjoy knurling-rs' defmt logging framework.

The video description is as follows:

In this stream, we peel back the crust on the tracing crate — https://github.com/tokio-rs/tracing/ — and explore its interface, structure, and mechanisms. We talk about spans, events, their attributes and fields, and how to think about them in async code. We also dig into what subscribers are, how they pick up events, and how you can construct your own subscribers through the layer abstraction. For more details about tracing, see https://docs.rs/tracing/latest/tracing/.

> What's been your biggest issues around ergonomics/amenities for OpenTelemetry?

I can't speak generally, but in the Rust ecosystem the various crates don't play well together. Here's one example: <https://github.com/tokio-rs/tracing/issues/2648> There are four crates involved (tracing-attributes, tracing-opentelemetry, opentelemetry, and opentelemetry-datadog) and none of them fit properly into any of the others.

The tracing (logging) mechanism in an asynchronous codebase (tracing).

Tracing is Tokio's alternative for async code.

At a technical level, in Rust, both [tracing]https://crates.io/crates/tracing) and log are entire ecosystems (though for the latter at least there's also third party logging frameworks), and there's at least a bridge from log to tracing.

I am using https://github.com/tokio-rs/tracing for logging purposes in my application. I would like to develop a feature wherein logs should be saved to a database table (via sea-orm). Something similar is this, but it does not solve my needs fully.

I've used the tracing infrastructure with tracing_flame to profile some hot paths in async code: https://github.com/tokio-rs/tracing/tree/master/tracing-flame

Oh nice! IIRC when I checked, it was the Unicode tables that smashed the code size. I recently hit the same issue with the tracing crate, where a crate feature (for env var filtering) pulled in regex and my binary was suddenly 1MB bigger.

I know about tools such as tracing, jaeger or tracy. While having a complete tracing could be a potential solution, these tools don't work with no_std.

tracing by itself only outputs log data, you need to consume them in a subscriber, the tracing-subscriber crate exists for this. (example)