Exact match. Not showing close matches.
'[PIC]:portB external interrupts'
|warning/apology: this post is longer than most I see on the piclist
I'm using the "interrupt on change" feature of RB4:7 on a 16F876
to control the direction of a hydraulic cylinder. A valve is
controlled based on prox sensors at the top and bottom of the
cylinder travel. The prox sensors are inputs to RB4 & 5;
RB6 & 7 are pulled up and reserved for ICSP use. RB0-3 are
unrelated inputs that only need to be read at boot. The very
simple logic used in the isr is: if the bottom prox sensor
is high, drive the cylinder up; if the top prox sensor is
high, drive the cylinder down. It works 99% of the time,
but occassionally stalls, which I have traced to missing the
interrupt (I also seem to see spurious extra interrupts, which
I am curious about, but they don't stall the cylinder).
I read the following on Andrew Warren's answer page:
"The PIC16C6X datasheet says that under certain conditions,
Change-On-PortB interrupts may be missed. Is this true?
Yes. If the change occurs just as PORTB is being read, the interrupt
flag won't be set and no interrupt will be generated. What many people
don't realize is that every instruction that accesses PORTB will read it.
The upshot of all this is that you can't really depend on the
Change-On-PortB interrupt to be reliable for anything other than
waking-up the processor from sleep mode.
Sucks, don't it?"
I assumed that if I did absolutely nothing else on portB I would
be ok. Was this an incorrect assumption?
RB0-3 are never looked at after interrupts are enabled. The
only time I look at portB at all is in the isr to see if RB4 or 5 is
high. We've made two changes trying to deal with this problem:
(1) .022 uf caps from RB4 & 5 to ground to clean up noise - still
(2) before enabling interrupts, change the rest of portB to outputs -
jury is still out.
Is the interrupt on change feature just not reliable enough to use in this
application, or is it more likely that I have a noise issue, or ???
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
More... (looser matching)
- Last day of these posts
- In 2000
, 2001 only
- New search...