Journal Articles

CVu Journal Vol 15, #4 - Aug 2003
Browse in : All > Journals > CVu > 154 (12)

Note: when you create a new publication type, the articles module will automatically use the templates user-display-[publicationtype].xt and user-summary-[publicationtype].xt. If those templates do not exist when you try to preview or display a new article, you'll get this warning :-) Please place your own templates in themes/yourtheme/modules/articles . The templates will get the extension .xt there.

Title: When Worlds Collide

Author: Administrator

Date: 03 August 2003 13:15:59 +01:00 or Sun, 03 August 2003 13:15:59 +01:00

Summary: 

#1 - Embedded Systems and General Purpose Computers

Body: 

Until recently the worlds of Embedded Systems and General Purpose Computers were two distinct branches of the computer/electronics industry, each with their own requirements, tool sets, philosophies, applications, markets and customers. First we must look at them individually before we can understand the issues when they meet.

Embedded Systems

The term Embedded Systems is often used synonymously with Real Time Systems, but the two terms are not the same. Real Time has a distinct definition; the system must perform within given time constraints, whereas Embedded System is a general term for a non-general purpose computer embedded in another device. With no explicit definition, we can only identify Embedded Systems by the characteristics they are likely to have:

  • No or limited human interface. A vehicle engine management system only interfaces to the mechanical and electronic parts of the car, whereas a washing machine controller has a limited human interface through simple buttons and display.

  • Provides only one or a set of closely related functions. A D-A converter in a CD player provides one clearly defined function, whereas a IP router performs many functions but all related to the management and routing of IP packets.

  • Contains program code in solid-state storage such as PROM that cannot be user upgradeable. The code for a mobile phone is often fixed for the life of the product but that of the telecom switch carrying a call from that phone will be upgradeable, usually without taking the switch out of service.

  • Either has no operating system or uses a small footprint embedded or real-time OS (RTOS).

  • All code is usually from one source (usually in-house) maybe with some bought-in libraries such as communications stacks. This means that all code running on the device is under the same control and thus can be fully integration tested before shipping and simple scheduling algorithms such as round-robin co-operative multi-tasking are safe to use.

  • The code is often designed and implemented for one proprietary hardware platform. The hardware and software are considered a single unit; they are useless on their own.

  • The memory and CPU power is usually constrained. On small devices manufactured in large quantities a few pence saved on a cheaper processor or smaller memory produces savings that dwarf the extra software development effort to fit the software to the limited hardware. Larger systems may be limited by having to use parts that will remain available for the product's predicted lifetime rather than using faster state-of-the-art components which may be obsolete quickly.

  • The product is defined by what it does, the how is largely irrelevant. A customer buys a washing machine with digital control, a fuel-injected engine, or a radio with digital tuning. They don't buy a computer that does washing, runs an engine, or tunes to radio stations.

General Purpose Computers

The PC has evolved from its original intention as a "Personal" generalpurpose computer to something so powerful it is practically the "ultimate" General Purpose computer. Many functions such as speech recognition and real-time video and audio encoding and decoding no longer need specialised platforms and the "humble" PC now has the power to perform these. Even super-computers are under threat from clusters of relatively cheap PCs. As with Embedded Systems, it is better to characterise General Purpose Computers rather than define them:

  • Thought of as a computer first, and a solution second. It is a computer running a word processor, rather than a word processing machine, a computer performing weather prediction rather than a weather predictor.

  • Even if dedicated to only one task, it is equally capable of doing lots of other tasks. The choice to dedicate to one purpose is purely an operational one and not to do with the underlying machine.

  • Has a rich human interface. Even the DOS command line is extensive compared with the interface to a digital alarm clock.

  • Has an operating system that allows multiple users and multiple applications to run so that one user or application can be prevented from interfering with the others.

  • Can run applications or even operating systems from different suppliers. It is common for the hardware and software to be produced by different companies, or different divisions within a large company.

  • Any specialisation is general rather than specific. The system may excel at floating-point arithmetic, parallel processing, or database storage, but many applications may exist that make use of these traits. A system such as a Cray super-computer may be viewed as rather specialist, but it really is a general-purpose computer compared with, say, a nuclear power station controller or telecommunications switch.

  • Are often highly configurable. A mainframe may be available in many different sizes (scalable) whereas the PC has a seemingly infinite number of combinations of processors, buses, cards, etc.

  • Are user-upgradeable, especially in terms of software.

Collision

As available processing power increases, size reduces, and prices drop, there is an increasing grey area where it is difficult to decide if a particular device is an embedded system, or a general-purpose computer. Embedded Systems is no longer a domain of 4- and 8-bit microprocessors, but increasingly of 32- or even 64-bit, often using the same CPU families chosen by the designers of General Purpose computers, because these are now powerful enough to perform tasks in software that previously required custom hardware-software solutions. Embedded Systems are increasingly able to perform tasks other than their core intent because they share base components with more general purpose platforms, and General Purpose computers are increasingly being used where an Embedded System would traditionally have been chosen because they [General Purpose computers] are now a powerful and cheap enough alternative.

Nowhere is this collision more apparent than the PDA (Personal Digital Assistant). It often is based on custom hardware typical of embedded systems with limited processing power and memory, and upgrade opportunity, contains its core program in ROM memory and has software written only for the one hardware platform. Yet it runs a number of applications such a word processing and web browsing, interacts directly to a human operator through a visual user interface, can be easily upgraded with replacement or new applications, and is often considered a computer with applications rather than a diary that happens to be electronic. So is a PDA an embedded system, or a general-purpose computer? Is it a very flexible embedded system, or a lightweight laptop PC?

Operating Systems

In the arena of Operating Systems - the glue that binds together the applications - the jury is still out. On one side, existing embedded OSs and new OSs based on embedded OS theory such as EPOS are being pushed by their respective supporters, and on the other, cut down versions of general purpose computer OSs such as Windows CE and Embedded Linux are being developed.

The Embedded Programmer

The embedded programmer is used to working within a tight budget of processing power and memory, and often using only simple 8-bit processors. In comparison, a modern 32-bit PDA has plenty of power and memory and should pose no challenge. However, there is one part of the PDA which will be alien to most embedded programmers: the graphical user interface (GUI). With the GUI come a number of problems that cannot be solved using traditional embedded methods: memory management, task management, error handling, etc.

Many programmers choose to work in the embedded world because the rules are clearly defined, albeit sometimes difficult. Writing hardware interface code requires care and precision, an understanding of how hardware works, and logic, but it is well defined - it works in a logical manner and the error conditions are usually documented. The usual answer to memory and task management in an embedded system is to allocate everything at start up - this is easy because the tasks and their memory requirements are known at start up, they may even be known at design time, therefore error conditions relating to these don't have to be handled during normal running. In fact, most resources can be handled in this way, for example, a serial port will only be used by the task designed to use it so allocation and de-allocation and the resultant resource locking is not required.

So, the new embedded programmer has to learn how to operate in the brave new world of user interfaces. A user of a PDA will be presented with a graphical interface much closer to a general purpose computer than any of the embedded devices he has currently come across, therefore he will expect them to behave as such. New programs can be loaded and executed at any time, which means resource allocation and contention need to be considered. There will probably be some PC card or removable memory slots, so resources may appear and disappear.

The Application Programmer

A typical application programmer has been fairly spoilt in recent years. As well as a large choice of development environments, the speed of processors and size of memory have increased at a fast rate. Rarely does the programmer of a modern day general-purpose computer have to spend time tuning code for space or performance, and when these become an issue such as in servers handling a high number of clients, it is design time decisions rather than programming idioms that yield the greatest results.

Sometimes the programmer does not even need to address the problem, as it goes away by itself due to the fast pace of change in the industry: A program that is sluggish during development time is acceptable at the point of release, and fast once shipped in numbers as hardware speeds outpace software development. Users have become used to having to upgrade their hardware to run the latest software so they almost expect it, so new features can eat up memory and processor cycles without fear.

The computer industry, believing there is a shortage of programmers, has accepted into its ranks scores of developers who otherwise would not make the grade. This has led to many companies where sloppy work has become the norm. The tolerance of the users to having to restart the program or machine, and of operating systems that tidy up the resources, means such practices proliferate.

These factors have led to the explosion of applications giving the user unprecedented choice. In recent years the exponential growth in open source programs has added to the existing commercial and shareware offerings increasing this choice further.

Yet, the most common "computer" on the planet is still embedded.

The Outlook

For a minority at the extremes, such as the programmer of 8-bit controllers and the database query language programmer, the colliding of worlds is irrelevant. For the rest of the computer industry many facets of the job will change, desktop applications will require a PDA version, server code will need to deal with a larger variety of clients, embedded systems will require graphical user interfaces and allow user driven upgrades. The application programmer will not only need to learn different platforms, but will be required to learn some of the skills the embedded programmer takes for granted, conversely, the embedded programmer will need to deal with interfaces that are no longer well defined or predictable and will no longer program in an environment mostly under his control.

The future will certainly require many of us to learn new skills, but our industry has always been in a state of rapid change. The better developers will expand their horizons and meet the challenge; the least skilled will struggle. As they say in France, "Plus ça change, plus c'est la même chose".

Notes: 

More fields may be available via dynamicdata ..