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.
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!
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!
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'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
@@googelstevejobs21 I found out that I could turn on optimization level "z" for my dependencies. This has resulted in debug and release code of nearly the same size because my program is trivial. Still, it is about 22k so I just need to find out if that is typical for an embassy based program. The device that I would target has 512k of flash so size may not be an issue regardless.
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.
@@slash.9882yeah I feel like the difference here is crate. Having a built in package manager is so much nicer than manually installing a library, and having to mess with file paths to that library in your program
What crate is being used at 0:11 for interfacing with the ublox module? I just noticed it in passing. I have found a the ublox-cellular-rs crate, but was wondering if there was another I missed.
This is unfortunately just a simulation of driver debugging via logging and not an actual crate… Used a number of cellular modems in my last job and discovered a lot of undocumented behavior this way.
Good question! There is actually an open issue for this in rust-lang/rust: github.com/rust-lang/rust/issues/118337 The TLDR appears to be that when building a project you are pulling in a pre-built binary for the core library float formatting functions (for your indicated target). These libcore binaries are built by the Rust Project to be optimized for speed and not code size, and therefore result in them being quite large.
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)
Now I finally understand what defmt does differently, thank you
you have a great presenting style!
Please continue making videos. You are clearly an expert and have consistently high quality.
Would love to see a non debug probe setup for this. Great video as always!
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.
Neat!
I almost feel a bit worried by how seemless that was. This crate is definitely on my reading list now.
Can't wait for that future video now!
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!
Very clear. Nice. I especially appreciated the tail joke.
That's hands down the best beginners tutorial about defmt I have seen so far! Well done
Thank you for your videos!😊
Nicely explained, can't wait for the follow up video about this topic!
Amazingly presented, love the editing and storytelling and the pace
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 was wondering about how to accomplish that. Do you have any ideas about how to actually accomplish that?
I've read the thumbnail as "Deform your legs". Insert "instructions unclear" meme
This feels a lot like Windows ETW. Nice.
I like that your RTT buffer is 8 times the total SRAM on one of my favourite microcontrollers. :)
Wow, love that defmt after what I've seen here😆
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
Great work as always!
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.
rule of thumb: always do a release build for embedded. Debug is just too big.
@@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
@@googelstevejobs21 I found out that I could turn on optimization level "z" for my dependencies. This has resulted in debug and release code of nearly the same size because my program is trivial. Still, it is about 22k so I just need to find out if that is typical for an embassy based program. The device that I would target has 512k of flash so size may not be an issue regardless.
Fascinating video
He is back 🔌
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...
Good video
Keep going, you deserve more subs
Realy looking forward to the next one. Your channel will blow up, trust me. Can I invest somehow? 😅
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.
Very nice. rust seams amazing compared to c
You could implement the same server side formatting trick in c.
@@prestonmlangford yes, but it seems way simpler on rust, it’s basically baked into a container
@@slash.9882yeah I feel like the difference here is crate. Having a built in package manager is so much nicer than manually installing a library, and having to mess with file paths to that library in your program
@@prestonmlangford you can do it in assembly too. Still prefer rust
What crate is being used at 0:11 for interfacing with the ublox module?
I just noticed it in passing. I have found a the ublox-cellular-rs crate, but was wondering if there was another I missed.
This is unfortunately just a simulation of driver debugging via logging and not an actual crate… Used a number of cellular modems in my last job and discovered a lot of undocumented behavior this way.
Why does float formatting grow the binary size so much?
Good question! There is actually an open issue for this in rust-lang/rust: github.com/rust-lang/rust/issues/118337
The TLDR appears to be that when building a project you are pulling in a pre-built binary for the core library float formatting functions (for your indicated target). These libcore binaries are built by the Rust Project to be optimized for speed and not code size, and therefore result in them being quite large.
Isn't this basically like protocol buffers
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)
What about the tracing crate, is it used in embedded?
AFAIK tracing isn’t used in embedded/no-std systems