Structure of embedded crates?

Hi all!

I know that there are auto-generated peripheral access crates for many microcontrollers. I gather that they share a very similar API as far as possible. Then there are HAL crates for a few families of uCs as well.

My question is: how similar are these HAL crates across product families and manufacturers? Are each developed independently, or are all Rust HAL crates based on a common architecture and design, regardless of manufacturer and product family?

I have experience with STM32 chips and STM32 HAL (C libraries). They have a model of providing an API which should be similar across all their products, and then providing extension APIs which are specific to the family in question.

This made me wonder if it would be possible to do something similar, but on even wider scale in the Rust embedded community. Is it possible to coordinate efforts so that a 16-bit PIC, an STM32 and an Arduino have a similar interface for e.g. GPIO? Can the HAL be written abstract enough to be able to swap out the HAL and chip, but keep the same higher-level application code? Or will there be too much platform-specific code to make it worthwhile?

I'm envisioning (maybe naively) a world in which exists a high-quality, open-source HAL implementation in Rust for most microcontrollers which is similar enough to enable switching of chips mid-development without any existing application code being lost. A uart should be used via the same API regardless of chip manufacturer and chip as far as possible.

Is this already the case? Is it at all possible?

1 Like

Yes there are common trait definitions that actually allow the (almost) same code to run on RaspberryPi and on STM32 for example. The crate is fittingly called embedded-hal.

Some implementations: STM32F4, STM32F1, Raspberry Pi, ATmega/ATtiny

2 Likes