What I pointed out was that when you write to the i8255, the data is "out there" now, i.e. within a cycle. With the serialized methods, e.g IIC, it has some latency. Now that's not a bad thing, at least not in all cases. However, there are some things it (i8255) will do that serialized comm's won't, namely tightly-coupled data transfers with handshaking. The 8255 behaves more or less (somewhat less, I have to say) like the port on an 805x-core MCU. If you compare that with any "standard" 805x-core MCU (none of which support IIC, SPI, etc.) it means that you have to bit-bang the IIC/SPI. Just how fast can you do that on a "standard" 805x-core MCU?

Let's not get tied up in this matter. IIC and SPI are not the same thing as parallel I/O and never will be, simply because of the latency imposed by serial communication between the MCU and the target device. Serial I/O is not the way to talk to code memory, and it's not the way to talk to parallel I/O.

If you want to discuss ways of attaching an 8255 to a non-standard MCU, there are many ways, and these certainly allow the data to be moved while waiting for time to pass. There are lots of tricks that can be used to accomplish fast data transfers, all dependent on the features of a given MCU. The Maxim/Dallas parts, for example, have an auto-increment mode for the DPTR. If you have data blocks to transfer in sync with an external peripheral, which does happen from time to time, you can set the data buffer such that you need simply monitor the DPH for a specific value, just for one example, and that will disclose when the transfer is completed. You can set the DPTR mode such that it increments one DPTR and not the other, using one DPTR as a source pointer and the other as destination pointer, (I havent yet tried this) so it moves data from a variable buffer location to a fixed external port or vice-versa. You can even set the external memory cycle length so it's different from the last time you went "external." Thta way, you can access an external port with a stretched cycle, while operating the core at full speed, fetching data from the internal XRAM buffer.

The whole point of the initial discussion was how to expand I/O, in a general sense. Jan mentioned SSI/MSI approaches, and, of course, the 8255 came up, though immediately in the "don't do this" context.

As I've said, I don't particularly like the 8255, because its outputs are weak. I like SSI/MSI logic, and I like CPLD's that have comparable I/O current.

These ST (formerly WSI) devices look like a possible way, but I doubt they're cheap and ubiquitous, particularly in Asia.

I think the question of expanding I/O deserves a thorough treatment, perhaps in a plurality of FAQ's, as has been suggested. It does require a rational discussion by people whose answer to, "I need more I/O than my particular MCU offers. How should I provide it?" is something other than "Buy a different MCU." That's just not always an option. It has to be answered in the context of "I have three days and little money."

RE