Oxide on My Wrist: Hubris on PineTime was the best worst idea
artemis.sh
artemis.sh
Ultimately, the embedded space (including all sorts of low-level, retro, "bare-metal", remote etc. programming) 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
This twitter space goes into a lot of detail: https://www.youtube.com/watch?v=cypmufnPfLw
But at the end of the day, no_std will allow a bigger ecosystem and sharing between many of these projects.
Having the ability to mark (for example) your stack as non-executable is a simple change that can remove a whole class of problems.
That is only the skimming the surface tho.
(Of course, having better formal models of how 'unsafe' code behaves might allow us to be a lot more rigorous in building safe primitives, such as by endowing some 'unsafe' calls with proof objects that might reify the outcome of a bounds check.)
Also, when you're dealing with embedded code, you're very likely going to be using unsafe code (e.g. driver level). With no other protection, incorrectly programming a DMA transfer to trample over code-space is not unknown... and Rust cannot protect you from that.
(Having said that... an MPU window will also not necessarilly catch a bad DMA transfer either).
This is a good point but isn't Hubris designed to use statically bounded amounts of memory anyway, like much embedded software? AIUI, this was a key reason for keeping their design focused on synchronized requests, avoiding the hard-to-predict buffering that's needed for supporting 'async' models.
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...
Bounding stack usage is of course a whole-program concern, but that ought to be feasible when building for embedded, where external "plugin" components are unlikely and there's no inherent need for true separate compilation. (Arguably, in such cases even the need for an actual "stack" structure is actually quite limited; a smarter compiler might well replace many uses of the activation stack with references to static data, reserving it for cases where e.g. reentrancy is actively needed. AIUI, there has been some work along those lines for LLVM.)
ARMv8-M does have stack limit registers, which do precisely this. Being a much simpler mechanism than the MPU, they are quicker to switch than the entire MPU state when switching tasks.
drv/ contains drivers, a mix of simple driver lib crates and fully-fledged server bin crates. Current convention is that drv/SYSTEM-DEVICE is the driver for DEVICE on SYSTEM (where SYSTEM is usually an SoC name), whereas drv/SYSTEM-DEVICE-server is the server bin crate.
I think it's worth praising this repo without knocking others. Open source authors have no obligation to their users; if they don't have the time to, or just don't care to, so organise their READMEs, then they need not. In fact, if it's sufficiently important, for much open-source software anyone else can do it, and submit a patch.
This is a hard problem. I try to make an effort, but too often I get it wrong.
I am not talking about the difficulty of writing high-quality explanatory prose. I'm talking about expanding what people consider standard practice, to include a bullet-point description of how the files in the project are laid out. You don't need to be a good writer in order to do this.
That said, just because something is hard doesn't mean it's not a skill that can be learned. Not everyone has the same attitude for writing (much like programming), but generally I believe that "most people can be taught most things to a basic level of competence", and I do not think documentation writing is exempt from that principle. There is no reason why the skill of writing halfway-decent documentation should not be taught in programming courses.
We have a custom build system on top of Cargo, and so things are a bit weird for a normal Rust project, and so it's extra important.
Even on projects that I'm actively working on, the most recent commit of a folder gives me no useful information, whereas if I could edit the README.md I could atleast add a description of each folder so that new users could understand the directory structure better.
(Context: async/await-based per-task loop to facilitate background LoRa send/receive while other tasks can continue to operate (DMA, SPI, etc) independently, with the overall loop shutting the primary Cortex core down when processing is completed/while waiting for events/updates.)
The last I checked, hubris was strictly synchronous and I didn't get the sense that the interaction between tasks was architectured in such a way that would facilitate low-power designs for battery-powered devices.
For more: https://hubris.oxide.computer/reference/#_why_synchronous
(Basically, this probably hasn't changed since you looked at it, but for anyone else who hasn't seen it yet...)
> shutting the primary Cortex core down
We don't have mainline support for multicore systems, and there's a big ? in there, design-wise. So yes, you are right to recognize that that is the current state of things.
Can you comment on this: others have asked here on HN before but didn't seem to get an answer - does power management/consumption factor in at all in the architectural design (even if it's "this makes it possible to add power management later") or is it strictly a non-goal? (I know your current particular application domains aren't constrained by battery capacity.)
It would be easy enough to hack the kernel to always WFI/WFE if all tasks are exited/completed, but I'm thinking about cases where task(s) are still running but the supervisor process is aware that they're all currently in a busy-waiting state. But that wouldn't be sufficient (on its own) if the OS requires certain peripherals to always remain powered up, uses a high-frequency tick interrupt that will constantly wake the device anyway, etc, etc.
It isn't that powerful, and I wish it had a second physical button. I haven't explored the mods very much because it does what I need it to do, but the scene has the feel of the early Xbox hacking scene, to me at least.
There's this watch which appears to be heavily inspired from the Amazfit Bip: https://www.kickstarter.com/projects/gfw/banglejs-2-the-open...
I wonder if the performance difference could, in some applications, create a preference for processors with enough SPI ports to dedicate one per peripheral (no chip select required). Not only no shared bus (as in I2C), but no shared SPI-task.
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...