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 |