From: Hugo G. <hu...@ro...> - 2010-08-23 14:56:07
|
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? 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? Many thanks, and please go easy, my experience with linux is limited! Hugo |
From: Thierry G. <t.g...@gm...> - 2010-08-23 15:46:01
|
Hi, The wiki page you mention targets the PXA-based motherboards. For the newer OMAP-based Overo COMs, there is a new wiki: http://www.gumstix.net/wiki with a page that might help: http://www.gumstix.net/wiki/index.php?title=Category:SPI I suspect your ATMega328 is configured to use 3.3V or 5V IO level. Please remember that the IO level on the Tobi is 1.8V: you will need level shifters. As for running the Overo as SPI slave, I believe the Linux kernel does not support it at this time. Regards, Thierry On Mon, Aug 23, 2010 at 4:55 PM, Hugo Grimmett <hu...@ro...> 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? > > 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? > > Many thanks, and please go easy, my experience with linux is limited! > > Hugo > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by > > Make an app they can't live without > Enter the BlackBerry Developer Challenge > http://p.sf.net/sfu/RIM-dev2dev > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > |
From: Ned F. <nfo...@wh...> - 2010-08-23 16:44:49
|
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. -- Ned Forrester nfo...@wh... Oceanographic Systems Lab 508-289-2226 Office / 774-392-5352 Cell Applied Ocean Physics and Engineering Dept. Woods Hole Oceanographic Institution Woods Hole, MA 02543, USA http://www.whoi.edu/ http://www.whoi.edu/sbl/liteSite.do?litesiteid=7212 http://www.whoi.edu/hpb/Site.do?id=1532 |
From: Hugo G. <hu...@ro...> - 2010-08-24 11:25:01
|
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. > |
From: Thierry G. <t.g...@gm...> - 2010-08-24 18:22:57
|
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 > > |
From: Benny B. S. <bb...@se...> - 2010-08-24 19:30:42
|
> 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). > > Unfortunately disabling the touchscreen in SW won't be enough. SPI can't be used on the external 40 pin header on a board which support touchscreen because of the way Gumstix has made the level conversion. SPI1_MISO (GPIO173) SPI1_NIRQ (GPIO114) is connected to a 164245 which always actively drives those signals. /Benny |
From: Hugo G. <hu...@ro...> - 2010-08-26 16:26:42
|
Dear Thierry, Thanks for your help, I do have a couple of questions: In the defconfig file it says "Automatically generated make config: don't edit". How then do I make sure the touchscreen is disabled? Also, can I just run the patch for the 2.6.32 kernel even though the most up-to-date version is 2.6.34, or does it need to be in the linux/linux-omap3-2.6.34 folder and some values changed? At the moment I have just put it into the linux/linux-omap3-2.6.32 folder as per the instructions in your linked post. Many thanks, 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 >> >> |
From: J. L. <vwy...@gm...> - 2010-08-26 20:53:59
|
Here is a howto for you to be able to change your kernel. http://www.gumstix.net/wiki/index.php?title=Kernel_Reconfiguration Hope that helps, it will give you the new defconfig, though I have just edited the file directly before and had it work but I am sure that is not a good way to do it. On Thu, Aug 26, 2010 at 9:26 AM, Hugo Grimmett <hu...@ro...> wrote: > Dear Thierry, > > Thanks for your help, I do have a couple of questions: > > In the defconfig file it says "Automatically generated make config: > don't edit". How then do I make sure the touchscreen is disabled? > > Also, can I just run the patch for the 2.6.32 kernel even though the > most up-to-date version is 2.6.34, or does it need to be in the > linux/linux-omap3-2.6.34 folder and some values changed? At the moment I > have just put it into the linux/linux-omap3-2.6.32 folder as per the > instructions in your linked post. > > Many thanks, > > 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 >>> >>> > > ------------------------------------------------------------------------------ > 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 > |
From: Hugo G. <hu...@ro...> - 2010-08-27 15:19:24
|
Hi J.L., None of the commands on that page work for me. 1. There is no org.openembedded/conf/machine/ folder, 2. The 2nd command does not reveal a bitbake version 3. The "bitbake linux-omap3-2.6.34" command returns: NOTE: Handling BitBake files: - (8358/8358) [100 %] NOTE: Parsing finished. 7554 cached, 479 parsed, 325 skipped, 1 masked. NOTE: Resolving any missing task queue dependencies NOTE: Preparing runqueue NOTE: Executing runqueue NOTE: Running task 359 of 359 (ID: 5, /home/mrg/code/Gumstix//org.openembedded.dev/recipes/linux/linux-omap3_2.6.34.bb, do_menuconfig) ERROR: function do_menuconfig failed ERROR: log data follows (/home/mrg/code/Gumstix//tmp/work/overo-angstrom-linux-gnueabi/linux-omap3-2.6.34-r88/temp/log.do_menuconfig.31233) | /home/mrg/code/Gumstix//tmp/work/overo-angstrom-linux-gnueabi/linux-omap3-2.6.34-r88/temp/run.do_menuconfig.31233: line 1238: gnome-terminal: command not found NOTE: Task failed: /home/mrg/code/Gumstix//tmp/work/overo-angstrom-linux-gnueabi/linux-omap3-2.6.34-r88/temp/log.do_menuconfig.31233 ERROR: TaskFailed event exception, aborting ERROR: Build of /home/mrg/code/Gumstix//org.openembedded.dev/recipes/linux/linux-omap3_2.6.34.bb do_menuconfig failed ERROR: Task 5 (/home/mrg/code/Gumstix//org.openembedded.dev/recipes/linux/linux-omap3_2.6.34.bb, do_menuconfig) failed NOTE: Tasks Summary: Attempted 358 tasks of which 358 didn't need to be rerun and 1 failed. ERROR: '/home/mrg/code/Gumstix//org.openembedded.dev/recipes/linux/linux-omap3_2.6.34.bb' failed So I guess I will just try editing it directly, as you say you have done (successfully) ? Thanks, Hugo On 26/08/2010 21:53, J. L. wrote: > Here is a howto for you to be able to change your kernel. > > http://www.gumstix.net/wiki/index.php?title=Kernel_Reconfiguration > > Hope that helps, it will give you the new defconfig, though I have > just edited the file directly before and had it work but I am sure > that is not a good way to do it. > > > > On Thu, Aug 26, 2010 at 9:26 AM, Hugo Grimmett<hu...@ro...> wrote: >> Dear Thierry, >> >> Thanks for your help, I do have a couple of questions: >> >> In the defconfig file it says "Automatically generated make config: >> don't edit". How then do I make sure the touchscreen is disabled? >> >> Also, can I just run the patch for the 2.6.32 kernel even though the >> most up-to-date version is 2.6.34, or does it need to be in the >> linux/linux-omap3-2.6.34 folder and some values changed? At the moment I >> have just put it into the linux/linux-omap3-2.6.32 folder as per the >> instructions in your linked post. >> >> Many thanks, >> >> 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 >>>> >>>> >> ------------------------------------------------------------------------------ >> 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 >> |
From: Hugo G. <hu...@ro...> - 2010-08-27 16:02:12
|
I have fixed this problem, which originated from my using a terminal-only tty1 which didn't allow menuconfig to open the required window. Hugo On 27/08/2010 15:57, Hugo Grimmett wrote: > Hi J.L., > > None of the commands on that page work for me. > 1. There is no org.openembedded/conf/machine/ folder, > 2. The 2nd command does not reveal a bitbake version > 3. The "bitbake linux-omap3-2.6.34" command returns: > > NOTE: Handling BitBake files: - (8358/8358) [100 %] > NOTE: Parsing finished. 7554 cached, 479 parsed, 325 skipped, 1 masked. > NOTE: Resolving any missing task queue dependencies > NOTE: Preparing runqueue > NOTE: Executing runqueue > NOTE: Running task 359 of 359 (ID: 5, > /home/mrg/code/Gumstix//org.openembedded.dev/recipes/linux/linux-omap3_2.6.34.bb, > do_menuconfig) > ERROR: function do_menuconfig failed > ERROR: log data follows > (/home/mrg/code/Gumstix//tmp/work/overo-angstrom-linux-gnueabi/linux-omap3-2.6.34-r88/temp/log.do_menuconfig.31233) > | > /home/mrg/code/Gumstix//tmp/work/overo-angstrom-linux-gnueabi/linux-omap3-2.6.34-r88/temp/run.do_menuconfig.31233: > line 1238: gnome-terminal: command not found > NOTE: Task failed: > /home/mrg/code/Gumstix//tmp/work/overo-angstrom-linux-gnueabi/linux-omap3-2.6.34-r88/temp/log.do_menuconfig.31233 > ERROR: TaskFailed event exception, aborting > ERROR: Build of > /home/mrg/code/Gumstix//org.openembedded.dev/recipes/linux/linux-omap3_2.6.34.bb > do_menuconfig failed > ERROR: Task 5 > (/home/mrg/code/Gumstix//org.openembedded.dev/recipes/linux/linux-omap3_2.6.34.bb, > do_menuconfig) failed > NOTE: Tasks Summary: Attempted 358 tasks of which 358 didn't need to be > rerun and 1 failed. > ERROR: > '/home/mrg/code/Gumstix//org.openembedded.dev/recipes/linux/linux-omap3_2.6.34.bb' > failed > > So I guess I will just try editing it directly, as you say you have done > (successfully) ? > > Thanks, > > Hugo > > > On 26/08/2010 21:53, J. L. wrote: >> Here is a howto for you to be able to change your kernel. >> >> http://www.gumstix.net/wiki/index.php?title=Kernel_Reconfiguration >> >> Hope that helps, it will give you the new defconfig, though I have >> just edited the file directly before and had it work but I am sure >> that is not a good way to do it. >> >> >> >> On Thu, Aug 26, 2010 at 9:26 AM, Hugo Grimmett<hu...@ro...> wrote: >>> Dear Thierry, >>> >>> Thanks for your help, I do have a couple of questions: >>> >>> In the defconfig file it says "Automatically generated make config: >>> don't edit". How then do I make sure the touchscreen is disabled? >>> >>> Also, can I just run the patch for the 2.6.32 kernel even though the >>> most up-to-date version is 2.6.34, or does it need to be in the >>> linux/linux-omap3-2.6.34 folder and some values changed? At the moment I >>> have just put it into the linux/linux-omap3-2.6.32 folder as per the >>> instructions in your linked post. >>> >>> Many thanks, >>> >>> 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 >>>>> >>>>> >>> ------------------------------------------------------------------------------ >>> 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 >>> > ------------------------------------------------------------------------------ > 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 |
From: Hugo G. <hu...@ro...> - 2010-08-30 10:30:58
|
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 >> >> |
From: Thierry G. <t.g...@gm...> - 2010-08-30 11:56:51
|
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 >>> >>> > |
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 >>>> >>>> |
From: Thierry G. <t.g...@gm...> - 2010-08-31 05:32:43
|
Hi Hugo, The spidev kernel driver only exposes the spi kernel interface to user-space programs. All it does is take what you want sent and pass it on to the kernel. It then takes what the kernel received and gives it back to your user-space program. The physical lines are managed by the kernel. You do not have to worry about the clock or the CS lines. However, you can have some amount of control on the clock and CS lines if you want, with the ioctl calls and the spi_ioc_transfer structure documented here: http://tomoyo.sourceforge.jp/cgi-bin/lxr/source/include/linux/spi/spidev.h (look at the spidev.h on your Gumstix for better accuracy). There are ways to chain messages without toggling the CS lines or set the expected max clock frequency. As for sample code, I used the two following programs: * http://www.mjmwired.net/kernel/Documentation/spi/spidev_test.c * http://www.mjmwired.net/kernel/Documentation/spi/spidev_fdx.c spidev_test.c is particularly useful. Regards, Thierry Genovese On Mon, Aug 30, 2010 at 6:19 PM, Hugo Grimmett <hu...@ro...> wrote: > 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 >>>>> >>>>> > |
From: Søren S. C. <li...@ss...> - 2010-08-31 08:23:02
|
> Oh ok, I thought I read somewhere that Spidev was only capable of "half > duplex", but that must have been referring to something else. I think this comment refers to that using normal Linux read()/write() functions you can only either read or write (half duplex). You can't do simultaneous read/write to your user land program using spidev, even thought the bus operates in full-duplex mode, this isn't reflected in the read/write Linux calls. I hope what I tried to say was clear? Søren --- SSC Solutions ApS - Denmark - www.ssc-solutions.dk |