Searching \ for 'PIC16C84 & PortB interrupt' 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: 'PIC16C84 & PortB interrupt'.

Truncated match.
PICList Thread
'PIC16C84 & PortB interrupt'
1995\11\10@043916 by SONY-OD

flavicon
face
I try to use a PIC16C84 and I get MICROCHIP documentation. There is something
strange:

 PortB can generate INTERRUPT when there is change on RB.4..7, the
documentation said: these pins are sampled on the Q1 cycle of read.
The new input is compared with old latched value in every instruction cycle.

HOW IT IS possible an interrupt occurs if portB is latched only on a READ
instruction ?
Does this means that it's neccessary to read PORTB every time to generate
an interrupt ?
MICROCHIP Doc. said: PortB can generate instruction in SLEEP mode, HOW it
is possible if portB is latched only on a read ?

Is it a mistake of the MICROCHIP doc. ?

Someone can help me please,

       Philippe <spam_OUTsonyedeTakeThisOuTspamiway.fr>

1995\11\10@112247 by Mike Keitz

flavicon
face
>I try to use a PIC16C84 and I get MICROCHIP documentation. There is something
>strange:
>
>  PortB can generate INTERRUPT when there is change on RB.4..7, the
>documentation said: these pins are sampled on the Q1 cycle of read.
>The new input is compared with old latched value in every instruction cycle.
>
>HOW IT IS possible an interrupt occurs if portB is latched only on a READ
>instruction ?

When the port is read by the program, the interrupt-compare latch is reset
to agree with the present state of the port inputs.  Thus the interrupt
condition goes away then until a pin changes (actually, I think the RBIF
flag needs to be manually reset as well).  In other words, the read resets
the compare function so a further change is required.  The sampling is done
on every instruction cycle.  If the sample doesn't agree with the latched
value (last value read), the RBIF flag is set, which causes an interrupt if
RBIE and GIE are also set.

>Does this means that it's neccessary to read PORTB every time to generate
>an interrupt ?

No.  It is only necessary to read port B once while the external hardware is
in the 'non-interrupt' state (this defines what the state is), then clear
RBIF, and set RBIE and GIE.  The next change of one of the B4-B7 pins will
generate an interrupt.  Before leaving the interrupt routine, be sure that
the port and the latch agree with each other (by doing a read) and the RBIF
is clear so another interrupt won't occur immediately.

>MICROCHIP Doc. said: PortB can generate instruction in SLEEP mode, HOW it
>is possible if portB is latched only on a read ?

The latch is one input of the compare, the pin state is the other.  The
value in the latch is held during sleep from the last value read while the
CPU was running.  The path from the pins through to the comparators is
apparently held open during sleep.

>Is it a mistake of the MICROCHIP doc. ?

The system as it is described in the doc seems to make sense to me, though
their description isn't real clear.  I'm not sure why the convoluted
implementation of latching twice, it seems that a one-cycle pipeline
(generating a pulse each time a pin were different from the last cycle)
would have worked just as well if the RBIF indeed has its own latch.

-Mike

1995\11\10@130911 by Conny Andersson

flavicon
face
At 10.36 1995-11-10 +0100, Philippe wrote:

>  PortB can generate INTERRUPT when there is change on RB.4..7, the
>documentation said: these pins are sampled on the Q1 cycle of read.
>The new input is compared with old latched value in every instruction cycle.
>
>HOW IT IS possible an interrupt occurs if portB is latched only on a READ
>instruction ?

Easy! The pins are sampled AND put in the portB register by the
MOVF/SWAPF/... instructions BUT they are also "sampled" by the interrupt
logic - two separate sample-circuits. The actual data on the pins are not
nescessarily the same as the actual data in the register.


-- Conny

1995\11\11@061235 by adrian

flavicon
picon face
On the topic of the port B int on a 16C84...

Would I be right in thinking that setting or clearing B0-3 using bit
operations would mean a port read and write and hence clear any pending
interrupt for B4-7 change ?

The way I read it, I cannot use B0-3 for any I/O without risking loss of a
pending B4-7 change interrupt, which meant is was useful for getting out of
sleep but not much else.

Did I miss read the spec, or is this how it works ?

--
_
(_) _| _ . _  _   Tel +44 973 222257
( )(_|(  |(_|| )  Fax UK 0500 222258                    E&OE

1995\11\11@182557 by Andrew Warren

face
flavicon
face
Adrian Kennard <.....adrianKILLspamspam@spam@RHANNA.DEMON.CO.UK> wrote:

>On the topic of the port B int on a 16C84...
>
>Would I be right in thinking that setting or clearing B0-3 using bit
>operations would mean a port read and write and hence clear any pending
>interrupt for B4-7 change ?

   Adrian:

   No.  Interrupts set the RBIF flag; once set, that flag will trigger a
   jump to the interrupt vector as soon as its enable flag (RBIE) and GIE
   are both set.

   However...

   There's a major flaw in the Change-on-Port-B Interrupt logic.  If you
   read from Port B at the same instant that a change on RB4-7 occurs, the
   RBIF flag will NOT be set.  BSF/BCF instructions perform a read, of
   course, so if you ever do BCFs, BSFs, or any other Port-B read operation,
   you can pretty much forget about using the Change-on-Port-B interrupt.

   -Andy

--
Andrew Warren - fastfwdspamKILLspamix.netcom.com
Fast Forward Engineering, Vista, California

1995\11\13@115230 by John Payson

flavicon
face
>     There's a major flaw in the Change-on-Port-B Interrupt logic.  If you
>     read from Port B at the same instant that a change on RB4-7 occurs, the
>     RBIF flag will NOT be set.  BSF/BCF instructions perform a read, of
>     course, so if you ever do BCFs, BSFs, or any other Port-B read operation,
>     you can pretty much forget about using the Change-on-Port-B interrupt.

Does MOVWF perform a read-before-write? [I realize, of course, that if it
did so it would ignore the value read, but it's probably easier to have the
hardware do the read for all of the ALU-freg ops].  What about CLRW?  Does
that read [IND] if the 7 lsb's of opcode are zero?  Would changing the 7
LSB's to something else cause that something else to be read [hopefully
harmlessly] instead?

1995\11\13@123306 by Mike Keitz

flavicon
face
>What about CLRW?  Does
>that read [IND] if the 7 lsb's of opcode are zero?  Would changing the 7
>LSB's to something else cause that something else to be read [hopefully
>harmlessly] instead?

An interesting question, if it exists this side effect could be useful for
something (not sure what yet).  If the possible extra read could be a
problem, you could replace CLRW with ANDLW 0 (exactly the same effect as
CLRW; W=0 and Z flag =1) or of course MOVLW 0 (W=0, but Z unchanged) instead
and forget about the CLRW "instruction" (as you've noticed, it's actually
coded as CLRF x,w) altogether.

-Mike

1995\11\13@150424 by Andrew Warren

face
flavicon
face
John Payson <.....supercatKILLspamspam.....MCS.COM> wrote:

>Does MOVWF perform a read-before-write?

   No.

>What about CLRW?  Does that read [IND] if the 7 lsb's of opcode are zero?

   No, but why not just use MOVLW 0 (if you don't want the Z flag to be
   affected) or ANDLW 0 (if you do)?

   -Andy

--
Andrew Warren - EraseMEfastfwdspam_OUTspamTakeThisOuTix.netcom.com
Fast Forward Engineering, Vista, California

1995\11\13@190107 by John Payson

flavicon
face
> >What about CLRW?  Does
> >that read [IND] if the 7 lsb's of opcode are zero?  Would changing the 7
> >LSB's to something else cause that something else to be read [hopefully
> >harmlessly] instead?
>
> An interesting question, if it exists this side effect could be useful for
> something (not sure what yet).  If the possible extra read could be a
> problem, you could replace CLRW with ANDLW 0 (exactly the same effect as
> CLRW; W=0 and Z flag =1) or of course MOVLW 0 (W=0, but Z unchanged) instead
> and forget about the CLRW "instruction" (as you've noticed, it's actually
> coded as CLRF x,w) altogether.

I was just realizing that, because of the existence of writable registers
in the 16Cxx (though not 16C5x) which are altered by reading, MOVWF has to
be an oddball instruction; on the 16Cxx, almost all of the instructions whose
first two bits are "00" fit the following formula:
 read F-register selected by OP0-6
 take that and W; compute a value and flags [incl. "skip" flag] using the
   operation specified by OP8-12
 store the result in W if OP7 is 0, or back in the F resister if OP7 is 1

The only exceptions are:
 movwf
 nop
 clrwdt
 retfie
 return
 sleep
 tris
 option

Note that were it not for the existence of read-modified registers, even
these instructions could be executed with the above formula provided that
something else was "also" done [except for MOVWF, all of them would decode
as "take W and some F-register, then store W into W].  I wonder if that's
how they are in fact decoded on the 16C5x?

PS--Does anyone know how the TRIS and OPTION instructions are decoded?  I'd
like to be able to access EECTL and EEDATA without having to muss around
with bank-switching on the 16C84.

1995\11\23@023010 by Dan Matthews

picon face
Sorry Andy,

I hate to correct you when you are 99.9% right, but...

In the PIC16CXX architecture EVERY instruction that accesses a register
performs a read first, for the exact reason mentioned, simplification of design.

In this case, a MOVWF to PORTB during what would be a change on PORTB
interrupt will in fact clear the interrupt condition.

       best regards,

               Dan Matthews

At 12:03 PM 11/13/95 -0800, you wrote:
{Quote hidden}

1995\11\23@133253 by Andrew Warren

flavicon
face
Dan Matthews <KILLspamdmatthewKILLspamspamprimenet.com> wrote:

> I hate to correct you when you are 99.9% right, but...
>
> In the PIC16CXX architecture EVERY instruction that accesses a
> register performs a read first, for the exact reason mentioned,
> simplification of design.
>
> In this case, a MOVWF to PORTB during what would be a change on
> PORTB interrupt will in fact clear the interrupt condition.

Thanks, Dan...  My message to John Payson was just the singlw word,
"no", so I guess the portion that was "99.9% right" was the
list's mail address, his quoted question, and my signature.

It was bad enough when only instructions that performed an EXPLICIT
read or read-modify-write kept the interrupt from happening... This
new information makes the change-on-portB interrupt almost
COMPLETELY worthless.  Does Microchip see this as a bug and plan to
correct it in future revs of the chip?

-Andy


Andrew Warren - RemoveMEfastfwdTakeThisOuTspamix.netcom.com
Fast Forward Engineering, Vista, California

1995\11\23@232947 by Dan Matthews

picon face
Actually, the "99.9% correct" was in reference to your many other extensive
replies found here and on the BBS.

       Best regards,

               Dan Matthews

At 10:30 AM 11/23/95 -0800, you wrote:
{Quote hidden}

1995\11\24@013644 by Martin J. Maney

flavicon
face
On Thu, 23 Nov 1995, Andrew Warren wrote:

> It was bad enough when only instructions that performed an EXPLICIT
> read or read-modify-write kept the interrupt from happening... This
> new information makes the change-on-portB interrupt almost
> COMPLETELY worthless.  Does Microchip see this as a bug and plan to
> correct it in future revs of the chip?

I have no connection with Microchip other than that I'm designing a 16C73
into a product currently being prototyped, but I believe I can predict
the answer.  They will say "no".  The data sheet has always [always = in
the 1994 and 1995/1996 books] implied that this feature was intended for
use in applications where the input change is used to wake the chip from
a sleep state, and of course when the chip is sleeping it won't be
reading or writing the port B pins and disturbing the change sensing...

There's even an application note that demonstrates exactly this use,
isn't there?

So I believe that this is _exactly_ the operation that Microchip designed
into those pins on port B, and the bug is only that you wish they worked
otherwise than they do.  The 1995/1996 databook is pretty explicit about
this:  "the interrupt on change feature is reccomended for wake-up on key
depression operation and operations where port B is used only for the
interrupt on change feature."  I think they could allow as well
applications where bit 0 is used as an external interrupt input (for
non-sleeping applications).

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