Dear Ned and Thierry,
Thanks to the both of you for your replies!

Ned: my situation is exactly that which you describe, whereby I require 1-direction data transfer between the ATMEGA (master) and gumstix (slave), at a regular 100Hz. However, due to my inexperience in dealing with drivers I will try to make do with using the Gumstix as the master.

Thierry: I am trying to follow your instructions in the final post of this thread (,-spidev,-et.-al-to24588398.html#a24594755). It seems that before the
"git diff diff --git a/recipes/linux/linux-omap3-2.6.30/overo/defconfig b/recipes/linux/linux-omap3-2.6.30/overo/defconfig"
command, a patch needs to be run. Is that the same one as from the beagleboard site you mention? The title of that patch implies it should configure the SPI3 bus, not the SPI1 bus I need. Please could I trouble you for a brief guide on how to apply the patch?
Sadly I'm feeling a little lost in the dark here, so any help would be much appreciated!

Best regards,

On 23/08/2010 17:24, Ned Forrester wrote:
On 08/23/2010 10:55 AM, Hugo Grimmett wrote:
  Hi there,

I'm a new gumstix user trying to configure the SPI protocol. The only 
gumstix documentation I can find is the sample code on this page 
( which doesn't seem to be 
quite what I need.
A couple of questions:
1. I'm using the 40-pin header on the Tobi expansion board, which has 6 
GPIO pins prefixed with _SPI1_, to which I have wired an ATMEGA328P. The 
sample code is configured for use of the NSSP pins, of which I can find 
no mention elsewhere. How do I adapt the code to work on the 
SPI-tailored GPIO170-175 pins?
Others will be able to help with the hardware.  I only use the PXA

2. I really need to run the Gumstix as the SPI slave, with the 
ATMEGA328P chip as host and initiating data transfers. What do I need to 
change to make this possible?
There is no SPI slave implementation for Linux, and likely never can be,
for the reasons periodically discussed on the mailing list:

You can search the list for references to "slave" to read the discussion
at its home page:

but it is not very searchable.  So...

Search Google for this pair of phrases:
"spi-devel-general" "spi slave"

The basic problem is that an SPI slave device is often required to
respond to a request within one SPI clock cycle (the master sends the
register address, and immediately expects to clock out the register
contents).  Linux (and likely every other operating system) is incapable
of that response time.

However, slave operation is possible in certain circumstances, either
when the devices involved don't require an immediate response, or when
the next transfer on the bus can be predicted in advance.  An example of
the latter case is where there is only one master and one slave on the
bus, and the master always sends data to the slave; thus the slave can
predict that the next transfer on the bus will require it to receive
data, and it can always have a buffer ready to be filled.

I have an application that works just that way: a device continuously
streams data at 11Mbit/s and Linux receives that data.  The driver (a
heavily modified version of pxa2xx_spi.c) maintains a queue of empty
buffers, and uses DMA descriptors to chain DMA transfers to those
buffers.  Interrupt service is required to maintain the queue of
buffers/DMA-descriptors, but no interrupts are required put data in a
buffer nor to shift to the next buffer (all handled by DMA).

In any case, even if your application can use Linux as a slave, you will
likely have to write a device driver, or modify an existing one, to get
the specialized functions that you need.