SOLVED: Post #11 - IOC on negative edge sometimes triggers twice on single press

[Demon]

catching key presses with isr's is never a good look

a simple polling debounce is way more effective ...

But isn't IOC specifically designed to handle this? The 16F18877 has IOC across all pins...?

...what is this about ?
'PinD2 CON $1A ' Datasheet table 13-2
'PinD3 CON $1B
'CCP3PPS = PinD2 ' CCP3 Peripheral input selection
'CCP4PPS = PinD3 ' CCP4 Peripheral input selection
...

It's PWM on Contrast and Backlight on LCD. I have at least 4 LCDs. That would equate to 8 pots to control contrast and backlight.

I prefer a HPW solution, that way I can control all LCDs with 1 dual encoder; 1 shaft for contrast, 1 shaft for backlight, and SPST-switch can toggle across each LCD.


I'm still digesting the code.

[Demon]

Look what I just found on p. 208:

The INLVLB register (Register 12-8) controls the input
voltage threshold for each of the available PORTB input
pins. A selection between the Schmitt Trigger CMOS or
the TTL Compatible thresholds is available. The input
threshold is important in determining the value of a read
of the PORTB register and also the level at which an
interrupt-on-change occurs, if that feature is enabled.

EDIT: Hmmm, p.212 has 1 as default on port B (ST input).

Ill try with INLVLB = %00000100, but I doubt it'll make a difference.


EDIT SOME MORE: Nope, still random double-processing.

[richard]

But isn't IOC specifically designed to handle this? The 16F18877 has IOC across all pins...?

no,
why would you ever need microsecond responses to a key press ?
how are you determining the key was held for a reasonable time and not just noise ?
how are you determining the key was released ?
how are you determining the key was in fact repressed?

isr for an emergency stop switch or a limit switch on fast moving machinery that needs protection sure , a human interface device
i don't think so.

It's PWM on Contrast and Backlight on LCD. I have at least 4 LCDs. That would equate to 8 pots to control contrast and backlight.

none of which require an i/p pin

The graphs show the signal at the switch and PIC pins; to confirm the absence of bounce on the signal.

if the sample rate of your digital oscilloscope is too low you will never see the bounces, the effective bandwidth is far to low
what you are viewing is an interpretation not reality. use the highest sample rate/resolution in single channel mode to get the best possible view

[richard]

see the white negative going spikes that indicate when samples are taken by my routine,

the spikes are 1 uS in width , on my rigol 100MHz 1Gs/S oscilloscope @ 0.5mS/div they are not accurately rendered nether are all that are in scope always even visible . saleae to the rescue at max res.
digital tools need to be understood and taken with a pinch of salt

i should point out @100uS/div all are visible but the display window is too small to see what i was looking for

[tumbleweed]

just a comment...

If you look at your code in post #1, the only thing the ISR does is set a flag that's read in your mainline code (NAV2_Swap_ON = 1).
You could drop all the interrupt stuff and just poll the IOCIF flag (or the individual flag bit) in the main loop with the same effect, much as Richard's done.

The interrupt flag bits get set even if interrupts aren't enabled.

[HenrikOlsson]

Yes!
Quite often I see comments like don't do any work in the ISR, just set a flag and do the work in the main loop.

That's totally fine if what the ISR is doing is, for example, putting UART characters into a buffer and when CR is received sets a flag. When the main loop sees that flag it processes the message.

But simply setting a flag that there's been an interrupt and then poll that flag in the main loop is...well of not much use and a waste resources. Just poll the interrupt flag (and remember to reset it) instead.

In general, the ISR should be kepts short and tight (no blocking commands like PAUSE etc (again, in general)) but if you're not actually DOING anytning in the ISR then you might not need an interrupt to begin with.

Sorry for the rant ;-)

[Demon]

...But simply setting a flag that there's been an interrupt and then poll that flag in the main loop is...well of not much use and a waste resources. Just poll the interrupt flag (and remember to reset it) instead....

It's not a rant if you guys help me. I didn't know that about the IOC flag being set regardless (I've done a lot of reading on Interrupt - remembering what I read is something else entirely).

Richard did find the real problem. I was using 0.01uF for the encoder and the switch. This is what it looked like at higher resolution:




Then I changed for 0.1uF:



Just a blip on this one:




But I have to use 0.01uF on the encoder or else they don't act properly.


So now I have to decide if I keep the 16F18877 and poll the IOC flag, or go back to the 16F1937 and poll the Port pin. I'm leaning towards the 16F1937 cause it costs a bit less.