• State Resolved
  • Locked Locked
  • Replies 11 replies
  • Subscribers 32 subscribers
  • Views 3144 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

TM4C123 ADC usage

Engin Bilgin
Prodigy 80 points
Other Parts Discussed in Thread: TM4C123GH6PM

Dear Forum,

I am  new on the TM4C platform and I have a question regarding the ADC configuration. I have inherited a hardware project where a TM4C123GH6PM MCU controls 5 H-Bridges for brushless DC motor control. So far I have managed to drive the bridges for forward/reverse/stop controls using the PWM outputs of the TM4C123. I am now in the proecess of writing the current monitoring code where I read the voltages from the on board sense resistors and throttle back the PWM's when an overcurrent condition happens. In addition to these I also have 2 brake drivers and a battery level detector that was designed in for monitoring through ADC's.

I was planning to do this by monitoring relevant ADC inputs either by comparator triggered interrupts or polling and taking the necessary action on the ISR's or in the main loop. After reading through the datasheet and the tivaware library user guides several times though I get the impression that individual inputs are not open to inspection. What I understand is that the sequencers act as an aggragate of similar or identical sensor groups with a single comparator trigger on a collection of values collected from various sources without transparent view on the exact data source (analog input channel). Am I correct in my understanding or am I missing some crucial step perhaps specific to multiplexed ADC's?

Say for example I configure Sequencer 0 to collect data from inputs AIN0 through AIN7. Is there any way to know which is the source of the converted data made ready in the FIFO? 

(Please excuse the naivete of the question, the board space is already cluttered and I am trying to avoid a major hardware overhaul to incorparate additonal ADC's)

Regards,

Engin

Edit1@20.06.2016 10:30 UTC, rephrased the wording of the question, removed unnecessary commentary

  • 0
    Guru 117855 points

    You should be able to directly relate each/every ADC input pin signal measure to the ADC data recovery from the FIFO. You may review the examples w/in "Examples/Peripherals/ADC" for detail & clarity.

    Now there may be a superior means to, "throttle back" (or extinguish immediately) all PWM outputs when an over-current is detected. The method you propose relies heavily - and exclusively - upon ALL MCU software running correctly! What if it does not? And - how fast can you detect and then (fully) respond to "any" over-current - when it must be detected @ ADC Conversion rates - and only then fed to MCU comparators?

    Firm/I suggest that (instead) you employ the MCU's analog (NOT digital) comparator to read the "peak" current from all 3 sense resistors. This comparator - being HW - is immune to SW hangs or other weakness. And infinitely FASTER in response. Even better - the analog comparator's digital output may TIE DIRECTLY to the "PWM Fault Input" which enables the immediate cessation of (all 3) PWM Motor Outputs.

    There are (few) more parts to this puzzle - yet this method proves (vastly) superior and is "welcomed" by regulatory agencies who most always will ask you, "Will your "safeties" perform if the MCU hangs?"  (the method you present cannot satisfactorily answer such issue)

  • 0 in reply to cb1_mobile
    Prodigy 80 points
    Dear cb1_mobile,
    Thanks for your quick reply, I think you are right on the safety and regulatory issues. I may have to switch to analog in a future revision.

    However the question of ADC configuration still lingers in my mind, the examples you suggested I read in c:\TivaWare_C_Series-2.1.2.111\examples\peripherals\adc are differential.c, single_ended.c and temperature_sensor.c and to my dismay all use sequencer 3 with a single ADC input pin sequencing. In this context yes you are correct I know which pin I'm sampling.

    Does this mean I will have to rapidly switch pin configurations on Sequencer 3 anytime I need to know which pin I'm sampling? I guess it would be a little tricky to write the ISR for that.

    Is the knowledge of the name of the currently sampled input port accesible anywhere on the hardware or software API's for sequencers that manage more than one ADC input pin(sequencers 0,1 and 2 namely)?

    Regards,

    Engin.
  • 0 in reply to Engin Bilgin
    Guru 47900 points

    Another glorious "meeting" calls - this must be brief.

    I missed the fact that (only) single channel is employed w/in vendor's (otherwise) helpful examples.

    Let's consider your use of the 8 channel sequencer - and you employ ALL 8 channels. Then that channel which is designated as, "Sequence Step 0" (that's the first one converted) will be (similarly) the "first one" to emerge from the FIFO - once the conversion has (fully & properly) completed. Sequence Step 1 will be the 2nd from the FIFO - and so on.

    Experimentation is best to (really) quell all doubts. You should be able to construct a simple resistive, voltage divider - and provide 8 individual voltages to 8 ADC inputs. (do not allow any ADC inputs to float!) In this manner - knowing the impressed signal levels - you may confirm for yourself the operation of the FIFO. Be sure to provide the necessary delay so that the ADC has (really) completed its conversion process "prior" to your unloading of the FIFO.

    Again experimentation will confirm BOTH your ADC understanding and the correctness of past design's hardware. (bad things happen too often when we "assume" all is well. Firm/I have built nice, expanding tech biz by NOT making such "assumptions" and by instead - employing stylized, "Test/Verify."

    Bon chance mon ami.

  • 0 in reply to Engin Bilgin
    Guru 27665 points
    Each entry in the sequence can be a different channel. You know which channel is in the result block by its position in the block.

    As far as current limit goes, I have usually employed multiple levels of limit. A H/W limit at the extreme this should rarely be employed, A S/W limit that reacts to the immediately measured current, followed by s/w current limits that limit the average current over longer periods of time. The longest time limits sized to protect your load.

    Robert
  • 0 in reply to Robert Adsett
    Guru 47900 points

    Robert Adsett said:
    A S/W limit that reacts to the immediately measured current

    My good friend - may we (somewhat) agree to (slightly) disagree?

    Can ANY S/W limit, "React quickly enough to an immediately measured current?"   Is such measure not bound by the conversion speed of the MCU's ADC - and then subsequent, follow-on comparative processing?   Somehow such does not meet the "spirit" of "immediate."   And - of course - fails completely when the MCU "hangs."

    The alternative - a fast, precise, analog comparator (uniquely) MEETS your requirement of "Immediate."   And - when fed by Cortex M MCUs which (thoughtfully) include DACs - indeed meet your requirement of "multiple levels" of such limit.

  • 0 in reply to cb1
    Guru 27665 points
    I don't think we are in disagreement cb1. Note that S/W limit is in addition to the faster H/W limit.

    The H/W can react quickly (say uS scale), the S/W will react likely closer to mS scale. Considering the time constants of the motor that is fast enough for many but not all cases and the S/W limit prevents the H/W from being hit. But there are cases where the S/W simply cannot react quickly enough. The S/W limits might be dealt with by control loop limits depending on how the control is structured.

    The limits also scale somewhat similarly to the SOA of the power devices, large for short periods of time and smaller for continuous current. Likewise the load (in the OP's case a motor) can take large currents for short periods of time of must stay below a lower limit over the thermal time constant of the load and the thermal time constant can be quite large. No single limit can encompass the entire range.

    Robert
  • 0 in reply to Robert Adsett
    Guru 47900 points

    Robert Adsett said:
    No single limit can encompass the entire range.  

    Yes - that is agreed - and explains why firm/I choose 180MHz M4 w/DACs and "brothers in arms: M0, M0+, M3 & M7s."   The DAC enables (wide or narrow) range adjustment and even allows for operational, temperature & component aging - often far more efficiently (and easier) than multiple SW tweaks provide.

    Note too that a key/critical advantage of the Analog Comparator (HW) approach is the ability to immediately extinguish all 3 PWM motor phase outputs - yet restore them (even) upon the "very next" PWM Cycle - if the over-current proved transient.   (which proves most often - the case...)   This "automatic clearing" of "Nuisance Over-Current Trips" is a (most) highly desired feature - and one superbly delivered via the MCU's Analog Comparator in conjunction w/DAC & PWM Fault Trip Input...

  • 0 in reply to cb1
    Guru 27665 points

    cb1- said:
    This "automatic clearing" of "Nuisance Over-Current Trips" is a (most) highly desired feature

    Perhaps less so when helpfully also connected to an NMI interrupt.

    Robert

  • 0 in reply to Robert Adsett
    Guru 47900 points
    As stated previously - this "automatic clearing" of all PWM Outputs does NOT require (any) S/W intervention - especially that of an interrupt. (NMI or other) The PWM Fault Input - tied to analog comparator's output - shuts down all PWM outputs - NO interrupts are employed...
  • 0 in reply to cb1
    Prodigy 80 points
    hmmmff, well I guess ADCSequenceDataGet() has been staring at me all this time, another curious case of CamelCaseBlindness(tm). Thank you guys, your ideas are most appreciated.
  • 0 in reply to Engin Bilgin
    Guru 117855 points
    MCU (here) is new to you - not so much to posters Robert & cb1.

    I do urge you to "test/verify" - too often there's NOT time for that - yet there's (endless) time (later) to "discover" design mistakes which should have been caught/corrected SOONER - rather than later. (and at far higher costs!)

    Thank you for the Verifies - glad to assist...