Post by thread:[PIC:]interrupt on change...

> Except when i read the documentation more carefully, I see that the IoC > interrupt is cleared by any IO to the port, and my outputs are being > driven all the time. There is even a caveat that IoC interrupts may be > missed entirely if the transition occurs during an IO instruction to the > port. Hmmph. That doesn't sound good. Does anyone have any > experience with how much trouble this is likely to be in real life? Interrupt-on-change should be renamed "wake-up-on-change" because it's useless on a running processor. Cheers, Bob -- http://www.piclist.com hint: The list server can filter out subtopics (like ads or off topics) for you. See http://www.piclist.com/#topics

Unless I am losing my mind, I currently use IOC on a running 12f629 to detect pin changes. I constantly write to GPIO using MOVWF and have no problems. IIRC on these chips, you can write to the port and it will not reset the IOC internal latch values (internal latch not GPIF interupt flag or whatever). However, BSF, BCF, ANDWF, etc are all read-modify-write instructions that will cause a "read" and reset the IOC latches. So you would have to use MOVWF to update your pins without messing up the IOC. The only time I read from GPIO is when I am in the IOC handler routine, just before clearing the interupt flag. The flag is "sticky" until you read from GPIO. - Ben On Fri, 11 Jun 2004 14:49:19 -0700, William Chops Westfield <spam_OUTwestfwTakeThisOuTmac.com> wrote: {Quote hidden}> > On Friday, Jun 11, 2004, at 14:28 US/Pacific, Bob Blick wrote: > > > > Interrupt-on-change should be renamed "wake-up-on-change" because it's > > useless on a running processor. > > > Oh. Rats! I suppose it would be OK if you have the entire port set to > be inputs, as in a keyboard scanner? > > Thanks > Bill W > > > > -- > http://www.piclist.com hint: The list server can filter out subtopics > (like ads or off topics) for you. See http://www.piclist.com/#topics > -- http://www.piclist.com hint: The list server can filter out subtopics (like ads or off topics) for you. See http://www.piclist.com/#topics

> Oh. Rats! I suppose it would be OK if you have the entire port set to > be inputs, as in a keyboard scanner? I'm sure that's an original purpose of PortB - a 4x4 keypad interface You might find something useful here AN566 - Using the Port B Interrupt on Change as an External Interrupt http://ww1.microchip.com/downloads/en/AppNotes/00566b.pdf AN552 - Implementing Wake Up on Keystroke http://ww1.microchip.com/downloads/en/AppNotes/00552e.pdf AN552 Source code http://ww1.microchip.com/downloads/en/AppNotes/00552.zip Interestingly, this application does not use IoC, although the 4x4 keypad is right across PortB (figure 2) AN557 - 4-channel Digital Voltmeter with display and keypad http://ww1.microchip.com/downloads/en/AppNotes/00557c.pdf -- http://www.piclist.com hint: The list server can filter out subtopics (like ads or off topics) for you. See http://www.piclist.com/#topics

Ben Hencke <.....PICLISTKILLspam@spam@mitvma.mit.edu> wrote: > Unless I am losing my mind, I currently use IOC on a running 12f629 to > detect pin changes. I constantly write to GPIO using MOVWF and have no > problems. Newer PICs don't have the problems that older PICs do; perhaps the 12F629 is one of those newer PICs. > IIRC on these chips, you can write to the port and it will not reset > the IOC internal latch values (internal latch not GPIF interupt flag > or whatever). However, BSF, BCF, ANDWF, etc are all read-modify-write > instructions that will cause a "read" and reset the IOC latches. So > you would have to use MOVWF to update your pins without messing up the > IOC. On PICs with the Interrupt-on-Change problem, an internal read is performed even for MOVWF instructions, so reads AND writes reset the Interrupt-on-Change latches. -Andy === Andrew Warren -- aiwKILLspamcypress.com === Principal Design Engineer === Cypress Semiconductor Corporation === === Opinions expressed above do not === necessarily represent those of === Cypress Semiconductor Corporation -- http://www.piclist.com hint: The list server can filter out subtopics (like ads or off topics) for you. See http://www.piclist.com/#topics

> IIRC on these chips, you can write to the port and it will not reset > the IOC internal latch values (internal latch not GPIF interupt flag > or whatever). However, BSF, BCF, ANDWF, etc are all read-modify-write > instructions that will cause a "read" and reset the IOC latches. So > you would have to use MOVWF to update your pins without messing up the > IOC. I just doublechecked the data sheet - 12F629 is the same as with the older chips - either a read or a write to the port will reset it, so if you get a change as you're writing to the port, you'll miss it. Cheerful regards, Bob -- http://www.piclist.com hint: The list server can filter out subtopics (like ads or off topics) for you. See http://www.piclist.com/#topics

Yes a read or write will reset the latches, but it doesnt matter if the latches are reset after GPIF is set. I think the problem with the GPIF not getting set (not interupting) is when there is a read involved. I think you can write to it all day long and it will always interupt properly. Quote from the 12f manual: "If a change on the I/O pin should occur when the read operation is being executed (start of the Q2 cycle), then the GPIF interrupt flag may not get set. " It specifically mentions the Q2 cycle. Quote from the mid-range manual: "Q1: Instruction Decode Cycle or forced No operation Q2: Instruction Read Data Cycle or No operation Q3: Process the Data Q4: Instruction Write Data Cycle or No operation " So to me this looks like the bug is only in the Q2 read cycle, and does not affect the write cycle. I could be doing something terribly evil, but I have several prototypes that do a lot of constant writing to GPIO and still rely on IOC to interupt and have not had any problems. - Ben On Fri, 11 Jun 2004 15:59:27 -0700, Bob Blick <.....bblickKILLspam.....sonic.net> wrote: {Quote hidden}> > > IIRC on these chips, you can write to the port and it will not reset > > the IOC internal latch values (internal latch not GPIF interupt flag > > or whatever). However, BSF, BCF, ANDWF, etc are all read-modify-write > > instructions that will cause a "read" and reset the IOC latches. So > > you would have to use MOVWF to update your pins without messing up the > > IOC. > > I just doublechecked the data sheet - 12F629 is the same as with the older > chips - either a read or a write to the port will reset it, so if you get > a change as you're writing to the port, you'll miss it. > > Cheerful regards, > > Bob > > > > -- > http://www.piclist.com hint: The list server can filter out subtopics > (like ads or off topics) for you. See http://www.piclist.com/#topics > -- http://www.piclist.com hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details.

Ben Hencke wrote : > Unless I am losing my mind, I currently use IOC on a running 12f629 to > detect pin changes. I constantly write to GPIO using MOVWF and have no > problems. The same. I had a prototype running with 100 Hz "zerocrosing signal" on one GPIO pin, and the output of a TSOP IR recevied on another and the gate of a TRIAC on a third GPIO pin. The two first was both using IoC and served by two ISR's. I could not "see" any trouble with this setup... But, maybe I wasn't looking hard enough... :-) :-) Regards, Jan-Erik. -- http://www.piclist.com hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details.

Don't be too quick to denigrate IOC! I'm using IOC on a running processor and I'm happy as a clam!! Yes, you do have to be careful - don't poll the port, define the entire port as inputs, let your interrupt do the reads, etc., but in some instances, it can be a near ideal answer to an otherwise sticky program. You can let your mainline code do all your heavy background routines and never miss an input change. In my case, I'm using IOC to handle two 2-bit optical encoder inputs and three pushbuttons. Saves me from having to poll those devices at a high enough rate to ensure no data loss, which would seriously impact the useful work I need to do in the background. My input from the encoders comes in bursts that, when they occur, demand a lot of processor activity, essentially suspending background activity during that time. To do this application in a polling environment would require a lot more horsepower than I'm presently using (I'm using 16F628s - maxed out on memory and RAM usage, but sufficient for the job!). To each their own, I guess! Dennis Bob Blick wrote: {Quote hidden}>>On Friday, Jun 11, 2004, at 14:28 US/Pacific, Bob Blick wrote: >> >> >>>Interrupt-on-change should be renamed "wake-up-on-change" because it's >>>useless on a running processor. >>> >>> >>> >>Oh. Rats! I suppose it would be OK if you have the entire port set to >>be inputs, as in a keyboard scanner? >> >> > >Yes, but you also don't want to poll the port, so if you use IOC you do >all reads in the interrupt service routine. > >Cheers, > >Bob > >-- >http://www.piclist.com hint: The list server can filter out subtopics >(like ads or off topics) for you. See http://www.piclist.com/#topics > > > -- http://www.piclist.com hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details.

All write ops perform a read first. From the '629/675 manual: "Reading the GPIO register reads the status of the pins, whereas writing to it will write to the port latch. All write operations are read-modify-write operations. Therefore, a write to a port implies that the port pins are read, this value is modified, and then written to the port data latch." Further along: "Any instruction that specifies a file register as part of the instruction performs a Read-Modify-Write (R-M-W) operation. The register is read, the data is modified, and the result is stored according to either the instruction, or the destination designator d . A read operation is performed on a register even if the instruction writes to that register... For example, a CLRF GPIO instruction will read GPIO, clear all the data bits, then write the result back to GPIO. THIS EXAMPLE WOULD HAVE THE UNINTENDED RESULT THAT THE CONDITION THAT SETS THE GPIF FLAG WOULD BE CLEARED." (my emphasis added) As noted by others, the IOC function can be used as long as the above is taken into condsideration. But the R-M-W "glitch" is real and must be dealt with. Ignoring it (as I did early on) will eventually result in software that seems flakey and intermittent. Hope this helps- Tom {Quote hidden}>Quote from the 12f manual: >"If a change on the I/O pin should occur when the read operation is >being executed (start of the Q2 cycle), then the GPIF interrupt flag >may not get set. " > >It specifically mentions the Q2 cycle. > >Quote from the mid-range manual: >"Q1: Instruction Decode Cycle or forced No operation >Q2: Instruction Read Data Cycle or No operation >Q3: Process the Data >Q4: Instruction Write Data Cycle or No operation " > >So to me this looks like the bug is only in the Q2 read cycle, and >does not affect the write cycle. > >I could be doing something terribly evil, but I have several >prototypes that do a lot of constant writing to GPIO and still rely on >IOC to interupt and have not had any problems. > >- Ben -- http://www.piclist.com hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details.

Hmm... Now I am definitely confused. So I found this in the instruction set info for MOVWF in the mid-range manual: Q1 Decode Q2 Read register 'f' Q3 Process Data Q4 Write Register 'f' That seems to put a nail in the coffin, and I would drop this here and now if I hadn't been using IOC for months now. I looked at some other instructions, namely CLRW: Q1 Decode Q2 Read register 'f' Q3 Process Data Q4 Write Register 'f' Now we all know that CLRW does not take a 'f parameter and doesn't affect any file registers right? The documentation is clearly copy/pasted. Perhaps the documentation for MOVWF is also bogus and whoever wrote "All write operations are read-modify-write operations" was just confused from reading the documentation ;-) So I think I will need to call Mchip Monday and ask them to explain this mess. -Ben On Jun 12, 2004, at 7:51 AM, Tom wrote: {Quote hidden}> All write ops perform a read first. From the '629/675 manual: > > "Reading the GPIO register reads the status of the pins, > whereas writing to it will write to the port latch. All write > operations are read-modify-write operations. Therefore, > a write to a port implies that the port pins are read, > this value is modified, and then written to the port data > latch." > > > Further along: > > "Any instruction that specifies a file register as part of > the instruction performs a Read-Modify-Write (R-M-W) > operation. The register is read, the data is modified, > and the result is stored according to either the instruction, > or the destination designator d . A read operation > is performed on a register even if the instruction writes > to that register... For example, a CLRF GPIO instruction will read > GPIO, > clear all the data bits, then write the result back to > GPIO. THIS EXAMPLE WOULD HAVE THE UNINTENDED RESULT > THAT THE CONDITION THAT SETS THE GPIF FLAG WOULD BE > CLEARED." > > (my emphasis added) > > As noted by others, the IOC function can be used as long as the above > is > taken into condsideration. But the R-M-W "glitch" is real and must be > dealt > with. Ignoring it (as I did early on) will eventually result in > software > that seems flakey and intermittent. > > Hope this helps- > Tom > >> Quote from the 12f manual: >> "If a change on the I/O pin should occur when the read operation is >> being executed (start of the Q2 cycle), then the GPIF interrupt flag >> may not get set. " >> >> It specifically mentions the Q2 cycle. >> >> Quote from the mid-range manual: >> "Q1: Instruction Decode Cycle or forced No operation >> Q2: Instruction Read Data Cycle or No operation >> Q3: Process the Data >> Q4: Instruction Write Data Cycle or No operation " >> >> So to me this looks like the bug is only in the Q2 read cycle, and >> does not affect the write cycle. >> >> I could be doing something terribly evil, but I have several >> prototypes that do a lot of constant writing to GPIO and still rely on >> IOC to interupt and have not had any problems. >> >> - Ben > > -- > http://www.piclist.com hint: The PICList is archived three different > ways. See http://www.piclist.com/#archives for details. > > -- http://www.piclist.com hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details.

Ben Hencke wrote : > So I found this in the instruction set info for MOVWF in the mid-range > manual: > > Q1 Decode > Q2 Read register 'f' > Q3 Process Data > Q4 Write Register 'f' Now, the 18 series might have different implementation of the instructions, the 18 series ref manual says about MOVWF : Q1 Decode Q2 Read register WREG Q3 Process Data Q4 Write Register 'f' which seems more logical, right ? I'd guess that that is what should have been in the 16 series docs also... > I looked at some other instructions, namely CLRW: > > Q1 Decode > Q2 Read register 'f' > Q3 Process Data > Q4 Write Register 'f' I think Q4 should have been "Write Register WREG", but the 'f' is still a bit confusing, of course. Jan-Erik. -- http://www.piclist.com hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details.

Ben wrote: > Now we all know that CLRW does not take a 'f parameter and doesn't > affect any file registers right? Actually, it DOES, on midrange PICs at least. Take a look at the bit patterns for CLRW and CLRF on any 16x datasheet, and you'll see that these are actually the same instruction, differing only in the destination bit. The assembler simply doesn't let you specify a register for CLRW, since it's almost completely irrelevant. NOT totally irrelvant, however. I've seen a Microchip app note somewhere that recommends that development tool authors generate CLRW instructions with an address other than the originally suggested 0 (INDF). That could cause obscure problems if FSR happened to be pointing to a register with side-effects on read, like RCREG. Jason Harper -- http://www.piclist.com#nomail Going offline? Don't AutoReply us! email EraseMElistservspam_OUTTakeThisOuTmitvma.mit.edu with SET PICList DIGEST in the body

Jason Harper wrote : > Ben wrote: > > Now we all know that CLRW does not take a 'f parameter and doesn't > > affect any file registers right? > > Actually, it DOES, on midrange PICs at least. Take a look at the bit > patterns for CLRW and CLRF on any 16x datasheet, and you'll > see that these are actually the same instruction, differing only in the > destination bit. And, if you also compare this with the 18 series PICs, where there is no CRLW instruction *at all*, but the W register is directly addressed throught the WREG FSR so you just do "CLRF WREG", then things begin to fall into place... It *could* be that the directly addresed WREG on the 18 series is just a minor difference in the instruction encoding, not a real difference in the actual processor architecture... I don't know... Jan-Erik. -- http://www.piclist.com#nomail Going offline? Don't AutoReply us! email listservspam_OUTmitvma.mit.edu with SET PICList DIGEST in the body

Ben Hencke wrote : > Unless I am losing my mind, I currently use IOC on a running 12f629 > to detect pin changes. I constantly write to GPIO using MOVWF and > have no problems. and Jan-Erik Soderholm <@spam@PICLISTKILLspammitvma.mit.edu> replied: > The same. Guys: (paraphrased from something I posted 4 years ago) It would be easy to test: You'd just need a variable-frequency square-wave input to PORTB, a foreground routine that does nothing but write to PORTB in a tight loop, an ISR that toggles a PORTA pin on every PORTB change, and two external counters whose readouts you can compare. Some PICs don't miss portb-change interrupts even if the pin-state changes during an explicit read; if you're using one of those chips, you'll never see the problem. If you're using one of the chips that DOES have the problem, though, the fact that you haven't seen it in your current project doesn't mean that it doesn't (or won't) happen. -Andy === Andrew Warren -- KILLspamaiwKILLspamcypress.com === Principal Design Engineer === Cypress Semiconductor Corporation === === Opinions expressed above do not === necessarily represent those of === Cypress Semiconductor Corporation -- http://www.piclist.com hint: To leave the PICList RemoveMEpiclist-unsubscribe-requestTakeThisOuTmitvma.mit.edu