We have upgraded the community system as part of the upgrade a password reset is required for all users before login in.

onionGpio Python Module

  • Has anyone had success using the onionGpio python package? I managed to make it work, sort of, but not without problems. Here's what I've noticed.

    First, out of the box, it only works with Python 2.7, not 3.6. You can easily port it to Python 3.6 by copying onionGpio.py from /usr/lib/Python2.7 to /usr/lib/Python3.6 and then editing the file to make the print statements in it into Python3-compatible calls to print(). There are only a few and they's debugging stuff.

    Second, the documentation says the getValue() method returns 0 or 1. Actually, it returns 0, '0', or '1'. Mostly the latter two except in the case of an error. To me it looks like a bug in the implementation. Also, it seems to me that it would be much better if getValue() returned True or False since it's reporting on whether a digital pin is on or off.

    Third, the implementation is a bit fragile in the sense that interrupting a program using it (for example, by typing ^C) is fairly likely to leave the GPIO system in a state that causes the next program that uses the module to fail when it runs. The reason for this is that the module got interrupted before it cleans up after itself.

    You can manually clean things up by going to /sys/class/gpio and doing an ls. Look for a directory named gpio? where ? is a number. then type the command:

    echo "?" > unexport

    where ? is the number at the end of the gpio? you found. E. g., if you find gpio2 listed, you'd type:

    echo "2" > unexport

    to clean it up.

  • So, after playing with the onionGpio module a bit more, I've reluctantly concluded that I can't use it to read gpio input that's reliable enough to do things like read a rotary encoder, even after fixing the bug in what it returns for getValue(). The trouble is partly that reading a pin is really slow because the implementation uses file manipulation and file I/O to read the bit in a hardware register somewhere that represents the pin. And partly it's because Python, being a garbage-collecting language, might take a break from executing your code to do a bunch of housekeeping between one of line of your code and the next. (Maybe it's possible to tell the Python environment to hold off on housekeeping stuff for a section of code. Some languages that garbage collect let you do that. I wouldn't know. But doing a getValue() executes a lot of code, as I said.)

    That means, for example, that if you're trying to decide which pin went HIGH first, pin1 or pin2, you can't do it reliably at the millisecond level by doing

    currentPin1 = pin1.getValue()
    currentPin2 = pin2.getValue()

    because too much time may have passed between the execution of the two lines of code.

    onionGpio (once it's fixed) should be okay for things that aren't time critical, but I think you're better off, even for only moderately time-sensitive stuff, to go for a different environment.

Log in to reply

Looks like your connection to Community was lost, please wait while we try to reconnect.