Decode 10MhZ serial input

Status
Not open for further replies.

nlambuca

Member
Hi,
I need to decode a 10Mhz clocked Data.
Arduino has lot of delays..and also tried the fastRead routines... but I don't seem to capture all...

I have 32 bits to decode on falling edge clock 10MHz.

Ideas?
 
Maybe trying using I2S in slave mode?

Or you could tell us more about this data format. Hard to give more specific advice when all we know is 10 MHz clock.
 
Hi Paul,
well this is proprietary stuff and I cannot publish it... but it is basically 33 clocks to get 32 bits ack at falling edge.
4 frames like this.

Clock running at 10MHz... so I need to sample Data at each clock falling edge.

This is just input. I Teensy will be rcvr and 1 way protocol.

2 Lines...CLK_OUT and DATA_OUT

implementing edge_trigger would work, but not sure code can keep up with 10MHz interrupts and how to set it up.

I am way more used to coding for embedded not using arduino, but for this one I was trying to go the easy way...
 
I2S BCLK polarity is programmable, so you can have either rising or falling edge. For details, see BCP (bit 25) on page 2130.

https://www.pjrc.com/teensy/K66P144M180SF5RMV2.pdf

The tricky part will be when to do about LRCLK. Normally I2S wants a 3rd signal to tell where the bits are framed into words. The default is LRCLK is high when the left channel is transmitted and low when the right channel is sent, with a 1 bit delay. It can also work in a mode where this signal is FS (frame sync) where it's high for a single bit time at the beginning of the frame, as used in TDM mode.
 
Doing this without I2S, I would imagine an interrupt for each falling edge probably requires more CPU time than Teensy 3.6 can offer. Even overclocked to 240 or 256 MHz, this is probably too much.

But DMA might be able to do it. Maybe. The performance info can be found on page 576. Running at 180 MHz, this would seem to mean you could get 10 million DMA requests per second.

You'd probably configure a DMA channel to trigger on the falling edge from a pin, and in the DMA's TCD you'd have it copy the GPIO's pin read register to a buffer in RAM. Then in your program you'd have to write code to read the bytes or words from that buffer, pull out the 1 bit for the data pin, assemble groups of 33 into the frames, and do whatever analysis you want... while keeping up with the arrival rate of 10 million new bytes per second.


Any of these ways will require you to get into some fairly low-level programming. Maybe some of the code from the audio library can help. We can try to answer questions here, but the reality of helping with this sort of proprietary system where you can't give details, well, it's less than ideal. You're going to have to figure out most of these details from the info in the reference manual.

Hopefully this advice can at least start you on the paths that have some chance of working within the limits of the hardware.
 
Status
Not open for further replies.
Back
Top