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.
Designers must be careful while assigning pins in software. They need to assign the highest-priority pins first. If you assign lower-priority pins first, then their locations will change as higher-priority functions are enabled. This is a somewhat restricted way of I/O pin mapping.
“Pick and place” I/O pin mapping
In the other approach, designers have the freedom to route any I/O to any of the remappable I/O pins. This more flexible approach avoids the priority problems I described and relies on a unique pin-definition interface, based on flexible pin-mapping configuration registers. Designers also get more help from the configuration tool, which alerts them to the listed design violations while enabling true I/O remapping with one-to-many, many-to-one, or many-to-many relationships.
Being very flexible, this kind of pin-mapping scheme still needs to be deployed with care, to avoid potential design violations. You can avoid design violations by using a unique pin-definition interface, which helps guard against design violations. For example, to avoid two outputs appearing on one pin, the register configuration is based on defining the function for each pin. As shown in Figure 2, the output on each pin is defined by a coded value in the Special Function Register (SFR). Each value of this bit combination defines one output function. That is, a value of “3” may specify the UART 1 Tx output function, while a value of “7” may specify the SDO line output for SPI. You can only define one value per pin, thereby preventing two outputs from appearing on one pin, while still allowing for the possibility of outputting the same function on multiple pins.
The input assignment shown in Figure 3 works the opposite way–the register configuration is based on assigning a pin to each function. For example, an input pin name for the UART Rx pin may be controlled by a coded value in the SFR. Each value of this bit combination may specify one remappable pin; a “0” value may specify the RP0 pin, a “1” may specify the RP1 pin, and so on. This register interface prevents the assignment of two different pins to one function, as the SFR control bits can only have one value at any given time.
Some MCU vendors also provide the ability to prevent accidental changes to the I/O configurations. To assist in this endeavor, these configuration registers may be locked and can only be unlocked for a small duration through a special key sequence. Some vendors provide an additional level of protection to prevent accidental I/O changes during an EMC event, by creating an inverted copy of all configuration bit registers and running a constant integrity check on the hardware by comparing this copy with the original value. The EMC event will try to corrupt all bits, either toward logic high or low. Therefore, this complimentary bit checking gives solid protection.
On MCUs with flexible pin mapping, peripherals don't have default pin-outs. Hence, you must initialize pin-outs before peripherals can be used. In the register-based flexible pin-mapping feature, after power up, the pin-mapping function comes out of reset with all outputs disconnected and all inputs mapped to a default register. Therefore, to access any peripheral, the flexible pin mapping registers must be initialized. Tools such as a Visual Device Initializer (VDI) provide graphical support for setting up many of the peripherals and other features on the vendor's MCUs. Double clicking the flexible pin-mapping icon in the VDI tool opens a drop-down window that lets designers easily set up the desired peripheral function and pin mapping. After completing the pin assignment on the MCU and initializing the peripherals, the VDI will generate the necessary code. A VDI tool can also generate a pin and interrupt usage report, to supplement the design documentation.
All analog functions and large peripherals, such as the parallel port, are also fixed. When making your function and pin assignments, remember to first assign the pins to the fixed analog and digital functions. Once this is done, you can assign the remappable functions and the port pins can be assigned to the remaining I/O.
Use flexible I/O
There are many advantages to using flexible I/O pin mapping, besides those defined earlier. A case in point: the vendor-defined pin-out may not be suitable for every system placement. Consider a wireless transceiver, which may have to be physically located at a different side of the final product (when compared with the SPI connection on the MCU that controls it). To meet this requirement, it's necessary to have the SPI channel and I/O pins on the same side of the MCU, otherwise the pc board routing will be complicated. Using a multiplexer-based flexible pin-mapping feature, you can appropriately define the peripheral's pin-out to reduce trace lengths and vias. This may simplify the pc board routing and may eliminate a few board layers, thus reducing the pc board's cost. The shorter trace, without vias, can also help to reduce EMI/ EMC problems.
In applications where the PWM controls the low-impedance load, you may need more current than the I/O pin's available drive strength. With multiplexer-based flexible pin mapping, it's possible to increase the drive strength for a particular peripheral signal by outputting the same signal on multiple pins and thus putting multiple I/O pin drivers in parallel. This reduces the need for an external driver circuit, further reducing the size and cost of the system.
By routing the same signal to many peripherals, designers can insert software patches for debugging application code and take remedial action on the existing prototype, where necessary. One way to do this is to use multiplexer-based flexible pin mapping to map the interrupt or input-capture function on the communication channel. This lets the designer monitor bus communication for custom events, such as glitches. In this way, multiplexer-based flexible pin mapping becomes a useful debug tool.
On-the-fly pin mapping
The earlier examples detailed the advantages of “pick-and-place” (or multiplexer-based) flexible pin mapping in software, under preprogrammed MCU conditions. This pin-mapping approach is so flexible that it can be invoked dynamically.
Let's analyze one such example. Unlike a synchronous SPI interface, the UART relies on asynchronous connections. These devices need both receive and transmit signals. In low-cost embedded applications, the absence of chip-select signals in UARTs restricts the options designers have in providing communication flexibility. One can find various peripheral devices with a UART interface. If the system has four such peripherals and one MCU, it will need four hardware UART modules on the MCU–even if all UARTs aren't used simultaneously. This is a common design problem, and there are a few conventional ways to solve it.
In the first approach, designers can use a hardware multiplexer chip to time multiplex one hardware UART module to four UART-enabled peripherals. This can be achieved by controlling the external MUX with some MCU I/O lines. In the second approach, designers can implement communication with multiple UART devices by using a large MCU that has four hardware UART modules. This large MCU may be overkill for the application. However, it's difficult to find a compact, cost-effective MCU with four hardware UART modules. With both examples, we'll end up with a less than optimal system cost and, most likely, a larger system footprint–either due to external glue logic or a larger MCU package.
Once again, multiplexer-based, on-the-fly flexible pin mapping of digital I/O pins can solve these design issues. UART communication isn't a master/slave type of communication. Instead, it's a one-on-one connection, with both sides being able to communicate at any time. However, many peripheral devices work in the slave mode. That is, they don't initiate communication on their own. Instead, they wait for the host MCU to send commands. It's easier to handle these devices by time-multiplexing the UART.
As shown in Figure 4, the four UART-based peripherals are connected to remappable pins on the MCU. The control program will dynamically map a UART in hardware to these four pin sets, based on the application's need. The multiple-UART interface works as follows: when the application wants to talk to device 1, the program will map the hardware UART to the RP1 and RP2 pins. This mapping is done by changing the pin-mapping registers, communicating with the device and getting all of the required data. When the MCU wants to talk to device 2, the program will map the hardware UART to the RP3 and RP4 pins, by changing flexible pin mapping registers, and so on.
If the MCUs with UART peripherals are a combination of slave devices and also need one asynchronous channel to receive data at any point, you have a few options. Usually these kinds of MCUs have two hardware UART modules. One of the hardware UART modules can be an asynchronous communication channel, and the second can be used for time multiplexing–to create multiple hardware UART modules.
If you're one of those designers who really likes to push the envelope, and have a need for both multiple asynchronous channels and multiple slave channels, a multiplexer-based flexible pin-mapping scheme can help you. If an MCU's asynchronous channel has a handshaking capability (Data Terminal Ready [DTR]/ Clear To Send [CTS]), you can use those signals to hold the asynchronous channel while you map the UART back to the original pin.
Another option is to map an edge interrupt or an input-capture signal onto the inactive UART receive pin. If another device starts an asynchronous transfer, the MCU will be interrupted. It can immediately switch the hardware UART module to the appropriate pins to receive data. The pins can be remapped in microseconds, depending on the MCU's speed. This should pose no problems, because most UART communication takes place at slower speeds. Therefore, a hardware UART will still be able to receive that data. This solution may not work for some special systems that need all UARTs to be asynchronous channels.
Gaurang Kavaiya is an engineering group manager of applications in the Advanced Microcontroller Architecture Division at Microchip Technology Inc. He received his BSEE degree from Gujarat University (India). Gaurang can be reached at .