Blinking an LED: Embedded Rust ecosystem explored
Вставка
- Опубліковано 23 чер 2024
- Today we find several ways to blink an LED, and explore the various layers of abstraction within the embedded Rust ecosystem.
Chapters:
0:00 Intro
0:36 Peripheral Control
3:47 Unsafe Rust
6:13 Peripheral Access Crate
8:09 Hardware Abstraction Layer
10:56 Some(Rust)
14:00 Board Support Package
17:03 The Rusty.. Kit?
References:
• Embedded Rust setup ex...
@letsgetrusty • The magic of Rust's ty...
"The Book" | doc.rust-lang.org/book/index....
Special thanks to Patreon supporters!
- David King - Наука та технологія
As a professional Embedded Firmware Engineer, I would have killed to have this guy teach me when I started out.
Do I know rust? No
Do I program embedded? No
Did I throughly enjoy the video anywas? Absolutely!
Long time Rust Embedded Working Group member and full-time Rust and Embedded Rust trainer here.
This was so good. 10/10, no notes.
Thanks!! 🙏
the best video i see so far explains layers in embbeded WITH EXAMPLES , keep the great work , the video productions is very good . expect tutorials soon .❤❤
The real strength of Rust is the awesome content crated by people like this guy.
This is essentialy a dramatization of a Rust book, one place with a comprehensive domain specific content.
I love it.
Really Impressive, I didn't have idea that Embedded Rust was on so elaborated state yet and exist support crates for different micros and also commercial boards. I was thinking that on Embedded Rust everything will be need to be did at "bare metal" level. Thanks so much for taking the time to made this videos!
Thanks Julian!
The production quality and the simple way you teach and explain things makes it such a great experience to watch and learn from your videos. This is too good 👌
This channel is a goldmine in my search for embedded content. I've been writing software for over 5 years and miss my early embedded career. I'd like to transition back and your videos are wonderful. Thank you and I look forward to future videos
Great video, and cleared up some of the acronym salad I see I out there. Please keep it up.
A very friendly, well explained intro to Rust on embedded systems. The algorithm recommended video, so took a peak with a bit curiosity, now wanting to learn more.
This is a masterful video, HIGHLY recommended if you want to start with embedded Rust.
Really great Video! I would love to see a video from you about embassy-rs and async embedded rust and where it fits into the whole embedded rust ecosystem.
Embassy/async videos coming…
Speaking of which, the embassy docs have an example that is the same idea as this video, called layer-by-layer.
Third video and 13k subs. I think you hit the motherlode. Well done. Thank you for this content, hope you can keep going!
Thanks for the vids so far, here’s to getting a lot more people into embedded!
Excellent explanation. I like the focus on why these layers of abstraction exist, and how Rust lets you traverse this whole tower of abstractions as you please.
The video is awesome : it makes embedded rust fun to learn !
You found too many ways of blinking an LED and I found a great channel to follow!
Really good video! I think you're the first one on YT exploring this space of Rust and you'll be helping a lot of people get started. Keep it up! I hope to see some tutorials on using I2C and SPI interfaces :)
Very nice video!
But waiting for the next one will be hard!
Great Introduction, I followed your guide and the setup was a piece of cake.
I would love to learn from you, how to structure a bigger embedded project.
Hopefully some with unit tests, that could also run partly on the Host system.
This is so cool!!! I just ordered my microbit. I'm sure you're busy, but hopefully you'll keep making these videos.
Don't know if you know or like it, but you're a natural great teacher. You should cover more rust topics with a real-world example. Just like the blinky light.
I guess my biggest problem with your videos is that they come out not that often. Otherwise, the best embedded tutorials so far!
This one was supposed to come out several weeks ago, but travel and sickness pushed it back... on the upside, the delay allowed me to catch a fairly major update to the `nrf-hal` crates, which if missed would have rendered the example from the HAL chapter inoperable when run under the latest version. So there is a silver-lining to being late I guess 😂
better a bit less often, and this quality maintained!
BTW, any suggestion for just learning more Rust basics...strangely, by connecting bare metal to Rust, I start to understand more... big thanks!
Maybe this is a tangent. But back in the days i developed some, lets call them exotic, i/o techniques for coping with limitations. For example using analog multiplexers to read a whole matrix keyboard with just a few pins or reading both channels of an encoder and using them as a 2bit value to index into an array to detect state changes. Without doing soma analysing it feels a bit hard to implement these with HAL or BSP.
Great video, exact the right level of detail and great pace and well scripted. Thank you
this reminds me of a Friends episode (I know) "He uh, forgets to umm… Oh-oh he always, he always umm-Oh, who am I kidding! He’s the best roommate ever! (Hugs Chandler.)" The best Embedded Rust series ever! Keep up the great work.
the into got me hooked
Great content, and great production. The music is such a vibe
Damn, these are good. Love the tone, love the rythm. Keep up the great work!
This is just phenomenal content
Finally this video pop out🎉🎉.
Fantastic video! Great job covering the process of finding the information you need and implementing an idea start to finish. This series is going to become a staple for getting started with embedded rust, and even rust alone for some!
These vids are awesome, please do continue!
I knew this one's coming after the last one 😁 Already pre-liked the video! ❤
Another video, another banger. Keep up the good work!
I can't wait for the next tutorial, the are so great!
Great video!! Thanks for sharing
great video, glad to be watching part 2
Really high quality video, great job!
Fascinating and educational, thank you!
I started studying embedded rust last saturday and did this blinky exercise. Rooting for more of your videos in the future. Great content!.
I wish I had this exact video before I started working with my microprocessors HAL a couple weeks ago, and before I tried working with my 8x8 multiplexed LED just last week. Excited for more videos!
Cristal clear. Superb teacher...Thx for this serie of videos about embeded rust. Kudos
Thank you!! Awesome stuff
Fantastic information! Thank you!
Keep up the great work!!
Another great video!
Awesome video!
Superb videos. Clear, concise, beautiful.
Thank you for another excellent video! :D
Loving your channel, great video!
Thank you very much!!!!!
amazing video!
You make great content!!
Keep it coming 🔥🔥🔥
You were born to be a teacher!! Great Video!
Fantastic!, thanks ❤
Great, This is way I'm at, looking forwards for the next video. I'm actually really eager to your videos as they will be my supporting material to try and persuade colleagues to try rust in their projects. thanks
Pro content, respect.
So good!!
Very informative videos! Thank you a lot for the effort ❤
I'm new to the embedded world so clarifications on each step are very useful. Also cool to know how to approach the same problem with a different layers of abstraction.
awesome!
Great video. I'm off to try some of these approaches on my stm32 projects😊
I don't know Rust and I don't write embedded software, but this video is amazing!
Thanks for this overview, coming from C embed it can be a bit confusing to find your bearings in the rust ecosystem. The ability to possibly write your own BSP for custom boards to properly handle complex peripherals (like IC2 screens or memory) sounds great
Gotta love this guy ❤
Man, you’re gonna get big :)
Amazing
man i love this channel
Love ur content ❤
Such a great video! Your videos are truly the best ones I've seen regarding embedded rust. The others were always skipping some steps and left a lot of ambiguity.
If you are ever searching for ideas to make a video out of: I'd love to see one that ports one little program to multiple different microcontrollers / boards to show the steps that need to be changed.
Or a video about using SPI to drive a simple peripheral - for example an 8x8 LED-Matrix. I tried the latter, but failed due to the MAX7219-crate potentially having some bugs.
Please continue to make these great, detailed videos. Tell us if you're in need of patreon subscriptions :-D
He is definitely a team leader ❤
I recommend people to take a look at Embassy. The concept in this video and the previous ones is great, but it is also very complicated. Just my 2 cents
What's "Embassy"?
11:30 this is called the TypeState pattern, by the way.
Typestate FTW! 🙌
love when you drop a new video 😂
5:25 btw, there's also a write_volatile method on pointers, so you could have written this as GPIO0_PINCNF21_ROW1_ADDR.write_volatile(PINCNF_DRIVE_LED). It saves an import and reads slightly nicer imo.
Strong Opening
Finally another video :))
I really loved this video and I hope to see more from you soon :)
One question: What is your workflow with music? Do you write it yourself or is there some nice software you use? Is it stock music that is just timed really well?
Thanks!
All the music is from Epidemic Sound, for now at least.. I think I'm burning through some of their best content at an alarming rate 😅 I try to find songs that fit the mood of the chapter or just sound cool & help carry the story forward, and try not to reuse tracks between videos. Editing is done in Final Cut Pro. We'll see how long I can continue making videos this way, but for now I'm really enjoying how they turn out 😀
Very very good breakdown of the various layers of abstraction in embedded Rust... "oxidation forms on the metal"... NICE!
My main take away from this is that the nRF52833 is quite a nice chip... sounds loads less over-complicated than the STM32s
STM32 has one of the best documentation out there. What do u mean over-complicated? Setting output pin is about setting THREE registers.
I've been starting my embedded (at least non Arduino IDE) journey with rust recently and decided to target the esp32 with std. I think in downloading the esp32 crates and reading through the basic tutorials to get it compiled I missed some of the underlining info this video had.
Hey, I really love your videos! Thanks for the videos! I wanted to ask if you could at some point also cover embedded Linux with rust?
Possibly! Must admit that is not my wheelhouse: running on embedded Linux is probably going to more closely resemble a Rust program developed for your host machine (using `std`) than something that is highly resource-constrained like an MCU (using `no-std`). Would be interesting to investigate eventually though...
what are you using to edit your videos? great work not only on the embedded side but also on the editing wow
Thanks! Currently using Final Cut Pro for video editing.
Curious what the name of the book is on the table in the background haha
Slowly making my way through “The Linux Programming Interface”…
lets do Zig next
Could you please explain how can I change the state of an output pin from 2 different places in the code? Since it takes ownership of it
For a system that isn't running other tasks (or trying to drive the output pin via interrupt), you could pass a mutable reference to the pin to a function, which could then set its output.
Something like:
`fn set_output(pin: &mut impl OutputPin, is_on: bool) { pin.set_state(PinState::from(is_on)).unwrap();
}`
Then to call it:
`set_output(&mut row1, is_on);`
After seeing this, I am curious about the government's desire to move from C to Rust. I think it is well intentioned but knowing how underfunded/underallocated those jobs can be, I think there will be a lot of defaulting to unsafe rust when things get difficult (where the benefits of rust would be most needed).
Hoping that I can do my small part in providing useful/engaging educational content regarding how to do Rust "the right way"
@@therustybits I think the video does a great job of that! My comment was more directed at people who think rust will be a magic fix for memory issues. It only works if people are willing to pay and wait for developers with the ability to achieve what you are showing.
May be a question showing my ignorance with Rust and Microcontrollers but, if we have 1 pin for 25 leds, is it still possible to light them all at the same time? Not just to the naked eye, but in real time as well?
Generally speaking, if you want to independently control N LEDs, you’ll need N pins to control them, assuming you’re not using dedicated external hardware that is effectively doing this for you. In the case of the microbit, we only light up one row or 5 LEDs at a time, though we do use all 10 pins to do this: the row pin we are interested in is high (the others must be all low), then each column pin is either high (no voltage difference across LED, is off) or low (voltage difference across LED, is on).
If you just want to light up all N LEDs at the same time and don’t need to individually control them, you can wire all their cathodes to ground (through resistors) and all their anodes to one pin, assuming it can handle the current requirements without dropping too much voltage. ⚡️🚨
I have a question about the unsafe rust version.
Why did you write 1
Something I didn't mention (but probably should have) is that all of the pins default at reset to inputs, with a disconnected input buffer: they are basically floating, neither high nor low. In order for current to flow through the LED, it needs to see a high voltage on its anode side (row 1) and a low voltage on its cathode side (column 1). So we need to set both pins 21 and 28 as outputs. Only setting row 1 as an output and driving it high (3.3V) is not enough, as the circuit is left open without also grounding column 1 (0V). Hope that made sense!
@@therustybits I see so you set 28 to an output with setting 0x770 to 1 to avoid it being an input. So all in all both pins need to be outputs but we only toggle 21 high/low.
Yep! The line where we toggle the state of row 1/pin 21 is also setting all the other output pins low (0), which in this example is just column 1/pin 28.
@@therustybits Thanks for clearing things up! Keep up the great content btw!
Nice video thank you sir , I'm an embedded systems engineering student , I work with C it's straightforward for me , I didn't work with Rust before ...
I don't work with HALs , I do the work from register level , am I just wasting my time ?
No, you would be wasting time learning Rust. Don't worry.
Nice! Nothing wrong with working with registers directly (in C or Rust); the HAL is just a way to work at a higher level of abstraction. Becoming proficient in C is a great way to learn low-level systems... but eventually you may find yourself wanting some of the things Rust has to offer (memory-safety, stronger type system, modern tooling, etc).
Bonus exercise for the class: make the “I ❤ Rust” message *scroll*! 😂🤓
I feel like I'm getting a little bit clever with every video.
First
You make it look too simple
Try to abstract different pins on different boards (and MCUs). Since everything is a struct field, you can't use type aliases. You are left with horrible macros hand writing them. It does satisfy borrow checker, however reality brutally proves this approach horrible.
What would your alternate approach be?
@@haydenridd Type aliases. for example.
If safety is the main reason to use Rust instead of C, and you have to disable Rust's safety checks even for a program as basic as toggling an LED then why not just use C for embedded software and leave Rust for user space applications and embedded linux?
The unsafe keyword does not mean that you are doing something bad. It just means that you are leaving the safe path of software development defined by Rust and now have to make sure yourself that the specific part of the Code in the unsafe block does not contain any security gaps and does exactly what it is supposed to do.
While in C you always have to make sure that you write safe code, in Rust you only have to do so in the unsafe block. That doesn't mean it's a bad thing. At that moment, Rust gives you full control and responsibility over your implementation.
Because what is “unsafe” today can be made safe tomorrow - for instance by implementing the equivalent of placement new for system memory on this embedded system, after which you can reference the memory address. Unsafe allows you to scope the exception areas of evolving risk, as @PietPanzer said, but also remove it and increase safety guarantees with time.
And that’s pretty much exactly what the PAC does here.
Unsafe doesn't disable the safety checks, just like the existence of void doesn't disable C's type system. The idea is to create isolated units of unsafety via the unsafe keyword, keeping the rest of your project safe. This is a massive win for safety and performance, since you can create high performance code without any barriers when you need it, and safely abstract it to allow the rest of your team to consume your work without needing to first read all the documentation you probably haven't written yet.
Also, I don't think safety actually is the main reason to use Rust. Memory safety allows library authors to create far more complex libraries whilst knowing that they (and other libraries) aren't interfering with each other inadvertently. Rust has some of the best libraries in the world already, and it's only a decade old. Comparing Serde to any other alternative from any other language is a joke.
Thank you for your replies. Does anything stop C developers from doing the same thing? Like mark certain parts of their code as "unsafe" using comments, for example , and come back to it later and "make it safe"? Or does unsafe do way more than just marking a part of the source code?
@@armincal9834 It's more than a marker, it also unlocks functionality. You are unable to dereference a raw pointer in safe Rust, it's a compiler error. The only way to dereference a raw pointer is inside an unsafe block. This means that in normal code, you know nobody is working with raw pointers.
Why is this so much more complicated and so hard to read? I don't see why would anyone choose Rust over C/C++ and CMSIS/HAL. All I can hear is memory safety gibberish from Rust fanboys, but I never had any issues while coding embedded.