TABLE OF CONTENTS Embedded software has traditionally been thought of as software on small computers . In this traditional view, the principal problem is resource limitations (small memory, small data word sizes and relatively slow clocks). The solutions emphasise efficiency; software is written at a very low level (in assembly code or C), operating systems with a rich suite of services are avoided and specialised computer architectures such as programmable DSPs and network processors are developed to provide hardware support for common operations. These solutions have defined the practice of embedded software design and development for the last 25 years or so.
Of course, thanks to the semiconductor industry's ability to follow Moore's law, the resource limitations of 25 years ago should have almost entirely evaporated. Why then has embedded software design and development changed so little? It may be because extreme competitive pressure in products based on embedded software, such as consumer electronics, rewards only the most efficient solutions. This argument is questionable, however, since there are many examples where functionality has proven more important than efficiency. We will argue that resource limitations are not the only defining factor for embedded software, and may not even be the principal factor now that the technology has improved so much.
Resource limitations are an issue to some degree with almost all software. So...
