Hello Rustaceans! @georgemorgan and I are happy to announce Flipper, an embedded development platform we've been working on for the past few years. The project is still in a very early stage, but we've just open sourced our repository, and @georgemorgan gave a presentation of the platform at the latest bay area rust meetup. We have big plans for Flipper, and Rust plays a huge role in our vision for it.
What is Flipper?
Flipper is an embedded development platform that can be controlled remotely from any programming language. Our goal is to make embedded development easier for everyone, especially people who don't have lots of low-level knowledge. By supporting higher level programming languages, we hope to make hardware projects accessible to developers who may only know Python or Java.
Flipper and Rust
As you may have guessed, Rust is one of the languages that you can use to control Flipper. And what's more, it's also the language which we're using to write our tools! We have a command line app written in Rust which we use for flashing the firmware, generating language bindings, and - coming soon - creating and managing Flipper packages. Furthermore, since Flipper is based on the idea of controlling hardware remotely, you can control it directly from the command line.
One thing to note here is that while we're using Rust to control Flipper, it's not quite Embedded Rust because we're not compiling Rust to run directly on the device. Instead, we're compiling Rust for the host machine and using our library libflipper to execute C functions remotely. This means that all of the functionality of Flipper's standard library is available in stable rust by just importing a crate!
Project status
Leading up to today, we've been doing a lot of prototyping and pioneering,making sure that our programming model actually works and that it works wellfor a variety of different languages and platforms. We've created proof-of-concept implementations for all of the languages we want to support, and have started rounding out and polishing the ones we most heavily rely on, namely C, Rust, and Python. Moving forward, we'll start establishing general guidelines for language binding APIs, because it seems like the machinery in each set of bindings will be very similar. Hopefully, this means that while we focus on the bindings that need our immediate attention, others can feel free to jump ahead and implement bindings for the languages they use.
Future plans
I personally have a lot of plans for Flipper and Rust, but it will probably take us a while to reach a point that I can spend time on these ideas specifically.
Flipper package manager and registry
I would really love for Flipper to have an equivalent to cargo and crates.io so that users can publish and reuse packages that they write. As we've been defining and refining how packages in Flipper work I've always kept this in mind, trying to plan ahead and make it as easy as possible to build these tools around them. There are a lot of unsolved questions here, but we have a while to solve them.
Native embedded rust on Flipper
I've been following the development of rust for embedded for quite awhile now, and I'm blown away by how much progress @japaric and friends have made in this space, just in the past year! After we get all of Flipper's remote API's nailed down, I would love to explore supporting embedded-rust packages to compile directly to Flipper. I think that embedded rust still needs some time to grow and gather more support in stable rust, but by the time that happens we may be ready to look at making this jump! In the nearer-term it may be possible to make an implementation of embedded-hal that compiles on a host machine (using stable rust perhaps?) and simply executes Flipper's standard library remotely. I can't make any promises about getting around to that myself, but I'd be happy to chat about my thoughts on that if anybody's curious.
