• State TI Thinks Resolved
  • Locked Locked
  • Replies 3 replies
  • Answers 1 answer
  • Subscribers 30 subscribers
  • Views 298 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.

Compiler/TM4C1294NCPDT: Interruption response time

user5169723
Prodigy 90 points
Part Number: TM4C1294NCPDT

Tool/software: TI C/C++ Compiler

The interruption response time from the network refers to the time that the computer receives the interrupt signal to the operating system and completes the switch to the interrupt service program. That is to say, it does not include the time to carry out the interruption.
Now I want to detect this response time, what to do and read the handbook is not clear. Hurry up!!!

  • 0
    TI__Guru**** 158915 points

    Hi,

     You didn't mention who is generating the interrupt and what frequency you are operating the device at. If you want to get some idea on the response time you can use a GIO input to generate an interrupt and once you are in the ISR immediately set another pin. On the scope you measure the difference between the two pin edges. 

      Using a GPIO input to generate interrupt as an example, when a rise edge is detected it must be first latched (that is one cycle) and then go through a edge detection logic (this is one more cycle). A edge is detection logic is normally a flop followed by a AND gate with a bubble on one of the input terminal.  The interrupt request is then sent to the CPU. The CPU will take about 12 cycles to save the context on the stack or 6 cycles with tail chaining. Refer to the ARM Cortex-M process TRM for detail.  

    user5169723 said:
    Hurry up!!!

      Can you elaborate this comment? 

       

  • 0 in reply to Charles Tsai
    Guru 117850 points

    Hi Charles,

    Bravo - so GOOD that you "high-lighted" poster's improper, "Command."    (Hurry Up!)

    We cannot know if such was "by intent" or simply poster's, "language limitation" - yet in either case - "requests" always are judged more favorably than "commands."    ("Hurry up" as used here - proves both unkind,  unwarranted - and normally will inspire DELAY - not quickness!)

  • 0 in reply to cb1_mobile
    Guru 13040 points
    Absolutely agree!!!
    Reading such an order makes every nerve in me react on a negative manner, and conspire to reply only a year from now!
    Also, I wonder what "network" is the original post referring to? And what "computer"?