• State
  • Locked Locked
  • Replies 20 replies
  • Subscribers 32 subscribers
  • Views 7266 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

TM4C1290NCPDT: performance of GPIO

Brandon08
Mastermind 23425 points
Part Number: TM4C1290NCPDT

Team, I am trying to figure out how short of a GPIO pulse can be detected by the schmitt triggered GPIO inputs. We have a customer that would like to detect a 30ns pulse reliably as an event trigger in their system. Assuming the device is in active mode polling, can we reliably commit? I cannot find any technical specification in the datasheet to reliably say one way or another.

  • 0
    TI__Guru**** 159385 points
    Hi,
    Is there a reason why an interrupt method by detecting a change of the edge of the input not considered in the application? 30ns is about 3.6 cycles of CPU clock. Normally in design, it should be detectable for a pulse that is larger than 2 cycles. So as far as detecting a 3 cycle pulse I think it is doable. However, I don't think you can reliably poll an input with a 3 cycle width. It takes some cycles to read the GPIO register. I think the back to back read of a register will be greater than 3 cycles.
  • 0 in reply to Charles Tsai
    Guru 117850 points

    Greetings Charles,

    Recently - while working w/"Bruno" on his PWM measurement via MCU's Timer - we learned that an input signal (persisting high) for, "TWO MCU System Clock periods" is "guaranteed to be detected by that Timer!"      Note: Timer configured to, Input Edge (or) Input Time Count Mode.

    Via this method - no such "Polling" of an input is required!       We note that you (properly) identified the weaknesses of such "polling" approach.

    Might this be yet another demonstration where the "poster suggested" approach is not (quite) optimal?        This Timer approach appears superior - especially as it is essentially "AUTOMATIC" (i.e. the occurrence of the input pulse is "latched" - enabling a far less demanding "read".)

  • 0
    Guru 13040 points
    Hi there,
    As mentioned by cb1, the misleading word on your post is "polling".
    TM4C's - and the whole MCU planet - have interrupts for a reason! All your customer needs to do is configure the interrupt for a GPIO.
    Now, some considerations:
    - Different that timer edge capture, GPIO interrupt does not need two cycles to reliably process - if the GPIO input signal had crossed the boundary during one cycle, that will surely set a GPIO Edge interrupt - hence, >9ns is the number here for a TM4C @120MHz - 30ns detection is a piece of cake.
    - The ability of your signal actually being sent above trigger voltage for a given time is not related to the digital inner side of the MCU, but rather to the analog capacity of whatever is driving it - the capacitance of the GPIO's are published, and the time a signal takes can be calculated/measured for a particular circuit - of course, taking in consideration driver's health and trace and associated "thieves".
    - Not included in the question was HOW FAST must the RESPONSE be. That is a different story, and it depends on what else is running on the program, what are the ISR sizes, and what are the interrupt priorities - but the if 30ns is the desired response time, the answer is that no TM4C can guarantee it even if not doing anything else.
    Regards
    Bruno
  • 0
    Guru 117850 points

    DEEP SEARCH said:
    how short of a GPIO pulse can be detected by the schmitt triggered GPIO inputs

    Bruno my friend - might you have not taken the poster's saving, (hedge, above) fully/properly into account?        As you know - the Schmitt extracts (some) price for its advantage!

    If vendor's Charles states, "2 cycles" - then I'd vote w/him!

    Have you (carefully) constructed - the (very) briefest of signals - and routed it to the MCU - and "confirmed" your "single cycle OR LESS" theory?       (high stack of chips placed upon, "NO!")

    Certain professions "dwell more in small detail" than others - might that be (especially) required, here?

    It is noted that, "While the "Search is claimed to be Deep" - it is FAR from Responsive!"

  • 0 in reply to Bruno Saraiva
    TI__Guru**** 159385 points
    Hi Bruno,
    Thanks for your insights. I think we all agree that polling cannot be done reliably at 3-cycle width. I'd like to share a bit of my experience as a designer before. Normally in design, to avoid metastability we will run an asynchronous signal through two flops. This is the reason I stated that two cycles will be fine. If an input signal width is very close to the clock cycle then it may not detect the edge in all PVT (process corner, voltage, temperature) corner in conjunction with tolerances such as PLL jitter.
  • 0 in reply to cb1_mobile
    Guru 13040 points
    True, the datasheet says nothing about the minimum pulse time for the GPIO to perceive a change... nowhere!

    I dug my comment from the dark layers of my MSP430 past experience: one cycle there was sure to be captured.

    I guess one can assume, after seeing all considerations here, that one cycle is barely possible, but two are kind-of-certain. The overall comments tell poster that his 30ns won't be a problem, and that polling is not the way to go (as you quickly stated).

    Have I (carefully) reconstructed the signal? No!!!! - I don't even have hardware for such! The fastest thing I have is indeed a 120MHz launchpad. My function generator is 70MHz, and I'm not even sure I could configure it for a single pulse. More money needed into this bench to construct a 10ns spike! Actually, the question made me wonder if I could generate a 1-cycle pulse with a TM4C by using two outputs, offset by 1 cycle somehow (an even timer used to trigger another, maybe?), and then a logic gate?

    Regards

    Bruno
  • 0 in reply to Charles Tsai
    TI__Mastermind 23425 points

    Charles,

    Lots of good discussion here. Am I understanding correct that if the MCU detects the signal via timer capture, or GPIO interrupt from active state (not polling) then the signal can be reliably detected, assuming the CPU clock is operating fast enough?

  • 0 in reply to Brandon08
    TI__Guru**** 159385 points
    Hi Deep Search,
    Yes, your understanding is correct.
  • 0 in reply to Charles Tsai
    Guru 117850 points

    In the attempt to best comply w/poster's "desire for depth" - we've just confimed the guidance provided by Charles - in which (sometimes) one System Clock cycle proves "detectable" - yet two such cycles (always) proves detectable!           We performed the combined, hardware/software test, below.

    Experimental Method:
    My group employed a Cortex M7 (alas, from another) and a (very) fast FPGA gate (another, other) feeding that gate's output into (two) TM4C123 LPads - via short, direct, shielded cable.     (only one LPad was used at a time - two used to better, "generalize" our findings.)

    Our M7 system clock was set to 200MHz (could be set higher) which yielded (math friendly) 5nS period.      Our "intercepting/blocking" FPGA gate - controlled by the M7 - could then pass a continuous "high level" signal of "integer multiplies of 5nS."      Our TM4C123s - clocked at 80MHz - thus had a 12.5nS period/clock cycle.

    Findings:
    A single M7 clock pulse (high) width (5nS) was NEVER detected by the 4C123 - nor were 10nS pulse (high) widths - but on occasion (3 out of 20 runs) we detected the 15nS pulse (high) width!    That 15nS is just beyond (by 2.5nS) the 12.5nS - single cycle - 4C123 period.

    And - just as Charles reported - when we "extended" the gate's pulse (high) width to 30nS (which exceeds two 4C123 cycles [25nS]) we ALWAYS succeeded in such pulse detection!

    Summary: 

    Thus the experience/guidance provided by Charles - at least in this (limited) test methodology - has been confirmed.

    "20 out of 20" could (surely) be improved (repetition wise) - yet appears, "Good for Gov't Work" - and just may qualify as "Deep."        (sorry - could not resist...and (eventually) you did respond)

  • 0 in reply to Bruno Saraiva
    Guru 10570 points
    Good catch on the response time Bruno.

    As a side note, if a fast response time is not needed neither is the fast detect likely needed. A pulse is easily stretched or even latched in HW, unburdening the micro.

    Robert
  • 0 in reply to cb1_mobile
    Guru 13040 points
    Awesome awesome awesome awesome!!! (can't click the LIKE button that much, you know that).
    Can I be as curious as to ask what happened at 20ns and 25ns (this one critically coincidental to 2x TM4C123 period)?
  • 0 in reply to Robert Adsett72
    Guru 117850 points
    OMG Robert - that's SO true - and missed by ALL here! Do note my experimental results - which confirm Charles' belief.
    What "catch" by Bruno? (response time?)
  • 0 in reply to cb1_mobile
    Guru 10570 points
    Yes, Bruno noted that the needed response time has never been mentioned.

    Nice test, although I might hedge a bit about process, temperature and signal variations. Shows nicely where the limits likely are though.

    Robert
  • 0 in reply to Bruno Saraiva
    Guru 117850 points

    Bruno Saraiva said:
    Awesome awesome awesome awesome!!!

    NOW (that's) a "proper" reward for "cracking the whip" upon "eye-rolling, (Do cb's dirty work)" highly skilled/motivated (or they're "faking it") staff!

    Guess what - cb1 FAILED to "Test at either of the points you just mentioned!"     (20nS as it is still in, "No Man's Land" (i.e. between 1 & 2 "4C123" cycles) - but 25nS - was (my) clear screw-up!)      Although - (still) clinging to (sometimes) perfection - may I claim that the "desire for a "safety factor" excluded 25nS from consideration?        NO - I just screwed that up - will repeat - when (maybe "if") crack staff (ever) return from lunch...

    The bar has been raised high for the award of FIVE "awesomes" - but w/boards "at the ready" - and my curiosity aroused - and (almost) skilled labor present - how could I not launch?    (expect that I'll hear re: (almost) crack - yet I write for my amusement...)

    BTW - I bet you that Charles' findings extend to the MSP family as well - while you (surely) saw a success - I suspect it would drop drastically in frequency - if employing the test method shown here...

  • 0 in reply to Robert Adsett72
    Guru 117850 points

    Robert Adsett72 said:
    Nice test, although I might hedge a bit about process, temperature and signal variations.

    Look - have I not been dragged (kicking, screaming (ok crying) enough) [by Bruno's discovery of my screw-up] that we may (this once) forego "PVT" variations?

    That said - have you not just provided cb1 an "out?"        Clearly I "avoided" 25nS (precisely 2 "4C123" cycles) due to the fact that (I just knew) Robert would soon arrive - and demand "guardband!"     (very well provided by my test @ 30nS - which should satisfy (even) YOU!)        (maybe...)

  • 0 in reply to cb1_mobile
    Guru 10570 points
    Of course, that clearly explains the gaps.

    Seriously though that's a nice set of measurements.

    Robert
  • 0 in reply to cb1_mobile
    Guru 13040 points

    C'mon, don't minimize your endeavour! It was really great.

    And to be fair, I really got CURIOUS about those other values - almost to the point of assuming you had the numbers and just decided not to overcrowd the report...

    But having seen your other comment - the one on whipping the staff - here's my step-by-step process upon reading the experiment:

    - Came to a conclusion that staff should have tested/reported

    - Prepared a mental note and saved an image for the purpose

    - Decided not to whip the fellows

    - Read your comment later on

    - Changed my mind to endorse the whipping and post the aforementioned image: "Shouldn't this evaluation be done by someone with a badge?" :)

    Cheers!!!!

    Bruno

  • 0 in reply to cb1_mobile
    Guru 13040 points

    cb1_mobile said:
    I bet you that Charles' findings extend to the MSP family as well

    If I recall, the fast one back then was 16MHz, maybe 25...

  • 0 in reply to Robert Adsett72
    Guru 117850 points

    Robert Adsett72 said:
    Seriously though that's a nice set of measurements.

    I had "hoped so" too.     Biggest hurdle was "pulling staff" from their (critical) social updates - so that we (might) run such "kool" experiments.      

    I'm thinking - (but only if we succeed and SHIP (day late product) today) - that if I could (almost) "Sync" the FPGA gate's output w/"4C123's system clock" - we may "harvest" better than "3 of 20" pulse detections - when LESS than 2 MCU cycles arrives as input!

    Of course - both Bruno's and your recognition of "Response Time" (sorta) lessens the value of this otherwise (great) investigation...        (Oh well - excitement peaked briefly - now back to "design/test - tweak design/retest - pray/test & now SHIP" reality...)

  • 0 in reply to Bruno Saraiva
    Guru 117850 points

    Mes Amis,

    If "youse guys" (pure Chicago, or NYC) keep poking/prodding - I may "Cross 70K forum threshold - sooner rather than later.    

    Whipping (must) be done w/(some) care/concern - as "not all" here are "fellows!"      (indeed we "try" to impress each other - even (perhaps especially) those "opposite.")

    There was NO hidden agenda - simply my screw-up - and to be fair - I did NOT fully explain what we were after.     It was a good opportunity to "play" w/our new FPGA board - and (everyone) [but for Raymond] LOVES the Cortex M7 board!      (apologies for the "inside TV" humor - but I lived 13 years in L.A. - still SELL to Movie, TV, Recording Studios... they will "GET and Appreciate" that reference...)