Recently, several large consumer electronics companies announced a collaboration called the Consumer Electronics Linux Forum (CELF) to develop further the Linux platform for use in digital home electronic devices. The founders of CELF--Matsushita Electric, Sony, Hitachi, NEC, Royal Philips Electronics, Samsung, Sharp and Toshiba--are focused on the advancement of Linux as an open-source platform for consumer electronics devices. As such, they actively are supporting and promoting the spirit of the Open Source community.

The advantage of embedded Linux is it is a royalty free, open-source, compact solution that provides a strong foundation on which an ever-growing base of applications can run. Linux is a fully functional operating system, with support for a variety of network and file-handling protocols--an important requirement in embedded systems because of the need to compute anywhere, anytime. Modular in nature, Linux is easy to slim down by removing utility programs, tools and other system services that are not needed in an embedded environment. The advantages for companies using Linux in embedded markets are faster time to market and reliability. For those developers, the combination of a digital signal processor (DSP) and uClinux may be of particular interest.

Because Linux is similar to UNIX in that it is a multi-user, multitasking OS, the kernel has to take special precautions to assure the proper and safe operation of up to thousands of simultaneous processes from different users on the same system. The UNIX security model, after which Linux is designed, protects every process in its own environment with its own address space. Every process also is protected from processes being invoked by different users. Additionally, a virtual memory (VM) system has additional requirements that modern CPUs have to fulfill, including dynamic allocation of memory and mapping arbitrary memory regions into the private process memory.

Some devices, such as Analog Devices' Blackfin Processor, do not provide a full-fledged memory management unit (MMU), because developers targeting their application to run without the use of an OS normally do not need an MMU. Additionally, MMU-less processors such as the Blackfin are more power efficient and often are significantly less expensive than the alternatives.

To support Linux on such devices, a few trade-offs have to be made:

Memory protection is not a real problem for most embedded devices. Linux is a stable platform, particularly in embedded devices, where software crashes rarely are observed.

The second point is a little more problematic. In software written for UNIX or Linux, developers often use the fork system call when they want to do things in parallel. The fork call makes an exact copy of the original process and executes it simultaneously. To do that efficiently, it uses the MMU to map the memory from the parent process to the child and copies only those memory parts to that child it writes. Therefore, uClinux cannot provide the fork system call. It does, however, provide vfork, a special version of fork in which the parent is halted while the child executes. Therefore, software that uses fork system calls has to be rewritten to use either vfork or threads. uClinux supports threads because they share the same memory space, including the stack.

As for point number three, there usually is no problem with the malloc support uClinux provides, but minor modifications sometimes have to be made.

Most of the software available for Linux or UNIX can be compiled directly on uClinux. The rest usually require only some minor porting or tweaking. Only a few applications do not work on uClinux, with most of those being irrelevant for embedded applications anyway.

When selecting development hardware, developers should choose carefully with regards to price and availability. They also should look for readily available open-source drivers and documentation.

A uClinux Blackfin Processor development environment consists of the GNU Compiler Collection (GCC cross compiler) and the binutils (linker, assembler and so on) for the Blackfin Processor. Additionally, some GNU tools such as awk, sed, make and bash, plus Tcl/Tk are needed, although they usually come as part of basic desktop Linux distributions.

After the development environment has been installed and uClinux distribution decompressed, development may start. First, the developer uses the graphical configuration utility to select an appropriate board support package (BSP) for his target hardware. Developers using their own hardware should make themselves comfortable with development on the EZ-KIT Lite or STAMP hardware (schematics and production files available here). After that, they can start writing their drivers and making a BSP by copying an existing one and modifying a few parameters.

Most of the development work consists of selecting the appropriate drivers and de-selecting kernel features not needed for the project in question. A selection of library features and user-space programs follows thereafter.

Figure 1. Graphical Kernel Configuration

The uClinux distribution provides a wide selection of utilities and programs designed with size and efficiency as their primary considerations. One example is BusyBox), a multi-call binary program that includes the functionality of a lot of smaller programs and acts like any one of them if it is called with the appropriate name. If BusyBox is linked to ls and contains the ls code, it acts like the ls command. The benefit of this is BusyBox saves some overhead for unique binaries and those small modules can share common code.

After everything is selected and successfully compiled, the Kernel and a RAM disc image can be loaded on to the target hardware with the help of the VisualDSP++. Once this is successful, further development can proceed. The next step is to use a serial or network-enabled bootloader instead of loading through the JTAG interface. A small circuit connected to a PC's parallel port and Blackfin's JTAG interface can be used to flash the bootloader initially to the target memory. But it is important to note that this workaround doesn't provide the debugging and emulation capabilities that VisualDSP++ does. Once the kernel is up and running, the free GNU Debugger (GDB) can be used to debug user applications.

The next step would be the development of the special applications for the target device or the porting of additional software. A lot of development can be done in shell scripts or with languages such as Perl or Python. Where C programming is mandatory, Linux's extensive support for protocols and device drivers provides a powerful environment for the development of new applications.

Figure 2 is an example of how easy an AC'97 audio codec could be wired to a Blackfin Processor, without the need for additional active hardware components.

Figure 2. AD1885 Wiring Diagram

Below is an example of a very simple program for reading from this codec, assuming an audio AC'97 driver is compiled into the kernel.

 main(){
...
fd = open("/dev/dsp", O_RDONLY, 0); //open the audio device
... 
int speed = 44100; // 44.1kHz
ioctl(fd, SNDCTL_DSP_SPEED, &speed)// set sample rate  
...
read(fd, buffer_rx, number_of_bytes); // read number_of_bytes into buffer
...
close(fd); // close device
}

Despite the fact that Linux originally was not designed for use in embedded systems, it has found its way to a lot of embedded devices. Since the release of kernel version 2.0.x and the appearance of commercial support for Linux on embedded processors, there has been a real explosion of new embedded devices that feature the OS. Almost every day there seems to be a new device or gadget that uses Linux as its operating system, in most cases going completely unnoticed by end users. Today a majority of the available broadband routers, firewalls, access points and even some DVD players utilize Linux (see LinuxDevices.org for examples).

Linux and uClinux offer a bevy of drivers for all sorts of hardware and protocols. Combine that with the fact that Linux doesn't have runtime royalties, and it quickly becomes clear why so many developers are using Linux for their devices.

But why would anyone use Linux on a DSP?

In the past, DSP's have been used in a lot of applications including sound cards, modems, telecommunication devices, medical devices and all sorts of military and other appliances that perform pure signal processing. Those DSP systems generally were designed specifically for those applications and had only basic capabilities so as to meet their tight cost and size constraints. As DSPs have become more powerful and flexible, thereby servicing the more advanced requirements of military, medical and communication users, they still have lacked the proper capabilities to run advanced operating systems. Traditional DSPs are powerful and flexible but can be rather expensive. They often are found clustered together on special signal-processing hardware where there is no need to have an operating system such as Linux running on the DSP itself. This generally is due to the fact that in those systems the DSP gets its data from some type of additional central processing unit. Therefore, only basic system software had to be written for such DSPs.

Accompanied by the quickly advancing multimedia convergence and proliferation of multimedia and communication enabled gadgets, there now is a big market for a new type of DSP. Currently, the most widely used design for servicing these markets is the combination of a general-purpose processor with a traditional DSP serving as a co-processor. In this scenario, the operating system runs on the host processor and the signal processing is done on the DSP. This type of dual-processor design is sub-optimal, though, due to inefficiencies incurred in cost, power and size.

There are a few solutions to accommodate the new market demands:

Because Linux originally was developed for server and desktop usage, it does not have the hard real-time capabilities that most other operating systems of comparable complexity and size have. Nevertheless, Linux, and in particular uClinux, has excellent so-called soft real-time capabilities. This means that while Linux or uClinux cannot guarantee certain interrupt or scheduler latency, compared to other operating systems of similar complexity, they show favorable performance characteristics. If one needs a so-called hard real-time system that can guarantee scheduler or interrupt latency time, there are a few ways to achieve such a goal:

In most cases, hard real-time is not needed, particularly for multimedia applications, where the time constraints are dictated by the abilities of the user to recognize glitches in audio and video. Those physically detectable constraints that have to be met normally fall in the area of tens of milliseconds, which is no big problem on fast chips such as the Blackfin. Stricter timing requirements can be achieved with a little tweaking or with some straightforward changes to the scheduler. In kernel 2.6.x, the new stable kernel release, those qualities have been improved with the introduction of the new O(1) scheduler and kernel preemption.

In most cases, when running popular audio/video MPEG algorithms, there is enough processing power left over for the scheduler to have enough time to handle the low number of processes that normally run on such devices. Therefore, there is no problem to utilize programming in various languages--Perl, Python, PHP--and run Web servers--SNMP, PPP or PPPoE, firewalls--while decoding video and audio. Therefore, there is no need to use hard real-time OSes that lack the advanced features that Linux can provide.

The combination of a first-class DSP core with traditional microcontroller architecture on a single chip avoids the restrictions, complexity and higher costs of traditional heterogeneous multiprocessor systems. Beneath the established peripheral equipment (SPI, UART with IrDa support, timer, RTC, Watchdog and event controller), all members of the Blackfin processor family provide two serial dual-channel ports (SPORTs), each supporting four stereo I2S channels with data rates up to 100 MBit/s. Furthermore, the newest members of the Blackfin Processor family (ADSP-BF531, ADSP-BF532, ADSP-BF533 and ADSP-BF561) provide a parallel peripheral interface (PPI) that provides connectivity for TFT flat panel displays and video converter (CCIR-656, 27MHz). The PPI also may be used as a parallel interface for AD/DA converters with speeds up to 65 MSPS.

All Blackfin processors combine a signal processing engine with the advantages of a clean, orthogonal RISC-like microprocessor instruction set and single-instruction, multiple-data (SIMD) multimedia capabilities into a single instruction set architecture. The micro signal architecture (MSA) core is a dual-MAC modified Harvard architecture designed to have unparalleled performance on both audio and video algorithms, as well as standard program flow and arbitrary bit manipulation operations mainly used by an OS.

The ADSP-BF531/BF532/BF533 processors have three large blocks of on-chip memory, providing high-bandwidth access to the core. These memory blocks are accessed at full processor core speed. The two memory blocks sitting next to the core, referred to as L1 memory, can be configured either as data or instruction SDRAM or cache. When configured as cache, the speed of executing external code from SDRAM is nearly on par with running the code from internal memory. This feature is well suited for running the uClinux kernel, which doesn't fit into internal memory. Also, when programming in C, the memory access optimization can be left up to the core by using cache.

Blackfin processors are designed using a low power and low voltage design methodology and feature dynamic power management. They meet the requirements of current mobile and battery powered applications. A Blackfin processor has multiple, highly flexible and independent DMA (direct memory access) controllers that support automated data transfers with minimal overhead impact on the processor core. DMA transfers can occur between the ADSP-BF531/BF532/BF533 processor's internal memories and any of its DMA-capable peripherals. Additionally, DMA transfers can be performed between any of the DMA-capable peripherals and external devices connected to the external memory interfaces, including the SDRAM controller and the asynchronous memory controller.

In combination with uClinux, an embedded processor offers tremendous advantages to designers, most notably by opening up a wide range of applications, drivers and protocols, which often are open-source or free software. In most cases, only a compilation or some minor tweaking is necessary to get that software up and running. Combine this with such invaluable tools as Perl, Python and PHP, and developers have the opportunity to develop even the most demanding feature-rich applications in a short time-frame, often with enough processing power left over for future improvements and new features. The embedded design community rapidly is adopting Linux as an operating system of choice. With the recent major update to the kernel, embedded Linux is proving to be a low-cost, dynamic development environment.