Searching \ for '[PIC] Question about LAT registers' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: techref.massmind.org/techref/microchip/devices.htm?key=pic
Search entire site for: 'Question about LAT registers'.

Exact match. Not showing close matches.
PICList Thread
'[PIC] Question about LAT registers'
2006\02\19@091454 by kerri

flavicon
face
Hi,
What is this LAT registers, what do they do, something read-modify-write
I completely don't understand this. Why do I need anything else if I have
PORT and TRIS ?

2006\02\19@094726 by Spehro Pefhany

picon face
At 02:14 PM 2/19/2006 +0000, you wrote:
>Hi,
>What is this LAT registers, what do they do, something read-modify-write
>I completely don't understand this. Why do I need anything else if I have
>PORT and TRIS ?

Using a RMW instruction on a PORT register (eg. bsf PORTA, 0) will read
all the bits in PORTA, set bit 0, then write the bits back again.

However, when you use the PORT address, the R part of the RMW reads the
levels actually on the port pins, which, for reasons of loading or because
the pins have not settled, or because it's an open-drain output, may not
be at the same logical levels as the port latch itself. This may vary
from part-to-part, with external hardware conditions or asynch timing
conditions (was there just an interrupt?).  The state of the
latch may thus undergo an unintended change (in bits other than 0 in the
above example). You may have to have a shadow latch register in RAM and
put more instructions in there to get it to work consistently (of course
it consumes RAM and runs slower at bit-diddling, which is one thing PICs
are pretty good at).

Using the LAT address means that R part of the RMW reads from the port
*latch*, not the port pins, so RMW instructions work right every time.

When introduced, it was LONG overdue, IMHO. Particularly since the 18F
series can execute instructions faster than the port pins can reliably
change state.

Best regards,

Spehro Pefhany --"it's the network..."            "The Journey is the reward"
spam_OUTspeffTakeThisOuTspaminterlog.com             Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog  Info for designers:  http://www.speff.com
->> Inexpensive test equipment & parts http://search.ebay.com/_W0QQsassZspeff


2006\02\19@111910 by kerri

flavicon
face
{Quote hidden}

ok, now assuming we have LAT to solve the issue, what do we need
to do with LAT register, should be use BSF PORTA,0 or BSF LATA,0

also, am I correct to say that LAT is only important for output pins

tia.

2006\02\19@114534 by Spehro Pefhany

picon face
At 04:19 PM 2/19/2006 +0000, you wrote:


>ok, now assuming we have LAT to solve the issue, what do we need
>to do with LAT register, should be use BSF PORTA,0 or BSF LATA,0

The LATter.  You still need the PORTA address for reading the input pins.

Note that LAT isn't really a new register, it's just a new address which
maps to the outputs of the port latch (which was always there).

>also, am I correct to say that LAT is only important for output pins

Yes, and only for RMW instructions (writing the entire port is not
problematic either way).

>Best regards,

Spehro Pefhany --"it's the network..."            "The Journey is the reward"
.....speffKILLspamspam@spam@interlog.com             Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog  Info for designers:  http://www.speff.com
->> Inexpensive test equipment & parts http://search.ebay.com/_W0QQsassZspeff


2006\02\20@035618 by Peter Todd

picon face
On Sun, Feb 19, 2006 at 09:59:12AM -0500, Spehro Pefhany wrote:
> When introduced, it was LONG overdue, IMHO. Particularly since the 18F
> series can execute instructions faster than the port pins can reliably
> change state.

So you mean, if I get my fancy 18F PIC running at 40mhz a dead simple
set/clear loop on a port won't get me a nice 2mhz (or whatever it works
out too) squarewave on my pins? Even in ideal conditions? (no parasitic
capacitance, minimal loading etc)

Or do you just mean in non-ideal conditions?

That could make building video generators and the like... a rather more
problematic task.

--
petespamKILLspampetertodd.ca http://www.petertodd.ca

2006\02\20@043445 by Wouter van Ooijen

face picon face
> > When introduced, it was LONG overdue, IMHO. Particularly
> since the 18F
> > series can execute instructions faster than the port pins
> can reliably
> > change state.
>
> So you mean, if I get my fancy 18F PIC running at 40mhz a dead simple
> set/clear loop on a port won't get me a nice 2mhz (or
> whatever it works out too) squarewave on my pins?
> Even in ideal conditions? (no parasitic capacitance, minimal loading
etc)
>
> Or do you just mean in non-ideal conditions?

Just using the PORT registers can be considered a non-ideal condition.
The 18F's introduced the LAT registers that do not have the
read-modify-write problem, so you can avoid the problem and have your
fast reacting pins.

Side note: IIRC there was also the write-in-Q2/read-in-Q1 problem for
(for instance) sequential instructions. Is this no longer an issue with
the 18F's?

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu


2006\02\20@062626 by Spehro Pefhany

picon face
At 04:12 AM 2/20/2006 -0500, you wrote:
>On Sun, Feb 19, 2006 at 09:59:12AM -0500, Spehro Pefhany wrote:
> > When introduced, it was LONG overdue, IMHO. Particularly since the 18F
> > series can execute instructions faster than the port pins can reliably
> > change state.
>
>So you mean, if I get my fancy 18F PIC running at 40mhz a dead simple
>set/clear loop on a port won't get me a nice 2mhz (or whatever it works
>out too) squarewave on my pins? Even in ideal conditions? (no parasitic
>capacitance, minimal loading etc)

The set/clear RMW loop using PORT addresses won't have a problem if it just
operates on a single particular bit, since the value *read*
on that bit doesn't matter. The problem would come up if you had a write
instruction that changed a port (RMW or just write), followed by a RMW
instruction that wasn't supposed to affect a bit changed by the previous
instruction. That might not work, even under ideal conditions, according to
the
datasheet numbers. But there's an easy solution with the 18F (LAT),
so the problem isn't at all serious.

In general, this issue is more and more likely to crop up as internal
clock speeds increase. You may have a part running at 200MHz internally,
but you certainly won't have (and don't want) port pins changing that
fast (too much EMI, for one thing), so the pins, in general, are going to be
out of sync with the instructions that control them, perhaps by several
instructions.

Best regards,

Spehro Pefhany --"it's the network..."            "The Journey is the reward"
.....speffKILLspamspam.....interlog.com             Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog  Info for designers:  http://www.speff.com
->> Inexpensive test equipment & parts http://search.ebay.com/_W0QQsassZspeff


2006\02\20@064534 by Wouter van Ooijen

face picon face
> In general, this issue is more and more likely to crop up as internal
> clock speeds increase. You may have a part running at 200MHz
> internally, but you certainly won't have (and don't want)
> port pins changing that fast (too much EMI, for one thing),

I can image applications where you certainly want that, generating video
is one.

> so the pins, in general, are going to be
> out of sync with the instructions that control them, perhaps
> by several instructions.

why? AFAIK changing a LAT pin will affect the physical pin within the
same or maybe the next instruction (2 stage pipeline).

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu


2006\02\20@065208 by Michael Rigby-Jones

picon face


{Quote hidden}

That would depend entrely on the ports drive capability and parasitic capacitance.  I know from experience that a 16F PIC running at 20MHz, cannot change the pin state in one instruction cycle with zero loading.

Regards

Mike

=======================================================================
This e-mail is intended for the person it is addressed to only. The
information contained in it may be confidential and/or protected by
law. If you are not the intended recipient of this message, you must
not make any use of this information, or copy or show it to any
person. Please contact us immediately to tell us that you have
received this e-mail, and return the original to us. Any use,
forwarding, printing or copying of this message is strictly prohibited.
No part of this message can be considered a request for goods or
services.
=======================================================================

2006\02\20@071854 by Gerhard Fiedler

picon face
Wouter van Ooijen wrote:

>> so the pins, in general, are going to be out of sync with the
>> instructions that control them, perhaps by several instructions.
>
> why? AFAIK changing a LAT pin will affect the physical pin within the
> same or maybe the next instruction (2 stage pipeline).

I think Spehro was not talking about pipelining in the processor
architecture. He was talking about the time it takes the pin to reach Vol
or Voh once the port latch is cleared/set. With a fast core (he was talking
about a 200 MHz core, possibly with a 5 ns instruction cycle, or maybe 20
ns on a PIC architecture) a port pin may take a number of cycles to reach
the threshold.

Of course, as you say, there are applications that want fast port pins. But
there are also many that don't want fast port pins -- so there are devices
with specific port drivers for both cases.

Gerhard

2006\02\20@074706 by Spehro Pefhany

picon face
At 12:43 PM 2/20/2006 +0100, you wrote:
> > In general, this issue is more and more likely to crop up as internal
> > clock speeds increase. You may have a part running at 200MHz
> > internally, but you certainly won't have (and don't want)
> > port pins changing that fast (too much EMI, for one thing),
>
>I can image applications where you certainly want that, generating video
>is one.

It's dead easy with modern technology to make a processor core with a 400MHz
instruction rate (~1/10 that of a Pentium). That's 2.5ns per instruction.
You don't want edge speeds much faster than about 10ns on the pins, possibly
slower in many applications (controlled rise/fall times). So even without
pipeline issues you are going to see multiple instructions executing
in the time the pin ramps from one level to the other. This is limited by
packaging and physics on the outside, and I don't think many of us are
going to want to go to LVDS or PECL with terminated controlled-impedance
traces on a general-purpose micro. You don't want the current, ground
bounce or EMI. As Mike says, there's a noticeable lag now, even at a
leisurely 20MHz.

If the high frequency stuff can be kept on-chip, then internal rise and
fall times well into the sub-ns range are no problem. But inputs such as
port pins and the clock will be slow (boosted up with a PLL in the latter
case) and outputs pins will lag by multiple instructions. The decoupling
is here and it's inevitable (on higher performance devices).

It's a bit like when you use a 4MHz PIC to turn on a relay. You know
pretty much exactly when you request the relay to turn on. It takes maybe
an instruction time for the driver to turn on. There's a blip in the current
as the parasitic capacitance charges and then the current begins  to ramp
up in the coil, not quite linearly. Some hundreds of instructions later,
the N.O. contact opens. Perhaps 3,000 instructions later the N.C. contact
first closes, and then it bounces and arcs around for another thousand or
two, depending on the construction of the relay. Finally, after perhaps
5-10,000 instructions you can be reasonably sure it's actually closed for
good. We just may get to that kind of ratio on port pins in our lifetimes.

>Best regards,

Spehro Pefhany --"it's the network..."            "The Journey is the reward"
@spam@speffKILLspamspaminterlog.com             Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog  Info for designers:  http://www.speff.com
->> Inexpensive test equipment & parts http://search.ebay.com/_W0QQsassZspeff


More... (looser matching)
- Last day of these posts
- In 2006 , 2007 only
- Today
- New search...