Through software, an MCU's features can come to the forefront with minimal design tradeoffs.

Feature creep and a tendency to maximize functionality within a compact microcontroller (MCU) often create problems for embedded system designers. Did you ever run into a situation where the application demanded multiple universal asynchronous receiver transmitters (UARTs), more than one serial peripheral interface (SPI) channel, and a few I/O pins? You zeroed in on a low pin-count MCU with the feature set you were looking for, only to later realize that everything about this design looked great until you started working on the schematic. Then you found out that one of the UART's pins was multiplexed (two functions on same pin) with another peripheral you were trying to use in the application.

If you've ever encountered this situation, you're not alone. The use of multiple serial channels is just one example. You'll find many design examples where two hardware peripheral features you need are actually mutually exclusive features, due to I/O pin multiplexing on the MCU.

All MCUs have their I/O pin-outs defined by the chip makers. These MCUs feature multiple functions multiplexed on their I/O pins. Especially complicated are the low pin-count devices, where it's common to see three or more functions multiplexed onto one pin. It's easy to see that this multiplexing leads to problems when allocating the MCU's resources in an embedded system, where the needed peripherals are found multiplexed on the same pins. Here, designers have some options: use higher pin count MCUs where the I/O lines are de-multiplexed; or use additional devices, such as multiplexers and extra glue logic, to get around these I/O line problems.

The third option is to implement one of the peripherals in software, such as bit-banging a UART through an I/O pin. With these workarounds, you'll end up with higher system costs. In addition, if you implement peripheral functions in software, it may result in lesser performance from the MCU, or higher power dissipation due to faster CPU operation.

I/O pin mapping in software
There's another interesting way to address this issue--letting the system designer define the MCU's pin-out. In other words, simply empower the designers to bring out the required functionality directly to the appropriate pins. Although it sounds revolutionary, the idea is a reality today. Flexible I/O pin mapping is available from a few MCU vendors.

The key challenge for MCU vendors in implementing flexible pin mapping is to offer the feature in a manner that avoids potential design violations. These violations could include defining two separate output functions onto the same pin, thus causing output short; or connecting two physical pins to same input function, causing bus contention.

Flexible I/O pin mapping is currently available in two flavors. The priority-encoding system shown in Figure 1 defines the MCU's I/O pin mapping in one approach. Here, the MCU's peripherals are graded by priority. The highest-priority peripheral takes the initial set of I/O pins, followed by the lower-priority peripherals that take up the remaining I/O pins in the configuration chain. This priority scheme avoids design violations by restricting only one function to each remappable pin, based on priority. The highest-priority function is fixed on one pin, while the lower-priority function can be moved to many pins. Usually, the pin assignment is controlled by some special function registers. Each function can be enabled or disabled with a control bit. If enabled, based on its priority compared with the priority of other functions, the function will show up on one pin.

View the full-size image