Polling within interrupt routine

[lipschutz]

Hi

Here is my problem:
The chip is 16F88.
External Interrupt(RB0) has been implemented to turn on pin 9(RB3) and 11(RB5) then the polling of pin 13(RB7) when cleared would turn off those outputs(i.e RB3, RB5).

RB7 and RB0 are tied with Vdd with a resistor of 1k and a push button switch from pin to GND. The problem is within interrupt condition upon a low on RB7 the program turns off outputs on RB3 and RB5 as expected but a couple of seconds later those outputs goes high again.

PORTB internal pull up resistors disabled, and all unused pins are configured as outputs and connected to GND via a 3.3k resistor. The code is attached.

Thanks in advance.
Lipschutz

 

[Nigel Goodwin]

Just a couple of points (from a very brief glance).

1) Why are you using interrupts to read the keys, there's not a lot going on otherwise?.

2) Why do a call from within the ISR?, it's bad practice (and pretty pointless as it's not used elsewhere) just stick it in the ISR.

 

[lipschutz]

1) the interrupt routine turns on a motor that need to be stopped a couple of seconds later depending on RB7 input. Others activities going on outside interrupt routine are not that much time dependent, so reading keys withing interrupt doesn't sound like more of an issue to me. But I would be happy to learn a better and robust way of doing that instead.

2) the delays that were called from within interrupt are there to avoid contact bounce, should I write delays inside the interrupt routine? And why is it bad? because the stack size is pretty small? anyway I'm gonna write out the segments in the ISR.

 

[Nigel Goodwin]

1) the interrupt routine turns on a motor that need to be stopped a couple of seconds later depending on RB7 input. Others activities going on outside interrupt routine are not that much time dependent, so reading keys withing interrupt doesn't sound like more of an issue to me. But I would be happy to learn a better and robust way of doing that instead.

As there's little going on, then polling keys is often easiest.

2) the delays that were called from within interrupt are there to avoid contact bounce, should I write delays inside the interrupt routine? And why is it bad? because the stack size is pretty small? anyway I'm gonna write out the segments in the ISR.

I was specifically referring to the 'isr exit' subroutine, which seems totally bizarre - an extra stack call, and two extra words used, all for no advantage at all.

And while you might not be using much stack, getting in bad habits now will come back to bite you in the future

A better debouncing solution for ISR routines is to use hardware, a schmitt trigger and a few components - I'm currently doing exactly that using a 40106 schmitt - and I've got six interrupts currently (or is it seven?).

 

[lipschutz]

As you said I've changed the code accordingly.. But I failed to find exactly where I made the mistake. It requires two presses (RB7) to turn off the signals on RB3 and RB5 otherwise both the outputs turn on just about a second later.

As there's little going on, then polling keys is often easiest.

Do you think PORTB change interrupt could have been a better solution instead of polling?

Thanks for your advice on stack issue.

 

[Nigel Goodwin]

Do you think PORTB change interrupt could have been a better solution instead of polling?

It depends on what else you're doing, and how fast you need to respond to key presses - in my case I'm measuring the time between pulses, so it needs to be fast.

I'm also using the 16F1827, which has a much better interrupt system - allowing interrupts from individual pins on PortB, and from transitions either way (and in fact I'm using two pins connected together to detect interrupts individually from the rising and falling edges).

Just had a count, I'm using seven interrupts - three for keys, two for the input signal, and two for timers.

 

[tunedwolf]

As Nigel said, doing anything that is not absolutely critical inside your ISR is just going to come back and haunt you later