TM4C1294NCPDT: Does differential sampling reduce throughput by 2x?

Patrick Emerick said:

I'm assuming differential sampling reduces throughput by two because two channels are being sampled

Under that assumption - would not the throughput be reduced by (even) 'beyond two?'     (As it is likely that channel sequencing/switching/referencing & other internal housekeeping is (additionally) demanded.)

I have no definitive data for this MCU - yet (other) ARM MCUs my firm employs, 'Can achieve differential sampling' w/only (very) slight loss in channel throughput.

The MCU Manual provides a base level of information (have you checked?)  ...  the depth of this issue may require vendor's, 'inside-knowledge' to properly inform & advise...

Should such data not be quickly/conveniently available (and your need persists) well designed & controlled 'experimentation' may 'Tease Out' a highly satisfactory answer...    (We have past employed a high-speed DAC (via an FPGA) to output a 'Linear Ramp' - and by applying that ramping signal to (the same - or even different) ADC Channels (under the sample sequence you've suggested) - we have been able to (properly) determine the (REAL) 'Moment of  (each) Channel's Signal Capture!')

Unknown is what's precisely meant by 'Throughput' - the method exposed provides the 'Signal Capture Throughput' - yet these captures must still be processed further prior to, 'Delivery to the User.'

Greetings Charles,

This poster has saved you from a, 'Postless Sunday.'    (that 's' was an important inclusion ...)

As the MCU's internal routings/flows likely shift when 'Differential is Commanded'  (and may thus be able to accommodate TWO ADC Channels) - is it not possible that the Same Sampling Clock - can capture both channels - simultaneously?     (I suspect that's how one of the newer ARM Cortex M7s manages that feat...)

May we ask if your MCU's ADC - when set to differential mode - also restricts each channel to, 'One-Half' of VDD?     (such would be of value to this poster - and my crüe.)

Good morning cb1,

 That is not possible. Each ADC core can only convert one channel at a time. In differential mode, an even channel X can be coupled with channel X+1 to form a differential pair. However, the the still has to be converted in sequence. One might tries to feed the same channel to two different ADC cores and perform conversion in parallel but that will be single ended input mode only.  Sorry, typing with my phone is not the most convenient way to support the forum. :)

Greetings Charles,

Thanks for that description - yet (pardon) 'I'm not ready to fully surrender yet!'     And I'm of the opinion that my belief - if proven correct - raises the value of your MCUs.    (i.e. Differential Analog Signal Handling is NOT doomed to, 'Throttle the MCU's conversion rate!'

Consider this - is not the 'Conversion of the Differential, Analog Signal' (somewhat) compromised - by the, 'Delay you note  (16 ADC Clock Periods + overhead) - between the conversion of each of these 2 Channels?'    Should the input signal be dynamic - does your device (really) perform a (proper) Differential Signal Conversion?    (I recall labs in my east-coast engineering school - in which 'great pains' were taken - to positively insure that our  Differential Analog Input Signal was 'split' - & then simultaneously processed.   Delays were verboten!

Now - it is known that the same ADC Clock Signal visits each/every Analog Channel.   By employing the differential channel scheme across two different Analog ADC Modules - 'the benefits of common clocking can be achieved.'   (Thus a proper Differential Analog Signal Conversion may result!)    The 'paired channels' required for Differential Signal Conversion may 'disallow' the use of separate ADC Modules - and thus condemn the differential conversion to error - as the second channel's conversion is impacted by that (minimum) 16 ADC Clock (+ overhead) Delay!   

We realize that each ADC Module deploys an 'Input Multiplexer' - and this prevents the 'Simultaneous Conversion of (two commonly clocked) ADC Channels.'    (i.e. w/in that specific ADC Module)   

This explains 'Why we've proposed the use of (both) ADC Modules' - to resolve the Single Channel Limitation - enforced by the multiplexer.    Recognized too is the (ease) which may be achieved by, 'Forcing all ADC Channels  w/in a  'Sequence'  to be w/in the same ADC Module.'    (we've not dug deep enough (yet) to discover if that really is the case.)

If what you note is correct - is "Measuring the Differential Analog Signal - at  'Different Points in Time' - qualified as Best Practice?"     Especially as the 'common ADC Clock' must route to each/every ADC Channel!     It would seem, 'Not overly challenging - to common clock each channel - designated as Differential.'   (which eliminates the 'enforced delay' - which impacts 'true' Differential Signal Conversion!)     Further processing post the conversion appears 'less restricting' - we are surprised that this 'Common Clocking' appears 'Not to have been implemented...'

Facts follow - these based entirely upon representations made w/in the 'TM4C123 Manual. - dated 12 June 2014.    While no definitive 'Differential Signal' conclusions were noted -  substantial data 'Builds toward the possibility of a 'Common Clocked' (thus REAL) Differential Signal Conversion!'

13 Analog-to-Digital Converter (ADC) Pg 799

The trigger source for ADC0 and ADC1 may be independent or the two ADC modules may operate from the same trigger source and operate on the same or different inputs.   A phase shifter can delay the start of sampling by a specified phase angle.
When using both ADC modules, it is possible to configure the converters to start the conversions coincidentally or within a relative phase from each other.

13.1 Block Diagram

The TM4C123GH6PM microcontroller contains two identical Analog-to-Digital Converter modules. These two modules, ADC0 and ADC1, share the same 12 analog input channels. Each ADCmodule operates independently and can therefore execute different sample sequences, sample any of the analog input channels at any time, and generate different interrupts and triggers.

Table13-2. Samples and FIFO Depth of Sequencers
In addition, sample sequences may be initiated on multiple ADC modules simultaneously using the GSYNC and SYNCWAIT bits in the ADCPSSI register during the configuration of each ADC module.

13.3.2.5 SamplePhaseControl

The trigger source for ADC0 and ADC1 may be independent or the two ADC modules may operate from the same trigger source and operate on the same or different inputs.   If the converters are running at the same sample rate, they may be configured to start the conversions coincidentally or with one of 15 different discrete phases relative to each other.
This feature can be used to double the sampling rate of an input. Both ADC module 0 and ADC module 1 can be programmed to sample the same input. ADC module 0 could sample at the standard position (the PHASE field in the ADCSPC register is 0x0).   ADC module1 can be configured to sample at 180 (PHASE = 0x8). The two modules can be be synchronized using the GSYNC and SYNCWAIT bits in the ADC Processor Sample Sequence Initiate (ADCPSSI) register.
Using the ADCSPC register, ADC0 and ADC1 may provide a number of interesting applications:

■ Coincident continuous sampling of different signals. The sample sequence steps run coincidentally in both converters. – ADC Module 0, ADCSPC = 0x0, sampling AIN0 – ADC Module 1, ADCSPC = 0x0, sampling AIN1.    Note: If two ADCs are configured to sample the same signal, a skew (phase lag) must be added to one of the ADC modules to prevent coincident sampling. Phase lag can be added by programming the PHASE field in the ADCSPC register.

Register 11: ADC Processor Sample Sequence Initiate (ADCPSSI)
This register provides a mechanism for application software to initiate sampling in the sample sequencers.    Sample sequences can be initiated individually or in any combination.   When multiple sequences are triggered simultaneously, the priority encodings in ADCSSPRI dictate execution order.
This register also provides a means to configure and then initiate concurrent sampling on all ADC modules. To do this, the first ADC module should be configured. The ADCPSSI register for that module should then be written. The appropriate SS bits should be set along with the SYNCWAIT bit.     Additional ADC modules should then be configured following the same procedure.   Once the final ADC module is configured, its ADCPSSI register should be written with the appropriate SS bits set along with the GSYNC bit.   All of the ADC modules then begin concurrent sampling according to their configuration.

Staff & I - even though it is Sunday - found this analysis & suggestions a challenge (and worthwhile) - and present this data & viewpoint for review, comment and (even)  clever exploitation...   Might there be, 'More than first (meets the eye)' - when 'zeroing in' on 'Proper & Effective' Differential Analog Signal Converting?

Hi cb1, 

  I will do some research and get back with you.

Thank you, Patrick for those kind & nicely informative comments - much appreciated.

Staff & I cannot successfully explain why both Differential Channels cannot be 'simultaneously converted' - especially if the 'limitations enforced by the ADC's multiplexer can be overcome.'     Perhaps there are (unwanted) differences in performance (offset, accuracy, drift etc.) which potentially justified the 'back to back (i.e. compromised) Differential Conversions' - acquired (only) from a single ADC Module.

To remove (any) elements of doubt - might you clarify:

Patrick Emerick said:

Both ADCs are triggered by the same timer so they sample the signal and the offset reference simultaneously.

We suspect that you are NOT referring to the '129 MCU's  ADCs!'    (as Charles has noted that (the normal/proper) simultaneously required conversions -  are not achievable!)      Might you confirm?

It is good for my young staff - and for (some) here - to learn of your success when deploying a solution very much as young staff/I've proposed.

Best of luck & success to you with your projects...

Hi cb1, Patrick,

  I'm very sorry that I gave the wrong information concerning differential mode.  cb1 is absolutely right that it does not make any sense in differential mode the two differential inputs are converted in sequence. It just defeats the purpose of the differential mode to reject the common noise entirely. I'm still trying to understand exactly how the differential mode works. I doubt two ADC cores are used at the same time. I tend to think in differential mode only channel x is converted while using channel x+1 as a voltage reference. How it is exactly done, I don't know yet.  I will get back once I confirm the intricacy of the differential mode. Once again, without cb1's relentless pursuit, I would not have known the big mistake on my prior answer. 

  The differential throughput in my opinion will be the same as in single-ended at the expense of using two channels instead of one. 

Greetings Charles,

Charles Tsai said:

...cb1 is absolutely right ... it does not make any sense in differential mode that the two differential inputs are converted in sequence.   It just defeats the purpose of the differential mode to reject the common noise entirely.

Yours is a courageous & generous response.    Do note that my intent was to:

• Aid the poster - as staff/I recognized that such 'Back to Back' (i.e. DELAYED) conversions of Differential Signals was, 'ERROR INVITING!'
• Advise & Inform this poster (and others) of the 'likely' mistaken belief that such conversions would, (near) HALF the Conversion throughput.
• Should the 'Back to Back' method (really) have been implemented - then at least the 'new generation' of pending MCUs  (not 'Others') may be able to exploit the correction method - outlined earlier.

The confirmation of my 'method/madness' by the OP is greatly comforting - yet any such 'enforced delay' upon a Differential Signal's Measurement - lands, 'outside normal/customary' - and thus I, 'Had to challenge poster's belief that the Conversion Rate was Halved!'

While presented here to (remarkable silence) - use of my firm's 'Linear Ramp' proves an outstanding means of (really) determining the Conversion Rate of  ALL ADC Channels.   (i.e. the Ramp is presented both 'Rising & Falling' - the difference in Acquired Conversion Values between successively Sequenced Channels is (highly) related to the 'Time Delay between successive Conversions.')     (note the avoidance of claiming 'exactly' related...)

As always - such inspired Measurement trumps any/all  'theory/simulation' - such explains how I (past) co-founded, then took small Tech Firm PUBLIC!   

Is it not now, (Fair/Appropriate)  that a 'Proper GREEN' be awarded?  

Pity that 'LIKE' was banned here - perhaps reasoned w/the same skill/intent of the, 'Failed Differential Conversions!'

I'm going to break this into two separate paths to reduce confusion.

Differential Sampling with two separate ADC Peripherals

• I have successfully implemented this with the TM4C1294NCPDT
• I don't see anything Charles has said to indicate two ADC Peripherals can't achieve proper simultaneous sampling. He says, "Each ADC core can only convert one channel at a time. In differential mode, an even channel X can be coupled with channel X+1 to form a differential pair. However, the the still has to be converted in sequence. One might tries to feed the same channel to two different ADC cores and perform conversion in parallel but that will be single ended input mode only." which, is interpreted by me to mean that each ADC Peripheral can convert one channel so, if triggered simultaneously, together they can convert two channels simultaneously. As far as I understand it, each ADC Peripheral has an independent input channel MUX so, each MUX can be configured independently.
• To accomplish this, I configured both ADC Peripherals identically, including ADCSPC set to 0x0, ADCEMUX[3:0] set to 0x5 and a timer setup as the trigger. I found that this worked without setting GSYNC.
• To clarify what cb1 quoted, my implementation is using ADC Peripheral 0 to sample the "signal" while ADC Peripheral 1 simultaneously samples "offset reference".

Differential Sampling with single ADC Peripheral

• I have no experience with this approach but, I'm working on a project which requires one ADC Peripheral to continuously sample at maximum sample rate while sampling a few differential signals with the other ADC Peripheral.
• I was led to ask the question because it didn't make sense to sample two channels sequentially to acquire a differential signal, as stated by cb1 but, nothing in the datasheet indicated how this actually works.
• I'm planning on testing this method but, I won't be able to get to it until later this week.

Patrick Emerick said:

... working on a project which requires one ADC Peripheral to continuously sample at maximum sample rate while sampling a few differential signals with the other ADC Peripheral.

Follows now the apparent 'Rules/Regulations' which impact the ADC's Differential Analog operation:

• There are 2 independent ADC Modules - each one includes an 8 Channel MUX.    The Mux likely prevents two ADC Channels - w/in the same ADC Module - from being simultaneously converted.
• The API functions: 'ADCSequenceConfigure() & ADCSequenceStepConfigure()' each enforce, 'All Sequenced Channels' to reside w/in the same ADC Module.   Thus - it would appear - that the MUX forces the unwanted Delay between each of the Differential Channels.   (i.e. the Mux can only feed the input analog signal to one channel at a time.    Thus - even if common clocking can be achieved - the 2nd analog channel is 'unavailable!')

These key factors  (above)  are documented via the TM4C123's Manual as follows:

4.2.2.27 ADCSequenceConfigure

Configures the trigger source and priority of a sample sequence.
Prototype:

void ADCSequenceConfigure(uint32_t ui32Base, uint32_t ui32SequenceNum, uint32_t ui32Trigger, uint32_t ui32Priority)

Parameters:

ui32Base is the base address of the ADC module.

ui32SequenceNum is the sample sequence number.

4.2.2.35 ADCSequenceStepConfigure

Configure a step of the sample sequencer.
Prototype:

void ADCSequenceStepConfigure(uint32_t ui32Base, uint32_t ui32SequenceNum, uint32_t ui32Step, uint32_t ui32Config)
Parameters:

ui32Base is the base address of the ADC module.

ui32SequenceNum is the sample sequence number.

ui32Step is the step to be configured.

ui32Config is the configuration of this step; must be a logical OR of ADC_CTL_TS, ADC_CTL_IE, ADC_CTL_END, ADC_CTL_D, one of the input channel selects (ADC_CTL_CH0 through ADC_CTL_CH23.)

Differential mode only works with adjacent channel pairs (for example, 0 and 1). The channel select must be the number of the channel pair to sample (for example, ADC_CTL_CH0 for 0 and 1, or ADC_CTL_CH1 for 2 and 3) or undefined results are returned by the ADC.

Both of these, 'Sequencing Configurations'  confine Channel Selection to the 'Specified ADC Module - only!'    Again - this suggests that an unwanted, error introducing delay will be inflicted upon the Differential Signal's Measurement.

Minus 'insider knowledge' - or 'inspired experimentation & measurement' (via the suggested, Linear Ramp, Voltage Application) the 'Real Workings' of the Differential Conversion remains unknown.

It is possible - that unless the MCU's internal signal routings prevent it - a, 'Re-Write of (each) of the ADC's Sequencing Configuration APIs  (remove the Single ADC Module Restriction) may enable (quick & eased) - yet (then) proper Differential Signal Conversion!

Patrick Emerick said:

which, is interpreted by me to mean that each ADC Peripheral can convert one channel so, if triggered simultaneously, together they can convert two channels simultaneously. As far as I understand it, each ADC Peripheral has an independent input channel MUX so, each MUX can be configured independently.

 Hi Patrick, your understanding is correct Please see below description and diagram. The analog inputs are routed to both ADC modules in parallel and they share the same trigger. If you use a trigger event (i.e. Timer) then it can trigger both the ADC module to convert at the same time. 

Please also try the differential mode using just one ADC module. It will be easier to setup just one ADC module rather than 2. There is a differential mode example under <TivaWare_Installation>/examples/peripheral/adc/differential.c. 

 About the incorrect information I provided earlier, I want to apologize again. Please refer to the datasheet as it clarified how the differential mode works. As it says, the voltage sampled is the 'difference' between the odd and even channels, not odd and even in sequence.

Hi Charles,

Thanks for your investigation of this question.

I'm going to test differential mode with one ADC Peripheral later this week. I would still like an explanation of how this works. If each ADC has a single input multiplexer how are two input channels sampled simultaneously by one ADC Peripheral? The idea you proposed earlier, one channel being used as a reference, would require some kind of additional multiplexing.

Hello Charles,

Charles Tsai said:

Please also try the differential mode using just one ADC module.

Nein - Nein - Nein!   May I - once more - respectfully disagree?     Pardon - I must ask - had you noted my earlier posting?    (Sent: Mon, Nov 4 2019 9:11 PM)

Do note that the 'Imposition of the ADC's Channel Multiplexer' INSURES that (EVEN) the odd & even (differential) channels are (necessarily) 'CONVERTED AT DIFFERENT TIMES!'    UNLESS - they are routed to separate ADC Modules - and the Conversions are simultaneously performed - and there exists 'High Synchronization' between the 2 ADC Modules!

I cannot understand, 'How this fact has become SO Obscured!'

Charles Tsai said:

voltage sampled is the 'difference' between the odd and even channels, not odd and even in sequence.

Again (pardon) - but 'UNLESS THE 'ODD & EVEN CHANNELS' ARE SIMULTANEOUSLY CONVERTED' - THE  DIFFERENTIAL MEASUREMENT REMAINS FLAWED!

Never does the MCU Manual address (or even suggest) the use of BOTH ADC Modules - to achieve these Differential Conversions!     

BTW - much of the data (now presented) arrived earlier in several of my postings ... pity SHOULD those thoughts & documented conclusions HAVE BEEN 'missed!'

As I wrote last night - it (MAY) be possible to 'REWRITE the API' - such that 'BOTH ADC MODULES MAY PARTICIPATE W/IN THE DIFFERENTIAL CONVERSION!'    THIS IS THE ONLY MEANS I NOTE WHICH AVOIDS THE SINGLE CHANNEL CONVERSION - 'PER MOMENT IN TIME' - ENFORCED BY THE MUX - RESIDING W/IN EACH ADC MODULE!

Hi cb1 and Patrick,

  I don't have the analog ADC schematic with me. I will suppose the analog ADC core takes Vin+ and Vin-. When in single-ended mode the Vin- is referenced to the GND. In differential mode both the differential inputs are connected to the Vin+ and Vin- simultaneously. I think a lot of the confusion arises from my earlier incorrect explanation. 

Aloha Charles,   (cb1's just discovered - 'Next Vacation Spot')

Charles Tsai said:

I will suppose the analog ADC core takes Vin+ and Vin-.

Yet there REMAINS the MUX - and in my 25+ years of Mux Usage - never have I (or more clever others) been able to 'Tease the '1 of N' Channel Mux'  to (simultaneously) Connect TWO Channels!   

Is not the MUX there to 'Reduce Components' (thus device size/cost)  -  and accommodate an (essentially) SINGLE Channel Conversion Methodology - which is (most always) 'TIME DIVISION MULTIPLEXED!'    (I.E. SEQUENCED!)

WHAT am I MISSING?

Hello Charles,

Your special (added) effort IS appreciated - thank you.

That said - that 'mystery' 2nd "Ch_X_SEL & DIFF_MODE" implementation is described 'NOWHERE' w/in your MCU's (past: LM3S, LX4F; & TM4C) documentation.    Might this methodology have been implemented w/in 'Higher Performance MCUs' -  which you (may have) employed?

Do keep in mind - there are 'Multiple Differential Signal Pairings' - (4 such pairings are possible) - does that not (substantially) further complicate such an implementation?     (i.e. As EACH/EVERY ADC channel w/in the MCU must have such (switchable access) -  to these 'transmission gates.'     As a past Tech Mgr @ another 'semi-giant' - such an implementation rings  (at least to me, here/now) as, 'Inefficient & Unusual.'

Should such 'Transmission Gates' exist - and prove successful - does this not render the 'ADC MUX' (essentially) superfluous?'     

Note too - the 'Transmission Gate Control' must have clear knowledge of:

• Not only the Differential Pair selected

but of

• The position of each Channel w/in the ADC's Stepped Sequence  (You have earlier advised that these may not be forced, 'Back to back!')

Pardon - as the MCU's internal structure must devote 'So many (expanded) design & implementation resources'  - to the (suspected)  very minority usage of 'Differential Conversion' - I remain a, 'Disbeliever!'

Tag:  Does the 'business case' for such 'excess' - really make sense?

Hi Charles,

Again - your focused effort IS much appreciated - that's for sure - staff/I thank you.

However - there appear (at least) TWO  'Unanticipated/Unfortunate  Consequences/Realities:'

• If what you state proves true - would not the Differential Conversion Mode run at TWICE the Conversion Rate?    (As 2 Channels are 'simultaneously converted!')
• And - should that 'Two Simultaneous Conversions Capability Exist' -  Why 'Limit It to JUST the (lesser used) Differential Conversions?'

(edit):  I earlier (above) clearly 'MISSED' the fact that, 'the 2nd Differential Analog Channel is being fed to Vin(-) - Not to a 2nd Analog Channel!    ('missed' may prove overstatement - as Charles' (just arrived posting) was the 'Very First revelation' of this resourceful Differential Conversion implementation!    (i.e. Feed the Odd Numbered Differential Channel to 'Vin(-)' - rather than a separate analog channel!)

I do believe that '4  (minimum) such Channels should feed Vin(-)' - not just the 3 shown!    (this as there are '4 Channel Pairs' available for Differential Conversion - and each of those 4 (independent of the feed to Vin(+) ) - must have a pathway to Vin(-) !)

In addition - thinking further - is it not true that, 'ALL Even numbered Analog Channels' must employ the identical (i.e. GATED means) to connect to Vin(+)?     And - if that's so - the same holds for 'ALL  Odd numbered Analog Channels' (i.e. connect them (potentially) to Vin(-) ) - as well!    (Can you say, 'Urban (or MCU) Sprawl?')     Thus the drawing above (may) benefit by 'further detailing' the ACTUAL NUMBER of Gating Elements - placed between - (both) Vin(+) and Vin(-)!   

Is it not true - that each/every analog channel (if there are an even number total of such channels) must 'be blessed w/a Gating Path to (either) Vin(+) [when even numbered] and Vin(-) [when odd numbered?']    (should there be an odd number total of analog channels - that last (even) channel (i.e. highest channel number) - has NO paired channel - thus escapes the need for such gating!)

We should note the ramifications of Charles' excellent, in-depth presentation:

a) the Differential Analog Conversion Rate is the same as that of 'Single Ended' - thus NOT 1/2 of the Single Ended Rate - as earlier (erroneously) 'Marked as Verified!'

b) the Differential Conversion design shown - providing all of the gating circuitry between (both) Vin(+) and Vin(-) is 'well matched' - should prove 'proper & effective' - which was, 'Far from the case when Use of a 2nd Analog Channel' (rather than simply feeding Vin(-) ) was (earlier) declared/suspected.

c) the presence of 'Four such  'Vin(-)' Gate Control Circuits' (not the 3 shown) (potentially) subjects the Vin(-) input to 'crosstalk' - even when - especially when - only single-ended usage is employed.   (i.e. (some) leakage/bleeding between those "held-off" channels is likely to occur...)

Staff & this reporter are (greatly) in debt to Charles for his 'Deep Dive' into these necessary circuit facts - never presented (to our best knowledge) w/in TM4C (or LX4F) documentation...   Thank you, Charles!

Multiple posts here (this thread) have been (erroneously) 'Marked as Verified.'    Yet only one (the very first responding) - properly resisted poster's claim of '2x reduced throughput!'    And that posting received NO Comment!

cb1_mobile said:

I have no definitive data for this MCU - yet (other) ARM MCUs my firm employs, 'Can achieve differential sampling' w/only (very) slight loss in channel throughput.

As long stated - there ARE seriously benefits resulting from 'Casting a broad  (MCU/related) net!'

Hello Charles,

Indeed you are correct - my focus upon the 'Differential Mode' led to my miss.    I am pleased that the remainder of my Summary - met w/approval.   

My intent was that such listing would add clarity - and provide a 'deeper glimpse' into 'What's really occurring' deep w/in the silicon.'

Again - your 'Above & Beyond Investigative Efforts' - for (it is believed) the first time here (or in LM3S/LX4F/TM4C Literature) has substantially added to the, 'Understanding of the ADC's Operation while commanded to 'Differential Conversion Mode.'

cb1 and Charles, Thank you for all of the input on my question.

The theory of operation outlined in Charles' diagrams and further clarified by cb1 seems to be a satisfactory explanation so, I will mark this issue as resolved. I would still like to test sampling speed of differential mode tomorrow and report back within the next couple of days to answer my original question

Greetings Patrick,

The 'true' design method (only recently exposed) is somewhat complex - yet post vendor's Charles (terrific) 'deep dive'  -  appears proper.

Patrick Emerick said:

I would still like to test sampling speed of differential mode tomorrow

Yet - my staff has (already) performed such test - and the results are 'EXACTLY THOSE NOTED' w/in my 'Opening Post' (first to respond) to you!    Yet - somehow -  (nearly) every post but mine - has received 'Verification!'

May I note that your testing (and measurement) - to prove 'proper' - must 'Impose a Rapidly Changing Differential Signal.'   A static or 'too slowly varying signal' would arrive (almost) equally upon (even) a time delayed, pair of analog inputs.   (which unfortunately - proves little...)

Minus my suggested, 'Feed of a Precise, Linear Ramp Voltage to each differential ADC channel' - your 'test method' may prove a challenge.    (i.e. your use of an existing, 'Test-Measurement Device' must (somehow) be 'Precisely Sync'ed' to the ADC's Differentially Fed Signal - as & (exactly) when - it is 'captured by the MCU!')     

You may now note the 'value & resourcefulness' of the Precision Linear Ramp' - which presents a 'change in level' - should the signal's arrival be (at all) delayed between each of the 'Paired Differential Channels!'

Tag:  Even the 'impossible to impress' gifted/young staff - embrace this unique cb1 method...

cb1_mobile said:

Yet - my staff has (already) performed such test - and the results are 'EXACTLY THOSE NOTED' w/in my 'Opening Post' (first to respond) to you!    Yet - somehow -  (nearly) every post but mine - has received 'Verification!'

Your first response, suggested that you tested differential sampling with other ARM microcontrollers - "I have no definitive data for this MCU - yet (other) ARM MCUs my firm employs, 'Can achieve differential sampling' w/only (very) slight loss in channel throughput." - so, I didn't consider it a resolution to my question. I have now went through the posts provided by you and Charles and marked those most relevant to answering my question.

Patrick Emerick said:

tested differential sampling with other ARM microcontrollers - "I have no definitive data for this MCU

That is because my group has never employed the '129 family of vendor's (other) MCUs.     Our test w/this vendor's '123 MCU' - confirmed the (nearly) exact, 'Rate of conversion' - Single Ended vs. Differential.    (Our test measured the total time to achieve 4, Back to Back Conversions - first Single-Ended then Differential.)   

Perhaps of interest - the 'Superiority of the Differential Method' revealed as, 'Generally Four to Eight Times more 'precise' (i.e. consistent) readings' - than were achieved when in Single-Ended Mode.   We find that (almost all) such 'MCU-based' ADCs (from all vendors) - usually suffer 'inconsistent measure' (i.e. 'jitter') of their 3-4 (even, sometimes 5) least significant bits!    (This (likely) resulting from common-mode and/or 'other' noise sources ... and both are 'far better suppressed' via Differential Conversion.) 

It should be noted too - that 'such gain' (in Signal Accuracy) - comes at the 'cost' (i.e. 'Trade-Off') of, 'Reduced Number (one-half) of Channels' Converted.     

It (may) also prove possible to, Expand beyond the '8 ADC Channel Limitation'  when operated as Differential.    (i.e. composed of 4 'Channel Pairings - demanding 8 ADC Channels - & exhausting Sequence 0!')    Declaration of  those (unique/inspired) 'Newly/Replacing Differential Channels'  -  (may) be 'Commanded on the fly!'    (Via software - which 'Reconfigures the 'Step Sequencer!')    Note that 'still' - only 8 ADC Channels are available (at any one time) in Differential Mode - yet these Channels may differ entirely from the 'initial group of 8!    (thus far - such is my firm's belief/theory - not yet confirmed - which (likely) ADDS further 'Capability & Flexibility!'      (And both (always) highly sought...)

TAG:  Likely means to 'Tease Out' even further capability than vendor imagined...