TCA9517: Multi master across the device.

Hey David,

In terms of following the allowed connections between TCA9517s, what you have listed in your system would work.

Now the catch here is, do all of your masters support arbitration? (In their software/library for I2C, can they tell when another master is trying to take control of the bus at the same time as itself?) The other concern here is, even if they do support multi master arbitration, there is some prop delays between the TCA9517 which make arbitration timing tricky.... the worst case is when master1 and master3 want to try to communicate at the same time, the communication needs to pass through 2 different 9517s which will have 100s of nano seconds of delay between the two. My opinion on this is, it is unreliable if you only use arbitration alone.

You may need to add some kind of way for all 3 masters to be able to tell who can take control of the bus. This can be handle through software.

Another way, could be using an I2C switch with interrupts which a main master can have control of the switch on the main SDA/SCL lines and the sub masters can request access through driving the INT line low. (TCA9543A, TCA9544A, TCA9545A  for example).

"Can anyone confirm that my use-case is supported by this device? Or reccommend an alternative?"

An alternative is to have a master Arbiter device on the bus to handle arbitration. Unfortunately, this is something we do not have in our portfolio currently.

-Bobby

Hi Bobby,

Thanks for the thorough reply.

All the masters in the system to support arbitration, but you do highlight an issue with the propogation delay that would become even more an issue with arbitrary extensions to this system. 

I will have to look into the arbitration schemes of the masters to see how this could be permuted with software, as this would be the least cumbersome to implement in our system. Do you have any reccommendations as far as implementing a software fix goes?

The I2C switches you present are very interesting in their operation but unfortunately with the way I2C is distributed in out system this (or a master arbiter device) would prove quite difficult to implement. Another open-drain signal could be shared between all the devices however and used for software master arbitration (similar to the INT pin is used in the I2C switches) but this would also require isolation to some degree so the propogation delay issue is likely to rear its head agian.

Cheers,

David

Hi Bobby,

Looking again at the datasheet for the TCA9517, it doesn't mention arbitration support anywhere. Whereas the deprecated PCA9517 does say that it will support it. Is this becasue of the proogation delay issues that you mentioned?

Thanks,

David

Hey David,

"Do you have any reccommendations as far as implementing a software fix goes?"

I don't have too much experience on this portion. Any solution I can think of revolves around hardware in which the masters share an open drain channel. The only other solution I can think of is to have a dedicated master which could talk to other slave masters to give them control of the bus every so often and when the slave masters are finished, they communicate back to the dedicated master that they aren't using the I2C bus anymore. I can't think of an efficient way to do this otherwise...

"Looking again at the datasheet for the TCA9517, it doesn't mention arbitration support anywhere.Whereas the deprecated PCA9517 does say that it will support it. Is this becasue of the proogation delay issues that you mentioned?"

The TCA9517 doesn't handle arbitration directly (neither does the PCA9517) but simply will pass the High to Low signal from either side. In terms of prop delays, I would expect the TCA9517 to be a bit better since the TCA family uses a newer process.

-Bobby