Multiple I2C slaves on r_iic


I'm sorry to almost duplicate other discussions here.  I could not find anything that was close enough to my problem that I could generalize.

I'm using SSP 1.1.3 on S7G2 based system.  I'm using ThreadX.

I have multiple I2C slaves on riic0.  

To configure, I create multiple instances of the the I2C driver on riic0.  The channel remains the same: 0.  The instance name and slave address change.  Can you confirm this is correct?

Can I use a separate callback for each?  Do I have the option of sharing a callback if that fits my design?




  • Hello Steve,

    Callback functions are instance specific, so even though specific RIIC channel always uses the same ISR's, user callback invoked by them would be specific to what is defined in your configuration. Using multiple instances is a way to go, although I recommend giving I2C Framework a go - it was designed to make multi-slave management easier.

    If you're planning to move to a newer release, SSP 1.2.0 and newer provide slaveAddressSet API to let you re-use single I2C instance to access many slave devices. Change of data rate is not possible without using another instance (and could also lead to problems on the bus).

  • In reply to Renesas Karol:

    Thank you, Karol.

    One follow up question: I was under the impression that the I2C framework did not allow the user to define a callback; that the callback was used by the framework. Am I incorrect?

  • In reply to Steve:

    Hello Steve,

    That's correct. I2C Framework provides its own callback implementation that sets Event Flags which are used by the rest of the code to control the transmission and API behaviour.

  • In reply to Renesas Karol:

    Hi Karol,

    A review of the above since it has been several days: I'm currently using multiple instances of the r_iic0 driver: one per device on that pair of SDA,SCL lines. Do I need to open and close while alternating use of the different instances? Or can I open both instances and leave them open while I read and write with each instance?

    (If I do switch to the framework implementation, are there any known bugs with SSP1.1.3? Sorry, I can't switch to 1.2.x at this time.)

  • In reply to Steve:

    Hi Steve,

    Yes, you should open/close each instance after using the previous one.

  • In reply to adboc:

    Thanks, adboc!

  • In reply to Steve:


    If you switch to the framework I2C you can just open and write/read on each framework device. (assuming that you use a separate framework I2C tree for each slave device, the simplest implementation) The framework will handle using them all at the same time. Just make sure to put a suitable timeout and use the restart=true on the write command that is to be followed directly by a read command for the same device.

    Also I strongly suggest porting to SSP 1.2 or 1.2.1 as there are known I2C bugs with SSP 1.1.3. (high/low periods don't meet spec, etc) It isn't hard to port and we can help you on the forum here.

  • In reply to Bill:

    Thanks, Bill. Good to know.
    I value the recommendation regarding 1.2.1. We came to Synergy only a few months ago; mere weeks before 1.2.0 beta was introduced. Our graphics and touch implementation are atypical and, as too few examples existed for the beta, we did not use it. By the time 1.2.1 was out, schedule pressures dictated the decision to remain at 1.1.3. It was not my call to make. There's a lot more to it, of course, but more than would be of general interest here.