Global Sources
EE Times-Asia
Stay in touch with EE Times Asia
?
EE Times-Asia > Embedded
?
?
Embedded??

Choose the right OS for your consumer devices

Posted: 15 Jan 2007 ?? ?Print Version ?Bookmark and Share

Keywords:operating system? RTOS? operating systems? ASIC? SoC?

By John A. Carbone
Express Logic

Innovative consumer electronics products have replaced business information technology systems as the major force driving the electronics industry. The explosive growth in this market has led to a proliferation of hardware platforms, operating systems and development tools. In response, the consumer products industry is embracing the concept of device software optimization (DSO) which involves optimization of technologies and processes on an enterprise basis rather than project by project. However, the highly competitive nature of the consumer products industry and the wide spectrum of products being developed to meet various market requirements means that only rarely does one size fit all.

The explosion of the consumer device market over the past decade has generated products primarily in three categories. Low-end devices generally are built around ASICs or SoCs with small amounts of program memory (ROM), typically around 256Kbytes, use an inexpensive processor, are manufactured in high volumes, and are typically developed by a single programming team. Typical examples of this type of device include many digital still cameras (DSCs) and inkjet printers.

Mid-range consumer devices, such as video cameras, are characterized by moderate amounts of program memory in the area of 1Mbyte to 2Mbytes and multiple programming teams. High-end devices, such as smart phones and STBs, typically have much more memory, perhaps 32Mbytes, use powerful processors and are developed by large programming teams (Figure 1).

Differing OS requirements
The OS requirements for these different categories of consumer devices vary widely. High-end devices typically use relatively expensive high-end processors, and often also coprocessors, that deliver tremendous throughput. These high-end devices typically have a high degree of human interaction, though, and users are slow enough that the high-end processors in these devices usually have no problem keeping up. Because of this, the real-time requirements are not particularly demanding.

Figure 1: From the low-end to the high-end, consumer devices have a wide spectrum of requirements.

High-end devices often have special-purpose hardware, such as the DSPs used in STBs for IP routing and video decoding, that remove the responsibility for the most demanding processing from the OS. These devices also have a wide range of peripherals that require operating systems with many middleware services.

Products on the lower end of the spectrum typically have very different OS requirements. Lower-end devices typically have relatively little human interaction and instead consist largely of processes whose timing needs to be tightly controlled. For example, pressing the shutter on a typical DSC kicks off a series of threads that might involve tasks such as measuring the ambient light, focusing the camera, capturing the image on the CCD, moving the image to memory, etc. These tasks all must be completed before the exposure period calculated by the DSC has elapsed and the shutter closes.

By the same token, a typical inkjet printer needs to scale the picture, translate the picture into appropriate inkjet commands, issue commands to the motors controlling the position of the jets, and fire the jets. Inkjet printers are sold largely based on their printing speed so all of these tasks must be completed within a brief and well-defined time period. Cost constraints for mass-market DSCs and inkjets printers don't allow for dedicated hardware to complete these tasks, so they must rely on the OS' real-time performance.

Hard vs. soft RTOS
This theory helps explain why the majority of low-end devices use a hard RTOS which provides 100 percent predictable response to interrupts while higher-end consumer devices often use soft RTOSs such as Linux and embedded versions of Windows that can't guarantee interrupt latency.

Another important factor in an RTOS for a low-end device is its context switching capability. This refers to the amount of time needed by the RTOS to save the state for the current task, load the context for another task, and begin execution. Note that there are no clear standards to compare the measurement of context switching across different RTOSs so it may be necessary to work with RTOS vendors to determine the performance of their products in your specific application environment.

These requirements help to show why Linux, despite its popularity in the high-end consumer device market, is rarely used in low-end devices. The best-case interrupt response and context switching times for embedded Linux are typically in the high tens of microseconds. Typical real-time performance for Linux is generally in the range of a few milliseconds. But it's important to note that in the worst, case Linux real-time performance is unbounded. On the other hand, the fastest hard RTOSs provide a deterministic real-time performance in the range of 1?s to 2?s, which is normally sufficient to meet the needs of the most demanding applications.

Memory requirements
Another important consideration is the RTOS' memory requirements. Low-end devices are typically built around a single SoC so the amount of memory is constrained by the available real estate and the need to incorporate other functions. The more memory consumed by the RTOS, the less that's available for the application. Off-chip memory may be provided in many applications; however, external memory offers inherent performance drawbacks.

External memory performance is acceptable for some uses, such as storing the image in a DSC, but rarely is sufficient for program code. It's important to note that application functionality will always grow into the future, so it's a good idea to allow headroom for future growth. A good rule of thumb is to keep RTOS code size to no more than around 10Kbytes to 25Kbytes for kernel services and comparably small sizes for key services such as TCP/IP, file system, and USB.

Complete development environment
Let's look at the RTOS in the context of the complete development environment (Figure 2). The middleware layer consists of a wide range of services, each of which may or may not be required in specific applications. For example, the network service typically provides an Ethernet communications port required by many midrange and high-end consumer devices, such as network-capable inkjets. The graphics middleware generally is used to develop the graphical user interface that is again typical mainly of higher end devices. USB, on the other hand, is ubiquitous among both high- and low-end consumer devices. Files systems are required by many consumer devices at all ends of the spectrum. For example, a printer must handle a range of file formats and a DSC must save files when creating an image and open files for viewing and transfer to a computer.

Figure 2: The complete development environment includes a host of standardized and custom components.

The specific middleware required in an application is an important factor in selecting an OS. An OS such as Linux offers hundredsperhaps more than 1000middleware applications. The richness of the available middleware provides an important advantage for Linux in high-end consumer applications. On the other hand, this richness comes at the price of slower performance, higher complexity, and the need to deal with the challenges of navigating the open-source environment.

Hard RTOSs, on the other hand, generally provide a smaller number of middleware options, but include all of the core services needed by designers of low-end consumer devices. The need for middleware in most any consumer device also points out a major disadvantage of building your own OS. In that case, you'll be responsible not only for developing all of the necessary middleware, but also for maintaining it in a rapidly changing environment.

Support for multiple hardware platforms
The RTOS' flexibility in terms of its support for a range of hardware platforms is another important concern. Developers of low-end consumer devices typically determine that a single, low-cost 32bit processor delivers the best performance-to-price ratio. There are a number of vendors, particularly ARM, Freescale, MIPS, and Analog Devices, competing for this business.

ARM has a particular strength in low-power, high-performance applications and has gained many wins in inkjet printers, mobile handsets and PDAs. MIPS offers high-performance processors that are widely used in portable game players, DSCs, laser printers and digital STBs. Freescale's Coldfire processors offer the advantage of low-cost integrated peripherals and are widely used in digital printers. Analog Devices' Blackfin processor competes at the high end of the performance spectrum by offering integrating DSP and general-purpose processor capabilities and has obtained recent design wins in camcorders.

Note that the 32bit processor market is changing rapidly and new offerings are continually being developed. You may be using ARM now, but in six months, the landscape may have changed enough that you'll pick MIPS for your next design. Selecting an OS that supports a broad range of processors will make it possible to switch to a different processor down the road while continuing to reuse most of your code. The rapidly changing processor environment also points out another weakness of developing your own OS: you may face the difficult task of developing yet another OS if the processor you chose for your previous product is no longer the best choice.

Using a commercial RTOS that supports various processors also helps keep your options open in addressing important issues such as multithreading versus multiprocessing. The race among microprocessor vendors to deliver the fastest clock speeds has run up against obstacles such as power consumption and hardware complexity. More recently, processor development has been driven by multiprocessing and multithreading approaches that deliver higher performance, while using less power and at a lower cost. Multithreading increases performance by using cycles in which the processor would otherwise be waiting to access slower memory to handle additional threads. Multiprocessing provides additional processor cores that can handle separate concurrent threads and provides the ability to turn off entire processors to save power while executing less demanding workloads.

Development tools
The development tools provided with the RTOS form another important factor. One of the most important areas is the need to start with a fresh SoC in the development of most low-end consumer devices. The Joint Test Action Group (JTAG) developed a methodology that provides complete controllability and observability of a JTAG compatible device's boundary pins using software control. This couples the development board to the host running the debugger more closely than with an Ethernet connection. Developers can download the initialization code during the early development phases. Every register on the chip is visible through the JTAG boundary-scan interface. The interface also can be used to set break points and to write directly to the SoC's registers.

Common pitfalls in selecting an RTOS

  • Don't buy a black box. Make sure you obtain the full source code and complete commercial support.

  • Don't be a pioneer. Use a solution that's been proven in many other devices and try it before you buy.

  • Don't use an OS with more capabilities than you need because it will consume additional memory, will take longer to learn, and will be tougher to debug.

  • Don't get trapped into a single source environment. Instead, use tools that support industry standards such as POSIX and multiple development environments.

  • Don't build your own OS. The costs of developing, debugging, and maintaining your own OS and associated middleware is far greater than the relatively low costs of purchasing a proven commercial OS.

About the author
John A. Carbone
is the VP of marketing for Express Logic. He holds a BS degree in mathematics from Boston College. Carbone can be reached at jcarbone@expresslogic.com.




Article Comments - Choose the right OS for your consume...
Comments:??
*? You can enter [0] more charecters.
*Verify code:
?
?
Webinars

Seminars

Visit Asia Webinars to learn about the latest in technology and get practical design tips.

?
?
Back to Top