Mbed-os: I2C Asynch -> Schedule transfer in callback

[AGlass0fMilk]

Description

- Type: Question

Question

I'm trying to write an asynchronous read function for a sensor (Silicon Labs Si7006). I found some slightly old example code that schedules another asynchronous I2C transfer during the first event's callback. This allows a single call to get the temperature and humidity readings from the device asynchronously.

See the library code here (https://os.mbed.com/teams/SiliconLabs/code/SILABS_RHT/)

Ironically I found this while reading an article "Using the mbed asynchronous APIs"

While writing unit tests for my driver, I get a Mutex error. I've narrowed it down to the fact that the I2C::transfer call tries to lock a mutex, which isn't allowed in an ISR context (which the callback is executing in?)

Is there a way I can schedule another I2C transfer during the first transfer's callback without relying on user code/thread context? I'm aware of the events library but it seems like a lot of code to pull in for an I2C device driver.

[0xc0170]

lock/unlock methods are virtual. Your driver can overwrite them. Thus you can handle your use case via own methods that can use different synchronization.

This brought me to the SPI implementation that has implemented transaction queue. It's async version actually is only interrupt safe (not thread safe) - not completely (I can see transaction handling is protected there, but not calling HAL functions like start transfer and others).

Should async methods be interrupt safe only? Based on the answer, we might fix I2C or SPI (to use the same synchronization for async).

@c1728p9 @bulislaw @jamesbeyond @scartmell-arm Can you please review?
[Mirrored to Jira]

[pilotak]

I would be interested in that too. I wrote a library to communicate with external I2C ADC using Async functions but ended up with Events to deal with timing.
[Mirrored to Jira]

[AGlass0fMilk]

I like the idea of I2C thread safety, but it would be nice to be able to queue multiple asynchronous I2C transactions that are triggered by the asynch callback.
[Mirrored to Jira]

[adbridge]

Internal Jira reference: https://jira.arm.com/browse/IOTCORE-296

[ciarmcom]

Thank you for raising this issue. Please note we have updated our policies and
now only defects should be raised directly in GitHub. Going forward questions and
enhancements will be considered in our forums, https://forums.mbed.com/ . If this
issue is still relevant please re-raise it there.
This GitHub issue will now be closed.