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 <julianbrunner@...> wrote:
>> On Tue, May 14, 2013 at 3:07 PM, Andy Walls <andy@...> 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
>> <Philip.Nye@...> 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
> gumstix-users@...
> https://lists.sourceforge.net/lists/listinfo/gumstix-users
|