From: Julian B. <jul...@gm...> - 2013-05-14 12:25:57
|
Hello, I'm looking for a way to transmit and/or receive a continuous stream of digital, serial data using my Overo Fire COM on a Summit expansion board. I'm relatively new to the whole embedded stuff, so I'm not sure how to best go about this. I'm experimenting with various devices like video game console controllers and RGB LED strips, which use serial data communication, but don't adhere to any commonly used protocol like 8n1 UART, SPI or I2C. So I find myself in need to be able to transmit and receive arbitrary streams of serial data with clocks of around 1 MHz. A concrete example would be sending a raw bitstream of 2400 bits to some device at 800 kHz, with the data line being set to low before and after the transfer, and no pauses during the transfer. I've been looking into SPI and from what the OMAP35x reference manual says in the section about Single-Channel Master Mode (19.5.2.5) it seems like I may be able to abuse the SPI interface to transmit arbitrary serial data streams without having pauses between the individual data words, but I'm not entirely sure, maybe I'm not interpreting it correctly. From what I've read in the section about the McBSP module, it wouldn't work since there may be pauses between the data frames. Another possibility may be using the GPIO ports directly (simply switching them on and off with the right timing to send my data), but I don't know what kind of transfer rates I can get on GPIO, or whether that is a good idea at all, with the scheduler and interrupts getting in my way. Using the UARTs is out of the question since these are way too slow from what I've seen in my experiment, in addition to forcing me to send start and stop bits. So, I'm not sure which approach is the easiest/best and I've been thinking that what I'm trying to do here can't be all that special, so I'm hoping that there is somehow a more straightforward way of doing this, which doesn't involve low-level programming of the SPI interface or bitbanging on the GPIO pins while fighting the process scheduler and the interrupts. So any pointers on how to approach this problem would be very helpful. Thanks in advance, Julian |
From: Nye, P. <Philip.Nye@AcuityBrands.com> - 2013-05-14 13:36:53
|
Hi Julian, It is not clear where the clock for you data originates, and why you can't accept pauses in the transfer. Does the clock needs to continue to run in the absence of data? UARTs in asynchronous mode rely on clocks independently generated each end and resync every byte to ensure drift does not cause errors. In synchronous mode, their clock usually runs continuously but they then need a start-bit/stop-bit framing mechanism so idle conditions with no data can be handled. SPI relies on the clock generated by the master being distributed to the slaves. The master has no obligation to keep the clock steady since pausing it just pauses all transfers. Mechanisms like Manchester encoding combine the clock and data into a single stream by ensuring that signal transitions occur at regular intervals irrespective of the data so the clock can be extracted. Despite the potential clock pausing, SPI sounds quite a good bet if you are happy to generate the clock from the Overo and sync the slave to it. 2400 bits is only 300 bytes which should run as a DMA transfer quite happily with no pauses. If you are running under Linux, beware - I have had trouble with the SPI driver not working properly when receiving data by DMA (receive works fine till the transfer size exceeds the DMA threshold of 150 bytes then it returns garbage). Philip On 14 May 2013, at 13:25, Julian Brunner <jul...@gm...> wrote: > Hello, > > I'm looking for a way to transmit and/or receive a continuous stream > of digital, serial data using my Overo Fire COM on a Summit expansion > board. I'm relatively new to the whole embedded stuff, so I'm not sure > how to best go about this. > > I'm experimenting with various devices like video game console > controllers and RGB LED strips, which use serial data communication, > but don't adhere to any commonly used protocol like 8n1 UART, SPI or > I2C. So I find myself in need to be able to transmit and receive > arbitrary streams of serial data with clocks of around 1 MHz. A > concrete example would be sending a raw bitstream of 2400 bits to some > device at 800 kHz, with the data line being set to low before and > after the transfer, and no pauses during the transfer. > > I've been looking into SPI and from what the OMAP35x reference manual > says in the section about Single-Channel Master Mode (19.5.2.5) it > seems like I may be able to abuse the SPI interface to transmit > arbitrary serial data streams without having pauses between the > individual data words, but I'm not entirely sure, maybe I'm not > interpreting it correctly. From what I've read in the section about > the McBSP module, it wouldn't work since there may be pauses between > the data frames. Another possibility may be using the GPIO ports > directly (simply switching them on and off with the right timing to > send my data), but I don't know what kind of transfer rates I can get > on GPIO, or whether that is a good idea at all, with the scheduler and > interrupts getting in my way. Using the UARTs is out of the question > since these are way too slow from what I've seen in my experiment, in > addition to forcing me to send start and stop bits. > > So, I'm not sure which approach is the easiest/best and I've been > thinking that what I'm trying to do here can't be all that special, so > I'm hoping that there is somehow a more straightforward way of doing > this, which doesn't involve low-level programming of the SPI interface > or bitbanging on the GPIO pins while fighting the process scheduler > and the interrupts. So any pointers on how to approach this problem > would be very helpful. > > Thanks in advance, > Julian > > ------------------------------------------------------------------------------ > AlienVault Unified Security Management (USM) platform delivers complete > security visibility with the essential security capabilities. Easily and > efficiently configure, manage, and operate all of your security controls > from a single console and one unified framework. Download a free trial. > http://p.sf.net/sfu/alienvault_d2d > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users |
From: Andy W. <an...@si...> - 2013-05-14 13:37:37
|
Isn't this the sort of thing the McBSP unit would be good for? (I have never used it myself.) A frame of 128, 32 bits words is 4096 bits. There are no pauses in the frame. That exceeds the 2400 bit requirement from your example. It looks like with the 40-pin header on the Summit, you can get McBSP3 (mcbsp3_dx, mcbsp3_dr, mcbsp3_clk, mcbsp3_fsx) out onto pins 27-30. Regards, Andy On Tue, 2013-05-14 at 14:25 +0200, Julian Brunner wrote: > Hello, > > I'm looking for a way to transmit and/or receive a continuous stream > of digital, serial data using my Overo Fire COM on a Summit expansion > board. I'm relatively new to the whole embedded stuff, so I'm not sure > how to best go about this. > > I'm experimenting with various devices like video game console > controllers and RGB LED strips, which use serial data communication, > but don't adhere to any commonly used protocol like 8n1 UART, SPI or > I2C. So I find myself in need to be able to transmit and receive > arbitrary streams of serial data with clocks of around 1 MHz. A > concrete example would be sending a raw bitstream of 2400 bits to some > device at 800 kHz, with the data line being set to low before and > after the transfer, and no pauses during the transfer. > > I've been looking into SPI and from what the OMAP35x reference manual > says in the section about Single-Channel Master Mode (19.5.2.5) it > seems like I may be able to abuse the SPI interface to transmit > arbitrary serial data streams without having pauses between the > individual data words, but I'm not entirely sure, maybe I'm not > interpreting it correctly. From what I've read in the section about > the McBSP module, it wouldn't work since there may be pauses between > the data frames. Another possibility may be using the GPIO ports > directly (simply switching them on and off with the right timing to > send my data), but I don't know what kind of transfer rates I can get > on GPIO, or whether that is a good idea at all, with the scheduler and > interrupts getting in my way. Using the UARTs is out of the question > since these are way too slow from what I've seen in my experiment, in > addition to forcing me to send start and stop bits. > > So, I'm not sure which approach is the easiest/best and I've been > thinking that what I'm trying to do here can't be all that special, so > I'm hoping that there is somehow a more straightforward way of doing > this, which doesn't involve low-level programming of the SPI interface > or bitbanging on the GPIO pins while fighting the process scheduler > and the interrupts. So any pointers on how to approach this problem > would be very helpful. > > Thanks in advance, > Julian > > ------------------------------------------------------------------------------ > AlienVault Unified Security Management (USM) platform delivers complete > security visibility with the essential security capabilities. Easily and > efficiently configure, manage, and operate all of your security controls > from a single console and one unified framework. Download a free trial. > http://p.sf.net/sfu/alienvault_d2d > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users |
From: Julian B. <jul...@gm...> - 2013-05-14 14:07:01
|
On Tue, May 14, 2013 at 3:07 PM, Andy Walls <an...@si...> wrote: > Isn't this the sort of thing the McBSP unit would be good for? (I have > never used it myself.) > > A frame of 128, 32 bits words is 4096 bits. There are no pauses in the > frame. That exceeds the 2400 bit requirement from your example. > > It looks like with the 40-pin header on the Summit, you can get McBSP3 > (mcbsp3_dx, mcbsp3_dr, mcbsp3_clk, mcbsp3_fsx) out onto pins 27-30. > > Regards, > Andy Yes, in this case, McBSP would suffice, but later on, I may run into scenarios that require more data to be transmitted, so it'd be nice if there was a way to handle arbitrary payloads. On Tue, May 14, 2013 at 3:36 PM, Nye, Philip <Phi...@ac...> wrote: > Hi Julian, > > It is not clear where the clock for you data originates, and why you can't accept pauses in the transfer. Does the clock needs to continue to run in the absence of data? > > UARTs in asynchronous mode rely on clocks independently generated each end and resync every byte to ensure drift does not cause errors. In synchronous mode, their clock usually runs continuously but they then need a start-bit/stop-bit framing mechanism so idle conditions with no data can be handled. SPI relies on the clock generated by the master being distributed to the slaves. The master has no obligation to keep the clock steady since pausing it just pauses all transfers. Mechanisms like Manchester encoding combine the clock and data into a single stream by ensuring that signal transitions occur at regular intervals irrespective of the data so the clock can be extracted. > > Despite the potential clock pausing, SPI sounds quite a good bet if you are happy to generate the clock from the Overo and sync the slave to it. 2400 bits is only 300 bytes which should run as a DMA transfer quite happily with no pauses. > > If you are running under Linux, beware - I have had trouble with the SPI driver not working properly when receiving data by DMA (receive works fine till the transfer size exceeds the DMA threshold of 150 bytes then it returns garbage). > > Philip I'm sorry, I should have mentioned that the signals I'd like to work on at the moment are self-clocking. I don't yet know whether it's really a Manchester code or just something similar. I also don't know how tolerant the slave is towards deviations from the expected clock rate. Since I'm interfacing proprietary hardware that I can't change, I'd just like to get as close as possible to the specified protocol, so I'd like to avoid having a vastly different clock rate as well as pauses in the transfer. I'm wondering if that's possible using SPI. Also, as mentioned in my reply to Andy, I may need to transfer more than 2400 bits at a time in the future and would like to invest in a setup that can handle this scenario as well. Thanks for the answers so far, Julian |
From: Julian B. <jul...@gm...> - 2013-05-14 14:19:05
|
So, just as a final clarification: I have a specification that says something like "a low bit is signalled by a 3us low followed by 1us high, and a high bit is signalled by 1us low followed by 3us high" and then I need to transfer a bitstream according to that protocol. I'd also like to stay flexible such that if I ever want to do something according to a different specification, I would be able to do that, too, not having to start from scratch again. Regards, Julian On Tue, May 14, 2013 at 4:06 PM, Julian Brunner <jul...@gm...> wrote: > On Tue, May 14, 2013 at 3:07 PM, Andy Walls <an...@si...> wrote: >> Isn't this the sort of thing the McBSP unit would be good for? (I have >> never used it myself.) >> >> A frame of 128, 32 bits words is 4096 bits. There are no pauses in the >> frame. That exceeds the 2400 bit requirement from your example. >> >> It looks like with the 40-pin header on the Summit, you can get McBSP3 >> (mcbsp3_dx, mcbsp3_dr, mcbsp3_clk, mcbsp3_fsx) out onto pins 27-30. >> >> Regards, >> Andy > > Yes, in this case, McBSP would suffice, but later on, I may run into > scenarios that require more data to be transmitted, so it'd be nice if > there was a way to handle arbitrary payloads. > > On Tue, May 14, 2013 at 3:36 PM, Nye, Philip > <Phi...@ac...> wrote: >> Hi Julian, >> >> It is not clear where the clock for you data originates, and why you can't accept pauses in the transfer. Does the clock needs to continue to run in the absence of data? >> >> UARTs in asynchronous mode rely on clocks independently generated each end and resync every byte to ensure drift does not cause errors. In synchronous mode, their clock usually runs continuously but they then need a start-bit/stop-bit framing mechanism so idle conditions with no data can be handled. SPI relies on the clock generated by the master being distributed to the slaves. The master has no obligation to keep the clock steady since pausing it just pauses all transfers. Mechanisms like Manchester encoding combine the clock and data into a single stream by ensuring that signal transitions occur at regular intervals irrespective of the data so the clock can be extracted. >> >> Despite the potential clock pausing, SPI sounds quite a good bet if you are happy to generate the clock from the Overo and sync the slave to it. 2400 bits is only 300 bytes which should run as a DMA transfer quite happily with no pauses. >> >> If you are running under Linux, beware - I have had trouble with the SPI driver not working properly when receiving data by DMA (receive works fine till the transfer size exceeds the DMA threshold of 150 bytes then it returns garbage). >> >> Philip > > I'm sorry, I should have mentioned that the signals I'd like to work > on at the moment are self-clocking. I don't yet know whether it's > really a Manchester code or just something similar. I also don't know > how tolerant the slave is towards deviations from the expected clock > rate. Since I'm interfacing proprietary hardware that I can't change, > I'd just like to get as close as possible to the specified protocol, > so I'd like to avoid having a vastly different clock rate as well as > pauses in the transfer. I'm wondering if that's possible using SPI. > Also, as mentioned in my reply to Andy, I may need to transfer more > than 2400 bits at a time in the future and would like to invest in a > setup that can handle this scenario as well. > > Thanks for the answers so far, > Julian |
From: Adam R. <sui...@gm...> - 2013-05-14 15:09:46
|
It sounds like what you really need is high speed bit-banging, I'm not sure if you'll be able to force SPI or McBSP into something that strict. You may consider grabbing a cheap FPGA or CPLD (ala Xilinx CoolRunner II) to interface with the hardware, and then implement something a bit more "established" to communicate between the Fire and the CPLD. You can pick up a Digilent C-Mod for <$25, which gives you around 25 GPIO that can be configured for any protocol with precise timing down to the clock speed. Anyway, I recently wrote an McBSP kernel driver for the Overo to interface with a DSP at approx 1.3 MHz. It uses leapfrogging DMAs to transfer data in 2kB words with no gaps. Scaling this up would be arbitrarily easy, there's no reason there needs to be a gap between frames in McBSP. -Adam On 05/14/2013 08:18 AM, Julian Brunner wrote: > So, just as a final clarification: I have a specification that says > something like "a low bit is signalled by a 3us low followed by 1us > high, and a high bit is signalled by 1us low followed by 3us high" and > then I need to transfer a bitstream according to that protocol. I'd > also like to stay flexible such that if I ever want to do something > according to a different specification, I would be able to do that, > too, not having to start from scratch again. > > Regards, > Julian > > On Tue, May 14, 2013 at 4:06 PM, Julian Brunner <jul...@gm...> wrote: >> On Tue, May 14, 2013 at 3:07 PM, Andy Walls <an...@si...> wrote: >>> Isn't this the sort of thing the McBSP unit would be good for? (I have >>> never used it myself.) >>> >>> A frame of 128, 32 bits words is 4096 bits. There are no pauses in the >>> frame. That exceeds the 2400 bit requirement from your example. >>> >>> It looks like with the 40-pin header on the Summit, you can get McBSP3 >>> (mcbsp3_dx, mcbsp3_dr, mcbsp3_clk, mcbsp3_fsx) out onto pins 27-30. >>> >>> Regards, >>> Andy >> Yes, in this case, McBSP would suffice, but later on, I may run into >> scenarios that require more data to be transmitted, so it'd be nice if >> there was a way to handle arbitrary payloads. >> >> On Tue, May 14, 2013 at 3:36 PM, Nye, Philip >> <Phi...@ac...> wrote: >>> Hi Julian, >>> >>> It is not clear where the clock for you data originates, and why you can't accept pauses in the transfer. Does the clock needs to continue to run in the absence of data? >>> >>> UARTs in asynchronous mode rely on clocks independently generated each end and resync every byte to ensure drift does not cause errors. In synchronous mode, their clock usually runs continuously but they then need a start-bit/stop-bit framing mechanism so idle conditions with no data can be handled. SPI relies on the clock generated by the master being distributed to the slaves. The master has no obligation to keep the clock steady since pausing it just pauses all transfers. Mechanisms like Manchester encoding combine the clock and data into a single stream by ensuring that signal transitions occur at regular intervals irrespective of the data so the clock can be extracted. >>> >>> Despite the potential clock pausing, SPI sounds quite a good bet if you are happy to generate the clock from the Overo and sync the slave to it. 2400 bits is only 300 bytes which should run as a DMA transfer quite happily with no pauses. >>> >>> If you are running under Linux, beware - I have had trouble with the SPI driver not working properly when receiving data by DMA (receive works fine till the transfer size exceeds the DMA threshold of 150 bytes then it returns garbage). >>> >>> Philip >> I'm sorry, I should have mentioned that the signals I'd like to work >> on at the moment are self-clocking. I don't yet know whether it's >> really a Manchester code or just something similar. I also don't know >> how tolerant the slave is towards deviations from the expected clock >> rate. Since I'm interfacing proprietary hardware that I can't change, >> I'd just like to get as close as possible to the specified protocol, >> so I'd like to avoid having a vastly different clock rate as well as >> pauses in the transfer. I'm wondering if that's possible using SPI. >> Also, as mentioned in my reply to Andy, I may need to transfer more >> than 2400 bits at a time in the future and would like to invest in a >> setup that can handle this scenario as well. >> >> Thanks for the answers so far, >> Julian > ------------------------------------------------------------------------------ > AlienVault Unified Security Management (USM) platform delivers complete > security visibility with the essential security capabilities. Easily and > efficiently configure, manage, and operate all of your security controls > from a single console and one unified framework. Download a free trial. > http://p.sf.net/sfu/alienvault_d2d > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users |
From: Nye, P. <Philip.Nye@AcuityBrands.com> - 2013-05-14 15:11:44
|
>> "a low bit is signalled by a 3us low followed by 1us >> high, and a high bit is signalled by 1us low followed by 3us high" This gives a data rate of 250kbps. I've met protocols like this before but I don't have enough experience of these to recognise it as a particular one. In theory the Overo would happily bit bang this protocol but you'd probably have to program it at a very low level to meet that data rate and depending on your OS might run into all sorts of scheduling difficulties. On transmit you could easily generate this from SPI by assigning four SPI bits to each transmitted data bit (0111 for a 1 and 0001 for a 0) and clocking at 4x your intended data rate. The MCSPI would handle this very easily. On receive you'd be best adding a little hardware (a 2us monostable would do it) and running the SPI in slave mode. Philip On 14 May 2013, at 15:18, Julian Brunner <jul...@gm...> wrote: > So, just as a final clarification: I have a specification that says > something like "a low bit is signalled by a 3us low followed by 1us > high, and a high bit is signalled by 1us low followed by 3us high" and > then I need to transfer a bitstream according to that protocol. I'd > also like to stay flexible such that if I ever want to do something > according to a different specification, I would be able to do that, > too, not having to start from scratch again. > > Regards, > Julian > > On Tue, May 14, 2013 at 4:06 PM, Julian Brunner <jul...@gm...> wrote: >> On Tue, May 14, 2013 at 3:07 PM, Andy Walls <an...@si...> wrote: >>> Isn't this the sort of thing the McBSP unit would be good for? (I have >>> never used it myself.) >>> >>> A frame of 128, 32 bits words is 4096 bits. There are no pauses in the >>> frame. That exceeds the 2400 bit requirement from your example. >>> >>> It looks like with the 40-pin header on the Summit, you can get McBSP3 >>> (mcbsp3_dx, mcbsp3_dr, mcbsp3_clk, mcbsp3_fsx) out onto pins 27-30. >>> >>> Regards, >>> Andy >> >> Yes, in this case, McBSP would suffice, but later on, I may run into >> scenarios that require more data to be transmitted, so it'd be nice if >> there was a way to handle arbitrary payloads. >> >> On Tue, May 14, 2013 at 3:36 PM, Nye, Philip >> <Phi...@ac...> wrote: >>> Hi Julian, >>> >>> It is not clear where the clock for you data originates, and why you can't accept pauses in the transfer. Does the clock needs to continue to run in the absence of data? >>> >>> UARTs in asynchronous mode rely on clocks independently generated each end and resync every byte to ensure drift does not cause errors. In synchronous mode, their clock usually runs continuously but they then need a start-bit/stop-bit framing mechanism so idle conditions with no data can be handled. SPI relies on the clock generated by the master being distributed to the slaves. The master has no obligation to keep the clock steady since pausing it just pauses all transfers. Mechanisms like Manchester encoding combine the clock and data into a single stream by ensuring that signal transitions occur at regular intervals irrespective of the data so the clock can be extracted. >>> >>> Despite the potential clock pausing, SPI sounds quite a good bet if you are happy to generate the clock from the Overo and sync the slave to it. 2400 bits is only 300 bytes which should run as a DMA transfer quite happily with no pauses. >>> >>> If you are running under Linux, beware - I have had trouble with the SPI driver not working properly when receiving data by DMA (receive works fine till the transfer size exceeds the DMA threshold of 150 bytes then it returns garbage). >>> >>> Philip >> >> I'm sorry, I should have mentioned that the signals I'd like to work >> on at the moment are self-clocking. I don't yet know whether it's >> really a Manchester code or just something similar. I also don't know >> how tolerant the slave is towards deviations from the expected clock >> rate. Since I'm interfacing proprietary hardware that I can't change, >> I'd just like to get as close as possible to the specified protocol, >> so I'd like to avoid having a vastly different clock rate as well as >> pauses in the transfer. I'm wondering if that's possible using SPI. >> Also, as mentioned in my reply to Andy, I may need to transfer more >> than 2400 bits at a time in the future and would like to invest in a >> setup that can handle this scenario as well. >> >> Thanks for the answers so far, >> Julian > > ------------------------------------------------------------------------------ > AlienVault Unified Security Management (USM) platform delivers complete > security visibility with the essential security capabilities. Easily and > efficiently configure, manage, and operate all of your security controls > from a single console and one unified framework. Download a free trial. > http://p.sf.net/sfu/alienvault_d2d > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users |
From: Julian B. <jul...@gm...> - 2013-05-21 14:10:37
|
Hello, Thanks for the answers, everyone. I tried giving McSPI a shot, since it seemed a little more high-level than McBSP, so I figured it'd be easier to use. Although if the source code of your driver is public, I'd be interested in having a look at that, too, Adam. I've also been somewhat confused by the fact that McBSP was always associated with sound processing, from what I've gathered the relevant drivers don't even get built unless one enables sound support in the kernel configuration. Isn't McBSP supposed to be a general purpose serial interface that can be used independently of sound applications? Anyways, I did some tests with SPI and it seems that there is always a pause between each word where the data pin is low. It seems that the length of this pause is always a clock cycle and it may be what is called synchronization delay in the OMAP35x specification, but I'm not completely sure, if anyone has some experience with this, I'd be grateful for any insight. Since each bit in the protocol I'm implementing has a low signal part, I was able to align that with the pause between words (if I want to send 1110, I just send 111 and have the 0 added as side-effect of the pause). I haven't been able to test it thoroughly due to currently missing equipment, but it seems like it might just work this way. Although I'm curious if this is the way to go, from how Philip described the implementation, it sounded like there was a way to use the SPI without having pauses between words. Cheers, Julian On Tue, May 14, 2013 at 5:10 PM, Nye, Philip <Phi...@ac...> wrote: >>> "a low bit is signalled by a 3us low followed by 1us >>> high, and a high bit is signalled by 1us low followed by 3us high" > > > This gives a data rate of 250kbps. > > I've met protocols like this before but I don't have enough experience of these to recognise it as a particular one. In theory the Overo would happily bit bang this protocol but you'd probably have to program it at a very low level to meet that data rate and depending on your OS might run into all sorts of scheduling difficulties. > > On transmit you could easily generate this from SPI by assigning four SPI bits to each transmitted data bit (0111 for a 1 and 0001 for a 0) and clocking at 4x your intended data rate. The MCSPI would handle this very easily. > > On receive you'd be best adding a little hardware (a 2us monostable would do it) and running the SPI in slave mode. > > Philip > > On 14 May 2013, at 15:18, Julian Brunner <jul...@gm...> wrote: > >> So, just as a final clarification: I have a specification that says >> something like "a low bit is signalled by a 3us low followed by 1us >> high, and a high bit is signalled by 1us low followed by 3us high" and >> then I need to transfer a bitstream according to that protocol. I'd >> also like to stay flexible such that if I ever want to do something >> according to a different specification, I would be able to do that, >> too, not having to start from scratch again. >> >> Regards, >> Julian >> >> On Tue, May 14, 2013 at 4:06 PM, Julian Brunner <jul...@gm...> wrote: >>> On Tue, May 14, 2013 at 3:07 PM, Andy Walls <an...@si...> wrote: >>>> Isn't this the sort of thing the McBSP unit would be good for? (I have >>>> never used it myself.) >>>> >>>> A frame of 128, 32 bits words is 4096 bits. There are no pauses in the >>>> frame. That exceeds the 2400 bit requirement from your example. >>>> >>>> It looks like with the 40-pin header on the Summit, you can get McBSP3 >>>> (mcbsp3_dx, mcbsp3_dr, mcbsp3_clk, mcbsp3_fsx) out onto pins 27-30. >>>> >>>> Regards, >>>> Andy >>> >>> Yes, in this case, McBSP would suffice, but later on, I may run into >>> scenarios that require more data to be transmitted, so it'd be nice if >>> there was a way to handle arbitrary payloads. >>> >>> On Tue, May 14, 2013 at 3:36 PM, Nye, Philip >>> <Phi...@ac...> wrote: >>>> Hi Julian, >>>> >>>> It is not clear where the clock for you data originates, and why you can't accept pauses in the transfer. Does the clock needs to continue to run in the absence of data? >>>> >>>> UARTs in asynchronous mode rely on clocks independently generated each end and resync every byte to ensure drift does not cause errors. In synchronous mode, their clock usually runs continuously but they then need a start-bit/stop-bit framing mechanism so idle conditions with no data can be handled. SPI relies on the clock generated by the master being distributed to the slaves. The master has no obligation to keep the clock steady since pausing it just pauses all transfers. Mechanisms like Manchester encoding combine the clock and data into a single stream by ensuring that signal transitions occur at regular intervals irrespective of the data so the clock can be extracted. >>>> >>>> Despite the potential clock pausing, SPI sounds quite a good bet if you are happy to generate the clock from the Overo and sync the slave to it. 2400 bits is only 300 bytes which should run as a DMA transfer quite happily with no pauses. >>>> >>>> If you are running under Linux, beware - I have had trouble with the SPI driver not working properly when receiving data by DMA (receive works fine till the transfer size exceeds the DMA threshold of 150 bytes then it returns garbage). >>>> >>>> Philip >>> >>> I'm sorry, I should have mentioned that the signals I'd like to work >>> on at the moment are self-clocking. I don't yet know whether it's >>> really a Manchester code or just something similar. I also don't know >>> how tolerant the slave is towards deviations from the expected clock >>> rate. Since I'm interfacing proprietary hardware that I can't change, >>> I'd just like to get as close as possible to the specified protocol, >>> so I'd like to avoid having a vastly different clock rate as well as >>> pauses in the transfer. I'm wondering if that's possible using SPI. >>> Also, as mentioned in my reply to Andy, I may need to transfer more >>> than 2400 bits at a time in the future and would like to invest in a >>> setup that can handle this scenario as well. >>> >>> Thanks for the answers so far, >>> Julian >> >> ------------------------------------------------------------------------------ >> AlienVault Unified Security Management (USM) platform delivers complete >> security visibility with the essential security capabilities. Easily and >> efficiently configure, manage, and operate all of your security controls >> from a single console and one unified framework. Download a free trial. >> http://p.sf.net/sfu/alienvault_d2d >> _______________________________________________ >> gumstix-users mailing list >> gum...@li... >> https://lists.sourceforge.net/lists/listinfo/gumstix-users > > > ------------------------------------------------------------------------------ > AlienVault Unified Security Management (USM) platform delivers complete > security visibility with the essential security capabilities. Easily and > efficiently configure, manage, and operate all of your security controls > from a single console and one unified framework. Download a free trial. > http://p.sf.net/sfu/alienvault_d2d > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users |
From: Nicola <pa...@li...> - 2013-06-02 08:33:33
|
have you seen my recipe on Mcbspi for overo water system? Nicola -- View this message in context: http://gumstix.8.x6.nabble.com/serial-data-stream-tp4967260p4967338.html Sent from the Gumstix mailing list archive at Nabble.com. |
From: Scott E. <sc...@ju...> - 2013-05-21 16:38:21
|
McBSP functionality was removed for external driver use for kernels >= 3.3. There is some discussion of it here http://comments.gmane.org/gmane.linux.ports.arm.omap/91842 It was a particularly nasty move by the TI kernel developers to restrict the McBSP controller to a single use this way. Imagine the uproar if they did that with McSPI controller. I have a half-dozen or so driver projects for clients using custom Overo carrier boards with McBSP drivers for special hardware. Some of them are for standard multi-channel ADC chips, but some are for completely proprietary, non-conventional hardware that would never get an in-tree driver. All these projects are frozen at the 3.2 kernel for now. A few months ago I started work on reverting the changes in a 3.6 kernel to get back the McBSP functionality for Overo and hopefully for the Duovero as well. I had to put it off for awhile due to other work, but I hope to get back to it soon. I lose /sound/soc/omap with the approach I've started, but that's not an issue for any of my projects that require an McBSP driver. -- View this message in context: http://gumstix.8.x6.nabble.com/serial-data-stream-tp4967260p4967286.html Sent from the Gumstix mailing list archive at Nabble.com. |
From: Adam R. <sui...@gm...> - 2013-05-21 16:56:16
|
Wow, I can't believe they did that. I'm interfacing with the McBSP port on a proprietary DSP board (using one of TI's DSP chips, go figure), and I don't think McSPI is really an option for this application. I just happened to start my development using the 3.2 kernel, looks like I got lucky...and it looks like I'll be frozen at 3.2 as well unless I get a chance to restore McBSP functionality on the newer kernels, or unless you beat me to it. -Adam On 05/21/2013 10:37 AM, Scott Ellis wrote: > McBSP functionality was removed for external driver use for > kernels >= 3.3. > > There is some discussion of it here > > http://comments.gmane.org/gmane.linux.ports.arm.omap/91842 > > It was a particularly nasty move by the TI kernel developers > to restrict the McBSP controller to a single use this way. > > Imagine the uproar if they did that with McSPI controller. > > I have a half-dozen or so driver projects for clients using custom > Overo carrier boards with McBSP drivers for special hardware. > > Some of them are for standard multi-channel ADC chips, but some > are for completely proprietary, non-conventional hardware that > would never get an in-tree driver. > > All these projects are frozen at the 3.2 kernel for now. > > A few months ago I started work on reverting the changes in a > 3.6 kernel to get back the McBSP functionality for Overo and > hopefully for the Duovero as well. > > I had to put it off for awhile due to other work, but I hope to get > back to it soon. > > I lose /sound/soc/omap with the approach I've started, but that's > not an issue for any of my projects that require an McBSP driver. > > > > > -- > View this message in context: http://gumstix.8.x6.nabble.com/serial-data-stream-tp4967260p4967286.html > Sent from the Gumstix mailing list archive at Nabble.com. > > ------------------------------------------------------------------------------ > Try New Relic Now & We'll Send You this Cool Shirt > New Relic is the only SaaS-based application performance monitoring service > that delivers powerful full stack analytics. Optimize and monitor your > browser, app, & servers with just a few lines of code. Try New Relic > and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users |
From: Chris C. <Cot...@ya...> - 2013-05-22 12:10:14
|
Yikes. TI removing easy access to McBSP is a very bad thing. Like Scott, we have proprietary carrier boards for the Gumstix. Ours use one McBSP instance for normal audio, plus two other instances (McBSP3 and McBSP5) simultaneously for high speed proprietary data. Moving this data to McSPI is not an option, since those interfaces are also being used. Restricting the use of an interface in this way is really bad news for the Gumstix (and other OMAP/TI based boards), as it restricts their usefulness in an embedded setting. It looks like TI have not even bothered considering the repercussions for existing users, and have just pulled the rug out from under their feet. Thanks for the heads up - when I get round to upgrading my kernel I'll be sticking with kernel 3.2, at least until this issue is (hopefully) resolved. -- View this message in context: http://gumstix.8.x6.nabble.com/serial-data-stream-tp4967260p4967289.html Sent from the Gumstix mailing list archive at Nabble.com. |