Rotary encoder with DT interrupts

[wjsmarine]

Hi All,

Just had a chance to try Mike's suggestion, terminal result below, still no good.

Power-on: 00011001  -  00011101
Priming PCON: 00011001  -  00011111

I'm Alive

RE_val 00001
RE_val 00002
RE_val 00003
RE_val 00004
RE_val 00005
RE_val 00006
RE_val 00007
RE_val 00008
RE_val 00009Power-on: 00011001  -  01011111
Priming PCON: 00011001  -  00011111

I'm Alive

RE_val 00001

@ Richard
I take your point about using an Int for the REsw but this code is only a snippet of a much larger, intensive program and the normal scan of the switch may be delayed due other processes - hence my using an Int for the pushbutton. I have not run the full code with this problem, only what has been submitted for this very reason (isolation of where the problem lies). I have tried with and without the REsw bit, still no difference with the bug.

@ Ioannis
The test pcb I've been using all along (and a breadboard to confirm) runs very well when I switch to the 16F886, supply is from a well regulated 9v bench unit which then gets regulated on board to either 5v or 3v3 as needed. The RE and all peripheral components are hard soldered on the pcb.

AFAIK I'm running the latest version of DTInts having found that out the hard way a number of weeks ago, identified by Richard (thanks again mate).

Maybe it is time to give up on this and go with your preferred way of using a RE Richard... but I'd like to solve the mystery if possible else have that nagging doubt using 16F1788 chips with Ints.

Cheers,
Bill

[richard]

your not trying to run chip at less than 5v ? decouple caps etc [i'm using none]
reset is pulled high ?
enc and sw pins are pulled high with suitable r

i cannot get mine to fail no matter hard i try , no caps, pwr off pk4 , dupont leads on a breadboard [you can't get worse conditions]
even using wpu is ok

i will go out on a limb and say
code cause 0%, isr cause 0% . other 100%

also when breadboarding all unused pins set as i/p is a good thing

[wjsmarine]

No, 5v all the way unless the app calls for 3v3 (typically when I use a Nokia GLCD). In any case the PIC should be able to handle 3v3 at low speeds, surely?

The pcb has bunches of decoupling caps, selectable 10k pullups (as used on the RE) and .1 caps to ground also to minimize and bounce at the source.

Reset is pulled high via a 10k series diode combination for the ICSP requirements.

I make unused pins output so don't need to worry about pullups as you would with inputs (else floating nightmares). I guess your wpu's take care of your inputs.

Worse case I'll develop with the F886 (yet to try the F1938, hopefully tomorrow - I think you have one or two of these IIRC).

What's next wise one?

Regards,
Grasshopper

[richard]

no, 5v all the way unless the app calls for 3v3 (typically when I use a Nokia GLCD). In any case the PIC should be able to handle 3v3 at low speeds, surely?

not sure , for the 16f1788 the microchip ipe with pk4 warns , 5.00 v recommended (not sure where the ldo comes into play)

I make unused pins output so don't need to worry about pullups as you would with inputs (else floating nightmares). I guess your wpu's take care of your inputs.

as i don't , i have never seen or heard of a pic having an adverse effect from an unused floating input. if your program is affected by an unused input then its incomplete.
the only measurable effect is a slight increase in power consumption (you need a microamp meter to detect it). floating pin nightmares for pic chips are a myth based on other logic families with fixed i/p pin to o/p pin relationships where totem-pole outputs could be driven at prodigious rates unnecessarily to bad effect, pics are not like that.
when breadboarding all unused pins set as i/p is a good thing, you won't damage anything with misplaced connections.

[picster]

I just use regular polling instead of interrupts when using a pb rotary, and only increment/decrement the "true status" upon TWO successive state changes in the SAME "direction". This eliminates debouncing and does not require interrupt use and it's infallible.

Picster