Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Jeremy Herbert
    @jeremyherbert
    I just got my treehoppers
    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
    Jeremy Herbert
    @jeremyherbert
    the python code appears to be printing the correct stuff
    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
    Jay Carlson
    @jaydcarlson
    Interesting! I'll take a look when I get back to a computer and see what's going on.
    Jay Carlson
    @jaydcarlson
    image.png
    @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 :-/
    Jay Carlson
    @jaydcarlson
    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.
    Jeremy Herbert
    @jeremyherbert
    according to system info on my mac
    version 1.12
    i will try the app now
    Jeremy Herbert
    @jeremyherbert
    yep app does exactly the same thing
    Jeremy Herbert
    @jeremyherbert
    ok well
    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
    Jeremy Herbert
    @jeremyherbert
    also
    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()
    Jay Carlson
    @jaydcarlson
    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!
    FrozenHaxor
    @FrozenHaxor
    Hello, I have found your awesome article about resurrecting a B350M-A motherboard since I have bricked mine... whoops
    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
    FrozenHaxor
    @FrozenHaxor
    @jaydcarlson Hope you will read this chat some time :P
    Jay Carlson
    @jaydcarlson
    Open it in a hex editor and take a look. I believe it's at the end. You'll see a bunch of blank data before it.
    FrozenHaxor
    @FrozenHaxor
    I found a tool that converts the CAP files into regular ROM, called "UEFI Tool" and it appears to have done the job. Will try to program the SPI flash tomorrow.
    FrozenHaxor
    @FrozenHaxor
    The new file now ends at FFFFF0 therefore the size is correct, it was too long in the original
    FrozenHaxor
    @FrozenHaxor
    Alright, that worked right away. Thanks for the article, it pointed me in the right direction even though I have a dedicated programmer.