C6747 interface to ADC

First, I would like to ask a few questions about what you are trying to do. Then I will toss out some comments to your questions above.

Q1: The C6747 EVM includes a "High-quality 24-bit stereo codec". Is that device not good enough for your needs, or do you need more of the same?

Q2: What is the part number for the ADC you want to interface to? Or better yet, what features do you want in your ADC? [Just a warning, but if it is not a TI part number, you will likely get some postings explaining how much better off you will be with a TI ADC. But you will also get your answers, either way.]

Q3: Are your aware of or are you using the Spectrum Digital OMAP-L137 Prototyping Module, http://www.spectrumdigital.com/product_info.php?cPath=27&products_id=217 ? It looks like a pretty good value for prototyping exactly the kind of project you are working toward.

Your answers will help direct our answers to your questions. More importantly, they will help us point you to a solution for your project.

From a quick look at the datasheet, sprs377b, and the Timer User's Guide, sprufm5a, it looks like the input clock to the Timers will be the OSCIN clock which is usually 27MHz. Dividing that down to generate a clock would be able to give you clock periods that are a mutliple of 74.074ns (2x37.037ns), and I am not sure that 74.074ns is possible. We would have to try it to see if the timers can do a count of 1 or not (i.e. would a PRD=0 or 1 give you a clock rate of 74.074 or twice that?). You need 100ns for 10MHz, so your answers to the questions will help steer the clock requirements.

CSL and DSP/BIOS are not at all mutually exclusive. You might not need to change the CSL timer example at all. If it uses an interrupt, you could stay with that interrupt code from the example and just not use the HWI_dispatcher() for that interrupt, or you could remove the "interrupt" keyword from the timer ISR and let the HWI_dispatcher() take care of the context save/restore. Off the top of my head, I cannot think of anything else that might be different when using DSP/BIOS.

The DSP/BIOS PRD module gives you easy access to create simple periodic functions. But they are usually timed in multiples of 1ms, and this sounds way too slow for you  Again, your answers will help steer these requirements, too.

I am very surprised that the PWM does not include an event to the EDMA, but that seems to be the case, as you have pointed out.

Sorry that I do not have any real and concrete answers for you, yet. But we will get there after a couple more cycles on this posting.

I totally missed the thing about the latency.  Sounds like we do need a FIFO. 

Lori

Generic DSP/BIOS is given the use of a timer in the CLK manager setup. You can assign any available timer, but it probably defaults to Timer64P0. You can look there to see which half.

The other timer and the other half of DSP/BIOS's timer are available for you to use in your code. CSL is used to open, configure, and access the timers that are not being used by DSP/BIOS for the CLK function. If you need to trigger an interrupt, then you will use DSP/BIOS HWI to assign your ISR to one of the available DSP interrupts (HWI15-4) and assign your timer event to that HWI; it is easiest to use HWI_dispatcher, which is also selected in DSP/BIOS.

The long latency (from an event through the EDMA to a transfer occurring) is a big concern. But then, you are trying to read 10M samples (4x2.5MSPS) and move that up to 40M when you move to 4x10MSPS. This is a lot of data to be pulling into the DSP and then run some processing. Since you have a 300 MHz internal DSP clock, this means you have less than 10 DSP cycles per sample to get some work done. At first glance, that does not seem very practical, and the NDK is not going to be cheap in terms of MIPS use in the DSP - I don't know what it is exactly, but that should be available in the documentation you get with it.

The ADS62P42 is not designed to be accessed as a memory device, but rather to have its data continuously clocked into some storage device or buffer. You might be able to get away with using the EMIFA EMA_OEN gated with a Chip Select and address lines to clock the ADC, but that qualifies as a hack-job and is probably not the best recommendation. But it could work if you dedicate an EDMA TC to just reading from EMIFA and putting the samples in a useful place. You could set the EMIFA timing parameters to hit the clock speed you want. You will not need the timer, but you will need to be very knowledgeable on the EMIF setup and the EDMA operation.

It may be likely that other higher-level engineering analysis needs to be done on your application to get the whole thing planned out. That may be tough in the public forum world.

Hi Brad,

Concerning the new C67x device with parallel A/D interface to be announced on June 9th:

 Will it also have an ARM (co) processor ?

Regards,

Cristian

Cristian,

That device is currently under NDA.  I've already said more than I should have.  If you go through the TI sales channels (e.g. rep or distributor) then perhaps they can setup the NDA and discuss it with you.  Otherwise I'm sorry to say that you'll have to wait until June 9th for more info!  Sorry, but I don't want to get "busted" for posting NDA info on a public forum!

Brad

In my opinion

1. I think you should re-set up the EDMA trigger event for EMIFA (please see the page 86 in SPRS563B.pdf). Then the EDMA will be triggered by the EMIF.

2.Since the NDK use the TSK (in DSP/BIOS), I think the DSP/BIOS process the TSK after main(). Therefore, I think the example in NDK is not suitable for your project. I think the NDK should not be progressed without using TSK.

In addition, could you tell me how to get the timer example code which doesn't use the DSP/BIOS for OMAP L137?

Dow

On a related note, the device I alluded to a long ways back has finally been announced.  It's the TMS320C6748.  It has a peripheral called the Universal Parallel Port that is intended to interface to a parallel ADC.

congratulations.

Inaddition, I'm instersting on the timer example.

Could you give me the related note, the document name?

Or, could you mail the example code to me?

Thanks.

Thanks for the info - the c6748 does look interesting.  I briefly examined the UPP spec, and it looks to be exactly what the EMIFA should have been, but I couldn't find an obvious indication of how deep the data buffer is (a FIFO?) or what the DMA latency would be.   Do you know any details about the UPP?

My first impression of the UPP was as a substitute for the EMIF. But my latest understanding is as a highly improved and enhanced parallel printer port. And this makes it the right fit for exactly what you want to do with it.

You can find details in the "Universal Parallel Port User's Guide" sprugj5. A good place to look for details on all of the C6748 peripherals is in the Technical Documents section of the Product Folder that you can find from www.ti.com, search by keyword for C6748, click Active product folders, click on the product folder for the C6748.

I could not find any answer to the buffer depth inside the UPP, but it is at least 64 bytes since that is the normal transfer burst size. And it would make sense that each buffer is at least twice that large since I/O data would still be moving while internal transfer are taking place.

DMA latency is hard to quantify since it means something different in different cases. Once you have a chance to understand how the UPP works, how its dedicated 2-channel DMA engine is programmed, and how interrupts can be configured, please post again with what your system-level concerns are. This powerful peripheral is intended to get a lot of data in and out of the DSP, so it might meet your goals exactly.

An older presentation inside TI showed the FIFO to be 512 bytes deep.  Perhaps that changed, but it should at least be in the ballpark.

Confirmed -- 512 bytes deep on both receive and transmit.