Quantcast

serial data stream

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

serial data stream

Julian Brunner
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gumstix-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: serial data stream

Andy Walls
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
> [hidden email]
> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gumstix-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: serial data stream

Nye, Philip
In reply to this post by Julian Brunner
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 <[hidden email]> 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
> [hidden email]
> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gumstix-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: serial data stream

Julian Brunner
In reply to this post by Andy Walls
On Tue, May 14, 2013 at 3:07 PM, Andy Walls <[hidden email]> 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
<[hidden email]> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gumstix-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: serial data stream

Julian Brunner
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 <[hidden email]> wrote:

> On Tue, May 14, 2013 at 3:07 PM, Andy Walls <[hidden email]> 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
> <[hidden email]> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gumstix-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: serial data stream

the suicidal eggroll
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 <[hidden email]> wrote:
>> On Tue, May 14, 2013 at 3:07 PM, Andy Walls <[hidden email]> 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
>> <[hidden email]> 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
> [hidden email]
> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gumstix-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: serial data stream

Nye, Philip
In reply to this post by Julian Brunner
>> "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 <[hidden email]> 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 <[hidden email]> wrote:
>> On Tue, May 14, 2013 at 3:07 PM, Andy Walls <[hidden email]> 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
>> <[hidden email]> 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
> [hidden email]
> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gumstix-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: serial data stream

Julian Brunner
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
<[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:
>>> On Tue, May 14, 2013 at 3:07 PM, Andy Walls <[hidden email]> 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
>>> <[hidden email]> 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
>> [hidden email]
>> 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
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/gumstix-users

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gumstix-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: serial data stream

Scott Ellis
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.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: serial data stream

the suicidal eggroll
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
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/gumstix-users


------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gumstix-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: serial data stream

Chris Cotton
This post was updated on .
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.  Besides; PCBs have already been laid and products (which will require firmware upgrades in the future) have shipped out to customers.  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.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: serial data stream

Nicola
In reply to this post by Julian Brunner
have you seen my recipe on Mcbspi for overo water system?
Nicola
Loading...