Interrupt mystery - need some guru help

[xnihilo]

Remind me not to fly on one of your planes.

When people get thrown extra duty because they didn't know something and the boss refused to help.
It's likely they won't bother asking questions the next time they have problems.

Who know's what goes un-fixed.

Fine, I'll do it.

xnihilo,

i VAR BYTE

i = PORTA            ' Clear mismatch condition
INTCON = %00001000   ' enable porta interrupts on change and clear flag

ON INTERRUPT GOTO in_sig    ' int routine

Remove the other INTCON statement.

It looks like I could finaly prevent interrupts occuring without no reason.
I still have to thoroughly test the program.
I would like to know what's the need for GIE.
In your code above, you don't enable GIE at all, I followed your instructions and it worked.
I thought that in order for Interrupts for PORTA change (or any interrupts) to be enabled, GIE bit had to be set. I could not find clear information neither in pbp manual nor in the pic datasheet.

I have more strange things happening though, in my program just after the int routine label if I add an LCD output with the value of variable "a" bits (with a loop of 6 iterations and LCDOUT #a.0(i)) after an "a=porta" to get port pins values and clear mismatch), the value displayed doesn't change no matter what pin triggered the int (even if the right pin is detected), and ever more strange, after the interrupt routine is finished and before going back to the infinite loop, the value of portA bits is displayed once again, with no reason...
Subtleties...

Anyway, thanks a lot for your help, hope it solved the problem. It is still not crystal clear for me how to use stuff related to interrupts, I'm using the instructions more or less empiricaly and I'm not sure about the order in which I write the program sections.

If you have some time to waste, maybe you could have a look at my program and let me know if you see very horrible things
http://users.edpnet.be/charlesetchri...g/se230308.pbp

Best regards

[Darrel Taylor]

When using ON INTERRUPT, the GIE bit is controlled by PBP.
Any attempts to change it manually will cause problems.

And the IOC port change interrupt, doesn't save the state of the PINs for you. If you're just getting a quick pulse, it's possible that the pulse is gone by the time you try to display the pins, or determine who shot you with what.

The very first statement in the interrupt handler should read PORTA and save the value in a variable. Then use that variable throughout your handler, instead of the pins themselves.

The IOC interrupt also triggers on any pins transition from low to high, or high to low.
But your program is only looking for HIGH states. If it makes it all the way through the handler before the pulse goes away, then you will get another interrupt at the end of the input pulse. This time it'll look like all the pins are at their default state, as if nothing changed. You'll need to account for the second interrupt, somehow.

You're also clearing the interrupt flag in 2 places in the handler, one at the beginning, and another at the end of the handler. The first one attempts to clear the flag, before PORTA has been read. But it won't clear the flag, because the mismatch condition still exists.
Read PORTA first, then clear the flag.

At the end of the handler, it clears the flag, but doesn't read PORTA.
With things like LCDOUT's in the handler, it can take quite a while to complete the handler, and the PINs may have changed in the mean time, so it would be necessary to read PORTA again before clearing the flag.

hth,

[xnihilo]

When using ON INTERRUPT, the GIE bit is controlled by PBP.
Any attempts to change it manually will cause problems.

I didn't understand that when I read PBP manual section dedicated to INTERRUPTS.

And the IOC port change interrupt, doesn't save the state of the PINs for you. If you're just getting a quick pulse, it's possible that the pulse is gone by the time you try to display the pins, or determine who shot you with what.

The very first statement in the interrupt handler should read PORTA and save the value in a variable. Then use that variable throughout your handler, instead of the pins themselves.

I understand but then I need to poll the pin that triggered the int because I'm reading a PWM signal on a Infrared Sensor (that pulls the pin LOW) that looks like:
a header (1200us ON, 600us OFF, 1200us ON, 600us OFF), then 8 times (8bits) either 600us ON or OFF followed by 600us OFF spacers, then a 600us OFF (trailer).

By the way, is the following indexed byte variable bit accessing "variable.0(indexvariable)" correct? Everyone on the forum does not seem to agree.

a VAR BYTE
...
a = porta
for i = 0 to 5
LCDOUT #a.0(i)
next i

The IOC interrupt also triggers on any pins transition from low to high, or high to low.
But your program is only looking for HIGH states.

In fact, pins are HIGH because of the WPU, I'm looking for HIGH->LOW transitions.
Am I wrong about the use of WPU?

By the way, something strange in PIC16f684 datasheet: to enable individual WPU, OPTION_REG bit 7 has to be "0"... Strange, isn't it? Shouldn't the bit be set instead of cleared?

If it makes it all the way through the handler before the pulse goes away, then you will get another interrupt at the end of the input pulse. This time it'll look like all the pins are at their default state, as if nothing changed. You'll need to account for the second interrupt, somehow.

In my routine, there is a block that will scan the input on the triggering pin for the duration of the expected signal (about 14.4ms) so the interrupts will not be re-enabled until the 14.4ms duration has elapsed. Efter that, yes, another interrupt may occur if some signal arrives on a pin and the int handler will check if the signal has the right structure, duration and if the data carried is valid. I hope my algorythm was fine.

You're also clearing the interrupt flag in 2 places in the handler, one at the beginning, and another at the end of the handler. The first one attempts to clear the flag, before PORTA has been read. But it won't clear the flag, because the mismatch condition still exists.
Read PORTA first, then clear the flag.

Right.

At the end of the handler, it clears the flag, but doesn't read PORTA.
With things like LCDOUT's in the handler, it can take quite a while to complete the handler, and the PINs may have changed in the mean time, so it would be necessary to read PORTA again before clearing the flag.

hth,

You are geat, thank you so much for your explanations.

[Darrel Taylor]

In my routine, there is a block that will scan the input on the triggering pin for the duration of the expected signal (about 14.4ms) so the interrupts will not be re-enabled until the 14.4ms duration has elapsed.

Oh, is that what it's supposed to do.
Might be a problem there. The comment also says 14400 uS, but those loops are going to take about 14.4 seconds instead.

FOR i = 0 TO 960			'total loop time: 14400 uS which is the total length of the bullet
	PAUSE 15	          	'remember that the minimum delay at 8MHz is 12 uS
	IF PORTA.0(area) == 1 THEN breakloop2 
				            'when signal goes high, exit loop and check duration before the change, you need about 600us
NEXT i

Actually, it looks like all your comments show PAUSEs in uS. But the PAUSE statement delays in milliseconds.

You probably wanted PAUSEUS.

[xnihilo]

Oh, is that what it's supposed to do.
Might be a problem there. The comment also says 14400 uS, but those loops are going to take about 14.4 seconds instead.

FOR i = 0 TO 960			'total loop time: 14400 uS which is the total length of the bullet
	PAUSE 15	          	'remember that the minimum delay at 8MHz is 12 uS
	IF PORTA.0(area) == 1 THEN breakloop2 
				            'when signal goes high, exit loop and check duration before the change, you need about 600us
NEXT i

Actually, it looks like all your comments show PAUSEs in uS. But the PAUSE statement delays in milliseconds.

You probably wanted PAUSEUS.

You are right, it is PAUSEus but for the test phase I replaced temporarily by PAUSE to be able to monitor what is going on with a 5V led.

[xnihilo]

There is a very strange thing happening.

I use RC5 without pullup and as an input at default 0V, I make it a 'listening' pin.
When a 5V pulse gets to this pin, I wait 1ms then set the pin as output and I set it high for 2ms. Then I turn it low and set is as input again to listen to any incoming pulses.

What's strange is that once the pic is powered on, an int is triggered as if porta was:
%00111111 while INTCON seems to be 0 (no int flag set).

Once the int handler has been processed once, the program behaves normaly.

So, there is obviously something that I don't grasp about setting a pin low or high and using WPU.

I should set TRISA register to determine which pin is used as input or as output.
I should use WPUA to determine what pin has its internal WPU enable. if disabled, the pin should stay LOW, shouldn't it?

If I explicitely write:

TRISA = %011111 'set RA5 as output, all other pins as inputs
OPTION_REG = %01111111 'enable individual WPU setting
WPUA = %011011 'enable WPU for all pins except RA3 and RA5
PORTA = %011111 'set all pins low except for RA5 (but WPU will bring HIGH all pins that have WPU enabled)

Like this I can expect to read porta as %011111 (31) but I get %111111 (63)...


updated code is at http://users.edpnet.be/charlesetchri...se250308-2.pbp

[mister_e]

The link to the code is broken

Probably it would be safer to clear all interrupts flags before enabling any of them. When you enable the internal pull-up, this could trigger an interrupt.

i would suggest
enable the internal pull-up
clear interrupt flags
enable interrupts.

Did you also tried with real pull-up resistors?