da1a4d5dbb
398: Extract SPI exclusive device into shared crate r=Dirbaio a=eldruin Some concerns have been raised regarding the error handling in `spi::blocking::ExclusiveDevice`. I am not sure what the problem was, though. I think `@GrantM11235` was the one to raise the concerns so maybe he can elaborate and then I can improve this description. Since that struct is just a helpful wrapper for a very specific situation, I propose we move it out of `embedded-hal` itself. For example into an `embedded-hal-shared` crate (or some other name, feel free to bikeshed). We should note that we (probably) have the same problem in `embedded-hal-async` where there is also an `ExclusiveDevice` for SPI, so if we create such a crate, we should agree on what to put in there: 1. Only blocking `ExclusiveDevice` 2. blocking + async `ExclusiveDevice` 3. any of the above + `RefCell`-based sharing 4. any of the above + some mutex / critical section We should also note that the great `shared-bus` crate also solves some of these problems so we might also put (some?) of this there. cc: `@Rahix` Co-authored-by: Diego Barrios Romero <eldruin@gmail.com>
embedded-hal
A Hardware Abstraction Layer (HAL) for embedded systems
This project is developed and maintained by the HAL team.
API reference
Scope
embedded-hal serves as a foundation for building an ecosystem of platform agnostic drivers.
(driver meaning library crates that let a target platform interface an external device like a digital
sensor or a wireless transceiver).
The advantage of this system is that by writing the driver as a generic library on top
of embedded-hal driver authors can support any number of target
platforms (e.g. Cortex-M microcontrollers, AVR microcontrollers, embedded Linux, etc.).
The advantage for application developers is that by adopting embedded-hal they can unlock all
these drivers for their platform.
embedded-hal is not tied to a specific execution model like blocking or non-blocking.
For functionality that goes beyond what is provided by embedded-hal, users are encouraged
to use the target platform directly. Abstractions of common functionality can be proposed to be
included into embedded-hal as described in this guide, though.
See more about the design goals in this documentation section.
Releases
At the moment we are working towards a 1.0.0 release (see #177). During this process we will
release alpha versions like 1.0.0-alpha.1 and 1.0.0-alpha.2.
Alpha releases are not guaranteed to be compatible with each other.
They are provided as early previews for community testing and preparation for the final release.
If you use an alpha release, we recommend you choose an exact version specification in your
Cargo.toml like: embedded-hal = "=1.0.0-alpha.8"
See this guide for a way to implement both an embedded-hal 0.2.x
version and an -alpha version side by side in a HAL.
Documents
Implementations and drivers
For a non-exhaustive list of embedded-hal implementations and driver crates check the
awesome-embedded-rust list.
You may be able to find even more HAL implementation crates and driver crates by searching for the
embedded-hal-impl, embedded-hal-driver and embedded-hal keywords
on crates.io.
Minimum Supported Rust Version (MSRV)
This crate is guaranteed to compile on stable Rust 1.54 and up. It might compile with older versions but that may change in any new patch release.
See here for details on how the MSRV may be upgraded.
License
Licensed under either of
- Apache License, Version 2.0 (LICENSE-APACHE or http://www.apache.org/licenses/LICENSE-2.0)
- MIT license (LICENSE-MIT or http://opensource.org/licenses/MIT)
at your option.
Contribution
Unless you explicitly state otherwise, any contribution intentionally submitted for inclusion in the work by you, as defined in the Apache-2.0 license, shall be dual licensed as above, without any additional terms or conditions.
Code of Conduct
Contribution to this crate is organized under the terms of the Rust Code of Conduct, the maintainer of this crate, the HAL team, promises to intervene to uphold that code of conduct.