problem with toggle command

[HenrikOlsson]

How else could it work? If it's supposed to toggle a bit it needs to know what state that bit is currently in, right?

[INVTLG]

Henrik,
Well, I guess I don't have to know If I just add 1 to whatever is there, so why should it have to know? - just kidding
From your original answer, I see that you obviously understand the inner workings of these microcontrollers & what the compiler is doing behind the scenes. I do not, & my last comment about the 2nd part of SUNFLOWER's answer is just this very thing; before I read your answer, I might think that somehow it could just add 1 to whatever is there.

[HenrikOlsson]

Exactly, when you think about it for a bit you'll realise that even PortA.1 = PortA.1 + 1 won't work because of the exact same reason and in this case it's even more "obvious" than with the TOGGLE command because here you have it spelled out. You're telling the compiler to read the state of PortA.1, add 1 to it and write it back. If, when Reading PortA.1 it always reads high because it's got its digital buffer disabled then it will work just as bad as TOGGLE will.

On top of that you should know that ALL bit operations are executed as Read-Modify-Write by the internal PIC hardware, has nothing to do with the compiler. So, if you're using some pins on PortA as digital outputs but you don't bother to enable the digital buffers and then you do something simple like PortA.0 = 1 what will happen is that the PIC (ie the actual processor) will read all 8 bits from PortA, set bit 0 and write all 8 bits back to the Port register and the state of "the other" pins might change "unexpectedly".

So, whenever you get "weird" results on any I/O pins, even if you're not actually writing to that specific pin you should always think about the analog peripherals.

And again, on the device with LAT register you should use those instead of port since they're pretty much unaffected by RMW issues, no matter the actual cause.

/Henrik.