I often see people label the read-modify-write behavior on I/O ports as a
'bug' or 'problem'. That would imply something is wrong that needs to be
fixed. The read-modify-write behavior on I/O ports cannot, in my opinion, be
called a bug or problem because it's my understanding that its behavior was
*intentionally* designed into the PIC architecture. Think about it this way:
if it were truly a silicon bug, Microchip would have fixed it *eons* ago.

For anyone thinking it was simply just a carry-over bug from the earliest
baseline architecture I offer this: Microchip could have addressed this
behavior on new architectures like the PIC18 and dsPIC, but the
read-modify-write behavior on I/O ports is still there in these newer
architectures. My rhetorical question would be: Why is that? For
backward-compatibility? I don't think so. Why would they re-introduce a
"bug" into new architectures for backward-compatibility. There is no
evidence that I've seen (or heard about) that indicates the
read-modify-write behavior on I/O ports was none other than by deliberate
design, and therefore not a bug. Perhaps I'm dead wrong about this, but I
don't thinks so -- however I would gladly stand corrected if evidence to the
contrary surfaced.

If users do not take this read-modify-write behavior or effect (as it
applies to I/O ports) properly into consideration when they design, then the
behavior can cause a problem, but I don't think it is fair to label it as a
bug or problem. There's plenty of documentation in data sheets and reference
manuals that go into detail about the read-modify-write behavior on I/O
ports. Microchip has always done a good job, in my opinion, at documenting
the ramifications of read-modify-write instructions on I/O ports -- as far
back as I can remember (even back on the classic baseline ('5X) chips).

Best regards,

Ken Pergola

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email listserv@mitvma.mit.edu with SET PICList DIGEST in the body