On Mon, 6 Aug 2001, Sebastian Garcia wrote:

> | >     movf   PORTB,W
> | >     iorlw  1<<clock_bit
> | >     movwf  PORTB
> | >     andlw  ~(1<<clock_bit)
> | >     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!

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?

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

Scott

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