Today at FUDCon I gave a lightning talk on interfacing devices to the Raspberry Pi, to try and explain why this device is so interesting to both educators and hackers.

Here's a recap of the demo for those who weren't there (or if I missed something); I was using a Pi running the Raspberry Pi Fedora Remix 17, and the point of the demo was to show how simple devices can be controlled (or sensed) directly from the command line (using just four commands: cd, ls, cat, and echo, plus sleep and the bash while...do loop):

1. Output

The Raspberry Pi has a number of General-Purpose Input/Output (GPIO) pins available on a connector on the corner of the board. These can be used as inputs or as outputs, and can be on (binary “1”) or off (binary “0”). The pinout diagram is available on the web.

Connecting up an output can be as simple as taking an LED (from any electronics part store, or snipped out of a dead PC) and a small resistor (I used a 220 ohm one - red/red/brown) and connecting them to one of the GPIO pins and a ground pin. In the demo I used GPIO 11 and ground, with a tiny breadboard and some male-femalejumper wires for convenience.

The software side is pretty simple: there's a directory, /sys/class/gpio, that provides access to the GPIO pins. By default, this directory contains just three entries:

What if you want to control something a lot bigger than an LED? Just substitute something like a Powerswitch Tail II for your LED - your Pi connects to an LED inside the tail, and whenever that LED is turned on, the water pump/blender/fan/toaster plugged into the tail starts up.

2. Input

Connecting an input is not any more complicated. In the demo, I hooked up an old “Turbo Mode” switch (remember those?!) to GPIO 24. In one position, it connected GPIO 24 to 3.3 volts, and in the other position, it connected it to ground.

Using this switch as an input was even easier than controlling the LED:

# cd /sys/class/gpio# echo 24 > export# cat gpio24/value0

... Now toggle the switch! ...

# cat gpio24/value1

3. Input & Output

Putting both of these together is pretty straightforward. You can control the flashing of the LED using the switch with a line like this:

For education, these experiments are simple, quick, and don't require a lot of background knowledge: the student needs only a handful of basic bash commands (cd, ls, cat, echo). Unlike an Arduino, the Pi doesn't need a separate system to host development. You also don't need to deal with files, interpreters, shebang lines, permissions, or compilers. But eventually (and usually pretty quickly), students will want to learn those concepts. In order to save their commands across boots, for example, they will soon want to store them in files: voila, scripts!

It's logical and easy to progress from controlling a single LED and reading a single switch to controlling six LEDs - enough for a two-way traffic light - and then you can add things like pedestrian crossing buttons. Or you can use two infrared LEDs and two infrared phototransistors (which act exactly like switches), mounted in a doorway, to count the number of people that have entered and exited from a room, turning on the lights whenever people are present. These types of projects are fun and engaging ways to teach logic, programming, and circuits.

After a while, students want to do something they can't easily do in bash, like drive a GPIO faster, or poll some complex combination of pins – and they're on to Python (or C, or Perl, or any of a multitude of other languages).

When students/hackers/makers want to connect something more complex than can be easily interfaced through GPIO, the Pi offers serial ports (you can put a message on an LCD display with two bash commands), I2C, and SPI interfaces. And although the ARM processor in the Pi is fairly slow, it is fast enough to do interesting things like speech synthesis and machine vision.

Source RPM packages -- SRPMs -- have an architecture of "src". In other words, a source RPM is a source RPM, with no architecture associated with it. There's an assumption that the package is architecture-neutral in source form, and only become architecture-specific when built into a binary RPM (unless it builds into a "noarch" RPM, which is the case with scripts, fonts, graphics, and data files).

An SRPM contains source code (typically a tarball, and sometimes patch files) and a spec file which serves as manifest and build-recipe, plus metadata generated from the spec file when the SRPM is built -- including dependencies (which, unlike binary RPMs, are actually the build dependencies).

However, the build dependencies may vary by platform. If package foo is built against bar and baz, and baz exists on some architectures but not others, then the spec file may be written to build without baz (and the accompanying features that baz enables) on some architectures. The corresponding BuildRequires lines will also be made conditional on the architecture -- and this make total sense. However, querying an SRPM on a given platform may give incorrect build dependency information for that platform if the SRPM was built on another platform -- and only rebuilding the SRPM on the target arch will correct the rpm metadata (and possibly render it incorrect for other platforms). Thus, I've come to realize, SRPMs are not truly architecture-neutral -- and I'm not sure if all our tools take this into consideration.

The Raspberry Pi has a micro-USB jack for power input. This can be used with any recent mobile phone adapter. If you use a two-part adapter, with a plug-in AC-DC converter and a USB A to micro-USB A cable, it's easy to measure the current drawn by the Pi.

To do this, you'll need a USB A male to USB A female extension cord and an ammeter or multimeter with a 1A or 10A range.

1. Remove the outer insulation in the middle of the USB extension cable. Peel back the shielding (silver braid and/or foil) to one side.

It looks like the Pi can draw anywhere from 250 to 500 mA in normal operation, though I did see smaller values in the early stages of startup. When idle, my Pi draws 320-380 mA; with a basic Logitech keyboard and mouse attached and in use, and with the CPU and GPU fairly active, it comes close to 500 mA.

Update: Powering the Pi from a Laptop

The fact that the Pi's current consumption is reliably under 500 mA means that it is actually safe to power from the USB port of another system. This is convenient for developers on the go: for example, I'm in an air-conditioned library escaping the current Toronto heatwave, and have my Pi connected to the back of my laptop with a micro-USB cable for power and a crossover ethernet cable for data.

This five-year renewable applied research grant enables me to continue and expand upon the work that I have been doing, along with a talented team of research assistants, with Fedora ARM and related projects. My goal is to bring the wealth of open source software currently available for x86 PCs and servers to emerging ARM based general-purpose computers. Although ARM architecture chips are the most popular CPUs made (more ARM chips shipped last year than there are people on this planet), most of these went into dedicated devices, and ARM chips are just starting to appear in general purpose computers. In order to make the transition to general-purpose ARM systems viable, industry-standard software stacks are needed. Fedora is a perfect fit for this purpose, because it encompasses both a large collection of cutting-edge open source software and a vibrant community, and it feeds many downstream distributions and projects.

My work in this new role will start with an expansion of existing work, including operating the Fedora ARM Koji buildsystem and improving the Raspberry Pi Fedora Remix, but I will additionally be focusing on Fedora on ARM server-class systems. In future phases, this will encompass working with the Fedora ARM project to promote ARM to primary architecture status, extending existing open source system management (and possibly virtualization/cloud management) frameworks to manage high-density ARM clusters, doing field trials of ARM-based data centre solutions, and bringing Fedora to the next generation of ARM technology.

Although the majority of my activity will shift from teaching to applied research, I will continue to teach the SBR600Software Build and Release course in order to bring the research experience back into the classroom. I'll also continue to participate in the TeachingOpenSource.org initiative. As an Industrial Research Chair, I will also have a bit more of a public-facing role, representing CDOT and advocating the use of energy-efficient systems to local SMEs.

Many thanks to Red Hat for partnering with Seneca on this initiative, and I look forward to (continuing to!) work closely with Red Hat's incredible technical staff. I also thank the many companies and organization who wrote letters of support for the grant application, and look forward to collaboration and possible future partnerships with those organizations. And I particularly want to thank Seneca for its support of applied research, my colleagues at CDOT for their encouragement and for creating such an awesome environment to do applied research, and for the team that wrote the grant application under intense pressure and tight deadlines last November.

My research group at CDOT and my Software Build and Release (SBR600) classes at Seneca worked together to produce the Raspberry Pi Fedora Remix, which takes the Fedora ARM software and adds a small number of additional software packages needed for use on the Pi. We tested the remix on an alpha (pre-production) board provided by the Foundation.

The computer education, hardware hacking/maker, and open source worlds are all eagerly anticipating the release of the $35 Raspberry Pi computer before the end of the month. In preparation for the hardware release, tthe Raspberry Pi Fedora Remix 14 distribution is being released this Wednesday, February 22.

Full details of the event are on the CDOT wiki. Everyone's invited, and I hope to see you there!