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

Happens if hardware interrupt and timer interrupt are activated simultaneously totally depends on the hardware as interrupts are concept that can be implemented in many different ways.

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

    if (timer interrupt ) {
        if (temprater >44)
          {
             stop system;
          }
    }
}

One of the most simple is the one level, one ISR vector hardware where all interrupts are handled in one ISR. Here the hardware implementation is usually a interrupt vector bit (flag) that can be set to cause the controller hardware instruction execution sequencing hardware to execute a internal call sequence to a single address (the ISR vector). The interrupt event hardware sets a source bit flag (like button interrupt, timer interrupt, etc ...) and the interrupt vector bit (flag) causing program execution to jump to the ISR address where the ISR checks for source bit flags, clears the source bit flag(s) (panic button, timer, etc...) and interrupt vector bit flag either by a software or hardware action for each source and return at normal program execution at the end of the ISR function.

Exactly simultaneous interrupts here would only (as a simplification of the actual hardware sequence) set flags and cause one ISR execution to handle both interrupts.


Another interrupt hardware implementation would be one level, multi ISR vector hardware with a internal call sequence to a address (a ISR vector) for each interrupt source.

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

}

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

}

Exactly simultaneous interrupts here would depend on the design of the interrupt arbitration hardware that might use fixed or programmable priorities to decide what runs first on a single core processor.

Another possibility is multi level, ISR vector (single or multi vectors per level) hardware that can handle preemption of ISR individual event vector execution.

 

"Normally" you want an ISR to set a flag and exit. Reason is you want to minimize
code execution inside interrupt to insure it does not "hang" up other processes
due to time spent. If you put some code inside ISR strong recommendation you do
not use any code that calls a f() inside ISR. Reason simple, that generates a lot of
stack push/pop that does not serve you well.

Also declare variables used inside ISR that are not local as "volatile" - https://www.geeksforgeeks.org/understanding-volatile-qualifier-in-c/

Your need for ISR to handle two different actions, use a flag to control then, exit, and perform service
for that ISR.

Regards, Dana.

 

Shouldn't line 21 be "interrupt2?"

When you go to the ISR, you will need to check both interrupts, at least that is the usual way.

 

Shouldn't line 21 be "interrupt2?"

When you go to the ISR, you will need to check both interrupts, at least that is the usual way.

Yes it should. He seems to be mixing several interrupt hardware implementations in one example per my posted short list of possible implementations. That's one source of his confusion here.

 

Higher performance systems usually have vectored interrupts, i.e. a different ISR is called for each device. For example, the UART will have its own ISR and a different ISR for SPI.

It is common to have one vector for one device. Within each ISR you have to test which function of the device is initiating the interrupt, for example, TX buffer empty, RX character received, RX parity error, RX overrun error, etc.

 

Vectored Interrupt hardware has been pushed down to 8-bit controllers today.

https://microchipdeveloper.com/8bit:vectored-interrupts
http://ww1.microchip.com/downloads/en/AppNotes/90003162A.pdf

 

Yes, I meant any MCU more advance that a lowly Microchip PIC.
Vectored interrupts have been around from almost day one with MCUs.
It was the initial PIC that had no vectored interrupt and only one stack level. I know things have improved since then.

 

Yes, most of the early microcomputer chips I designed systems for (808x, Z80, 680xx, TMS9900) had basic vectored interrupt capability but needed a external chip or hardware like the Intel 8259 to actually use it. My background and experience is designing interrupt bound UNIX OS type system software so I typically design (without using a RTOS ) controller software using the same tried and true techniques on everything but the lowest single IRQ interrupt, one vector limited hardware where very short interrupt routines for everything are the norm but not always as there are interrupt bound techniques (main does nothing but idle) that are useful even here in low power, single event applications.

 

I hear you. Yes there are applications where there is nothing else to do other than sit and poll a flag. In such cases there is no need for interrupts. In the early days of computing, there were only two devices to check, the keyboard and the teletype output (TTI and TTO). The only thing the program ever did most of the time was wait for the operator to press a key. The human was the slowest link in the chain, and still is.

 

I hear you. Yes there are applications where there is nothing else to do other than sit and poll a flag. In such cases there is no need for interrupts. In the early days of computing, there were only two devices to check, the keyboard and the teletype output (TTI and TTO). The only thing the program ever did most of the time was wait for the operator to press a key. The human was the slowest link in the chain, and still is.

Instead of polling a flag continuously, using a interrupt in those circumstances saves power (interrupt wakes up device from nanoamp sleep in main) and usually improves response times at the same time when there is more than one polled flag to check. After the ISR completes it returns to main, goes to sleep until the next interrupt. Very useful for battery powered devices.

 

Instead of polling a flag continuously, using a interrupt in those circumstances saves power (interrupt wakes up device from nanoamp sleep in main) and usually improves response times at the same time when there is more than one polled flag to check. After the ISR completes it returns to main, goes to sleep until the next interrupt. Very useful for battery powered devices.

Good idea. But low power and sleep modes only came along long after the microcomputer revolution had pack up and left town.

 

Good idea. But low power and sleep modes only came along long after the microcomputer revolution had pack up and left town.

This is totally incorrect about low power.

Starting with the 8085 in the late 70's and Z80 low power was a important consideration in devices with low power modes in memory devices like the 8185 and 8080AH as they were used in some of the original mobile phones.
https://www.americanradiohistory.co...ctronics-Digest-1983-Autumn-OCR-Page-0053.pdf
https://www.jameco.com/Jameco/Products/ProdDS/52062.pdf

 

Did the Intel 8086/8088 in the IBM PC or the Motorola 68000 in the Apple Macintosh have sleep modes? I don’t recall.

 

I never worked much with the 8086 family as I hated the instruction set but the original 68000 was a mainly static core you could slow clocks down to save power but it didn't have a sleep mode, later versions like the 68SEC000 designed for embedded applications were fully static with only a few uW in static standby/sleep mode. I had an Atari-ST with the 68000, making it run faster was my only concern when I was designing MX2 for the machine.

There are two TOS (non-GEM) multitasking environments for those interested in studying operating systems: MX2 and MINIX. There is precious little information available regarding MX2 other than that it's a TOS multitasking kernel from Fred Brooks. It was written in Modula-2 and is posted with source code, updates and some auxiliary tools on national BBSs. It is intended as a project to explore systems programming on the ST, rather than a basis for commercial software development. Those interested in pursuing MX2 should try to reach Brooks through his message area in Category 3, Topic 25 of the GEnie BBS ST Roundtable.

https://www.atarimagazines.com/startv4n12/multitaskingonst.html