Re: [Gumstix-users] SPI basics

[Thierry G. <t.g...@gm...>]

Hi Hugo,

Don't bother with the patch for BeagleBoard. Most of it has been
merged already. To enable spidev:
 * it must be enabled in the kernel config: the defconfig file. I
think it is already enabled in the Gumstix defconfig, so nothing to do
here.
 * u-boot must be configured with the proper muxing for the SPI pins:
that is already done in the Gumstix u-boot, nothing to do here either
 * you need to declare the properties of the SPI link you want: bus,
cs, freq, etc... This is done in a kernel source file called
board-overo.c. I do not think it is done in the latest kernels, so you
will have to create a patch for this file and add it to the kernel
bitbake recipe to patch the file when the kernel is built.

For example, this post:
http://old.nabble.com/spidev-tp27230456p27241022.html contains a patch
for the 2.6.32 kernel and the modifications to the 2.6.32 kernel
bitbake recipe. I haven't updated to 2.6.33 and 2.6.34 so I do not
have a patch ready to share. The patch for 2.6.32 will likely not
apply to newer kernels, but all it does is add an entry in the spi
info array. There are already entries in the array for the
touchscreens, so it should be easy to find.

Gotcha: the SPI busses are used by the touchscreen controllers on the
expansion boards that support them, so if you don"t use touchscreens,
I recommend you disable them in the defconfig, to avoid conflicts (in
the 2.6.32 kernel the touchscreens entries were conditionally added to
the spi info array based on the defconfig values, so I just disabled
them).

Hope this helps. Don't hesitate to ask if you are stuck.

Regards

Thierry

On Tue, Aug 24, 2010 at 1:24 PM, Hugo Grimmett <hu...@ro...> wrote:
> 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
> (http://old.nabble.com/SPI,-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,
> Hugo
>
>
> 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
> (http://docwiki.gumstix.org/Sample_code/C/SPI) 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
> processors.
>
> 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:
>
> spi...@li...
>
> You can search the list for references to "slave" to read the discussion
> at its home page:
> https://lists.sourceforge.net/lists/listinfo/spi-devel-general
>
> 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.
>
>
> ------------------------------------------------------------------------------
> Sell apps to millions through the Intel(R) Atom(Tm) Developer Program
> Be part of this innovative community and reach millions of netbook users
> worldwide. Take advantage of special opportunities to increase revenue and
> speed time-to-market. Join now, and jumpstart your future.
> http://p.sf.net/sfu/intel-atom-d2d
> _______________________________________________
> gumstix-users mailing list
> gum...@li...
> https://lists.sourceforge.net/lists/listinfo/gumstix-users
>
>