If you want a very concrete example to hang your hat on: making the I2C driver interrupt driven was a snap -- and importantly, can easily be done from a library, where the caller merely provides functions to call to enable a specified interrupt and to synchronously wait for interrupts.[0]
Looks interesting! Though I noticed the bit about the Konami code. The terminology is great, but alas it feels like I've run into as many i2c devices that break the i2c protocol as follow it. Ahem, I'd recommend avoiding Infineon I2C devices to keep your sanity. ;)
Reading the code, is it correct to say the ISR will timeout if the device doesn't respond? It's nice the driver returns the state of the bus locking in the error `Err(drv_i2c_api::ResponseCode::BusLocked);`. Makes me curious how you're doing that. I need to find timeout watch the video.
Yes, it will timeout if the device doesn't respond, thanks to the timeout logic in the STM32H7's I2C block.[0] If the block didn't have that logic, Hubris would still make it relatively easy to do that, though, as one would just perform the closed receive for the interrupt or a timer notification. (An example of a closed receive on a timer can be found at [1].)
[0] https://github.com/oxidecomputer/hubris/blob/01b5af3d54348ba...