It has been a busy few days. I’ve been attending a number of trade and technology events, dealing with some of the less interesting parts of running a business, and preparing for a few more events during Belfast Tech Week next week.

Doing business in the UK at the moment is not particularly easy, although one of the advantages of being a very small business is that I can remain relatively compact and adapt quickly when necessary.

When I have managed to get some development time, most of it has been spent working on the UCMOD boards.

More importantly, I’ve started looking at UCMOD less as a collection of individual boards and more as a complete system.

That has resulted in a few changes.

Drawing a clearer boundary#

One of the main things I have been refining is the boundary between the UCMOD microcontroller modules and the carrier boards they plug into.

Earlier versions of some of the modules included external connectivity directly on the processing board. For example, the UCMOD-L-STM32 included a QWIIC connector.

I’ve now decided to remove that.

The reasoning is fairly straightforward: the microcontroller module should concentrate on providing the processing platform and the electrical interfaces defined by UCMOD. The carrier board should decide how those interfaces are exposed to the outside world.

In other words:

The processing module provides capabilities. The carrier board decides how those capabilities are used and exposed.

That sounds obvious when written down, but it has taken a few board revisions to arrive at a design that follows that principle consistently.

What belongs on the UCMOD module?#

The UCMOD processing module should contain the things required to make the microcontroller itself useful and reusable.

That includes the microcontroller, its required support circuitry, decoupling, reset circuitry and any programming or debugging interfaces.

For example, an STM32 module might include its SWD or Tag-Connect programming interface, while the ATtiny versions retain the appropriate UPDI programming connection.

The module then exposes GPIO and peripheral functions through the UCMOD connectors.

The important distinction is that the module exposes the microcontroller’s capabilities, rather than deciding how a finished system should physically connect to peripherals.

That means interfaces such as UART, SPI and I²C may be available electrically through the UCMOD connector without necessarily having a dedicated external connector on the processing module itself.

What belongs on the carrier?#

The carrier board is where the external connectivity lives.

Depending on the purpose of the carrier, that might include:

  • Standard 2.54 mm pitch pin headers and sockets
  • QWIIC JST connectors
  • PMOD connectors
  • RS485 interfaces
  • CAN bus interfaces (planned)
  • Fibre interfaces (planned)
  • Application-specific inputs and outputs

This also gives the carrier considerably more freedom.

A general-purpose development carrier might expose GPIO through headers while also providing QWIIC and PMOD connectivity.

An industrial communications carrier might instead concentrate on RS485 or CAN and expose relatively little general-purpose I/O.

A completely application-specific carrier may not expose conventional development connectors at all.

The UCMOD module itself does not need to know or care.

Why move QWIIC?#

QWIIC is a good example of why I’ve changed direction.

I like QWIIC. It is compact, uses readily available four-pin JST connectors and provides a convenient standard for connecting I²C peripherals.

But placing a QWIIC connector directly on the STM32 processing module makes an architectural decision that does not really belong there.

Not every application needs I²C peripherals.

Some carrier boards may need several QWIIC connectors.

Others may expose I²C through a normal pin header, an internal connector or not expose it externally at all.

Moving QWIIC to the carrier means the processing module remains useful in all of those situations.

The same reasoning applies to SPI.

I’ve recently been looking at PMOD as a useful existing standard for connecting SPI peripherals. Unlike QWIIC, which is primarily associated with I²C, PMOD gives me a reasonably well-established way of providing SPI connectivity while still using inexpensive 2.54 mm connectors.

Again, however, PMOD belongs on the carrier rather than the processing module.

Modules versus interfaces#

This has also helped clarify another aspect of UCMOD.

The microcontroller module and the interface circuitry should generally remain separate.

For example, the microcontroller may provide a UART suitable for communicating with an RS485 transceiver, but the RS485 transceiver belongs on the carrier.

Likewise, a CAN-capable microcontroller can expose its CAN peripheral through UCMOD, while the CAN transceiver and external bus connector remain part of the carrier.

Conceptually the arrangement looks something like this:

                 UCMOD Module
          ┌────────────────────────┐
          │ Microcontroller        │
          │ Support circuitry      │
          │ Reset                  │
          │ Programming / debug    │
          │                        │
          │ GPIO / SPI / I²C /     │
          │ UART / CAN / control   │
          └────────────┬───────────┘
                       │
                  UCMOD Interface
                       │
          ┌────────────▼───────────┐
          │      Carrier Board     │
          │                        │
          │ QWIIC                  │
          │ PMOD                   │
          │ 2.54 mm headers        │
          │ RS485                  │
          │ CAN (planned)          │
          │ Fibre (planned)        │
          │ Application I/O        │
          └────────────────────────┘

This should make the processing modules simpler, more reusable and less opinionated about the system they eventually become part of.

It should also make the carrier boards more useful.

Taking a few boards backwards#

The downside is that several boards have effectively gone backwards in the development process.

I’ve taken both some of the UCMOD modules and carrier boards back to the design stage so that these ideas can be incorporated properly rather than continuing with boards that I already know I would want to change later.

That is slightly frustrating, but this is exactly the point where making those changes is relatively cheap.

It is much better to change a PCB design now than discover after ordering fifty boards that a connector or feature really belonged somewhere else.

The system is still evolving, and part of the purpose of building these boards is to find those boundaries through actual implementation rather than attempting to design the entire specification on paper first.

Where UCMOD is heading#

The result is that UCMOD is gradually becoming easier to define.

The processing modules provide interchangeable microcontroller platforms.

The carrier boards provide connectivity, physical interfaces and application-specific functionality.

That should eventually allow something like an STM32, ATtiny or another compatible processing module to be selected independently from the carrier board providing the rest of the system.

There is still plenty to work out, particularly around the auxiliary connector, peripheral allocation and how interfaces such as PMOD should be mapped consistently across different microcontrollers.

Those will probably form the basis of a few upcoming articles.

Meanwhile…#

I’ve also started another small business activity called Ards Tech Fix, providing local IT and software support around Newtownards, Bangor, Comber and Dundonald.

It came about after a few requests for local technical help and gives me somewhere separate from Protoworks to provide that kind of service.

I will leave it at that here, since this site is primarily concerned with my engineering work, but if you’re local and need a techie, feel free to have a look.

For now, however, it is back to UCMOD.

Next on the list is continuing to refine the carrier design, looking more closely at PMOD support and turning some of the design decisions I’ve been making into clearer UCMOD rules rather than leaving them implicit in the individual boards.