Raspberry I/O galore in new Gertboard video

The MAC is not on the SOC; it's part of the USB Hub. Not exactly ideal, latency-wise.

The SPI is documented here: http://www.element14.com/community/docs/DOC-43016/l/broadcom-datasheet-for-bcm2835-soc-used-in-raspberry-pi

Ah, thanks for pointing that out about the high precision realtime control.  I'm a Linux user and have worked with microcontrollers, so I've been excited at the prospect of using Linux in embedded projects.  The BeagleBone and Pi videos I've seen make the GPIO with Linux look great, but I wasn't considering the difficulty of getting timing correct when it matters.

And thanks for the Maple IDE link.  I hadn't realized that is so closely resembled the Arduino IDE.  I had thought only Digilent/Agilent had accomplished that level of software compatibility so far.  Looks like Maple is a better route for Arduino on ARM than the Arduino DUE (which seems missing in action).

Thanks,

Drew

All of you above seem to have a *very* in-depth knowledge of interfacing devices like this - do you have any suggested guides for a newbie ? (Me)

I have an Arduino or two and also a Picaxe board and one of the things I was interested in doing with the Pi was interfacing to sensors.

Any suggestions gratefully received, please be gentle with me.

Thank you.

Steve

Steve, if you have some Arduinos then the absolutely epic series of tutorials at http://tronixstuff.wordpress.com/tutorials/ is a must-read.  And lucky lucky you , the answers to your question are right there:

    SPI bus - https://tronixstuff.wordpress.com/2011/05/13/tutorial-arduino-and-the-spi-bus/

    I2C bus - http://tronixstuff.wordpress.com/2010/10/20/tutorial-arduino-and-the-i2c-bus/

That guy really deserves a medal.

PS. If you search for "I2C" in his list of tutorials, you'll find 3 chapters about it, an Intro, the Part One I linked, and a Part Two.

PS2. Since we're on Element 14's website, it's nice to give Jeremy Blum a plug for his very easy to follow video tutorial on I2C + Arduino, as he's sponsored by Element 14 --  https://www.youtube.com/watch?v=GJX0BRUagCg  --, as well as the Element 14 Arduino group which is full of excellent info --  www.element14.com/.../arduino  .

Morgaine.

Thank you Morgaine those links look extremely useful and exactly what I am after.

Looks like I'll have plenty of time to learn whilst I'm waiting for the pi to arrive...

Steve

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

GertBoard, the Raspberry-PI IO breakout board is an Arduino !?

I think I'm lost.

Upvote for Morgaine for all his good references

There is a DIP socket which could accomodate an ATMega168 or ATMega328 which makes it possible to act as an Arduino.  However, the examples in the video (and download) are just using the Broadcom SoC ARM processor directly to interact with the components on the Gertboard.  It appears that that the C program accesses ARM periphials like the GPIO port via memory mapping.

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