Oct 122015

If you’re a RasPi.TV regular, you’ll know that one of my very favourite things is hacking around with the GPIO ports on the Raspberry Pi and sharing my findings with the world. Sometimes this involves documenting a new feature, sometimes it involves making a new project, using a new chip or just getting something working that I haven’t tried before.

But it nearly always involves Python programming and the brilliant RPi.GPIO Python library by Ben Croston. I’ve written all sorts of tutorials (~16) on RPi.GPIO because it is one of my favourite things. You may also have heard of the RasPiO GPIO Ruler that I Kickstarted recently.

RasPiO GPIO Ruler

RasPiO GPIO Ruler

Now There’s A New Front-end Called GPIO Zero

Last time I visited Pi Towers, a couple of months ago, Ben Nuttall showed me some embryonic code he’d started working on to make RPi.GPIO more user-friendly for end-users. Last week he took it to Beta release and started gently letting the world know about it. It’s called GPIO Zero. It looks like an interesting development and I wanted to blog about it, so yesterday I asked him some questions about GPIO Zero. Here are the answers (Ben’s words in italics)…

Why did you create GPIO Zero?

Ben N: I started the project to provide simple interfaces to everyday components like LEDs and buttons, to make playing around with bits & pieces from the CamJam Edukit much more accessible. I would open up a Python shell and come up with little examples and it proved to be very fast for prototyping ideas and seeing what works – just a few lines to get going and it’s easy to take it in any direction from there. It’s only been a few weeks and it’s already become a very usable library.

Who is it aimed at?

Ben N: I’ve designed it with education in mind, to help teachers and kids get going with physical computing without the friction of worrying about pull ups, edges and all the setup. But I think most people will find it very handy.

Does it supersede RPi.GPIO?

Ben N: It will probably supersede RPi.GPIO for general use, but GPIO Zero is entirely built on RPi.GPIO so that’s not going away! When I showed Ben Croston (the author of RPi.GPIO) an early draft he said it was great – and that his library was never written to be an end-user library, just to bridge the gap providing Python access to the GPIO pins. People will be able to do most general purpose stuff with GPIO Zero, and if a component isn’t provided, they can use the underlying general InputDevice and OutputDevice classes, or they can just use RPi.GPIO.

I’m sure many people will continue to use RPi.GPIO purely because that’s what all the tutorials on the web use. Hopefully GPIO Zero will catch on and people will see how much neater their code can be!

I must say I’m eternally grateful to Ben for maintaining it! Not to mention all the projects I’ve used it for the last three years.

Why did you choose BCM over any other pin numbering system?

Ben N: We made a decision in the Foundation last year that we would always use BCM numbering for our resources. BOARD numbering might seem simpler but I’d say it leads new users to think all the pins are general purpose – and they’re not. Connect an LED to pin 11, why not connect some more to pins 1, 2, 3 and 4? Well 1 is 3V3. 2 and 4 are 5V. A lack of awareness of what the purpose of the pins is can be dangerous. Also, counting pins is a nightmare whichever way you’re counting them – you’re better off using a port label like your RasPiO Portsplus

RasPiO Portsplus Board

I completely agree with Ben about that. I detest counting pins and think it is an exercise best avoided altogether by having nice clear labels. That’s why I designed the above RasPiO Portsplus Board.

Will all official Raspberry Pi resources use GPIO Zero in future or is it
mainly for the most basic stuff?

Ben N: I imagine so. I’ve drafted up the code for some of the resources to see what they would look like – and I think they become much neater and make it easier to teach the concepts without getting bogged down with the code.

Some people might argue that you are abstracting away too much or making it too easy. How would you respond to that?

Ben N: I run a session for teachers at Picademy and in order to get them to make a button press control the camera module, I have to teach the concept of pull-ups. Then they have to teach that to their students. It’s not intended to be an electronics lesson, and it distracts from the purpose of the code, and the objective of the exercise. You might argue that it’s good to know about pull ups and pull downs, and you’d be right – but why do I have to teach that on day one? I’ve got a button, and I’ve connected it to ground and pin 17 – now let’s make it take a picture. If you want to teach the electronics in more depth there’s plenty of scope for that – but it shouldn’t be mandatory if you’re just getting started.

GPIO Zero is a Pythonic API, it’s a nice clean interface that allows you to get stuff done. That’s what high level languages and frameworks are designed to provide. Python code should be easy to write and easy to read. The API should be so simple that once you know how to do one thing, you can probably guess how to do another. It’s good to be able to say what you want code to do, rather than how to do it.

Is there anything else you’d like to tell the world about GPIO Zero?

Ben N: Expect a full release within a month. It’ll be pre-installed in Raspbian from then on. Until then, install the beta with pip. Check out the recipes for ideas and you’ll get the gist of how it works. If there’s anything you think should be added, just let me know on GitHub or the Google Doc.

A huge thanks goes to Dave Jones (author of picamera and picraft) for his voluntary help on the project. He’s responsible for some of the cleverest aspects of the library.

Thank you Ben for answering those questions.

Where Can I Get It?

The current Beta release and installation instructions are found here.

So What’s it Like?

Well for starters it’s simpler and more “natural language” in its approach. Let’s do a side by side comparison of the code needed to light an LED on GPIO25 and switch it off after 5 seconds. (Don’t try to run this code, as it contains both)…

# RPi.GPIO                        GPIO Zero
from RPi import GPIO              from gpiozero import LED
from time import sleep            from time import sleep
GPIO.setup(25, GPIO.OUT)          led = LED(25)
GPIO.output(25,1)                 led.on()
sleep(5)                          sleep(5)
GPIO.output(25,0)                 led.off()

GPIO Zero removes the need to set up the GPIO ports manually. All you do is tell the program what you want to do and it handles that part for you. It also sets warnings off (a feature I never actually use, but it’s an extra line of code you had to type if you did).

Natural Sounding Language

But Ben’s main point in developing GPIO Zero is to create a Python GPIO interface that can be addressed with natural sounding language, which makes it very approachable for learning.

Rather than having to get your head around…
GPIO.setup(25, GPIO.OUT) “I want to set up GPIO25 as an output”, you have…

led = LED(25) “I want to put an LED on GPIO25”, which makes more sense to a human being.

Rather than…

GPIO.output(25,1) “Switch our output on GPIO25 to On”, we have…

led.on() “Switch on our LED”

There is even a function for blink(), so you could blink an LED in 3 lines of code, which is ideal to grab the interest of a ‘small person’ within the limited time of their attention span.

from gpiozero import LED
led = LED(25)

In my teaching experience, if you can ‘get a result’ within a few minutes, you’ve got them hooked and interested. If it takes too long, you’re doomed!

More To Come

I haven’t yet had an in-depth play with GPIO Zero, but will now do so and report my findings in my next blog post.

When I learned to drive, I happily drove round in a manual (stick shift) car for 20 years before I bought my first automatic. I took to an automatic very quickly and love it and I don’t think I would want to go back to manual.

I suspect it may be a bit like this with GPIO Zero. There’s nothing wrong with RPi.GPIO – I’ve learned how to use it, it works well and I love it. But if you don’t need to ‘get your hands dirty under the hood’, GPIO Zero provides a nice clean way of getting the job done in a manner that is a lot easier to understand and quicker for learners. It’s another option, and it’s good to have choices.

  10 Responses to “GPIO Zero – Introduction”

  1. Hi Folks, thanks for the introtuction of GPIO Zero. I got a short question too: Will I be able to use it for PWM, like for servos or even ws2812b RGB LEDs?

    • Very doubtful because it will be using RPi.GPIO’s soft PWM which is not accurate enough for those applications. You really need a hardware PWM for both of those. ServoBlaster (C library) can be made to work on the Pi, but it is a bit jittery. Hardware PWM is the way to go though. I think Adafruit do a nice Servo Hat which you can run from i2c.

      • Hi alex, I agree to your opinion to a certain degree. Since the GPIO zero is meant to be used for beginners and educational purpose, we should try to give soft pwm a chance. I successfully cloned and adapted this project [www.youtube.com/watch?v=N5QmZ92uvUo] for a simple servo control, e.g. PI.CAM orientation – and it works fine (even with the jittery side effect)
        I also want to build a bigger project with more servos, so the adafruit servo hat is already ordered :-)

        Another idea (I gladly like to add to the git hub doc wish list) is to drive a stepper motor.

        And one last question about gpio zero (for this comment): is the led.blink() function working in background once set? That would be some kind of a multitasking in python, and I wonder if you would need to clean the GPIO on exit.

        Cheers McPeppr

        • I don’t know if something has changed since April 2013, perhaps it has? But at that time I tried RPi.GPIO softPWM as a means of controlling servos and it simply couldn’t do it. http://raspi.tv/2013/how-to-use-soft-pwm-in-rpi-gpio-pt-2-led-dimming-and-motor-speed-control

          When I put the oscilloscope on the signal, it wasn’t very consistent. As far as I understand it, servos need quite a consistent signal. That was using RPi.GPIO, which GPIO Zero is based on. So, unless something was improved that I don’t yet know about (possible) I’d still say no to servo control with softPWM in Python. (Not as a matter of authority – that’s up to Ben – I merely think it won’t work).

          I think blink is a background thread, but Ben will be able to answer that one better than me. I’m pretty sure GPIO.cleanup is taken care of for you too.

          • For soft PWM pigpio library is the best. I tiried RPi.GPIO, WiringPi and pigpio. The last one wins.

            I hope gpio zero is flexible enough to (in fgeature) support different backend libraries.

    • I have built in support for LEDs and RGBLEDs – and could potentially add it for further components such as servos and ws2812s. I’ll add them to the wishlist for future updates! If you have any further suggestions please post to GitHub or the Google Doc! (links above)

    • I’ve always preferred the RPIO library over all the others. It does PWM via DMA so its pretty fast/accurate. I’ve used it to control an 8 servo walking robot. It also includes simple functions for interrupts on GPIO and TCP sockets as well as a CLI for manipulating GPIO outside of python.


  2. By LED…could you also mean 3.3V or 5V relay?!?!? and which?!?!

    • You could. And you could also use a general purpose output for that. I don’t think there is a relay class in GPIO Zero (yet), but there probably doesn’t need to be. I’ve found 5V relays work OK on Pi with 3V3 logic and 5V power, but usually the little boards you buy for arduino etc are 0=On, 1=Off which can be confusing until you realise that.

Leave a Reply