Writing PIC port bits

As someone else said, this is normal and your fix is SOP. It can lead to all sorts of unpleasant bugs if you're not a bit careful.

Later PICs such as the 18F series have a second port memory location (called LATx rather than PORTx) that reads the latch output rather than the current port pin levels, and thus makes RMW instructions work the way you would probably expect.

Best regards, Spehro Pefhany

--
"it\'s the network..."                          "The Journey is the reward"
speff@interlog.com             Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog  Info for designers:  http://www.speff.com

fix I

writing

in RAM

Undoing

It's called using a shadow register. It's actually the best way to do things.

pins.

If you diddle a single bit on a port, you can run into the dreaded RMW (read modify write) issue. In order to change just one bit, the PIC has to read the whole port value, change the bit and write the whole port value back. The problem lies in reading the port bits. The actual pin state gets read and not the port latch register. This can be a real problem if the pins are heavily loaded and/or the PIC is running at higher clock speeds. Search Google for more than you ever wanted to know about this stuff.

matters.

of

of

Good luck, but I don't think you will likely succeed. Stick with using a shadow register to hold the pin values, it's one less thing to worry about.

possible,

Anyway, I

pushing,

on

This is a common pitfall with PICs.

...

Thanks; that helps more than you know. BTW, was your closing remark about PICs in regard to RMW? or to hair and sleeplessness?

'Read, modify, write'. If you do a bit set/clear on a bit in the port, the port itself is physically 'read', the bit is toggled, and the result written back to the output. The problem is that if (for instance), the pins have a heavy load, and though driven 'high', do not reach the voltage that the input sees as the 'high' level, the bit concerned will be read as a '0', not a '1', and written back with the wrong value. This example would be in a sense an 'overload' condition on the output concerned, but can be met on a quite reasonably loaded pin, if there is a some capacitance present. The actual 'write' to the port takes place in the last clock cycle of the instruction, while the 'read' takes place in the first clock cycle. So if you perform two successive I/O operations, setting (say) bit 0, then bit

1, on the second operation, there will only be one cycle of the processor clock, since bit 0 was nominally 'set', and it is common to find that the combination of load capacitance and gate drive limits, have not allowed the pin to reach the desired level in this time. It is inherent in the fact that there is only the port itself, and not a seperate output latch. The 18 family chips have a 'shadow register', to allow this to be avoided. On the older chips, doing it in software, or allowing enough time for the pins to correctly reach the required level, are well documented 'fixes' (MicroChip describes this problem comprehensively in a couple of their application notes).

Best Wishes

Particularly for open-drain outputs. This one is an accident waiting to happen:

LED Port pin -----[R]-----|

Time will never be enough when the pin is loaded enough to prevent it from reaching the desired level. on the 12 and 14 bit cores a shadow register is realy the only solution.

Wouter van Ooijen

-- ------------------------------------

Webshop for PICs and other electronics Teacher electronics and informatics

And the LED will not be lit. Did you intend something else? Are you using the LED as an input device?

Sure, but the LED may not reliably pull it all the way to '1'. RMW will then drive a '0' to the port pin, even if the LED is "off".

--
  Keith

Works fine in that direction, but with an open-drain port pin, the LED+resistor (depending on LED Vf and supply voltage) may not be able to pull up the output pin above the "1" threshold.

Best regards, Spehro Pefhany

--
"it\'s the network..."                          "The Journey is the reward"
speff@interlog.com             Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog  Info for designers:  http://www.speff.com

Yes, what he said.

Best regards, Spehro Pefhany

--
"it\'s the network..."                          "The Journey is the reward"
speff@interlog.com             Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog  Info for designers:  http://www.speff.com

Red LED's have lower on-voltage than green ones.

Suppose that the above port pin is open-drain, with the LED connected as above. Suppose the LED has been successfully turned off some time ago (long enough for the voltage to settle out) by a bsf instruction (bit set) operating on the port.

Now suppose that we try to modify another bit of the same port.. with, for example, a bsf or bcf instruction (or other RMW instruction). The RMW instruction first reads the entire port (input levels, not latch), modifies only the bit in question, then writes it back to the latch. If the open drain *output* was not pulled up to a "1", then the R part of the RMW instruction reads a "0" and writes that (unmodified) back to the latch. The LED then turns "on", which is probably not what you intended.

This can be "fixed" with a resistor across the LED, but then you can run into a potential time issue, as I implied in the first paragraph. If the instruction to turn the LED off is too close (time-wise) to the next RMW instruction on the same port for the stray capacitance to be charged reliably to the "1" level then you can have the same thing happening.

Best regards, Spehro Pefhany

--
"it\'s the network..."                          "The Journey is the reward"
speff@interlog.com             Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog  Info for designers:  http://www.speff.com

It doesn't? Why not? As long as there is a reasonable value resistor, shouldn't the PIC be able to pull the pin all the way to ground?

Doh, I get it now. I wasn't looking at that end of things. ;-)

A *little* (blue ones are higher), and that's why the statement (above):

"Why does it work with a red LED, but not with a green one?"

--
  Keith

It's always the end you're not looking at that you get kicked in! ;-)

There's a bunch of other usefull stuff (much learned the hard way) in this thread too.

--
  Keith