Chris Tyler's Blog - Teaching

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.

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!

StudentProject keyword in Fedora Bugzilla

nospam@example.com (Chris Tyler) — Wed, 11 Nov 2009 10:33:55 -0500

One challenge of teaching inside an open source community is finding projects which are appropriately for students to work on: they shouldn't be really trivial, because that won't provide a challenge or allow the student to engage with the community; they can't be huge, or the student won't finish them within the semester; and they can't be blockers or part of the critical path to a release, because the student may not be able to complete the project on the community's timeline.

My colleague David Humphrey introduced a new keyword into the Mozilla bugzilla tracker last spring, and it has been successfully used to identify many potential student projects (108 at the time of writing).

Good ideas are worth copying -- and since I'm bringing students into the Fedora community, and the POSSE-APAC professors will bring even more, I asked Dave Lawrence to add the StudentProject keyword to the Fedora/Red Hat bugzilla (thanks Dave and Paul!).

Your help in adding this keyword to any appropriate Fedora bugs you file, triage, or notice would be appreciated. Let's aim to identify 100 suitable bugs by FUDCon!

Kids vs. Students

nospam@example.com (Chris Tyler) — Sat, 07 Nov 2009 22:57:31 -0500

Last week, at both FSOSS and the Teaching Open Source Summit, I heard a word that jarred me slightly, because I had dropped it from my professional vocabulary a number of years ago: "Kids".

I stopped using the word "kids" to refer to students for several reasons -- including the fact that I had a student twenty years my senior, and another who was a fully accredited Civil Engineer in his home country -- but the main reason that I dropped it was that it is simply incompatible with the way open source communities work. In open source, roles are defined by contribution, not age or formal training. Some of the youngest members of the community are the most active, and make crucial and valuable contributions.

If we're teaching inside open source communities, then it's important that we value students as full members of those communities -- and I think that the term "kids" is dismissive of their abilities.

Professor's Open Source Experience - POSSE - This Week

nospam@example.com (Chris Tyler) — Sat, 18 Jul 2009 23:53:22 -0400

The first edition of Red Hat's POSSE program -- Professors' Open Source Summer Experience -- kicks off tonight (Sunday) and continues through Friday. Based on the premise that Open Source is best taught by someone with one foot in the academic world and one foot in an open source community, this week will be an immersive experience for five professors from around North America.

I look forward to teaching this program with my colleague David Humphrey (also from Seneca). It's going to be an intense learning experience for us as well, because we've never passed along our open source teaching model in a bootcamp format.

The brainchild of Greg DeKoenigsberg, POSSE's goal is to pilot a person-to-person approach to spreading the teaching of open community-based open source, and to be the first in a long line of professors' bootcamps around the world.

Working in the Open, in the Open Source Way

We'd love to have you join us online during POSSE. You can follow the play-by-play via @posse2009 on Twitter, or better yet, interact directly with the participants on the #teachingopensource-posse channel on the Freenode IRC network. Because we're teaching community-based open source, you will also see the POSSE participants popping up in various open source projects, including Mozilla and Fedora.

Help Wanted: Fedora Packaging Sponsors

We're going to be doing some Fedora packaging. If you're a Fedora packaging sponsor and have a bit of time later this week to accelerate some FE-NEEDSPONSOR cases, I'd appreciate your help Wednesday onward. Ian Weller (who is himself a packaging sponsor) and I will be working directly with the participants and doing initial reviews.

TeachingOpenSource Conference Call - Monday July 6

nospam@example.com (Chris Tyler) — Fri, 03 Jul 2009 11:46:08 -0400

The monthly TeachingOpenSource conference call is coming up on Monday. The focus of this call will be the textbook project that Greg DeKoenigsberg is starting up, and we'll also have an update on the Teaching Open Source Summit '09 (TOSS09) and other TOS projects.

The calls are open to everyone, so if you're in any way involved with or interested in the teaching of community-based open source, please feel free to join the call -- and if you're not already part of the TeachingOpenSource.org community, please jump right in!

Continue reading "TeachingOpenSource Conference Call - Monday July 6"

POSSE (Professors' Open Source Summer Experience) - Application deadline approaching!

nospam@example.com (Chris Tyler) — Sat, 28 Mar 2009 23:27:00 -0400

Greg DeKoenigsberg's POSSE program -- Professor's Open Source Summer Experience -- is a week-long immersion in the world of community-based open source open to any professor teaching programming.

This is a fantastic opportunity to get up to speed on open source development: working (1) at scale, on large codebases used on production systems, and (2) in community, collaborating on a global scale and leveraging the network effects of an open source community.

The application deadline for POSSE is this Friday, April 3. Red Hat is picking up all costs except for transportation -- you just have to get yourself there. Don't delay: read the wiki page and send your application!

TeachingOpenSource.org is Online

nospam@example.com (Chris Tyler) — Wed, 04 Mar 2009 12:00:00 -0500

Teaching community-based Open Source software development is a surprisingly difficult task. Many educational institutions, open source projects, and companies have started educational initiatives, but these exist in isolation.

To enable and empower collaboration across boundaries, and after extensive consultation, I announce TeachingOpenSource.org, a neutral collaboration point for everyone and everything involved in Teaching Open Source.

As a collaboration point, the success of this initiative depends on participation -- so if you have any interest in seeing Open Source taught effectively in our college, universities, and schools, please jump in!

High Schools are Not Preparing Students for Computer Studies

nospam@example.com (Chris Tyler) — Wed, 21 Jan 2009 21:39:00 -0500

My second daughter is about to enter High School, and we're trying to choose between two different high schools. During an Open House at one of the schools, I saw a room with some robotics set up, so I stopped in. The teacher was explaining to some other parents that "programming is often associated with electronic design", which piqued my interest. On the screen was a simple helloworld-class program written in Turing.

When my turn came to speak to the teacher, he explained that programming was part of their tech stream, and that students could take programming starting in grade 10. According to a diagram handed to me, students would enter the programming course after having taken an introductory tech course in grade 9 -- which is a basic overview of wordworking, electricity, a bit of metalwork, and some drafting (though a quick peek at the Ontario Ministry of Education website shows that the grade 10 course has no prerequisite). The teacher explained that they taught using Turing, and in the later courses students may be able to do some work in C/C++ or Java. Alternately, there are business computing courses, which teach students how to use popular productivity applications, and digital media arts courses, which cover multimedia applications.

This is bad on so many levels.

Turing is a proprietary language. It has only ever been used for teaching in Ontario high schools and has never been used for any significant real-world software development. It was never Free Software or Open Source (libre) and only became free software (gratis) when the company distributing it, Holt Software, ceased operations in 2007. The website for Holt Software (from which the software could be downloaded) appears to have gone offline, as has the website for the OpenT project, an open source reimplementation/superset. Although students can learn basic programming concepts with Turing, they will have to learn another computer language in order to program in any other context.

Many computer programmers are not involved in electronics design, woodworking, metalwork, or drafting. Few of my colleagues or students are into electronics design. There seems to be little or no recognition of connections between programming and logic, math, or language in the Ontario high school curriculum.

The question in my mind: do we fix this? Or route around it?

(Fortunately, not all Ontario students face these issues... for example, my friend Ernie Carmichael was teaching Python six or seven years ago at a Toronto-area private school, and I have recently had one of his students in my LUX class, having earned a bachellors in Phillosophy and picked up a couple of courses in logic since studying with Ernie).

Teaching Open Source - Getting on the Same Page

nospam@example.com (Chris Tyler) — Thu, 30 Oct 2008 09:40:28 -0400

Last week at FSOSS we had a great track on Teaching Open Source. Greg's solid blog post from yesterday outlines some of the challenges and has set the ball rolling on a "Coalition of the Willing" (which I've expanded slightly -- you've got to love wikis).

I believe that Code Development is a form of Research, and that Open Source is Peer-Reviewed Publication. If those two statements were widely accepted, teaching Open Source would be a lot more paletable to many university professors. We must advance that position while accommodating the transition: in comments on Greg's posting, Dr. Jef Spaleta noted the need for a peer-reviewed journal on Open Source. I believe this could be a very positive interim step. (Jef, are you going to make it happen?)

In the shorter term, we need to ensure we understand one another when talking about teaching Open Source, and its become painfully obvious that the participants in many conversations are not even on the same page in terms of what it means to teach Open Source. In an attempt to help sort this out, I've created a rough sketch of a taxonomy of Open Source education. Please take a look and join the discussion.

"Open Source" is not "Open Systems"

nospam@example.com (Chris Tyler) — Sat, 08 Sep 2007 11:08:43 -0400

In the past couple of weeks, I've heard several of my colleages refer to Open Source as Open Systems. I thought that this was a slip of the tongue, but since it's happened several times and by people of sufficient ... experience ... to remember Open Systems (as I do), I'm not so sure that the distinction is being made. To clarify:

The term Open Systems was used, primarily in the 1980's, to refer to systems that were hardware-and-software interoperable between different vendors and therefore avoided vendor lock-in (with varying degrees of success). Standards such as POSIX, SVID, and the Single Unix Specification provided source-code portability, and network standards such as TCP/IP provided network interoperability. However, Open Systems were still often proprietary, did not include source code, and were generally Unix-centric.
Open Source is software for which the source code is freely distributed (though the term is actually more formally defined). This software may be any type of program: an operating system, applications for an iSeries system, utilities for a Windows system, or games for a Mac. Since source code is provided, the software can be further enhanced and developed, and derivative works can be created.

There's not really much in common between the two. For good measure, one more definition:

Free Software is Open Source software protected by Copyleft licensing so that access to source code and freedom to use that code is preserved for recipients of derivative works. This is also formally defined.

You are Officially Lost

nospam@example.com (Chris Tyler) — Wed, 01 Aug 2007 13:54:06 -0400

Found in the pamscale(1) man page:

If you dont know what the mathematical concept of convolution (convolving) is, you are officially lost. You cannot understand this explanation.

Is this pointing out a shortcoming of the author or the reader? I'm sure you could make an argument either way.

CDOT Open Source Reception

nospam@example.com (Chris Tyler) — Tue, 22 May 2007 12:33:21 -0400

There are some amazing open source projects taking place at Seneca College (where I teach):

David Humphrey has developed one of the first courses anywhere dealing with the how of open source, focusing on the processes, community, and models that make open source work. Club Moz is a student group that sprang out of this course.
The ISA graduate certificate program has been teaching open source system administration (Linux admin, including key server apps and the open source desktop) for a number of years.
Students have built a Freedom Toaster, added Windows support to distCC, coded the first APNG implementation, added XML tags for manipulating Canvas objects in Firefox, performed comparative benchmark testing of Xen paravirtualization and hardware-assisted full virtualization, and made many other contributions to open source projects.

There are dozens of other open source initiatives underway, and many different partnerships with open source projects, companies, and other educational institutions. We're concentrating these initiatives under the umbrella of the Seneca College Centre for Development of Open Technology (CDOT).

On June 7, CDOT is hosting a wine and cheese reception to showcase our work, describe where we're headed with open source, and discuss partnership opportunities. There may be room for a few more guests, so if you're in the Toronto area and are interested in attending, drop me a line.

Great Conference

nospam@example.com (Chris Tyler) — Thu, 27 Oct 2005 21:33:19 -0400

I attended the 4^th Annual Seneca Free Software and Open Source Symposium on Monday. It was fantastic! -- lots of practical information about open source projects that are of interest to educators, both in the classroom and in administration, as well as the state of the FOSS and Open Content movements. Special thanks to the organizer, Bob Boyczuk, and the others at Seneca who made it happen.

If you're using Free Software or Open Source in Ontario, particularly in education, you owe it to yourself to circle this event on your calendar next year.