Searching \ for 'RB Port Change Interrupt on the '84' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/ints.htm?key=interrupt
Search entire site for: 'RB Port Change Interrupt on the '84'.

Truncated match.
PICList Thread
'RB Port Change Interrupt on the '84'
1996\06\11@110119 by myke predko

flavicon
face
Hi Gang,

I seem to remember somewhere that there was a problem with the RB Port
Change interrupt on the 16C84.  Does anybody know more about it?

Thanx,

Myke
Myke

"We're Starfleet officers, weird is part of the job."

Capt. Catherine Janeway

1996\06\11@141257 by John Payson

flavicon
face
> I seem to remember somewhere that there was a problem with the RB Port
> Change interrupt on the 16C84.  Does anybody know more about it?

In a nutshell, any instruction which does a write to any port will also do
a preceding read.  For most ports, this is not an issue since reading them
has little effect other than moving a few extra electrons around.  Reading
port B, however, will cause the compare latches to be read and clear any
pending interrupt-on-change condition.

Thus, the problems are these: [1] When doing a write to the port, the int-
on-change feature may be cleared; if the write happens just as the port
changes, the interrupt may never get flagged. [2] If a read happens just as
the port changes, the interrupt may never get flagged.

1996\06\11@214247 by Onat Ahmet

flavicon
face
>>>
> I seem to remember somewhere that there was a problem with the RB Port
> Change interrupt on the 16C84.  Does anybody know more about it?


Thus, the problems are these: [1] When doing a write to the port, the int-
on-change feature may be cleared; if the write happens just as the port
changes, the interrupt may never get flagged. [2] If a read happens just as
the port changes, the interrupt may never get flagged.
<<<

So, is there a workaround for this problem? Such as checking
for the interrupt flag before reading or writing to RB port?

Thanks;

| Ahmet ONAT  Kyoto Univ. Japan                                 |
| E-mail    : spam_OUTonatTakeThisOuTspamkuee.kyoto-u.ac.jp                           |
| WWW page  : http://turbine.kuee.kyoto-u.ac.jp/staff/onat.html |
|             My 6 leg walker, RC airplanes & more in home page |

1996\06\11@235537 by Martin J. Maney

flavicon
face
On Wed, 12 Jun 1996, Onat Ahmet wrote:

> So, is there a workaround for this problem? Such as checking
> for the interrupt flag before reading or writing to RB port?

There's the work-around described in the datasheet (this has been in
there for at least some of the 16Cxx parts for a while):

 "The interrupt on change feature is recommended for wake-up on key
  depression operation and operations where PORTB is used only for the
  interrupt on change feature.  Polling of PORTB is not recommended
  while using the interrupt on change feature."

I also recall that Microchip said, some time ago, that future revisions
would fix this feature, but I don't recall just how future that was to be.
I think it may be fixed in the A-suffix versions of the 16C7x chips, etc.

1996\06\12@003138 by Neil Gandler
flavicon
face
On Tue, 11 Jun 1996, Martin J. Maney wrote:

> On Wed, 12 Jun 1996, Onat Ahmet wrote:
>
> > So, is there a workaround for this problem? Such as checking
> > for the interrupt flag before reading or writing to RB port?
>
> There's the work-around described in the datasheet (this has been in
> there for at least some of the 16Cxx parts for a while):
>
>   "The interrupt on change feature is recommended for wake-up on key
>    depression operation and operations where PORTB is used only for the
>    interrupt on change feature.  Polling of PORTB is not recommended
>    while using the interrupt on change feature."
>

So are you saying that if someone was to use a pin on port B with
the interrupt on change, that the rest of the ports pins shouldnt be
used for any other application?
I don't quite understadn what you meant.

               Neil Gandler

1996\06\12@004640 by John Payson

flavicon
face
>> Thus, the problems are these: [1] When doing a write to the port, the int-
>> on-change feature may be cleared; if the write happens just as the port
>> changes, the interrupt may never get flagged. [2] If a read happens just as
>> the port changes, the interrupt may never get flagged.
>
> So, is there a workaround for this problem? Such as checking
> for the interrupt flag before reading or writing to RB port?

For non-critical applications, checking the interrupt flag before or after
reading/writing the port will work most of the time, as will simply checking
when reading the port to see if it (the value read back) has changed.  This
will not work 100%, however, since the port value might change just as the
port is being read, resulting in the 'read' getting the old port state and
the latches getting the new state.

If this feature is being used in, e.g., a push-button remote control where
a failed interrupt detect will result in another button being pushed (which
WOULD then get detected) this is not a major problem; most consumers won't
notice if their controller misses a button push every 10,000 closures.  In
applications where a missed change-detect could result in a frozen system
(e.g. port B senses a relay closure which will remain until the system clears
it) other methods of sensing input changes should be used.

1996\06\12@012956 by John Payson

flavicon
face
>  So are you saying that if someone was to use a pin on port B with
> the interrupt on change, that the rest of the ports pins shouldnt be
> used for any other application?
> I don't quite understadn what you meant.

That's pretty much what it means, I'm afraid.  Basically there is one real
use for the interrupt-on-change feature that actually works fairly well:
using a PORTB trigger to wake from sleep.  While this will not be 100%
reliable in cases where the trigger condition may be "pre-existing", it is
good enough to be used for things like remote controls and items like that.

Further, even in a remote-control context it may be possible to make the
port B trigger reliable: if one can ensure that all the inputs WILL be in
an inactive state before the last time portB is read before sleep, then
any time they become active will cause an interrupt.  For example, assume
a keyboard is wired 4x4 using PB0-PB3 as output and PB4-PB7 as input.  The
following will cause the CPU to go to sleep but re-awaken if and when any
button is pushed [assuming pullups on PB0-PB3]:

       bsf     RP0     ; Bank 1
       movlw   $FF
       movwf   PORTB   ; Set TRISB to all inputs
       bcf     RP0     ; Bank 0
       clrf    PORTB   ; Prepares PORTB to ground outputs 0-3, but doesn't
                       ; do it YET [because of TRIS].
       bsf     RP0
       movlw   $F0
       movwf   PORTB   ; Set 4 LSB's to low outputs.  NOTE: This instruction
                       ; does NOT access PORTB and so cannot clear the PORTB
                       ; latches!
       bcf     RP0     ; Back to bank 0
       ...
       sleep           ; Frere Jacques... dormez-vous?

1996\06\12@023129 by Martin J. Maney

flavicon
face
On Wed, 12 Jun 1996, Neil Gandler wrote:

> On Tue, 11 Jun 1996, Martin J. Maney wrote:
> > There's the work-around described in the datasheet (this has been in
> > there for at least some of the 16Cxx parts for a while):
> >
> >   "The interrupt on change feature is recommended for wake-up on key
> >    depression operation and operations where PORTB is used only for the
> >    interrupt on change feature.  Polling of PORTB is not recommended
> >    while using the interrupt on change feature."
> >
>
>  So are you saying that if someone was to use a pin on port B with
> the interrupt on change, that the rest of the ports pins shouldnt be
> used for any other application?
> I don't quite understadn what you meant.

No, you've got it, near enough.  As John has explained (and given a nice
example of its intended use), this really isn't of much use as a general
interrupt source as you might expect in a general purpose machine.

About all I can think of to add is the observation that even if you can
afford to "waste" the rest of PORTB this probably can't be made entirely
reliable for more general use.  The catch is that you HAVE to read the
port in order to clear the interrupt that has occured, and that read can
cause another interrupt to be missed.  Not very often, perhaps, but if
you can't afford to miss the change...  (and, I tend to think, if you
could afford to miss an occasional change, forget about the interrupt on
change and just poll it from time to time and detect the changes
yourself - as many pins, on whatever ports as you need.)

1996\06\12@031140 by Prashant Bhandary

flavicon
picon face
I kinda anticipated these problems and what I intend to do in
one of my apps is use one of the PortB pins to read a bitstream
and interrupt on change. The Port B Change ISR sets the other
output pins on this port. The RTCC is set to interrupt on
wraparound. In case there is no change on Port B for a few RTCC
wraparounds I write to the port.

The bitstream is dynamic enough so that the PortB outputs don't
get delayed significantly. In case the bitstream is idle, the
RTCC interrupt will update the port after a few idle RTCC wraparounds.
This will mean I lose any port B changes that occur at that time
but any bits after a long idle period will have enough preceding sync
bits before sending anything important.

Anybody see any flaws in this scheme?

For those who followed the Model RR/DCC thread, the Port B input
reads the DCC signal. Port A does the PWM H bridge driving. The
other Port B pins are function outputs that control things like
lights, etc. which can tolerate some latency. On a 10 MHz 16C84,
the RTCC cycles every ~100us. This is used as the PWM base and
for timing the bitstream.

Regards

Prashant
+----------------+  -------------------------------------------------
|                |    Prashant Bhandary
|   +---+        |    Spatial Information Systems Section
|   |   |        |    Roads and Traffic Authority
|   |   |        |    Rosebery NSW 2018, AUSTRALIA
|   |   |        |    Tel:  +61-2-662 5299
|   |   +----+   |    Fax:  +61-2-662 5348
|   |        |   |    Email: .....prashbKILLspamspam@spam@rta.nsw.gov.au
|   +--------+   |
| Still a newbie |    "2b|!2b" - William Shakespeare
+----------------+  -------------------------------------------------

1996\06\12@112458 by myke predko

flavicon
face
All yesterday afternoon and evening, my ISP was down, so I couldn't see all
the messages/suggestions, so I did the next best thing; I tried it empirically.

The reason for asking this is my version of the Electronics Now Runabout
Robot (March '96).  In my original code, I used RB0 and looked at each edge
(going up or down).  I wanted to try the bit change interrupt for two
reasons; The first was to allow two I/R receivers (essentially getting 360
degree coverage) without having to AND the outputs together before
intputting into the PIC.  The second reason was that my original code
required changing the interrupt edge and I thought that using the bit change
interrupt would eliminate this requirement.

So, I created some code to do try this out.  The hardware was simply the two
I/R receivers along with two LEDs to indicate when the Interrupt Handler was
entered and which of the I/R receiver was active (basically just copying the
port back to the LEDs in the interrupt handler).

The first problem I found was with the LED's on PORTB.  Initialization and
writing to them seemed to screw up how the bit change interrupt wasworking.
Moving the LEDs to PORTA seemed to clear this up without any problems.

In my final application, I require four output bits to control the two
motors, these can be used from PORTA without any problems (and maybe an
additional bit for indicating when an instruction is being received) and not
use PORTB for anything else.

Now, I'm curious to know if I can use other PORTB bits for Input.  ie will a
"movf PORTB, w" instruction to poll other bits cause a problem with port
change bits?

Thanx,

Myke
{Quote hidden}

Myke

"We're Starfleet officers, weird is part of the job."

Capt. Catherine Janeway

1996\06\12@130122 by Neil Gandler

flavicon
face
On Wed, 12 Jun 1996, Martin J. Maney wrote:

{Quote hidden}

____

I just want to make sure I got this. If I have one input on PORT B
lets say PB7, with 3 leds on PB0-PB2. And I can't spare port B since
I am using the PIC16C61. If I use the interrupt on change feature and
I change the state of one of the LEDs that would trigger the state
change interrupt? Also an idea to prevent the ocassionaly miss of a
switch. Just make sure the keys are well debounced with a small delay.
The interrupt routine lasts perhaps for less than 1ms ( unless your
code is huge), I don't know how many people can repeatedly press
a button every millisecond.

       Neil Gandler

1996\06\12@191605 by John Payson

flavicon
face
> I just want to make sure I got this. If I have one input on PORT B
> lets say PB7, with 3 leds on PB0-PB2. And I can't spare port B since
> I am using the PIC16C61. If I use the interrupt on change feature and
> I change the state of one of the LEDs that would trigger the state
> change interrupt? Also an idea to prevent the ocassionaly miss of a
> switch. Just make sure the keys are well debounced with a small delay.
> The interrupt routine lasts perhaps for less than 1ms ( unless your
> code is huge), I don't know how many people can repeatedly press
> a button every millisecond.

Actually, the problem is just the opposite: if the user pushes the button
precisely at the time you change the state of the LED's, the interrupt
WOULDN'T happen until the button again changed state [e.g. the user released
it].  Further, there is no really good way to check whether the button has
been pushed without reading the port; if the button's pushed precisely as
the port has read, the same potential problem still exists.

1996\06\12@205905 by Martin J. Maney

flavicon
face
Myke and Neil seem to be asking much the same question this afternoon, so
just one reply to both.  :-)

On Wed, 12 Jun 1996, myke predko wrote:

> Now, I'm curious to know if I can use other PORTB bits for Input.  ie will a
> "movf PORTB, w" instruction to poll other bits cause a problem with port
> change bits?

In earlier PICs with the interrupt on change (again, sorry, I don't seem
to have saved the message that mentioned when this was (supposed to be?)
fixed - perhaps the 16CxxA and recent non-A parts?), basically any
access, read or write, to PORTB will cause the latch that is part of the
change-detect logic to be reset.  This is exactly how you were intended
to reset it, in fact, but it proves to restrict the use one can make of
the interrutp on change for any application other than waking the PIC up
from sleep.  The PIC does internal reads (as part of a generic
read/operate/write cycle) of PORTB for at least reads, writes, or bit
operations on PORTB.

However, you can use PORTB pins for output if you're willing to go to
some small bother, and you can live with what amounts to an
open-collector output.  The trick would be to write all zeros to the
PORTB pins not used for interrupt-on-change, and to control the state of
these pins through TRISB.  Come to think of it, you could get active pull
up or down from each pin, depending on whether you set it to 0 or 1,
couldn't you?

Warning!  Warning!  I haven't tested this idea!  It's probably not
original with me, but I can't recall seeing it described before -
probably memory failure on my part, as it's pretty obvious after it's
been described, isn't it?  ;-)

There's been some discussion about when the PIC might unexpectedly read
PORTB, but I don't recall that we've ever gotten an authoritative answer
to some fascinating (and troublesome, if you want to use interrupt on
change) speculations about this.


PS: nothing is new... I was about to send this off when I remembered that
I've seen the trick of controlling an output by writing to TRIS instead
of the data register in a couple places - I think it's suggested for
driving the I2C bus, for example.  I've been browsing the specs and app
notes for this recently, so that's probably the spark.

More... (looser matching)
- Last day of these posts
- In 1996 , 1997 only
- Today
- New search...