She took a painful breath and looked up at the sky. Her heart was pounding. There was nothing to do but wait.
Somewhere, at the edge of the solar system, her robot, HER ROBOT, was receiving its first instructions.
It was waking up, and was being told to listen to her commands. Even though the synchronization message was only a few hundred bytes, it was still going to take another hour or so.
70 bits per minute, give or take a few. We had mastered faster than light communication, and it was slow as hell.
As a (late) part of the #rust2020 request, I wanted to talk about one of the paper-cuts that has become decently problematic for new and experienced users of Embedded Rust:
The size costs of formatting in Rust today are unreasonably expensive for users of Rust on bare metal embedded systems.
In particular there are two root issues I can see:
- Out of the box formatting machinery, including
panic!() in Rust is not program space efficient
- More problematically, there is no way to change or opt-out of this cost, and it can show up in unexpected places that are outside of developer control
To be clear: I don't think that these issues are a failing of the language, but rather a sign of growth. The current formatting solution has managed to work without issue for most people (and is still okay-ish in edge cases like embedded) for the better part of 4 years. However as we push Rust to more use cases, the language will need to adapt if it would like to fill into these spaces.
This post aims to illuminate the challenges faced today, and attempt to draw an attainable set of paths moving forward.
For open source projects, it can be difficult to find balance between a number of factors: the free time of contributors, the desires of the communities using the project, the ability to on-ramp and mentor new contributors, and to provide necessary guidance and feedback.
The Rust Project, and multiple sub-teams and working groups have found success in use of the RFC Process for making informed, high level decisions. However, the RFC process does not address the work necessary for exploratory projects before a decision is made, the work necessary to implement made decisions, or the work necessary to maintain and overhaul parts of the projects in the long run.
To address these needs, I'd like to propose a general concept and approach called Shepherding, which aims to assist maintainers of these projects with this aspect of managing the project. By enumerating core goals and putting a name to concepts, but specifically NOT mandating every aspect of implementation, I hope that this technique can be applied across many teams inside and outside of the Rust Project.
The "Shepherding v3.1" name comes from a blog post written by Niko Matsakis titled Shepherds 3.0, which also does an excellent job describing the motivations regarding these efforts. This post instead makes a few clarifications and additions to the 3.0 post, and aims to be a "reference manual" for the concept, defining terms and important goals, rather than discussing motivations.
Hey all, just a quick note on whats going on in my life right now. I'm leaving my current position at Geeny/Telefónica Next, and focusing on a personal project around Continuous Integration for Firmware and Hardware development for (at least) the next few months. This would help developers implement Hardware in the Loop testing as described by a previous blog post of mine.
Oh, and hopefully I'll find some time to relax for a couple weeks.
Next > >
At the recent 2018 Rust All Hands, I met up with Katharina @spacekookie, who works on an open source project that creates software for Embedded Linux Devices. She had talked with the other engineers on the project about including some Rust components, however with their limited flash storage space (8MB for the whole firmware, including operating system and all other software), she was worried that the Rust binaries wouldn't fit. The current webserver component for their project was measured in the 100's of KB, while the Rust binary she produced was already multiple MBs, even with a