RPi_HAT_Config

This is how I design systems, at least at the moment. For me, the hardest part of creating a system design with things like MCUs where there are multiple functions for each pin. You have sometimes six or seven different options and many times there are other connected interdependencies for using one particular function. Pin configuration for an MCU can be done (sometimes) with tools provided by a vendor, but that doesn't really help much with overall system design. Things like assigning consecutive bits on a port to consecutive pins is important, but it gets complicated quickly when doing systems with more IO involved.

So, what I do is map out all the major pins that need to be connected, start assigning those functions that are most limited availability, and then rinse and repeat until all connections are made. Yes, you *could* do this in the schematic, but how do you verify that you haven't used a given function already or duplicated a net name? On more simple designs, this is overkill, but even this one benefits from this approach.

OK, what was the outcome of the configuration? What were the tradeoffs to stay within our target? One item was I2C. Ideally, I would put some sort of multiplexing on the I2C bus so that each IO module gets a separate interface to the bus. This allows using more than one of a sensor that has a fixed address. One on each IO module. Well, the MCU only has one I2C bus, it is a lower pin count part. *But*, it does have two different I2C implementations for the same bus. This means that two pins can be configured to be I2C_SCL. So, what I've done is used both of those pins and only connected them directly to each IO module. This should allow for me to reassign the functionality and address each IO module as needed. Yes, there is setup and teardown to do, so there is some overhead. This isn't too different from a separate I2C multiplexing IC addressed on I2C.

What other considerations were there? SPI, it looks like we should be OK, if the Pi is in place and is interfacing via SPI, it will be the master, otherwise, the KE02 will be the master. Faced with the limitation of a 44-pin KE02, I started with connecting between the IO modules first, and then used what was left over to interface as much directly to the Pi. The result is not a 100% pin coverage between the IO module pins. Instead, we have UART TX/RX, SWD + Reset, and two additional GPIO pins connected between the Pi and the KE02. This allows for options on how to send data back and forth, plus either interrupt lines or possibly a parallel data interface. The SWD + Reset gives us a direct way to program and debug the KE02 via OpenOCD on the Pi.

Most likely, the KE02 could either run a generic interface program with configuration and data is sent via SPI or UART or it could be programmed with specific behavior and then either run independent of the Pi (a lightweight stand-alone app) or be able to interface on any of the connections. Technically, you could even use SWD to do some direct memory polling or something like that, but I don't know how practical that is.

That is the core system design, next up is the schematic layout and then PCB layout.