Our great sponsors
-
-
awesome-embedded-rust
Curated list of resources for Embedded and Low-level development in the Rust programming language
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
hubris
A lightweight, memory-protected, message-passing kernel for deeply embedded systems. (by faithanalog)
-
probe-rs
A debugging toolset and library for debugging embedded ARM and RISC-V targets on a separate host
-
-
-
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
See Tock OS https://www.tockos.org/ for another Rust-based embedded OS with a fairly comparable design to Hubris. The debugging capabilities of Humility make an interesting comparison to what's provided by cargo-embed https://probe.rs/docs/tools/cargo-embed/ and Knurling Tools https://knurling.ferrous-systems.com/tools/ by Ferrous Systems.
Ultimately, the embedded space has common needs and it would be convenient to see more widespread cooperation among these projects, improving reliability and avoiding wasteful duplication of work. More resources at https://github.com/rust-embedded/awesome-embedded-rust
See Tock OS https://www.tockos.org/ for another Rust-based embedded OS with a fairly comparable design to Hubris. The debugging capabilities of Humility make an interesting comparison to what's provided by cargo-embed https://probe.rs/docs/tools/cargo-embed/ and Knurling Tools https://knurling.ferrous-systems.com/tools/ by Ferrous Systems.
Ultimately, the embedded space has common needs and it would be convenient to see more widespread cooperation among these projects, improving reliability and avoiding wasteful duplication of work. More resources at https://github.com/rust-embedded/awesome-embedded-rust
Why does nobody do this in their readmes normally? They just let you look into the code and tell you "now figure it all out yourself".
[0] https://github.com/faithanalog/hubris/tree/pinetime
Under the hood, cargo-embed, knurling's probe-run, and Humility are all built atop probe-rs (https://probe.rs/) to provide debugging - I think in this case it's actually a great example of cooperation between projects! Probe-rs has received PRs from both Knurling and Oxide devs; it provides the common interface to use various types of debug hardware and talk to various types of microcontroller cores, essentially replacing OpenOCD.
Other folks have mentioned this, but it's important to understand the limitations of Rust with respect to safety. In particular: every stack operation is -- at some level -- an unsafe operation as it operates without a bounds check. This isn't Rust's fault per se; non-segmented architectures don't have an architecturally defined way to know the stack base. As a result, even an entirely safe Rust program can make an illegal access to memory that results in fatal program failure. That, of course, assumes memory protection; if you don't have memory protection (or, like many embedded operating systems, you don't make use of it), stack overflows will plow into adjacent memory.
But wait, it gets worse: stack overflows are often not due to infinite stack consumption (e.g., recursion) but rather simply going deep on an unusual code path. If stack consumption just goes slightly beyond the base of the stack and there is no memory protection, this is corrupt-and-run -- and you are left debugging a problem that looks every bit like a gnarly data race in an unsafe programming language. And this problem becomes especially acute when memory is scarce: you really don't want a tiny embedded system to be dedicating a bunch of its memory to stack space that will never ("never") be used, so you make the stacks as tight as possible -- making stack overflows in fact much more likely.
Indeed, even with the MPU, these problems were acute in the development of Hubris: we originally put the stack at the top of a task's data space, and its data at the bottom -- and we found that tasks that only slightly exceeded their stack (rather than running all of the way through its data and into the protection boundary) were corrupting themselves with difficult-to-debug failures. We flipped the order to assure that every stack overflow hit the protection boundary[0], which required us to be much more intentional about the stack versus data split -- but had the added benefit of allowing us to add debugging support for it.[1]
Stack overflows are still pesky (and still a leading cause of task death!), but without the MPU, each one of these stack overflows would be data corruption -- answering for us viscerally what we "need the MPU for."
[0] https://github.com/oxidecomputer/hubris/commit/d75e832931f67...
[1] https://github.com/oxidecomputer/humility#humility-stackmarg...
Other folks have mentioned this, but it's important to understand the limitations of Rust with respect to safety. In particular: every stack operation is -- at some level -- an unsafe operation as it operates without a bounds check. This isn't Rust's fault per se; non-segmented architectures don't have an architecturally defined way to know the stack base. As a result, even an entirely safe Rust program can make an illegal access to memory that results in fatal program failure. That, of course, assumes memory protection; if you don't have memory protection (or, like many embedded operating systems, you don't make use of it), stack overflows will plow into adjacent memory.
But wait, it gets worse: stack overflows are often not due to infinite stack consumption (e.g., recursion) but rather simply going deep on an unusual code path. If stack consumption just goes slightly beyond the base of the stack and there is no memory protection, this is corrupt-and-run -- and you are left debugging a problem that looks every bit like a gnarly data race in an unsafe programming language. And this problem becomes especially acute when memory is scarce: you really don't want a tiny embedded system to be dedicating a bunch of its memory to stack space that will never ("never") be used, so you make the stacks as tight as possible -- making stack overflows in fact much more likely.
Indeed, even with the MPU, these problems were acute in the development of Hubris: we originally put the stack at the top of a task's data space, and its data at the bottom -- and we found that tasks that only slightly exceeded their stack (rather than running all of the way through its data and into the protection boundary) were corrupting themselves with difficult-to-debug failures. We flipped the order to assure that every stack overflow hit the protection boundary[0], which required us to be much more intentional about the stack versus data split -- but had the added benefit of allowing us to add debugging support for it.[1]
Stack overflows are still pesky (and still a leading cause of task death!), but without the MPU, each one of these stack overflows would be data corruption -- answering for us viscerally what we "need the MPU for."
[0] https://github.com/oxidecomputer/hubris/commit/d75e832931f67...
[1] https://github.com/oxidecomputer/humility#humility-stackmarg...
The pinetime can basically do anything you want it to, as long as you're willing to make it so. I'm wearing it on my wrist right now, but I have an iPhone and the support for it is not great. In terms of build quality, it's quite good, and the battery lasts for about a week. It's slimmer than an apple watch, which is a major plus for me. But if you have an iphone, step tracking and limited music control is all you'll get in terms of accessory use. You can always contribute, however, and there is a very active community working on the firmware in the github repo (https://github.com/InfiniTimeOrg/InfiniTime).
The thing that the PineTime does really well, however, is beat the price tag of basically every other smartwatch out there ($30). I'm not sure how chip-shortage prices might be affecting this though...