887 won't exit interrupt

[hantto]

Hello!

I'm experimenting with interrupts now. I got it to enter the interrupt, but it won't exit it! What seems to be the problem?

;		===============================
;			  Interrupt
;		===============================

		org	0x0004			;Interrupt Vector

Iterrupt	movwf	w_temp			;Save W register
		swapf	status,	w		;Swap status to be saved into W
		movwf	s_temp			;Save STATUS register
		movfw	PCLATH
		movwf	p_temp			;Save PCLATH 

		call	LCD_Clr
		call	LCD_Line1

		movlw	'J'
		call	LCD_Char
		movlw	'e'
		call	LCD_Char
		movlw	'a'
		call	LCD_Char
		movlw	'h'
		call	LCD_Char
		call	Delay255


Int_Exit	movfw	p_temp
		movwf	PCLATH			;Restore PCLATH
		swapf	s_temp,	w	
		movwf	STATUS			;Restore STATUS register - restores bank
		swapf	w_temp, f
		swapf	w_temp, w		;Restore W register
		retfie

;		== Interrupt End ==

Thank you! All help is warmly welcome!

 

[bonxer]

You never clear the flag of the interrupt you are servicing, so it's continually being serviced. Also, I'm sure your 0x0000 reset vector is set to jump over the ISR to the start of your code, but wouldn't hurt to ask just in case.

 

[hantto]

Oh, totally forgot that. Thank you

Yes, I jump over to the beginning of the code at 0x0000.

 

[Nigel Goodwin]

I would also mention that you're not checking for what caused the interrupt. as long as there's only one possibility it probably doesn't really matter - but it's as well to check.

Another observation is what you're doing inside the interrupt, generally an interrupt should be as short a time as possible - using LCD routines inside one is going to make it an extremely long time.

The usual idea behind an interrupt is that it's transparent to the normal running of the program - this wouldn't be any where near that.

 

[hantto]

Well, it doesn't matter much in my application. And how would I implement a menu if not by interrupts from the B-port? My program is doing quite alot (well, measuring which takes about 0,3s among other things), so I would have to press a key for a long time before anything would happen.

But tank you, the info is useful

I have an additional question: Is it possible to never return from a interrupt? What I mean is that after the interrupt I wouldn't use the REFIE but just jump to a certain part of the code?

 

[Nigel Goodwin]

Well, it doesn't matter much in my application. And how would I implement a menu if not by interrupts from the B-port? My program is doing quite alot (well, measuring which takes about 0,3s among other things), so I would have to press a key for a long time before anything would happen.

You simply poll for a switch press periodically during the 0.3s routine, no problem.

But tank you, the info is useful

I have an additional question: Is it possible to never return from a interrupt? What I mean is that after the interrupt I wouldn't use the REFIE but just jump to a certain part of the code?

It would certainly be a totally disasterous thing to attempt, and is almost certain to result in your program not working correctly - the first obvious problem is stack overflow.

I'm presuming this is related to your menu system?, the idea has only occured to you because you're using interrupts in an unusual way.

 

[hantto]

You simply poll for a switch press periodically during the 0.3s routine, no problem.

You mean to periodically test for a button under the routine itself? Like write a subroutine to test it and call it between the main codelines?

I'm presuming this is related to your menu system?, the idea has only occured to you because you're using interrupts in an unusual way.

 

[Nigel Goodwin]

You simply poll for a switch press periodically during the 0.3s routine, no problem.

You mean to periodically test for a button under the routine itself? Like write a subroutine to test it and call it between the main codelines?

Yes, assuming you have a simple delay loop for the 0.3s (it probably won't be that simple, but the principle is the same), it can't consist of a single loop - not to give that length delay.

So it must consist of nested loops, say a 3mS loop called 100 times.

All you do is add a call to poll for the switch press in the outer loop - so in this example, the switch would be checked every 3mS instead of every 300mS.

As I said, your example probably isn't that simple, but anything that takes 300mS on a PIC is spending a LOT of time just wasting time.