- Shopping Bag ( 0 items )
Embedded software needs have grown exponentially over the past quarter century. In 1975 writing 10,000 lines of assembly code was a considered a huge undertaking. Today, a cell phone can contain five million lines of C or C++! Embedded software 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. This practical guide, written by industry pioneer Colin Walls, helps embedded design engineers to rise to that challenge.
The author offers expertise and insights from his quarter century of design experience, covering a plethora of major concerns in an easy-to-reference essay format that provides the reader with detailed tips and techniques, and rigorous explanations of technologies. Contributions from other well-known designers in the embedded systems field offer additional seasoned perspectives on everything from exotic memories to USB software. This one book has an amazing breadth of coverage, undertaking 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, Programmable Logic and much more.
For those in the field who are looking to broaden their professional skill-sets in order to advance, as well as those "newbies" just entering the field of embedded systems design, this comprehensive new reference is a must-have!
The accompanying CD-ROM contains source code for the many real-world examples in the text, to save readers from needless re-typing. Also included are PowerPoint slides to create trainingseminars or classes from the text, and various product-related spec sheets. Provides an amazing breadth of coverage by undertaking all the key subjects embedded engineers need to understand
1.1 What Makes an Embedded Application Tick? 1 1.2 Memory in Embedded Systems 8 1.3 Memory Architectures 12 1.4 How Software Influences Hardware Design 18 1.5 Migrating Your Software to a New Processor Architecture 22 1.6 Embedded Software for Transportation Applications 29 1.7 How to Choose a CPU for Your System on Chip Design 33 1.8 An Introduction to USB Software 36 1.9 Toward USB 3.0 40
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.
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.
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.
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.
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 to market is tight.
There is increasing interest in industry-wide RTOS standards, such as OSEK, POSIX (Portable Operating System Interface), and µiTRON. This subject is wide ranging, rather beyond the scope of this article and worthy of one devoted exclusively to it.
OSEK: The short name for the increasingly popular OSEK/VDX standard, OSEK is widely applied in automotive and similar applications.
µiTRON: The majority of embedded designs in Japan use the iTRON architecture. This API may be implemented as a wrapper on top of a proprietary RTOS, thus deriving benefit from the range of middleware and CPU support.
POSIX: This standard UNIX API is understood by many programmers worldwide. The API may be implemented as a wrapper on top of a proprietary RTOS.
1.1.4 File System
A digital camera will, of course, include some kind of storage medium to retain the photographs. Many embedded systems include some persistent storage, which may be magnetic or optical disk media or nonvolatile memory (such as flash). In any case, the best approach is standards based, such as an MS-DOS-compatible file system, which would maximize the interoperability possibilities with a variety of computer systems.
There is increasing demand for a fault-tolerant flash file system with wear-leveling support to protect against power failure and maximize the usable lifetime of media.
There is a seemingly inviolate rule in the high-tech world: the easier something is to use, the more complex it is "under the hood."
Take PCs for example. MS-DOS was very simple to understand; read a few hundred pages of documentation and you could figure out everything the OS was up to. Whatever its critics may say, Windows is easier to use, but you will find it hard (no, impossible) to locate anyone who understands everything about its internals; it is incredibly complex.
USB fits this model. Only a recollection of a few years' experience in the pre-USB world can make you appreciate how good USB really is. Adding a new peripheral device to a PC could not be simpler. The electronics behind USB is not particularly complex; the really smart part is the software. Developing a USB stack, either for the host computer or for a peripheral device, is a major undertaking. The work has been done for host computers—USB is fully supported on Windows and other operating systems. It makes little sense developing a stack yourself for a USB-enabled device. Many off-the-shelf USB packages are available.
The LCD panel on the back of a camera has two functions: it is a graphical output device and part of the UI. Each of these functions needs to be considered separately.
As a graphical output device, an LCD is quite straightforward to program. Just setting RGB values in memory locations results in pixels being lit in appropriate colors. However, on top of this underlying simplicity, the higher-level functionality of drawing lines and shapes, creating fills, and displaying text and images can increase complexity very rapidly. A graphic functions library is required.
To develop a GUI, facilities are required to draw screen elements (buttons, icons, menus, etc.) and handle input from pointing devices. An additional library, on top of the basic graphics functions, is required.
Excerpted from Embedded Software: The Works by Colin Walls Copyright © 2012 by Mentor Graphics. Excerpted by permission of Newnes. All rights reserved. No part of this excerpt may be reproduced or reprinted without permission in writing from the publisher.
Excerpts are provided by Dial-A-Book Inc. solely for the personal use of visitors to this web site.