RE: CCS/DK-TM4C129X: Six simultaneous ADC conversions

Why do you believe that (only) 'simultaneous' ADC conversions will suit?

Should that prove a 'real' (or at least highly desired) objective - it proves likely that SIX, Synchronized MCUs (each converting one channel) ... or SIX External, sync'ed, dedicated ADCs - must be deployed.    If in doubt - kindly list that API Command - which enables, 'Multiple ADC Channel Conversions' ... simultaneously.    (None exist! ... my belief)

Review of  'high performance' instruments usually reveals that, 'MULTIPLE, HIGH-SPEED, Dedicated ADC (ICs) are employed (never an MCU) - when such 'simultaneous measures' are sought!

Perhaps 'relaxing' your requirement to (near) simultaneous (i.e. 'such conversions - as close-together as possible) proves more 'realistic.'

(edit)  To Vendor's 'Bob.'   Your response had not appeared as I composed.      

Indeed there ARE 2 ADCs - yet is there an API - ADC Command - which enables BOTH to convert - exactly at the same point in time?      (that's key - is it not?)

Follows the API's function for such ADC conversion:    (from the latest/greatest PDL User Guide.)

4.2.2.28 ADCSequenceDataGet
Gets the captured data for a sample sequence.

Prototype:
int32_t
ADCSequenceDataGet(uint32_t ui32Base,
uint32_t ui32SequenceNum,
uint32_t *pui32Buffer)

Parameters:
ui32Base is the base address of the ADC module.        ***  my belief - ONLY a  SINGLE 'base address'  of an ADC Module may be employed!
ui32SequenceNum is the sample sequence number.
pui32Buffer is the address where the data is stored.

Description:
This function copies data from the specified sample sequencer output FIFO to a memory resident
buffer. The number of samples available in the hardware FIFO are copied into the buffer,
which is assumed to be large enough to hold that many samples. This function only returns
the samples that are presently available, which may not be the entire sample sequence if it is
in the process of being executed.

The only way to do what you want to do is to find a mcu with six independent adc modules, or to use external adcs.

No other way around that

Hallowed vendor may (truly) need to 're-think' their 'OVERLY GENEROUS' Award of  'Suggested Answer!'    

24 hours has elapsed - yet that 'errant'  (suggested) flag ... still flies!     (giving requester poster (some) hope - when here is NONE!)

Hi CB1,

Good to hear from you again. Sorry, I missed your post update.

If the two ADC's operate off of the same trigger source, such as a timer, they can indeed be configured to sample different channels at the same time.

Hi Bob,

That 'bit of info' is (again) very well disguised - is it not?       (clearly NOT FOUND by our poster, Danny, or myself.)

That said - I made the effort to present the 'most suitable' API Command - which (STILL) appears 'UNABLE to ACCOMMODATE' ... BEYOND 'ONE SINGLE ADC!'

Is use of DRM - or ASM - then ... the ONLY MEANS to achieve such (suspected) 'simultaneous' conversions?

In closing - despite the claim of 'coincidental conversions' - I do NOT SEE HOW -  the TWO ADCs (at different addresses) may be simultaneously accessed!

It should not prove too difficult to 'confirm' that claim (generate a very short pulse - presented in parallel - to each different ADC) and determine if there (really) is simultaneous detection - by the TWO DIFFERENT ADC Modules!)     (I sense NOT - unless the address fields (cleverly) overlap (enabling ONE address to enable (both) ADCs!)

Having past worked (and consulted) for another 'giant' semi firm - I know that there are, 'implementation (primarily layout) differences' - between the different 'On MCU' ADC Modules.     And indeed - even though (potentially) 'Common Triggered' - that may, 'NOT PROVE SUFFICIENT' to insure (real) simultaneous conversions!         (My earlier 'test methodology' can PROVE THIS!)

Yet,  the 'different' acquired data - still must be individually processed - which I believe will 'break' this simultaneous intent!      It is noted - both 'here' and at (other) ARM Vendors - not all claims made - prove valid...   (errata's on-going presence - surely supports that...)

Note too (via my legal training) that the claim (made here) extends ONLY to, 'START  the conversions coincidentally!'       Such language - (perhaps deliberately)  does NOT (positively) extend to, 'ALL SUBSEQUENT CONVERSIONS - ALSO  BEING COINCIDENT!'      (which of course - is of MAJOR IMPORTANCE - in this specific 'Use-Case'...)

Hi Bob,

While (a bit) delayed - your response this morning has been, 'World Class!'      Thank you much - for that.

Our posts just crossed - might you read mine of 08:36 - in which I, 'attempt to justify' my reason for 'simultaneous conversion disbelief.'

And my identification of the fact that, "Starting Conversions Coincidentally' does not 'fully/completely' INSURE - that  'ALL FOLLOWING CONVERSIONS' - maintain said 'coincidence!'
IF that proves true - the language should be extended - to reflect that BROADER (ALL subsequent conversion) MCU device capability!       (rather pointless to 'limit/discount' - such an empowering feature!)

Having (further) reviewed the ADC Section of the MCU Manual - staff/I have noted that several (additional) 'Set-Up/Config' Register 'Hooks' ARE required - to exploit this 'hoped for' Two Channel, Conversion "start & maintain' Coincidence.       The earlier - 'Suggested Answer' - by itself - did not hint at the rather obscure method required - to (maybe) acquire 'Two Channel, Simultaneous Conversion.'     Follow-on points - raised by another & myself - may have 'added' much (needed) additional data.    (it is suspected that still more programming detail is required - to harass all of the required Registers - into this 'simultaneous conversion' attempt.)     (post flying the suggested answer pennant - did not provide this 'necessary & sufficient' detail - demanded by poster's 'simultaneous' (still unexplained) conversion request...)