Chris Tyler's Blog - Mozilla Education Planet

Why the Pi is Great for Teaching and Hacking

nospam@example.com (Chris Tyler) — Fri, 18 Jan 2013 15:03:01 -0500

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-female jumper 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:

# cd /sys/class/gpio
# ls -l
total 0
--w------- 1 root root 4096 Dec 31 1969 export
lrwxrwxrwx 1 root root    0 Dec 31 1969 gpiochip0 -> ../../devices/virtual/gpio/gpiochip0
--w------- 1 root root 4096 Dec 31 1969 unexport

Placing a GPIO number in the export file gives us control of that GPIO:

# echo 11 > export

And the kernel responds by creating a directory corresponding to that GPIO pin:

# ls -l
total 0
--w------- 1 root root 4096 Jan 14 18:39 export
lrwxrwxrwx 1 root root    0 Jan 14 18:40 gpio11 -> ../../devices/virtual/gpio/gpio11
lrwxrwxrwx 1 root root    0 Dec 31 1969 gpiochip0 -> ../../devices/virtual/gpio/gpiochip0
--w------- 1 root root 4096 Dec 31 1969 unexport

The gpio11 directory contains a number of pseudo-files for controlling the pin:

# cd gpio11
# ls -l
total 0
-rw-r--r-- 1 root root 4096 Jan 14 18:41 active_low
-rw-r--r-- 1 root root 4096 Jan 14 18:41 direction
-rw-r--r-- 1 root root 4096 Jan 14 18:41 edge
drwxr-xr-x 2 root root    0 Jan 14 18:41 power
lrwxrwxrwx 1 root root    0 Jan 14 18:39 subsystem -> ../../../../class/gpio
-rw-r--r-- 1 root root 4096 Jan 14 18:39 uevent
-rw-r--r-- 1 root root 4096 Jan 14 18:41 value

The files we care about are direction and value. The direction is initially set to input (in), which we can see if we cat the direction file:

# cat direction
in

We can change the pin to an output by writing out into that file:

# echo out > direction

The value file will tell us if that pin is off (0) or on (1):

# cat value
0

If you set this value to 1, the LED should turn on:

# echo 1 > value

If it doesn't, you probably have it plugged in backwards. Switch the wires (I'll wait).

Once the LED is on, you should be able to turn it off by setting the value to 0:

# echo 0 > value

From an educational perspective, this is really cool: it makes a concept (bit) tangible.

But turning the light on and off gets boring quickly. The next step is to write a command-line loop to make the LED blink:

# while true; do echo 1 > value; sleep 0.2; echo 0 > value; sleep 0.2; done

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/value
0

... Now toggle the switch! ...

# cat gpio24/value
1

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:

# while sleep 0.1; do if [ $(<gpio24/value) = "0" ]; then echo 1 > gpio11/value; sleep 0.2; echo 0 > gpio11/value; sleep 0.2; fi; done

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), I²C, 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.

Measuring the Raspberry Pi's Current Consumption

nospam@example.com (Chris Tyler) — Wed, 20 Jun 2012 13:00:07 -0400

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.

2. Cut the 5V supply wire (usually coloured red).

3. Connect your ammeter or multimeter to the cut 5V line.

4. Insert this cable between your AC-DC converter and the USB cable going to your Raspberry Pi.

So, how much current does the Raspberry Pi draw?

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.

New Role: Industrial Research Chair - Open Source Technology for Emerging Platforms

nospam@example.com (Chris Tyler) — Thu, 10 May 2012 11:06:59 -0400

On Tuesday, the Natural Sciences and Engineering Research Council (NSERC) announced a number of grant awards at the Polytechnics 2012 conference, including the new Industrial Research Chairs for Colleges (IRCC) grants. I am honoured to be selected as the chairholder for the NSERC Industrial Research Chair for Colleges in Open Source Technology for Emerging Platforms in the Centre for Development of Open Technology at Seneca College.

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 SBR600 Software 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.

Watch this space for updates!

Element 14's Wonderful Forums Considered Harmful

nospam@example.com (Chris Tyler) — Fri, 09 Mar 2012 12:41:43 -0500

Element 14, the web presence of one of the Raspberry Pi distributors, Farnell, operates a wonderful forum system. However, there is one significant problem with their system: under their terms of use, a person who is under 13 is prohibited from using the forum (and those between 13 and 18 from using it without their parent's explicit consent).

This understandable requirement, probably a result of US legislation (and perhaps legislation in other jurisdictions?), is at odds with the Raspberry Pi's stated focus on children (hence the "considered harmful" jab).

I'd encourage the Raspberry Pi community to use forum and wiki systems that don't exclude the device's target audience from participating! Perhaps Element 14 would consider a revision to their Terms of Use, or a dedicated forum with special rules that would enable children to participate. In the meantime, the Raspberry Pi Foundation's forums and the E-linux Wiki do not have age restrictions on participants.

Open Source Translation Database

nospam@example.com (Chris Tyler) — Thu, 08 Mar 2012 12:36:22 -0500

Andrew Smith has released his Open Source Translation Database project, which contains thousands of open source translation files and can populate new translation files based on previous translations. In the released form this in incredibly useful -- and he has ambitious plans for new features and capabilities such as suggesting strings to be used in new projects based on the number of available translations.

Congratulations, Andrew, on this launch!

Raspberry Pi Fedora Remix 14 - Release Event this Wednesday!

nospam@example.com (Chris Tyler) — Mon, 20 Feb 2012 11:04:45 -0500

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!

Update: Fixed link above.

Gnome Documentation Hackfest

nospam@example.com (Chris Tyler) — Thu, 17 Mar 2011 09:13:46 -0400

For the next six days, CDOT is hosting some members of the of the GNOME documentation team for a documentation hackfest in preparation for the upcoming GNOME 3.0 release. On Friday we're holding an informal lunchtime talk to introduce the Seneca and Gnome communities -- and if you're in the greater Toronto area and are free, you're welcome to join us!

Temperamental Power Supply

nospam@example.com (Chris Tyler) — Wed, 23 Feb 2011 00:25:50 -0500

Today, the ATX power supply for the PandaStack I described in my last post is working happily. I have no idea what changed... which is a bit worrisome.

PandaStack

nospam@example.com (Chris Tyler) — Tue, 22 Feb 2011 09:43:47 -0500

Our "PandaStack" of PandaBoard builders (shown here with 9 of the 15 builders installed) is now ready to run as part of the Fedora ARM build farm. However, I've run into a weird problem -- the ATX power supply I bought to power the boards works fine with 1-3 boards, but Something Bad happens when a fourth board is connected. It's not a capacity issue as far as I can see; it seems to be related to noise. Time to borrow a scope and take a close look at waveforms ... in the meantime, we'll power some of the boards with the ATX supply and some with stand-alone power bricks.

Changing the Open Web

nospam@example.com (Chris Tyler) — Fri, 28 Jan 2011 08:57:54 -0500

My colleagues in the Centre for Development of Open Technology have been doing some amazing work enhancing the open web. One of their libraries, Popcorn.js, enables web video to move beyond being a box on the page to become a part of the hyperlinked, dynamic web. With a ton of frantic hacking by the Popcorn team which began on Tuesday morning (!), PBS launched an interesting web page that night showing analyst's comments synchronized to a video of the US President's State of the Union speech. PBS comments about the effort are posted on The Rundown.

You should check out what these folks are doing with 3D on the web -- the Javascript port of the Processing data visualization language, Processing.js -- point cloud data -- and web audio!

Update: Dave Humphrey has blogged about the work that he and his team did on the SOTU page with PBS.

Fedora, Seneca, and FUDCon Tempe

nospam@example.com (Chris Tyler) — Thu, 27 Jan 2011 01:13:27 -0500

This semester is the fourth time that I've run the Software Build and Release (SBR600) course at Seneca College, and we have record enrollment a full house! This course is one of a number of open source courses connected with the Centre for Development of Open Technology; it is a professional option in our Computer Systems Technology program, which focuses on network and system administration, and it has two goals:

Teach software build and release (aka Release Engineering/Build Team) principles, technology, and skills
Teach how to contribute effectively in an open source community

In this course, I use the Fedora build and release process as a illustration of how large-scale build and release works, something which is only possible because of the transparent nature of open source processes. I also use Fedora as a community which is open to worthwhile contributions from any interested participants. In these first three weeks of the course, we've examined building from source, RPM packaging, the use of mock for build dependency testing, the use of koji for multi-platform testing, signing packages, and creating package repositories. The remainder of the semester is largely project-based.

The students are currently researching and selecting projects from a short list of potential projects which have been screened for manageable size and practical real-world value. This semester, many of these projects are focused on the Fedora ARM secondary architecture, since the ARM buildsystem is physically located at Seneca, but some projects are related to different areas within Fedora (or, in one case, Fedora+Mozilla). In all cases, the students are expected to work with the community, use community communication tools and practices, and ultimately, advance the state of the respective area to which their project contributes. That means that if new software is packaged, it will be put through package review and end up in Fedora; if scripts or programs are written, they will be reviewed and committed upstream; and if documentation is written, it will end up in an appropriate and accessible place such as the wiki.

On Friday, ten SBR600 students will be traveling with Paul Whalen and me to FUDCon Tempe eight students from the current semester and two from the previous semester. They're looking forward to making connections with other Fedorans, hearing about the latest and greatest technology, hacking, and generally starting down the road to becoming active contributors.

Please join us! -- I invite you to check out what we're doing, either in the usual Fedora places or in the #seneca channel on Freenode, on the Seneca wiki, or on Planet CDOT.

Come and Speak at FSOSS 2010

nospam@example.com (Chris Tyler) — Wed, 21 Jul 2010 22:24:09 -0400

The 9th Annual Free Software and Open Source Symposium (FSOSS, "eff-sauce") is coming up on October 28th and 29th, here at Seneca College in Toronto. This is a great event with a wide-ranging, eclectic mix of workshops and presentations.

I've been involved in planning FSOSS for the past few years, but stepped back a bit to catch my breath this year. Mary Lynn Manton has stepped up to the task of chairing this year's event with Rose Saliba, who is co-chairing for her third year.

FSOSS is still looking for interesting workshops and presentations on a variety of open source topics. If you're working with open source in any way, this could be a great opportunity -- please check out http://fsoss.ca and submit a presentation proposal right away!

Seneca and the Fedora ARM Secondary Architecture

nospam@example.com (Chris Tyler) — Thu, 22 Apr 2010 11:04:20 -0400

ARM processors power the digital mobile age. Billions are produced per year, ending up in the majority of cellphones as well as in e-book readers, plug computers, the OLPC XO 1.75, tablets, netbooks, intelligent RJ-45 network jacks, and even microSD cards.

The Fedora ARM Secondary Architecture project has done a great job of porting Fedora releases to ARM. To assist this initiative, this semester's Software Build and Release course at Seneca (SBR600) put together a new Koji build farm for the ARM architecture in preparation for using koji-shadow to follow the primary architectures. It's been a fascinating and challenging project -- working with cross-compilers, emulators, and hardware with much smaller configurations than standard PCs. A large amount of effort was spent benchmarking various configurations to determine optimal memory and storage arrangements and to compare emulated vs. hardware ARM performance to guide the configuration of the build farm.

So now we're at the end of the semester. Where do things stand?

We have a working Koji build system, with two hardware builders plus emulated (VM) builders
Since we're at the end of the semester, things will be quiet for the next week and a half, but then we've hired a graduate to work on this full-time (intros coming up shortly )

What's next? In May-June we expect to:

set up FAS2 certs
add 10+ hardware builders
implement koji-shadow

Clarity in Error Dialogs

nospam@example.com (Chris Tyler) — Sun, 21 Feb 2010 15:37:34 -0500

I've met my share of error dialogs through the years. Ones that say "Something bad has happened. Ok?" are annoying but understandable.

However, one in gpk-update-viewer, which I encountered yesterday, is a real head-scratcher:

This dialog sometimes appears when you try to close the gpk-update-viewer window while updating and it reads:

Cannot cancel running task
There are tasks that cannot be cancelled.
[Cancel] [Quit]

Quite apart from the fact that this dialog shouldn't appear at all -- packagekit will continue the update in the background -- the two buttons appear to mean the same thing, both of which are (according to the dialog) impossible.

(bug 567135)

Update: Richard Hughes noted in the comments that this is fixed upstream

Dear Lazyweb: How can you find a process ID given a window ID?

nospam@example.com (Chris Tyler) — Mon, 23 Nov 2009 15:14:34 -0500

As far as I know, there is no way to reliably get a process ID from an X window ID for local clients (to implement Richard's View Source idea). I would love to be wrong!

Questions:

(1) Did I miss something? Can this be done now?

(2) If this can't be done now, what would it take? Could we create an X extension so that the server can supply connection info for a window, and then trace that connection info back to a specific process?