ryan

yeah concurrency is a wee bit tricky, unfortunately i haven't dug into [RTIC](https://rtic.rs) to comment on that part. the best approach for sharing _peripherals_ is [Rahix/shared-bus](https://github.com/Rahix/shared-bus), though there are some...

Ahh, I see you [point](https://github.com/atsamd-rs/atsamd/blob/9f6085584bd5587ae1afac123358299b586c5a9d/hal/src/common/delay.rs#L51)! IMO this seems like a slight oversight on the `Delay` implementation front. In embedded C it's pretty normal to have a `SysTick` interrupt handler that...

> The only guarantee delay provides is that the delay is at least as long as requested. This is a good point and also, somehow viscerally upsetting 🙃 > Would...

hey thanks for the PR! looks pretty good to me. the only question i have is how we define / configure buses of widths that are not an existing (standard...

Also totally onboard with improvements! For anyone else reading, there is related discussion in #64. I've been wondering whether a builder-style API would work, something like `SPI.start().write(&[W]).read(&mut[W]).end()` could support transactions...

@Rahix I like your suggested alteration to @RandomInsano's suggestion, thought the address only makes sense for the i2c implementation anyway I think. I think at the moment I am in...

> @ryankurte: Hmm, unfortunately the builder API can't easily be built ontop of a slice API. The issue is that I cannot transform the builder type (which is recursive) into...

Aha, I thought this was familiar, we've already had this discussion wrt. iterator based SPI which was designed to address part of this issue https://github.com/rust-embedded/embedded-hal/pull/47 (both the linux overhead and...

> read does not take input, so it does not need an iterator. Instead it returns an iterator of bytes. Take a look at the second playground link for clarification...

> I'm sorry I don't follow. You don't see the bus timing anyway, that's why you have to set a speed at the master and let the peripheral work at...