 |
 |
| View previous topic :: View next topic |
| Author |
Message |
kupikupi
Joined: 03 Sep 2005
Posts: 31
|
| why do we use interrupt? please help me |
 Posted: Sat Sep 03, 2005 5:04 am |
 |
|
hi guys.... im doing programming in C for my microcontroller PIC18F452
im really new to this...
i want to ask ... why do we need interrupts??? when do we use it ?? i've done some research on interrupt and from wat i understand .. interrupt is something like calling a function...it also use some timer .. wats the difference between calling a function and using an interupt ?? could anyone explain how could i use interrupt ?? do i really need to use it ?? thanx a lot..
Last edited by kupikupi on Sat Sep 03, 2005 7:22 am; edited 1 time in total |
|
 |
SherpaDoug
Joined: 07 Sep 2003
Posts: 1640
Location: Cape Cod Mass USA
|
|
| Posted: Sat Sep 03, 2005 7:06 am |
|
|
Interrupts are mostly for dealing with real world processes that take real amounts of time to execute. They are used a lot with serial ports.
Say you are controlling the temperature of an oven by monitoring a temperature sensor, switching a heater on and off and you get your setpoint temperature by a serial port to a terminal. You could 1) check the temperature, 2) adjust the heater, 3) read the new setpoint if there is one, 4) goto #1. But what happens if someone starts to type in a new setpoint and stops halfway through? If the loop stops at 3# for too long the oven will get too hot or cold.
If the serial port is connected to an interrupt the processor can alternate between checking the temperature and adjusting the heater. When a byte comes in the serial port the ISR (interrupt service routine) grabs the byte from the UART, stuffs it in a buffer, checks if there is a complete command in the buffer and if so sets a flag. Every once in a while the main program checks the complete command flag, and if it is set the command is interpreted and acted upon. The main loop can deal with the new command when it has time to, not when the command arrives.
_________________
The search for better is endless. Instead simply find very good and get the job done. |
|
|
kupikupi
Joined: 03 Sep 2005
Posts: 31
|
|
| Posted: Sat Sep 03, 2005 7:31 am |
|
|
i'm sorry but i don't really get what u meant ...
| Quote: | | The main loop can deal with the new command when it has time to, not when the command arrives. |
i was told that the interrupt occurs when the there is a task of a higher priority to execute( meaning that it immediately executes a new command)... but from what u said when a new command comes in .. it will deal with it when it has time to ... could u please explain more.. im confused,.... anyway thanx very much for the reply .. really appreciate that....
im actually using the PIC to detect a signal from a remote control to drive 2 motors of a small cart... where then does the interrupt comes into the frame??? thanx |
|
|
SherpaDoug
Joined: 07 Sep 2003
Posts: 1640
Location: Cape Cod Mass USA
|
|
| Posted: Sat Sep 03, 2005 9:08 am |
|
|
The interrupt is a high priority, but should be very short. In my example when a byte has come into the UART it must be read out before one or two more bytes come in or it will be lost. The PIC UARTs can only store a byte or two. The original UART on a PC could store 8 bytes, but it was a dedicated chip.
So reading the byte out of the UART before it is lost is a high priority. But if the ISR takes too long the low priority task (maintaining oven temperature) will fail. So the ISR should just do something simple like read the byte from the UART and push it into a buffer, and maybe see if that byte was a end-of-command character (like a <CRLF>) and set a flag is it is so. Lengthy operations like printf() or mathmatic calculations should not be done in the ISR.
To the main program loop nothing will be seen to happen except for bytes mysteriously appearing in the buffer. At some convient time in the main loop the program will test the flag and if it is set the program can then examine the contents of the buffer and execute any commands seen.
The ISR is a high priority task but it is invisible the the main program, except for the flag or other interfaces we have defined.
_________________
The search for better is endless. Instead simply find very good and get the job done. |
|
|
kupikupi
Joined: 03 Sep 2005
Posts: 31
|
|
| Posted: Sat Sep 03, 2005 10:06 am |
|
|
| hmmm... so it has to execute a quick instruction ?? that i guess will be the difference between calling a function and interrupt ?? and also interrupt only reads bytes?? so it also means that we only use interrupts when there is bound to be varied inputs ? correct em if i'm wrong .. thanx alot ... |
|
|
kupikupi
Joined: 03 Sep 2005
Posts: 31
|
|
| Posted: Sat Sep 03, 2005 10:27 am |
|
|
hmmm... so it has to execute a quick instruction ?? that i guess will be the difference between calling a function and interrupt ?? and also interrupt only reads bytes?? so it also means that we only use interrupts when there is bound to be new inputs ? correct em if i'm wrong .. thanx alot ...
| Quote: | | When a byte comes in the serial port the ISR (interrupt service routine) grabs the byte from the UART, stuffs it in a buffer, checks if there is a complete command in the buffer and if so sets a flag. Every once in a while the main program checks the complete command flag, and if it is set the command is interpreted and acted upon |
| Quote: |
so u mean that while waiting for a new command .. the program wil continue running the other 2 alternately until the new command is completed.... |
|
|
|
kupikupi
Joined: 03 Sep 2005
Posts: 31
|
|
| Posted: Sat Sep 03, 2005 10:27 am |
|
|
hmmm... so it has to execute a quick instruction ?? that i guess will be the difference between calling a function and interrupt ?? and also interrupt only reads bytes?? so it also means that we only use interrupts when there is bound to be new inputs ? correct em if i'm wrong .. thanx alot ...
| Quote: | | When a byte comes in the serial port the ISR (interrupt service routine) grabs the byte from the UART, stuffs it in a buffer, checks if there is a complete command in the buffer and if so sets a flag. Every once in a while the main program checks the complete command flag, and if it is set the command is interpreted and acted upon |
so u mean that while waiting for a new command .. the program wil continue running the other 2 alternately until the new command is completed.... |
|
|
newguy
Joined: 24 Jun 2004
Posts: 1903
|
|
| Posted: Sat Sep 03, 2005 10:29 am |
|
|
YOU are interrupt driven. Let me explain.
If you are in a crowded room, do you look back over your left shoulder, then back over your right shoulder, then left again, etc...? Or, IF a person taps you on one of your shoulders, do you turn to see who it is? What is more efficient, checking to see if someone is about to tap you, or waiting for the tap?
If you put supper in the oven, do you get down on the floor to watch it through the window, or do you set the timer on the oven to alert you when it is done? What is a better use of your time? What happens if someone rings the doorbell while you're waiting for your food to cook? Which approach will guarantee that your food will not burn?
These examples are obvious regarding which is the better approach. It's the same with interrupts vs. other means of accomplishing a task in a microcontroller: interrupts are more efficient, they allow the micro to attend to other things, and they free up time so that the micro doesn't waste time while waiting for a specific event to occur. |
|
|
kupikupi
Joined: 03 Sep 2005
Posts: 31
|
|
| Posted: Sat Sep 03, 2005 10:48 am |
|
|
| newguy wrote: | YOU are interrupt driven. Let me explain.
If you are in a crowded room, do you look back over your left shoulder, then back over your right shoulder, then left again, etc...? Or, IF a person taps you on one of your shoulders, do you turn to see who it is? What is more efficient, checking to see if someone is about to tap you, or waiting for the tap?
If you put supper in the oven, do you get down on the floor to watch it through the window, or do you set the timer on the oven to alert you when it is done? What is a better use of your time? What happens if someone rings the doorbell while you're waiting for your food to cook? Which approach will guarantee that your food will not burn?
These examples are obvious regarding which is the better approach. It's the same with interrupts vs. other means of accomplishing a task in a microcontroller: interrupts are more efficient, they allow the micro to attend to other things, and they free up time so that the micro doesn't waste time while waiting for a specific event to occur. |
hmm.. i think i got it .. so the ISR keeps checking for a complete command .. once there's a complete command .. it sets the flag..
at least i got an idea of wat it does.. but .. how do i use it..
lets say im driving motors using a remote control ... at 1st the motor moves forward when i push the forward button(so i've got a function which forwards the motor) .. and when i push the reverse button ... interrupt occurs.. and flag is set .. wat does it do next ? how does it go to the function for reversing the motor after the flag is set?? thanx for taking the trouble to reply... |
|
|
newguy
Joined: 24 Jun 2004
Posts: 1903
|
|
| Posted: Sat Sep 03, 2005 11:21 am |
|
|
| kupikupi wrote: | hmm.. i think i got it .. so the ISR keeps checking for a complete command .. once there's a complete command .. it sets the flag..
at least i got an idea of wat it does.. but .. how do i use it..
lets say im driving motors using a remote control ... at 1st the motor moves forward when i push the forward button(so i've got a function which forwards the motor) .. and when i push the reverse button ... interrupt occurs.. and flag is set .. wat does it do next ? how does it go to the function for reversing the motor after the flag is set?? thanx for taking the trouble to reply... |
I have no idea what your application does, but I'll try to guess.
I'll assume your remote has three buttons: forward, reverse and stop. These three buttons are used to control one motor.
The way I'd set up the receiver would be like this. I'd have some sort of interrupt driven command receiver. If the command comes in via an rs-232 link, then I'd use a pic with a USART, and I'd use the int_RDA (receive data available from USART) interrupt. If the command came in via an infrared link, then I'd use one of the pic's external interrupts (int_EXT) to decode it. It really doesn't matter, so long as you have some sort of interrupt driven way to get data.
This data interrupt wouldn't check the incoming message, simply load a buffer with the data and set a flag - data_available - or something similar. The main() routine would then check to see if data_available is true. If it is, then make data_available false (because we're attending to it), and THEN call a function to decode the command.
You decode the command out of the ISR because it takes time. If you do it inside an ISR, then that's time that the pic is spending doing one thing, while ignoring everything else.
So, decode the message and determine if it's one of the three you recognize (forward, reverse, stop), and take the appropriate action.
You could also easily add limits to this particular example, like if a forward or reverse limit was reached, and you'd like to turn off the motor. Wire up limit switches, and route them to other external interrupts. If those interrupts trigger, then either set a flag - stop - or, if it wouldn't take too much code, turn off the motor inside the ISR. |
|
|
kupikupi
Joined: 03 Sep 2005
Posts: 31
|
|
| Posted: Sat Sep 03, 2005 11:37 am |
|
|
| Quote: | | The main() routine would then check to see if data_available is true. If it is, then make data_available false (because we're attending to it), |
i dont get this part... could i get an example of this in C?? thanx.. thanx for all ur explanation .. im beginning to get a clear picture... but i have a few questions..
1. i need 3 functions .. to forward, reverse and stop .. so i write all 3 in the main .. where do i place the interrupts..
say this in my function
void main()
if (xxxx=01)
{
xxxxxxxxxxxxxxxxxxxx(forward)
}
if (xxxx=10)
{
xxxxxxxxxxxxxxxxxxxxx(reverse)
}
if(xxxx=00)
xxxxxxxxxxxxxxxxxxxx(stop)
}
FYI ... im really bad at programming.. im still learning .. thanx for ur patience.. really appreciate it.. |
|
|
newguy
Joined: 24 Jun 2004
Posts: 1903
|
|
| Posted: Sat Sep 03, 2005 11:43 am |
|
|
In your RDA interrupt, you'll set data_avail = TRUE. Your main routine would then look like this:
| Code: | main() {
restart_wdt(); // if you're using the watchdog, reset it here
if (data_avail) {
data_avail = FALSE; // think about it, if the ISR sets it to be true, but
// you never set it to be false, what would happen?
decode_command(); // write a function to decode the command. The
// little code snippet you just posted would do the trick
}
} |
Edit: one thing I just noticed with your code snippet will cause you problems. If you're testing to see if a variable is equal to something, use two equal signs, ==. In your code snippet, you have one, =. |
|
|
kupikupi
Joined: 03 Sep 2005
Posts: 31
|
|
| Posted: Sun Sep 04, 2005 12:56 am |
|
|
| Quote: | if (data_avail) {
data_avail = FALSE; // think about it, if the ISR sets it to be true, but
// you never set it to be false, what would happen? |
i got this part.
| Quote: | decode_command(); // write a function to decode the command. The
// little code snippet you just posted would do the trick
}
}[ |
so i could write all 4 decoding command here??
| Quote: | | Edit: one thing I just noticed with your code snippet will cause you problems. If you're testing to see if a variable is equal to something, use two equal signs, ==. In your code snippet, you have one, =. |
[/quote]
yeah .. i realized that... thanx..
so in my ISR ... do i do this?( is that all??)
| Code: | interrupt isr()
if(data_avail)
{
data avail=TRUE;
} |
could u explain the above code in words..so when there is data available.. who reads the new data and how ??
does this
| Code: | if (data_avail) {
data_avail = FALSE; |
mean there's an interrupt ?? wat does true and false do ??
which part loads the buffer??
thanx...
so when the interrupt flag is set... the main routine detects it and set it to false?? that's all ? then in executes the folowing commands?
im really bad at this.. so i think i need more detailed explanation .. sorry for the trouble.. thanx alot.. |
|
|
kupikupi
Joined: 03 Sep 2005
Posts: 31
|
|
| Posted: Sun Sep 04, 2005 1:43 am |
|
|
i kinda get how it works already .. so the ISR fills the buffer .. then once the buffer is full .. it sets the flag and the main function is acknowledged(the main function always checks if the flag is set).. then it executes subsequent commands... my question is
1. where does the ISR read bytes from ?
2. while the program is waiting for a new input .. it has to do something else rite?? in my case ( using IR remote control to control 2 motors of a small cart) while waiting for a signal .. what does it do ?? it keeps executing the previous command until a complete new command is received rite? i get the idea that im using interrupts so that the program can keep doing other things while waiting for a new command... but i think of the cart i'm controlling .. when i send a command( when i push a button) .. the program executes it .. then when i release the button ... then cart should stop. then when i push another button .. it moves again .. so the program doesnt move if i dont push any button .. do i still need an interrupt here?? ( since the cart doesnt need to do anything else if i dont send a command in .??) |
|
|
Ttelmah
Guest
|
|
| Posted: Sun Sep 04, 2005 3:07 am |
|
|
You still at one point talk about the ISR 'checking'. It doesn't.
Let's go back to the human analogy. You are working out the back of your house, and expecting visitors. The two options open to you, are:
1) Keep walking through to the hall every minute or so, and 'check' if anybody has arrived. This in computer terms, is the 'polling' solution.
2) Rig up a very loud doorbell, so that you can keep working out the back, and stop what you are doing when it rings. This is the 'interrupt' solution.
What an ISR actually 'does', is completely down to the code inside it. However what _triggers_ it (rings the bell), is down to the hardware. The PIC, contains hardware to trigger an ISR, from a number of events. A serial character arriving, the serial transmit buffer emptying, a SPI transaction completing, a AD conversion completing, and also to trigger off specific external lines being operated. The ISR, does not 'check', it only executes when the signal arrives.
The ISR solution, is used, where events occur at unpredicatable intervals, which need to have their basic handling done quickly (in the case of the serial port for instance, the incoming character must be removed from the buffer, or the potential exists for an 'oveflow' if more characters arrive), and at the same time, the 'main' code has other things it can be getting on with in the meantime.
Normally, the ISR, will then also want to 'tell' the main code that something has happened (as if the visitor at the door, is actually a 'delivery' of something to do with the work you are doing), so when you have finished signing for the delivery, you carry it back with you to the back of the house, and put it down while you finish the actual job you are working on, perhaps putting a sticky note on the edge of your desk to remind you to deal with it lattr. This is the computer 'equivalent', of putting the received character into a 'buffer', and setting a 'flag' (the 'sticky note'), that the delivery has arrived.
Best Wishes |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
