TM4C1294NCPDT: Trigger periodic timer from pin

Robert,

One possible shenanigan would be to try Wait-for-Trigger mode... I have never tested it with an external signal...

The idea would be: configure your incoming GPS signal as a TCCP input pin of a TIMER_N, which is configured as edge count mode configured to one single edge.

Configure your 10Hz timer to wait-for-trigger on TIMER_N+1.

I am not sure that the single pulse input will be a valid "timeout" on the first timer to trigger the second, but it is a possibility.

The other option I see is to actually measure the clock rate between a few consecutive PPS's (you do get one per second, don't), and do a bunch of chain calculations: you can read the exact moment your PPS arrived, again using TCCP in edge time mode, The either "assume" you MCU clock is precise (say 120,000,000 equals to  one second), or calibrate it. Then do some math and figure out an expiration value for a synch timer (yep, this description got to shenanigan...)

Oh, another: measure the cycles taken by a ROM_GPIOPinRead plus a TimerEnable, and deduct that from the first configuration - poll your GPIO signal on the first run... (still, how can you trust that your MCU clock is precise? Do you plan to have a continuous 10Hz pulse after that? Eventually GPS PPS and MCU will out-sync, won't?

Good luck!

Bruno

Robert Cram said:

I do not want to start the timer by calling start() from an ISR

I also read this request - and after a search thru the Timer APIs - noted the "wait for trigger."      (yet have no experience doing - or using such...)

Yet I would ask, "Why is the (obvious) "Detection of signal edge upon a select GPIO - resulting in an ISR (which (instantly) ENABLES an (already) fully configured Timer) deemed undesirable?      This method should surely work - and the ISR may be granted highest priority - what IS the objection?

One wonders if poster may have "missed" the fact that the selected Timer may be fully configured - and ready - and awaiting the simple "GO" - launched immediately via entry into the (dreaded) ISR!

it proves ALWAYS true - that such "poster restrictions" are NEVER explained nor justified.      (thus are most often - unreasonable & w/little merit!)

Cb1,

The use of ISR is totally nondeterministic, despite the priority level assigned.

You could be serving another ISR during the pulse - and then, your timer GO would happen only after that one is finished - not an option for this case.

Bruno

Bruno Saraiva said:

The use of ISR is totally nondeterministic,

Does not "emotion" lead to your "Darden-like" use of "totally?"     (what if the "bloody glove" does NOT fit?     What then?)        May I submit this ARM document - which appears to "breach" your "totally!"     (appears that the (earlier) lesson learned "properly" has not yet, "sunk-in.")        "Words indeed - DO have meaning!"

Note that such "tail-chaining" IS accommodated here!       I will find & present "Pre-emption" - which bears heavily here - as well...    

And - can each/every of the competing methods be (really) awarded the title of  "Deterministic?"       Neither poster nor you (nor I) have implemented/explored - your "straw-man" argument may have holes...

(in response to Robert's query ot Timer's, "Edge or Time of Arrival" captures)

Indeed Robert - they do - I (even) read/reviewed that late last night - (both events AND "moment in time") of signal are captured/latched. (briefly - must then be "read/processed" or will be lost to "next" event.)

Missing link for our poster was the "Absence of any "auto trigger mechanism" (other than trigger of the MCU's ADC). Thus - the potential advantage of, "Other than the dreaded GPIO ISR method" declines - and STILL no "guaranteed to work" - alternative method - has arrived - these rocky shores.     (I sail this weekend - docks, whales, other vessels - all are targets...I've "promised" the CG that I'll not - "run aground, again.")

Bruno Saraiva said:

You could be serving another ISR during the pulse - and then, your timer GO would happen only after that one is finished - not an option for this case.

Let the record note that NO support is offered in justification of the above!      Can that ever be "good" - it can never be "compelling!"

Now comes data - originating from ARM - which offers HIGH DISPUTE to the quotation, above.      Illustrated here is the concept of, "Pre-emption" - employed by ALL ARM Cortex MCUs - which forces the halt to an executing lower priority interrupt - and after 6 cycles - launches the "just arrived" higher priority one!        And this (just may meet) the criteria for "Deterministic."

It is "ok" to have opinions - even better to offer up those w/proven validity - and (some) independent support...

You will note the higher priority interrupt (IRQ2) "kicking the already executing (IRQ1) to the curb!"      (credit singer "Kesha" for, "curb kicking")

Robert Adsett said:

And when interrupts are disabled that time gets added non deterministically to the interrupt.

While I love your reasoning power - that quote is a bit (pardon) "imprecise" for my taste.       Let's dissect - try to aid clarity:

• ...disabled (that time) - of  "which"  time do you speak?     In our case in point - no such "disabling of interrupts" is allowed - when we are set-up & configured (i.e. waiting) for our "High Priority, Special" signal's arrival
• ...added...(to the interrupt) - again "which" interrupt?     Surely NOT the, "High Priority, Special" interrupt - which has (long) been pre-configured - and only awaits the input (trigger) signal's arrival.

Agreed that there (may) be (large number of cases) - but our poster has made no mention of such - we must "try this case" w/facts - "admitted and in evidence."

Under the known facts - presented here - the use of "highest priority" for his "special signal" - appears the best/brightest (and ONLY) workable SOLUTION presented...     (and intriguing as it was the ONLY one disallowed/rejected!)

I attended an ARM based conference in the UK in 2015. A demonstration was provided - with the "highest priority interrupt signal trigger - and its ISR (both) enabled - and it was established that, "Entry to that "high priority" ISR, + 6 cycles" marked the time elapsed - until a "monitoring Led" came to life...   (first function w/in the hi-priority ISR)

It remains unclear to me why (any) pre-existing, disabled interrupt(s) - can inflict delay upon this (already enabled) high priority interrupt.

Just reviewed the capture mode of the timers, or as TI calls it edge timer mode. I'm not seeing why that cannot be used.

I didn't grab the 129 documentation so maybe it's different but the documentation I did read suggested both 24 and 48 bit modes were available. 48, at least should be sufficient for the task.

Robert

Interrupt disable by its very nature disables all interrupts except for NMI and processors exceptions (divide by zero, bus faults). That's rather the point of having the instruction. It works that way on the ARM architectures as well.

Robert

Robert Adsett said:

I do agree some information on what the poster was trying to achieve rather than just the technique they are trying to use would help us help.

Helping the enfeebled "Helper Crüe" appears NOT high on his list.     (although - after he received Bruno's response - may be "long gone.")

To your, "In the capture interrupt you can read the capture and current time."       Do you/I agree - that there exist (both), "EDGE COUNT Capture and EDGE TIME Capture" capability - and that these are "separate?"     Both may be achieved (simultaneously) by routing the input signal to two Timer input pins - programmed to encompass both modes.     I do NOT believe that was your point, though.

Might the fact that the MCU's external "Timer Pin" must serve (both) input and output demands - due to that added (MCU internal) routing complexity - subject the actual "Time of Signal Arrival" to (some) error?

I remain at a loss to fully understand what's really sought here - unless a "10Hz Timer" is to be initiated (and thereby KILLING/REPLACING) any existing 10Hz Timer - upon each/every - "special" signal arrival.     Is that your understanding, Robert?

cb1_mobile said:

To your, "In the capture interrupt you can read the capture and current time."       Do you/I agree - that there exist (both), "EDGE COUNT Capture and EDGE TIME Capture" capability - and that these are "separate?"     Both may be achieved (simultaneously) by routing the input signal to two Timer input pins - programmed to encompass both modes.     I do NOT believe that was your point, though.

Both true. I was referring to reading both the capture register and the active timer value register. But subtracting the former from the latter we have a straightforward measure of how much time has elapsed since capture. It is unnecessary to start you first 100mS timeout at the same time as your capture, you can shorten it by this delta time.

cb1_mobile said:

Might the fact that the MCU's external "Timer Pin" must serve (both) input and output demands - due to that added (MCU internal) routing complexity - subject the actual "Time of Signal Arrival" to (some) error?

I would expect that to be less than the clock period though.

cb1_mobile said:

I remain at a loss to fully understand what's really sought here - unless a "10Hz Timer" is to be initiated (and thereby KILLING/REPLACING) any existing 10Hz Timer - upon each/every - "special" signal arrival.     Is that your understanding, Robert?

That might be what's being attempted, correcting the timing by periodically restarting. I though the usual technique was to adjust the time base instead which would be a lot simpler and avoid periodic large changes.

Robert

This:

Robert Cram said:

3) a signal on a pin to start a periodic timer, in some hardware-ish/periperal-ish rather than ISR-ish way.

is confusing. I see two possibilities

1. You want to set on output pin immediately upon receiving the pulse, in which case there is no need for processor intervention. It could only make things worse
2. You want to start a timer (or series of timers to output a limited chain of pulses). In that case the approach I outlined will achieve that without needing any tight timing

You seem to have rejected the third possibility of that you want to make the timing more accurate. Maybe there's fourth?

Robert

Poster's "mystery" signals (while much suggesting):

• there's a "book deal" in the works
• as with "ACA" (Affordable-Less "Care" Act) - we must "Pass the bill" before learning the bill's contents.     (if that's ever to be revealed...)

We are (nearing) some 30+ posts "into this" - yet poster will NOT - release us from our (combined) misery...    (Not for me...)

The approach is simple. In more detail

1. Use the timer capture to capture when the pulse occurred. This would also trigger an interrupt
2. In the interrupt read the current time of the timer (a) as well as the captured time (b).
3. Set up a timer for your 100mS edge it will occur 100ms - (b-a)ms from now (already determined as b).
   • This one-shot timer will set the output and trigger an interrupt to re-load it in SW
4. Record a time c that is 200ms from a. Use this time in a subsequent interrupt to set the next edge.
5. Once you've finished your string of pulses you can stop and wait for the next input.

100mS is a long, long time on this processor. You have plenty of time to set up the edges w/o worrying about latency. The interrupts do not even need to be high priority. The sequence from 2 to 3 should be protected from interrupts so that it remains deterministic but there's really nothing else that's critical. This setup is actually probably doable even on a much slower processor.

That's assuming you are setting a limited number of pulses each time. If you are outputting a continuous 10Hz wave it's probably better to adjust your time base instead. it's closer to  continuous and simpler.

Robert

Robert Cram said:

Indeed, item 2 is what I'm looking for (a hardware-level, pin-triggered periodic timer)

This is confusing. Item 1 is a hardware level pin-triggered timer. Item 2 is an internal to the micro timer.

Also periodic suggest an infinite series of pulses, while other parts of your post suggest a limited sequence.

it may be worth your while for yourself to sit down and write out your needs in a clear fashion.

Robert