Kristian Hoffmann

March 15, 2004

Hardware and Software Considerations for Building Embedded Systems

Embedded systems are everywhere. They are in everything from traffic signals to cell phones, and even your favorite game console. Despite the neat boxes that they sometimes come in, embedded systems are nothing more than small, purpose built, computers. And even though it may seem like a hard field to get in to, there is an overwhelming abundance of off the shelf hardware and freely available software for embedded systems. However, there are a few considerations that should be made when designing embedded systems. The goal of this paper is to be an overview of what's out there, decent guidelines for putting together your own, and common pitfalls that should be avoided when dealing with and building embedded systems.

The first task that should be in mind is picking the right hardware for the job. Unfortunately, 'because it looks cool' isn't a reasonable criteria. Factors like size, the intended environment, and architecture are some of the major aspects to consider when choosing embedded hardware. Starting with size, one has to really think about how and where the device is going to be used. There happens to be a complete range of sizes available in the embedded hardware market. The most familiar would probably be Flex or Micro ATX. These are smaller versions of the commonly used standard or Mini ATX PC form factors. While most people wouldn't consider these for embedded hardware, one might be surprising at how many embedded devices there are out on the market that are just Micro ATX systems in a fancy box. The ATX family of boards are almost always built using the Intel x86 architecture making software development much easier. Moving down in size comes a new form factor released by VIA Technologies Inc. (www.via.com.tw) called Mini ITX. This board design may restrict the size to 17cm by 17cm, but it does not restrict the features. Even the mid-range Mini ITX boards usually come with 1GHz+ processors, multimedia encoders/decoders, as well as all or more of the I/O capabilities¹ commonly found on high-end desktop PCs. All of these boards have the added bonus of being able to double as desktop PC boards which means there is almost no learning curve for those familiar with standard PC hardware.

The next group is comprised of familiar hardware that has been reshaped to fit a particular need in the embedded world. For example, single board computers, or SBCs, come in form factors like ISA, PCI, PCISA, PICMG² , and PC/104+³ . Without going into too much detail, these boards are all variations of the original ISA and PCI buses. As the name would suggest, instead of a single board containing only one peripheral device, it contains all the components normally found on a PC motherboard. The single edge connector (except for PC/104+) connects the SBC to a backplane containing other peripheral devices. The PC/104+ standard is unique in that instead of having a normal edge connector, it has an array of pins both on top and bottom. This makes PC/104+ devices stackable, and thus, very compact and customizable. Some of the smallest off the shelf components are the system on module (SoM) or system on chip (SoC) devices. These embedded systems are condensed into mere chips ranging in size from the larger DIMM (standard PC memory) form factor, to SODIMM (similar to laptop memory), and even smaller. These tend to be trickier to deal with because their only link to the outside world is through a proprietary series of pins on an edge connector. It may be necessary to break out a soldering iron to do something as simple as plug a serial cable into one of these. Even though they may not be the best thing to start out with, they can be a great choice for building small or low power embedded systems.

The architecture of an embedded system will make a big impact on the rest of the development process including choice in programming language, operating system, and more. As alluded to earlier, choosing an architecture that is the same as your development environment will remove the potential for many of the possible problems that exist. The Intel x86 architecture, commonly used on nearly all desktop PC systems, is probably the safest and easiest choice. In addition to easing the development process, x86 also has broader hardware and software support than most other architectures. But x86 isn't always the right choice. These days x86 processors are geared towards very high clock rates which means greater power consumption. There are exceptions like Transmeta's Crusoe⁴ and Via's Eden⁵ processors, but both still have clock rates upwards of 600MHz. Some applications require far less processing power and could also benefit from much lower energy consumption. Such applications are probably more suited for the ARM or MIPS architectures, which are RISC processors cores. The interesting part is that neither ARM Holdings Ltd. or MIPS Technologies Inc. produce any processors themselves. Instead, they just design the processor core and then license out the design to whoever wants to produce them. This arrangement leads to a wide array of ARM and MIPS processors on the market ranging in speed, features, and price. A nice feature of the ARM architecture is that the instruction set is fixed by the ARM specification. That means that assembly language code written for one particular ARM processor should be able to run on any other ARM processor (Yaghmour 59). The MIPS, however, has many variants so there is no guarantee that code written for one MIPS processor will work at all on another (Yaghmour 61). Both of these architectures are fairly common in devices like cell phones, PDAs, and other hand-held electronic devices. If an architecture is chosen that differs from the development environment, there are certain complications that must be accounted for. Namely, all the executable code will need to be generated with a cross-compiler. Basically, a cross-compiler is one that runs on one architecture, but produces code for another. The GNU Compiler Collection (GCC)⁶ is a suite of compiler front-ends that makes for a very good cross-compiler. Unfortunately, setting up GCC as a cross-compiler is not a simple task and really falls outside the scope of this paper.

Size, reliability, and cost are three important factors when choosing a storage medium for an embedded system. As with a lot of things, picking firm values for two of those criteria leaves no alternatives for the third. For example, using magnetic media, such as a hard disk drive, for storage is an inexpensive way to get a very large amount of storage. The down side is that disk drives are not terribly fond of being jostled around and have a tendency to randomly fail without warning. Although it might not be a bad idea to use a hard drive for development, there's really no safe way to use one in a production system. On the other hand solid state flash devices are significantly more reliable than magnetic disk drives. There are several types of flash media. Most are available in the form of an integrated circuit, and therefore come prepackaged on embedded boards. This can make some flash devices a bit harder to deal with without the proper tools. Luckily, there's a middle ground. Flash discs⁷ , or flash drives, are flash chips that have been added to a standard drive interface. The result is a device that 'looks' like a magnetic disk drive to the system, but in reality is a flash device with all of the benefits that come along with it. One caveat of all flash devices, both flash ICs and drives, is the problem of wearing. Each flash device has a rating for how many times each page can be written or erased. There are ways to reduce the effects such as wear leveling. Wear leveling is a technique that can be implemented in hardware or software that spreads writes to the flash across all of the available media. The result is a flash that has been worn more evenly even if from a higher level it looks like the same block has been rewritten over and over. There are file systems, such as the Journaling Flash Filesystem (JFFS)⁸ , that have been specifically written for use on flash devices to reduce the effects of this problem. In the end, the software chosen, or written, to run on the embedded system should be aware of its underlying storage media and make adjustments as necessary.

When it's time to put all of this hardware together, it becomes necessary to really think about how and where the embedded system is going to be used. Every piece of hardware has its own characteristics, benefits, and drawbacks. Care must be taken to ensure that properties of the hardware won't conflict with the indented use of the system. One example could be a game console system. The sum of the cost of components must stay within reason if there are any hopes to sell it down the line. The processor and media components must be able to handle the stress of rendering elaborate 3D graphics as well as mixing several channels of audio on the fly. Luckily, this system will most likely be used in someone's living room or other such climate controlled environment. This opens up the possibility of active cooling which will most likely be a requirement with today's high-end graphics processors. Another possible embedded system could be a wireless access point for an industrial setting. The requirements for this system are almost completely different. The processor should be suited to handle the requirements of whatever protocol stack will be running on the device, plus a safe margin. If the processor is overrated for the task, it may not survive in ambient temperatures ranging from 100-120F. Active cooling may also not be an option due to possible airborne contaminants that would render almost any active cooling system useless in no time. In general, there is no one size fits all embedded system. It really ends up depending on how and where the system is going to be used. Choosing the software to run on your embedded system is the next big step. One option is to write your own from scratch. Given the right specifications about the chosen architecture, anyone can write their own embedded operating system. Depending on what features and functionality is required, that may be a viable option. But in a lot of cases, starting with an existing embedded operating system is a more feasible option. Microsoft⁹ has really made a big push into the embedded market with Windows CE, and now Windows CE .NET¹⁰ , and Windows XP Embedded¹¹ .

Another option is to run a Linux-based operating system. One of the advantages to running Linux on an embedded system is the fact that nearly all the software available for Linux is licensed under the GNU General Public License (GPL)¹² . Because of that, all of the components necessary to build an operating system can be compiled from scratch for the intended architecture. The term Linux itself really refers to the kernel or the core of the operating system. The Linux kernel can be customized to only include the required features. The rest of the operating system is comprised of libraries, utilities, and application programs. In all Linux based operating systems there exists what are called the C libraries. These libraries implement the system calls that make up the basic functionality of the operating system. The GNU Project maintains the most commonly used C libraries called GLIBC¹³ . GLIBC is notorious for its size. The latest version (2.3.2) compiles to around 2-3MB. That may not seem very large until you try to fit it and everything else you need onto a 4MB flash device. For that reason, there exists a project called uClibc¹⁴ . uClibc is essentially a smaller version of GLIBC. The size is reduced by removing compliance to some standards as well as some more advanced features and optimizations available in GLIBC. Nevertheless, the uClibc development team claims that you should be able to build nearly everything with uClibc that you can with GLIBC. They go so far as to challenge developers to find programs that won't compile against uClibc. The net result is a set of C libraries that are only 200-300KB instead of 2-3MB. From there, it's just a matter of features. Another project, called BusyBox¹⁵ , is designed to provide the basic set of utilities and programs that one might need to make the beginnings of a useful operating system. The list of features that it provides has become quite extensive and has come to the point of including a minimal web server. Again, BusyBox is completely customizable and can be trimmed down to nothing but the bare essentials.

In the end, it turns out that embedded systems is a field that is pretty easy to get into. Much of the mystery in embedded systems is the fancy box in which the components are hidden. The real task is to outline the requirements and find components suited for the task, much like with software engineering. The more advanced hardware aspects of embedded systems is something that can be learned later on, but is definitely not a prerequisite to the field.

Works Cited

Yaghmour. Building Embedded Linux Systems. Sebastopol: O'Reilly & Associates, Inc., 2003.

Footnotes

... capabilities¹

http://www.viaembedded.com/product/epia_MII_spec.jsp?motherboardId=202

... PICMG²

In common usage, PICMG actually refers to the PICMG's PCI-ISA standard. See http://www.picmg.com/pciisa.stm for more information.

... PC/104+³

http://www.pc104.com/whatis.html

... Crusoe⁴

http://www.transmeta.com/crusoe/index.html

... Eden⁵

http://www.via.com.tw/en/Products/eden.jsp

... (GCC)⁶

http://gcc.gnu.org/

... discs⁷

http://www.icpamerica.com/ifm_401.php

... (JFFS)⁸

http://developer.axis.com/software/jffs/ and http://sources.redhat.com/jffs2/jffs2-html/

... Microsoft⁹

http://msdn.microsoft.com/embedded/default.aspx

... .NET¹⁰

http://msdn.microsoft.com/embedded/prodinfo/prodoverview/ce.net/default.aspx

... Embedded¹¹

http://msdn.microsoft.com/embedded/prodinfo/prodoverview/xp/default.aspx

... (GPL)¹²

http://www.gnu.org/copyleft/gpl.html

... GLIBC¹³

http://www.gnu.org/software/libc/libc.html

... uClibc¹⁴

http://www.uclibc.org/

... BusyBox¹⁵

http://busybox.net/