While serial interfaces consume few MCU pins, they do consume time, and offer lower performance and slower response times than a parallel-interfaced (via the external memory bus) CPLD that provides the parallel ports that, in earlier days, might have been provided with "family" logic, i.e. decoders, registers, buffers, etc. The CPLD also offers some flexibility that it can be field-programmed, allowing for some changes.

With serially-interfaced hardware, you dedicate a few pins of the MCU's I/O resources, while, with the parallel interface, you allow the use of P2 and P0 during external bus cycles. If you are using those ports for other things as well, more resources are needed to guard against collisions. Port function can be registered externally, but and inputs can't be read in real time during external bus cycles anyway. P0 and P2 can be registered in your programmable logic. The may well have to be latched in order to perform a complete decode if there's much I/O. The external bus interface requires connections, not only to the MCU but to the CPLD as well. There's not much you can do to avoid losing those 18-20 pins on the CPLD. If you have considerable external I/O requirement, the CPLD may be the answer, but the package probably won't be small and convenient. A common 44-pin TQFP CPLD has only about 32 I/O's If 20 are used by the MCU interface, you only are left with 12. The smallest such CPLD's have only 32 registers. If you consume 24 of them for the MCU interface, that leaves only 8 for your port expansion ... well, you get the point, I'm sure.

The CPLD's that I've commonly used for 805x expansion have been tqfp-144's Those are thumbnail-sized parts. There are 100-pin parts, but, after all, we're trying to expand I/O's. CPLD's with a significant number of available pins aren't small, and they aren't cheap.

Programmable logic allows you to do lots of things that might be quite inconvenient with other approaches, but, they also allow you to make mistakes that can prove costly. You have to include resources to guard your P0 and P2 port I/O functions against collision with external bus hardware. This means you have to study out the precise details of the MCU you're using, as they don't all behave in exactly the same way where their external bus is involved. Some MCU's don't even support the "classic" external bus.

The obvious advantage of using an external-bus-interfaced parallel port is that the reads and writes to those resources happen right away, rather than a number of clocks, whether generated in hardware or firmware, later. The obvious disadvantage is the requirement for those extra resources required to protect the P0 and P2 functions that would otherwise be unhindered. As always, it's a tradeoff. If you can "live with" the delays imposed by serialized I/O expansion, that's probably less trouble, though it does involve more code. I like programmable hardware. It's pretty easy to use, but it's not the be-all-and end-all. Programmable logic does allow you to construct devices that you can't buy, though.

I suspect the hardware cost will turn out to be approximately the same in either the IIC or the CPLD case. If you buy someone's IIC solution, you're still going to have to buy the silicon-by-the-pound. From where I sit, there's nothing like writing to an I/O function and knowing that it's already over when the write cycle is over, and that the I/O read is as real-time as it can be.

RE