@aglass0fmilk I was reading again your original post for the virtualization of DigitalIn/Out/etc. here:
It turns out we are in the exact same situation (using the MCP23017 instead of MCP23008). In our case, we have an array of touch sensors and we want to know when each one of them is touched to react to that.
In your second comment, you point to this use-case application:
I’m wondering if you also have an example of use of this library implementing the interface::DigitalIn.
In particular, how do you handle interrupts in on different pins?
I am also interested in this topic. I have been working with I2C expanders and I had integration problems due to Mbed OS non-virtual interfaces. At the end, we decided to integrate them at HAL level to be available from DigitalOut API but there are some interrupt issues which we haven’t resolved yet.
Thanks for your interest in this. I’m glad I’m not the only one who finds this feature useful.
I do not currently have an example of this library implement the interface::DigitalIn.
Interrupts are difficult in this situation because there is an underlying I2C transfer that needs to occur to know which pin is asserting the interrupt. This cannot be done in an interrupt handler as it stands now. It could be possible to eliminate the mutex locks by subclassing the I2C class, but this opens up a lot of potential for thread safety issues. This is only a potential solution if the I2C bus is NOT shared with other devices – which is usually not the case.
I have an example of using the virtualized CAN interface in my library here:
@ladislas If you want to have a call sometime that would be easier to answer your specific questions