Daniel Egger

@jcsoo > "Application" covers a lot of territory and could include code on both sides of that boundary. I respectfully disagree. The application (or more commonly called "firmware" in embedded...

Yes, the embedded-hal traits define the interface, they do not actually do anything (well, not a lot) by themselves.

@puzrin Some (most?) MCU have mappable interrupts, e.g. STM32 with the EXTI but that's only a part of my point. When you're using interrupts there's a common set of operations...

EXTI is STM32 specific and thus not a good choice for a trait. The abstraction is not about the interrupt handler calls but the interrupt setup and handling; it would...

I've added a rough cut of my idea here: https://github.com/therealprof/embedded-hal/tree/features/interrupts This is what an exemplary implementation for the `RTC0` interrupt on a NRF51 might look like (of course this should...

> How do you get the peripheral back so that you can call functions on it? I'd compose it into the HAL implementation if necessary. > How do you propose...

@xd009642 I very much like this idea. I also agree with @ryankurte that a watchdog should be disable-able since there are some architectures around that start with watchdog enabled by...

Fair enough.

@df5602 Thanks for your feedback! I don't think this is actually a problem since in the end the application will always be responsible for proper hardware setup and configuration. I...

> But isn't this basically the case now? The current SPI abstraction seems to assume that the CS is a separate entity that can be controlled independently from the SPI....