• State Resolved
  • Locked Locked
  • Replies 9 replies
  • Subscribers 31 subscribers
  • Views 2086 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.

DK-TM4C129X: Can GPTM be used as a delay line from a CCP input to a uDMA trigger?

Leo Bredehoft58
Expert 1260 points

Part Number: DK-TM4C129X

I would like to be able to adjust the time of occurrence of a DMA, relative to an external signal requesting it.  Is it possible to connect that external signal to a GPTM CCP input and cause the timer to generate a uDMA trigger a configurable number of clock cycles after an edge on the external signal?  What is the setup for this?  Do you have example code?

  • 0
    TI__Guru**** 191886 points
    Hi Leo,
    One way you can try is the Input Edge-Count mode in the GPTM. What it will do is to count the number of edges detected against a programmable edge count. When there is a match, an interrupt/DMA request is asserted.
  • 0 in reply to Charles Tsai
    Guru 117855 points

    Hi Charles,

    Your solution (may) be valid - provided the poster is able to input a sufficient length, "pulse train."     (i.e. so that the "number of edges required - is met - such may be "beyond" poster's intent, though)

    While I'm no expert - would not that same Timer - configured as (simple) ONE-SHOT (set to poster's desired delay) prove a more direct solution?     (such would accept a SINGLE input pulse - and then (one hopes) trigger the µDMA upon one-shot's expiration...)         I work w/too many (other ARM MCUs) to recall the exact operation of those here - yet I KNOW we've succeeded w/this method w/(others') ARM MCUs...

  • 0 in reply to cb1_mobile
    TI__Guru**** 191886 points
    Hi cb1,
    Thanks for the idea. I was at first thinking the same line too but the poster wanted to detect an external input pin and creates a programmable delay after the edge is detected before triggering the uDMA. The one-shot timer mode does not use the external pin and hence I dropped the idea. I was also thinking to first generate an interrupt upon detection of an edge and in the ISR start another timer and use the timeout of the second timer to trigger the uDMA. But this is perhaps a bit more complicated if the poster can provide a free running pulse train.
  • 0 in reply to Charles Tsai
    Expert 1260 points
    The only reason for using the timer hardware in the first place is to provide tight, adjustable timing for SSI acquisition of ADC data at 1 Msamples/second, so software involvement is out of consideration. If external hardware becomes necessary, I'll just do the delay there. From what I'm hearing now, the GPTM's won't support the kind of "clocked delay line" behavior I'm hoping for. Is that true?
  • 0 in reply to Leo Bredehoft58
    Guru 117855 points

    I believe that a "single edge pulse" - input to any common GPIO - may trigger a, "Highest Priority, Pre-Emptive Interrupt" which is "guaranteed" to enter its ISR w/in 6 MCU cycles.     The first instruction w/in that ISR would "launch" a Timer - configured in one-shot mode - and the "expiration of that Timer" would (then) trigger your µDMA.       (note: this depends upon the ability of the Timer - in one-shot mode - to produce such a µDMA trigger - that detail, "left for the reader.")

    Unstated is the "extent" of the delay you require - yet it seems a delay as small as "8 MCU cycles" (may) be achievable - and delays beyond that are deterministic, guaranteed - and precise.

    Might this solution method meet your objective?      

    The software involvement is "one-time" and essentially confined to: GPIO & Timer - set-up/configuration - and simple ISR - thus may (just) warrant consideration...     (especially so as this method overcomes any/all external HW involvement/size/cost/effort...)

  • 0 in reply to cb1_mobile
    Expert 1260 points
    I wouldn’t want to go down the software road – I’m trying to get an SSI ADC dump to take place as quickly as possible after ADC busy deassertion, with minimal jitter, which I would have to slow down to accommodate. SSI dump jitter with the current, improperly-delayed solution is less than 100 ns, which I would like to retain.
  • 0
    Expert 1260 points
    I wouldn’t want to go down the software road – I’m trying to get an SSI ADC dump to take place as quickly as possible after ADC busy deassertion, with minimal jitter, which I would have to slow down to accommodate.  SSI dump jitter with the current, improperly-delayed solution is less than 100 ns, which I would like to retain.
    This message has been marked as Medtronic Controlled
     
  • 0 in reply to Leo Bredehoft58
    Guru 117855 points
    That's your choice - note that Charles & I have devoted time, thought, effort in your behalf...
  • 0 in reply to cb1_mobile
    Expert 1260 points
    Thanks very much for answering my questions.