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.
Please click the Verify Answer button on this post if it answers your question.
In reply to Charles Tsai:
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".)
DEEP SEARCHhow 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!"
In reply to Bruno Saraiva:
In reply to cb1_mobile:
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?
In reply to DEEP SEARCH:
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!
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)
All content and materials on this site are provided "as is". TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with regard to these materials, including but not limited to all implied warranties and conditions of merchantability, fitness for a particular purpose, title and non-infringement of any third party intellectual property right. TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with respect to these materials. No license, either express or implied, by estoppel or otherwise, is granted by TI. Use of the information on this site may require a license from a third party, or a license from TI.
TI is a global semiconductor design and manufacturing company. Innovate with 100,000+ analog ICs andembedded processors, along with software, tools and the industry’s largest sales/support staff.