Title: When Worlds Collide

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.

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:

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:

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?

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 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.

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.

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".