Using the eTPU to clock in data.

Discussion to talk about software related topics only.
Post Reply
thomastaranowski
Posts: 82
Joined: Sun May 11, 2008 2:17 pm
Location: Los Angeles, CA
Contact:

Using the eTPU to clock in data.

Post by thomastaranowski »

I'd like to use the eTPU on my 5234 to clock in data, but there doesn't appear to be a function for it, or could be twisted to work. Ideally it would work like the Input Capture function, and stash the received bits into a buffer on the tpu, and interrupt only on buffer half full and buffer full, for example. The GPIO isn't really useful since I want to use this for clocking in data at high speed (4+ Mb/s), and it doesn't do much for me that the regular Coldfire GPIO pins doen't already do for me. It seems that if I want this, it seems that I have to pay 4k+ for a eTPU compiler, which doesn't feel wholesome. If only gcc could compile eTPU code :(
thomastaranowski
Posts: 82
Joined: Sun May 11, 2008 2:17 pm
Location: Los Angeles, CA
Contact:

Re: Using the eTPU to clock in data.

Post by thomastaranowski »

Any ideas on how to clock in data from the eTPU guru's? Someone's got to know enough to at least mock me openly :)
Ridgeglider
Posts: 513
Joined: Sat Apr 26, 2008 7:14 am

Re: Using the eTPU to clock in data.

Post by Ridgeglider »

I have not fooled with it but consider DMA transfers, (possibly with the eTPU or not). See The Freescale 5234 Reference manual chapter 14.2 which indicates that DMA transfers can be triggered by the eTPU on at least the 5235 (not sure about 5234?).
User avatar
lgitlitz
Posts: 331
Joined: Wed Apr 23, 2008 11:43 am
Location: San Diego, CA
Contact:

Re: Using the eTPU to clock in data.

Post by lgitlitz »

The eTPU is probably the wrong peripheral for clocking in high speed data. The eTPU also does not have any Freescale provided functions to handle clocking in data ( SPI slave ). They provide an SPI master peripheral but this is limited to a speed under 1mbit. You can write a custom eTPU function but just the compiler costs about 3-5K. Even your own custom function will likely not be able to provide 4mbit of performance here. The eTPU is primarily meant for complex motor control timing, not high-speed communication.

The UART peripherals on this processor support synchronous serial mode. Using this I have been able to keep up data rates over 10mbit. The problem here is the data is UART format so you need to have a start bit and a stop bit for each data word. You will also want to write a driver that uses DMA here or you will be flooded with interrupts.

Probably the best approach here would be to use some external hardware on the data bus, this is the fastest communication peripheral on the processor. I would probably go with a small, cheap CPLD. This should be a very simple HDL design and should be able to easily get the performance you are looking for. If you have a MOD-DEV-100 development board then you already have a CPLD on the data bus to test your HDL code. Another method might be using standard logic ICs, maybe a 74595 to latch the serial data and a counter to trigger the DMA or interrupt.
v8dave
Posts: 333
Joined: Thu Dec 31, 2009 8:31 pm

Re: Using the eTPU to clock in data.

Post by v8dave »

Actually, I was going to suggest an external device too but the idea of using the CPLD on the dev board is a quick way to get this working and prove your design with commiting to any hardware (assuming you have the MOD100 dev board in the first place).

You'll need to download the ISE software to use it and get a JTAG interface but the JTAG is brought out to J21 so you can at least use it in your design. There is ample spare pins taken out to TP points too.

It would be nice if Netburner would release the HDL code for this part of the dev board, so as you could save on designing the databus interface at least.

There is nothing stopping you actually putting in any other interface, such as SPI on the CPLD.

I have often thought about digging out my JTAG interface I got with Altium Designer and seeing if I can have a go at programming the CPLD from that! :o)

Dave...
Post Reply