Possible reason for i2c communications to fail?

[jimrh]

Greetings!

I have noticed a number of topics, and messages within topics, that discuss the problems encountered while trying to maintain successful communication with various i²c devices.

Today I took a look at the datasheet for the Texas Instruments TCA9548A, 1 to 8 i²c buss multiplexer and noticed the following points of fact:

1. There are two possible communications modes using i²c:
   • “Standard” mode, which uses a 100kHz clock.
   • “Fast” mode, which uses a 400kHz clock.
      
2. The maximum capacitance of the entire buss path, including parts, wiring, PCB traces, pins, Acts of God, (etc.), is 400pF when running in “fast” mode.

Viz.: Taken from the Texas Instruments TCA9548A datasheet: (which I have attached)
tca9548a.pdf.txt (2.9 MB) (remove the “.txt” at the end)

The maximum bus capacitance for an I²C bus must not exceed 400 pF for fast-mode operation.  The bus capacitance can be approximated by adding the capacitance of the TCA9548A, Cio(OFF), the capacitance of wires, connections and traces, and the capacitance of each individual slave on a given channel.  If multiple channels are activated simultaneously, each of the slaves on all channels contribute to total bus capacitance.

It is important to note that 400pF is a very small value; casual body/finger capacitance can easily exceed that.

If we take into account the length of the Grove connector wires, insulation, proximity to each other and other parts of the 'bot/circuit/chassis, the ultimate length of all this wiring and the PCB traces, the fact that one single i²c port can be, and often is, shared among a number of devices, and so on, (etc.), I would not be surprised if the total wiring and circuit capacitance was in the significant fractions of a μF range. (1μF = 1,000,000pF)

It should also be noted that 400kHz is considered part of the medium-wave radio spectrum, just below the AM broadcast band.  (The intermediate frequency for a standard AM receiver is 455kHz, and the actual AM broadcast band starts at 535kHz.)  Though abysmally slow by today’s multi-giga-hertz standards, it’s still a high frequency and demands out attention and respect.

This leads me to wonder which i²c mode is being used by the Raspberry Pi in general, and the Dexter software in particular. . .

Also, is this selectable?  Can devices like the IMU or GPS operate at “standard” mode frequencies?  Maybe this is something worth investigating?

Though we know that the Raspberry Pi appears to have problems with clock-stretching, is it possible that circuit capacitances could be screwing up rise and fall times to make things even worse?

[cyclicalobsessive]

Fast mode is for “fast cars and fast w…”. I haven’t found either around the GoPiGo.

You are tilting windmills.

[jimrh]

@cyclicalobsessive

You are tilting windmills.

That wasn’t my intention.

Unfortunately I have not done a lot of research about i²c on the Pi/GoPiGo.

What I do know about the Pi is:

1. Later versions of the Pi, especially the Pi-4, have seriously beefed up hardware.
2. Versions later than the initial Pi-1 have dedicated controllers for things like USB and i²c, presumably using DMA to communicate.  Even version 1 Pi’s had a dedicated USB controller - though relatively lame.  I don’t remember about the i²c controller, but I think it was dedicated hardware in the chipset too.
3. Since the GPU is able to generate reasonably high-resolution HDMI, we have to assume that the GPU has a certain amount of “oomf!” itself - perhaps even more than the main processor!
4. The GPU, when not fully loaded, is used to help off-load some of the processing tasks, especially computational tasks.

The result of all this is the potential for, (at the very least), some versions of the Pi to be able to support “fast-mode” i²c communication.  If it doesn’t, than I stand corrected.

Since I believed it possible, and I noticed the article about fast-mode i²c being picky, I thought I’d share it.

Sorry if I confused anyone.

[cyclicalobsessive]

@jimrh

potential for, (at the very least), some versions of the Pi to be able to support “fast-mode” i2c communication.

Fast-mode is for real-time systems. RPi running a non-RT OS should not be asked to excel at RT tasks. Suggesting you will be much happier and more productive to forget about all the what-ifs of the world. (But, hey, I should probably have kept the “my opinion” part of this to me-self. Shoot me. I’m going for a run now in the 87 deg mid-day sun, so nobody should listen to me for good advice.)

[jimrh]

@cyclicalobsessive

I’m going for a run now in the 87 deg mid-day sun, so nobody should listen to me for good advice

Fuggeddaboutit!  Your advice is always good.

We don’t always see things eye-to-eye, or have the same vision for our robots, (no pun intended!), but that’s what makes it interesting!

I’m just glad that you wrote this before going for a run in 87°sun.  I shudder to think what it would have been like afterwards!

P.S.
Stay hydrated and don’t forget a hat!