Merge branch 'master' into prove-inputpin

.github/CODEOWNERS

@@ -0,0 +1 @@
+* @rust-embedded/hal @ilya-epifanov @thejpster

.github/bors.toml

@@ -0,0 +1,4 @@
+block_labels = ["needs-decision"]
+delete_merged_branches = true
+required_approvals = 1
+status = ["continuous-integration/travis-ci/push"]

.travis.yml

@@ -2,8 +2,20 @@ language: rust
 
 matrix:
   include:
+    - env: TARGET=x86_64-unknown-linux-gnu
+      if: (branch = staging OR branch = trying) OR (type = pull_request AND branch = master)
+
+    - env: TARGET=thumbv6m-none-eabi
+      rust: beta
+      if: (branch = staging OR branch = trying) OR (type = pull_request AND branch = master)
+
+    - env: TARGET=thumbv7m-none-eabi
+      rust: beta
+      if: (branch = staging OR branch = trying) OR (type = pull_request AND branch = master)
+
     - env: TARGET=x86_64-unknown-linux-gnu
       rust: nightly
+      if: (branch = staging OR branch = trying) OR (type = pull_request AND branch = master)
 
 before_install: set -e
 
@@ -25,9 +37,9 @@ before_cache:
 
 branches:
   only:
-    - auto
     - master
-    - try
+    - staging
+    - trying
 
 notifications:
   email:

CHANGELOG.md

@@ -7,6 +7,42 @@ and this project adheres to [Semantic Versioning](http://semver.org/).
 
 ## [Unreleased]
 
+## [v0.2.1] - 2018-05-14
+
+### Changed
+
+- Auto-generated documentation (docs.rs) now includes the unproven traits.
+
+## [v0.2.0] - 2018-05-12
+
+### Added
+
+- A `ToggeableOutputPin` trait has been added. This trait contains a single method: `toggle` that
+  can be used to toggle the state of a push-pull pin.
+
+### Changed
+
+- [breaking-change] The signature of `CountDown.wait` changed; it now returns `nb::Result<(),
+  Void>`. Where [`Void`] is the stable alternative to the never type, `!`, provided by the stable
+  [`void`] crate. Implementations of the `CountDown` trait will have to be updated to use the new
+  signature. With this change this crate compiles on the stable and beta channels.
+
+[`Void`]: https://docs.rs/void/1.0.2/void/enum.Void.html
+[`void`]: https://crates.io/crates/void
+
+- [breaking-change] the `OutputPin.is_{low,high}` methods have been moved into its own trait
+  `StatefulOutputPin` and renamed to `is_set_{low,high}`.
+
+- It has been clarified in the documentation that `OutputPin` must be implemented for push-pull
+  output pins (and e.g. not for open drain output pins).
+
+## [v0.1.3] - 2018-05-14
+
+### Changed
+
+- Re-export most / unchanged traits from embedded-hal v0.2.x to allow inter-operation between HAL
+  implementations and drivers that are using different minor versions.
+
 ## [v0.1.2] - 2018-02-14
 
 ### Added
@@ -23,6 +59,8 @@ and this project adheres to [Semantic Versioning](http://semver.org/).
 
 Initial release
 
-[Unreleased]: https://github.com/japaric/embedded-hal/compare/v0.1.2...HEAD
+[Unreleased]: https://github.com/japaric/embedded-hal/compare/v0.2.1...HEAD
+[v0.2.1]: https://github.com/japaric/embedded-hal/compare/v0.2.0...v0.2.1
+[v0.2.0]: https://github.com/japaric/embedded-hal/compare/v0.1.2...v0.2.0
 [v0.1.2]: https://github.com/japaric/embedded-hal/compare/v0.1.1...v0.1.2
 [v0.1.1]: https://github.com/japaric/embedded-hal/compare/v0.1.0...v0.1.1

CODE_OF_CONDUCT.md

@@ -0,0 +1,37 @@
+# The Rust Code of Conduct
+
+## Conduct
+
+**Contact**: [HAL team][team]
+
+* We are committed to providing a friendly, safe and welcoming environment for all, regardless of level of experience, gender identity and expression, sexual orientation, disability, personal appearance, body size, race, ethnicity, age, religion, nationality, or other similar characteristic.
+* On IRC, please avoid using overtly sexual nicknames or other nicknames that might detract from a friendly, safe and welcoming environment for all.
+* Please be kind and courteous. There's no need to be mean or rude.
+* Respect that people have differences of opinion and that every design or implementation choice carries a trade-off and numerous costs. There is seldom a right answer.
+* Please keep unstructured critique to a minimum. If you have solid ideas you want to experiment with, make a fork and see how it works.
+* We will exclude you from interaction if you insult, demean or harass anyone. That is not welcome behavior. We interpret the term "harassment" as including the definition in the [Citizen Code of Conduct](http://citizencodeofconduct.org/); if you have any lack of clarity about what might be included in that concept, please read their definition. In particular, we don't tolerate behavior that excludes people in socially marginalized groups.
+* Private harassment is also unacceptable. No matter who you are, if you feel you have been or are being harassed or made uncomfortable by a community member, please contact one of the channel ops or any of the [HAL team][team] immediately. Whether you're a regular contributor or a newcomer, we care about making this community a safe place for you and we've got your back.
+* Likewise any spamming, trolling, flaming, baiting or other attention-stealing behavior is not welcome.
+
+## Moderation
+
+These are the policies for upholding our community's standards of conduct.
+
+1. Remarks that violate the Rust standards of conduct, including hateful, hurtful, oppressive, or exclusionary remarks, are not allowed. (Cursing is allowed, but never targeting another user, and never in a hateful manner.)
+2. Remarks that moderators find inappropriate, whether listed in the code of conduct or not, are also not allowed.
+3. Moderators will first respond to such remarks with a warning.
+4. If the warning is unheeded, the user will be "kicked," i.e., kicked out of the communication channel to cool off.
+5. If the user comes back and continues to make trouble, they will be banned, i.e., indefinitely excluded.
+6. Moderators may choose at their discretion to un-ban the user if it was a first offense and they offer the offended party a genuine apology.
+7. If a moderator bans someone and you think it was unjustified, please take it up with that moderator, or with a different moderator, **in private**. Complaints about bans in-channel are not allowed.
+8. Moderators are held to a higher standard than other community members. If a moderator creates an inappropriate situation, they should expect less leeway than others.
+
+In the Rust community we strive to go the extra step to look out for each other. Don't just aim to be technically unimpeachable, try to be your best self. In particular, avoid flirting with offensive or sensitive issues, particularly if they're off-topic; this all too often leads to unnecessary fights, hurt feelings, and damaged trust; worse, it can drive people away from the community entirely.
+
+And if someone takes issue with something you said or did, resist the urge to be defensive. Just stop doing what it was they complained about and apologize. Even if you feel you were misinterpreted or unfairly accused, chances are good there was something you could've communicated better — remember that it's your responsibility to make your fellow Rustaceans comfortable. Everyone wants to get along and we are all here first and foremost because we want to talk about cool technology. You will find that people will be eager to assume good intent and forgive as long as you earn their trust.
+
+The enforcement policies listed above apply to all official embedded WG venues; including official IRC channels (#rust-embedded); GitHub repositories under rust-embedded; and all forums under rust-embedded.org (forum.rust-embedded.org).
+
+*Adapted from the [Node.js Policy on Trolling](http://blog.izs.me/post/30036893703/policy-on-trolling) as well as the [Contributor Covenant v1.3.0](https://www.contributor-covenant.org/version/1/3/0/).*
+
+[team]: https://github.com/rust-embedded/wg#the-hal-team

Cargo.toml

@@ -11,7 +11,11 @@ license = "MIT OR Apache-2.0"
 name = "embedded-hal"
 readme = "README.md"
 repository = "https://github.com/japaric/embedded-hal"
-version = "0.1.2"
+version = "0.2.1"
+
+[dependencies.void]
+default-features = false
+version = "1.0.2"
 
 [dependencies.nb]
 version = "0.1.1"
@@ -22,3 +26,6 @@ futures = "0.1.17"
 
 [features]
 unproven = ["nb/unstable"]
+
+[package.metadata.docs.rs]
+features = ["unproven"]

README.md

@@ -2,6 +2,8 @@
 
 >  A Hardware Abstraction Layer (HAL) for embedded systems
 
+This project is developed and maintained by the [HAL team][team].
+
 ## [API reference]
 
 [API reference]: https://docs.rs/embedded-hal
@@ -51,99 +53,12 @@ Issues used to track unproven APIs will be labeled as `unproven-api`s in the iss
 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
-
-These are (WIP) implementations of `embedded-hal` for various platforms. Feel free to send a PR
-adding yours to the list!
-
-You may be able to find even more implementations by searching for the [`embedded-hal-impl`] keyword
-an crates.io. If you publish a `embedded-hal` implementation to crates.io please use that keyword to
-let others more easily find your crate!
-
-[`embedded-hal-impl`]: https://crates.io/keywords/embedded-hal-driver
-
-### Linux
-
-- [`linux-embedded-hal`]. For the Raspberry Pi and other SBC that expose pins with embedded
-  functionality (SPI, I2C, etc.)
-
-[`linux-embedded-hal`]: https://crates.io/crates/linux-embedded-hal
-
-### Nordic
-
-- [`nrf51-hal`]. Check the [`microbit`] crate for examples that can be run on the [micro:bit]
-
-[`nrf51-hal`]: https://crates.io/crates/nrf51-hal
-[`microbit`]: https://crates.io/crates/microbit
-[micro:bit]: http://microbit.org/
-
-### NXP
-
-- [`lpc82x-hal`]
-
-[`lpc82x-hal`]: https://github.com/braun-robotics/rust-lpc82x-hal
-
-### ST Microelectronics
-
-- [`stm32f103xx-hal`]. Contains examples that can be run on the [Blue pill] and similar boards.
-
-[`stm32f103xx-hal`]: https://github.com/japaric/stm32f103xx-hal
-[Blue pill]: wiki.stm32duino.com/index.php?title=Blue_Pill
-
-- [`stm32f30x-hal`]. Check the [`f3`] crate for examples that can be run on the STM32F3DISCOVERY.
-
-[`stm32f30x-hal`]: https://crates.io/crates/stm32f30x-hal
-[`f3`]: https://crates.io/crates/f3
-
-### Texas Instruments
-
-- [`tm4c123x-hal`]
-
-[`tm4c123x-hal`]: https://github.com/thejpster/tm4c123x-hal
+## Implementations and drivers
 
-## Drivers
+For a list of `embedded-hal` implementations and driver crates check the [awesome-embedded-rust]
+list.
 
-These are (WIP) platform agnostic drivers that can be used with any of the above implementations to
-interface all sort of external devices like sensors and actuators. Feel free to send a PR adding
-yours to the list!
-
-You may be able to find even more implementations by searching for the [`embedded-hal-driver`]
-keyword an crates.io. If you publish a driver to crates.io please use that keyword to let others
-more easily find your crate!
-
-- [`l3gd20`]. Gyroscope
-
-[`l3gd20`]: https://crates.io/crates/l3gd20
-
-- [`lsm303dlhc`]. Accelerometer + compass
-
-[`lsm303dlhc`]: https://crates.io/crates/lsm303dlhc
-
-- [`mag3110`]. Magnetometer
-
-[`mag3110`]: https://crates.io/crates/mag3110
-
-- [`mfrc522`].` RFID reader / writer
-
-[`mfrc522`]: https://crates.io/crates/mfrc522
-
-- [`motor-driver`]. Motor drivers like the L298N and the TB6612FNG
-
-[`motor-driver`]: https://github.com/japaric/motor-driver
-
-- [`mpu9250`]. Accelerometer + gyroscope + magnetometer IMU
-
-[`mpu9250`]: https://github.com/japaric/mpu9250
-
-- [`si5351`]. Clock generator
-
-[`si5351`]: https://github.com/ilya-epifanov/si5351
-
-- [`si7021`]. Humidity and temperature sensor
-
-[`si7021`]: https://github.com/wose/si7021
-
-[`embedded-hal-driver`]: https://crates.io/keywords/embedded-hal-driver
+[awesome-embedded-rust]: https://github.com/rust-embedded/awesome-embedded-rust#driver-crates
 
 ## License
 
@@ -160,3 +75,12 @@ 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.
+
+## 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

ci/after_success.sh

@@ -15,6 +15,6 @@ main() {
         echo OK
 }
 
-if [ $TRAVIS_BRANCH = master ]; then
+if [ "$TRAVIS_EVENT_TYPE" == "push" ] && [ "$TRAVIS_BRANCH" == "master" ]; then
     main
 fi

ci/install.sh

@@ -1,7 +1,9 @@
 set -euxo pipefail
 
 main() {
-    return
+    if [ $TARGET != x86_64-unknown-linux-gnu ]; then
+        rustup target add $TARGET
+    fi
 }
 
 main

ci/script.sh

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

src/blocking/i2c.rs

@@ -1,4 +1,9 @@
 //! Blocking I2C API
+//!
+//! Slave addresses used by this API are 7-bit I2C addresses ranging from 0 to 127.
+//!
+//! Operations on 10-bit slave addresses are not supported by the API yet (but applications might
+//! be able to emulate some operations).
 
 /// Blocking read
 pub trait Read {
@@ -17,7 +22,7 @@ pub trait Read {
     /// Where
     ///
     /// - `ST` = start condition
-    /// - `SAD+R` = slave address with 8th bit set to 1
+    /// - `SAD+R` = slave address followed by bit 1 to indicate reading
     /// - `SAK` = slave acknowledge
     /// - `Bi` = ith byte of data
     /// - `MAK` = master acknowledge
@@ -43,13 +48,29 @@ pub trait Write {
     /// Where
     ///
     /// - `ST` = start condition
-    /// - `SAD+W` = slave address with 8th bit set to 0
+    /// - `SAD+W` = slave address followed by bit 0 to indicate writing
     /// - `SAK` = slave acknowledge
     /// - `Bi` = ith byte of data
     /// - `SP` = stop condition
     fn write(&mut self, addr: u8, bytes: &[u8]) -> Result<(), Self::Error>;
 }
 
+/// Blocking write (iterator version)
+#[cfg(feature = "unproven")]
+pub trait WriteIter {
+    /// Error type
+    type Error;
+
+    /// Sends bytes to slave with address `addr`
+    ///
+    /// # I2C Events (contract)
+    ///
+    /// Same as `Write`
+    fn write<B>(&mut self, addr: u8, bytes: B) -> Result<(), Self::Error>
+    where
+        B: IntoIterator<Item = u8>;
+}
+
 /// Blocking write + read
 pub trait WriteRead {
     /// Error type
@@ -68,11 +89,11 @@ pub trait WriteRead {
     /// Where
     ///
     /// - `ST` = start condition
-    /// - `SAD+W` = slave address with 8th bit set to 0
+    /// - `SAD+W` = slave address followed by bit 0 to indicate writing
     /// - `SAK` = slave acknowledge
     /// - `Oi` = ith outgoing byte of data
     /// - `SR` = repeated start condition
-    /// - `SAD+R` = slave address with 8th bit set to 1
+    /// - `SAD+R` = slave address followed by bit 1 to indicate reading
     /// - `Ii` = ith incoming byte of data
     /// - `MAK` = master acknowledge
     /// - `NMAK` = master no acknowledge
@@ -84,3 +105,25 @@ pub trait WriteRead {
         buffer: &mut [u8],
     ) -> Result<(), Self::Error>;
 }
+
+/// Blocking write (iterator version) + read
+#[cfg(feature = "unproven")]
+pub trait WriteIterRead {
+    /// Error type
+    type Error;
+
+    /// Sends bytes to slave with address `addr` and then reads enough bytes to fill `buffer` *in a
+    /// single transaction*
+    ///
+    /// # I2C Events (contract)
+    ///
+    /// Same as the `WriteRead` trait
+    fn write_iter_read<B>(
+        &mut self,
+        address: u8,
+        bytes: B,
+        buffer: &mut [u8],
+    ) -> Result<(), Self::Error>
+        where
+        B: IntoIterator<Item = u8>;
+}