RSL10 - Blocking I2C Driver

Hello RSL10 Community,
The released versions of SDK for RSL10 include non-blocking implementation example of I2C peripheral Driver. (Transmit and Receive Interrupt based handlers)

May I request for a version where the I2C transactions are performed in blocking mode. (Using while() based transactions).


Hi @rajucoolsuraj,

This can be achieved using the built in capabilities of the I2S CMSIS Driver on RSL10.

By reading the status register of the I2C to check if the interface is busy, you can trap execution in a while loop and effectively implement a blocking solution. Please see a code snippet below that demonstrates how to do this in our ‘i2c_cmsis_driver’ sample firmware.

        /* Refresh the watchdog timer */

Hello Brandon,
Thanks for the help.
But, digging deeper into the source code for i2c cmsis driver , it will reveal the mechanism used to transact over I2C.

I want to eliminate use of interrupts for I2C transactions.

Every read and write should be done using only i2c registers while blocking other executions.


Hi @rajucoolsuraj,

For this implementation, you will likely not be able to use the CMSIS I2C Driver as it only supports Interrupt or DMA based I2C transfers.

You will need to perform the entire I2C transaction by interacting with the necessary hardware registers directly.

In this situation, you should use the ‘I2C_STATUS’ hardware register to keep track of the various busy statuses of the I2C transaction.

Thank you so much Brandon.
Have you or others attempted such a implementation.

Would fast track my debugging .

Thanks again.

Hi @rajucoolsuraj,

We do not have a polling version of the I2C Drivers internally. Only versions that use the DMA and Interrupts.

For general setup and configuration you can reference the CMSIS Driver for Interrupts (I2C_RSLxx.c), as it will setup and configure the I2C as necessary prior to a transfer. The difference in your implementation would likely be mostly how the Input/Output registers of the I2C are read or written too, as they will poll the Status registers instead of relying on an interrupt.

Thanks Brandon,
That is the approach planned.
I shall experiment with replacing interrupt callback by a polling function to await status update!