whaleygeek / bitio

A micro:bit I/O device library for Python
Other
92 stars 31 forks source link

Accelerometer not working #25

Closed bcopy closed 4 years ago

bcopy commented 4 years ago

Hi,

I have updated to the bitio.hex provided in the repo, but the accelerometer returns triple zeros.

This sample returns (0,0,0) even when the microbit is moved :

import microbit
while True:
     print(microbit.accelerometer.get_values())
     microbit.sleep(250)

Here's my DETAILS.TXT :

# DAPLink Firmware - see https://mbed.com/daplink
Unique ID: 9901000051864e450xxxxxxxxxxxxxxxxxxxxxxxxxxx
HIC ID: 97969901
Auto Reset: 1
Automation allowed: 0
Overflow detection: 0
Daplink Mode: Interface
Interface Version: 0253
Bootloader Version: 0243
Git SHA: 64359f5c786363065a41ec15c348e3d53568da03
Local Mods: 0
USB Interfaces: MSD, CDC, HID, WebUSB
Bootloader CRC: 0x32eb3cfd
Interface CRC: 0x53375800
Remount count: 1
URL: https://microbit.org/device/?id=9901&v=0253

Any known issues ?

whaleygeek commented 4 years ago

Hi, no known issues (although that is not the same as no issues!)

If you run the same program directly on the microbit using python.microbit.org, what do you see appear at the REPL from the micro:bit (the new web editor now supports WebUSB, so if you are on a recent version of the Chrome browser, you should be able to interact direct with the micro:bit at the repl prompt once connected).

bitio was structured so that mostly you could take a host program and run it unmodified on the actual micro:bit to get near-identical behaviour.

There were a small number of micro:bits with faulty accelerometers that responded in that way, but you should get an error code when the micro:bit boots if that is the case, see...

https://support.microbit.org/support/solutions/articles/19000097285-050

Moving over from the two sensors to the combined sensor highlighted a number of 'older' micro:bits that had broken accelerometers, as the self-test workflow in the latest runtime was more rigorous in order to detect which sensor type was fitted.

Start with the test I suggest above, and do report back.

whaleygeek commented 4 years ago

Also, note that the .hex loaded for bitio is just a bare microPython with a display.show(Image) in it for the bitio logo - the host side python pokes commands directly via a raw REPL over the serial port (a binary safe prompt with deterministic response characteristics, basically).

So if you type 'print(accelerometer.get_values())' at the REPL prompt to a micro:bit loaded with a blank micropython program created by python.microbit.org, you will get the same response (I suspect) as you see in bitio - which might imply a device failure of some sort.

whaleygeek commented 4 years ago

https://github.com/whaleygeek/bitio/issues/23

whaleygeek commented 4 years ago

For completeness, this is the device-side code of bitio, super simple, all the hard work happens at the host end...

from microbit import *

copyright = "bitio (c) 2017 David Whale"

def bitio():
    LOGO = Image("90000:90090:90909:00909:00090")
    display.show(LOGO)

bitio()
print(copyright)
whaleygeek commented 4 years ago

Dragging and dropping bitio.hex into python.microbit.org will show you this code, and then pressing the download button 'bakes in' the latest MicroPython c++ runtime (which supports both older and newer sensor configurations in one image).

bcopy commented 4 years ago

Thanks a lot, it works !