Post by thread:PIC16C84 & PortB interrupt

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_OUTsonyedeTakeThisOuTiway.fr>

>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

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

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

Adrian Kennard <.....adrianKILLspam@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 - fastfwdKILLspamix.netcom.com Fast Forward Engineering, Vista, California

> 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?

>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

> >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.

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}>John Payson <supercatspam_OUTMCS.COM> wrote: > >>Does MOVWF perform a read-before-write? > > No. > > -Andy > >-- >Andrew Warren - @spam@fastfwdKILLspamix.netcom.com >Fast Forward Engineering, Vista, California > >

Dan Matthews <KILLspamdmatthewKILLspamprimenet.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 - RemoveMEfastfwdTakeThisOuTix.netcom.com Fast Forward Engineering, Vista, California

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}>Dan Matthews <spamBeGonedmatthewspamBeGoneprimenet.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 - TakeThisOuTfastfwdEraseMEspam_OUTix.netcom.com >Fast Forward Engineering, Vista, California > >

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).