Originally from: http://forum.micropython.org/viewtopic.php?f=6&t=219
With this code:
acc = pyb.Accel()
led = pyb.LED(4)
print(acc.x(), acc.y(), acc.z())
The .x, .y, and .z methods always return the same values. Commenting out the led = pyb.LED(4) line makes it work normally.
I cannot confirm this bug. Putting the above code in a fresh main.py works just fine (with v1.2-15-g951ed9d).
After playing around a bit more, I think that this is really the same thing as #626
I'm guessing that there are subtlties in the delay amount based on the particular HW. I had it to the point where adding any extra code after the pyb.LED() call would make things work, and removing the code would make things fail. But it also didn't seem to be 100% consistent. So my conclusion is that this is timing related to the time between pyb.Accel() and the first call to .x()
Oh yes, there is an "issue" that you must wait a little between initialising the accel, and making the first read. Waiting long enough (whatever that is, need to read the docs on the accel) should be a robust fix.
Do you think we should add a delay in the pyb.Accel() function, to fix this properly (so people don't have the same issue over again)? Of course, that introduces a perhaps unnecessary delay for those that do things between pyb.Accel() and reading...
Or we could time stamp when accel was init'd, and if a read is called too early, we wait. This is much more complex to implement.
Given that we're only talking about 10s of milliseconds, I'd personally be inclined to just make Accel add the delay. If somebody really cared, we could add an option to not delay.
You're most likely only going to call pyb.Accel() once in your code.
I did find one instance where the 20 msec delay was too short, but I couldn't reproduce it. I'd recommend perhaps increasing to 30 msec.
The datasheet says 12ms + 1/ODR (ODR = Output Data Rate) for the "Turnon time Standby to Active" which I interpret as 12ms plus 1 sample time. The default sample rate is 120 samples/second, which corresponds to 8.33 msec, or 20.33 msec total.
Ok, need to change the 20's to 30's, and add a delay right at the end of accel_start.
Since the I2C class is now mature, you can even write your own accel driver in Python. So if people want something better, they can do that.
@dpgeorge - regarding the I2C module, have you had a chance to look at #745 / #746 yet? 16-bit memory addressing is a strict requirement for some devices; I have been using my proposed fix in my project and I don't think it should break existing code. Just wondering if you are still looking for something cleaner or more general. Thanks!
stmhal, accel: Increase start-up times to 30ms; add extra 30ms delay.
For accel to start-up reliably, need to wait 30ms between on/off, and
30ms for it to enter active mode. With this fix the accel can be read
immediately after initialising it.
Addresses issue #763.
Changed 20ms delay to 30ms delay and added an extra 30ms delay at the end of the initialisation.