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.

Interrupts on Port D

Hi,

in startup_ccs.c. there is only one interrupt handler for PORT D .

 

I have registered RISING EDGE interrupt source on Port D PIN 1 , there is one interrupt handler for that.

 

Now , I want to handle interrupt on PORT D , pin 2 ( HIGH -> int source),

How can I handle that ? As there is only one interrupt handler for port D, How can I handle interrupts on various pins on port D ?

 

 

Thanks,

Sanchit Mehra 

  • Hello Sanchit,

    In the interrupt handler, when you get the Interrupt Status for which pin the interrupt was generated, you must read it to a avariable.

    Then using if-else condition where you logically AND the status returned individual interrupts can be handled. Other than that Port P and Q provide you with per pin interrupt for which you may have to re-wire your board.

    Regards
    Amit
  • While in agreement w/Amit's guidance - should those interrupts be, "external switch/keypad generated" it's far more normal/customary to employ an "active low" rather than active high. This is done for good - historic reasons - pull-up resistors at/near those port pins are most robust - and your external circuit need only (then) "pull-down" the desired pin/pins. (which frees you from "powering" switch/keypad.)

    Amit's method also enables your detection of "multiple Port D pins active" - as you are not limited to the search for a, "Single pin match" when the, "Source of the interrupt is being evaluated..." (this method potentially expands your interrupt response vectors from 8 to 255...)
  • cb1- said:
    Amit's method also enables your detection of "multiple Port D pins active" - as you are not limited to the search for a, "Single pin match" when the, "Source of the interrupt is being evaluated..." (this method potentially expands your interrupt response vectors from 8 to 255...)

     Hi CB1, please can you explain what mean this? I am not understanding what has to to with edge detect interrupt.

     On TIVA I don't know in deep features but I imagine this feature is near what is from other processor. I use this feature on MSP430 to read encoder and process high speed response from external events from TIVA I understood follow same rules, has TIVA something special and or similar to CLA of C2000 series or FreeScale 683xx?

  • If i could,

    I believe cb1 is referring to the fact that since the handler is the same for all 8 pins, you have to read the register to check which one called said interrupt. Well that is a 8bit word (32bit actually but 24 of them are garbage). So you can check all the pins at the same time right?
    You don't need to do 1 by 1 check, just extract the masked interrupt register value and check the value. 255 would mean all pins called the interrupt. 0xF0, would be pins 8, 7, 6 ,5 called the interrupt.

    With a handler for each pin, if 2 pins triggered an interrupt you would have to check 2 interrupts sequentially. Dealing also with the push-pop time between the 2 different interrupts. The method of all pins to the same handler helps also with that push-pop extra cycles that a "interrupt per pin" would have in case of multiple pin interrupts. (although the ARM-M4 is good at handling that, it's still extra cycles)

    Just my guess :P
  • Hi Luis, what about ?? If you get interrupt from 8 sources on one handler then an 8 level decision tree has to be built, so from where come this 255 vector?
    On TIVA there is the BitBANG feature splitting access of bit so this split access affectively to a 255 port accessing just combination of bits, if you access by mask then you select just one address, this result as if 255 port where active accessing subset of port mapped to sparse memory address.
    Is this also true for interrupt?
    Or there is some other special feature I don't know?

     Post edit:

     Luis see here for example about GPIO feature like input qualifiers, extended and all source that come from...

    http://www.ti.com/general/docs/lit/getliterature.tsp?genericPartNumber=tms320f28075&fileType=pdf

     I suppose TIVA has simple interrupt like MSP430 simple edge or level.

  • Indeed Luis - you explained "avec le precision." C'est tres bien.

    Roberto - we use such "whole port analysis" both w/this vendor's & w/other ARM MCUs to detect (if you will) multiple, simultaneous key presses. (i.e. consider pressing shift, or ctrl, or alt -along with another key)

    We also employ this, "whole port interrupt analysis" when scanning Touch-Screens - again to detect, "multiple touch points." In certain cases our SW will call the interrupt several times - to insure that even slight delays between multiple touches (or key presses) are correctly recognized.

    Roberto - all of the "heavy work" is done w/in the interrupt handler - there are (to our knowledge) no special features which speed or ease this capability. Have I (and Luis) answered to your satisfaction? My point was not to "hijack" poster's thread - but instead to suggest to convert an apparent limitation into an advantage...
  • Roberto Romano said:
    If you get interrupt from 8 sources on one handler then an 8 level decision tree has to be built

    Is that really (and always) the case, Roberto?  What if - w/in the interrupt handler - we "read" the port in question - as Tiva ports (mostly) are limited to 8 bits - does that not "escape" the requirement for an 8 level decision tree?  (we think so)  As stated - we may read that port (quickly/efficiently) several times to insure the correct detection of multiple (near simultaneous) keypresses.

    What you may be missing - the interrupt is the "Signaling Agent" - and our interrupt service then performs a serious of port reads - to determine the exact number of bits which have generated that signal...  And - the examination of that 8 bit port should resolve to 255 potential - vector jump locations...

  • cb1- said:
    Have I (and Luis) answered to your satisfaction? My point was not to "hijack" poster's thread - but instead to suggest to convert an apparent limitation into an advantage...

     Hi CB1, Luis, I see that an interrupt service routine that can also be deferred to execute far from interrupt as from I learnt on VAX system.

     Original post was asking about how to detect single pin interrupt so how to build interrupt service and recognize pin. In case of single pin nothing than service oìin case of multiple pin then first copy the IRQ flag then single answer can be fired sequence of simple bit test/ switch case with large table.

  • Roberto - you/I/Amit/Luis try to answer to the benefit of many - not just single poster.

    I believed that my presentation of how to (seemingly) expand the interrupt responsiveness from a single port had merit - perhaps even beyond that offered by ports equipped w/"each/every pin able to trigger a unique interrupt!"

    Just as you said - in olde dayze - you/I few others "had no choice" but to "spin our own" capability - via resourceful methods - from a too limited resource.
    My attempt here was to add that capability - which seems as important (if not far more so) than the original post's (limited) thrust...