Making the I2C Master be non blocking

[ammaree]

I am working to port an application from the TI CC3200/TM4C environment to the ESP32 platform.

In the TI environment we used the non blocking I2C Master driver that comes with the TI SenseHub (http://software-dl.ti.com/tiva-c/SW-TM4 ... .4.178.pdf) to provide highly functional non-blocking I2C API to what is actually an average I2C peripheral.

Based on my elementary comparison the level of functionality provided by the ESP32 I2C peripheral far exceed that of the TI components, specifically with the implementation of the hardware FSM. And the ESP32 I2C API seems to make best use of the available hardware functionality.

With our application reading a large number of sensors (up to 15 on a mote) and
# with some of the sensors requiring 2 commands (trigger conversion & read data) spaced ~100mSec apart
# and the user requirement for all sensors to be read at least every 1sec (some every 100mS)
# we are optimising the I2C bandwidth by triggering the commands in a sequence
# with the slowest sensors (conversion) triggered at the start and read at the end of the sequence.

What I am missing is essentially 2 or 3 pieces of functionality to make the I2C driver a dream to work with:
#1 using callbacks, with a specified (void * type ) value to return, at the completion of Read, Write or Read-Modify-Write phases to avoid the task blocking
#2 request queuing layer to buffer multiple sequential requests and execute them in the background, with the callbacks
#3 support for 16 bit type Little and Big Endian sensors at the transaction level.

For the trigger command we essentially do not use the callbacks but for the read commands the callbacks are used to take the raw values from the buffer and store them in predefined locations for use between sensor read intervals.

Any chance that these enhancement (at least #1) could get some urgent consideration?
It would be of huge value to our project.

Thanks

[ammaree]

@ESP_Sprite any comment or suggestion..

[ESP_Sprite]

No, sorry. Callbacks would have to happen from an ISR context, which is very hard to use well. Can I suggest an alternate solution? Especially for the complex case you have here, you would be way better off spinning up a task that handles all the intrinsics of the timing of the I2C requests, and you can then use either callbacks or inter-task-communication primitives (e.g. queues, semaphores, task notification) to communicate the results to the tasks that need it.