Dario Nieuwenhuis

Have you seen #4106 ? seems you guys are working on the same thing.

@cbiffle FYI the `stm32-metapac` PAC already supports stm32c0 chips (used in the `embassy-stm32` HAL). Naming of registers there is already consistent across chips. Policy is "consistency across chips first, matching...

yeah, exactly! :) it was born out of the frustration with the patches...

I don't think I2SExt is a "real" peripheral though? just a mode of i2s?

This is a workaround. Missed wakeups should never happen, I would prefer if we found the root cause and fixed it.

i'm going to close this for now, hopefully someone can figure out what's the root cause of the issue :cry:

As you mention, this is a breaking change so it'd have to be released as `embedded-hal v2.0`. Even if upgrading 1.0->2.0 is easy, the real burden is the ecosystem split...

- You mention your rewrite exposes more hardware capabilities, and is more usable/configurable/flexible. Can you show examples? i.e. "with the previous API doing X was annoying/impossible, with the new API...

i'm going to close this since the FDCAN driver has moved forward quite a bit so I don't see a path to getting this merged. Feel free to open issues...

nie :rocket: (note: when this is finished, we probably want the example to live in the trouble repo. I think that's where most of the "API evolution" will be, so...