WIP: Re-organising repo

Cargo.toml

@@ -1,28 +1,10 @@
-[package]
-authors = [
-  "Jorge Aparicio <[email protected]>",
-  "Jonathan 'theJPster' Pallant <[email protected]>"
+[workspace]
+members = [
+	"embedded-hal",
+	"embedded-hal-delay",
+	"embedded-hal-digital",
+	"embedded-hal-i2c",
+	"embedded-hal-serial",
+	"embedded-hal-spi",
+	"embedded-hal-timer",
 ]
-categories = ["asynchronous", "embedded", "hardware-support", "no-std"]
-description = " A Hardware Abstraction Layer (HAL) for embedded systems "
-documentation = "https://docs.rs/embedded-hal"
-edition = "2018"
-keywords = ["hal", "IO"]
-license = "MIT OR Apache-2.0"
-name = "embedded-hal"
-readme = "README.md"
-repository = "https://github.com/rust-embedded/embedded-hal"
-version = "0.2.3"
-
-[dependencies.nb]
-version = "0.1.1"
-
-[dev-dependencies]
-stm32f3 = { version = "0.8", features = ["stm32f303", "rt"] }
-futures = "0.1.17"
-
-[features]
-unproven = ["nb/unstable"]
-
-[package.metadata.docs.rs]
-features = ["unproven"]

README.md

@@ -4,54 +4,9 @@
 
 This project is developed and maintained by the [HAL team][team].
 
-## [API reference]
+## Repository Layout
 
-[API reference]: https://docs.rs/embedded-hal
-
-## 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 `discussion`s 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 `proposal`s 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-api`s 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.
+This repository is a workspace containing multiple crates. The top-level crate is [`embedded-hal`](./embedded-hal), which pulls in the various other HAL crates at stable revisions. If you want the bleeding-edge, you can depend on one of the other HAL crates separately.
 
 ## Implementations and drivers
 

ci/install.sh

@@ -4,6 +4,7 @@ main() {
     if [ $TARGET != x86_64-unknown-linux-gnu ]; then
         rustup target add $TARGET
     fi
+    rustup component add rustfmt
 }
 
 main

ci/script.sh

@@ -2,11 +2,8 @@ set -euxo pipefail
 
 main() {
     cargo check --target $TARGET
-    cargo check --target $TARGET --features unproven
-
-    if [ $TRAVIS_RUST_VERSION = nightly ]; then
-        cargo test --target $TARGET --features unproven
-    fi
+    cargo test --target $TARGET
+	cargo fmt -- --check
 }
 
 main

embedded-hal-delay/Cargo.toml

@@ -0,0 +1,15 @@
+[package]
+name = "embedded-hal-delay"
+version = "1.0.0-rc1"
+authors = ["Rust Embedded Working Group <[email protected]>"]
+edition = "2018"
+categories = ["gpio", "embedded", "hardware-support", "no-std"]
+description = " A busy-waiting delay Hardware Abstraction Layer (HAL) for embedded systems "
+documentation = "https://docs.rs/embedded-hal-delay"
+keywords = ["hal", "delay", "busy-wait"]
+license = "MIT OR Apache-2.0"
+readme = "README.md"
+repository = "https://github.com/rust-embedded/embedded-hal"
+
+[dependencies]
+nb = "0.1"

embedded-hal-delay/README.md

@@ -0,0 +1,91 @@
+# `embedded-hal-delay`
+
+>  A Hardware Abstraction Layer (HAL) for busy-waiting on embedded systems
+
+This project is developed and maintained by the [HAL team][team]. This crate may contain unstable functionality - the stable API is exposed in the [`embedded-hal`](https://crates.io/crates/embedded-hal) crate.
+
+## [API reference]
+
+[API reference]: https://docs.rs/embedded-hal-delay
+
+## How-to: add a new trait
+
+This is the suggested approach to adding a new trait to `embedded-hal-delay`
+
+### 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 `discussion`s 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 `proposal`s in the issue tracker.
+
+### Testing period
+
+If there are no objections to the proposal the new trait(s) will land in this
+crate 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 are exported from the
+top-level `embedded-hal` crate. 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-api`s 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.
+
+[awesome-embedded-rust]: https://github.com/rust-embedded/awesome-embedded-rust#driver-crates
+
+## License
+
+Licensed under either of
+
+- Apache License, Version 2.0 ([LICENSE-APACHE](LICENSE-APACHE) or
+  http://www.apache.org/licenses/LICENSE-2.0)
+- MIT license ([LICENSE-MIT](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][CoC], the maintainer of this crate, the [HAL team][team], promises to
+intervene to uphold that code of conduct.
+
+[CoC]: CODE_OF_CONDUCT.md
+[team]: https://github.com/rust-embedded/wg#the-hal-team

embedded-hal-delay/src/lib.rs

@@ -0,0 +1,33 @@
+//! Delays
+//!
+//! # What's the difference between these traits and the `timer::CountDown` trait?
+//!
+//! The `Timer` trait provides a *non-blocking* timer abstraction and it's meant to be used to build
+//! higher level abstractions like I/O operations with timeouts. OTOH, these delays traits only
+//! provide *blocking* functionality. Note that you can also use the `timer::CountDown` trait to
+//! implement blocking delays.
+
+#![deny(missing_docs)]
+#![no_std]
+
+/// Blocking traits
+pub mod blocking {
+
+    /// Millisecond delay
+    ///
+    /// `UXX` denotes the range type of the delay time. `UXX` can be `u8`, `u16`, etc. A single type can
+    /// implement this trait for different types of `UXX`.
+    pub trait DelayMs<UXX> {
+        /// Pauses execution for `ms` milliseconds
+        fn delay_ms(&mut self, ms: UXX);
+    }
+
+    /// Microsecond delay
+    ///
+    /// `UXX` denotes the range type of the delay time. `UXX` can be `u8`, `u16`, etc. A single type can
+    /// implement this trait for different types of `UXX`.
+    pub trait DelayUs<UXX> {
+        /// Pauses execution for `us` microseconds
+        fn delay_us(&mut self, us: UXX);
+    }
+}

embedded-hal-digital/Cargo.toml

@@ -0,0 +1,14 @@
+[package]
+name = "embedded-hal-digital"
+version = "1.0.0-rc1"
+authors = ["Rust Embedded Working Group <[email protected]>"]
+edition = "2018"
+categories = ["gpio", "embedded", "hardware-support", "no-std"]
+description = " A digital GPIO pin Hardware Abstraction Layer (HAL) for embedded systems "
+documentation = "https://docs.rs/embedded-hal-digital"
+keywords = ["hal", "IO", "gpio"]
+license = "MIT OR Apache-2.0"
+readme = "README.md"
+repository = "https://github.com/rust-embedded/embedded-hal"
+
+[dependencies]

embedded-hal-digital/README.md

@@ -0,0 +1,92 @@
+# `embedded-hal-digital`
+
+>  A Hardware Abstraction Layer (HAL) for driving a General-Purpose
+>  Input/Output (GPIO) peripheral on embedded systems
+
+This project is developed and maintained by the [HAL team][team]. This crate may contain unstable functionality - the stable API is exposed in the [`embedded-hal`](https://crates.io/crates/embedded-hal) crate.
+
+## [API reference]
+
+[API reference]: https://docs.rs/embedded-hal-digital
+
+## How-to: add a new trait
+
+This is the suggested approach to adding a new trait to `embedded-hal-digital`
+
+### 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 `discussion`s 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 `proposal`s in the issue tracker.
+
+### Testing period
+
+If there are no objections to the proposal the new trait(s) will land in this
+crate 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 are exported from the
+top-level `embedded-hal` crate. 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-api`s 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.
+
+[awesome-embedded-rust]: https://github.com/rust-embedded/awesome-embedded-rust#driver-crates
+
+## License
+
+Licensed under either of
+
+- Apache License, Version 2.0 ([LICENSE-APACHE](LICENSE-APACHE) or
+  http://www.apache.org/licenses/LICENSE-2.0)
+- MIT license ([LICENSE-MIT](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][CoC], the maintainer of this crate, the [HAL team][team], promises to
+intervene to uphold that code of conduct.
+
+[CoC]: CODE_OF_CONDUCT.md
+[team]: https://github.com/rust-embedded/wg#the-hal-team