Project ideas, help & support, general electronics and software engineering discussions
but I'm having an issue
I'm running the following code
inp = 0x01
for i, pin in enumerate(board.pins[10:18]):
print(pin)
pin.digital_value = bool(inp & (1<<i))
inp = 0x01
for i, pin in enumerate(board.pins[10:18]):
print(pin)
pin.digital_value = bool(inp & (1<<i))
I have pins 10 to 17 hooked up to my logic analyser
I expect 0x01 to be output
but instead I get 0x00
if I output 0x05
same problem
however, if I output 0x10, I get 0x18
0x20 outputs 0x24
0x40 outputs 0x42
0x80 outputs 0x81
so clearly, the lower nibble is being ignored, and the upper nibble is being mirrored to the lower half of the byte
Pin 10: Digital push-pull, False
Pin 11: Digital push-pull, False
Pin 12: Digital push-pull, False
Pin 13: Digital push-pull, False
Pin 14: Digital push-pull, False
Pin 15: Digital push-pull, False
Pin 16: Digital push-pull, True
Pin 17: Digital push-pull, False
(that's for 0x40)
so it looks like this might be a firmware bug
@jeremyherbert, this sounds like an old bug. What firmware version are you running? I don't (yet) have a Python API for accessing firmware version, but your operating system can tell you the revision of the device. In Windows Device Manager:
with Linux,
dmesg should list the revision when you first attach the device
in macOS, you should be able to visit System Information to retrieve the device revision
It's entirely plausible that I accidentally sent you beta test boards with an incorrect firmware :-/
I'm away right now, and don't have any boards with me, but I glanced through the firmware source code and didn't see any obvious bugs. Tonight I'll plan to duplicate your setup. One other thing I might have you try is the Treehopper App, available at https://treehopper.io/downloads/, which should eliminate any hidden Python bugs.
version 1.12
i will try the app now
i took everything out of the breadboard
and redid it all
and it works now
:(
i guess i did something wrong somewhere, but I have no idea what
probably should run the python thread as a daemon thread
because otherwise the code hangs on the listener thread unless you properly do
board.disconnect()
Great, glad you got it working (somehow?). If you have any more strange GPIO bugs, let me know. All Treehopper pins have internal pull-ups, but those get disabled when in analog mode, so if I pin somehow gets put in analog mode, there's nothing driving the pin, and you can get some weird logic states. I think I cleared up all the edge cases with the firmware init() function that is explicitly called by connect() (otherwise, the board has no idea when an app "connects" or "disconnects" from a board, and its state gets out of sync).
Thanks for the daemon thread tip. I'll integrate that request next time I'm working through Python issues. I'm an awful Python programmer, so I appreciate any feedback you have! The Python API has proven quite popular --- I'm glad I started working on it before launching the product; I don't think it'd be the same without Python support!
And I have been able to program the chip, but it looks like the ROMs from ASUS site are somehow larger than 16MB or something
I see that you mentioned stripping off metadata in hex editor, what kind of data does need to be stripped? Is it at the beginnig of the file or maybe the end? Or did I get it wrong?
Or perhaps you would be so kind to upload a working ROM that I could program, although I'm very curious and would love to figure this out on how to do it myself with their official update files