Embedded Rust's logging sorcery

[@MaxWeninger]

That's hands down the best beginners tutorial about defmt I have seen so far! Well done

you have a great presenting style!

[@hermannpaschulke1583]

Now I finally understand what defmt does differently, thank you

[@argonaut4772]

Please continue making videos. You are clearly an expert and have consistently high quality.

[@PeterKrull1]

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!

[@pedromartinspersonalemail5100]

I was wondering about how to accomplish that. Do you have any ideas about how to actually accomplish that?

[@jaopredoramires]

Amazingly presented, love the editing and storytelling and the pace

[@Themreg9]

Neat! I almost feel a bit worried by how seemless that was. This crate is definitely on my reading list now.

[@jan_the_man]

Would love to see a non debug probe setup for this. Great video as always!

[@RiwenX]

Can't wait for that future video now!

[@fromeijn]

Nicely explained, can't wait for the follow up video about this topic!

[@mikkelens]

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!

[@robonator2945]

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.

[@MrMassaraksh]

Thank you for your videos!😊

[@dgkimpton]

Very clear. Nice. I especially appreciated the tail joke.

[@xTatsuran]

I've read the thumbnail as "Deform your legs". Insert "instructions unclear" meme

[@edgeeffect]

I like that your RTT buffer is 8 times the total SRAM on one of my favourite microcontrollers. :)

[@namr2000]

Great work as always!

[@tomekmgr]

Wow, love that defmt after what I've seen here😆

[@kv7622]

really nice level of details, thanks! I was like where did Embed.toml go when trying to follow along. Took me some time to figure out "probe-rs" runner (noob here), but all part of learning (and should have payed attention to the notes for "Embedded Rust setup explained" where probe-rs was mentioned)

[@Ariccio123]

This feels a lot like Windows ETW. Nice.

[@wall_k]

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

[@sluagh5534]

Fascinating video

[@vikaspoddar001]

He is back 🔌

[@meiramshunshalin6915]

Good video

[@meiramshunshalin6915]

Keep going, you deserve more subs

[@SteveM0732]

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.

[@googelstevejobs21]

rule of thumb: always do a release build for embedded. Debug is just too big.

[@NotherPleb]

​@@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

[@SteveM0732]

@@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.

[@quantump8877]

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.

[@therustybits]

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.

[@macho512]

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)

[@therustybits]

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...

[@b1chler]

Realy looking forward to the next one. Your channel will blow up, trust me. Can I invest somehow? 😅

[@slash.9882]

Very nice. rust seams amazing compared to c

[@prestonmlangford]

You could implement the same server side formatting trick in c.

[@slash.9882]

@@prestonmlangford yes, but it seems way simpler on rust, it’s basically baked into a container

[@Aubstract]

@@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

[@sobreinquisidor]

​@@prestonmlangford you can do it in assembly too. Still prefer rust

[@riley-arr-g]

Not when you want a good low level language and you know what you're doing and don't have time for the rust paradigm shift. Ask Linus... 😂

[@NotherPleb]

What about the tracing crate, is it used in embedded?

[@therustybits]

AFAIK tracing isn’t used in embedded/no-std systems

[@JamEngulfer]

Why does float formatting grow the binary size so much?

[@therustybits]

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.

[@MaxWeninger]

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

[@therustybits]

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.

[@carrotylemons1190]

Have you ever had any issues where messages are randomly not shown? Thanks so much for this video!

[@therustybits]

This could be caused by an undersized RTT buffer: by default, if you try to add a new message into a full RTT buffer, the new message(s) will be dropped.

[@canofpulp]

Isn't this basically like protocol buffers

[@pedromartinspersonalemail5100]

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)