Dario Nieuwenhuis

> async_task::Task would have to be parametrized over the future type and the schedule function type. Not necessarily, what needs to be parametrized is the `StaticTask` that you statically allocate...

:+1: to splitting, this way we can do breaking changes to these without disturbing the main crate. > or some other name, feel free to bikeshed not sure on `-suared`,...

okay, so: There's 2 ways of writing a UART HAL drivers: - **Buffered**: The driver has a reasonably-sized buffer in RAM. Hardware places Incoming bytes are placed into the buffer...

Maybe having a trait for an "ADC device" is not really needed? We could just have this ``` trait AdcChannel fn read(&mut self) -> Result; } ``` If the hardware...

> Now, why do we have a blanket impl for &mut T if the StatefulOutputPin methods only need &self? StatefulOutputPin requires OutputPin, so `impl StatefulOutputPin for &T` would require `impl...

I'd just make baudrate an `u32` (or maybe some `Hertz` concrete type that is in `embedded-hal` that wraps an u32 or something) Having an unconstrained `type BaudRate` seems like the...

I think the `try_` naming is a mistake. 1. It is noisy 2. It is inconsistent with the rest of the Rust ecosystem, therefore unidiomatic. For example, all IO in...

>@therealprof: However there **is** precedence for methods which are using `try_` to differentiate from the previous infallible methods like `try_fold` vs `fold`. As outlined in my previous post, `try_` *would*...

This has been discussed in today's Rust Embedded meeting. ``` Dirbaio: maybe the real question here is "do we want infallible versions of the traits or not" Dirbaio: if yes,...

Perhaps CountDown should be *removed* before 1.0, and added later when fixed then? The current trait is useless in generic drivers, and fixing it is a breaking change. There are...