Defining the UCMOD Auxiliary Connector

Today I decided to define the UCMOD Auxiliary Connector layout.

UCMOD Connector#

As a prelude to designing the UCMOD Auxiliary Connector, here is the current pinout definition for the existing main UCMOD connector.

There are 12 GPIO pins available through the standard UCMOD connector, with a defined primary function assigned to each where appropriate. These include I2C, UART, SPI and four analogue-capable pins.

The format is therefore simply Primary Function / Generic GPIO Number.

This does not guarantee that every primary function will be available on every UCMOD module. Different microcontrollers provide different peripherals and pin-mapping options. Instead, the intention is that where a microcontroller provides a compatible peripheral, that peripheral should be mapped to the corresponding pin on the UCMOD connector wherever possible.

For example, the microcontroller pin connected to UCMOD pin 5 should support I2C_SCL where possible, while also being capable of operating as a normal GPIO.

This defines how functionality is mapped from the microcontroller onto the UCMOD connector; it does not require a carrier board to use that pin for its primary function.

If a carrier board does not require a particular peripheral, the corresponding pin may instead be configured by the microcontroller firmware as a general-purpose I/O pin, provided that the microcontroller pin selected for the primary function can also operate as a normal GPIO.

For example, a UCMOD module may map an I2C-capable microcontroller pin to I2C_SCL / GPIO0. A carrier board which uses I2C can therefore rely on finding SCL at that location, while another carrier board which does not require I2C may use the same connection as GPIO0.

This allows the standard peripheral mappings to remain predictable without unnecessarily reserving pins on carrier boards which do not use those peripherals.

Microcontroller Alternate Functions#

Many modern microcontrollers allow a single physical pin to provide several peripheral functions. These alternate functions are a property of the microcontroller and are not represented as secondary functions within the UCMOD connector definition.

Instead, every UCMOD signal position has one defined primary function, together with its GPIO fallback.

Where a microcontroller pin provides another useful function, that function should be exposed through its own appropriate UCMOD pin wherever possible.

For example, if a microcontroller pin can operate as both an analogue input and a DAC output, the analogue function may be connected to one of the standard AN positions while the DAC function can be exposed separately, potentially through one of the UNIQUE positions on the Auxiliary Connector.

There is one important rule I want to establish for UCMOD modules:

A physical microcontroller pin should normally map to exactly one UCMOD signal position. Multiple UCMOD positions connected to the same microcontroller pin are an exceptional implementation and must be explicitly documented, preferably using configurable links rather than permanent electrical connections.

This is important because two UCMOD connector positions should normally be assumed to represent independent electrical signals. Permanently connecting both positions to the same microcontroller pin could create unexpected behaviour if a carrier board attempted to drive, configure or otherwise use those signals independently.

There may still be cases where a useful peripheral function is available only on a microcontroller pin which has already been mapped to another UCMOD position. In those situations, the module may expose the same physical microcontroller pin at an additional UCMOD position, but this should be treated as an exception rather than normal practice.

Where practical, this alternative mapping should be configurable using something such as a 0 Ω link or solder bridge. This allows the module designer to expose the additional function without permanently making two UCMOD positions electrically identical.

If a permanent shared connection is unavoidable, the affected connector positions must be clearly identified as aliases in the module’s schematic, pinout and documentation so that carrier-board designers know that the signals cannot be treated independently.

This approach keeps the UCMOD connector definition simple while still allowing modules to expose useful alternate functions provided by more capable microcontrollers.

A good example is the STM32G0B1CBT6. Its VREF+ signal is provided by a dedicated microcontroller pin rather than sharing a GPIO or analogue-input pin. Under the revised UCMOD convention, VREF is therefore not listed as an alternate function of one of the standard analogue pins. If a particular STM32G0 UCMOD module needs to expose VREF+, it can instead assign it to a suitable UNIQUE position on the Auxiliary Connector.

This is an important part of the UCMOD design: the connector defines where compatible functionality should appear, but it does not attempt to reproduce every alternate-function combination available internally on a particular microcontroller.

UCMOD Auxiliary Connector#

The UCMOD Auxiliary Connector follows the same convention as the main UCMOD connector. Each signal pin has one defined primary function and, where appropriate, may alternatively be used as a GPIO.

The Auxiliary Connector provides standard locations for an additional UART, I2C and SPI interface, along with an auxiliary interrupt signal and CAN transmit and receive signals.

The AUX prefix means that these are additional interfaces beyond those provided by the main UCMOD connector. It does not mean that they are secondary or lower-priority functions of the individual connector pins.

Pins 12 through 16 are deliberately different. Where the primary function is listed as UNIQUE, a peripheral or other function specific to that particular microcontroller may be mapped to the pin.

If the carrier board does not require that function, the pin may instead be used as the corresponding GPIO, provided the underlying microcontroller pin supports GPIO operation.

For example, one UCMOD module might expose a DAC output on one of these pins, while another might expose VREF, a timer output, USB-related signal, additional communication peripheral or some other capability specific to that microcontroller.

This flexibility comes with a trade-off. A carrier board which depends on a particular UNIQUE function risks becoming tied to the UCMOD module, or family of modules, which provides it. Carrier boards intended to remain broadly interchangeable should therefore use these pins as GPIOs unless they deliberately require functionality provided by a particular microcontroller.

I’ve also defined pins 17 and 19 as AUX_CAN_TX and AUX_CAN_RX. This keeps the UCMOD definition independent of whether the underlying microcontroller implements classical CAN, CAN FD or another compatible CAN controller implementation.

General UCMOD Design Philosophy#

The general UCMOD design philosophy is to provide a flexible interface between a microcontroller module and a carrier board, allowing microcontroller modules to be swapped without requiring the carrier board to be completely redesigned.

It is intended that the UCMOD interface can be implemented by a wide range of devices, from small 8-bit microcontrollers through to considerably more capable 32-bit microcontrollers.

However, UCMOD is not intended to remove the developer’s responsibility to understand the microcontroller being used.

UCMOD standardises where capabilities appear; it does not standardise the capabilities of the microcontroller itself.

It also does not attempt to expose the internal alternate-function mapping of every supported microcontroller through the connector definition itself.

Instead, each UCMOD pin has a clearly defined role. The individual UCMOD module is then responsible for mapping suitable microcontroller pins onto those roles.

As a general rule, there should be a one-to-one relationship between a physical microcontroller pin and a UCMOD signal position. This helps ensure that connector positions which appear independent to a carrier-board designer really are independent.

Where a microcontroller provides several useful functions on the same physical pin, the preferred approach is to select the most appropriate UCMOD mapping and expose other functions through different microcontroller pins where possible.

Only when that is not possible should the same physical microcontroller pin appear at multiple UCMOD positions. Such aliases are an implementation detail of the individual module, must be clearly documented, and should preferably be controlled using configurable links rather than being permanently wired together.

A developer still needs to know which peripherals a particular microcontroller provides, which UCMOD functions are implemented by a particular module, and any electrical or peripheral limitations associated with that device.

The advantage is that if both a microcontroller module and a carrier board implement a standard UCMOD function, they already agree on where that functionality should appear.

That should make it much easier to design reusable carrier boards while still allowing different UCMOD modules to take advantage of the capabilities of their underlying microcontrollers.

Next Steps#

I’m generally happy with the design of the Auxiliary Connector.

I did consider making it completely freeform, allowing each carrier board and UCMOD module to define its own auxiliary pinout. However, I think having a standard definition is considerably more useful, even if some pins remain unused on smaller microcontrollers.

Most larger microcontrollers provide multiple UART, I2C and SPI peripherals, and often CAN as well. The main interfaces can therefore be mapped to the standard UCMOD connector, while additional interfaces can be exposed through the Auxiliary Connector.

The UNIQUE pins then provide an escape hatch for useful functionality that doesn’t fit neatly into the common UCMOD peripheral definitions.

My next problem is mechanical rather than electrical: ensuring that UCMOD boards conform to standard board dimensions and connector locations so that modules can be physically swapped in and out as needed.

At the moment, I’m primarily thinking in terms of two form factors: small (implementing just the UCMOD connector) and large (implementing both the UCMOD and Auxiliary connectors).

The small form factor would be intended for relatively compact microcontrollers such as the ATtiny1614 and CH32V003/4/5, while the larger form factor would accommodate devices such as the STM32G0B1CBT6, ESP32-C6/S3, RP2040 and GD32V series.

Once those dimensions and connector locations are standardised, the electrical and mechanical parts of the UCMOD specification should start to come together into a much more clearly defined platform.