From: Hugo G. <hu...@ro...> - 2010-08-30 16:19:35
|
Dear Thierry, Oh ok, I thought I read somewhere that Spidev was only capable of "half duplex", but that must have been referring to something else. How much of the protocol does Spidev handle? For example, do I need to manually set the CS pin high and low? It would be really useful to have some sample code for the gumstix which uses Spidev. Do you know where there is some available? It must surely exist, but as of yet I have failed to find any..! Best regards, Hugo On 30/08/2010 12:56, Thierry Genovese wrote: > Hi Hugo, > > Half-duplex does not really exist for SPI as far as I know. There is > always a bit received when a bit is sent by the master. If you only > want to write, just ignore the received bits. If you only want to > read, have the master send enough 0 bits (or random bits) and use only > the received bits sent by the slave. > > I think that if you only want to read or write with spidev, you can > use read and write calls on the /dev/spidev handle and avoid using > ioctl altogether. Internally it does exactly the same but sends 0 or > ignores the received bits as needed. > > Regards, > > Thierry > > > On Mon, Aug 30, 2010 at 12:30 PM, Hugo Grimmett<hu...@ro...> wrote: >> Dear Thierry and Gumstix, >> >> I'm so nearly there, but I have come up short on the last hurdle: writing a >> script to make use of SPIDEV and communicate with the atmega328P. My code so >> far is derived from the SPIDEV documentation here >> (http://www.mjmwired.net/kernel/Documentation/spi/spidev), but it doesn't >> desribe how to initiate reads and write cycles, only how to set up the bus >> for communication. How does the protocol work with respect to half-duplex >> transmission? >> In full-duplex mode, which is not required for my project, I understand that >> for each SPI clock cycle, >> 1. The master sends out a bit, which is read by the slave, and >> 2. The slave send out a bit, which is read by the master. >> >> How is half-duplex transmission different, and how do I use the ioctl >> command to read from the atmega slave? >> >> So far my code is the following: >> >> ------------------------------------------ >> #include<fcntl.h> >> #include<unistd.h> >> #include<sys/ioctl.h> >> #include<linux/types.h> >> #include<linux/spi/spidev.h> >> >> >> int main(int argc, char *argv[]) { >> int file; >> char filename[20]; >> >> int i2c_addr = 0x2F; >> char buf[64]; >> char write_buf[2]; >> unsigned short x; >> long m[3]; >> >> // Open SPI1 bus with CS0 >> sprintf(filename, "/dev/spidev1.0"); >> if ((file = open(filename, O_RDWR))< 0) >> { >> printf("Couldn't open SPI1 bus with CS0\n"); >> exit(1); >> } else { >> printf("%s\n",filename); >> } >> >> // Set SPI mode = 1 >> if (ioctl(file, SPI_IOC_WR_MODE, SPI_MODE_0)< 0) >> { >> printf("Couldn't set SPI mode\n"); >> exit(1); >> } >> >> // Read back SPI mode >> if (ioctl(file, SPI_IOC_RD_MODE, SPI_MODE_0)< 0) >> { >> printf("Couldn't set SPI mode\n"); >> exit(1); >> } >> >> // INSERT CODE TO READ FROM SLAVE HERE >> >> } >> ------------------------------------------ >> >> Thanks to all for the help so far! >> >> Hugo >> >> >> >> >> On 24/08/2010 19:22, Thierry Genovese wrote: >>> 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 >>>> >>>> |