Per,

It would be helpful to know whether the main 3.3V MCU already has enough I/O pins that can be assigned 1::1 to the signal pins on the ribbon cable. If so how many pins are you talking about?

Clearly the desire to support toggling rates of the pins on the cable of up to 5MHz implies that you want almost direct software control of the pins instead of having them remoted behind some type of serial interface such as SPI or I²C.

As I had suggested in the previous thread that you linked, you may want to consider the use of a small FPGA type device. These parts often have I/O pins that can be programmed to a slew of different I/O protocols including voltage threshold levels, I/O modes, selectable pullup/pulldown and so forth. An FPGA type part is "programmable" in that you can select its operational characteristics based on the "image" that gets loaded into the part at startup.

I suspect that you do not need actual pin-by-pin configurability because you know the universe of devices that can connect to this ribbon cable connector. Even with 20 or 25 legal devices the number of I/O configurations needed to support them is 20 or 25. This is much much less than the number of configurations of a handful of I/Os that can each be programmed to support say 4 or 5 modes each. So you could support each device type on the cable with a FPGA program image that the has the correct I/O pin setup. In general the small FPGA would simply become a specialty transceiver between your MCU and the device on the cable. Your various drivers in software would toggle and monitor MCU I/O pins as appropriate for each device type and the external FPGA, which has been setup ahead of time, will translate the I/Os as appropriate.

FPGAs also support to concept of banks of I/O pins that are powered from a design time selection of a particular voltage range. You could consider making the I/O bank rail voltage switchable via an external FET circuit so that you could actually support devices that were 3.3V or 5V.

Another thing to consider is that once you inject an FPGA into the middle of things you have the option of adding logic inside that can off load certain functionality of the device protocol on the ribbon cable and let the hosting MCU have an easier job. For example the FPGA could support making a PWM signal or scanning a small key matrix or even implement a simple serial protocol.

One thing to consider here is that in the FPGA world much the same thing has happened as has occurred in the MCU space. The parts available that still support 5V I/O are becoming less and less. A quick search will find that many part families that are even now considered mature parts are supporting I/O bank rail voltages of up to 3.3V.

It does also beg a discussion about the reason why you have to stay with 5V devices on this cable connection of yours. You may want to take a hard look at that and drive toward having a family of devices that instead work at 3.3V. Hanging onto your old legacy 5V devices and designing to that could end up being a mill stone around your neck as the future comes along. It could get to be hard to get parts to continue to build those legacy devices. Also invariably there will be a time when new device types will be wanted and you'd like to have the option to design those to work with the parts available at that time.

Michael Karas