Embedded Software

The Works

Colin Walls

• Publisher: Newnes
• Year: 2012
• ISBN:
  9780124159693
• Edition: 2
• Topic: Computer Science
• Subtopic: Hardware
• Index: Computer Science

As the embedded world expands, developers must have a strong grasp of many complex topics in order to make faster, more efficient and more powerful microprocessors to meet the public's growing demand. Embedded Software: The Works covers all the key subjects embedded engineers need to understand in order to succeed, including Design and Development, Programming, Languages including C/C++, and UML, Real Time Operating Systems Considerations, Networking, and much more. New material on Linux, Android, and multi-core gives engineers the up-to-date practical know-how they need in order to succeed.

Colin Walls draws upon his experience and insights from working in the industry, and covers the complete cycle of embedded software development: its design, development, management, debugging procedures, licensing, and reuse. For those new to the field, or for experienced engineers looking to expand their skills, Walls provides the reader with detailed tips and techniques, and rigorous explanations of technologies.

Key features include:

• New chapters on Linux, Android, and multi-core – the cutting edge of embedded software development!
• Introductory roadmap guides readers through the book, providing a route through the separate chapters and showing how they are linked

About the Author

Colin Walls has over twenty-five years experience in the electronics industry, largely dedicated to embedded software. A frequent presenter at conferences and seminars and author of numerous technical articles and two books on embedded software, he is a member of the marketing team of the Mentor Graphics Embedded Software Division. He writes a regular blog on the Mentor website (blogs.mentor.com/colinwalls).

• New chapters on Linux, Android, and multi-core – the cutting edge of embedded software development!
• Introductory roadmap guides readers through the book, providing a route through the separate chapters and showing how they are linked

Chapter 1

Embedded Software

Chapter Outline

1.1 What Makes an Embedded Application Tick?

1.2 Memory in Embedded Systems

1.3 Memory Architectures

1.4 How Software Influences Hardware Design

1.5 Migrating Your Software to a New Processor Architecture

1.6 Embedded Software for Transportation Applications

1.7 How to Choose a CPU for Your System on Chip Design

1.8 An Introduction to USB Software

1.9 Toward USB 3.0

This first collection of articles either set the scene, providing a broad view of what embedded software is all about, or address a specific area that is not really encompassed by another chapter.

1.1 What Makes an Embedded Application Tick?

This is very much a “setting the scene” article, based upon one that I wrote for NewBits in late 2003 and a talk that I have delivered at numerous seminars. It introduces many embedded software issues and concepts that are covered in more detail elsewhere in this book.

CW

Embedded systems are everywhere. You cannot get away from them. In the average American household, there are around 40 microprocessors, not counting PCs (which contribute another 5–10 each) or cars (which typically contain a few dozen). And these numbers are predicted to rise by a couple of orders of magnitude over the next decade or two. It is rather ironic that most people outside of the electronics business have no idea what “embedded” actually means.

Marketing people are fond of segmenting markets. The theory is that such segmentation analysis will yield better products by fulfilling the requirements of each segment in a specific way. For embedded, we end up with segments like telecom, mil/aero, process control, consumer, and automotive. Increasingly though, devices come along that do not fit this model. For example, is a cell phone with a camera a telecom or consumer product? Who cares? An interesting area of consideration is the commonality of such applications. The major comment that we can make about them all is the amount of software in each device is growing out of all recognition. In this article, we will take a look at the inner workings of such software. The application we will use as an example is from the consumer segment—a digital camera—which is a good choice because whether or not you work on consumer devices, you will have some familiarity with their function and operation.

1.1.1 Development Challenges

Consumer applications are characterized by tight time-to-market constraints and extreme cost sensitivity. This leads to some interesting challenges in software development.

Multiple Processors

Embedded system designs that include more than one processor are increasingly common—market research suggests that, before very long, multicore designs will be the norm. A digital camera typically has two CPUs: one deals with image processing and the other looks after the general operation of the camera. The biggest challenge with multiple processors is debugging. The code on each individual device may be debugged—the tools and techniques are well understood. The challenge arises with interactions between the two processors. There is a clear need for debugging technology that addresses the issue of debugging the system—that is, multicore debugging.

Limited Memory

Embedded systems almost always have limited memory. Although the amount of memory may not be small, it typically cannot be added on demand. For a consumer application, a combination of cost and power consumption considerations may result in the quantity of memory also being restricted. Traditionally, embedded software engineers have developed skills in programming in an environment with limited memory availability. Nowadays, resorting to assembly language is rarely a convenient option. A thorough understanding of the efficient use of C and the effects and limitations of optimization are crucial.

If C++ is used (which may be an excellent language choice), the developers need to fully appreciate how the language is implemented. Otherwise, memory and real-time overheads can build up and not really become apparent until too late in the project, when a redesign of the software is not an option. Careful selection of C++ tools, with an emphasis on embedded support, is essential.

User Interface

The user interface (UI) on any device is critically important. Its quality can have a very direct influence on the success of a product. With a consumer product, the influence is overwhelming. If users find that the interface is “clunky” and awkward, their perception of not just the particular device, but also the entire brand will be affected. When it is time to upgrade, the consumer will look elsewhere.

So, getting it right is not optional. But getting it right is easier to say than do. For the most part, the UI is not implemented in hardware. The functions of the various controls on a digital camera, for example, are defined by the software. And there may be many controls, even on a basic model. So, in an ideal world, the development sequence would be:

1. Design the hardware

2. Make the prototypes

3. Implement the software (UI)

4. Try the device with the UI and refine and/or reimplement as necessary.

But we do not live in an ideal world. …

In the real world, the complexity of the software and the time-to-market constraints demand that software is largely completed long before hardware is available. Indeed, much of the work typically needs to be done even before the hardware design is finished. An approach to this dilemma is to use prototyping technology. With modern simulation technology, you can run your code, together with any real-time operating system (RTOS) on your development computer (typically Windows or Linux), and link it to a graphical representation of the UI. This enables developers to interact with the software as if they were holding the device in their hand. This capability makes checking out all the subtle UI interactions a breeze.

1.1.2 Reusable Software

Ask long-serving embedded software engineers what initially attracted them to this field of work and you will get various answers. Commonly though, the idea of being able to create something was the appeal. Compared with programming a conventional computer, constrained by the operating system and lots of other software, programming an embedded system seemed like working in an environment where the developer could be in total control. (The author, for one, admits to a megalomaniac streak.)

But things have changed. Applications are now sufficiently large and complex that it is usual for a team of software engineers to be involved. The size of the application means that an individual could never complete the work in time; the complexity means that few engineers would have the broad skill set. With increasingly short times to market, there is a great incentive to reuse existing code, whether from within the company or licensed from outside.

The reuse of designs—of intellectual property in general—is common and well accepted in the hardware design world. For desktop software, it is now the common implementation strategy. Embedded software engineers tend to be conservative and are not early adopters of new ideas, but this tendency needs to change.

Software Components

It is increasingly understood that code reuse is essential. The arguments for licensing software components are compelling, but a review of the possibilities is worthwhile.

We will now take a look at some of the key components that may be licensed and consider the key issues.

1.1.3 Real-Time Operating System

The treatment of an RTOS as a software component is not new; there are around 200 such products on the market. The differentiation is sometimes clear, but in other cases, it is more subtle. Much may be learned from the selection criteria for an RTOS.

RTOS Selection Factors

Detailed market research has revealed some clear trends in the factors that drive purchasing decisions for RTOS products.

Hard real time: “Real time” does not necessarily mean “fast”; it means “fast enough.” A real-time system is, above all, predictable and deterministic.

Royalty free: The idea of licensing some software, and then paying each time you ship something, may be unattractive. For larger volumes, in particular, a royalty-free model is ideal. A flexible business model, recognizing that all embedded systems are different, is the requirement. Of course, open source is another possibility.

Support: A modern RTOS is a highly sophisticated product. The availability of high-quality technical support is not optional.

Tools: An RTOS vendor may refer you elsewhere for tools or may simply resell some other company’s products. This practice will not yield the level of tool/RTOS integration required for efficient system development. A choice of tools is, on the other hand, very attractive.

Ease of use: As a selection factor, ease of use makes an RTOS attractive. In reality, programming a real-time system is not easy; it is a highly skilled endeavor. The RTOS vendor can help by supplying readable, commented source code, carefully integrating system components together, and paying close attention to the “out-of-box” experience.

Networking: With approximately one-third of all embedded systems being “connected,” networking is a common requirement. More on this topic later.

Broad CPU support: The support, by a given RTOS architecture, of a wide range of microprocessors is a compelling benefit. Not only does this support yield more portable code, but also the engineers’ skills may be readily leveraged. Reduced learning curves are attractive when time t...