Raspberry I/O galore in new Gertboard video

FYI - the RaspberryPi.org blog has just posted with a link to download the software for the Gerboard:

http://www.raspberrypi.org/archives/960

Gert has had a lot of requests from you guys for the software used in the last Gertboard video (Gertboard, for those who are new round here, is a GPIO expansion board you can use to get your Raspberry Pi to drive motors, lights, sensors and all that good stuff.)

 

For now, you can download the Gertboard software here

A cursory look shows that it is written in C and appears to use memory mapping to interface with the ARM peripherals.  In addition to LEDs and buttons via GPIO, it includes an example of interfacing with an external ADC and DAC via SPI.  It also show how to use the ARM's built-in PWM capability (including some nice ASCII art).

Cheers,

Drew

I took a quick look at the C code too, which incidentally compiles fine on an Intel Linux box as well.

This is the kind of program that should never be run on a Linux machine, as it contains timing loops and polls and busy waits, burning up CPU instead of being I/O event-driven like all good Unix programs should be.

(It's just a demo of course, which is fine in itself, but the trouble is, people take demos and extend them into non-demo applications which preserve all the problems of the demo code.)

It's because of problems like this that the Gertboard has a microcontroller of its own.  The general idea is that you put timing loops, polling and busy waiting down in the micro where it can be done with good realtime constraints, only occasionally sending I/O events back to the Rpi where the user-space program waits passively on a file descriptor.  That way you don't suffer all the poor timing and latency issues of Linux user space, and you don't burn up CPU in wasted loops on the host machine.

Issues like this will become an integral part of the technical education which the Rpi is intended to provide.  Expose our youngsters to the right way of doing things and we'll end up with better engineers in times ahead.  The opposite is also true.

See also: http://en.wikipedia.org/wiki/Busy_waiting

I took a quick look at the C code too, which incidentally compiles fine on an Intel Linux box as well.

This is the kind of program that should never be run on a Linux machine, as it contains timing loops and polls and busy waits, burning up CPU instead of being I/O event-driven like all good Unix programs should be.

(It's just a demo of course, which is fine in itself, but the trouble is, people take demos and extend them into non-demo applications which preserve all the problems of the demo code.)

It's because of problems like this that the Gertboard has a microcontroller of its own.  The general idea is that you put timing loops, polling and busy waiting down in the micro where it can be done with good realtime constraints, only occasionally sending I/O events back to the Rpi where the user-space program waits passively on a file descriptor.  That way you don't suffer all the poor timing and latency issues of Linux user space, and you don't burn up CPU in wasted loops on the host machine.

Issues like this will become an integral part of the technical education which the Rpi is intended to provide.  Expose our youngsters to the right way of doing things and we'll end up with better engineers in times ahead.  The opposite is also true.

See also: http://en.wikipedia.org/wiki/Busy_waiting