The last few days have been looking at the pin configuration of a system that ran the Pi pins directly to a module header with analog pins provided by an MCU. Not that the whole time was spent on this, but more doing some planning and then digesting the limitations of different options. It ended up to do a 4-module design, it would need a 64-pin package MCU to provide all the support (2 modules completely on the MCU and support for the other 2 modules that are mostly handled by the Pi). This starts pushing up the complexity of the design and also the cost of it, somewhere that is outside of the ideal solution space.

So, I stepped back and considered what are the design goals. One option is to go for a 4-module design but to limit it when connected to existing connector boards (remove system pins, etc.). The problem with this is implementing a non-standard pinout of the modular controller connector kind of defeats the purpose of having a standard. The other option was to re-assess the benefits of hooking up the Pi to a system like this and see if there was some design in the middle that really put some benefits back into it over just the existing controller modules.

The current (final) design direction for this project is this:

1. Create a 2-IO Module compatible design that is a Raspberry Pi HAT.
2. Instead of creating an adapter module that works as a controller module, create a combined controller-connector module that integrates an MCU that acts both as an intelligent buffer between the Pi and the IO modules as well as extends the Pi with ADC and other facilities.
3. Keep the total retail pricing at $10, which means we want a BOM cost of something like $2.5.
4. Use a 5V and ESD tolerant part, like the KE series to protect the Pi from things that would normally damage it.
5. Create a powered and unpowered variant.
6. Make sure it is compatible with extended modules, like the POE power module, since, well, that fits really well with the Pi as a network powered installation.

Now that the design is more at a system level, it is not as important to do the pin connections first, but to look at the board level configuration. I've started with creating a full HAT sized board and put an assembly together that has the features required to look at spacing of things and to consider the overall use case. That gives us a direction to help define the system inputs and outputs which then defines the requirements of things like the MCU. OK, time to go hash that out.