Blog
Rust is rolling off the Volvo assembly line
Tock binary size
Sequential-storage: efficiently store data in flash
While using a full-blown filesystem for storing your data in non-volatile memory is common practice, those filesystems are often too big, not to mention annoying to use, for the things I want to do. My solution?
I've been hard at work creating the sequential-storage crate. In this blog post I'd like to go over what it is, why I created it and what it does.
Rust for hardware vendors
At Tweede golf we're big fans of creating applications on embedded devices with Rust and we've written a lot about it.
But if you're a hardware vendor (be it chips or full devices/systems), should you give your users Rust support in addition to your C support?
In this blog I argue that the answer to the question is yes.
Are we embedded yet?
Rust at Royal Netherlands Aerospace Centre
Crash! And now what?
Imagine you've just deployed an embedded device in the world and of course, you have tested it thoroughly and it works. To monitor the device, you've set up some logging.
Low power & low frustration (video)
Pioneering Rust in High Tech
Pioneering Rust in the high-tech industry!
Together with High Tech Software Cluster, we organized an event to showcase Rust’s strengths and safety features to tech companies in the Brainport region in the Netherlands.
We asked 5 people why they like Embedded Rust
LoRaWAN Applications in Rust
Last September, at the start of my internship at Tweede Golf, my tutors gave me a LoRa-E5 Dev Board. My task was to do something that would make it easier to write applications for this device in Rust. Here's what I did.
Optimizing Image Processing on the Edge
Async Rust vs RTOS showdown!
It's time for another technical blog post about async Rust on embedded. This time we're going to pitch Embassy/Rust against FreeRTOS/C on an STM32F446 microcontroller.
My first weeks at Tweede golf
Async on Embedded: Present & Future
In our last post, we've seen that async can help reduce power consumption in embedded programs. The async machinery is much more fine-grained at switching to a different task than we reasonably could be. Embassy schedules the work intelligently, which means the work is completed faster and we race to sleep. Our application actually gets more readable because we programmers mostly don't need to worry about breaking up our functions into tasks and switching between them. Any await is a possible switching point.
Now, we want to actually start using async in our programs. Sadly there are currently some limitations. In this post, we'll look at the current workarounds, the tradeoffs, and how the limitations might be partially resolved in the near future.
Measuring power consumption: sync vs. async
Long range networking with LoRa: an overview
Build your own async primitive
Concurrency isn't easy and implementing its primitives is even harder. I found myself in need of some no-std, no-alloc Rust async concurrency primitives and decided to write some. I kept the scope small so even you and I can understand it. Even so, it still involved futures, wakers, atomics, drop and unsafe. I'll introduce each of those to you while building a simple primitive. At the end, you will be able to implement your own primitives!
Potential improvements for Rust embedded abstractions
Recently, we worked on an embedded (STM32) project in Rust
and we got some hands-on experience with
the abstractions commonly used for that.
There's embedded-hal, which offers abstractions related to
timing, GPIO pins and
common communication peripherals like SPI and USART.
There's also multiple stm32xxx-hal crates
which offer abstractions over
most of the peripherals of different STM32 CPU families.
Although many of them were nice to use,
we found some parts to be lacking
and we'd like to propose some potential improvements
to embedded-hal and its implementing crates.
Rust, my first embedded language (1/5)
The promise of Rust async-await for embedded
Why Rust is a great fit for embedded software
Making embedded robust with Rust
Embedded software has an issue that most software doesn't: It can be very hard to get it patched. Sometimes a device hangs 5 meters high on a street light in the middle of a highway in another country. Sometimes a device is attached to a customer's heart. Sometimes strict validation requirements make changes to the software very expensive. In each case it is important to build software that doesn't fail, even in unpredictable conditions.