With the current setup, both the FT260, FT260_I2C (and future FT260_GPIO,FT260_UART) objects all hold the same hid.device handle. Since they have direct read/write access, the I2C object could be reading and expect an I2C report, but receive a Interrupt or UART report instead.
I've started working on the FT260_GPIO already and hence came across this issue, these are the options I've considered:
- Move all HID read/write functionality into FT260 directly and have it filter/buffer the reports based on report ID for I2C/UART/GPIO/Interrupts. This would fundamentally change the constructor for the other classes, as they would be initialised with an FT260 rather than a hid.device.
- Ignore any report IDs which don't match what is expected at that time. This would mean reports are dropped and could potentially cause issues with interrupts being missed.
I would prefer to go with option one -it would change the FT260_I2C initialisation but would probably be better in the long term if someone (me at the moment) wanted to use both I2C and GPIO Interrupt at the same time.
With the current setup, both the FT260, FT260_I2C (and future FT260_GPIO,FT260_UART) objects all hold the same hid.device handle. Since they have direct read/write access, the I2C object could be reading and expect an I2C report, but receive a Interrupt or UART report instead.
I've started working on the FT260_GPIO already and hence came across this issue, these are the options I've considered:
I would prefer to go with option one -it would change the FT260_I2C initialisation but would probably be better in the long term if someone (me at the moment) wanted to use both I2C and GPIO Interrupt at the same time.