ADC over GPMC for the OMAP3530

Your "typically" is giving me hope that some ADC's might have a data framing that might fit into GPMC requirements.

Anything like that from TI? (or from anyone else, in case you want/can share that)

I'm not aware of any ADCs from TI with those attributes.

Hey Brandon,

I finally had time to take a better look at this.
I'm wondering whether your previous answer is still valid considered that:

1.  the ADC in question can be run at sample rates compatible with the GPMC_FCLK frequencies
2. in my application the loss of samples is not critical, granted that I can flag such an event
3. the maximum length of an acquisition is such that a circular buffer could comfortably be implemented in RAM, allowing for continuous DMA access to the peripheral

Another way of approaching this could be implementing DMA on a block of 11/12 GPIO's, but I can't find any example of code along the lines of working with a whole block of GPIO's and possibly implementing DMA on those. Also, would the L4 interconnect be fast enough for my app (I need 20-25MHz).

Thanks a lot,

Alberto

Alberto Pierotti said:

I'm wondering whether your previous answer is still valid considered that:

1.  the ADC in question can be run at sample rates compatible with the GPMC_FCLK frequencies

I still stand behind my comments.  I appreciate the thought process you are going through, but my comments are still valid.  Here is my reasoning.  Assume for the moment that the ADC you are targeting will run at sample rates compatible with the GPMC_FCLK frequency.  I would presume at this point that the ADC in question would generate data on every clock edge.  Whenever I have looked at ADCs with parallel data interfaces, they have a Clock signal and Data[*] signals.  They send data out on every clock cycle.  You may be able to configure which edge, but nontheless, every clock cycle will have converted data to capture.  They also tend to be source-clock synchronous, meaning the ADC is the driver of the clock and data.

The very nature of the GPMC interface will not sustain continuous capture of samples on every clock cycle, meaning it will not hold the chip select and other control signals active indefinitely while capturing data.  At some point, usually based on some finite number, it will deassert the control signals and no longer capture data.  Secondly, the GPMC does not operate off of an external clock.  Therefore, we can not guarentee being synchronous to the data stream coming out of the ADC.

Unless you have external circuitry (ie. FIFO or something like it) or the ADC itself has a FIFO memory in it, the GPMC is not a candidate, in my (not so humble) opinion, for this type of functionality.

Alberto Pierotti said:

in my application the loss of samples is not critical, granted that I can flag such an event

As I mentioned, I appreciate you working through your use-case to try to work around constraints placed by the GPMC interface.  I don't know how you would recognize/know that you have missing/dropped samples once the GPMC stops collecting data.  You may have a better idea of what the signal looks like that you are sampling and can somehow use CPU cycles to analyze the data to find a break.

Alberto Pierotti said:

the maximum length of an acquisition is such that a circular buffer could comfortably be implemented in RAM, allowing for continuous DMA access to the peripheral

Another way of approaching this could be implementing DMA on a block of 11/12 GPIO's, but I can't find any example of code along the lines of working with a whole block of GPIO's and possibly implementing DMA on those. Also, would the L4 interconnect be fast enough for my app (I need 20-25MHz).

The speed of the L4 interconnect will be a function of which OPP (Operating Performance Point) you are configuring the device for.  I believe at a maximum it can run up to ~80MHz.  But if you need 1/4 of that bandwidth just to setup a DMA to sample GPIO pins, that doesn't leave a lot of bandwidth for other peripheral accesses.  Also, it is not just about available bandwidth.  There is a specific time upon which you need to sample the data from the ADC.

Hey Brandon,

I truly appreciate your help. Your opinions are way beyond being humble, imho that is :)

In light of that, I'll add a FIFO to my system - I've done it before (over ten years ago) on an old framegrabber based on a TMS and it worked fine, even if it chewed up some real estate. 

Any recommendation on TI's FIFO and/or possible already existing implementations with the OMAP's?

Thanks a lot once again,.

Alberto

Alberto Pierotti said:

Any recommendation on TI's FIFO and/or possible already existing implementations with the OMAP's?

Unfortunately, I don't.  The interface should be straighforward though.