Feature request: I2C interrupt handling

[kmatch98]

Following on the previous discussion regarding interrupts, I am considering how to improve display response to capacitive touchscreen events.

I am considering whether it is [useful, possible] to create an event queue for I2C interrupt events.

I don't know anything about interrupt handling in CircuitPython, or CircuitPython does event scheduling, so this is just a first attempt at proposing a behavior and structure. I'm open to feedback, suggestions, clarification about what it will take to implement and the challenges to be faced.

Here's my basic thoughts on how it would work for a capacitive touchscreen:

My desired usage: I want to access a time-stamped list of touchscreen events [x, y, touch status (touch down, still-touched, touch up)].
I will pop off an touchscreen event from the queue and respond to it with a graphical change on the display (for example, reposition a rectangle on the screen).

Definition:

• A pin to watch for interrupts
• Define trigger polarity (rising, falling or state-change)
• An I2C address and command to request the data
• Define how to decode the returned data and stuff it into a time-stamped Event Queue data structure
• Maximum number of elements in the Event Queue's ring buffer
• Define overflow behavior (stop when full, or wrap around with the latest data)

Action:

1. When the interrupt pin triggers, CircuitPython queues an I2C data request.
2. I2C data is requested (is this scheduled?).
3. I2C data is received.
4. Data is parsed and stuffed into the Event Queue for use on the Python side.

Event Queue elements:

• Time stamp
• Decoded data structure (dict?)
• Overflow flag
• Functions or data:
  • get max length
  • get current length
  • empty?
  • overflow?
  • pop data off the queue

[tannewt]

This will be tough because the user code could also be accessing I2C at the same time.

[kmatch98]

Hmm.. does this mean that the I2C code would have to be rewritten to schedule the communications?

[tannewt]

You can probably do it using a lock where the background code will wait until user code isn't using I2C.