An update on the HAL front.
I have now published (on GitHub) the cortex-m-hal crate which contains a
Hardware Abstraction Layer (HAL), in the form of a bunch of traits, for the
following peripherals / functionality:
- Input Capture
- Pulse Width Modulation
- Quadrature Encoder Interface
- Serial Peripheral Interface (SPI)
- Serial (UART) interface
- Timer / timeouts
Along with a reference implementation in the form of the blue-pill crate,
which I believe has the most complete API build on top of a device crate
generated via svd2rust. That crate also contains a bunch of examples.
The key points of this HAL are:
It's fully non-blocking but it's not tied to a particular asynchronous
model. You can easily adapt it to operate in blocking mode, or to work with
futures, or to work with an async / await model. All this magic is done via
the nb crate so check out that crate documentation too. That nb crate even
has an await! implementation, which doesn't work right now because generators
have not landed in the language, but that macro lets you do cooperative
multitasking in a cleaner way than if you would have used the futures
crate.
It's minimal to make it easy to implement and keep it as zero cost as
possible. The main idea is have enough of an API to erase device specific
details like registers but let you build higher level abstractions
with minimal overhead. Want a blocking read with timeout semantics? Just compose
the Serial and Timer abstractions using a generic function.
The ultimate goal of this HAL is code reuse. I know people have different
opinions about how an embedded program should be structured (e.g. cooperative
tasks vs event-driven tasks vs threads) and will want to use different
higher level abstractions tailored for their needs. What I want to see is that
those abstractions get built on top of this HAL instead of seeing everyone
rewrite very similar register manipulation code to build those abstractions.
I'd love to get some feedback. I have opened a bunch of issues in the
cortex-m-hal issue tracker where you can leave comments about each
particular trait. The HAL also needs more testing across devices to make sure
it's generic enough to be implemented for devices from different vendors so let
me know if can or can't implement this HAL for some device.