Skip to content

/embedded-hal

A Hardware Abstraction Layer (HAL) for embedded systems
  1. Rust 98.8%
  2. Shell 1.2%
Branch: master
Find File
Clone or download

Clone with HTTPS

Use Git or checkout with SVN using the web URL.

Open in Desktop Download ZIP

Launching GitHub Desktop...

If nothing happens, download GitHub Desktop and try again.

Launching GitHub Desktop...

If nothing happens, download GitHub Desktop and try again.

Launching Xcode...

If nothing happens, download Xcode and try again.

Launching Visual Studio...

If nothing happens, download the GitHub extension for Visual Studio and try again.

@bors @ryankurte
@eldruin @therealprof
4 authors Merge #127 
127: Digital v1 <-> v2 compatibility wrappers and shims r=japaric a=ryankurte

This PR introduces implicit  v1 -> v2 (forward) compatibility, and explicit wrapper types for v2 -> v1 (reverse) compatibility between digital trait versions as a final step for #95, as well as moving the deprecated v1 traits to a re-exported module for clarity.

As @japaric pointed out, it is not feasible to have implicit compatibility in both directions, so it seemed reasonable to make regression explicit as it hides an `.unwrap()` on failure.

@therealprof, @hannobraun, @eldruin what do you think of this approach?
I think it probably needs more documentation, though I am definitely open to suggestions as to what / where.

See also: #100, #92, #102.



Co-authored-by: Ryan Kurte <ryankurte@gmail.com>
Co-authored-by: Diego Barrios Romero <eldruin@gmail.com>
Co-authored-by: Daniel Egger <daniel@eggers-club.de>
Latest commit 264d080 Mar 21, 2019
Permalink
Type Name Latest commit message Commit time
Failed to load latest commit information.
.github tweak bors.toml Aug 12, 2018
ci
src Merge #127 Mar 21, 2019
.gitignore
.travis.yml add CODEOWNERS, CoC; tweak bors and Travis Aug 7, 2018
CHANGELOG.md
CODE_OF_CONDUCT.md
Cargo.toml
LICENSE-APACHE
LICENSE-MIT v0.1.0 Jan 16, 2018
README.md

README.md

embedded-hal

A Hardware Abstraction Layer (HAL) for embedded systems

This project is developed and maintained by the HAL team.

API reference

How-to: add a new trait

This is the suggested approach to adding a new trait to embedded-hal

Discussion

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.

Proposing a trait

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.

Testing period

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-impl and needs-driver to signal what's required for them to move to the set of proven traits.

Implementations and drivers

For a list of embedded-hal implementations and driver crates check the awesome-embedded-rust list.

License

Licensed under either of

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.

You can’t perform that action at this time.