Don’t try the above setup at home: my Raspberry Pi rebooted when I was removing the alligator clip!

Once I broke ground on Raspberry Pi hacking with the UART tutorial, I decided it would be interesting to see just how capable the GPIO offered really was. Considering I had a Picoscope at hand, I chose to see how fast those GPIO pins really are under various programming environments.

The basic test setup was to toggle one of the GPIO pins, namely the GPIO 4 (it was easily accessible with my adapter and didn’t interfere with UART) and see what frequency square wave could be achieved. This is basically the “upper limit” for any signalling one can hope to achieve with the GPIO pins – likely real-life scenarios where processing needs to be done would aim for some fraction of these values.

Here’s a useful cheat sheet to current benchmark results:

Language	Library	Version / tested	Square wave
Shell	/proc/mem access	not applicable / July 3, 2012	3.4 kHz
Python	RPi.GPIO	0.3.0 / August 1, 2012	44 kHz
Python	wiringPi	github @ August 14, 2012	20 kHz
C	Native library	not applicable / July 3 and August 14, 2012	14-22 MHz
C	BCM 2835	1.3? / July 3, 2012	4.7 – 5.1 MHz
C	wiringPi	not available / August 14, 2012	6.9 – 7.1 MHz
Perl	BCM 2835	1.0 / July 3, 2012	35 kHz

Note: The earlier test images have been taken with longer leads, so high-frequency waveforms exhibit some roundness and overshoot that would not be there without the jumper wires I originally used to avoid resetting the Pi when poking the GPIO pins directly with a probe. So don’t read too much into the waveform. See the section on C benchmarks which have been redone with shorter ground lead, and you’ll see that even at 22 MHz the square wave generated is quite nice.

Shell script

The easiest way to manipulate the Pi GPIO pins is via console. Here’s a simple shell script to toggle the GPIO 4 as fast as possible (add sleep 1 after both to get a nice LED toggle test):

#!/bin/sh

echo "4" > /sys/class/gpio/export
echo "out" > /sys/class/gpio/gpio4/direction

while true
do
	echo 1 > /sys/class/gpio/gpio4/value
	echo 0 > /sys/class/gpio/gpio4/value
done

As expected, the performance of this implementation is not good: A 3400 Hz square wave can be generated using this method. For turnings things on and off this is enough, but no signalling and hardly even LED PWM is feasible.

Update: Note that I have my probes at 1:10 setting, so the actual voltage value is 10x what is displayed in the figures!

Python

One of the simplest ways to access the GPIO with a “real programming language” (sorry bashers :) is with the RPi.GPIO Python library. Installing it was simple: Just download the .tar.gz file, extract files and run python setup.py install. Our test script is simple as well:

import RPi.GPIO as GPIO

GPIO.setmode(GPIO.BCM)

GPIO.setup(4, GPIO.OUT)

while True:
    GPIO.output(4, True)
    GPIO.output(4, False)

If you expected the Python library performance to be any better, prepare for a disappointment: The above script achieves only 900 Hz square wave, meaning that you don’t do anything fancy with this library. Update: While the 0.2.0 version performance was terrible, the newer 0.3.0 version has significantly improved performance: 44 kHz square wave could be generated. The diagram below is updated for version 0.3.0, see the older version’s results here.

I was really surprised by the lackluster performance of the Python implementation. I’m not very familiar with Python optimizations, so if someone can suggest any improvements to the code or execution parameters, drop me a line!

The improved performance in Python is probably enough for simple multiplexing and LED PWM applications. Note that the new version requires some additional steps in installation, name getting Python development kit with sudo apt-get install python-dev. I originally got errors while trying this, but upgrading my packages solved that problem.

Update: Another alternative for Python are the wiringPi Python bindings. With the following simple test program, a square wave of 19.5 kHz was generated – about half the speed of the updated RPi.GPIO library:

import wiringpi

io = wiringpi.GPIO(wiringpi.GPIO.WPI_MODE_PINS)

io.pinMode(7,io.OUTPUT)

while True:
    io.digitalWrite(7,io.HIGH)
    io.digitalWrite(7,io.LOW)

C: Maximum performance

The Raspberry Pi Wiki gives a nice C code example for true hardware-level access to the GPIO. The interfacing is slightly more difficult, but code isn’t too bad. I took the example program and simplified the main method after setup_io() to this:

// Set GPIO pin 4 to output
INP_GPIO(4); // must use INP_GPIO before we can use OUT_GPIO
OUT_GPIO(4);

while(1) {
  GPIO_SET = 1<<4;
  GPIO_CLR = 1<<4;
}

Without any optimizations, I got an excellent 14 MHz square wave. However, since we are operating at the very extremes of the device, the waveform isn’t too square anymore;

Update 3. The measurements for these high frequency signals are now completely redone. First there was an issue with inadequate sampling rate of the Picoscope 2204. Then I had adequate bandwith, but too long test leads (I used a female-male jumper wire for ground and test lead). The waveforms below are now completely redone and the rest of the text in this section rewritten. Sorry for the inconvenience, it should be accurate now:

Compiling with the -O3 flag gives even more impressive results: 21.9 MHz square wave. As seen from the waveform, one cannot expect the device go any further than this. As a clock signal, this still might work nicely, but I wouldn’t call it a square wave anymore. However, w We can conclude that using C, signalling at several MHz speeds should be achievable.

BCM2835 C library

Mike McCauley has made a nice C library called bcm2835 that can also be used to interface with the GPIO pins using C. Its installation was also quite easy: download, run the standard configure / make / make install commands and you’re good to go. Compiling the code is done with the -l bcm2835 compiler flag to include the library. Benchmark code looked like this (note that in Broadcom numbering, GPIO 4 is P1_07):

#include <bcm2835.h>

#define PIN RPI_GPIO_P1_07 // GPIO 4

int main(int argc, char *argv[]) {
    if(!bcm2835_init())
	return 1;

    // Set the pin to be an output
    bcm2835_gpio_fsel(PIN, BCM2835_GPIO_FSEL_OUTP);

    while(1) { // Blink
	bcm2835_gpio_write(PIN, HIGH);
	//delay(500);
	bcm2835_gpio_write(PIN, LOW);
	//delay(500);
    }

    return 0;
}

The performance is not far beyond the earlier C example: A solid 4.7 MHz which could be bumped to 5.1 MHz with the use of -O3 optimization flag. Definitely enough for most applications!

Note that the overshoot in above image is likely due to a long ground lead (see the notes in the C section and beginning of the article for details).

WiringPi

Gordon Henderson has written an Arduino-like wiringPi library using C. I had a request to benchmark that, too. Here’s the simple test program:

#include <wiringPi.h>

#include <stdio.h>
#include <stdlib.h>
#include <stdint.h>

int main() {
  if (wiringPiSetup () == -1)
    exit (1) ;

  pinMode(7, OUTPUT);

  while(1) {
    digitalWrite(7, 0);
    digitalWrite(7, 1);
  }

  return 0 ;
}

With the normal GPIO access method, the library already clocks an impressive 6.9 MHz square wave. The picture below has also been updated for more accurate waveform:

There’s also a GPIO access method which involves calling wiringPiSetupGpio() instead of wiringPiSetup(), and using the normal GPIO numbering instead of wiringPi native renumbering system, so 7 becomes 4 in the above code. The performance is increased slightly to ~7.1 MHz.

Also, a /proc/sys based access method was provided, but it was a lot slower, running at 200 kHz on average. The wiringPi also comes with a command gpio that can be used to access the GPIO, but the performance is very poor. The program below achieved a 80 Hz square wave:

gpio -g mode 4 out

while true
do
	gpio -g write 4 1
	gpio -g write 4 0
done

There’s also a “pwm” command, but I couldn’t get that to work. The wiringPi library also has Python, Ruby and Perl bindings. I tried out the Python version and got an almost 20 kHz square wave, which is quite good (about half the speed of RPi.Python 0.3). I’d expect the Perl and Ruby bindings to be on the same speed level.

Perl

Mike McCauley has also made a Perl module that uses the above C library to provide GPIO access in our favorite language (who doesn’t love Perl?). For installation, I recommend skipping cpan command and just downloading the module from its CPAN page, extracting, and running perl Makefile.PL / make / make install commands. Like it usually is, the Perl code isn’t pretty, but it does the job well:

use Device::BCM2835;
use strict;

Device::BCM2835::init() || die "Could not init library";

# Set RPi pin P1_07 (GPIO 4) to be an output
Device::BCM2835::gpio_fsel(&Device::BCM2835::RPI_GPIO_P1_07, 
                            &Device::BCM2835::BCM2835_GPIO_FSEL_OUTP);

while (1) { # Strobe
    Device::BCM2835::gpio_write(&Device::BCM2835::RPI_GPIO_P1_07, 1);
    Device::BCM2835::gpio_write(&Device::BCM2835::RPI_GPIO_P1_07, 0);
}

Compared to the Python version, the Perl module packs a bit more punch: 35 kHz square wave was achieved – enough for some simple PWM applications, if not quite enough for audio generation etc.

As with the Python version, any tips to improve Perl execution performance are welcome!

Conclusion

Based on these simple benchmarks, I can conclude that shell and Python access to GPIO is enough for any automation tasks, but at least the Perl level performance is needed to do any fancier stuff. For actual signalling applications, C seems like the only choice. I haven’t tried the C# and Java interfaces, but I’d expect them to be on the level of C and Perl, respectively, or a bit slower.

Hope you enjoyed this article! As always, I recommend you to subscribe to the feed to get the latest posts without checking back manually. And if you really like the content, donations towards future hacking efforts are very much appreciated.