timer1 based ISR max rate ?

Hello,

Im planning a 6713DSK based design and am thinking of using timer1 to create a periodic ISR to handle continuous sampling an of ADC.(Im still very new with this DSK, and so havent tried it out myself)

Assuming I keep the ISR short (ie: read the ADC, toggle a GPIO, output to a DAC, some housekeeping), can someone give me a rough estimate of how fast I can expect to be able to sample ?

I was hoping to be able to sample at up to 7Msps. Is this realistic for the 6713 DSK ?

Feedback would be appreciated as if its not realistic I'll need to head in a different direction.

Thanks,
Carlo

Check Out Industry's First Single-Chip, Multi-Format, Real-Time HD Video Transcoding Solution for Commercial & Consumer End Equipment: www.ti.com/dm6467 Start a New Thread

Carlo,

On Wed, Feb 27, 2008 at 10:15 PM, wrote:
> Hello,
>
> Im planning a 6713DSK based design and am thinking of using timer1 to
> create a periodic ISR to handle continuous sampling an of ADC.(Im still very
> new with this DSK, and so havent tried it out myself)
>
> Assuming I keep the ISR short (ie: read the ADC, toggle a GPIO, output to a
> DAC, some housekeeping), can someone give me a rough estimate of how fast I
> can expect to be able to sample ?

There are a lot of dependencies - like ADC/DAC access time and the
definition of 'some housekeeping'.
>
> I was hoping to be able to sample at up to 7Msps. Is this realistic for the
> 6713 DSK ?

Not with an ISR. Probably not at all in the 'real world' without
adding some special hardware.
The real answer depends on the actual requirements.

I don't remember the clock rate of the DSK, but here are some numbers.
7Msps = 142ns
225Mhz = 4.4ns, 142/4.4 = 32 clocks
200Mhz = 5.0ns, 142/5 = 28 clocks

GPIO and control register access will take multiple clocks.
DAC/ADC access will take more than 1 clock.

If this is not for a real product, one might could write a loop that
read ADC, set GPIO high, set GPIO low, wrote the DAC, branch back to
reading the ADC.

mikedunn
>
> Feedback would be appreciated as if its not realistic I'll need to head in
> a different direction.
>
> Thanks,
> Carlo
>
>

--
www.dsprelated.com/blogs-1/nf/Mike_Dunn.php
Check Out Industry's First Single-Chip, Multi-Format, Real-Time HD Video Transcoding Solution for Commercial & Consumer End Equipment: www.ti.com/dm6467 Start a New Thread

Thanks Mike for the feedback.
I can now see rapid sampling via an ISR will be too time consuming, so Im planning to add some hardware.

I will add a cpld-based interface so that the DSP will see the adc/dac as a simple memory location via its asynch.EMIF.

Is it correct to say that since ECLKOUT is derived from CPU clock, and so is the internal Timer source clock, that I can use the Timer to generate ISRs to read the sample latches, whose rate will be integrally related to the loading of these latches, and so no samples will be missed due to lack of synchronization (ie: slip between the latch loading rate and the DSP reading rate)?

Thanks for any comments.

Carlo

Check Out Industry's First Single-Chip, Multi-Format, Real-Time HD Video Transcoding Solution for Commercial & Consumer End Equipment: www.ti.com/dm6467 Start a New Thread

Carlo-

> Thanks Mike for the feedback.
> I can now see rapid sampling via an ISR will be too time consuming, so Im planning to add some hardware.
>
> I will add a cpld-based interface so that the DSP will see the adc/dac as a simple memory location via its
> asynch.EMIF.
>
> Is it correct to say that since ECLKOUT is derived from CPU clock, and so is the internal Timer source clock, that I
> can use the Timer to generate ISRs to read the sample latches, whose rate will be integrally related to the loading of
> these latches, and so no samples will be missed due to lack of synchronization (ie: slip between the latch loading
> rate and the DSP reading rate)?

Theoretically yes. But I would suggest that your CPLD hardware latch A/D data in response to A/D converter "sample
read" or other derived signal -- a FIFO might be preferable -- and DSP code read from that. My experience has been
that "touching" the A/D only with precise signals that don't depend on any software latencies or variable response
rate (as with an ISR) is always something good to consider.

-Jeff

Check Out Industry's First Single-Chip, Multi-Format, Real-Time HD Video Transcoding Solution for Commercial & Consumer End Equipment: www.ti.com/dm6467 Start a New Thread

Thanks for the comments Jeff.

I think Im on the right track now.
The CPLD will act much like a FIFO, grabbing & latching the samples independently of the DSP, and using ECLKOUT for timing so its all sync'ed.

DSP can then grab the latched data from the CPLD using aysnc r/w when ever it needs it.

Cheers,
Carlo

Check Out Industry's First Single-Chip, Multi-Format, Real-Time HD Video Transcoding Solution for Commercial & Consumer End Equipment: www.ti.com/dm6467 Start a New Thread

Carlo-

> Thanks for the comments Jeff.
>
> I think Im on the right track now.
> The CPLD will act much like a FIFO, grabbing & latching the samples independently of the DSP, and using ECLKOUT for
> timing so its all sync'ed.
>
> DSP can then grab the latched data from the CPLD using aysnc r/w when ever it needs it.

That sounds Ok. If you have some type of "sample ready" or other signal from the A/D converter that is delayed with
respect to ECLKOUT (or its integer submultiples), then I would suggest you run that to the CPLD also. You might need
it to latch data into the FIFO.

-Jeff

Check Out Industry's First Single-Chip, Multi-Format, Real-Time HD Video Transcoding Solution for Commercial & Consumer End Equipment: www.ti.com/dm6467 Start a New Thread