search

RobTillaart / TCA9548

Arduino library for TCA9548 8 channel I2C multiplexer and compatibles.
MIT License
20 stars 7 forks source link

Use in multi master mode #22

Closed Manhem closed 1 week ago

Manhem commented 2 weeks ago

Hi. Can your library work in a multi master mode or how can I detect if the I2C bus is occupied then I try to use it?

RobTillaart commented 2 weeks ago

Thanks for the question,

I have no practical experience with multiple master, and never had it in mind when writing the library.

So the first answer is "no".

How to detect is an interesting question, I dont know and I expect it depends on the I2C library used if these provide the hooks needed.

On AVR (UNO et al) I have never seen related calls in the I2C library, ESP32 which has more resources might have additional functions to support it.

Will have a look if ESP32 has support, might be interesting to try to implement it.

RobTillaart commented 2 weeks ago

How multiple master should work - part 2 of the video

RobTillaart commented 2 weeks ago

From - https://www.i2c-bus.org/multimaster/

There are I2C environments where multiple masters are driving the bus. In such case each device needs to be able to cooperate with the fact that another device is currently talking and the bus is therefore busy.

This translates into:

If you plan to use a multimaster device on a bus it is essential that all masters are multimasters. A single-master is simply a device, which does not understand the above mechanisms. If a singlemaster and a multimaster are connected, the singlemaster may well interrupt the multimaster causing unpredictable results.

@Manhem

So you need to find out if the boards you are using understand arbitration.

An additional problem might occur in case of the multiplexer, as the master that gets the bus should get it twice, First to set the multiplexer and second to write to / read from a device.

Q: which board(s) are you using?

Manhem commented 2 weeks ago

We have develop a board that has a SAMD21G18 CPU as one master. This one is taking care of the PCF9548. On the output from PCF, two of the channels are connected to a XP-pico-sxl. The XT-pico has two I2 buses. Each bus is connected to only one of the outputs in parallell. XT-pico is the other master, also running in multimode. Nothing more is connected on the PCF I2C input, only the CPU.

So it could be good to have your library look at the output to see if it's taken. If it's taken, close the output and give a alarm back to track in the software. Otherwise just send the command.

The XT-pico we have so much controll over. But they have told us that it's going in multimode. (was in the specification we give them)

My software with you library work perfect without the XT-pico. But when I connect the XP-pico it runs for some time and then everything in my program stops.

We have develop a board that has a SAMD21G18 CPU as one master. This one is taking care of the PCF9548. On the output from PCF, two of the channels are connected to a XP-pico-sxl. The XT-pico has two I2 buses. Each bus is connected to only one of the outputs in parallell. XT-pico is the other master, also running in multimode. Nothing more is connected on the PCF I2C input, only the CPU.

So it could be good to have your library look at the output to see if it's taken. If it's taken, close the output and give a alarm back to track in the software. Otherwise just send the command.

The XT-pico we have so much controll over. But they have told us that it's going in multimode. (was in the specification we give them)

My software with you library work perfect without the XT-pico. But when I connect the XP-pico it runs for some time and then everything in my program stops.

What we can see with an analyser, we have a collision on the I2C if the XT-pico send something and then your library also want to send something, then everything crash.

I hope I give you something understandable to work from.

I hope I give you something understandable to work from.

RobTillaart commented 2 weeks ago

So it could be good to have your library look at the output to see if it's taken. If it's taken, close the output and give a alarm back to track in the software. Otherwise just send the command.

If you mean that the library should detect it has been used, that is in theory possible as one can add timestamps to the functions, so one can see when the last moment was it "forwarded" a command to the hardware. The library cannot see which device (processor) send the command, I2C does not have a "sender field", and the library cannot not know for how long the bus will be taken.

As in my previous post, the I2C implementation should support multimaster operations. If it does not you get conflicts. My library does not have control over the I2C hardware, so this is impossible with the PCF9548 library as far as I can think of.

My software with you library work perfect without the XT-pico. But when I connect the XP-pico it runs for some time and then everything in my program stops.

Collision,

What we can see with an analyser, we have a collision on the I2C if the XT-pico send something and then your library also want to send something, then everything crash.

So apparently the I2C driver of one of them (or both) does not support the I2C multimaster collision detection.

I hope I give you something understandable to work from.

A schema (drawing) would be helpful to understand your setup.

Manhem commented 2 weeks ago

Hi. I send you the schema with the part of CPU-PCF9548 and also XT-Pico part. Hope you understand how we have built it and also that you can fix something that can help us. If you have anything you will try, I can do it for you. Please let me know. Schema.pdf

RobTillaart commented 2 weeks ago

Thanks for the schema, Better put a question on the Arduino forum, there are people with more I2C know how than I have.

RobTillaart commented 2 weeks ago

Studied the schema shortly, this is what I understand.

The ATSAM is the primary controller of the PCA9648. The ATSAM can disconnect the PICO completely (select channel > 1) The ATSAM can connect the PICO through channel 0 or channel 1 or both. The ATSAM connects to an I2C_EEPROM (M24M02) The ATSAM can connect to an I2C_DISPLAY (EA_DOGS164W-A) over channel 2

When the PICO is connected it can act either as slave or as master. When the PICO is connected it can send a command to the PCA9648 and (de)select channels When the PICO is connected it can disconnect itself. When the PICO is connected it can access the I2C EEPROM. When the PICO is connected it can enable channel 2 to connect to the I2C DISPLAY.

So far the schema.

Back to your question:

So it could be good to have your library look at the output to see if it's taken.

The library can enable one or more channels.

What do you mean exactly with (1) output and (2) taken?

The ATSAM can set PCA.setForced(true); and then poll the PCA channels selected. However this polling is time consuming. Furthermore it needs access to the I2C bus it is a "master" command which may conflict with the PICO. So we are back to my earlier statement, the processors should support multimaster mode.

Manhem commented 2 weeks ago

Can you send a command from the "outside" to manage the PCF? I was thinking it was only allowed to manage the PCF from the "inside" (on the PCF pin 22 and 23).

RobTillaart commented 2 weeks ago

I was thinking it was only allowed to manage the PCF from the "inside" (on the PCF pin 22 and 23).

Disclaimer, I never tried, but

Hypothesis

Datasheet PCA9548a, chapter 3 The PCA9548A device has eight bidirectional translating switches that can be controlled through the I2C bus.

I interpret that as that the SDA/SCL becomes one I2C bus with SD0/SC1. This means that when e.g. channel 0 is enabled, the I2C EEPROM which is connected to SDA/SCL is visible for the PICO.

Test todo

You can confirm this hypothesis easily by e.g. running an I2C scanner on the PICO after ATSAM enables channel 0.

  1. default all channels disabled

  2. the ATSAM enables channel 0

  3. The I2C bus now consists of (SDA, SCL, SD0, SC0)

  4. The PICO now runs the I2C scanner and it should be able to see the EEPROM and the PCF.

  5. Assuming the PCF is visible, the PICO can send the command PCF.enableChannel(2) to make the display visible.

  6. The I2C bus now consists of (SDA, SCL, SD0, SC0, SD2, SC2)

  7. The PICO now runs the I2C scanner and it should be able to see the EEPROM, the PCF and the DISPLAY.

Give it a try.

Manhem commented 2 weeks ago

The software in XT-pico is not our, but I shall see what I can do or talk to the people that takes care of the XT-pico.

RobTillaart commented 1 week ago

As it is not a problem of the library, I close the issue. Feel free to comment or reopen if new insights pop up.