Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
javl opened this issue Dec 14, 2013 · 3 comments
Open

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

javl opened this issue Dec 14, 2013 · 3 comments

Comments

@javl
Copy link

javl commented Dec 14, 2013

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
Copy link

lurch commented Dec 16, 2013

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
Copy link
Author

javl commented Dec 17, 2013

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
Copy link

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. ;)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants