Interrupts

[-Dan-]

Hi,

I'm trying to understand interrupts.

What is the difference between an interrupt and just a gosub statement

below is an example i found on the melabs website.

what action triggers the interupt.




' On Interrupt - Interrupts in BASIC
' Turn LED on. Interrupt on PORTB.0 (INTE) turns LED off.
' Program waits .5 seconds and turns LED back on.

led var PORTB.7


OPTION_REG = $7f ' Enable PORTB pullups

On Interrupt Goto myint ' Define interrupt handler
INTCON = $90 ' Enable INTE interrupt

loop: High led ' Turn LED on
Goto loop ' Do it forever


' Interrupt handler
Disable ' No interrupts past this point
myint: Low led ' If we get here, turn LED off
Pause 500 ' Wait .5 seconds
INTCON.1 = 0 ' Clear interrupt flag
Resume ' Return to main program
Enable

[Jerson]

Imagine you sitting at your desktop PC. Imagine you checking your inbox every now and then. It would involve you logging into your account, checking, etc. This is how you would do it if you gosub. Now, imagine for a moment, you have installed a widget like Yahoo messenger which tells you when you have received an email. This is similar to an interrupt. It lets you attend to your business without having to keep repeatedly checking your inbox.

Interrupts are triggered by events(in the case above, receipt of mail).

In the example you cited, the interrupt is triggered by the RB0 pin of the controller.

Once you understand On interrupt goto, look up Darrel Taylor's wonderful Instant Interrupts. I'm not good at linking threads, so please search it. It is much more powerful than the PBP ON INTERRUPT statement

[-Dan-]

Imagine you sitting at your desktop PC. Imagine you checking your inbox every now and then. It would involve you logging into your account, checking, etc. This is how you would do it if you gosub. Now, imagine for a moment, you have installed a widget like Yahoo messenger which tells you when you have received an email. This is similar to an interrupt. It lets you attend to your business without having to keep repeatedly checking your inbox.

Interrupts are triggered by events(in the case above, receipt of mail).

In the example you cited, the interrupt is triggered by the RB0 pin of the controller.

Once you understand On interrupt goto, look up Darrel Taylor's wonderful Instant Interrupts. I'm not good at linking threads, so please search it. It is much more powerful than the PBP ON INTERRUPT statement

Thanks for your reply


Wouldn't the microcontroller have to constantly keep looking for the event to trigger the interupt?

and which part of that code tells you the interrupt is triggered by RB0

Thanks

Dan

[jmgelba]

Using Darrels Instant Interupts, whats the fastest theoretical responce to an interupt using an 18F at 8MHz?
I have several applications lined up that need less than 50uS responce times.

[Archangel]

Thanks for your reply


Wouldn't the microcontroller have to constantly keep looking for the event to trigger the interupt?

and which part of that code tells you the interrupt is triggered by RB0

Thanks

Dan

Hi Dan,
Real interrupts are like your alarm clock in the morning, You might like to ignore but it doesn't take no for an answer, Real interrupts will INTERRUPT whatever the pic is doing and perform the code specified, and no the other code doesn't have to keep checking. THAT SAID, PBP does not have REAL interrupts. ON INTERRUPT sets a flag on the stack and continues the command that was executing and then jumps to the interrupt routine. If you want real interrupts you must either use assembler or Darrel's Instant Interrupt routine.
<br> INTCON and OPTION_REG are used to control the interrupts and whether they occur on rising or falling edge.

[-Dan-]

Hi Dan,
Real interrupts are like your alarm clock in the morning, You might like to ignore but it doesn't take no for an answer, Real interrupts will INTERRUPT whatever the pic is doing and perform the code specified, and no the other code doesn't have to keep checking. THAT SAID, PBP does not have REAL interrupts. ON INTERRUPT sets a flag on the stack and continues the command that was executing and then jumps to the interrupt routine. If you want real interrupts you must either use assembler or Darrel's Instant Interrupt routine.
<br> INTCON and OPTION_REG are used to control the interrupts and whether they occur on rising or falling edge.

Hi Joe,

thanks i get the general idea now, but how does the pic know that the event which should trigger the interupt has happened if it isn't looking for it.

in the little code example i posted it says:

On Interrupt Goto myint ' Define interrupt handler



i understand that it would jump to an interrupt handler call myint but there are no parameters specified as to when it should jump to the interrupt handler, this is what i'm finding confusing.

[Jerson]

The PIC knows that an interrupt has occurred when

1. the event is triggered by hardware and sets a flag inside the PIC silicon
2. If you have the interrupts enabled and have a service routine for it, the moment the event occurs, the interrupt service routine (ISR) will service it and return back to what it was doing at that point in time.
3. The RB0 pin is also called INTE pin and is the one that triggers the event in your code.
4. This is the line that enables the INTE and GIE bits in the interrupt register telling the PIC whether to handle the interrupt in code when it happens

INTCON = $90 ' Enable INTE interrupt

[-Dan-]

The PIC knows that an interrupt has occurred when

1. the event is triggered by hardware and sets a flag inside the PIC silicon
2. If you have the interrupts enabled and have a service routine for it, the moment the event occurs, the interrupt service routine (ISR) will service it and return back to what it was doing at that point in time.
3. The RB0 pin is also called INTE pin and is the one that triggers the event in your code.
4. This is the line that enables the INTE and GIE bits in the interrupt register telling the PIC whether to handle the interrupt in code when it happens

INTCON = $90 ' Enable INTE interrupt

Ohhh i see its triggered by hardware not software

Thank you Jerson for helping me understand

[rswain]

Interrupts are something like, if you touch a hot stove, the sensor in your hand detects "something's wrong". That signal goes to a specific location in the brain and causes a muscle action to happen. You don't think about it - it just happens. No matter what you WERE doing before, your hand is going to yank back NOW! You'll then go back to what you were doing before you touched the hot stove.

More technically speaking, when a hardware interrupt is enabled, and one occurs, the hardware gates in the PIC direct the program pointer to a specific location in memory where the interrupt subroutine's address is stored. The program pointer gets the address of the interrupt service routine and then goes there to handle the interrupt. Once the interrupt handling routine (that you wrote) is done, then the program goes back to where it was based on what it was doing at the time of the interrupt.

Example: You were blinking an LED on Port A.0. All is well. In your program you configured the Port B.0 pin for interrupt on low-to-high transition and enable the Port B.0 interrupt. Then you pushed a button that connects 5v to Port B.0. The blink portion of the program is stopped, and the chip's internal program pointer goes to the interrupt location in memory and looks for the address of your interrupt handler, and goes there. Once it gets to the end of that routine, then action resumes in the main program (blinking the A.0 LED) where it left off before the interrupt occured.

You can do this via two methods - PBP or DT INTS. It really depends on how fast you want to handle the interrupt and how much you want to "do it the right way", I guess. In other languages and chips, I've always used hardware interrupts and prefer to handle them as fast as possible and with as little impact on the running program as possible. Often times the interrupt is something that's just plain boring or bothersome like an input character from a USART, a counter rolling over, a timer rollover, odometer tic, etc. Nothing you really want to redirect the main program over, but something that still needs to be addressed and then move on back to what you were doing before. Interrupts using DT INTS is the fastest way, and probably (technically) the right way to handle PIC interrupts while using PBP as your language. I strongly suggest learning more about interrupts at the hardware level (RTFM) before you attempt DT INTS. While Dave's documentation is good, it assumes you know what/how/why interrupt in the first place. Not a good place for a newbie to go off exploring without some guidance.

Hope this helped,
rswain

[Archangel]

OK lets beat this subject into shim stock . . . INTERRUPTS are TRIGGERED by hardware events, They are handled by software. Assembly will start working on the interrupt within 2 to 4 cycles of the Oscillater. PBP On Interrupt, puts a pointer on the stack, like it does with a subroutine, and executes it right after it finishes what it is doing.
Consider this:

start:
on interrupt goto Emergency<font color=red><b>_</b></font color>stop  ':D thanks mister_e
main:
PortB.3 = 1 ' motor runs for 1 minute, stops for 1 minute
pause 60000
PortB.1 = 0
Pause 60000
goto main
Emergency_Stop:
PortB.3 = 0
sleep
end

In the example above ASM interrupts will shut the motor off right now, PBP might have you wait 59 seconds

[mister_e]

and in the example above, there's an underscore missing

[carlos22]

Big thanks to you all
-Dan-
Jerson
jmgelba
Joe S. --- Oh those funny days N. Khouroutchouv and others
rswain
mister_e
-------------------
Greetings from Algeria.

[carlos22]

Question:

Did anyone manage to get a working PicBasic pro + Microstudio + wine under Debian GNU/linux_lenny.

Thanks in advance.