Chris Tyler's Blog - Seneca Planet

Looking for a Debugging Mentor

nospam@example.com (Chris Tyler) — Wed, 20 Feb 2013 13:12:46 -0500

I'd love to figure out why my Toshiba Z830's screen-brightness controls work fine after suspend but don't work after hibernate with Fedora 17 (I have two-phase suspend/hibernate set up). I'm comfortable doing debugging but don't even know where to start on this one -- I don't know which subsystems to poke at.

Anyone willing to mentor me through this?

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.

SBR600 - Winter 2013

nospam@example.com (Chris Tyler) — Mon, 17 Dec 2012 00:19:23 -0500

The SBR600 Software Build & Release course provides a unique opportunity for Seneca CTY students to get involved with an open source community. However, for the Winter 2013 semester, we opened the course late, so not very many students are aware that it's available.

If you're interested in taking SBR600, or know anyone who is: SBR600 is available for the Winter 2013 semester through SIRIS.

The OSTEP Team

nospam@example.com (Chris Tyler) — Wed, 28 Nov 2012 23:34:47 -0500

The Open Source Technology for Emerging Platforms (OSTEP) team at Seneca consists of four research assistants who work with me on projects related to enabling Linux and related open source technologies on emerging ARM systems - specifically working with the Fedora ARM Secondary Architecture initiative.

Since I haven't had an opportunity to introduce the team recently, I thought I would (very briefly) do so here.

Andrew Green (agreene) is our repo guru and is currently composing and testing the Raspberry Pi Fedora Remix 18. He is working part time with the OSTEP team while completing the CTY program at Seneca.

Dmitry Kozunov (DarthJava) works full-time with OSTEP. His main area of responsibility is the Fedora ARM buildsystem infrastructure, which means he wrestles heroically on a daily basis with unstable dev boards and multi-terabyte backups. He will be continuing his studies in the Seneca IFS program in January.

Jon Chiappetta (fossjon) is working full-time on a zippy armv6hl optimized build for the Raspberry Pi, and simultaneously experimenting with alternate approaches to koji queueing for secondary architectures. Jon is a graduate of our IFS program and our resident Python pro.

Jordan Cwang (frojoe) is a graduate of the Seneca CTY program and works part-time with the OSTEP team on infrastructure issues. He's is our bcfg2 whiz and is currently working on several infrastructure projects including improving security with measures such as two-factor authentication.

When is an SRPM not Architecture-neutral?

nospam@example.com (Chris Tyler) — Fri, 23 Nov 2012 22:13:55 -0500

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.

Edit: I know that not all of our tools take this into consideration.

Continue reading "When is an SRPM not Architecture-neutral?"

Interested in buying a Raspberry Pi?

nospam@example.com (Chris Tyler) — Mon, 10 Sep 2012 17:17:44 -0400

I'm trying to gauge interest in being able to buy the Raspberry Pi at the Seneca Bookstores (no promises!). Please take a second and let me know what you think using this poll...

customer survey

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 links

nospam@example.com (Chris Tyler) — Wed, 29 Feb 2012 17:38:21 -0500

The Raspberry Pi hardware went on sale last night, and as with every other event related to the Pi, pandemonium ensued!

The educational, tech, and mainstream media is starting to take note. Here are some links to local coverage of the Pi and our work on the software for it:

Update 2012-03-03 - additional links:

Radio Canada International - Masala Canada
CBC News - Lang and O'Leary Exchange (segment starts at 47:05)

Update 2012-03-10 - additional links:

MindShare Learning Report - March 2012

To clarify Seneca's involvement, because it may not be clear from the press coverage:

The Raspberry Pi Foundation created the Raspberry Pi hardware, and has licensed its production to a pair of UK-based production and distribution companies, Farnell (which has wordwide subsidiaries including Newark here in Canada) and RS Components (Allied Electronics in Canada).
The Centre for Development of Open Technology (CDOT) within Seneca College works with the Fedora ARM group within the Fedora Project to produce a build of Fedora for ARM devices. One of our roles is the creation and operation of the build system, a cluster of more than 60 ARM-based computers used to build the ARM software.
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.

Information about the Remix may be found on the Seneca CDOT wiki.

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.

Seriously, CBC?

nospam@example.com (Chris Tyler) — Sat, 28 Jan 2012 12:51:44 -0500

Going to the CBC this morning, I found this:

I have three problems with this:

The CBC is our public broadcaster, funded in large part by tax money. It should support wide access.
I'm not running IE, I'm running Firefox. The ad is lying to me. If they're able to detect I'm not running the latest version of IE, they should also detect that I'm not running IE at all. My browser is not old, either -- I'm running the latest release of Firefox, which contains several features not yet supported by IE.
IE does not run on my platform (Linux). The ad is a waste of time for me and a waste of money for the advertiser. The pages to which the ad links are all specific to Windows, with no consideration for those running Mac OS/X, Linux, or any other platform.

The ad text seems to imply endorsement. Does the CBC actually endorse the position that the only acceptable end-user computing platform is Windows on an x86 computer? Is increasing the monopoly of a foreign corporation a suitable goal for a taxpayer-funded public broadcaster? I trust not.

Fedora ARM on the Raspberry Pi at Seneca CDOT

nospam@example.com (Chris Tyler) — Wed, 19 Oct 2011 16:53:37 -0400

What happens when you combine a $25/$35 computer, a major Linux distro's secondary arch effort, and a college that's deep into open source?

You get Fedora-ARM running on the Raspberry Pi at Seneca CDOT!

Here's a tiny video peek...

&amp;lt;/p&amp;gt;

&amp;lt;/body&amp;gt;
&amp;lt;/html&amp;gt;

There's a lot of optimization still to be done (including X11) but look forward to a Raspberry Pi Fedora image (spin/remix), Fedora 15 for ARM, and the Raspberry Pi device itself all being available next month.

(In or near Toronto? There are three talks related to Fedora ARM and/or the Raspberry Pi at FSOSS next week).

Gnome 3: Not Ready for Prime Time in Fedora 15

nospam@example.com (Chris Tyler) — Sat, 23 Apr 2011 12:19:17 -0400

I've been intrigued by the Gnome 3 desktop and the design decisions that the Gnome project has decided to test. Hearing some members of the Gnome community explain the design decisions in person was very interesting, and helpful when transitioning to the Gnome shell. And I'm proud that the Fedora Project is continuing to lead by incorporating new technologies and designs First.

But I've been using Gnome 3 in the Fedora 15 alpha and beta releases for a while now, and I'm convinced that Gnome 3 is not ready for prime time yet, at least as implemented in Fedora 15 (and this is completely separate from the issue of whether the Gnome 3 design changes are good or bad, and whether the Gnome community is ignoring the needs and wants of the users and downstreams -- both subjects of much debate). As one example, multi-monitor setups are not working as expected, at least for me. In fact, it's a stretch to say that they're working at all:

On my laptop/netbook, logging in with an external monitor connected results in Gnome 3 running in degraded mode, with Gnome 2-style menus. Logging in without an external monitor connected, and connecting it after login, results in a usable configuration - at least all of the real estate is accessible.
I run with the external display above my laptop. Maximizing a window on the external display results in it filling the rightmost 1/3 of the screen. Unmaximized windows may be moved, but only to positions where the right edge of the window is within the right-most 1/3 of the screen. You can fill the screen by placing the window all the way to the right and dragging a corner to the left side, though. There are many other behaviours which are just weird.
The Activities button is on the laptop screen, but the touch-to-activate-Activities corner is on the external monitor.
Rearranging the position of the monitors using the Displays setting tool results in badly torn, messed up images. They resolve to something that looks almost usable a fraction of a second before the Does this look right? dialog gives up and reverts me to the original configuration, with my desktop backgrounds missing.

This is 2011, and multi-monitor configurations are not a novelty any more. In fact, they're the norm where I work, and I use external monitors with my laptops and netbooks all the time

Perhaps some of these issues are video driver problems, and Gnome 3 isn't to blame. But the problems with Gnome 3 are not limited to just multi-display configurations; for example: GDM's list of users does not scroll properly when the list is long (I went to file a bug on that one, but was disheartened searching through the 253 other open Fedora GDM bugs to see if it was already reported). If something goes wrong during the login process, a message appears telling you that something went wrong, but offering no way to find out what went wrong -- not even through a "Details..." button -- and the only action available to the user is to click a button marked "Ok" (I can't login? It's definitely not OK). The icons at the top of the screen respond to left- and right-click in the same way -- except for the iBus icon -- where's the consistency in that?

I don't want to be a gloomy Eeyeore (though I understand the temptation to become one) but I really don't think we're close to release-ready with Gnome 3 in F15.