Ship a 1.0 release

[thejpster]

Part of rust-embedded/wg#383

Settled blockers:

• WIP: Re-organising repo #169 (closed for later consideration)
• [RFC] Changing the way we handle addition/changes to the traits #163
• [RFC] Use core language async primitives instead external crates #172
• [RFC] digital::v3 interface + moving to a single interface
• Use nb 1.0 #234
• Consider improving watchdog API using move semantics #98 PR: Improve watchdog API design using move semantics #222
• PwmPin: allow get_duty to return the old value for some time #140
• Support 7-bit and 10-bit I2C addressing #147 PR: Make I2C compatible with multiple address sizes #230
• Change reference implementation to something more maintained #156
• ADC API does not allow non-unit channels #110
• Creating abstractions over Pwm trait is not ideal #244 PR: Swap PWM channel argument to pass by reference #246
• Turn traits and execution model modules inside out #298
• Capture trait requires moving/copying channel argument #249
• [RFC] Revamp Error types #229 PR: Add error traits for communication interfaces #296
• Pwm enable and disable methods only work for channels #182 PR: Add methods to enable/disable the entire timer #183
• spi: add Read and separate-buffers Transfer #287
• u8 as default SPI Word #321
• SPI: split into device/bus, allows sharing buses with automatic CS #351
• spi: allow impls returning early, add flush.  #365
• Alternative SPI word lengths: add default SPI word types #320
• IoPin trait not practical to implement with multiple input/output types #340
• Extract SPI exclusive device into shared crate #398
• It's not clear when can::ErrorKind::Acknowledge should be returned #387
• Split nb and can traits to separate crates. #394
• WIP: I2C bus/device. #392
• delay: make infallible. #432
• I2c: simplify, expand docs, document shared bus usage. #440
• spi: make SpiDevice transaction take an operation slice instead of a closure. #443
• bus/i2c: add RefCell, CriticalSection and Mutex shared bus implementations. #445
• I2C transaction_iter should take an iterator of mutable references #367
• SPI implementation doesn't follow embedded-hal requirements for CS linux-embedded-hal#87 discussed in WG meetings, we decided we're OK with the solutions in SPI implementation doesn't follow embedded-hal requirements for CS linux-embedded-hal#87 (comment)
• serial: add ReadExact, ReadUntilIdle #349
• New embedded-io release #480
• Migration page #283 PR: Add initial version of migration guide #284
• Update changelogs #482
• Document defmt feature #483
• spi: add settings to embedded-hal-bus SpiDevice impls for CS-to-clock delays. #539 docs in spi: document Operation::DelayNs is not for CS delays. #559, will add CS delays to embedded-hal-bus later.
• RFC: rename DelayNs to Delay #541
• Document SemVer hazards of spi::Operation::DelayNs #552
• Clarify flushing/"blocking" behavior #455

Open blockers:

• gpio: require &mut self in InputPin and StatefulOutputPin. #547
• Revert "gpio: require &mut self in InputPin and StatefulOutputPin" #553 ?
• Release v1.0.0 #555
• Show that MCU and linux implementations work fine
• Show that drivers can work fine with the new changes
• Your issue here!

Feel free to nominate issues also by commenting below

[jamesmunns]

Here is a link to the video call discussion had by myself and most of the members of @rust-embedded/hal team. This includes initial decisions made, and justification/reasoning for each point. The next steps for this would be to codify this into an RFC, and get approval for it (though there is already general consensus within the embedded-hal team).

by the way, this was the "issue with the list of big topics" we were looking for during the meeting :)

[eldruin]

I believe the only unresolved issue as of the list above is #172
I would also add the dependency on rust-embedded/nb#20
Then we need to think about the dev-dependencies which are at the moment stm32f3 and futures. I guess specially these will hold us back for a while.

[Disasm]

This async story began just recently and I do not expect it to end in the coming year. Why should we block on it? We can always add this later. In the worst case, these async traits will be released in embedded-hal v2.0.0.

[therealprof]

I also think we should keep async separate because it's a different paradigm and might need require a different approach anyway. I can imagine taking an approach similar to async-std vs std, i.e. have the async traits in a separate crate async-embedded-hal which would allow crates to move indepedently and express more clearly what is supported where.

[ryankurte]

i have mixed feelings about async being separate in the long term, but imo it very much depends whether we can find an approach (as is the case for one of the demonstrated ones) that allows everything to be a default impl on top of our base nb or poll traits as we have now with the blocking default methods, so we have one source of truth for integration, simplify the job of hal implementers, and you'll always have access to both. Or if these introduce fundamentally incompatible requirements and must be managed separately. this, however, is not something we can conclusively tell afaik.

i posed here (#172 (comment)) that if we have a path towards a decision on the nb/futures swap I would be okay to hold, but so long as it's an open / unknown problem I would also prefer to keep moving and accept integrating async may be another breaking change down the line.

(i would also very much like to hear the thoughts of @japaric if ya have a moment to look at all of this)