romilly / quick2wire-python-api

Python API for controlling GPIO and I2C devices connected to the Raspberry Pi
Other
290 stars 103 forks source link

i2c.py, ValueError, out of range 0-256 in writing_bytes #49

Open javl opened 10 years ago

javl commented 10 years ago

Not sure what causes this problem, but I'd though it might be useful to at least post an issue report. I tried using the quick2wire library with a cheap accelerometer by running the following code:

from i2clibraries import i2c_adxl345
adxl345 = i2c_adxl345.i2c_adxl345(0)

But immediately I get the following error:

Traceback (most recent call last):
  File "./test1.py", line 6, in <module>
    adxl345 = i2c_adxl345.i2c_adxl345(0)
  File "/home/pi/projectfolder/i2clibraries/i2c_adxl345.py", line 100, in __init__
    self.setActivityThreshold()
  File "/home/pi/projectfolder/i2clibraries/i2c_adxl345.py", line 178, in setActivityThreshold
    self.setOption(self.ActivityThreshold, intervals)
  File "/home/pi/projectfolder/i2clibraries/i2c_adxl345.py", line 230, in setOption
    self.bus.write_byte(register, options)
  File "/home/pi/projectfolder/i2clibraries/i2c.py", line 14, in write_byte
    writing_bytes(self.addr, *bytes))
  File "/home/pi/projectfolder/quick2wire-python-api/quick2wire/i2c.py", line 97, in writing_bytes
    return writing(addr, bytes)
  File "/home/pi/projectfolder/quick2wire-python-api/quick2wire/i2c.py", line 108, in writing
    buf = bytes(byte_seq)
ValueError: bytes must be in range(0, 256)

Printing these values, I noticed at least one of them indeed isn't in this range: -3

As a quick hack I changed the function in i2c.py so it clamps the values in byte_seq before returning the message, after which everything works perfectly.

def writing(addr, byte_seq):
    lst = list(byte_seq)
    for i in range(0, len(lst)):
        lst[i] = max(0, min(255, lst[i]))
    byte_seq = tuple(lst)
    buf = bytes(byte_seq)
    return _new_i2c_msg(addr, 0, create_string_buffer(buf, len(buf)))
lurch commented 10 years ago

IMHO your 'quick hack' is only hiding the bug, not fixing it ;-) Sounds to me like the real bug is that something in i2c_adxl345.py is passing in the value of -3 to an i2c function when it shouldn't be.

javl commented 10 years ago

That's why I called it a 'quick hack', not a fix ;) It might help others that run into this problem (I was using the latest NOOBS Raspbian raspberry pi image, like a lot of other people).

malkowski commented 10 years ago

Looks like the actual bug is in the way the i2c_adxl345 library handles negative accelerometer values during initialization. I bet if you flipped your accelerometer upside down and ran your code again, it would work ;) At least that's what I found.

I'd say the way the quick2wire API handles this error is great -- the stack trace points out the exact point of failure, once a bit of logging is added to figure out where the rogue value is coming from.

As to the problem you're seeing though, I just ran into the same issue and can offer a couple pointers that may help. I had to set the offset on my accelerometer, since it didn't actually report 1g when sitting on a flat surface. (See the datasheet for the correct register, or the source code of i2c_adxl345.py, though it's not implemented fully.) I also modified i2c_adxl345.py and changed lines from "if intervals < 256" to "if 0 < intervals < 256", which is hacky, but "if intervals < 256" is already a bit hacky...so... there you have it. Hopefully that helps, even if it's totally off topic. ;)