I2C Read/Write functions in GPIO Interrupt

RE: I2C Read/Write functions in GPIO Interrupt

Vidar Berg — Mon, 30 Oct 2023 12:10:33 GMT

Happy to help. Yes, it seems that k_event_* might be more suitable for your situation. The main reason I suggested using a semaphore was its simplicity. However, there are several options available to signal an event from the ISR to your thread.

RE: I2C Read/Write functions in GPIO Interrupt

Phobios — Mon, 30 Oct 2023 11:11:28 GMT

Thanks a lot Vidar for the clarification.

I've a thread anyway, since I have some other heavy duty work to do there so I think I'll go with that. Since I have two ISR GPIO lines, aka two interrupts I'm using k_event_post() and k_event_wait() instead of semaphores. Then I can distinguish which event has occurred. Is there any downside using this; should I go with the semaphore or is it anyway the same procedure in the SDK background (from timing, awake time and battery aspects)

RE: I2C Read/Write functions in GPIO Interrupt

Vidar Berg — Mon, 30 Oct 2023 10:44:17 GMT

Hello Phobios,

[quote user=""]But would't that be way slower that just reading a few registers within the ISR[/quote]

The API initiates the read transaction and doesn't return until the transaction completes, making it more involved than reading some registers. As a result, the blocking time can be relatively long.

The i2c driver is using semaphores with waits to allow the API to be blocking/synchronous, and these cannot be called from an interrupt context.

[quote user=""]How would be the solution to this? I was thinking of using an event which i set in the GPIO interrupt and in a thread I read out the data with I2C functions[/quote]

If you create a separate thread, you can use k_sem_give() from the gpio interrupt to wake-up this thread and perform the burst read. Alternatively, you can create a workqueue item to read the sensor.

Best regards,

Vidar