In embedded systems, energy efficiency is crucial for practical applications. Usually devices run on a battery, so the less energy you use, the longer the power supply will last. In this post we'll look at the basics of going to sleep and waking back up, and build a proof of concept using the nRF52840 development kit.
Welcome to the age of communication. It's 2021 and technology has come a long way. People, large machines and small devices communicate more intensively than ever before, and many technologies to enable them to do so have been developed. Some of those technologies use physical pathways like fibreglass to reach their receivers, others use radio signals to send messages. It's these wireless communication technologies that spark the imagination the most.
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!
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.
First-up is Henk Dieter, backend developer at Tweede golf. He has been interested in Rust for quite some time. Actually, it’s how Henk Dieter found out about Tweede golf, as it was one of the first companies in the Netherlands to adopt Rust as their weapon of choice.
Typically embedded devices are developed using C++. At Tweede golf we have chosen to use Rust instead for implementing our embedded devices. This is controversial as the embedded hardware field is generally quite conservative. Convincing our clients to adopt Rust for their products can be a challenge.
Rust is nice for a lot of things. At Tweede golf we've been using the language primarily for high-performance web applications. But that's not all Rust can do. Rust can be used to write embedded applications as well.
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.