Can anybody please explain the concepts of interrupts and polling in realation to real time programming, also listing the advantages and disadvantages.

 

That is a pair of subjscts that do not lend themselves to a brief explanation. Here is a reference to get you started - http://en.wikipedia.org/wiki/Real-time_computing.

 

thanks, I will study the link carefully

 

You might want to look up RTOS or realtime operating systems.

What is your application? Polling usually uses up more cpu resources since it means you are actively monitoring an input (in software whereas an interrupt happens in harware). The response time to this input is based on how often you are checking it.

 

Interrupts can be implemented in software, typically as interrupt service routines (ISRs) where low-level processor instructions switch the context to the ISR code fragment. The ISR is responsible for dealing with the source of the interrupt.

Interrupts are probably a better mechanism for real-time systems because the processor is not wasting valuable processor time and resources polling a status variable. In real-time systems you want your processor resources to be focused towards system tasks. The important aspect of interrupts in real time systems is defining priorities. Think of the following example: if a real-time system is executing a particular task and another part of the system generates an interrupt, the system must ascertain which task has priority - imagine your aircraft not prioritising between the autopilot and the cabin toilet flush mechanism!

Dave

 

In fact there are other mechanisms that are used, which would be more suited to real-time systems. That is using a dedicated processor module to deal with the interrupt source.

Most sources of interrupts (or components that are likely to be polled) are external devices (peripherals in the computing world). When one of these devices requires attention it informs the central processor by means of either an interrupt or when the processor polling deduces that this is indeed the case. The processor then sets up and delegates the task to a dedicated management console. The central processor is then able to continue with its normal execution.

When the dedicated console has completed, it instructs the central processor which then has the task of prioritising the tasks importance at that point in the system execution. This technique is very common in systems where an interrupt from a system component is for a task that takes quite a lot of time - for example, large data transfer. This may or may not be something characteristic of a real-time system.

Dave

 

How does a processor KNOW that an interrupt has occured ? ( as in , a person pressed a key on the keyboard or whatever) .. Doesn't it have to keep checking a status register or variable ? (polling ?)

 

How does a processor KNOW that an interrupt has occured ? ( as in , a person pressed a key on the keyboard or whatever) .. Doesn't it have to keep checking a status register or variable ? (polling ?)

No the interrupt occurs asynchronously. Therefore, the interrupting device asynchronously interrupts the processor execution causing the processor to perform a context switch to save its current state and switches to an interrupt service routine (a software routine designed to deal with the interrupt). If you are thinking of this in terms of hardware/software ISRs are referred to by their general name of interrupt handlers.

Dave