1

The scripts and the results mostly speak for themselves. smbus returns good data when I use the standard I2C GPIO pins, but the pigpio bit banging I2C returns what looks like random data.

What might I try to debug this?

note: I didn't forget to move the SDL and SCA leads to the appropriate pins. Using 3.3V to supply the DS3231 Real Time Clock.


smbus works. When I convert these back from BCD to ints, I get a reasonable time object, with seconds increasing at 1 Hz.

import smbus
import pigpio
from binascii import hexlify

ADDR    = 0x68
start   = 0x00
nbytes  = 7
baud    = 9600

bus = smbus.SMBus(1)

pi = pigpio.pi()

for i in range(3):
    seven_bytes = bus.read_i2c_block_data(ADDR, start, nbytes)
    print "seven_bytes: ", seven_bytes
pi.stop()

"""  RETURNS
seven_bytes:  [24, 9, 21, 1, 19, 3, 24]
seven_bytes:  [24, 9, 21, 1, 19, 3, 24]
seven_bytes:  [24, 9, 21, 1, 19, 3, 24]
"""

pigpio bb returns random bytes.

import pigpio
from binascii import hexlify

ADDR    = 0x68
start   = 0x00 # unused
nbytes  = 7
baud    = 9600 # have tried several
SDA     = 4
SCL     = 17

pi = pigpio.pi()
pi.set_pull_up_down(SDA, pigpio.PUD_UP)
pi.set_pull_up_down(SCL, pigpio.PUD_UP)
pi.bb_i2c_open(SDA, SCL, baud)

for i in range(3):
    count, data = pi.bb_i2c_zip(SDA, [4, ADDR, 2, 6, nbytes, 3, 0])
    print "count, hexlify(data): ", count, hexlify(data)
pi.bb_i2c_close(SDA)
pi.stop()

"""  RETURNS
count, hexlify(data):  7 004184bba180b9
count, hexlify(data):  7 1c8b001ac01218
count, hexlify(data):  7 15011303180041
"""

edit 1: per @Joan's comment:

pigs, the socket interface to pigpio also returns random bytes. The following are the pigs equivalents to bb_i2c_open, bb_i2c_zip, and bb_i2c_close. All bytes are non-repeating.

pi@raspberrypi:~ $ pigs bi2co 4 17 9600
pi@raspberrypi:~ $ pigs bi2cz 4 4 0x68 2 6 7 3 0
7 187 161 128 185 28 139 0
pi@raspberrypi:~ $ pigs bi2cz 4 4 0x68 2 6 7 3 0
7 25 128 71 25 22 1 19
pi@raspberrypi:~ $ pigs bi2cz 4 4 0x68 2 6 7 3 0
7 3 24 0 65 132 187 161
pi@raspberrypi:~ $ pigs bi2cc 4

Or reading only once and close/open just to see what happens:

pi@raspberrypi:~ $ pigs bi2co 4 17 9600
pi@raspberrypi:~ $ pigs bi2cz 4 4 0x68 2 6 7 3 0
7 65 132 187 161 128 185 28
pi@raspberrypi:~ $ pigs bi2cc 4

pi@raspberrypi:~ $ pigs bi2co 4 17 9600
pi@raspberrypi:~ $ pigs bi2cz 4 4 0x68 2 6 7 3 0
7 139 0 25 192 80 7 22
pi@raspberrypi:~ $ pigs bi2cc 4

pi@raspberrypi:~ $ pigs bi2co 4 17 9600
pi@raspberrypi:~ $ pigs bi2cz 4 4 0x68 2 6 7 3 0
7 1 19 3 24 0 65 132
pi@raspberrypi:~ $ pigs bi2cc 4

edit 2: per @Joan's answer (not finished posting results, test in progress):

Using smbus:

seven_bytes:  [1, 2, 3, 4, 5, 6, 7]
seven_bytes:  [8, 9, 10, 11, 12, 13, 14]
seven_bytes:  [15, 16, 16, 16, 16, 16, 16]

Using pigpio:

count, data:  7 
  hexlify(data):  01020304050607
count, data:  7     
  hexlify(data):  08090a0b0c0d0e
count, data:  7 
  hexlify(data):  0f101010101010
  • @joan I don't understand, what is pigs? Oh I found the link, let me give it a try! – uhoh Mar 19 '18 at 22:25
  • @joan very nifty! ;-) Unfortunately still random, but wow, very happy to learn something new. – uhoh Mar 19 '18 at 22:43
  • @joan I'm a little confused on the correct sequence when including those two now. First bi2co, then those two, then bi2cz, bi2cc? – uhoh Mar 19 '18 at 23:00
  • 1
    My mistake, Python works fine, I had introduced an error into a new module I am working on. – joan Mar 20 '18 at 8:56
1

There are various debug steps you can take.

  1. bit bang on the hardware I2C GPIO. If it works for SMBus then it should work with bit bang. It eliminates wiring and the pull-ups being a problem.
  2. use pigs to implement the code. If that works that would suggest the Python module is faulty. pigs bi2co 4 17 9600 then pigs bi2cz 4 4 0x68 2 6 7 3 0
  3. Switch on internal pigpio daemon debugging and try to trace the Python execution. pigs csi 4 then cat /dev/pigerr& to see the trace.
  4. Use the Pi's slave I2C bus to emulate the device. To do this connect the SDA GPIO to GPIO 18 and the SCL GPIO to GPIO 19. Use the command pigs bscx 0x680305 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 to set the slave as I2C address 0x68 and load the FIFO with 1 to 16. Then run the Python code and you should see byte values 1 to 16 (then 16 repeatedly) being returned.

In this case I suspect 1. will work as I expect the weak (50k) internal pulls are not good enough for the I2C bus.

  • Thanks! I'll take these out for a spin and see what happens. #1 does sound really possible. I'll have some other I2C devices to rotate through later tonight as well. This is extremely helpful, thanks! – uhoh Mar 20 '18 at 9:25
  • The 50k pullups are well beyond sufficient. They are closer to being to high if you want to go above 400kHz than anything else. Also keep in mind, that slave devices often carry their own pullups, lowering the overall resistance on the bus for every slave connected. – mystery Mar 20 '18 at 12:51
  • absurd life delay, will do this today! (yes, delay due to absurd life, not absurd delay...) – uhoh Mar 29 '18 at 19:11

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.