Pingo and RPi-Distro/python-gpiozero

[s-celles]

It may be a good idea to have a look at RPi-Distro/python-gpiozero API https://github.com/RPi-Distro/python-gpiozero/

Pinging @bennuttall @waveform80 @martinohanlon

Maybe some code merge should be considered.

see
https://www.raspberrypi.org/blog/gpio-zero-a-friendly-python-api-for-physical-computing/
https://blog.adafruit.com/2016/01/22/gpio-zero-developing-a-new-friendly-python-api-for-physical-computing-raspberry_pi-piday-raspberrypi/

[s-celles]

Here is some ideas I like in python-gpiozero API.

A LED or a (push) Button can be instanciate using only pin number (there is no need to pass a pin object). but we might be ok about what kind of pin numbering is use in such a case (BCM or BOARD ?)

from gpiozero import LED
from time import sleep

led = LED(17)

while True:
    led.on()
    sleep(1)
    led.off()
    sleep(1)

An other feature I like in their API is the way they manage "events" with push button

from gpiozero import LED, Button
from signal import pause

led = LED(17)
button = Button(3)

button.when_pressed = led.on
button.when_released = led.off

pause()

[bennuttall]

Glad you like GPIO Zero.

It's BCM numbering only.

Do you have anything to contribute? Feel free!

[waveform80]

Just to elaborate a bit on what happens behind the scenes in gpiozero... When you construct something like LED(17), internally the library expects a pin object to be passed in (instead of 17) but we have a "default" pin implementation so that gets converted into LED(DefaultPin(17)) and DefaultPin is (usually, currently) just an alias for RPiGPIOPin so that'd be equivalent to LED(RPiGPIOPin(17)) where RPiGPIOPin is a pin implementation based on the RPi.GPIO library.

The advantage of this is firstly that it presents a simple face to new users - they don't have to worry about pin implementations and they have a single pin numbering scheme to deal with (BCM was selected rather than BOARD for various reasons I can go into if people really want...). However, for more advanced users they can pass in a very specific pin implementation if they want to, including things like PiGPIOPin which (because it's socket based) permits things like remote controlling pins over a network socket, e.g. LED(PiGPIOPin(17, host='my-other-pi')). In future (haven't got there yet - limited time, etc. etc.) it should also allow using pins on IO extender boards. For example, something like:

extender_board = SomeIOExtender(i2c_addr=0x3F)
led = LED(extender_board.pins[2])

(note entirely sure how I'd represent extender board pins at the moment, so don't consider that a blueprint or anything! :)

The event handling in gpiozero looks simple on the surface (as it should) but there's a little magic behind the scenes to make it a little more flexible: you can pass in a handler with no mandatory arguments, or you can pass in one which takes a single mandatory argument in which case the handler will be called with the triggering object as that parameter. Function prototype introspection is used to achieve this (this has some limitations, i.e. you can't use it on external functions, but if people are writing functions in C they're advanced enough to deal with making a python wrapper where needed). Event handling also relies on the underlying pin implementations providing efficient edge triggering (which in all but one current implementation are handled by epoll waits).

Anyway, feel free to ask if you want details or pointers to stuff!

[s-celles]

Thanks a lot @bennuttall and @waveform80 for your great explanations about GPIO Zero internals.

It will be great if such a library could support many boards (RaspberryPi, BeagleBone, Arduino...) like pingo is doing... but that's maybe out of the scope of this project ?