• State
  • Locked Locked
  • Replies 6 replies
  • Subscribers 31 subscribers
  • Views 598 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.

TM4C1294NCPDT: How do I generate an output pulse N clock cycles after an input?

Lucas Hartmann
Prodigy 100 points
Part Number: TM4C1294NCPDT

I have a periodic input signal, and want to generate a rising edge 90 degrees after that of the input.  I thought of using a TMRxA capture input for time reading (period and phase calculated from there), and this works fine.

However I can not find a way to use TMRxB to generate the output rising edge... I can start A and B synchronized, but compare actions only happen on timeout, so I would need to break sync to make it work... Worse, starting compare on an ISR adds an unpredictabledelay.

To put this other way, I want to generate an output signal with a rising edge delayed exactly N clock cycles from that of an input signal.

Any ideas?

  • 0
    Prodigy 250 points

    Use an externally triggered timer in single pulse mode

  • 0
    Guru 117855 points

    I agree w/poster,  "millwood's"  suggestion -  that  "Single-Pulse"  (called "One-Shot"  here)  is well chosen.

    That said - your comment,  

    Lucas Hartmann said:
    Worse, starting compare on an ISR adds an unpredictable delay.

    may NOT be as,  "well  chosen!"      Are you suggesting that the ARM, Cortex "M" series of MCUs prove  "NOT Deterministic" -  especially in their response to interrupts?      Such WAS one of the central intents - of the ARM Design team - and is well noted.     (and easily confirmed)     From where did you draw such conclusion?

    Twelve system clocks elapse between the "Interrupt Trigger" and "Entry into the ISR" - provided one observes (suitable) design guidelines.     Those guidelines may include:

    • Promoting  the "Key" Interrupt  to the capability of, "Pre-emption."      (such allows it to halt (even) another interrupt "in process" - and execute to completion - only (then) automatically enabling the "halted" interrupt to  "continue/complete!")      Most impressive...

    That's "Not so unpredictable" is it?     You are not alone in such thinking - yet the extraordinary success & overwhelming adoption of ARM MCUs - makes their "miss" of  such key features ... unlikely!     And (that) was entirely  "predictable..."

  • 0 in reply to cb1_mobile
    Prodigy 100 points

    So it is predictable as long as you do the ISR code in assembly, count cycles across all possible branches, and use no critical sections (interrupts disabled) on lower priority code. I am not entirely sure how FreeRTOS manages signaling, so I have to assume the worst (I am not blaming ARM for this ;-).

    Anyways, I could not find how to use external trigger input. All the tivaware user guide mentions is using the timeout of one timer as a trigger to the next.

    Maybe I could use a capture-count timer with a period of 1 to trigger the next one. Takes up one extra timer, but should work.

  • 0 in reply to Lucas Hartmann
    Guru 117855 points

    Lucas Hartmann said:
    So it is predictable as long as you do the ISR code in assembly

    Once again - I believe your belief to be "mistaken!"     One of the key objectives of ARM was to insure that ISRs could be coded - entirely - in C!

    You do not have to "count cycles" - if your key interrupt is promoted to,  "Pre-Emptive" - its entry to its service routine will prove (highly) predictable.    It appears that my earlier noting that,  "ALL lesser interrupts will be (temporarily) halted - so that  the one "Pre-Empting" receives IMMEDIATE SERVICE -  may not have been properly absorbed.     You DO NOT have to "disable interrupts!"

    ARM MCUs are "orders of magnitude" beyond most earlier, embedded classed, MCUs.     When you have free time - your visit to ARM's (very large) web-site - will present a "treasure-trove" of documents - sure to (better) inform your opinions.      In defense of this vendor - their MCU manuals (already) exceed 1K pages - it is hard to justify their (improved) promotion & description of the unique benefits - afforded by ARM.

    You - just now - introduce "FreeRTOS"  (BTW - you/others should know - FreeRTOS has been licensed by (both) MIT & Amazon Services - highly impressive.    (and of course - accommodates BEYOND - "one and only one" vendor's  MCUs.    (So mistaken (can you say LIMITING) ... that...)    I'd avoid (any) RTOS at this early stage - more "complexity" will neither speed nor ease your objective...

    We should note that your use of  "Multiple Timers" - rather than "just one" - is inspired - and very likely to,  "Speed, Ease & Enhance" your code's development.    "Premature Optimization" as noted by friend Robert here (et moi) so often leads to "flawed & delayed" development.     (far better to "complete your project - only (then) probe to see if, "Anyone beyond yourself  REALLY CARES  for the (always) delaying "optimization!")     (hint:  90%+ of the time - they do NOT!)

    "Proceed by Refinement" - long has been a byword (another description of the banned "KISS" - which advises its proponents to,  "Accomplish the Mission in:  Small, Distinct, Measurable, Systematic Chunks - especially AVOIDING any/all attempts at "optimization" - till (later).     (if ever!)

    Might you better (and further) describe your difficulty w/ "How to use external trigger?"    There are multiple triggers - and multiple functions which (may) be triggered.    Better specification IS required...

  • 0 in reply to cb1_mobile
    Prodigy 100 points
    ARM is awesome, I get that, and that's why I am using it. I know about premature optimizations, and why they should be avoided. But I also know I must understand my system before I can plan anything on it.

    How do I generate an output rising edge N cycles delayed from an input rising edge, with no software timing dependency other than ISR completion before the second edge.

    I can not depend on ISR entry time because:
    - RTOS or user code may disable interrupts for short intervals in critical code.
    - I may need to generate the delayed edge for more than a single channel, and they may happen, let's say, 3 clock cycles apart.

    In those old, awful PIC microcontrollers all I needed was to set a capture on one channel, get the edge time, add N, and set the compare on the other channel. Using "timer match" allows delayed software action, but not compare pin output.
  • 0 in reply to Lucas Hartmann
    Guru 117855 points

    Your restriction - introduced by the RTOS - is one of (several) downsides to RTOS - which I believe (too often) to be glossed over.   (only the "hoped for benefits" are admitted...)

    I'm rather sure that programming staff here (my small firm - beyond me) CAN achieve your goals - yet the "intrusion of the RTOS" - places us in a (likely) untenable position.

    Vendor staff  however - are skilled, trained & "connected" (to inside info) - they should be able to (further) guide you.    (although the RTOS will (likely) complicate & delay their efforts - as well...)