DT Ints not working on 16F18426

[tumbleweed]

Glad it's working. If you run across anything funny let us know.

There are a few bytes of ram reserved by DT_INTS for things that aren't needed, so they could be gotten rid of too but it's not hurting anything.

I'll add a few other new chips in also in the hope they become supported at some stage

As long as the chip is supported by mpasmx 5.87 then you've got a shot at it. That's basically any device that has an existing file in the DEVICES folder,
with the exception of the 18FxxQ84. That one is listed as supported by mpasmx but it doesn't work (that's an mpasmx fault, not pbp).

Anything past that and I don't think you'll see it get added... mpasmx is at the end of its life unless it's extended like the Swordfish folks have done for the 18F series.

I wouldn't trust proteus simulations to get it right, especially with these new chips.

[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