0

I'm running a Pi B+ rev 1.2 and recently acquired 2 I2C modules:

DS-RGBW.S LED lighting DS-RGBW.S LED lighting picture

Microstack accelerometer: Microstack accelerometer

When connecting the LED module, address 70 appears to be occupied as planned. I modify the script to use SMBus(1) instead of SMBus(0). Script runs, but no response. When terminating the script, python claims to have been at line 96, time.sleep(000.1). None of the lights have been on. The 48VDC terminal is not used, but I'm not sure it's even supposed to be used. Attached to pin 3/4/5/6 as shown on the diagram given by the supplier.

So, ok. It might be from a bad batch, so I hooked up the accelerometer. I don't have the baseboard, but it fits just fine without (on pin 1/3/5/7/9/11)(leaving the 4+2 pins not connected). But now I i2cdetect -y 1 shows an empty address table.

Yes, I did reboot after installing all required dependencies and yes all required configurations have been modified. I'm running the latest software on the latest Raspbian. How should I debug my I2C trouble? Anyone experience with problems like these?

If any pertinent information is missing, please comment.

Update:

Script called is from this zip file as stated in the product manual. /RGBW.S_Disk/R-PI/RGBW.py

# Designer Systems DS-RGBW LED Lighting Shield Raspberry-PI Demonstrator

# Requires Raspberry-PI A or B board

# DS-RGBW.S [A0 & A1 jumpers ON] connected to I2C interface (GPIO pin 3 SDA, pin 5 SCL)

# RGBW.py   Date: 13/7/13   Version: 1.00 

# Run from LX terminal window using 'sudo python RGBW.py

# Fades WHITE up/down, outputs a number of RGB colours and then cycles through colour wheel

# Note: May require I2C setup procedure on R-PI

# Use CTRL+C to exit


# import modules needed for this application
import smbus
import time

# NOTE: THE ZERO IN THE COMMAND BELOW MAY NEED CHANGING TO A '1' DEPENDING ON THE RASPBERRY PI USED
bus = smbus.SMBus(1)

# Define DS-RGBW.S I2C address
address = 0x70

# Routine to write to I2c register from DS-RGBW.S
def writeRegister (register, value):
    bus.write_byte_data(address, register, value)

# Routine to write to I2c,define registers
def writeRGBWregisters (red, green, blue):
    bus.write_byte_data(address,3,red)
    bus.write_byte_data(address,4,green)
    bus.write_byte_data(address,5,blue)

# Routine to write to i2c, define registers
def writeHSBregister (hue,saturation,brightness):
    bus.write_byte_data(address,6,hue)
    bus.write_byte_data(address,7,saturation)
    bus.write_byte_data(address,8,brightness)

# Main program
while True:

# All off 
    bus.write_byte_data(address,2,0)
    bus.write_byte_data(address,3,0)
    bus.write_byte_data(address,4,0)
    bus.write_byte_data(address,5,0)

# Fade white LED from 0 to 99%   
for data in range(0,99):    
    writeRegister(2,data)
            time.sleep(0.01)

# Fade white LED from 99 to -1 
for data in range(99,-1,-1):    
    writeRegister(2,data)
            time.sleep(0.01)

# Sleep 2 second
    time.sleep(2)

# Send RGBW colour (Pink)      
    writeRGBWregisters(255,88,67)             

# Sleep 2 second
    time.sleep(2)

# Send RGBW colour (Green)
    writeRGBWregisters(48,187,80)      

# Sleep 2 seconds       
    time.sleep(2)

# Send RGBW colour (Orange)
    writeRGBWregisters(243,99,20)

# Sleep 2 second
    time.sleep(2)

# Send RGBW colour (Dark Purple)
    writeRGBWregisters(86,54,80)

# Sleep 2 seconds
    time.sleep(2)

# Set colour wheel to start colour   
    writeHSBregister(0,255,255)

# Rotate though complete colour wheel by changing HSB Hue value     
    for hue in range(0,255):
           writeRegister(6,hue)
           time.sleep(000.1)

# Sleep 2 seconds
    time.sleep(2)

Update 2:

Re-flashed the RPi with a fresh install. It's still not working as expected, but now I get the following for i2cdetect -y 1 with the RGBW connected:

     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          __ __ __ __ __ __ __ __ __ __ __ __ __
10: __ __ __ __ __ __ __ __ __ __ __ UU __ __ __ __
20: __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __
30: __ __ __ __ __ __ __ __ __ __ __ UU __ __ __ __
40: __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __
50: __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __
60: __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __
70: 70 __ __ __ __ __ __ __

The UU weren't there before at 1b and 3b. They're also there when nothing is connected.

Mast
  • 139
  • 14
  • "If any pertinent information is missing, please comment" -> What script are you talking about?!? All I see here are two photographs and some references to i2cdetect, which is a compiled executable. – goldilocks Mar 24 '15 at 01:45
  • @goldilocks Added. – Mast Mar 24 '15 at 07:59
  • did you add the i2c line in /boot/config.txt ? see http://raspberrypi.stackexchange.com/questions/27073/firmware-3-18-x-breaks-i2c-spi-audio-lirc-1-wire-e-g-dev-i2c-1-no-such-f – Tommy Trussell Mar 24 '15 at 14:05
  • @TommyTrussell Yes, dtparam i2c_arm/i2c1/spi are all on. – Mast Mar 24 '15 at 21:06
  • OK I just got it working myself. You have to activate the i2c stuff in /boot/config.txt AND add the modules to /etc/modules – Tommy Trussell Mar 25 '15 at 16:59
  • @TommyTrussell I'm not sure why, but that didn't do the trick for me. I might go for a fresh install to make sure I didn't mess something up in the meantime, but without any way to debug what exactly is wrong it's still stabbing in the dark. – Mast Mar 25 '15 at 17:15
  • [I guess I can't format in comments] I was trying to show what I have in my /etc/modules – Tommy Trussell Mar 25 '15 at 19:24
  • Yes I see the UUs sometimes, too -- it means the driver has detected a (potential) conflict at that spot and skipped probing it. The man page says "this strongly suggests there's a chip at this address." You do have one at address 70 -- is that where you expect it? If not, you may want to look for a driver conflict such as http://www.raspberrypi.org/forums/viewtopic.php?f=44&t=81750 or http://jeelabs.org/book/1452c/ – Tommy Trussell Mar 26 '15 at 19:49
  • Yes, 70 is as expected. There's no reason to assume the device uses more than that address. – Mast Mar 27 '15 at 07:35

2 Answers2

2

I had the same problems (and the UU's are not the accelerometer, they are there on mine too). I'd given up on this when persistence got the better of me and I came across this: https://github.com/microstack-IoT/python3-microstacknode/issues/1

You may be one of the lucky people that got one of the 'couple' of boards made without the connection between pin 2 and 3 on JP1.

Missing connection.

You need to bridge this connection (I stuck a bent staple in the holes, but soldering may be better)!

Matthew
  • 71
  • 5
0

Here's what I did to get my i2c device to work. I followed the hints in Firmware 3.18.x breaks I2C, SPI, audio, lirc, 1-wire (e.g. /dev/i2c-1, No such file or directory)

Here's my /etc/modules

$ cat /etc/modules
# /etc/modules: kernel modules to load at boot time.
#
# This file contains the names of kernel modules that should be loaded
# at boot time, one per line. Lines beginning with "#" are ignored.
# Parameters can be specified after the module name.

snd-bcm2835
i2c-dev
i2c-bcm2708

(The snd-bcm2835 module was already in my /etc/modules file.)

As for /boot/config.txt for whatever reason the line added by raspi-config for i2c did NOT work so I commented it out.

$ cat /boot/config.txt     
#dtparam=i2c_arm=on
dtparam=i2c1=on 
Tommy Trussell
  • 281
  • 1
  • 6
  • 1
    I suspect at least one of the dtparam lines is superfluous (not needed) but I am not sure. – Tommy Trussell Mar 25 '15 at 19:40
  • I can't imagine you need all of those indeed. However it should work, but it did not fix my problem. – Mast Mar 25 '15 at 20:32
  • You might try disconnecting all the add-on boards and seeing if the situation changes. I just tried it on mine, and the i2cdetect command still runs, it just doesn't show anything. ... never mind I just saw where you have already done that. – Tommy Trussell Mar 25 '15 at 20:43
  • ALSO be sure you have run apt-get update and apt-get upgrade -- that's the first thing I did this morning. – Tommy Trussell Mar 25 '15 at 20:43
  • It's the first thing I did when noticing it didn't work. I probably should've mentioned that somewhere, but I expected that to be superfluous. – Mast Mar 25 '15 at 21:01
  • after tinkering some more I have determined that for my i2c device (a PiFace LCD display board) I don't need all the lines so I am removing the dtparam=spi and dtparam=i2s lines from my example above. I am sorry it hasn't been helpful. – Tommy Trussell Mar 25 '15 at 21:16
  • It's still not working, but see update 2: for the promised update. – Mast Mar 26 '15 at 16:47