BeagleBone Black GPIO Benchmark

Look what the mailman brought: It’s a shiny (or maybe matte?) BeagleBone Black, freshly arrived (actually it’s been over a month, but time sure flies…) from Newark element14! I’ve been doing Raspberry Pi related hacking for a while, but especially when the Pi was still fresh and new, I did from time to time consider if the grass would be greener on other side of the fence. Or blacker, in this case, as I mean BeagleBone Black.

BeagleBone was long very much more powerful than Raspberry Pi, but now that Pi2 has come out, price and specification-wise they are closer than ever. A quick personal comparison chart:

  BeagleBone Black Raspberry Pi 2 (B)
Price 46 € (Element14) 32 € (Element14)
Processor 1GHz single-core Cortex-A8 0.9GHz quad-core Cortex-A7
Memory 512MB DDR3 1GB
Connections USB host, USB device, micro-HDMI 4x USB, HDMI, 3.5mm Audio/analog video
GPIO 2x 46 pin headers (65 digital I/O) 40 GPIO pins (26 digital I/O)
Other 4GB integrated flash, works as USB device camera and display interface on board

When Pi1 was out, the BeagleBone Black with the more modern Cortex-A8 chip and higher clockrate was definitely the more powerful, but now with 4-core Pi2, the tables have somewhat turned. Still, the clockrate is higher and there’s more GPIO. And speaking of GPIO, my Raspberry Pi vs. Pi2 GPIO benchmark has gotten a lot of interest, so I thought the best way to take this black beauty for a test drive would be to benchmark BeagleBone Black GPIO in a similar way.

Test setup

Test bench

The test subject is the most recent revision C of BeagleBone Black. I followed the (a bit lacking in detail and readability) Getting Started guide and downloaded the latest Debian Jessie image (8.3, 2016-01-24), flashed it to card and ran apt-get update and apt-get dist-upgrade (2016-04-14).
Continue reading BeagleBone Black GPIO Benchmark PyMySQL Plugin

I’ve been playing around today with BottlePy, an excellent mini-framework for Python web development. However, getting Python MySQL support is always a hassle, I never know if MySQLdb has died or not, so I thought I’d try PyMySQL for a change.

In addition to being just generally awesome, Bottle has a nice plugin syntax, and even a great 60-line sample of a SQLite plugin. So I adapted it for PyMySQL, turns out this was quite easy:

import pymysql.cursors
import inspect

class PyMySQLPlugin(object):
    ''' This plugin passes a pymysql database handle to route callbacks
    that accept a `db` keyword argument. If a callback does not expect
    such a parameter, no connection is made. You can override the database
    settings on a per-route basis. '''

    name = 'pymysql'
    api = 2

    def __init__(self, db, user, password, host='localhost', charset='utf8mb4', keyword='db'): = host
        self.user = user
        self.password = password
        self.db = db
        self.charset = charset
        self.keyword = keyword

    def setup(self, app):
        ''' Make sure that other installed plugins do not affect the same
            keyword argument.'''
        for other in app.plugins:
            if not isinstance(other, PyMySQLPlugin): continue
            if other.keyword == self.keyword:
                raise PluginError("Found another %s plugin with "
                "conflicting settings (non-unique keyword)." %

    def apply(self, callback, context):
        # Override global configuration with route-specific values.
        #conf = context.config.get('sqlite') or {}
        #dbfile = conf.get('dbfile', self.dbfile)

        # Test if the original callback accepts a 'db' keyword.
        # Ignore it if it does not need a database handle.
        args = inspect.getargspec(context.callback)[0]
        if self.keyword not in args:
            return callback

        def wrapper(*args, **kwargs):
            # Connect to the database
            db = pymysql.connect(,

            # Add the connection handle as a keyword argument.
            kwargs[self.keyword] = db

                rv = callback(*args, **kwargs)
                #if autocommit: db.commit()
            #except sqlite3.IntegrityError, e:
                #raise HTTPError(500, "Database Error", e)
            return rv

        # Replace the route callback with the wrapped one.
        return wrapper

As you may see, there is no autocommit support and graceful recovery from database errors is something that is missing as well, but it’s a great start. There were a couple of GitHub projects with similar aims, but those seemed a bit behind the times (one was adding Python 3.4 support, and I’m already on 3.5, for example). A little NIH syndrome for me, maybe. Using the above library is quite easy:

from bottle import install, route
from somefile import PyMySQLPlugin

pymysql = PyMySQLPlugin(user='dbuser',
        password='dbpass', db='dbname')

def demo(db):
    # This method has a "db" parameter, and the plugin activates
    with db.cursor() as cursor:
        sql = "SELECT `id`, `password` FROM `users` WHERE `username`=%s"
        cursor.execute(sql, ('johndoe',))
        result = cursor.fetchone()
        return str(result)

Hope you found this useful!

Raspberry Pi 2 vs. 1 GPIO Benchmark

Raspberry Pi 2 GPIO Benchmark

It’s battle time! Some of you may have heard that Raspberry Pi 2 is out with more punch than ever. Just how much more? Well, apt-get dist-upgrade went about 5 times faster with the new Pi. With 1 GB of RAM and four cores, this will definitely be a boost for my home SSH box ergonomics over the previous version.

But what about hacking? There has been a lot of interest in getting GPIO benchmarks for the Pi 2 similar to my earlier Raspberry Pi GPIO benchmark. Well here it is! Please refer to the earlier article for source code and nice screenshots of square waves, as I’ll concentrate on the performance difference only here. You can also get the code from Github:

Summary of results

All the Pi 1 benchmarks were ran 14th and 15th February 2015 using latest versions of the libraries as stated in my updated benchmark post. Pi 2 benchmarks were all run 25th and 26th March 2015 with the latest versions. If you get significantly different results at a later date, please let me know and I’ll update the table!

Language Library Pi 1 Pi 2 Change
Shell /proc/mem access 2.8 kHz 7.0 kHz 2,5x
Shell / wiringPi WiringPi gpio utility 40 Hz 95 Hz 2,4x
Python RPi.GPIO 70 kHz 243 kHz 2,5x
Python wiringpi2 bindings 28 kHz 103 kHz 3,7x
Ruby wiringpi bindings 21 kHz N/A 3,7x
C Native library 22 MHz 41.7 MHz 1,9x
C BCM2835 5.4 MHz 7.2 MHz 1,3x
C WiringPi normal GPIO wiringPiSetup() 4.1 MHz 9.3 MHz 2,3x
C WiringPi GPIO wiringPiSetupGpio() 4.6 MHz 9.4 MHz 2x
C WiringPi sys wiringPiSetupSys() 120 kHz 185 kHz 1.5x
Perl BCM2835 48 kHz 154 kHz 3.2x

Continue reading Raspberry Pi 2 vs. 1 GPIO Benchmark

Arduino and Raspberry Pi Serial Communication

Today’s the last day of my summer holiday, and I had some free time on my hands. So I decided to see if I could get my Arduino Uno and Raspberry Pi to talk to each other. It turned out the task was even easier than my previous Pi to RS-232 project – all that was needed between the two devices was some jumper wire and two 1 kOhm resistors to form a voltage divider between Arduino TX pin and Pi RX pin – Arduino understands Pi’s 3.3V signal levels just fine so Pi TX to Arduino RX needed no voltage shifting at all.

IMPORTANT UPDATE! It turns out that the RX pin on the Arduino is held at 5V even when that pin is not initialized. I suspect it is due to the fact that the Arduino is programmed via these same pins every time you flash it from Arduino IDE, and there are external (weak) pullups to keep the lines to 5V at other times. So the method described below may be risky – I suggest either add a resistor in series to the RX pin, or use a proper level converter (see this post for details how to accomplish that). And if you do try the method below, never connect the Pi to Arduino RX pin before you have already flashed the program to Arduino, otherwise you may end up with a damaged Pi!!!

Setting Raspberry Pi up for serial communications

In order to use the Pi’s serial port for anything else than as a console, you first need to disable getty (the program that displays login seen) by commenting the serial line out of Pi’s /etc/inittab:

1:2345:respawn:/sbin/getty 115200 tty1
# Line below commented out
# 2:23:respawn:/sbin/getty -L ttyAMA0 115200 vt100
3:23:respawn:/sbin/getty 115200 tty3
4:23:respawn:/sbin/getty 115200 tty4
5:23:respawn:/sbin/getty 115200 tty5
6:23:respawn:/sbin/getty 115200 tty6

If you don’t want the Pi sending stuff over the serial line when it boots, you can also remove the statements console=ttyAMA0,115200 and kgdboc=ttyAMA0,115200 from /boot/cmdline.txt. You’ll need to reboot the Pi in order for the changes to take effect.
Continue reading Arduino and Raspberry Pi Serial Communication

Django – next stop after Ruby on Rails?

Having done web development on several platforms (Perl+CGI, ASP.NET and PHP), I was introduced to Ruby on Rails about two years ago, and it was love on first sight. The separation of code and layout was a bliss after PHP require statements (and vaguely similar to ASP.NET, by the way), and database abstraction was on a wholly different level.

And, you don’t need semicolons after statements in ruby, just how sexy is that? What more can a man need (write a comment, if you disagree :).

Now Rails does have some annoyances, like painful configuration for multiple applications running on a same server. If someone actually likes writing Lighttpd rules and making special provisions for it in routes.rb, again, let me know. It also seems that in some cases, all the abstraction and “there is a really clever hack to do this with just one line of code” -mentality has taken over good sense, which for me has meant that my “Rails 0.9” skillset has been mostly deprecated, and replaced with layers upon layers of new stuff I should be continuously keeping up with.

Now a recent Slashdot article (the one linking the page-long rant from Mongrel developer) had some positive comments related to Django, and I decided to check it out. And guess what? It just rules.
Continue reading Django – next stop after Ruby on Rails?