16F627A PortA.4 trouble?

[Gusse]

Or try something like

TempByteA VAR BYTE
TempByteA.1 = LED.1
TempByteA.2 = LED.2
'etc
PortA = TempByteA
'etc

This is working workaround for the issue. Thanks!

When you do several concecutive bit operations like you're doing there is a possibillity that the actul voltage at "previous" pin hasn't actually reached the threshold voltage for the logic level that previous command set it to. So when the PIC performs the read it actually reads a high even though the previous command set it low. And because it reads a high that is what get written back to port.

If you'd perform several concecutive byte writes to the port it's likely you'll see the same effect.

I haven't seen that kind of issues before and with current project the A.4 was failing in bit-mode. Even if A.4 was moved to be first port operation, it still failed.

Hi Robert,
The effect is increased due to several reasons. In a perfect world there wouldn't be an issue but due to capacitive loading on the pins etc the effect increases as the speed goes up. Some PICs (the larger ones) may not have the +/25mA drive capacity on the port pins so there it'll take even longer to "charge" to external capacitance and bring the voltage up.

18F devices and I believe the newer 16Fxxxx devices have LAT registers associated with each port. Writing to LATx instead of PORTx bypasses the issue completely because the inherent RMW operation is then performed against the LAT (which is the port latch register) instead of the actual port pins.

All port that I use are driving high impedance load, P-FET gate (+ 56k pull-up to VCC), so definitively ports are not heavily loaded.
I think this i a real bug, but don't know is it in PBP or somewhere else.