I was looking at both ufmt and defmt a few months ago and was wondering what made them so much lighter than std-based options, and this explains it pretty well!
One thing that'd be interesting is hosting the dfmt dictionary on the device itself. You'd lose some of the space savings, but the dfmt dictionary wouldn't need to stay in-ram, and it'd only need to be transfered to the client once. I.e. if you have a microcontroller with 32kb of memory and 512kb of ROM, with each one log message by default being 800 bytes long, each dfmt-ed log message being 4 bytes long, 5000 different log messages, and a 128kb dfmt dictionary, then your usage figures would look like this A : no dfmt - can't run Executable uses at 5000*800 bytes, aka 4,000,000 byes, aka 4mb. Since you only have 32kb of memory, you cannot run this program. (or, more accurately you can't store the entire executable in active memory, which generally means it's a pain in the ass to run) Rom is also using at least 4mb just to store the program. So this hypothetical program wouldn't fit in either your RAM or ROM. B : dfmt - can run Executable uses only 4*5000 bytes since it only needs to operate over dfmt-encoded strings. I.e. it needs 20,000bytes, aka 20kb. So the logging uses 20/32 of your kb of memory. Your rom also only needs to store 20kb of dfmt encoded text data. The device can also theoretically run faster since it spends less time and resources managing longer lengths of memory. HOWEVER, if you don't have the dfmt dictionary the logs are gibberish C : dfmt with included dfmt dictionary on-device - can run Executable sitll only uses 20kb, requriing 20/32kb of your memory. Your rom also needs to store that 20kb of the executable. HOWEVER, you're also storing the 128kb dfmt dictionary, meaning in total you are using 148/512kb of your ROM for dfmt strings. This setup also achieves the theoretical runtime benefits of dfmt by not needing to send entire strings. HOWEVER, unlike the previous case, since the entire dfmt dictionary is stored in ROM anyone can request the device give them it's dictionary to read it's logs. These are obviously fabricated numbers, but it illustrates the general principle. Storing a dictionary AND the compressed data can very well be smaller than the full, uncompressed data. This should be obvious since it's how literally all modern data compression works, but this is a youtube comment section so assuming that anything is 'obvious' is a fatal error.
These videos are great! After coming from Arduino serial printing, using defmt for the first time straight up blew my mind. I am also at the point now where I would benefit greatly from being able to transmit my defmt logs wirelessly, and have also wondered about the versioning issue. Looking forward to your next video!
I'm going to have to try defmt a bit more then. I was testing Embassy on an STM32 with nothing more than an LED that turns on when a button is pressed and the debug build wouldn't fit into 64k of flash. I may not have been doing it correctly now that I see how you setup and used defmt. Thanks.
@@googelstevejobs21it's better to tweak the dev profile. For example, using [profile.dev.package."*"] opt-level = "z", will optimize all your dependencies for size while keeping your crate unoptimized and fast to compile
Oh, I think I have a nice usecase for this Having a tiny MCU in a device and bigger wi-fi enabled mcu as an addon will allow me to keep firmware tiny and have formatting happen on big MCU if it's connected
I love your videos, quality over quantity is appreciated. As a starting embedded software engineer it is useful to get these tips & insights. I'm messing around with the 'blue pill' (STM32F103C8T6) and Rust in my private time, got some trouble flashing with probe-rs. Have you tried experimenting with the ESP32 platform and their Rust implementation? That is also very interesting to look into (and FRTOS)
I have an ESP32 sitting on my desk, but haven't done anything with it quite yet. It is a pretty popular target for embedded Rust so I imagine there will be a video/project with it in the future...
Just a suggestion. But do you plan to also cover the tracing crate from the Tokio team? Similar topic but especially useful once you start working with multiple tasks. I know this is not primarily an embedded topic then but maybe
Possibly? The channel is still young so I wouldn't rule anything out at the point. That said, I feel like I have enough embedded content to fill out my schedule into the foreseeable future.
It does give the same vibe. There's a crate called postcard-rpc that implements that for embedded systems (but your PC would need to run postcard-rpc too to decide the messages)
