How timer interrupt work

Status
Not open for further replies.

Djsarkar

Member
Hi
I do not understand how different tasks will be executed on each interrupt

For example, interrupt occur at every 5ms

When Frist interrupt occur, do the first task

When second interrupt occut, do the second task

When third interrupt occur, do the third task

Repeat whole process

Here is my idea how first interrupt occur and finish his work in ISR but I don't understand how and when second and third task will execute?

 
It's up to you what you do with the interrupts, you need to program the ISR to do as you wish. Bearing in mind that ISR should preferably be kept as short and fast as possible, and avoid calling subroutines if you can.

A fairly common solution is to use 'flags', so the first time the interrupt gets called set flag1, the next time set flag2, etc.

The main loop then polls the flags and responds accordingly, resetting the flags in each relevant routine.
 
You are assuming that multi threading is done via interrupts. This is true for small micros (pretend multi threading) but not realy true threading. On micros you just use interrupts to manage many tasks.

Mike.
 
[QUOTE="Nigel Goodwin, post: 1383993, member: 10131"
A fairly common solution is to use 'flags', so the first time the interrupt gets called set flag1, the next time set flag2, etc.
I did not understand how the first flag set in the first call and how the second flag is set on the second call.

When interrupt occur main function will call to ISR routine

Int main ()
{
....
}
ISR
{


}
 
Simply increment a counter, when it equals ONE then set flag1, when it equals TWO then flag2 etc. When it gets past the highest value rest the counter to ONE.

However, I'm with Pommie in that it sounds like you're probably trying to do something in the wrong way?.
 
Sounds like you have 3 tasks you want to do. You want to do one of the interrupt tasks every 5mS.
Nigel said 'flags'. I would have used the word "task counter".
First think in the interrupt code:
If Task_Counter=2 then Task_Counter=0 and go to task code 2,
If Task_Counter=1 go to task cose 1
task code 0 (because we know TC=0)
 

I suggested 'flags' so as to keep the ISR short and fast, and run most of the program in the main code - rather than running everything from within the ISR.
 
However, I'm with Pommie in that it sounds like you're probably trying to do something in the wrong way?.
This question is related to interrupt. threading will be very advanced topic for me. I don't know about it. I do not have clear understanding on the interrupt right now, so I would not like to go to the advanced topic.
 
This question is related to interrupt. threading will be very advanced topic for me. I don't know about it. I do not have clear understanding on the interrupt right now, so I would not like to go to the advanced topic.

So why are you asking about running different sections of code sequentially via timer interrupts?, it's a fairly unusual application for micro-controllers.

Here's a little snippet of ISR code from one of my routines, it's run every 1mS via a timer interrupt (which also generates a running millisecond counter). You simple set the variable 'Count_Down' to the delay you require (it's a unsigned int, so maximum 16 bit - just over 1 minute), and set the COUNTDOWN_FLAG to 'true'. The ISR routine simply resets the flag when it times out - so the main program just has to check that flag in a loop, while it's doing other things.

It was originally written for use with a GSM modem, where you send a command - then set the countdown, and wait until you get the required answer back, or the countdown times out so you know it's failed.

C:
if (COUNTDOWN_FLAG)         // if it equals true
{
    if (Count_Down>0)
    {
        Count_Down--;
        if (Count_Down<1)
         {
             COUNTDOWN_FLAG=false;
         }
    }
}
 
When I was reading the timer interrupt, the question came up, why do you need timer interrupt?

I am looking reason why should we use timer interrupts in project

Suppose we can bake a bread in a microwave oven for five minutes. If you bake bread more than five minutes, it will start burn.

Is it useful to use timer interrupt in this requirement?
 
You seem to be looking at this the wrong way round. The question should be is using an interrupt a good way to solve the problem you are trying to solve. A microcontroller used in a microwave oven has other things to do as well as just keep track of time. It also has to display time and other information which probably means updating digits on a multiplexed display at regular intervals (Probably a few hundred times per second) It also needs to monitor the keypad to see if a button has been pressed. Using timer interrupts make doing these thing easier. A timer interrupt could increment counters to keep track of time and also step to the next digit position for a multiplexed display. The main program loop could be comparing the seconds and minute counters with the set cooking time. This is a link to a tachometer design as an example.
https://lesjhobbies.weebly.com/simple-tachometer-for-1-to-99-pulses-per-rev.html
This uses two timers that interrupt. One is keeping track of time from the system clock and the other is counting input pulses from a rotation sensor. The system clock timer interrupt is also used for display multiplexing. If you click on "source an hex files" you will get a .zip file which contains the source file (.asm extension)
If you look at the interrupt section of the code it should make things clearer to you.

Les.
 
Last edited:
Most microprocessor / MCU based devices doing anything other than very trivial tasks need to do several things "at the same time" and the simplest way of achieving that is often a regular interrupt.

Among other things, that can be used to update a software real-time clock, count down timers used in the general program, poll I/O devices to see if they have data ready or are available to send data from a buffer, update inputs and outputs, set status bits for the main loop program to act on, do software PWM, look for changes to inputs that may signal an event etc.

The list is just about endless - just don't do anything in an interrupt that may "hang" or take excess time; if anything needs a delay, leave it and check again next interrupt.

Putting (or triggering) all the time-critical stuff in interrupt routines means the main program can do whatever is needed for the intended device function, update displays, indicators etc. without causing delays to the critical parts; once you get the hand of that principle, it makes the overall programs far simpler.

The speed of interrupts depends on the device requirements; I've used anything from 100Hz to over 100KHz in different designs, with 1KHz and 10KHz (or 9600Hz) probably being the commonest.
 

It's useful because you can easily create an RTC (Real Time Clock) using timer interrupts - if you use a 32KHz crystal (often an option on TMR1) you can generate an interrupt every second, you then count those, and every 60 seconds increment the minute counter and zero the seconds, then do the same for hours, days, months etc.

For the 5 minute oven timer you just set a countdown clock - just like my code above - except you're counting down in seconds and minutes, not milliseconds.

If you're not using a 32Khz crystal, then it's often difficult (if not impossible) to get a direct one second interrupt - the section of my code above runs at 64MHz, and the ISR is driven by one millisecond interrupts from a timer - it does at least three things - one it keeps a running count of milliseconds in a large variable, two it runs the countdown code above, three it increments another millisecond counter that it resets every thousand counts (so only an unsigned int) and creates a one second clock, which in turn creates a one minute clock etc. for an RTC.

Because there's a 'one second' section in the ISR, that's a good place to put an alarm test - so your RTC could be compared to an alarm time and date, and trigger an action when it happens (by setting a flag that's tested for in the main code).
 
Status
Not open for further replies.
Cookies are required to use this site. You must accept them to continue using the site. Learn more…