In a world of ubiquitous embedded computing devices, from automobile engines to cell phones, one thing stands out: they usually operate in isolation. Previously, the technology to network them together was either too expensive or nonexistent. More and more, however, these types of objects are being connected to networks, even the Internet. They are actively communicating with one another and the world at large, forming a truly connected world.

This trend has pushed both hardware and software technology in a direction that allows building low-cost, embedded platforms that are networked. These ``thin servers'' are perfect for embedding in intelligent devices, devices that really are information-aware appliances. They perform not only their own specific control functions but also can interact over a network to allow a whole new set of distributed features.

Our problem has been finding an easier way to produce a truly general-purpose appliance, yet retain simplicity of design, production and programming. In our case we were seeking to develop a unit that had the functionality and robustness of a $10,000 network-routing device, with the ease of production and affordability of an appliance costing a mere few hundred dollars. Until now, building a complex, multifunctional device would quickly become prohibitively expensive or simply too large and take too long.

Conversely, a purpose-built appliance often would be serving too specific an application to be able to be reused. Either way, embedded applications are extremely cost-sensitive. Even a few extra dollars on a build price can translate to too much of a cost burden for a product under commercial realities, particularly in the consumer mass-market. And this situation will never get easier.

However, design technologies are allowing cheaper individual components, higher integration of functions, advanced programmable computing devices from a handful of chips, and devices built for a few tens of dollars with multipurpose functionality.

The PCs of today are not ready to be shrunk down to network appliances yet. Build costs for even a low-end PC are over twice the cost of building special-purpose internet appliances.

Yet, connectivity to the outside world is a vital aspect of networked appliances. Some type of network interface will be required and that may be narrowband, broadband or something else entirely. Some common interfaces today are analog (V.90), ISDN, xDSL, cable modem, wireless (802.11 and Bluetooth) and 10/100/1000Base-T.

Another important issue with any sort of programmable device is its configuration interface; that is, how the embedded device can be set up and configured by a user. Many embedded systems have no user-configurable interface, others may require--or at least support--extensive configuration options. This problem is often made much simpler by the fact that the device is networked. The simplest option typically is to use a small web server inside the embedded network appliance. This has many advantages, the chief one being that web browsers are ubiquitous and well understood by almost everyone. There are, of course, other options ranging from a classic command-line configuration method to more advanced network management protocols, such as SNMP.

The overriding factor that affects the total cost of any embedded system manufactured in volume is the cost of actually building the hardware. The upfront engineering costs are usually amortized over the lifetime of the product. But a real problem is the time-to-market--that time from initial product conception to the shipping of final product in volume. A clear trend with modern, complex, networked appliances is that the bulk of development time is spent on software engineering, creating the software system at the heart of the embedded network appliance.

A mix of features and constraints make embedded network appliances unique. There is no easy or simple answer as to what the best trade-offs for performance, cost and functionality will be. Each product that incorporates an embedded network system will differ. Figure 1 illustrates some of the many aspects we had to take into account to build a low-cost internet appliance.

Figure 1. The Internet Appliance Puzzle

We were able to solve many of the challenges mentioned above through clever hardware design, but we were left with one big problem: what operating system is powerful enough to make the appliance a truly general-purpose unit with a long production lifetime through versatility and upgradability? While many operating systems may meet that requirement, can they reside within 1MB of Flash?

The answer was with a variant of Linux called µClinux, or Microcontroller Linux. It is a flavor of Linux directly derived from the exceptional Linux kernel work of Linus Torvalds, Alan Cox and a team of thousands of developers spread across the Internet. µClinux extends Linux to the very smallest of microcontrollers that have no MMU (memory management unit) hardware.

Suddenly you have an operating system that will give you all the power of Linux with TCP/IP networking in 512KB of RAM. Most Linux applications now can be ported easily to a tiny embedded appliance. The work of literally thousands of outstanding programmers becomes available to you, reducing development time to a fraction of the more traditional development cycles. Anyone familiar with Linux and the Open Source movement will realize there has already been a solution written for almost any problem, and the source code is there for the taking. Not only does it make general debugging easier, but it also means that the kernel and utilities can be tailored to the exact requirements of the system.

Simply put, the advantages of µClinux for us were: free (no license or per-unit cost); freely available source code (no vendor lock-in); free development environment and extensive set of compilers, linkers, debuggers and other toolchains; free and a large base of software applications; free, fast and forthcoming bug fixes; real-time extensions available; many target microprocessors options (no dependence on a chip vendor to do a port); and large range of peripheral device support.

The latter two mean that a hardware design engineer has a much larger range of choices in attempting to build a minimal design. And Linux is powerful enough to get everything out of the hardware platform.

In theory it appears as though Linux makes an excellent choice for a large set of low-cost embedded network appliances, but the proof is in the final outcome. Now it's time to introduce an in-depth example of a low-cost embedded network appliance, a home/office residential internet gateway.

At its core the hardware platform (dubbed NE2520) consists of the following components: a Motorola ColdFire 5307 CPU (90MHz, 4KB internal cache), 4MB SDRAM, 1MB Flash ROM, two 10Mbps Ethernet and two RS-232 serial ports (see Figure 2).

Figure 2. The Hardware Core of the NE2520

Note the small core component count. By using highly integrated devices the count is kept low, and ultimately the manufacture cost is also kept low. Notice the small amounts of RAM and Flash used. Minimal resources will be a typical characteristic of all low-cost embedded systems, and this appliance is no exception.

It is also worth noting that no form of mass storage is in this. It must keep all its operating code and configuration information in the nonvolatile Flash ROM device. This design is not a shrunk-down PC.

The heart of the unit is the Motorola ColdFire CPU, a specialized embedded CPU delivering exceptional computing performance at a low cost. It integrates a number of standard logic parts onto the chip to reduce the overall system part count. Included are such things as cache memory, interrupt controller, DMA engine, timers, memory controller circuits and device select logic. In traditional workstation and PC computers these types of functions exist in one or more support chips outside of the CPU.

The ColdFire is a descendant of the popular Motorola 68000 processor family. Those engineers familiar with the 68000 will feel right at home with the ColdFire processor. The instruction set and addressing modes are a subset, and the overall CPU core is similar. The processor register set is identical, although the stack pointer implementation differs.

ColdFire processors are 32-bit devices, but one point of concern is that they do not have any virtual memory support. This would have been a problem if not for µClinux, which solves that problem intrinsically.

The NE2520 uses its 1MB Flash ROM to store the operating system kernel, the root filesystem and also a configuration filesystem. It also bootstraps from this Flash memory when it is powered on. Flash memory is a nonvolatile type of memory (it does not lose its contents when power is removed). It can also be reprogrammed in circuit, meaning that the NE2520 can be loaded with newer revisions of its operating code (firmware) while on the customer's network.

The NE2520 contains 4MB of modern fast SDRAM. The main operational memory of the system, it is used to hold the running kernel and applications. It is also used to hold a RAM filesystem. This RAM filesystem provides a small temporary file store for applications to use while running. It also provides a convenient place to store device logging and status information.

Generally speaking, the smaller the memory size the lower the cost. So considerable engineering effort will be spent keeping the kernel and application set as small as practical. For some applications it will also be necessary to cut down functionality to conserve memory. Usually this simply means removing features that cannot be used in the embedded system.

The peripheral set was chosen to provide the required network connectivity as simply and cheaply as possible. The serial ports are integrated devices in the ColdFire CPU. Ethernet interfaces are provided by a low-cost SMC Ethernet card. Ten status LEDs are used to provide a visual indication of the operating status of the NE2520.

Building any type of embedded system is greatly different from building a typical desktop computing application. This difference has made engineering embedded systems a specialty skill and a time-consuming, difficult task. Traditionally each new system is handcrafted using a mix of existing and new source code. Normally operating systems crafted specifically for embedded systems are used, and their programming interfaces inevitably differ from those of workstations.

To a large extent, using a Linux-based embedded system alleviates a lot of the pain usually associated with programming an embedded systems. Now the kernel component is almost identical to any workstation-based Linux system. All low-level hardware components that need to be created use the existing, well-documented Linux driver model. Similarly, the application environment is virtually identical, meaning a familiar application programming interface (API) and a large base of existing tools and utilities can be drawn upon.

In the case of the Lineo NE2520 platform, the µClinux kernel provides a Linux interface totally compatible with workstation Linux. The primary utility set required is the same networking tools required for workstation Linux--they only need to be ported to the ColdFire processor architecture.

Embedded systems are generally not capable of hosting their own build environment. The hardware resources available in low-cost embedded systems simply do not allow for a suite of compilers, linkers, debuggers, etc. Almost always the embedded system software and applications are cross-compiled from a workstation environment. (Note that some embedded systems can and do have full compilation toolchains self-hosted, but those that we are examining here typically will not.)

When using a Linux-based kernel the choice of toolchain is obvious. The GNU tools offer a complete set of compilers, assemblers, linkers and debuggers. In fact, they are of a quality arguably as good as, or better, than tools provided by any proprietary vendor.

For the NE2520 product, the GNU gcc version 2.95.2 compiler is used because it has excellent support for ColdFire processors. The binutils package version 2.10 provides the rest of the build tools, supplying the required assembler, linkers and object-file manipulators. As a side note, the toolchain is configured to generate ELF format binaries--the same as those generated on a typical Linux workstation.

Figure 3. Exploded View of the Final Unit

It's all very well to talk about design projects like a theoretical exercise, one that has unlimited time and materials. Given enough time most engineers can make a solution that is elegant and functional. The secret to our success has been to focus on low-cost solutions that can be designed and developed quickly.

Perhaps our most challenging scenario arrived when a customer liked our design but absolutely had to have an x86 architecture solution. Worse still, we only had two weeks to produce a prototype. We were able to design and build a functional prototype ready for manufacturing, simultaneously porting the software environment to the x86 architecture, in ten days. This simply would not have been possible without Linux and the large pool of GNU software.

The flexible base built on embedded Linux has allowed us to create quickly a family of products with a range of interface, performance and functionality options. It has also given our team of engineers the ability to spin new variations in incredibly short time frames; usually within weeks instead of the industry norm of months.

Resources