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.

TM4C123GH6PM: Understanding Input Edge-Time Mode: Detect missing edges when counter/timer overflows

Part Number: TM4C123GH6PM

Hello,

I am working on understanding how the Edge-Time Mode Timer works on the TM4C123GH6PM, in particular, clarification to the note shown below from the datasheet. The idea is to capture an edge which happens to fall outside the 216 or 224 (with prescaler enabled) count values. I know the 32-bit/64-bit timer can be used to generate 248 with a prescaler can be used to count higher time events, however, I want to experiment with using a periodic timer as the note suggests.

  1. The first bullet point states "periodic timer cycles at the same rate as the edge-time timer"
    • From my understanding, this means to use the same clock source.
  2. For second bullet point, I don't get why we need the periodic timer needs higher priority
  3. I don't understand which counter should be subtracted, the peroidic timer or edge-time timer?

 Overall I am having a hard time understanding how the periodic-timer helps capture the missing edge.

Thanks,

Fil

  • May I first note that your post is very caringly presented and well organized.    For one SO new here - yours proves,  "Off the chart" good!

    To your issue - while the MCU Manual made great effort - I agree that (both) descriptions (Edge Time & Edge Count) could have been improved.    It is noted that the devil lurks in detail - yet the "degree of detail" - often proves difficult to determine.

    Filmon Elias said:
    The first bullet point states "periodic timer cycles at the same rate as the edge-time timer"
    • From my understanding, this means to use the same clock source.  

    It (may) be possible to employ a different clock source - yet that introduces added risk & effort - demanding,  "to what point?"    Thus the choice of identical clock source  AND  identical timer cycles.   (both periodic & edge timer)   Minimize and/or eliminate error sources.

    Filmon Elias said:
    For second bullet point, I don't get why we need the periodic timer needs higher priority

    The periodic timer serves as your "Check Valve" - it (alone) determines if an "expected edge" has "gone missing."    Clearly then - its service (must) over-weigh that of the, "Item being monitored."   (edge timer - in this case)

    Filmon Elias said:
    I don't understand which counter should be subtracted, the peroidic timer or edge-time timer?

    I bet that you DO understand!   The periodic timer is the "Check Value" - it alerts to a "Delayed or Missing" pulse - that's NOT to be counted.   (unless for statistical [error incidence] reporting.)    The Edge Timer - which (likely) incremented (illegally - due to "time-out") must be corrected - thus it receives the subtraction.

    Firm/I always urge client-users to,  "Devise simple MCU-based experiments" - to reinforce key: "beliefs, knowledge & understanding."     You may program a GPIO to regularly provide pulses - feed these to your selected Timer Input - and upon a certain "count" ...  delay (or "swallow") one of those pulses - while monitoring the  Edge Timer's reaction.    

    If I recall correctly - the Edge-Time mode monitors & logs, "Snapshots in Time" during which your selected event - is captured.    The (separate) Edge Count mode - more simply - tracks the "Number of events" which have transpired.    

    You may wish to consider - "When best to employ either?"    If the input signal is "high enough in frequency" - Edge Count is (usually) selected.    Very low frequency signals benefit from Edge Time mode - in which the "differential in time - across several pulses" enables a higher accuracy frequency measurement...    (yet only after the,  "Period to Frequency" conversion is completed...)

  • If your subject title reflects your concern, all you need is to check for the interrupt flag, via a capture interrupt or polling.

    If the body of your question reflects your concern, you can check the overflow flag, or increment a variable in the overflow isr that serves as the high byte/word/double word for the capture counter.
  • Appreciate the response cb1_mobile.

    Sorry but I still question how the periodic timer catches a missing edge, please advice which image below best represents how the two timers would interact.

    Image 1

    Image 2

    Image 3

    Thank you again,

    Fil

  • Thank you Danny.

    I get what you mean by counting every overflow like the image below. I am just curious about the method the datasheet it describing.

    Count by variable

    Thanks,

    Fil

  • Filmon Elias said:
    I still question how the periodic timer catches a missing edge, please advice which image below ...

    I prefer "not" to be drawn into your scope of how such issue should be addressed.

    I have stated - and will do so again - "Should the Periodic Timer generate its interrupt - that indicates that the,  "Expected Signal Edge" has not arrived in a timely fashion."     And - it is my belief that the Edge Timer may well "increment" as it "reloads" and launches another count sequence.

    If the issue is language - maybe I'll defer to your diagrams.    I prepare "Technical Contracts" as one aspect of my job - and such "drawings" prove not as "clear/convincing" as the written word!

  • "I don't understand which counter should be subtracted,"

    simple: "-1" = "+ (-1)" = "+ 0xffff", the default period in that particular setup.
  • Thanks, cb1, I was thinking the periodic timer would be used to capture the time between two edges. But now I see the idea is to resize the edge timer based on when the first edge is detected.

    Appreciate your help and dealing with my naivety.
  • Ha, I see, it wraps around from 0 to 0xffff.

    Thanks,
    Fil
  • Thank you my friend - and "Not so" naive!    Quite a good set of questions - and again - the care & preparation that went into your post - were (very) well noted. (and appreciated)

    Speaking to "preparation & appearance" - as your career advances - and you get to enjoy  "fine restaurants, boats, autos etc." you will note that  "preparation & appearance play MAJOR ROLES" - and the obvious care & attractiveness of  your post (I'm sure) served as an effective Magnet!

    On similar "difficult to initially grasp" tech situations - if your brain "works like mine" (staff offers their condolences - should that prove true) I find that  most always - placing carefully considered "experimental values" into the key MCU Registers - and then running the code - will GREATLY  "Speed & Enhance" understanding.    (the (very) bright can "skip that step" - not so - for me...)     (and - had you noted - despite the added weight/wind resistance of my "shell" - my (ditch residing) rabbit competitor "spun out" on that last turn - and NOW I'm ... properly - back in the lead...)

  • just so you know that approach isn't terribly reliable. I wouldn't use it myself.