I still do not have a good understanding for Interrupt I have theoretical question on interrupt eg. generate first interrupt for 15 ms and print "orange" inside in ISR routine . when first interrupt over generate second interrupt for 20 ms and print "mango" inside ISR routine

I am showing how the first interrupt will work, through the pseudo code, But for the second interrupt, where mango should to be write in code ?

   #include<microcontroller.h>
 
   int main ()
   {
      intilize_system();
     
      while ()
      {
      }
      return 0;
   }
    Interrupt()
    {
      printf("orange \n");
    }
   }

 

I still do not have a good understanding for Interrupt

In digital computers, an interrupt is an input signal to the processor indicating an event that needs immediate attention.
An interrupt signal alerts the processor and serves as a request for the processor to interrupt the currently executing code, so that the event can be processed in a timely manner.
Max.

 

In the more modern products with R/W IE bits and IF bits you can trigger an interrupt directly from software without a hardware based IF bit setting trigger. Setup a ISR vector of a module not being used, enable the interrupt, set the flag, the ISR will execute. It's also very common to trigger interrupt driven serial I/O by setting the TX interrupt flag with a timed software trigger or program logic after a transmit buffer is loaded.

 

That is ok for simple testing.

In actual computer system you never will do that. You want to spend the shortest possible time in the ISR (Interrupt Service Routine). Why? Because there could be many different events happening and each one could be interrupting at any time.

Here is a real life example:

1) phone rings
2) doorbell rings
3) microwave times out
4) kettle is boiling
5) baby starts to cry
6) your favorite show on TV is just about to begin

 

Never is too strong a word. I wouldn't do it with a single priority, single signal level interrupt system but even the fairly low end controllers have sufficient interrupt capabilities to have at least dual interrupt levels with preemption. Never do it if you don't understand all the implications of doing it.

 

That is ok for simple testing.

When first interrupt happen for 15 ms. print message "orange"
When second interrupt happen for 20 ms. print message "mango"

My pseudo code shows process only for first interrupt Where to write code for second interrupt ?

   #include<microcontroller.h>

   int main ()
   {
      intilize_system();
   
      while ()
      {
      }
      return 0;
   }
    Interrupt()
    {
      printf("orange \n");
    }
   }

 

An interrupt can serve as a "pacing/timing" mechanism. For example, say you are sending something at the relatively slow rate of 9600 baud, you can use an interrupt to do something else while waiting for the next bit to send.

 

Simply write another function with a different name.

    Interrupt1()
    {
      printf("orange \n");
    }
   }

    Interrupt2()
    {
      printf("mango \n");
    }
   }

How you tie those two routines into the interrupt system to run when interrupts happen is totally device dependant. Usually the programming language will provide libraries to manage the details.

 

In actual computer system you never will do that. You want to spend the shortest possible time in the ISR (Interrupt Service Routine). Why? Because there could be many different events happening and each one could be interrupting at any time.

We should do the polling method for the longest time and use interrupt for the shortest time. generally there are many devices like LED, LCD, Relay.. take time between 30ms to 60ms.

What should be the shortest time according to you ? 5ms, 10ms, 20ms, under 50ms.

 

When first interrupt happen for 15 ms. print message "orange"
When second interrupt happen for 20 ms. print message "mango"

What do you mean by "happen for 15ms"?
Interrupts are not meant to last for X ms.

There are two types of interrupting signals:
1) edge triggered interrupts
2) level sensitive interrupts

Here are two examples:

1) I set my alarm for 6:30 am. When that time is reached, the alarm is activated once and stays on until I hit the alarm OFF button.
This is an edge triggered event. It happens once. It does not "happen for 15 ms".

2) The carbon monoxide detector goes off indicating CO level above an established threshold. The alarm is activated. It stays activated until the CO level falls below the established threshold. This is a level sensitive interrupt. Computer systems must be programmed to deal with level sensitive interrupts in an appropriate manner. Since interrupts are pre-emptive, i.e. it takes over control of the processor, the system has to engineer a way to allow other processes to resume even while the event generating the fault signal is till present.

 

We should do the polling method for the longest time and use interrupt for the shortest time. generally there are many devices like LED, LCD, Relay.. take time between 30ms to 60ms.

What should be the shortest time according to you ? 5ms, 10ms, 20ms, under 50ms.

Usually, in the systems that I program, ISR will occupy no more than 10μs.

 

Usually, in the systems that I program, ISR will occupy no more than 10μs.

I wonder what you were doing in such a short time. It is very difficult to control a device in such a short time. Perhaps you were monitoring an electronic device

 

I wonder what you were doing in such a short time. It is very difficult to control a device in such a short time. Perhaps you were monitoring an electronic device

Usually when you service a external and/or hardware driven interrupt as an event you want the event capture (set a flag, trigger another task) as fast a possible so the system is ready for another event capture. Interrupts can to do more than capture events, they can also be processing interrupts (usually from an internal trigger) to execute less time critical code controlling a device in a narrow timing window that might be milliseconds long without the main program waiting and/or checking for a software flag for the correct time to execute, and, if the system has more than one level of interrupt and priorities, not interfere with the event interrupts that need microsecond response times. If designed correctly from the start this partitioning of event, processing and main simplifies systems by providing isolation and interface driven structure between software modules.

Here we see the debug traces of two interrupts on a PIC Q43 controller. The top line is a process interrupt low priority ISR (low to high trace means processing starts) that processes ADC data from a 10 data point buffer into voltage, current, power and energy floating point numbers precisely every second for battery coulomb counting. This takes about 10ms of processor time every second. The bottom trace is the ADC conversion complete event high priority interrupt ISR that toggles a debug pin. The actual ADC processing time per interrupt is at most a few microseconds. You should notice there is no change in the speed of the high priority interrupt while the low priority interrupt is running.

 

I wonder what you were doing in such a short time. It is very difficult to control a device in such a short time. Perhaps you were monitoring an electronic device

Interrupts have been used in computers of all sizes for over half a century for all manner of peripheral devices. It is an article of faith that interrupt routines must be a short as possible. To write a long protracted interrupt routine is to guarantee an unreliable, erratic, and faulty system that will drop data and malfunction in major ways. Even on machines with instruction cycles in excess of several microseconds we could write the routines we needed in several tens of microseconds.

What exactly do you mean to imply by "monitoring an electronic device". Is that your idea of throwing shade?

 

Interrupts have been used in computers of all sizes for over half a century for all manner of peripheral devices. It is an article of faith that interrupt routines must be a short as possible. To write a long protracted interrupt routine is to guarantee an unreliable, erratic, and faulty system that will drop data and malfunction in major ways. Even on machines with instruction cycles in excess of several microseconds we could write the routines we needed in several tens of microseconds.

What exactly do you mean to imply by "monitoring an electronic device". Is that your idea of throwing shade?

IMO it's only a guarantee of a unreliable, erratic, and faulty system if you don't know what the hell you are doing.

 

I wonder what you were doing in such a short time. It is very difficult to control a device in such a short time. Perhaps you were monitoring an electronic device

I believe that you do not understand how interrupts work. You still have not explained what you mean by "happen for 15ms".

Suppose I have a web camera and I want to capture video at 40 frames per second. The camera sends an interrupt when a frame is captured. This happens every 25ms. The processor does not sit and poll the camera for 25ms.

Here is how interrupts are supposed to work.

Every 25ms the camera sends an interrupt. The ISR recognizes and acknowledges the interrupt. This takes less than 10μs.
The processor now has to retrieve the frame in under 25ms. This is not done in the ISR. This is done in the main loop by the task scheduler.

Meanwhile the ADC is interrupting at a rate of 44.1kHz, i.e. every 22.67μs. The processor takes one ADC reading and stores it an a buffer. This also takes less than 10μs.

Both sound and video are captured with no loss of data.

(This is only an example but in reality there are more efficient ways of doing this. While all of this is happening, the processor could be doing motion detection, face recognition, spectral analysis, etc, and still not miss any events.)

 

IMO it's only a guarantee of a unreliable, erratic, and faulty system if you don't know what the hell you are doing.

LOL -- did you know what you were doing the first time you wrote one?

 

LOL -- did you know what you were doing the first time you wrote one?

Yes, as I actually studied computer science, computer architecture and OS design 40+ years ago before writing OS and device driver software for minicomputers. At the time my listed major for VA benefits was electrical engineering and I had little interest in programming but after a few hardware focused architecture classes I switch the major to computer science so the VA would pay for those classes.

 

I believe that you do not understand how interrupts work. You still have not explained what you mean by "happen for 15ms".

I assume that I am working on the system that performs 102 tasks. This entire system has 100 normal tasks and 2 very important tasks

suppose main routine complete 100 tasks and we have two interrupt routine tasks

Task 101 : Whenever panic button press, alert buzzer should ring
Task 102 : check temperature of system at every 1 ms if it is greater then specified range. stop system

main ()
{
  while (1)
  {
   Task1();
   Task2();
 
   Task100();
   }
}

interrupt1  // hardware interrupt
{
   if (panic button pressed)
    {
       ring buzzer;
    }

}

interrupt1  // timer interrupt for every 1ms
{
        if (temprater >44)
    {
       stop system;
    }

}

You can see that while loop is busy to complete 100 tasks. but whenever panic button will press processor will stop whatever is doing in while loop and it will execute whatever written in hardware interrupt routine. Same when timer interrupt generate, processor will stop what it is doing in main routine for 1ms

I just wants to know what happens if hardware interrupt and timer interrupt are activated simultaneously

 

Timer interrupt every 1ms is not the same as processor busy for 1ms.

Timer interrupt at any interval is serviced for less than 10μs.
Processor is now able to respond to any other interrupt.

If both interrupts happen at the same time, first interrupt is processed. Second interrupt is processed within the next 10μs.
The key is: Don't spend more than 10μs in any ISR.