Hi.
This is my view on the LAT/PORT/TRIS issue.
Probably more or less the same thing, but in
slightly different wording.


> The last value written to PORT is in LAT. eg LATD holds the
> contents that are to be written out if a pin is configured as an
> output
>
> But, a read of PORT (which may be caused by a read-modify-
> write instruction) over-writes what is in LAT.
>
> This can be trouble if PORT is a mix of inputs and outputs,
> because PORT writes to LAT (see below)
>
> When a pin is configured as an input and PORT is read, the
> corresponding bit in PORT is the state of the external pin.

Actualy, a read of PORT *always* reads the state of the external
pin no matter how TRIS is configured.
The question is *how* the pin is driven.

When configured as an input, the pin is (mainly) driven by an
external source. I say mainly, becuse you have to
take things like passive pullups (internal source) into account.

When configured as an output, the pin is (mainly) driven by
the value in LAT. I say mainly since you have take
things like capacitive loads (potential timing/race issues) into
account. And the pin could be shorted to Vdd or Vcc, of course.

Still, a read from PORT always reads the level of the
physical/external pin no matter how TRIS is configured.

> PORT register writes to the LAT register

And on the 18-series a write to the PORT and a write to LAT
is actualy the same thing. A read from those regs are not
the same thing.

So read-modify-write instructions using LAT (instead of PORT)
should be safe (or *are* safe according to the data sheets).

> Bottom line is that there is the possibility of problems if you assume
> the state of LAT, most definitely when changing the state of TRIS. You
> should keep track of what your s/w may do inadvertently to pins. For
> s/w that doesn't change TRIS after initialisation, it's
> probably nothing to worry about

Besides of the timing/race issues with capcitive loads. Isn't that
maybe the main issue with r-m-w instructions anyway ?

Best Regards
Jan-Erik.

--
http://www.piclist.com hint: To leave the PICList
mailto:piclist-unsubscribe-request@mitvma.mit.edu