2 ms·
Great point on embedded dependencies - In theory they can be a time saver, but in Rust land, they're often too.. abstract, and full of missing features and bugs
by the__alchemist 5y ago
Great point on embedded dependencies - In theory they can be a time saver, but in Rust land, they're often too.. abstract, and full of missing features and bugs. Easier to open the datasheets, and send a few bytes down the SPI/I2C etc lines. I haven't been able to use any deps without forking. In Rust, popular abstractions tend to get in the way too, ie if a rust peripheral struct is trying to own a shared bus.
Another good point, re HALs. She skipped the official HAL after finding it to be too much trouble. I've found that a good peripheral access library generated from SVD files is all you need, and is easier to work with than a HAL that's not carefully made. Ie an API that provides named register blocks, registers, and fields, and knows how many bits go in each, which you can read from etc. (Is this what the CMSIS lib she mentioned is?)
Related to the last point: "I write very small, usually project-specific, abstractions over that" - If you decide a popular or official HAL isn't helping you, you end up writing your own HAL!
> I've chosen to avoid using the Node.js ecosystem in favor of just plain JavaScript
Also a choice I agree with.
- stefan_ 5y agoSomething is weirdly rotten in the Rust embedded ecosystem. The overarching experience is best described as akin to C++ template metaprogramming. The final result is that setting a GPIO output somehow requires unwrapping an option, as if we didn't just set a single bit in some register and there were actual meaningful errors with that operation the uC could detect.
- the__alchemist 5y agoTypestates and reliance on `embedded-hal` traits are a particular pain. I think we're in a weird spot, where the language itself, and some of the build tools (Like those by the Knurling team) are outstanding, but the most popular libraries have made questionable design decisions, and have flaws that show almost immediately. I'm curious how many teams are developing new projects using Rust, but staying away from the open source ecosystem.
- codeflo 5y agoIt’s not just crates.io. I have a minimal, no Libc, no runtime dependencies Windows project for fun that compiles to a tiny executable of only a few kilobytes. If you’re going down this minimalist/better C route, you increasingly have to avoid large parts of the Core library as well, which is becoming more bloated by the minute. The culture seems to move in the direction of “avoid unsafe at all costs” (even where that makes the API so complicated that it hurts correctness in practice) and “avoid dynamic dispatch at all costs” (even where that hurts performance).
- vbsteven 5y agoYour comment made me wonder if crates.io is starting to show some of the same issues that npm has. Lots of small packages, not always consistent, focussed on one use case that make other use cases non-optimal. The recent posts about Rust in Android shows a side of this. They are avoiding Cargo in favor of plugging in their own build system. Use the language for its benefits and avoid the ecosystem (partly).
- rcxdude 5y agoI think the case with embedded code on crates.io is more along the opposite: they're trying to make the experience as consistent as possible by defining common interfaces for embedded drivers so code can run consistently with different hardware or libraries. The problem is it's really hard to design such abstractions, especially safely, when you can't make many assumptions about the hardware it'll be abstracting over and efficiency is paramount.
- the__alchemist 5y agoTo address unwrapping the GPIO set: this is caused by a (popular) misuse of embedded-hal traits. The traits are fallible to be general, but HALs use this as their primary API, and make it always pass. So unwrap is effectively clutter, and misdirection. The answer is to provide a primary API that's decoupled from the traits, and bolt on the traits to support generic drivers.
- unwind 5y agoCMSIS is Arm's own standard ("Cortex Microcontroller Software Interface Standard") for low-level software interfacing. It's on Github [1], and rather nice. Vendor's middleware can be of varying quality, so just using CMSIS seems refreshingly nice! [1] https://github.com/ARM-software/CMSIS_5 https://github.com/ARM-software/CMSIS_5
- the__alchemist 5y agoThank you. It sounds like it's something between a peripheral access lib, and HAL, in terms of abstraction level. A minimalist HAL.