16F676 Interupt on Change pin determination

[BGreen]

Sorry arch, I edited it to simplify it and may have messed that up. Let me check it and I'll post again.

[BGreen]

I fixed it and it still does the same thing. In addition, it seems that if I even get close to it sometimes it goes off. Is there a pin I should ground or have I really screwed something up?

[Archilochus]

I tossed the code into MicroCode Studio to get a better look - think I see the problem...

	IF NEWPORTA.5 <> OLDPORTA.5 THEN
ILOOP:
		I = I + 1
		IF I = 5 THEN
			resume BASE
		ENDIF
		LOW LED : PAUSE 1000 : HIGH LED
		PAUSE 1000
		GOTO ILOOP
	ENDIF

	IF NEWPORTA.4 <> OLDPORTA.4 THEN
		I = I + 1
		IF I = 4 THEN
			resume BASE
		ENDIF
		LOW LED : PAUSE 1000 : HIGH LED
		PAUSE 1000
		GOTO ILOOP  ; <<<<<<<<<< JUMPS BACK TO Iloop
	ENDIF

No matter which pin is interrupted, the code jumps back to "Iloop", which is in the middle of the "IF NEWPORTA.5 <> OLDPORTA.5 THEN" test. It loops there until done, blinking the LED as if A.5 were interrupted, no matter which pin actually caused it.

Arch

PS - on the erratic triggering, make sure your programmer is actually setting MCLR off, and check for 'floating' inputs.
What value pullup/pulldowns are you using?

[BGreen]

I wasn't using anything but internals on this Arch. I'll check out what you posted and give it a whirl. Thanks for the help. I think my brain began to die after I passed 50.

[Archilochus]

Had a few extra minutes and rewrote the code - I think it should work - I don't have any 16F676's to try it on.
(yer way ahead of me... my brain died off around 5 or so)...

@ DEVICE PIC16F676,INTRC_OSC_NOCLKOUT,WDT_ON,PWRT_OFF,BOD_OFF,PROTECT_OFF,CPD_OFF,MCLR_OFF
	LED var PORTA.0
	BlinkCount var byte
	CounterA var byte
	OLDPORTA VAR byte
	NEWPORTA VAR byte
; DISABLE ANALOG INPUT, COMPARATOR ON PORTA, A/D reference...
	ANSEL = 0 : CMCON = 7 : VRCON = 0
	TRISA = %00111110	; PortA In/Out states
	WPUA = %00000110
	INTCON = %10000000 : IOCA = %00111000 : OPTION_REG = %00001000
	LED = 0 : PAUSE 1000 : LED = 1
	GOTO BASE
;
; SUBROUTINES
MYINT:
	NEWPORTA = PORTA	; read current PortA state
	INTCON = %10000000
;
	IF NEWPORTA.5 <> OLDPORTA.5 THEN
		BlinkCount = 3	; Set up for 4 blinks
	ENDIF
;
	IF NEWPORTA.4 <> OLDPORTA.4 THEN
		BlinkCount = 2	; Set up for 3 blinks
	ENDIF
;
	IF NEWPORTA.3 <> OLDPORTA.3 THEN
		BlinkCount = 1	; Set up for 2 blinks
	ENDIF
;
	for CounterA = 0 to BlinkCount
		LED = 0 : PAUSE 1000 : LED = 1 : PAUSE 1000
	next CounterA
	RESUME Base
; The above section could have an error trap in case none of the IF's are true for some reason.
; A "Select Case" might use less code space.
;
; Start main program loop here
;
BASE:
	BlinkCount=0 : OLDPORTA = PORTA
;
ON INTERRUPT GOTO MYINT
	INTCON = %10001000
;
LOOP:
	SLEEP 240 : GOTO LOOP
	end

Arch

[BGreen]

Arch, once again I'd like to thank you. That was it. At one time programing was one of my strong points, but it seems I get lost pretty easy these days. Thanks for helping me out again.

[Darrel Taylor]

Well, that definately looks better, and it may work better for now, but it still needs a couple things.

The Interrupt "Handler" should be enclosed within DISABLE/ENABLE statements to keep the Interrupt Handler itself from being interrupted again.

The clearing of the Flag should be done in the handler, not the point that execution resumes. If you RESUME without clearing the flag first, you can end up right back in the Handler again.

And, "resume BASE" should only be "RESUME".
When specifying a location to RESUME to, it essentially does a GOSUB to that routine when the Handler is finished. However, in this program, the PIC is told to go to Sleep, without ever returning from that GOSUB. So on each interrupt, it pushes another address on the stack, which overflows after 8 interrupts. For a 16F, the Stack will wrap around to the beginning again without causing a reset, so you may never see the problem right now, but if there are any other subroutines involved, they will never get a chance to RETURN, or will return to the wrong place.

Because of the "Spaghetti" nature of this program, these problems may not be evident because it just falls back into the program and continues on, but when you start adding things later, you will lose a large portion of whatever hair you may have left trying to figure it out.
<br>

[BGreen]

Thank you Darrel. I appriciate the help.