Hi Scott, ----- Original Message ----- From: Scott Dattalo | On Mon, 6 Aug 2001, Sebastian Garcia wrote: | | > | > movf PORTB,W | > | > iorlw 1< | > movwf PORTB | > | > andlw ~(1< | > movwf PORTB | > | | > | Note that this still does a read/modify/write. | > | > | > Just to be sure: The movwf 's (?). (the movf not because destiny is W) | | No it's not the movwf's. For some reason Olin decided to clip out the | comment leading up to this snippet and thus presenting it out of | context. The comment said something like, "If PORTB hasn't been | written to for a 'long time' then you can do something like this". | | The issue is that the midrange (and 12-bit, but not the 18cxxx) | devices don't have an I/O output latch that is independent of the | output driver. So reading an I/O port cause the those values to be | written out again. I realize that sentence is confusing, but imagine | an I/O line having a capacitor tied to it. It takes time to cause the | capacitor to charge to a new state. So suppose the capacitor is | uncharged and you try charging by setting an I/O high. If you READ the | I/O port, immediately following the write, there's a good chance it's | still low. If it turns out that it is low, then this will refrech the | output latch with a zero and then drive the capacitor low again! I understand the R-M-W issue, and I think of it as divided in two classes: 1) R-M-W *instructions* over the port (In fact these kind of instructions acts the same way over any register, but AFAIK there have no critical effects on other than the ports). That's while executing, in the same Q cycle. 2) R-M-W *operations*, done by a pair of instructions accessing the port, in adjacent Q cycles (or between some instructions). I guess You are talking here about case (2), while I was talking about case (1). My doubt is *who* are the R-M-W instructions, other than the well known 'bcf' and 'bsf'. I think the only R-M-W instruction in that posted code is the movwf because it reads register f (in fact, being f equal to PORTB, it reads the port *pins*), then process it (I assume it modify only the different bits in comparison to W), and then writes the register f (writes the port latch). Please let me know if I'm wrong. I never saw documented who are the R-M-W instructions and I'm supposing this based on the Q-cycle activity of each instruction...(from the instruction set description). | Most of the times you don't have a capacitor tied to an I/O line. But | it's not uncommon to have 10 to 100 pF of parasitic capacitance | sitting on an I/O line. Is this a problem? A PIC I/O has around ~ 30 | to 50 ohms output impedance (I'm just guessing this ...). Taking the | worst case of 50 ohms and 100 pF leads to a 5nS time constant. Even | when the clock is 20Mhz, this is hardly a factor. So the typical case | is probably okay with the BCF/BSF's. I'd only begin to really worry | when driving external cables and similar cases. Something like | bit-banging an I2C prom would most probably work just fine. Hey, who | was the bonehead complianing about the original SPI code? Now that You mention I2C, I've read a MChip tip that shows the R-M-W fact as a "feature", for handling I2C bus conflicts, and for "fault-tolerant systems". | > | However, I think the RMW problem has been blown out of proportion. It | > | only | > | matters if 1: you have other bits in the port that you will be toggling | > | between input and output and you don't explicitly set their state when | > | switching to output, and 2: if the external circuit holds a PIC output in | > | its opposite state. You have full control and knowledge of #1. #2 is | > | rare | > | because it usually means poorly designed hardware, although it could | > | legitimately happen for short periods of time (a few uS) after the output | > | is | > | switched if the external circuit has considerable capacitance. | > | > | > You forgot the open-source pin possibility, when it's configured as output | > but being driven externally. | | I thought open-source only worked for software :). Me too! :o) Change for: open-drain. And in my other mail I've swapped read and write... :o) Best Regards, S.- -- http://www.piclist.com hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details.