LM3S2948: About internal FIFO timing chart for ADC

Greetings Charles,

May staff/I 'applaud you' for such a 'caring post' - even though poster's part (a 'named one') has long been, 'Dead & Buried.'

However - young staff has a 'different take' on poster's quest.   (or what they (youthfully believe) more properly 'should be' his quest!)   

Staff submits that a 'superior goal' is the, 'Identification of the precise time in which the MCU's ADC 'sampled/captured' each step w/in the stepped sequence.'    Staff believes such 'precise moment in time of the actual ADC input CAPTURE' -  (usually) [cb1 added] proves far more valuable - than any/all  MCU 'house-keeping duties' - (i.e. moving those ADC captures into the FIFO.)

Now I believe that 'Case may be made' for either objective.    Poster (may) have sought the 'timing burden' - imposed between 'ADC's conversion launch & the availability of such stored data.'     And I've advised young staff that when,  'Action must be taken based upon ADC results' - such 'timing insight' proves useful.

Staff believes that, 'Knowing exactly when each/every 'step - w/in the stepped sequence' occurs - may 'heighten the odds of 'transient measurement - even detection!'    And that (appears) little known or revealed - via the GPIO pulse method.    (i.e. HOW do we (really) know (exactly when) "We are providing the ADC Inputs?")    Are not those 'ADC Inputs' difficult to gate - thus they (may) be present prior to the 'hoped for' - Start of ADC Launch.

Staff has adopted our firm's 'long-term' use of an FPGA's highly programmable, high-speed DAC.    This is programmed to perform as a (highly) Linear Ramp - and by 'Commanding the Ramp to start (linearly rise) one instruction prior to the ADC's (final) enabling - and then post conversions' completion - (comparing each Stepped Acquistion w/the 'Known Ramp Voltage vs. elapsed Time') - the 'actual' time of each ADC capture is discovered.

Perhaps there is 'No best way' - and the 'blend' of both methods (or other ones) - yields the most valuable & productive results...

Hi cb1,

  Thank you for an alternative method to provide a linear ramp. Definitely a good method. 

cb1_mobile said:

(i.e. HOW do we (really) know (exactly when) "We are providing the ADC Inputs?")    Are not those 'ADC Inputs' difficult to gate - thus they (may) be present prior to the 'hoped for' - Start of ADC Launch.

  I think we can set another GPIO high prior to calling the ADCProcessorTrigger() for starting the conversion. Measure the rise to rise of the two GPIO pins. As mentioned, this will only provide the total time of all the channels in one sequencer to finish the conversion. However, one can easily find out the duration it takes for one channel with a two-pass experiment. For example, configure X number of channels in a sequencer for conversion. Measure the time it takes with the two GPIO pins. In the next pass, increase to X+1 channels in the sequencer for conversion. Measure the time lapse for X+1 channels. Subtract between the two passes. This shall eliminate all the overheads associated reading the FIFO and the cycles it takes to set the GPIO pins.

Hello again, Charles,

Charles Tsai said:

However, one can easily find out the duration it takes for one channel with a two-pass experiment.

It is wondered as well - how impacting  may be (for example) - the 'arrival of other interrupts' (especially higher priority ones) - while the ADC is, 'in process.'    It proves 'rare' that the ADC may, 'monopolize the MCU' - and that fact (should) be considered - don't you agree?

Might it 'prove safest' to accept that,  'The availability of ADC data - 'Is what it is' - (may even be 'variable') and 'maximizing ADC throughput' may require very 'considered & careful' programming.    (or (even) a dedicated, high performance ADC - if such need proves REAL!)

Hi cb1,

  The Tiva ADC is of SAR. The conversion time will be independent ADC input voltage. For a 12-bit ADC it shall basically take 12 ADCCLK cycles plus the overhead to sample and hold the input to complete the conversion. 

And should 'higher priority' interrupts arrive (during) the "ADC's multi-channel, interrupt servicing, stepped sequence routine" - does that not inflict a variability in, 'ADC's data availability?'

Hi cb1,

 If the intention is to perform a benchmark/measurement on the ADC latency then I think an environment with only the ADC under test should be provided. I agree adding other variability to the test environment certainly inflict variability to the test results. 

Charles Tsai said:

I agree adding other variability to the test environment certainly inflict variability to the test results. 

Indeed - and the 'reality' is that such, 'Other Variability' is to be expected!    (i.e. when the MCU is programmed to perform 'normal/customary' Real-World functions - which place multiple demands upon the MCU.)

Poster's 'rarely' (i.e. never) explain their justification for requests - and 'concrete answers' are unlikely to prove of 'great value' - due to the (normal) demands of Real-World applications...

During carefully controlled/managed tests of a variety of ARM Cortex MCUs  (Multiple Vendors: M3s, M4s & M7s) staff noted:

• certain segments of the ADC's capture were 'more resistant' to such 'outside world disturbances'
• other segments were 'far more sensitive' - thus more easily disrupted
• and the critical 'Degree of disruption' was yet another variable - and so often caused by 'other MCU operations in process'

As a 'pristine environment' (ADC and only the ADC running) proves 'unlikely'  (in (any) Real-World application) - poster's desire for high accuracy may prove 'elusive!'     (As well as unexplained...)

Hello Charles,

Thank you for reply.

My customer has been using LM3S2948 on their application since 2015.

Recently they are facing conversion data issue on internal ADC.

As you know, there are many issue on this device.

I informed to them your suggestion(GPIO) .

To avoid ADC issue, I will propose software measures as other suggestion.

(Sampling several ADC data and cancel incorrect data.)

And I will suggest to check ADC errata.

I will discuss with them in this week , because I'm not sure know how far they understand the device issue.

(Their development staff at that time already has been retired.)

Regards,

Tao_2199