|0.2.3||May 9, 2019|
|0.2.3-rc.1||Apr 10, 2019|
|0.2.2||Nov 3, 2018|
|0.2.1||May 14, 2018|
|0.1.0||Jan 16, 2018|
#2 in Embedded development
4,656 downloads per month
Used in 243 crates (228 directly)
A Hardware Abstraction Layer (HAL) for embedded systems
This project is developed and maintained by the HAL team.
This is the suggested approach to adding a new trait to
Ideally, before proposing a new trait, or set of traits, you should create an issue where the use cases and requirements of the trait(s) are discussed.
These issues will be labeled as
discussions in the issue tracker.
Once there's consensus on the requirements of the trait(s) a new issue, or a PR, with a proposal should be opened. The proposal should include the actual trait definitions as well as a link to the issue with previous discussion, if there was one.
If the proposal includes more than one alternative then there should be further discussion to try to single out the best alternative.
These issues / PRs will be labeled as
proposals in the issue tracker.
If there are no objections to the proposal the new trait(s) will land behind the "unproven" Cargo feature and an issue about the new trait(s) will be created. If the proposal includes several alternatives and a single one couldn't be chosen as the best then each alternative will land behind a different Cargo feature, e.g. "alt1" or "alt2".
The traits will undergo a testing period before they move into the set of proven traits. During this period users are encouraged to try to implement the unproven traits for their platforms and to build drivers on top of them. Problems implementing the trait(s) as well as successful implementations should be reported on the corresponding issue.
To leave the unproven state at least two implementations of the trait(s) for different platforms (ideally, the two platforms should be from different vendors) and one generic driver built on top of the trait(s), or alternatively one demo program that exercises the trait (via generic function / trait object), should be demonstrated. If, instead, reports indicate that the proposed trait(s) can't be implemented for a certain platform then the trait(s) will be removed and we'll go back to the drawing board.
Issues used to track unproven APIs will be labeled as
unproven-apis in the issue tracker and they
may also include the labels
needs-driver to signal what's required for them to
move to the set of proven traits.
For a list of
embedded-hal implementations and driver crates check the awesome-embedded-rust
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.
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.