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.

Does Interrupt-on-change feature exists in Stellaris LM4F120?

Hi guys,

I am looking a feature which actually exists in PIC microcontrollers called "Interrupt on change", which is a kind of feature whenever there is either a rising edge or a falling edge on the selected pin, the controller generates an interrupt.

I am looking for the same feature in stellaris LM4F120, does this feather exists ? if not can i tigh two pins together such that i make two interrupts one on rising edge and other on falling edge will that work ?

Actually, I am working on a protocol recognition which is actually stream of bits at 1-1.5MHz and i want to capture the rising and falling edges and transfer the data on spi port, can i implement it in M4 or M3 devices ?

I thank you for all of your replies.

Regards

Sahil

  • I am sorry it is feature instead of feather
  • Re: GPIO Interrupt upon a signal edge.

    Yours was the very first Stellaris entry into Cortex M4 and in fact was an LX4F - no LM4F were produced.

    Suspect that you can best answer your question - and aid your understanding - by a scan of the GPIO section w/in the MCU manual.  In addition - your read/review of StellarisWare (9453 in particular - the last StellarisWare version which included LX4F - btw) will list the function calls which may enable your target interrupt.

    You're correct about the use of a 2nd port and/or pin - with each port/pin set to interrupt upon opposite edges.  This always works - but at the cost of a pin.

    Remember to employ pull-up/down resistor to insure that the MCU sees valid logic levels - at all times.

    As your part has long been retired - handle w/extreme care and/or acquire newer, low cost eval boards - likely w/more modern & more capable MCUs...  (should you choose the newer MCU route - review MCU data so that you choose a device which supports your "any edge" need...)

  • And I thought you were being colourful :-)

    Cb1 has got it right on this, start with current chip and documentation.

    Robert
  • Mon ami,  (Re: "Got it right - "on this")

    Might you be (implying) that I, "Got it wrong" elsewhere?    (will not be the first (nor likely) last time, either)   At least - you/I "show up/try!"
     
    My boat's been becalmed in the Pacific for days - yet the water had more "chop" than forum "stir" - here...

  • Hi,

    Thanks to all of you for your replies.

    So for the current hardware which is LM4F120, I should use two interrupt pins tight together with pul-downs and having rising edge on one pin and falling edge interrupt on another pin, hopefully it will work ?

  • We see no mention of your read/review of MCU manual - which supplies the "real" (and best) answer.

    If you go "two pin route" it may prove safest to choose 2 different ports. (some of these older MCUs could only accommodate a single interrupt edge - iirc.)

    Do realize your MCU is neither repairable nor replaceable - great care must thus be employed - and (any) learning gleaned from such "dead/buried" device may not (fully/properly) transfer to any "existing" (available for purchase) device...

  • Hello Sahil,

    Did you read the data sheet (GPIO chapter). You would find your answer on just more than rising or falling edge!!!

    Regards
    Amit
  • Hi Amit,

    Recall that poster's (abandoned) MCU was a very stripped down version. (e.g. w/out PWM module & other "normal" MCU capabilities)

    Believe mention was earlier made of GPIO chapter AND use of 9453 (which was the last (past) version which included LX4F). It may well be that this so limited version MCU supported only one edge - proper read will reveal...
  • Hello cb1

    No. This MCU supports falling, rising and both edge detection along side high and low level.

    Regards
    Amit
  • Hi Amit,

    Never to challenge "the source" but I seem to recall past client having extreme difficulty w/LX4F120 - and complaining mightily of its "stripped down" status. (hard to justify its selection for "first ever" Cortex M4 eval)

    To the "Both Edge" detection (this now from memory - perhaps > 3 years past) client was in a quandary as to "how" to properly configure one single port pin - to recognize both edges. It clearly worked when "pulled up" and logic low arrived - and when "pulled down" and logic high arrived - but the issue arose when the external signal (which was tri-state) was "at Hi-Z." In this case - that MCU's gpio behavior was erratic - and I recall that persisting across several devices.

    Begs the question now (for your current devices) - how should the "idle state of that dual-edge gpio" be best set when the sole input signal may drive high/low/or Hi-Z?   For example - do you recommend both pull-up & pull-down - and if so - how does that pin report when "No signal" (or a Hi-Z) signal is present?

    Further - if the GPIO "dual-edge" (one hopes) is "pulled-down" how then is it to recognize a "new" Hi-Z to low transition?   (Ans: it cannot)   Same holds true when pulled-up - and a Hi-Z to high transition occurs.   These (both) are edges - and will be unrecognized - thus the value of such "kitchen-sink" dual-edge detection is compromised - is it not?

    My earlier point - 2 separate pins - each properly pulled either up or down (but not both) & (properly) tied together - worked fine for that past client - dual edge (notably) failed!!

  • Hello cb1

    To be honest I have not seen an example for both edge detection. In one case when we tested we had a driver on the other side for the GPIO in both edge detection with a Pull Down (for noise immunity) when the driver side was not configured yet.

    Regards
    Amit
  • Hi Amit,

    At first glance - "dual-edge detection" is appealing.   Yet - w/some thought/consideration - if the idle state is "pulled up" how then do we recognize a "rising edge?"   (Assumed a tri-state source is driving.)   The opposite state & pull down condition holds as well.  What "IS" the "real" logic state when both pull-up & pull-down resistors - are emplaced?   Does this not compromise - at least somewhat - the hysteresis margin between "high & low?"

    Our "brief" investigation revealed that, "dual-edge" detection usually - but not always - enforced restrictions upon the "idle signal level."   (thus was sub-optimal - the cost of one additional GPIO - w/each now "single-edge" triggered - completely solves this problem...)   (and enables the full recognition of "either edge" of a tri-state capable signal source)

    Our vote - two strong, secure (well known), opposite edge detectors outperform the "single pin" forced into, "double duty!"

  • Hello cb1,

    Yes, it does.

    Regards
    Amit
  • cb1, am I to understand you not only wanted to detected, L -> H and H->L but Z->L and Z->H?

    Robert
  • Robert,

    I've no such want - only sought to cover such eventuality.

    It would be interesting to know "how" the MCU "manages" a GPIO tasked w/interrupting on both signal edges.

    We've done this in the past via switching between input & output - then (gently) driving - and noting results. I do not believe this MCU - placed (only) into "dual-edge" mode - can reliably make such identifications...

    We (may) have to deal with what "is" is - yet I believe that a Hi-Z to high (or low) IS a valid edge - and hard to (reliably) detect by "both edge" gpio setting...

  • I don't believe Z to L,H can be reliably detected on any micro input even with two pins. Z to L or Z to H would only require an appropriate pull-up or down but to detect both would require additional hardware and two inputs I think. After all you are looking at detecting four possible transitions, arguably six.

    Robert
  • Here - one simple minded scenario:

    Z to L: one input is "pulled-up" - will "see" this L signal arrival

    Z to H: second input is "pulled down" - will see this H signal arrival

    Now "diode steering" may aid this 2 pin implementation.   Again one common input signal (H-L-or Z) fed to each "single edge detect" GPIO pin.  (i.e. the objective is to "prevent" the unwanted "circuit combination" of (both) pull-up & pull-down resistors - creating an unstable or far too narrow signal "idle")  

    I do recall my firm's achieving this input recognition (via 2 pins) and client's repeated failure (via one pin, dual-edge detect.)   (detect not - in this case)

  • I think that diode steering would either prevent signals from propagating at all or not isolated the Z case sufficiently. Consider just the pullup case.

    The diode must block the high voltage from bleeding into the Z, but that also prevents an applied low from pulling it down. I believe something more sophisticated is called for. It could be done with a bias network and a couple of comparators. That would be quite inexpensive.

    Robert
  • Hi,

    I am sorry for being late in my reply as I am super saturated these days on my tasks.
    I thank you all for your always useful comments just a last question, in your personal opinion, I have good number of pins available that can be configured as rising edge and falling edge interrupt, my question, which method would you prefer to adopt i.e. two seprrate pins tight together and one serving Intrrupt routine on rising other serving on falling edge OR should be one single pin configured as rising and falling edge ?
  • Given you have plenty of pins there is no question. Use two pins. You have the luxury of experimenting with both methods to see what works best/most easily.

    Robert
  • As the "first" here to recommend two "tied" pins - by all means - use that method just as you've outlined.   You may wish to pull-down the pin which interrupts on a rising (edge) and pull-up on that which interrups on one falling.  

    You may repay the attention here by configuring your 2 pins in that manner - and then reporting what each pin (when read) reports.   I suspect there will be "interaction between the pull-up/pull-down" - we past chose (considered/clever) external resistor values - so that (some) hysteresis remained - and that oscillation was avoided.   (such may (now) prove the biggest challenge you face...)

    Dawns that we (may) have "sequentially enabled the MCUs (not yours) internal pull-up and pull-down resistors - IN and OUT" - such that only ONE such pull-up OR pull-down was ever enabled!     (thus solving the pull-up/down expected (and unwanted) interaction.)   This - done at a high enough frequency - will "catch" either a rising or falling edge - albeit with some, slight delay.   (and surely - Good for Gov't Work!)

    What appeared (on the surface) as "easy" - appears, "Not so much!"  (at least to poster's Robert et cb1...)

  • Hi Cb1,

    Thank you for your reply.
  • Hi Sahil,

    Thank you - plz re-read - I've tweaked (added some (hopefully) useful, added facts for your consideration...)    (we did this many moons ago...)

    And "merci beaucoup" for your (Green) highlight/reward.  

  • cb1- said:
    Dawns that we (may) have "sequentially enabled the MCUs (not yours) internal pull-up and pull-down resistors - IN and OUT" - such that only ONE such pull-up OR pull-down was ever enabled!   

    That would work. Do not ever put a pull-up and pull-down on the same digital input line. The consequences range from the destructive to the merely indeterminate.

    Robert

    Personally I would never trust internal pull-ups/pull-downs to this task.  Too fragile, too exposed and generally too variable.

  • Robert Adsett said:
    I would never trust internal pull-ups/pull-downs to this task.

    Yet - the ability to "selectively enable" first one - and then its (opposite) - proves critical in satisfying poster's "interrupt on both edge, need."

    Of course - if GPIOs are (still) in excess/abundance - one can employ (another) GPIO to switch a single, external R between "pull-up" or "pull-down."  

  • Only needed in the presence of floating inputs and a need to detect a transition from float to both high and low independently. Not a stated requirement of the OP.

    In such an event I'd even more want to isolate the micro from the floating input.

    Robert