[HN Gopher] Writing embedded firmware using Rust
___________________________________________________________________
Writing embedded firmware using Rust
Author : todsacerdoti
Score : 99 points
Date : 2021-12-19 14:52 UTC (8 hours ago)
(HTM) web link (www.anyleaf.org)
(TXT) w3m dump (www.anyleaf.org)
| miohtama wrote:
| > Hiring programmers proficient in Rust is much more difficult
| than in C or C++ due to the smaller user base. Example code,
| tools, and libraries released by MCU manufacturers are almost
| always for C or C++. The Rust embedded infrastructure is new, and
| rapidly changing.
|
| While Rust cost per engineer today is higher, is the cost of the
| project lower, because due to Rust those engineers are much more
| efficient?
| wyager wrote:
| I recently did an embedded project using rust
| (https://yager.io/vumeter/vu.html). It was great, and I'm
| planning to use Rust for embedded projects in the future. There
| are a few pain points, especially around rust's relatively
| limited polymorphism, mutable refs, and the constraints imposed
| on async/await by type system limitations, but it was still super
| nice compared to using C(++). I'm also optimistic these pain
| points can be mostly fixed with improvements to the type system.
| I think they might already have improved length polymorphism - I
| think I saw something about that recently.
| sanjayio wrote:
| As someone who plans on dabbling into embedded Rust next, this
| is great to hear. Thanks for sharing. Any resources that were
| helpful in your embedded Rust journey?
| mh7 wrote:
| Not seen much point in rust for embedded for small MCU's that I
| target.
|
| All memory are statically "allocated" as global variables/buffers
| and never free'd, so there's no ownership or dangling references
| to worry about ever. This allows me to know at link time how much
| memory my program uses.m and of course simplify programming.
|
| Only single cores, the only synchronization issue is between
| interrupts and main program, a case rust doesn't handle afaik(?)
| and in 99% of the cases a ring buffer or simple flag variable is
| enough.
|
| Never use much abstractions, so C is fine in terms of ergonomics.
| Never use third party libraries aside from CMSIS register
| headers.
|
| Probably the only thing that would help me is some static
| reflection and compile time programming, but I have python
| scripts as a code generation step to generate tables,
| definitions, annotations, etc, and that works fine.
| michael_j_ward wrote:
| If you're interested writing embedded Rust firmware, I suspect
| will also be interested in this.
|
| https://cliffle.com/blog/on-hubris-and-humility/
| bcantrill wrote:
| In addition to Cliff's talk/blog -- which are absolutely
| outstanding -- I would recommend listening to the Twitter Space
| we did on Hubris and Humility last week.[0] It was a really fun
| conversation, and it also serves as a bit of a B-side for the
| talk in that it goes into some of the subtler details that we
| feel are important, but didn't quite rise to the level of the
| presentation. And of course, be sure to check out the source
| itself![1][2]
|
| [0] https://www.youtube.com/watch?v=cypmufnPfLw
|
| [1] https://github.com/oxidecomputer/hubris
|
| [2] https://github.com/oxidecomputer/humility
| NoahKAndrews wrote:
| Wow, what a cool system design
| travisgriggs wrote:
| Naively Curious.
|
| I do quite a bit of good old C on Atmel & STMicro chips M0+
| chips. When I do, there's a whole layer/framework of register
| definitions (structs, enumerated, typedefs, etc) C header files
| that I'm able to include for my specific chip and package.
|
| If I want to experiment with Rust in place of C on one of these
| chips (say an Atmel SAMD21 J) what are my options? Do I have to
| reverse engineer all of those register mappings into Rust
| constructs? Can Rust import and use C header files?
| kennywinker wrote:
| To add on to what bri3d said, these Rust register definitions
| are being auto-generated using SVD* files published by the chip
| vendors. For stm32 for example there are the auto-generated
| register definitions** and then the HAL layers*** on top that
| try to build easy to use tools on top of the registers (e.g. an
| SPI or USART type with write and read functions).
|
| * https://www.keil.com/pack/doc/CMSIS/SVD/html/index.html
|
| ** https://github.com/stm32-rs/stm32-rs
|
| *** https://github.com/stm32-rs/stm32f4xx-hal for the stm32f4xx
| line
| leafario2 wrote:
| > Can Rust import and use C header files?
|
| Yes, after piping them through rust-bindgen, any binary can be
| statically of dynamically linked. I did this, it's nice that
| it's possible, but the PAC route others have described here is
| way better.
| bri3d wrote:
| The embedded-hal project supplies these for a wide variety of
| controllers, for SAMD specifically, https://github.com/atsamd-
| rs/atsamd .
| axegon_ wrote:
| Rust is a brilliant candidate for embedded systems - safety,
| built-in package management, it's ergonomic and pleasant to work
| with. But it has one fundamental problem, which the entire
| community refuses to address: the steep entry. Several months ago
| I was making a wedding gift for a friend which almost exclusively
| involved embedded development. And having several brand new
| STM32's laying around I initially opted for them and rust. In all
| fairness the entire thing did not involve all that much: If I
| recall correctly, an I2C display, RTC, sound sensor, some
| adafruit soundboard, sound amplifier+speaker and a couple of push
| buttons. I went against one of my own core philosophies of not
| using something for the sake of using it, that being rust on this
| occasion. In theory the STM32 should be a great candidate since
| the Embedded Rust Book revolves around it. Well... No. You see,
| each time you decide to get something rolling, you have to work
| your way through tons of configuration, completely blind. And
| just as you are convinced that you did everything right, compile
| your code and flash the device, you get a cryptic error and you
| are left clueless as to what it may be. It took me 7 days to get
| the I2C display going. I guess you could slash a few hours since
| I had to get Cyrillic letters out on the screen but that was just
| a few hours at best. At one point I simply gave up because I
| didn't have that much time to waste and ran back to the trusty
| Arduino. And this is fundamentally what's crippling the embedded
| Rust world - it's way too much of a hassle to be considered a
| good option when you have to deal with a schedule - you have to
| spend absurd amounts of time fiddling with setup and poor
| documentation. If those issues are addressed at one point, I'd
| gladly ditch arduino for good. But until then the embedded rust
| is just some fun toy to play around with on a day off.
| sanjayio wrote:
| I'm curious how well you knew Rust prior to starting? I'm
| learning Rust at a very slow pace. I finished a language
| specific course, going through advent, and I'm planning on
| going through an embedded Rust book next. I can imagine
| attempting to jump straight into embedded Rust could be very
| challenging.
| brundolf wrote:
| I get the sense they weren't talking about what most people
| mean when they say "steep entry" in a Rust context (i.e. the
| language itself), but specifically its support and
| documentation for the embedded case
| xxpor wrote:
| Damn, I've been doing a bunch of exploring of this exact topic
| over the past week. This would have saved me a bunch of time.
| Unlucky for me it wasn't submitted last Sunday!
|
| One thing that's killed me a bit is the core::/std:: split, when
| the core:: versions have the exact same semantics, or perhaps are
| equivalent for the things that they do implement (for example,
| the core version might be missing the serde parts, but is
| otherwise the same). There's a few crates I tried out that
| wouldn't compile with no_std, but with a simple text
| substitution, would work. I'm sure there's a million edge cases
| I'm not aware of, but if cargo or rustc could provide an option
| to just sub in the core version, that'd be really nice.
| nynx wrote:
| Yeah, std is actually just stuff re-exported from core + some
| more stuff.
| eska wrote:
| I assume one could send a patch to those crates that defines
| "use core::" instead of "use std::" by using the compile time
| config directive to check whether the std is enabled?
| hkalbasi wrote:
| Isn't "use core::" enough, without compile time config
| directive?
| xxpor wrote:
| Oh yes, and I've started preparing those patches. It's just a
| bit of a bummer to have the churn when you're just starting
| out and iterating through ideas.
___________________________________________________________________
(page generated 2021-12-19 23:00 UTC)