Embedded hardware design for dummies

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.

Designers have yet another option to handle the 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.