[Design View / Design Solution]
Add Modular Plug-In Functionality To Any Embedded Design
By taking advantage of the latest 16-bit MCUs that offer flexible I/O pin mapping, designers can conceive efficient embedded designs by taking the modular plug-in approach.
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.
Reprints
