Make sure you’re putting -release on your production builds for optimization,no debug info. I’m sure you know but it could be a good thing to show for anyone watching who hasn’t read the cargo book.
If you configure it right, with lto=true, strip=true, opt-level='z', and panic='abort' (this one is necessary anyways), you should be able to get your ELF to be about 4KB. And what's going to be flashed on your Uno is very less anyways so doesn't matter (a simple loop {} is like some 100 bytes)
Awesome video. Seems that there is just a lot of hacks to be able to get started using Rust on embedded. Hopefully it gets more straightforward as time goes by.
I generally agree with this comment. There’s just not as much polish here as there is with other areas of rust. None of the knowledge is all in one place. That’s why I’m so excited for LLL (or L3?) to take on this topic. He’s clearly a bright guy good at explaining things, including the dusty corners.
I'm already glad it's this much clearer. While doing the Rust embedded book in 2019, there was a lot more things to get a hold of. Like for instance the STM32F303 board. Now I can just grab an Uno or Nano that I have lying around and actually use. The source code has also gotten a lot more compact.
The Knurling Project is actually pretty hot. It kind of gives you "compile", "flash", "debug", "forward log/output" and other things out of the box. It still does require an understanding of how embedded rust works in general, of course.
I expermiented this myself a few days ago and i found that there isn't enough tutorial / example online for a still beginner in rust to create programm other than blink More video on advanced concept on this would be awesome (Serial, ...)
Arduino is just a a collection of libraries and a simple IDE, like a sandbox for beginners. Of course Arduino didn't make AVR, they're just using the old chip on their branded PCBs
Pretty cool. I am looking to get into the embedded automotive space. I have been looking at C, Ada/Spark and Rust. C and Ada are both very mature and well used in the embedded space. But I do see the potential in Rust. I appreciate your videos, thanks!
I don't know much about Rust, but isn't one big advantage that Rust will not have Runtime Errors. All errors are handled by the compiler. Leaves only errors in logic. But in embedded that seems like a big advantage to me, because runtime errors are hard to track afterwards.
@@AlbatrossCommandoI was just echoing what I heard in previous video on Rust. Stating that one of the advantages of Rust compared to C(++) would be that it would be nearly impossible to write code that would give a runtime error. How this would be achieved, I don’t know. If you say there is a panic handler, then obviously it’s eiter a useless thing, or it’s there to handle runtime errors. I guess you might just be right. Maybe if there comes a time that I will learn Rust, I will find out. For now I’m to busy writing c# and typescript professionally and doing some c(++) for hobby
I wanted to add a note that people don't HAVE to type "rustup override set nightly-2021-01-07" in order to have the code built. The good part about it is that you sure as heck need to have a nightly toolchain, but everything after nightly-2021-01-07 would work, so you could've just ran "rustup override set nightly" which would've instead installed the latest nightly build available and overrided the project with it. Other than that, amazing content
I appreciate the video. I just started learning Rust after hearing so much praise. I got my X86 dev environment up and running without any effort. But I must say I was surprised after running into so many "gotchas" trying to get code onto just an Arduino. By comparison getting golang code to run on all my microcontrollers was much more seamless. I think i'll have to wait until things advance before using Rust for my embedded projects. Good content as always.
It does in fact not really run on everything. Yet. The platforms that you can target with the default rustc are limited to at most these supported by LLVM, and many device manufacturers don't provide a LLVM backend. But there's hope that 1) device manufacturers getting better about llvm support and 2) rust is getting a compiler with gcc backend / a gcc frontend, which is in fact getting worked on right now. Other than this yeah, Rust has very much the capability of running on pretty much everything. All that's lacking is tooling at times. Because of the work for the Linux kernel we're even getting fallible allocation APIs, which make using the alloc crate (Box, Vector, Hashmap etc) on top of just core (Result, Option etc) a possibility for many embedded devices.
Thanks, great video ! :D Much waiting for more in depth dives into embedded programming with rust ;) few comments in compact form for people still on this 2y later : 1) As previous people have remarked, newer version of nightly also work to compile 2) it seems that besides gcc-avr, one also needs avr-libc, that can installed via apt install avr-libc 3) using the current version of the json file in Rahix/avr-hal and building the project using cargo build --release 4) if one goes with the current version of the github repo, it should not be forgotten to update to : rev = "15080aa" (at the time of this comment)
Was neat to have a peek at the avr-hal. Looks like there is some support for the Adfruit Trinket. Will be interesting to see what can fit on that tiny package.
If you're on Windows and have Arduino already installed, then you already have avr-gcc and avrdude. Just add it to your PATH. It's usually in C:\Program Files (x86)\Arduino\hardware\tools\avr\bin
This reminds me of how we used th threaded list language FORTH to write code for custom military hardware. The ability to construct an arbitrary software architecture for a hardware level architecture and run FORTRAN on top of that was a powerful tool back in the 1980s.
Wow! The video is excellent! The whole toolchain to make Arduino programs feels like a nightmare... Once it is all figured out, I can imagine why Rust would be very interesting and productive to use, but, really, I would only use it if there was an IDE that would concentrate and automate the whole thing for me. Arduino IDE will still rule for a while :)
And for sake of completeness the time it takes to actually write the code as far as programmer time. Because I think you’ll find you will get fairly close to rust for an order of magnitude less time writing it.
I think benchmarking battery or memory consumption would be a more fitting benchmark. You're rarely ever going to need performance on these chips, if you're driving them to the limit and not currently revising a cheaper version of a well sold device you're probably doing it wrong - and at that point you can afford to rewrite it in assembly or whatever if you need it. Most of the time at worst you send updates a little slower, who cares. Meanwhile running out of memory is a real issue, and if you're trying to run devices on battery, or generally around the clock, energy consumption is very relevant.
@@9SMTM6 I think performance should work as a good proxy for battery usage. Generally speaking, if your code isn't running, the processor can idle/sleep/standby/etc. So that would be a major power savings. Your memory usage comment is 100% accurate. That is the real killer on embedded.
@@brendanhansknecht4650 probably not the worst, but also not necessarily a perfect indicator, especially with multicore - like the RPi Zero 2 has. But also memory usage tends to influence energy consumption, and unfortunately often not in a linear fashion. Also thinking about it, I think it's easier to measure, well not necessarily battery life, but energy usage correctly and in a realistic environment. For speed though it's harder to measure and might push one to unrealistic scenarios to measure a difference at all.
Yeah, a very important thing you forgot to mention is --release for a release binary, idk how many takes you did so it's fine but having a pinned comment would be nice.
¡Qué buen video introductorio acerca del uso de RUST con AVR/Arduino! Aprovecho para preguntar si has experimentado también con RUST en la plataforma de STM32. Gracias
In this video, you flashed the AVR. . . did you overwrite the bootloader? did you specify the main() to be put in a section that did not clobber the bootloader?
you should mention something about changing the build options. Especially since you dont have a debugger on the AVR, using vanilla debug yields no benefit except the increased binary size. That's also true for arm &riscv , enabling lto & friends, even for debug builds, makes the code much much smaller.
The git commit sha you wrote was wrong. Instead of 450c, you wrote 540c. I enjoyed your tutorial. I finished it. How should we prepare the arduino board?
Unless I missunderstand that amount of data written, that's insane for such a small function. 5,8KiB for a blinking LED, it's about 800B with Arduinos "C++ thingy" and 300B in C. It's fine on Raspberries and other higher level of embedded systems but not an Atmega 328 or a PIC etc. I get the point of this video that this language can be compiled for enything and it's great in that sense. Keep up the good work.
Hey bro, love your new Rust videos! Please note that you can make your life way easier if you start using vscode with the Rust plugins. The zooming for recording is also better, since the filetree zooms as well. Keep it up, most of us are new to Rust so what you're doing is great :D Can you maybe explain a bit about the whole memory stack/heap part for embedded?
Just a question about the upload process, at the end it says “5792 bytes of flash verified”, does that mean that that is the total size of the program, because you said the size was 600k before, is that 600k just the elf file and the 5792 bytes the actual size used on the arduino?
After a bit of cussing and carrying on(didn't know about 'profile.release' and 'profile.dev') I finally got it to work. Love your videos man, keep it up!
Great video. I didn't know that Rust for Arduino Uno existed. Unfortunately I couldn't recreate what you built in this video. I gets stuck with: "error: language item required, but not found: `eh_personality`" When I do the cargo build at 08:22. Fortunately the examples by Rahix do compile and upload. Thanks for pointing out this is possible! Keep up the good work.
For anyone wondering I have solved the error 'eh_personality'.. You need to put these lines in your cargo.toml: [profile.dev] panic = "abort" [profile.release] panic = "abort"
Out of curiosity: A friend of mine is interested in Rust and also has a lot to do with embedded devices, but he hesitates to use Rust there, because he thinks fo his taste there is still way too much C in it. My question would be how it is changing with time or if his argument is already depricated. Love your videos by the way!
I'm not exactly an expert on embedded, but this sounds very wrong to me. I've admittedly only coded in one "higher-level" language for controllers, that being Micropython, but that one was already showing me the limits. You barely ever have any bindings for compatible libraries (which you need to drive sensors or even networking), and I ran out of memory fast. Python pushes you to a model that is resource intensive. Of you can't find a fitting library with binding for your device you need to use a C library. Rust can do that just fine and easily, Python, and I'm certain most other comparable languages, make that painful. As I said I've got limited experience, but from what I've seen, Rust as a basic language is PERFECT for embedded. Because of no GC or pervasive reference counting it has basically the same memory footprint as C, which is good on memory starved embedded devices (memory costs energy and money... Disproportionately much on embedded). Rust doesnt use exceptions, like C++, but an explicit error model, which can actually run without a heap, and which also means far less debugging, because it's explicit and thus always well documented and easy to spot. Rust has an ecosystem of packages on crates.io that run on "no_std" environments, which is pretty much a necessity on embedded. And because if it's expressive type system libraries have much less gotchas than your typical C library. Even your typical device manufacturer will have a hard time to code a difficult to use Iibrary:).
Thanks for walking through this. I tried doing this very thing probably about a year ago now. With much struggle, I never really got 100% of the way there. I didn't have time to pick it back up since then. Do you, by any chance, have any notes that you could post about how you got your dev environment setup (tools installed, etc)? I never satisfactorily got through all of the "hacks" needed for the Rust toolchain.
Could you strip out the unused parts of the final ELF file here as well?? 600kb is not lightweight for a AVR to be honest. Big reasons I love your Assembler stuff is mainly the final output of it is so damn slimmed down i could just cram extra stuff onto the Pico that the C compiler wouldn't cuz of extra libs it just pulls into support the build.
Luckily the whole ELF doesn’t get flashed to the board. Most of that 600Kb is ELF header and debug symbols. AVRDUDE rips out only programmable pages from the ELF and puts them on the AVR.
But what is the memory use like? since on a microcontroller every byte counts. A binary that is 600KB is a lot of memory for such a small amount of code, so if that has to also be used in memory too. This is way too expensive.
Is there a significant performance enhancement by programming directly on the metal instead of on top of Linux or Windows? Can I write a web server that interfaces with PostgreSQL without having an operating system installed?
Awesome video, struggled with getting rust cross compiling for embedded, too. I don't quite get why we need the gcc-avr Toolchain, isn't rust based on llvm? Or is it used for linking only?
Help!!!! Trying this on my pc and it just won't compile and I don't even get how to go about debugging it Please create an updated video with latest version of rust. The things on this video does not work anymore. Please!!!!
I tried to run Rust on my vacuum cleaner, but it didn't work. Perhaps because it's a Microsoft vacuum cleaner: the only product they made that doesn't suck?
This is great and all, and don't get me wrong, this is a really impressive proof of concept project. But isn't the code like... bloated to the Extreme? For me, an embedded project is a challenge, because you have to keep complexity in mind, speed, and yes, code size. Yes, you COULD use a bigger micro, but you also could slap a RPI on and call it a day. What's the challenge in that? Again, this is a great video, and straight to the point tutorial, I just don't see the practicality of it (yet)!
I loath the let keyword! Always have in TCL and some Basics. And man, this is fucking involved for such a trivial little thing. It's code is even smaller in bloody assembler! I'd write something this trivial in Assembler with a nice little XOR on the port to toggle it. :D 6K is btw smaller than the 10M you said a runttime would take (as someone in the comments last week also told me). But 600K to toggle a single bit is utterly unacceptable!
Nearly 6000 bytes where the Arduino uses around 1000. Seems a tad on the big side to me . Assemnly can do it in 28 bytes! ;-) Still, an interesting series so far, thanks. Cheers, Norm.
@@NormanNodDunbar as far as I’m aware there’s no pin operation in avr assembly. There’s just an out opcode that takes a port and a value. Even the sbi and cbi operate on a whole port. It wouldn’t be very RISC if there was either :) Or am I missing something?
This is absolutely too much effort for something I can do in Arduino c Like why to bother even arduino api is making it too easy that rusting it Is going to be useless
I think that rust is a bit problematic on embedded cus because when initializing a rust runtime executable a lot of memory allocated compared to a c rtex. An in-depth analysis of the memory allocations performed can be found under the topic "Investigating Memory Allocations in Rust" by ysantos
Is Rust bloated and slow compared to embedded c? As someone who exclusively uses c for real time embedded applications I am very partial to C compared to anything else, this may just be internal bias but if I see any type of intelligence or memory safety I immediately assume it is going to be slow code.
Rust can be just as fast as c if not faster. Basically its around the same speed depending on application and implementation. Most of rusts checks happen at compile time.
The runtime performance is same as C or C++. Very often the same exact machine instructions. Memory safety comes from what the compiler refuses to build, not from additional runtime checks.
This looks cool, but a HAL for an AVR? All this seems like an overly complicated way of avoiding reading the datasheet. Over 4k of flash to twiddle an output- if you put this into a product, you'd be throwing away money for having to use an AVR with more flash.
The only problem is that he ran a debug build. A release build is only 324 bytes. That is much smaller than Arduino. It is still larger than the ~200 bytes for raw C, but that is due to the hall doing a little bit of extra initialization that you would probably end up adding to the C anyway.
Literally anything compiles to anything with the right tools. What you're saying is that rust compiled to c, which like all c programs, can be compiled to assembly. I would hardly call this bare metal rust.
![[#2024MAMA] BIGBANG (빅뱅) - 뱅뱅뱅 (BANG BANG BANG) + FANTASTIC BABY | Mnet 241123 방송](http://i.ytimg.com/vi/EQsYfiPR9uM/mqdefault.jpg)
How did you say 92d540c wrong twice but type it correctly
I just watched this and spat out my coffee XD I have no idea.
Muscle memory
@@nodge9671 Not a real thing
Blew my fkn mind
@@milespiano ??? XD
Make sure you’re putting -release on your production builds for optimization,no debug info. I’m sure you know but it could be a good thing to show for anyone watching who hasn’t read the cargo book.
Also binary size. For microcontrollers, flash space is critical.
@@cerulity32k yeah he even mentioned that he said "600k wow pretty big" yeah cause it's got all the debug hooks lmao
If you configure it right, with lto=true, strip=true, opt-level='z', and panic='abort' (this one is necessary anyways), you should be able to get your ELF to be about 4KB. And what's going to be flashed on your Uno is very less anyways so doesn't matter (a simple loop {} is like some 100 bytes)
FYI, an easier way to flash the code onto your board is ravedude. It does most of the magic for you, including detecting the post and such
Good to know, thank you!
Awesome video. Seems that there is just a lot of hacks to be able to get started using Rust on embedded. Hopefully it gets more straightforward as time goes by.
Yeah I found the project setup pretty clumsy. Luckily Rahix has a template you all can use for your projects.
I generally agree with this comment. There’s just not as much polish here as there is with other areas of rust. None of the knowledge is all in one place. That’s why I’m so excited for LLL (or L3?) to take on this topic. He’s clearly a bright guy good at explaining things, including the dusty corners.
I'm already glad it's this much clearer. While doing the Rust embedded book in 2019, there was a lot more things to get a hold of. Like for instance the STM32F303 board. Now I can just grab an Uno or Nano that I have lying around and actually use.
The source code has also gotten a lot more compact.
The Knurling Project is actually pretty hot. It kind of gives you "compile", "flash", "debug", "forward log/output" and other things out of the box. It still does require an understanding of how embedded rust works in general, of course.
I expermiented this myself a few days ago and i found that there isn't enough tutorial / example online for a still beginner in rust to create programm other than blink
More video on advanced concept on this would be awesome (Serial, ...)
Please note: Arduino is not AVR! Yes, most Arduino use AVR controllers, but also ARM. AVR controllers are also used outside the Arduino world.
Just wondered how Rust would work on AVR (As the CPU is not into the LLVM of the Rust compiler) only ARM-Cortex etc is.
@@HermanWillems Rust works on AVR, but as far as I know it uses some parts from the AVR GCC toolchain. At least the linker
Arduino is just a a collection of libraries and a simple IDE, like a sandbox for beginners. Of course Arduino didn't make AVR, they're just using the old chip on their branded PCBs
Pretty cool. I am looking to get into the embedded automotive space. I have been looking at C, Ada/Spark and Rust. C and Ada are both very mature and well used in the embedded space. But I do see the potential in Rust. I appreciate your videos, thanks!
I don't know much about Rust, but isn't one big advantage that Rust will not have Runtime Errors. All errors are handled by the compiler. Leaves only errors in logic. But in embedded that seems like a big advantage to me, because runtime errors are hard to track afterwards.
C is your best choice.
@@erikjvanderveen That is just factually incorrect mate what do you think the panic handler is for?
@@AlbatrossCommandoI was just echoing what I heard in previous video on Rust. Stating that one of the advantages of Rust compared to C(++) would be that it would be nearly impossible to write code that would give a runtime error. How this would be achieved, I don’t know. If you say there is a panic handler, then obviously it’s eiter a useless thing, or it’s there to handle runtime errors. I guess you might just be right. Maybe if there comes a time that I will learn Rust, I will find out. For now I’m to busy writing c# and typescript professionally and doing some c(++) for hobby
@@erikjvanderveenDiv by zero? Just to name one very obviously possible one.
I wanted to add a note that people don't HAVE to type "rustup override set nightly-2021-01-07" in order to have the code built. The good part about it is that you sure as heck need to have a nightly toolchain, but everything after nightly-2021-01-07 would work, so you could've just ran "rustup override set nightly" which would've instead installed the latest nightly build available and overrided the project with it. Other than that, amazing content
Thank you, this was my main question watching the video in 2023 :)
The content is soooo original! All your videos are great! Thank you and keep doing what you're doing 🙏🏻 This channel will grow FAST 🔥
I appreciate the video. I just started learning Rust after hearing so much praise. I got my X86 dev environment up and running without any effort. But I must say I was surprised after running into so many "gotchas" trying to get code onto just an Arduino. By comparison getting golang code to run on all my microcontrollers was much more seamless. I think i'll have to wait until things advance before using Rust for my embedded projects. Good content as always.
It does in fact not really run on everything. Yet.
The platforms that you can target with the default rustc are limited to at most these supported by LLVM, and many device manufacturers don't provide a LLVM backend.
But there's hope that 1) device manufacturers getting better about llvm support and 2) rust is getting a compiler with gcc backend / a gcc frontend, which is in fact getting worked on right now.
Other than this yeah, Rust has very much the capability of running on pretty much everything. All that's lacking is tooling at times. Because of the work for the Linux kernel we're even getting fallible allocation APIs, which make using the alloc crate (Box, Vector, Hashmap etc) on top of just core (Result, Option etc) a possibility for many embedded devices.
I agree. The title really confused me. Rust isn't a supported target on all the platforms we use at my job.
Thanks, great video ! :D
Much waiting for more in depth dives into embedded programming with rust ;)
few comments in compact form for people still on this 2y later :
1) As previous people have remarked, newer version of nightly also work to compile
2) it seems that besides gcc-avr, one also needs avr-libc, that can installed via
apt install avr-libc
3) using the current version of the json file in Rahix/avr-hal and building the project using
cargo build --release
4) if one goes with the current version of the github repo, it should not be forgotten to update to :
rev = "15080aa" (at the time of this comment)
Recently discovered your channel and just loved it!
Glad you enjoy it!
can you handle interruptions with Rust? Because thinking in something "more complex" than blinking a led, I'd rather use an interruption
Was neat to have a peek at the avr-hal. Looks like there is some support for the Adfruit Trinket. Will be interesting to see what can fit on that tiny package.
Such a small channel with an awesome content. Wish you lots of success
Thanks a ton!
If you're on Windows and have Arduino already installed, then you already have avr-gcc and avrdude. Just add it to your PATH. It's usually in C:\Program Files (x86)\Arduino\hardware\tools\avr\bin
The out/debug will have a compiled binary but without --release it will be significantly bigger
I have no experience with Rust nor Arduino but the way you explain things is absolutely comprehensible!
This reminds me of how we used th threaded list language FORTH to write code for custom military hardware. The ability to construct an arbitrary software architecture for a hardware level architecture and run FORTRAN on top of that was a powerful tool back in the 1980s.
Wow! The video is excellent! The whole toolchain to make Arduino programs feels like a nightmare... Once it is all figured out, I can imagine why Rust would be very interesting and productive to use, but, really, I would only use it if there was an IDE that would concentrate and automate the whole thing for me. Arduino IDE will still rule for a while :)
A topic of suggestion would be speed of execution(RUST vs C vs ASM) in the embedded controllers for the rust series.
And for sake of completeness the time it takes to actually write the code as far as programmer time. Because I think you’ll find you will get fairly close to rust for an order of magnitude less time writing it.
I think benchmarking battery or memory consumption would be a more fitting benchmark.
You're rarely ever going to need performance on these chips, if you're driving them to the limit and not currently revising a cheaper version of a well sold device you're probably doing it wrong - and at that point you can afford to rewrite it in assembly or whatever if you need it. Most of the time at worst you send updates a little slower, who cares.
Meanwhile running out of memory is a real issue, and if you're trying to run devices on battery, or generally around the clock, energy consumption is very relevant.
@@9SMTM6 I think performance should work as a good proxy for battery usage. Generally speaking, if your code isn't running, the processor can idle/sleep/standby/etc. So that would be a major power savings.
Your memory usage comment is 100% accurate. That is the real killer on embedded.
@@brendanhansknecht4650 probably not the worst, but also not necessarily a perfect indicator, especially with multicore - like the RPi Zero 2 has. But also memory usage tends to influence energy consumption, and unfortunately often not in a linear fashion.
Also thinking about it, I think it's easier to measure, well not necessarily battery life, but energy usage correctly and in a realistic environment. For speed though it's harder to measure and might push one to unrealistic scenarios to measure a difference at all.
@@brendanhansknecht4650 lol try to compare the performance and current for AVR and a simple cortex M0 and you'll have a bad time
If the binary is 100kb how does it fit on the 32kb flash? Love your content btw!!!
Yeah, a very important thing you forgot to mention is --release for a release binary, idk how many takes you did so it's fine but having a pinned comment would be nice.
¡Qué buen video introductorio acerca del uso de RUST con AVR/Arduino!
Aprovecho para preguntar si has experimentado también con RUST en la plataforma de STM32. Gracias
In this video, you flashed the AVR. . . did you overwrite the bootloader? did you specify the main() to be put in a section that did not clobber the bootloader?
Yup! When you use the Arduino bootloader instead of the ICSP, it doesn’t touch the bootloader section.
Love your channel! The Rust Age is coming
Hello, next could you make a tutorial for screen display or using sensors ?
Great video. Ever consider a video for the STM32F411 BlackPill? I like it because it has floating point hardware and is pretty cheap too.
Nice and informative video, although I had a hard time reading the dark magenta text against the equally dark background
Good project must try i am learning rust these days
Curious, why did you add the panic-halt dependency (which adds a panic handler), but then implement your own panic handler?
Thanks! After I watched this video, I managed to get rust to run on my iPhone.
you should mention something about changing the build options. Especially since you dont have a debugger on the AVR, using vanilla debug yields no benefit except the increased binary size. That's also true for arm &riscv , enabling lto & friends, even for debug builds, makes the code much much smaller.
and also that using [no_std] means you cannot use 90% of the libraries you may be used to.
I recall it's possible to setup "cargo run" to automatically push the code to the board :)
Can you please share pointers on how to?
I'm guessing you'd add something to the toml file?
Thank for the video.
It really helps me a lot.
Thanks, the video was awesome!!
Do you think I could use Rust for more complex project or a better choise is use C/C++ ?
The git commit sha you wrote was wrong. Instead of 450c, you wrote 540c.
I enjoyed your tutorial. I finished it. How should we prepare the arduino board?
Great Stuff!
Thanks!
Unless I missunderstand that amount of data written, that's insane for such a small function.
5,8KiB for a blinking LED, it's about 800B with Arduinos "C++ thingy" and 300B in C.
It's fine on Raspberries and other higher level of embedded systems but not an Atmega 328 or a PIC etc.
I get the point of this video that this language can be compiled for enything and it's great in that sense.
Keep up the good work.
To clear up your confusion 4 months later, it's just that this youtuber forgot to create a release build and to strip the binary.
Great video!
Hey bro, love your new Rust videos! Please note that you can make your life way easier if you start using vscode with the Rust plugins. The zooming for recording is also better, since the filetree zooms as well. Keep it up, most of us are new to Rust so what you're doing is great :D Can you maybe explain a bit about the whole memory stack/heap part for embedded?
Very interesting. Nice upload speed to the board!
Could you put all your Arduino stuff in one playlist?
Just a question about the upload process, at the end it says “5792 bytes of flash verified”, does that mean that that is the total size of the program, because you said the size was 600k before, is that 600k just the elf file and the 5792 bytes the actual size used on the arduino?
Exactly! AVRDUDE isn't taking the whole ELF and stuffing it in there, only the necessary program memory.
glad i found your channel
After dealing with c++ arduino code now i understand why rust is so loved
After a bit of cussing and carrying on(didn't know about 'profile.release' and 'profile.dev') I finally got it to work. Love your videos man, keep it up!
Great video. I didn't know that Rust for Arduino Uno existed.
Unfortunately I couldn't recreate what you built in this video. I gets stuck with:
"error: language item required, but not found: `eh_personality`"
When I do the cargo build at 08:22. Fortunately the examples by Rahix do compile and upload.
Thanks for pointing out this is possible! Keep up the good work.
I have the same problem.. Can you compile your project now?
For anyone wondering I have solved the error 'eh_personality'.. You need to put these lines in your cargo.toml:
[profile.dev]
panic = "abort"
[profile.release]
panic = "abort"
Out of curiosity: A friend of mine is interested in Rust and also has a lot to do with embedded devices, but he hesitates to use Rust there, because he thinks fo his taste there is still way too much C in it. My question would be how it is changing with time or if his argument is already depricated. Love your videos by the way!
I'm not exactly an expert on embedded, but this sounds very wrong to me.
I've admittedly only coded in one "higher-level" language for controllers, that being Micropython, but that one was already showing me the limits.
You barely ever have any bindings for compatible libraries (which you need to drive sensors or even networking), and I ran out of memory fast. Python pushes you to a model that is resource intensive.
Of you can't find a fitting library with binding for your device you need to use a C library. Rust can do that just fine and easily, Python, and I'm certain most other comparable languages, make that painful.
As I said I've got limited experience, but from what I've seen, Rust as a basic language is PERFECT for embedded. Because of no GC or pervasive reference counting it has basically the same memory footprint as C, which is good on memory starved embedded devices (memory costs energy and money... Disproportionately much on embedded). Rust doesnt use exceptions, like C++, but an explicit error model, which can actually run without a heap, and which also means far less debugging, because it's explicit and thus always well documented and easy to spot.
Rust has an ecosystem of packages on crates.io that run on "no_std" environments, which is pretty much a necessity on embedded.
And because if it's expressive type system libraries have much less gotchas than your typical C library. Even your typical device manufacturer will have a hard time to code a difficult to use Iibrary:).
Thanks for walking through this. I tried doing this very thing probably about a year ago now. With much struggle, I never really got 100% of the way there. I didn't have time to pick it back up since then. Do you, by any chance, have any notes that you could post about how you got your dev environment setup (tools installed, etc)? I never satisfactorily got through all of the "hacks" needed for the Rust toolchain.
I guess he has beefed up his readme since I played with it last.
Rust Is Winning Me Day by Day.
Would love to learn next how objects in OOP languages like C++ and Ruby are represented in memory.
What? How is that even relevant?
Could you strip out the unused parts of the final ELF file here as well?? 600kb is not lightweight for a AVR to be honest. Big reasons I love your Assembler stuff is mainly the final output of it is so damn slimmed down i could just cram extra stuff onto the Pico that the C compiler wouldn't cuz of extra libs it just pulls into support the build.
Luckily the whole ELF doesn’t get flashed to the board. Most of that 600Kb is ELF header and debug symbols. AVRDUDE rips out only programmable pages from the ELF and puts them on the AVR.
Love the videos!
But what is the memory use like? since on a microcontroller every byte counts. A binary that is 600KB is a lot of memory for such a small amount of code, so if that has to also be used in memory too. This is way too expensive.
Is there a significant performance enhancement by programming directly on the metal instead of on top of Linux or Windows?
Can I write a web server that interfaces with PostgreSQL without having an operating system installed?
Is there any reason you didn't do a release build with `cargo build --release`?
Not really, I didn't go into the release vs debug for the sake of this video. Wouldn't hurt to do a release!
I do wonder what size the binary would be stripped.
@@Dygear it's 324 bytes for me when building in release. So very reasonable size.
@@brendanhansknecht4650 Wow! That really good!
That was a fun ride
Can you show us how to run rust on PIC microcontrollers?
suggestion: use stm32 as they are supported in mainline rust
perfect video
You offer rust or C++ as options for someone interested in learning embedded system programming ?
So... what's in the other 613.12 kb of the elf? Is it all just debug info?
Now with inline assembly update we will be able to seamlessly adapt rust to a greater variety of embedded devices.
Can confirm, even my grandma's old shed has some rust running in the corner
where does this json come from? magic....
Awesome video, struggled with getting rust cross compiling for embedded, too.
I don't quite get why we need the gcc-avr Toolchain, isn't rust based on llvm? Or is it used for linking only?
Who needs a HAL when you can go bare balls to the metal
walls
Help!!!! Trying this on my pc and it just won't compile and I don't even get how to go about debugging it Please create an updated video with latest version of rust. The things on this video does not work anymore. Please!!!!
I tried to run Rust on my vacuum cleaner, but it didn't work. Perhaps because it's a Microsoft vacuum cleaner: the only product they made that doesn't suck?
This is great and all, and don't get me wrong, this is a really impressive proof of concept project. But isn't the code like... bloated to the Extreme? For me, an embedded project is a challenge, because you have to keep complexity in mind, speed, and yes, code size. Yes, you COULD use a bigger micro, but you also could slap a RPI on and call it a day. What's the challenge in that?
Again, this is a great video, and straight to the point tutorial, I just don't see the practicality of it (yet)!
It's now crab rave for rustaceans
Cool video, but i can't compile for some reason it gives me language item required, but not found: `eh_personality` error
Please, do all of us a favor and set that sublime text border to dark
Nice video btw
Is there any way to do this on windows? Any ide or smthn?
Thanks
I loath the let keyword! Always have in TCL and some Basics.
And man, this is fucking involved for such a trivial little thing. It's code is even smaller in bloody assembler!
I'd write something this trivial in Assembler with a nice little XOR on the port to toggle it. :D
6K is btw smaller than the 10M you said a runttime would take (as someone in the comments last week also told me). But 600K to toggle a single bit is utterly unacceptable!
LOL! Yeah, it was pretty clumsy to get the cargo set up. I highly suggest using the template crate in the description.
@@LowLevelTV I highly suggest to use C or Assembler in this case :D
Nearly 6000 bytes where the Arduino uses around 1000. Seems a tad on the big side to me . Assemnly can do it in 28 bytes! ;-)
Still, an interesting series so far, thanks.
Cheers,
Norm.
No need to XOR. Just write to the PINx register instead of the PORTx register and it will toggle.
Cheers,
Norm.
@@NormanNodDunbar as far as I’m aware there’s no pin operation in avr assembly.
There’s just an out opcode that takes a port and a value. Even the sbi and cbi operate on a whole port. It wouldn’t be very RISC if there was either :)
Or am I missing something?
Excellent.
Thank you! Cheers!
This is absolutely too much effort for something I can do in Arduino c
Like why to bother even arduino api is making it too easy that rusting it
Is going to be useless
Perhaps if you are making more complicated program and want rusts memory safety features. Or if you are comfortable with rust but not C.
I thought you were going to show how I can remove actual rust from my electronics :(
What os are you using in this video?
So, it's hard to tell. Are you going to focus on embedded Rust, or just briefly showcase it and jump to the next thing?
That was cool.
Thanks!
Thank you!
How does one tell whether a 3rd crate will run with no_std?
With only 2K ram I would think one would avoid using the heap. In that case why use Rust?
I think that rust is a bit problematic on embedded cus because when initializing a rust runtime executable a lot of memory allocated compared to a c rtex. An in-depth analysis of the memory allocations performed can be found under the topic "Investigating Memory Allocations in Rust" by ysantos
It might do less allocations when you specify no_std... but yeah, it could absolutely cause problems on some small devices.
Twice you read the hash revision at 2:55 incorrectly as 45, but wrote it correctly as 54
Not judging, just found it interesting.
subscribed!
Is Rust bloated and slow compared to embedded c? As someone who exclusively uses c for real time embedded applications I am very partial to C compared to anything else, this may just be internal bias but if I see any type of intelligence or memory safety I immediately assume it is going to be slow code.
rust seems like c with safety wheels attached. It probably is much slower
Rust can be just as fast as c if not faster. Basically its around the same speed depending on application and implementation. Most of rusts checks happen at compile time.
@@mychromebook9935
What?
You haven't really done anything with Rust, have you?
The runtime performance is same as C or C++. Very often the same exact machine instructions. Memory safety comes from what the compiler refuses to build, not from additional runtime checks.
Can i do same with python??
awesome 👏👏👏👏👏👏👏
Author's copy-paste isn't working :( hi need to type everything.
This looks cool, but a HAL for an AVR? All this seems like an overly complicated way of avoiding reading the datasheet. Over 4k of flash to twiddle an output- if you put this into a product, you'd be throwing away money for having to use an AVR with more flash.
The only problem is that he ran a debug build. A release build is only 324 bytes. That is much smaller than Arduino. It is still larger than the ~200 bytes for raw C, but that is due to the hall doing a little bit of extra initialization that you would probably end up adding to the C anyway.
i dont get it, i keep getting fetching errors from this repo
I love rust
Hi, somebody write Code in RUST for ESP32-2432S08R ? Please share a Example for Display Text / Graphic on the Display please
Ahah, low level gang😎
Literally anything compiles to anything with the right tools.
What you're saying is that rust compiled to c, which like all c programs, can be compiled to assembly.
I would hardly call this bare metal rust.
You say '450' where it is (and you type) '540'