interrupt vs polling

Hi, I ve been confused by the concepts of these 2: interrupt and polling.
, polling means the MCU keeps checking a flag to indicate if something happens.
With interrupt, MCU is free to do other things, and when "something" happens, an interrupt is generated to notify the MCU. So it means the MCU does not need to check the flag!!!!
Thats the theory. However, I remember with TMR0, when overflow occurs, an interrupt generated which makes pin T0IF in INTCON reg High. Therefore the MCU also needs to check this flag to determine if the interrupt occurs. :?
Why? :?: so what the advantages of interrupt?
Thanks

Interrupts are a little confusing to people who just have software experience. Special hardware in the controller is looking at the interrupt flag. When an interrupt occures the hardware causes a jump to the interupt routine without any software help. The CPU and the special interrupt hardware run at the same time so the CPU can be dooing something else and the special interrupt hardware is still looking at the interupt flag. When the interupt occures the interrupt hardware take control of the CPU and instead of executing the next instruction it saves where the next instruction is (so it can come back) and jumps to a special memory location in the code and the CPU then starts executing from that point. There is a special instruction to jump back to the saved memory location and resume executing from where the CPU left off.

Hope this helps
Brent

so what the advantages of interrupt

Click to expand...

1. Interrupts are used when you need the fastest response to an event. For example, you need to generate a series of pulses using a timer. The timer generates an interrupt when it overflows and within 1or2 usec, the interrupt service routine is called to generate the pulse. If polling were used, the delay would depend on how often the polling is done and could delay response to several millisecs. This is thousands times slower and the pulse generated will be jittery.

2. Interrupts are used to save power consumption. In many battery powered applications, the microcontroller is put to sleep by stopping all the clocks and reducing power consumption to a few microamps. Interrupts will awaken the controller from sleep to consume power only when needed. Applications of this are hand held devices such as TV/VCR remote controllers.

You forgot:
3). Interrupts can be a far more efficient way to code. If you need to respond to TMR0 overflow, you'd have to be putting checks for TMR0IF all over the place. In the middle of every loop. Just how often depends on how far you can let an interrupt go unanswered. If TMR0 is going to be a clock source, you might have TMR0 overflow a second time before it gets addressed and there's absolutely no way to know that happened, so you could "lose" counts off your clock periodically.

Once you've got multiple interrupt sources, you'd spend more time checking them then doing anything else.

You forgot:

Click to expand...

No I didn't forget.

It's a given that if you use polling, the polling rate should be faster than the rate the event occurs. If you cannot poll at that rate, then you have to use interrupts because you need to respond to the event in a timely way. My case #1 above applies. I seldom need to resort to interrupts if the event is slower than a millisec rate. PICs will give you enough speed to poll at that rate for most applications.

Interrupts can also be inefficient in coding. Variables, specially 16-bit ones, that are modified within an interrupt service routine cannot be accessed in the main program without checks to see if they were altered in between instructions. If extra care is not taken, it might produce bugs that will take days to track down.

I make it a practice to segregate registers that are written during ISRs so that they are accessed with care in the main program. IMO, to use interrupts just to improve coding is not good.

patricktran said:

However, I remember with TMR0, when overflow occurs, an interrupt generated which makes pin T0IF in INTCON reg High. Therefore the MCU also needs to check this flag to determine if the interrupt occurs. :?
Why?

Click to expand...

You need to check the flag when you have multiple interrupt sources (for example timer and portb change). Since all interrupts jump to the same location you'll have to test the flag to know which interrupt was triggered. It's not polling, just determining the cause of the interrupt.

If you know that only the timer would generate interrupts you don't need to check the flag anymore.

BR

:idea:
Just a tip for people who now "understand" the theory but are wondering how the hell to use int's (as most coders call em in comments).......

Refering to other comments about making sure that the int regisiters don't get mixed up with your main code register I usually use "flags".

What are flags? well imagine we all had usa style, outside, letter boxes...... at night you put the red "flag" down on the letter box sometime later (usually in the morning!) you will look out of the window and check to see if the "flag" is up..... If it is, you have mail, you go outside and get it, the postbox has been updated by the post(mail)man interrupt!......

If you are still following (awake!)..... how do this help in a pic??? Well if we want to start a timer for say 10ms we can "clear" a flag (like the mailbox) that is "cleared" in the int routine (like the mailman). This means that we can do other stuff in pic code and then check the timer "ocassionally" maybe every 100uS, OK we may loose a bit of accuracy, but we have had very little code outlay.....PLUS!!! we can have several flags all cleared by the same int routine......

OK I am gonna lie down for a bit...... If anyone needs to see some code, let me know!

BTW, this isn't the only use of int's so no flaming, please!! :wink:

Nice analogy :wink:, but I would say that is the analogy of polling instead of using the interrupt.

The interrupt analogy would be if right after the mailman deposits the mail you'll be instantly teleported to your mailbox, pick up the mail and then instantly return to what you were doing before. So you can do whatever you want and still you know you won't miss the mail. The flag in this case is not necessary.

Now suppose you have more mail boxes. Even if you are instantly teleported to them you need to know which mailbox has mail and the flags are useful for this.

BR

Motion is right. I agree with motion.

I give here a small difference (it should be noted) that as coming to an interrupts, you have to save WREG, STATUS, PCL, PCLATH, because the current ones may be overwrite. And you will lost the current values when you get back your program at where you leave to interrupts.

But with polling, you don't have to do this, because you are working with it. And you know the current values.

It's important to note that, perhaps many interrupts occur at the same time, and you have to choose which one is implemented first. Yes, it's easy but someone may forget it. And it will run interrupts again immediately after the first interrupt, after RETFIE instruction.

We should end(or begin, in somecase) the interrupt subroutine with clearing relative flag. Don't clear flags at the begin or the end of the whole interrupt service routine.

I prefer using interrupts in small applications because it makes the programs clear. But the fact that, real world applications usually work at lower speed than milliseconds. Therefore, we may use polling instead. Everything is oki, as you understand about interrupts and polling, you can use it for your own applications, patrick. Don't confuse with this stuff. Just make your program run first.

Here are two more uses of interrupts:

3. Interrupts are used for program debugging. The newer PICs (PIC16F877) have a feature called In-Circuit Debugging (ICD). It is enabled in the configuration fuses. If enabled, your program's execution can be interrupted at a preset position (breakpoint) or single stepped so that you can examine its registers, etc. Documentation can be found the ff. link.

**broken link removed**

4. Interrupts can be used for pre-emptive multi-tasking. It is possible to write a short interrupt service routine so that the PIC18 family can switch between several tasks such LCD refresh, serial ports access, keyboard scan, etc. However, it may be simpler and safer to write a round-robin scheduler in the main program loop instead of using interrupts. This may be the only alternative in the older PIC16 family.