Skip to content

Release on crates.io #25

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
hannobraun opened this issue Nov 29, 2017 · 2 comments · Fixed by #27
Closed

Release on crates.io #25

hannobraun opened this issue Nov 29, 2017 · 2 comments · Fixed by #27

Comments

@hannobraun
Copy link
Member

What's currently blocking the release of this crate on crates.io? One obvious blocker is that nb is not yet published there. I've opened an issue there too.
@hannobraun hannobraun mentioned this issue Nov 29, 2017
Closed
@japaric
Copy link
Member

japaric commented Dec 1, 2017

What's currently blocking the release of this crate on crates.io?

We are missing digital I/O traits (I smuggled in an OutputPin trait while no one was looking, though) and those are like the most common kind of I/O.

I'd like to see a resolution to RFC #18 so we can define the module hierarchy in this crate. (Or perhaps the blocking / higher level traits should be in a different crate, IDK)

We need to figure out some way to indicate the stability of the traits (IDK if #[unstable] is now available for user libraries) so we can distinguish between "this is our first stab at an abstraction for this peripheral, anything goes" and "we are 50%+ sure this abstraction won't suffer a breaking change the next week". We could use a non-default "unstable" Cargo feature; put all the unstable API behind that feature and reserve the right to break that unstable API in patch releases.

@hannobraun
Copy link
Member Author

Thanks for the info!

We need to figure out some way to indicate the stability of the traits (IDK if #[unstable] is now available for user libraries)

It doesn't seem to be. There's an open issue.

We could use a non-default "unstable" Cargo feature; put all the unstable API behind that feature and reserve the right to break that unstable API in patch releases.

I think that sounds like a workable solution.

@japaric japaric mentioned this issue Jan 11, 2018
Merged
japaric pushed a commit that referenced this issue Jan 16, 2018
@homunkulus
Auto merge of #27 - japaric:v1, r=japaric
28bfba1 
[RFC] v0.1.0 release

## Motivation

We want to get some traits out to encourage people to write more driver crates, generic crates that
interface external components, using these traits.

IMPORTANT A v0.1.0 does *not* mean we are going to stop adding new traits. It also does *not* mean
that we are stuck forever with the traits we already have; we can still tweak the existing traits
provided a good rationale to do so is presented.

## Detailed design

This RFC proposes releasing as "stable" all the traits that have been proved useful in building
proof of concept driver crates.

The other traits will be released as "unstable". They'll be hidden behind the "unstable" Cargo
feature.

Stable traits:

- `PwmPin`
- `Timer`
- `blocking::delay::Delay{Ms,Us}`
- `blocking::i2c::{Read,Write,WriteRead}`
- `blocking::spi::{Transfer,Write}`
- `serial::{Read,Write}`
- `digital::{OutputPin}`
- `spi::{FullDuplex}`

These have been proved viable in the reference implementation, [`stm32f30x-hal`], and several generic
drivers: [`mpu9250`], [`l3gd20`], [`lsm303dlhc`], [`mfrc522`], [`tb6612fng`]

[`stm32f30x-hal`]: https://github.com/japaric/stm32f30x-hal
[`mpu9250`]: https://github.com/japaric/mpu9250
[`l3gd20`]: https://github.com/japaric/l3gd20
[`lsm303dlhc`]: https://github.com/japaric/lsm303dlhc
[`mfrc522`]: https://github.com/japaric/mfrc522
[`tb6612fng`]: https://github.com/japaric/tb6612fng

Unstable traits:

- `Capture`
- `Pwm`
- `Qei`

The rationale of these being unstable is in the crate source code.

## Unresolved questions

- Should `OutputPin::is_{low,high}` be renamed to `OutputPin::is_output_{low,high}` to prevent a
  potential collision with a future `InputPin` trait that provides similarly named methods?

Now it's your chance to bikeshed all the names and the module hierarchy to your heart content.

## Changes in this PR

- Added `Default` marker traits as per #18 (comment)
- Blocking I2C traits
- Delay traits
- All doc tests have been unignored.
- The traits mentioned above have been feature gated

closes #25

cc @hannobraun @ahixon
peckpeck pushed a commit to peckpeck/embedded-hal that referenced this issue Nov 10, 2022
@bors @eldruin
Merge rust-embedded#26
0d7a4ad 
26: Transactional WriteRead r=ryankurte a=eldruin

This fixes rust-embedded#25 by implementing a transactional write-read without STOP in the middle.
It also fixes a type cast which was the only warning present.

Co-authored-by: Diego Barrios Romero <eldruin@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

[RFC] v0.1.0 release rust-embedded/embedded-hal
2 participants
@hannobraun @japaric