Add Modular Plug-In Functionality To Any Embedded Design

Utilizing modularity in an embedded design opens up a number of new possibilities when compared to standard embedded applications. It enables the design of compact form-factor devices, without sacrificing functionality. Modularized embedded designs can be designed economically, because they can be tailored to the application—avoiding unnecessary functionality and cost. They’re also production-friendly, since they open up new diagnostic possibilities without requiring excessive additional resources on the device itself.

We can better understand this modularity by examining an embedded system comprising multiple modular extensions that perform unique tasks. The main controller can be programmed to act as a host that’s capable of recognizing and controlling a number of individual, modular plug-in cards. These cards then can perform a number of different functions, from sensing to communications.

In generic terms, a standalone embedded-system design comprises some of the following components: a computing block, a sensor block, a display element, a user interface, and some storage and connectivity options. Based on these function blocks, we can imagine a sample application where one or many of them are implemented modularly. To strike a balance between computing power and cost, a good host controller would be something like a 16- or 32-bit MCU.

As an example, we will examine a method for designing a versatile flash card reader application. This multifunction card reader will use flash-memory cards as the “plug-in modules” and utilize a small 16-bit MCU as the main controller. Cards, including Compact Flash (CF), Secure Digital (SD), eXtreme Digital (xD), and Memory Stick, can be read with this device. The interface requirement dictated by these various card formats suggests that we would need a minimum bus width of about 24 lines to guarantee compatibility with all card types.

On the connectivity side, we would also need the card reader to interface to a USB host, such as a PC. Note that a number of devices from various manufacturers are designed directly for these applications. While these are ideal when affordable, not every design has the budget for these application- specific chips, which are often large, high-speed ICs. Therefore, we will examine how the application can be done with lower-cost, general-purpose microcontrollers.

BUS FLEXIBILITY VS. PIN COST Any embedded design can support “modular plug-ins,” if it uses enough pins. Designers can tie pins of various peripherals from the controller together to obtain a bus with the necessary functionality. There’s a logical progression covering pins used and functionality obtained—using only two pins, designers can’t do much except provide power and ground to the plug-in card. Although these two pins needn’t come off the MCU, they can be brought out from the MCU if necessary to provide more control over the power to the card.

A bus with four I/O signals can assist designers in implementing a number of functions. These functions include a variety of serial communications, analog-to-digital conversion, and others. By using a six-line I/O bus, you will be able to address all types of serial communication requirements. (A parallel communication interface requires 10 lines or more.)

Using regular MCUs with fixed I/O pinouts, the schematics of this design may reveal that many of the peripherals needed for the card reader can actually be found multiplexed on the same pins of the MCU. While this sounds ideal, it’s more than likely that the multiplexing combination will not match the plug-in card pinout. Also, these I/O pins may be on an inconvenient side of the MCU, resulting in PCB routing problems.

One way to get around this problem is to use an expensive, high-pin-count MCU that’s rich in I/O lines, and thus there are no I/O placement restrictions (Fig. 1). However, you will be left with quite a few unused pins on a large-packaged MCU, which means wasted space and excess cost.

The other alternative is to use a compact MCU with fewer I/O pins, which uses a few multiplexers and glue logic to get the required bus width of 24 signal lines with the appropriate functionality (Fig. 2). Under this approach, the compact form factor of the design is the first casualty. Routing, carddetection logic, and firmware will also become complicated.

Designers have yet another option to handle this tangled I/O line problem. They can cluster the required I/O lines and implement the peripherals in software— SPI or UART functions can be bit-banged through I/O pins. This avoids the higher system costs from either the usage of a high-pin-count MCU or extra devices. Beware, though—when these peripheral functions are mimicked in software, the MCU performance may degrade or the design may dissipate more power due to faster CPU operation. As a result, you can still end up with a costly, complicated design.

Depending on the application (type of card inserted and detected), bootloading the code into the MCU can work well. This is accomplished by putting a small amount of flash memory, which has the new code, on the plug-in module itself or on a separate loader card. Other applications will require all or most of the cardhandling code to be already present in the MCU. This will allow for the smallest and cheapest possible plug-in cards, at the cost of using more flash memory on the MCU.

Continue on Page 2

FIXED AND FLEXIBLE I/O PINOUTS Many of the ills faced by compact and sophisticated embedded designs, such as a versatile card reader, can be traced to the fixed I/O pinouts of the MCUs. Previously, designers had no choice but to follow the MCU I/O pinouts defined by the vendors. Given the limitations in size and performance, it was natural that most MCUs featured multiple functions on their I/O pins in a multiplexed manner. On low-pincount MCUs, this multiplexing results in MCU resource-sharing problems—a common scenario where the required peripherals could be found multiplexed on the same I/O pins, rendering them mutually exclusive.

Now let’s flip the MCU I/O pinout problem on its head. How about making the I/O pinout on the MCU flexible? This feature will at once enable designers to route the needed functionality directly to the appropriate pins. Flexible I/O pin mapping today is available from a few MCU vendors. This flexibility allows us to reimagine the same card reader as a plug-in module based on an MCU that offers flexible I/O pin mapping, such as the Microchip PIC24FJ64GA004 MCU (Fig. 3).

To serve as a card-reader interface, a 24-line bus that caters to different types of storage cards can be brought out from the MCU. Using the flexible pinout feature, this design can be comfortably routed and implemented to handle a 24-line bus, as well as a USB interface to the host using a USB-toserial converter.

Using an MCU that offers flexible I/O pin mapping results in a simpler interface for a card-reader design that can handle multiple flash card formats. The beauty of this design rests on the fact that UART, I²C, SPI, and analog and parallel peripherals can all be made to communicate over the same bus, with minimal I/O pin investment. This allows for the use of MCUs in 28-pin or 44-pin versions and 8- by 8-mm packages or smaller to help conserve space. Higher-pin-count MCUs typically require 12- by 12-mm or larger packages.

HOW TO DETECT NEW CARDS To detect new cards presented to the main controller, you have to invest a few I/O lines to implement the functions of identification and safe insertion/removal of new plug-in cards. One option is to use serial communications to read an ID from the plug-in module. Another option is to detect certain pull-up and pull-down resistor combinations on the module. The third option is to use an analog-to-digital converter (ADC) to detect the change in value of a pull-up resistor—using different resistors for each board type.

An important aspect of plug-in functionality is safety first, at all times. Designers must ensure the safe insertion and removal of cards and prevent electrostatic discharge (ESD) when connecting and disconnecting the module from the main system. This can be done by removing power from the bus when the plug-in cards are idle.

Note that in our flash card reader example, the previously mentioned methods of card detection may not work. We’re limited to the specs of the flash cards themselves. So, how can card detection be done? In most cases, the cards’ specifications define the detection system. Secure Digital card sockets have a switch that makes a connection when inserting a card. Compact Flash has a card detect line that pulls a pin low when inserting a card. Note that these pins should be included in the card interface when specifying the bus width for each card type.

I/O PIN MAPPING—IMPLEMENTATION ISSUES Pin-remapping MCUs provide both low cost and high flexibility. Such MCUs are less restrictive as to what can be used on the plug-in port. MCU vendors have implemented the flexible I/O pin-mapping feature in different ways. Given the possible I/O pin-mapping permutations, such as one-to-many, many-to-one, or many-to-many, MCU vendors need to tread carefully. With the flexible I/O feature, it’s simple to define two separate output functions onto the same pin. However, this assignment can result in an output short. In another instance, a bus contention results when the designer mistakenly connects two physical pins to same input function.PRIORITY-BASED I/O PIN MAPPING In one method, the MCU’s flexible I/O pin mapping is subjected to a priority-encoding system. Here, each peripheral or function has a pre-defined priority. In this I/O pin-mapping system, the highest-priority MCU peripheral always occupies the initial sets of pins, followed by the lower-priority peripherals that claim the remaining pins, and so on down the configuration chain. This priority scheme avoids design violations by restricting only one function to one 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. Most commonly, the pin assignment is controlled by some Special Function Registers (SFRs). A control bit makes it possible to enable or disable a function. When enabled, a function—based on its priority in relation to the priority of other functions—will appear on one I/O pin.

While still more flexible than a fixed I/O MCU, this design approach limits the designer’s freedom to route I/O freely. That’s because you can only select from one of the many predefined MCU I/O pinouts.

MULTIPLEXER-BASED I/O PIN MAPPING In the other flexible-pin-mapping implementation, designers can route any input or output to any of the I/O pins. This approach relies on pin-definition interfaces based on SFRs. These hardware flexible-pin-mapping configuration registers prevent the aforementioned design violations, while allowing for true I/O remapping with one-to-many, many-to-one, or many-to-many relationships.

Some MCU vendors also provide the capability to prevent accidental changes to I/O configurations. To assist in this endeavor, the configuration register may be locked; it can only be unlocked for a small duration via a special key sequence. Some vendors provide an additional level of protection by shadowing the configuration and SFRs and constantly verifying hardware integrity. These measures help to prevent accidental I/O changes that can occur due to EMC events or abrupt power changes.

Continue on Page 3

BENEFITS OF FLEXIBLE I/O Flexible I/O remapping offers a number of other benefits beyond the previously mentioned multiplexing options. There are times when the vendor-defined pinout is sub-optimal for particular board layouts.

Take the example of an SD card slot that must be located at one end of the enclosure. This scenario demands the presence of an SPI channel and I/O pins on the same side of the MCU. If not, the trace routing on the PCB will be complicated. With flexible pin mapping, the MCU pinout can be defined to simplify PCB routing—possibly eliminating the need for a multilayer PCB and reducing system cost.

Designers can make creative use of flexible-pin-mapping features. For example, a debug tool can be conceived, based on flexible pin mapping. Routing the same signal to many peripherals makes it possible to insert software patches for debugging application code. By mapping an interrupt or input capture function onto a communication channel, bus communication can be monitored for specific events, such as glitches.

TOOLS ASSIST IN FLEXIBLE I/O MAPPING MCUs with flexible pin mapping have no default pinouts for the peripherals. Therefore, the firmware creator needs to initialize the pinouts to access the peripherals. In the case of multiplexerbased flexible pin mapping, after poweron reset, the pin-mapping function has its outputs disconnected and inputs mapped to a default register. To access any of the peripherals, the flexible-pinmapping registers must be initialized. Tools such as a Visual Device Initializer (VDI) help you initialize the peripherals and other MCU features.

For example, double-clicking the flexible- pin-mapping icon in Microchip’s VDI tool opens a drop-down window, which enables the designer to quickly set up the desired peripheral function and its corresponding pin(s) (Fig. 4). Besides assisting in the initialization of flexible pin mapping, the same VDI can help you initialize all of the MCU’s peripherals. After the pin assignment on the MCU is completed and peripherals initialized, the VDI will generate the necessary initialization code. Furthermore, a VDI can also be used to generate a resource usage report to supplement your design documentation.

When defining the required peripherals and their pin assignments, remember to assign the pins to the fixed analog and digital functions at the outset— many times, not all functions are remappable. Analog functions and some large peripherals, such as the parallel port, usually will contain fixed I/O lines. Therefore, you should utilize the fixed pins as the base of the bus and map the necessary serial functions onto these pins when needed.

CONCLUSION Embedded designs with plug-in functionality require a flexible I/O interface. In the past, these applications required a larger MCU package to be able to access the exact peripheral set on an MCU. Or, they had to resort to extra multiplexing devices. When both of these approaches failed, designers had to recreate the peripheral function in software. These workarounds ultimately increased design costs and development time.

Software-based flexible I/O pin mapping is the answer to this vexing design issue. It gives designers access to the exact peripheral set they need on an microcontroller. With these softwarebased, flexible-pin-mapping features, a designer will be able to utilize a smaller, cheaper microcontroller in a compact package to design efficient, modular plug-in embedded systems at economical costs.