search

rust-embedded / embedded-hal

A Hardware Abstraction Layer (HAL) for embedded systems
Apache License 2.0
1.99k stars 200 forks source link

Discussion: Impl reuse across MCUs #184

Open dzarda opened 4 years ago

dzarda commented 4 years ago

embedded-hal has done a great job in reducing the combinatorial complexity stemming from the m:n amount of microcontrollers:devices. But this is only part of the complexity problem present in current embedded development.

The other part comes from the fact that new MCUs/SoCs keep coming out at a breakneck pace. The silicon vendor is unable to iterate the HDL of every peripheral in the system every time a new Snapdragon 999 comes out. They reuse those internals. Code driving these things must keep the "complexity pace" with the hardware.

ChibiOS HAL has found a way to reuse peripheral code between STM32 types - possibly because Giovanni di Sirio has insider info due to being employed by ST :) Check out the LLD/ sources that act as building blocks for all the peripheral sets:

https://github.com/ChibiOS/ChibiOS/tree/master/os/hal/ports/STM32/LLD

I realize this has little to do with embedded-hal per se but I hadn't figured out a better place to pose this. How achievable is this for us? @japaric ?

ryankurte commented 4 years ago

Hey thanks for the issue, it's an interesting problem! At one point in time we were looking at extracting commonality using svd2rust (or similar) that we could then extend where required and re-export across device families.

I'm not sure what the state of the art is at the moment, however, you might be interested in looking at https://github.com/rust-embedded/svd2rust/issues/96 (and the related issues) from back then, as well as https://github.com/stm32-rs/svdtools which is used for pre-processing SVDs now.

Disasm commented 4 years ago

@dzarda We have kind of proof-of-concept of reusing the USB driver across different MCUs, and it looks possible for most of the peripherals. However, any additional info about STM32 peripherals is highly appreciated, because at the moment it's gathered from RMs with error-prone human eyes.

adamgreig commented 4 years ago

We already do this for lots of devices in the same family in the various HAL crates, where it's more likely that peripherals are reused more or less exactly. For example, stm32f4xx-hal supports some 17 product lines (each of which comes in multiple package and memory size variants). The same peripheral driver code works on all of them, with some variant-specific tweaks selected at compile time, just like ChibiOS.

We could imagine going further and sharing individual peripheral drivers between HALs, e.g. refactor out the stm32f4xx-hal's SPI driver for stm32f3xx-hal when it happens to be the same, but often there are small and annoying differences between families even when the base IP is very similar. I don't think embedded-hal (or the wg) needs to do much here though: the HAL teams could decide to refactor out peripheral drivers and then use them in each HAL that shares hardware, but ultimately I think the end users are still going to use "the HAL for their MCU", and whether it has its own copy of a driver or re-uses a shared one is immaterial. It's very rare for peripherals to be shared between vendors, so I think this mostly comes down to how the various vendor teams want to organise their HALs rather than needing a wg-wide coordination.

dzarda commented 4 years ago

Thank you for your responses gentlemen. I'm glad my ideas are not new here. Will study the issues linked!