DT Ints not working on 16F18426

[richard]

Bit the bullet and fished out an old 16f18875 from curiosity hpc board,
code works fine. seems proteus fails to emulate that chip properly
looks very much like the switch release triggers another interrupt that is not easily serviceable

[amgen]

One important thing I learned from my EET courses years ago ..... circuits have 2 responses to a change in voltage/current. There is an initial response that relates mostly to inductance and capacitance and previous state of circuit, then there is the 'steady state response' that comes after the circuit settles to constant state (micro/milli seconds later). That is not exactly referring to switch/contact bounce, but the interrupt could be triggered/cleared many times from contact bounce unless there is some kind of circuit that debounces the mechanical switch. One kind of test could be done is have the interrupt count/display how many times it gets triggered from a switch press.

[richard]

do simulated switches bounce in a simulated circuit simulation?
do androids dream of electric sheep ?
so many unknowns

[amgen]

do simulated switches bounce in a simulated circuit simulation?

I would suppose that there are good simulations and faulty simulations

[tumbleweed]

looks very much like the switch release triggers another interrupt that is not easily serviceable

That's one of the reasons why it's usually better NOT to use interrupts to handle things like button presses and just poll it.
In your main loop you can still use the IOC IF flag to check and see if you need to look for a key press, but there you can add debounce delays, etc... things that don't really belong in an ISR.

Polling for it in the main loop also gets around the problems created by getting interrupted in the middle of things, stuff like I2C, displays, serial ports, etc. that can't really get interrupted if they're used in both main and the ISR.

[Ioannis]

Tottaly agree with that.

I got in a rabbit hole trying to make a keyboard matrix work in an ISR along with debounce etc. Just a waste of time...

A tight loop is just fine. And as tumbleweed noted, use Interrupt just to note MCU that a key was pressed, maybe wake it up from sleep. Then a loop will do the rest.

Even if other interrupts are needed when keyborad is serviced, ISR will do that just fine.

Ioannis

[mpgmike]

Darrel Taylor's Instant Interrupts (DT_INTs) changed things for the PBP world. PBP Interrupts are Polled, not actually using the built-in Interrupt hardware. Using ASM somewhat defeated the reason to buy PBP in the first place. Earlier PICs stayed with standardized naming conventions, Bank selection, and Bank location of SFRs. Newer PICs gave new names to familiar peripherals; like changing TMR2 to T2TMR for example. The newer PICxxQyy PICs even changed the default Bank from BANK0 to BANK4. No wonder DT_INTs no longer worked.

A small group of us dove into the ASM behind the scenes for the DT_INTs and uncovered the working mechanisms. By changing naming, BANK locations of SFRs, and a few other things, we were able to get the incredible DT_INTs working on newer offerings. The good news is that a collaborative effort spells out what these changes entail, and how you can do it too. This body of work is available in The Book of DT's Interrupts.