This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

I2C in multimaster mode

I am working on a system with dual Bluetooth chips one acts as primary and the other as secondary.

image description

I want these two communicate with a shared resource(Accelrometer) via I2C independently. But as per datasheet NRF51822 can not have a MultiMaster I2C. Is there any way to do it via soft I2C implementation? Both nRF51822also communicate with each other to send some command and share status information.

Parents
  • Hi

    Maybe this can be done, but it will be a very complex implementation.

    1. TWI Slave: If you want to communicate between two nRF51s then one will have to act as a master and the other as a slave. Unfortunately the nRF51 does not have hardware support for TWI slave mode. Hence, you will need to make a software implementation for the TWI slave (I'm not aware of any software TWI slave examples).

    2. Code complexity: If you want both chips to be able to initiate a transfer to accelerometer both will have to implement the TWI master functionality. Furthermore, since you want the nRF51s to talk to each other then at least one will need slave functionality as well. If you want both nRF51s to be able to initiate a transmission to the other nRF51 then both nRF51s will need both a slave and master implementation. Case in point, a lot of code and a lot of things that might go wrong.

    3. Flow control: Since you want both nRF51s to be able to act as a master you will need some sort of flow control. Since flow control is not usually used in the TWI protocol there is no hardware support for this either. So again you will have to implement something in software.

    4. Software TWI and Softdevice: Running a Softdevice concurrently with a software TWI implementation is difficult due to strict timing requirements. The Softdevice will regularly seize complete control over the nRF51 and corrupt any and all ongoing software TWI transfers.

    A couple of solutions:

    1. Use the nRF52. It has hardware support for two instances of both master and slave TWI.
    2. Use SPI between the nRF51s to ease the burden of the TWI implementation.
Reply
  • Hi

    Maybe this can be done, but it will be a very complex implementation.

    1. TWI Slave: If you want to communicate between two nRF51s then one will have to act as a master and the other as a slave. Unfortunately the nRF51 does not have hardware support for TWI slave mode. Hence, you will need to make a software implementation for the TWI slave (I'm not aware of any software TWI slave examples).

    2. Code complexity: If you want both chips to be able to initiate a transfer to accelerometer both will have to implement the TWI master functionality. Furthermore, since you want the nRF51s to talk to each other then at least one will need slave functionality as well. If you want both nRF51s to be able to initiate a transmission to the other nRF51 then both nRF51s will need both a slave and master implementation. Case in point, a lot of code and a lot of things that might go wrong.

    3. Flow control: Since you want both nRF51s to be able to act as a master you will need some sort of flow control. Since flow control is not usually used in the TWI protocol there is no hardware support for this either. So again you will have to implement something in software.

    4. Software TWI and Softdevice: Running a Softdevice concurrently with a software TWI implementation is difficult due to strict timing requirements. The Softdevice will regularly seize complete control over the nRF51 and corrupt any and all ongoing software TWI transfers.

    A couple of solutions:

    1. Use the nRF52. It has hardware support for two instances of both master and slave TWI.
    2. Use SPI between the nRF51s to ease the burden of the TWI implementation.
Children
No Data
Related