Saturday, 24 August 2013

The need for speed - I2C bus

When designing the high-integrity I2C bus for InterPi (and later, MegaBoard Pi), I simply followed the guidance of the NXP (previously Philips) application note AN10441 which says that the bidirectional level shifter can be used for both Standard-mode (up to100 kbit/s) or in Fast-mode (up to 400 kbit/s) I2C-bus systems.  Today, I have conducted some tests to explore the limits of the system.

Test Conditions:
  • Raspberry Pi Model B Rev 2 with Raspbian (current)
  • InterPi (one of the PiCocktails conjoined series)
  • Quick2Wire I2C Port Extender (operating at 5V)
  • 5V I2C bus pullups provided by Tiny RTC module
  • Quick2Wire short ribbon cable
  • Room temperature 
Caution:  Do NOT connect a Tiny RTC or Quick2Wire I2C Port Extender (operating at 5V) to a Quick2Wire Interface board.
Test Method:
Using the new diagnostic and test program, which can be downloaded from here, the program was exercised a number of times while increasing the bus speed until the onset of I/O errors.  The bus speed was altered by use of the following commands (with variations) that remove the I2C module and then add it with the desired speed characteristic:
    sudo modprobe -r i2c_bcm2708
    sudo modprobe i2c_bcm2708 baudrate=1200000

Test Result:
Operation up to 1.2 Mbits/s was quite solid and operation at higher speeds failed consistently.

It would seem that the NXP engineers' claim of 400 kbits/s is a conservative one , as one might expect, and that InterPi's high integrity I2C bus architecture can be expected to deliver high performance so long as bus compatibility and capacitance issues are suitably managed.

I did consider incorporating some redundancy into the program to perform read corroboration and read after write verification but decided not to do so because there is limited potential to overcome the fundamental weaknesses in the MCP23017 control protocol.  Because the MCP23017 does nothing to verify its received commands, it is vulnerable to single bit errors that can cause it to:
  • read from an erroneous register address (read corroboration can help),
  • write to an erroneous register address (very nasty),
  • perform a read instead of a requested write (write verification can help), or
  • perform a write instead of a requested read (nasty)
Multiple bit errors can cause even greater mayhem.

These weaknesses argue for a conservative approach when deciding on the I2C bus clock speed. 

1 comment: