HỆ THỐNG NHÚNG ĐIỆN TỬ

Elsevier US Prelims-H8583 3-8-2007 8:31p.m. Page:i Trimsize:7.5×9.25in
Fonts:Times & Legacy Sans Margins:Top:48pt Gutter:60pt Font Size:11/14 Text Width:34.6pc Depth:37 Lines
Embedded Software
Elsevier US Prelims-H8583 3-8-2007 8:31p.m. Page:ii Trimsize:7.5×9.25in
Fonts:Times & Legacy Sans Margins:Top:48pt Gutter:60pt Font Size:11/14 Text Width:34.6pc Depth:37 Lines
Newnes Know It All Series
PIC Microcontrollers: Know It All
Lucio Di Jasio, Tim Wilmshurst, Dogan Ibrahim, John Morton, Martin Bates, Jack Smith,
D.W. Smith, and Chuck Hellebuyck
ISBN: 978-0-7506-8615-0
Embedded Software: Know It All
Jean Labrosse, Jack Ganssle, Tammy Noergaard, Robert Oshana, Colin Walls, Keith Curtis,
Jason Andrews, David J. Katz, Rick Gentile, Kamal Hyder, and Bob Perrin
ISBN: 978-0-7506-8583-2
Embedded Hardware: Know It All
Jack Ganssle, Tammy Noergaard, Fred Eady, Lewin Edwards, David J. Katz, Rick Gentile,
Ken Arnold, Kamal Hyder, and Bob Perrin
ISBN: 978-0-7506-8584-9
Wireless Networking: Know It All
Praphul Chandra, Daniel M. Dobkin, Alan Bensky, Ron Olexa, David Lide, and
Farid Dowla
ISBN: 978-0-7506-8582-5
RF & Wireless Technologies: Know It All
Bruce Fette, Roberto Aiello, Praphul Chandra, Daniel Dobkin, Alan Bensky,
Douglas Miron, David Lide, Farid Dowla, and Ron Olexa
ISBN: 978-0-7506-8581-8
For more information on these and other Newnes titles visit: www.newnespress.com
Elsevier US Prelims-H8583 3-8-2007 8:31p.m. Page:iii Trimsize:7.5×9.25in
Fonts:Times & Legacy Sans Margins:Top:48pt Gutter:60pt Font Size:11/14 Text Width:34.6pc Depth:37 Lines
Embedded Software

Jean Labrosse
Jack Ganssle
Tammy Noergaard
Robert Oshana
Colin Walls
Keith Curtis
Jason Andrews
David J. Katz
Rick Gentile
Kamal Hyder
Bob Perrin
AMSTERDAM • BOSTON • HEIDELBERG • LONDON
NEW YORK • OXFORD • PARIS • SAN DIEGO
SAN FRANCISCO • SINGAPORE • SYDNEY • TOKYO
Newnes is an imprint of Elsevier
Elsevier US Prelims-H8583 3-8-2007 8:31p.m. Page:iv Trimsize:7.5×9.25in
Fonts:Times & Legacy Sans Margins:Top:48pt Gutter:60pt Font Size:11/14 Text Width:34.6pc Depth:37 Lines
Newnes is an imprint of Elsevier
30 Corporate Drive, Suite 400, Burlington, MA 01803, USA
Linacre House, Jordan Hill, Oxford OX2 8DP, UK
Copyright © 2008 by Elsevier Inc. All rights reserved.
No part of this publication may be reproduced, stored in a retrieval system, or
transmitted in any form or by any means, electronic, mechanical, photocopying,
recording, or otherwise, without the prior written permission of the publisher.
Permissions may be sought directly from Elsevier’s Science & Technology Rights
Department in Oxford, UK: phone: (+44) 1865 843830, fax: (+44) 1865 853333,
E-mail: You may also complete your request online
via the Elsevier homepage (), by selecting “Support & Contact”
then “Copyright and Permission” and then “Obtaining Permissions.”
Recognizing the importance of preserving what has been written, Elsevier

prints its books on acid-free paper whenever possible.
Library of Congress Cataloging-in-Publication Data
Embedded software/Jean Labrosse . . . [et al.]. – 1st ed.
p. cm. – (Newnes know it all series)
Includes bibliographical references and index.
ISBN-13: 978-0-7506-8583-2 (pbk. : alk. paper) 1. Embedded computer systems–
Programming. 2. Computer software–Development.
TK7895.E42E588 2008
005.26–dc22
I. Labrosse, Jean J.
2007023369
British Library Cataloguing-in-Publication Data
A catalogue record for this book is available from the British Library.
ISBN: 978-0-7506-8583-2
For information on all Newnes publications
visit our Web site at www.books.elsevier.com
07080910 987654321
Printed in the United States of America
Working together to grow
libraries in developing countries
www.elsevier.com | www.bookaid.org | www.sabre.org
Elsevier US Prelims-H8583 3-8-2007 8:31p.m. Page:v Trimsize:7.5×9.25in
Fonts:Times & Legacy Sans Margins:Top:48pt Gutter:60pt Font Size:11/14 Text Width:34.6pc Depth:37 Lines
Contents
About the Authors x
Introduction xiii
Chapter 1: Basic Embedded Programming Concepts 1
1.1 Numbering Systems 2
1.2 Signed Binary Numbers 5
1.3 Data Structures 13

1.4 Communications Protocols 29
1.5 Mathematics 37
1.6 Numeric Comparison 46
1.7 State Machines 59
1.8 Multitasking 74
Chapter 2: Device Drivers 85
2.1 In This Chapter 85
2.2 Example 1: Device Drivers for Interrupt-Handling 89
2.3 Example 2: Memory Device Drivers 110
2.4 Example 3: Onboard Bus Device Drivers 134
2.5 Board I/O Driver Examples 143
2.6 Summary 168
Chapter 3: Embedded Operating Systems 169
3.1 In This Chapter 169
3.2 What Is a Process? 175
3.3 Multitasking and Process Management 177
3.4 Memory Management 213
3.5 I/O and File System Management 230
3.6 OS Standards Example: POSIX (Portable Operating System Interface) 232
3.7 OS Performance Guidelines 235
3.8 OSes and Board Support Packages (BSPs) 237
3.9 Summary 239
www.newnespress.com
Elsevier US Prelims-H8583 3-8-2007 8:31p.m. Page:vi Trimsize:7.5×9.25in
Fonts:Times & Legacy Sans Margins:Top:48pt Gutter:60pt Font Size:11/14 Text Width:34.6pc Depth:37 Lines
vi Contents
Chapter 4: Networking 241
4.1 Introduction to the RCM3200 Rabbit Core 243
4.2 Introduction to the Dynamic C Development Environment 244
4.3 Brief Introduction to Dynamic C Libraries 246

4.4 Memory Spaces in Dynamic C 247
4.5 How Code Is Compiled and Run 256
4.6 Setting Up a PC as an RCM3200 Development System 259
4.7 Time to Start Writing Code! 259
4.8 Embedded Networks 274
4.9 Dynamic C Support for Networking Protocols 275
4.10 Typical Network Setup 279
4.11 Setting Up a Core Module’s Network Configuration 282
4.12 Project 1: Bringing Up a Rabbit Core Module for Networking 288
4.13 The Client Server Paradigm 293
4.14 The Berkeley Sockets Interface 294
4.15 Using TCP versus UDP in an Embedded Application 298
4.16 Important Dynamic C Library Functions for Socket Programming 300
4.17 Project 2: Implementing a Rabbit TCP/IP Server 303
4.18 Project 3: Implementing a Rabbit TCP/IP Client 311
4.19 Project 4: Implementing a Rabbit UDP Server 322
4.20 Some Useful (and Free!) Networking Utilities 328
4.21 Final Thought 331
Chapter 5: Error Handling and Debugging 333
5.1 The Zen of Embedded Systems Development and Troubleshooting 333
5.2 Avoid Debugging Altogether—Code Smart 340
5.3 Proactive Debugging 341
5.4 Stacks and Heaps 342
5.5 Seeding Memory 344
5.6 Wandering Code 346
5.7 Special Decoders 347
5.8 MMUs 348
5.9 Conclusion 349
5.10 Implementing Downloadable Firmware with Flash Memory 350
5.11 The Microprogrammer 350

5.12 Advantages of Microprogrammers 351
5.13 Disadvantages of Microprogrammers 351
5.14 Receiving a Microprogrammer 352
5.15 A Basic Microprogrammer 354
5.16 Common Problems and Their Solutions 355
5.17 Hardware Alternatives 362
5.18 Memory Diagnostics 364
5.19 ROM Tests 365
www.newnespress.com
Elsevier US Prelims-H8583 3-8-2007 8:31p.m. Page:vii Trimsize:7.5×9.25in
Fonts:Times & Legacy Sans Margins:Top:48pt Gutter:60pt Font Size:11/14 Text Width:34.6pc Depth:37 Lines
Contents vii
5.20 RAM Tests 367
5.21 Nonvolatile Memory 372
5.22 Supervisory Circuits 372
5.23 Multibyte Writes 374
5.24 Testing 378
5.25 Conclusion 378
5.26 Building a Great Watchdog 379
5.27 Internal WDTs 382
5.28 External WDTs 384
5.29 Characteristics of Great WDTs 386
5.30 Using an Internal WDT 389
5.31 An External WDT 391
5.32 WDTs for Multitasking 393
5.33 Summary and Other Thoughts 395
Chapter 6: Hardware/Software Co-Verification 399
6.1 Embedded System Design Process 399
6.2 Verification and Validation 401
6.3 Human Interaction 403

6.4 Co-Verification 405
Chapter 7: Techniques for Embedded Media Processing 443
7.1 A Simplified Look at a Media Processing System 445
7.2 System Resource Partitioning and Code Optimization 451
7.3 Event Generation and Handling 452
7.4 Programming Methodology 455
7.5 Architectural Features for Efficient Programming 456
7.6 Compiler Considerations for Efficient Programming 465
7.7 System and Core Synchronization 472
7.8 Memory Architecture—the Need for Management 476
7.9 Physics of Data Movement 488
7.10 Media Processing Frameworks 495
7.11 Defining Your Framework 497
7.12 Asymmetric and Symmetric Dual-Core Processors 505
7.13 Programming Models 507
7.14 Strategies for Architecting a Framework 510
7.15 Other Topics in Media Frameworks 523
Chapter 8: DSP in Embedded Systems 529
8.1 Overview of Embedded Systems and Real-Time Systems 536
8.2 Real-Time Systems 536
8.3 Hard Real-Time and Soft Real-Time Systems 537
8.4 Efficient Execution and the Execution Environment 541
www.newnespress.com
Elsevier US Prelims-H8583 3-8-2007 8:31p.m. Page:viii Trimsize:7.5×9.25in
Fonts:Times & Legacy Sans Margins:Top:48pt Gutter:60pt Font Size:11/14 Text Width:34.6pc Depth:37 Lines
viii Contents
8.5 Challenges in Real-Time System Design 542
8.6 Summary 553
8.7 Overview of Embedded Systems Development Life Cycle
Using DSP

554
8.8 The Embedded System Life Cycle Using DSP 554
8.9 Optimizing DSP Software 580
8.10 What Is Optimization? 580
8.11 The Process 581
8.12 Make the Common Case Fast 584
8.13 Make the Common Case Fast—DSP Architectures 584
8.14 Make the Common Case Fast—DSP Algorithms 587
8.15 Make the Common Case Fast—DSP Compilers 588
8.16 An In-Depth Discussion of DSP Optimization 595
8.17 Direct Memory Access 595
8.18 Using DMA 596
8.19 Loop Unrolling 604
8.20 Software Pipelining 610
8.21 More on DSP Compilers and Optimization 620
8.22 Programmer Helping Out the Compiler 633
8.23 Profile-Based Compilation 646
8.24 References 653
Chapter 9: Practical Embedded Coding Techniques 655
9.1 Reentrancy 655
9.2 Atomic Variables 656
9.3 Two More Rules 658
9.4 Keeping Code Reentrant 659
9.5 Recursion 661
9.6 Asynchronous Hardware/Firmware 661
9.7 Race Conditions 662
9.8 Options 664
9.9 Other RTOSes 665
9.10 Metastable States 666
9.11 Firmware, Not Hardware 668

9.12 Interrupt Latency 671
9.13 Taking Data 674
9.14 Understanding Your C Compiler: How to Minimize
Code
Size 677
9.15 Modern C Compilers 677
9.16 Tips on Programming 687
9.17 Final Notes 695
9.18 Acknowledgments 696
www.newnespress.com
Elsevier US Prelims-H8583 3-8-2007 8:31p.m. Page:ix Trimsize:7.5×9.25in
Fonts:Times & Legacy Sans Margins:Top:48pt Gutter:60pt Font Size:11/14 Text Width:34.6pc Depth:37 Lines
ix Contents
Chapter 10: Development Technologies and Trends 697
10.1 How to Choose a CPU for Your System on Chip Design 697
10.2 Emerging Technology for Embedded Systems Software Development 700
10.3 Making Development Tool Choices 707
10.4 Eclipse—Bringing Embedded Tools Together 721
10.5 Embedded Software and UML 725
10.6 Model-based Systems Development with xtUML 739
10.7 The Future 743
Index 745
www.newnespress.com
Elsevier US Prelims-H8583 3-8-2007 8:31p.m. Page:x Trimsize:7.5×9.25in
Fonts:Times & Legacy Sans Margins:Top:48pt Gutter:60pt Font Size:11/14 Text Width:34.6pc Depth:37 Lines
About the Authors
Jason Andrews (Chapter 6) is the author of Co-verification of Hardware and Software for
ARM SoC Design. He is currently working in the areas of hardware/software co-verification
and testbench methodology for SoC design at Verisity. He has implemented multiple
commercial co-verification tools as well as many custom co-verification solutions. His

experience in the EDA and embedded marketplace includes software development and
product management at Verisity, Axis Systems, Simpod, Summit Design, and Simulation
Technologies. He has presented technical papers and tutorials at the Embedded Systems
Conference, Communication Design Conference, and IP/SoC and written numerous articles
related to HW/SW co-verification and design verification. He has a B.S. in electrical
engineering from The Citadel, Charleston, S.C., and an M.S. in electrical engineering from
the University of Minnesota. He currently lives in the Minneapolis area with his wife,
Deborah, and their four children.
Keith Curtis (Chapter 1) is the author of Embedded Multitasking. He is currently a
Technical Staff Engineer at Microchip, and is also the author of Embedded Multitasking.
Prior to and during college, Keith worked as a technician/programmer for Summit
Engineering. He then graduated with a BSEE from Montana State University in 1986.
Following graduation, he was employed by Tele-Tech Corporation as a design and project
engineer until 1992. He also began consulting, part time, as a design engineer in 1990.
Leaving Montana in 1992, he was employed by Bally Gaming in Las Vegas as an engineer
and later as the EE manager. He worked for various Nevada gaming companies in both
design and management until 2000. He then moved to Arizona and began work as a
Principal Application Engineer for Microchip.
Jack Ganssle (Chapters 5 and 9) is the author of The Firmware Handbook. He has written
over 500 articles and six books about embedded systems, as well as a book about his sailing
fiascos. He started developing embedded systems in the early 70s using the 8008. He’s
started and sold three electronics companies, including one of the bigger embedded tool
www.newnespress.com
Elsevier US Prelims-H8583 3-8-2007 8:31p.m. Page:xi Trimsize:7.5×9.25in
Fonts:Times & Legacy Sans Margins:Top:48pt Gutter:60pt Font Size:11/14 Text Width:34.6pc Depth:37 Lines
xi About the Authors
businesses. He’s developed or managed over 100 embedded products, from deep-sea
navigation gear to the White House security
system and one instrument that analyzed
cow poop! He’s currently a member of NASA’s Super Problem Resolution Team, a group

of outside experts formed to advise NASA in the wake of Columbia’s demise, and serves on
the boards of several high-tech companies. Jack gives seminars to companies world-wide
about better ways to develop embedded systems.
Rick Gentile (Chapter 7) is the author of Embedded Media Processing. Rick joined ADI in
2000 as a Senior DSP Applications Engineer and he currently leads the Processor
Applications Group, which is responsible for Blackfin, SHARC, and TigerSHARC
processors. Prior to joining ADI, Rick was a member of the Technical Staff at MIT Lincoln
Laboratory, where he designed several signal processors used in a wide range of radar
sensors. He has authored dozens of articles and presented at multiple technical conferences.
He received a B.S. in 1987 from the University of Massachusetts at Amherst and an M.S. in
1994 from Northeastern University, both in Electrical and Computer Engineering.
Kamal Hyder (Chapters 4 and 5) is the author of Embedded Systems Design Using the
Rabbit 3000
Microprocessor. He started his career with an embedded microcontroller
manufacturer. He then wrote CPU microcode for Tandem Computers for a number of years
and was a Product Manager at Cisco Systems, working on next-generation switching
platforms. He is currently with Brocade Communications as Senior Group Product Manager.
Kamal’s BS is in EE/CS from the University of Massachusetts, Amherst, and he has an
MBA in finance/marketing from Santa Clara University.
David J. Katz (Chapter 7) is the author of Embedded Media Processing. He has over 15
years of experience in circuit and system design. Currently, he is the Blackfin Applications
Manager at Analog Devices, Inc., where he focuses on specifying new convergent
processors. He has published over 100 embedded processing articles domestically and
internationally and has presented several conference papers in the field. Previously, he
worked at Motorola, Inc., as a senior design engineer in cable modem and automation
groups. David holds both a B.S. and M. Eng. in Electrical Engineering from Cornell
University.
Jean Labrosse (Chapter 3) is the author of MicroC/OS-II and Embedded Systems Building
Blocks. Dr. Labrosse is President of Micrium whose flagship product is the Micrium
�C/OS-II. He has an MSEE and has been designing embedded systems for many years.

Tammy Noergaard (Chapters 2 and 3) is the author of Embedded Systems Architecture.
Since beginning her embedded systems career in 1995, she has had wide experience in
www.newnespress.com
Elsevier US Prelims-H8583 3-8-2007 8:31p.m. Page:xii Trimsize:7.5×9.25in
Fonts:Times & Legacy Sans Margins:Top:48pt Gutter:60pt Font Size:11/14 Text Width:34.6pc Depth:37 Lines
xii About the Authors
product development, system design and integration, operations, sales, marketing, and
training. Noergaard worked for Sony as a lead software engineer developing and testing
embedded software for analog TVs. At Wind River she was the liaison engineer between
developmental engineers and customers to provide design expertise, systems configuration,
systems integration, and training for Wind River embedded software (OS, Java, device
drivers, etc.) and all associated hardware for a variety of embedded systems in the Consumer
Electronics market. Most recently she was a Field Engineering Specialist and Consultant
with Esmertec North America, providing project management, system design, system
integration, system configuration, support, and expertise for various embedded Java systems
using Jbed in everything from control systems to medical devices to digital TVs. Noergaard
has lectured to engineering classes at the University of California at Berkeley and Stanford,
the Embedded Internet Conference, and the Java User’s Group in San Jose, among others.
Robert Oshana (Chapter 8) is the author of DSP Software Development Techniques. He has
over 25 years of experience in the real-time embedded industry, in both embedded
application development as well as embedded tools development. He is currently director of
engineering for the Development Technology group at Freescale Semiconductor. Rob is
also a Senior Member of IEEE and an adjunct at Southern Methodist University. He can be
contacted at:
Bob Perrin (Chapters 4 and 5) is the author of Embedded Systems Design Using the Rabbit
3000
Microprocessor. He got his start in electronics at the age of nine when his mother gave
him a “150-in-one Projects” kit from Radio Shack for Christmas. He grew up programming
a Commodore PET. In 1990, Bob graduated with a BSEE from Washington State
University. Since then, Bob has been working as an engineer designing digital and analog

electronics. He has published about twenty technical articles, most with Circuit
Cellar.
Colin Walls (Introduction and Chapter 10) is the author of Embedded Software: The Works.
He 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, Colin is a member
of the marketing team of the Mentor Graphics Embedded Systems Division. Colin is based
in the UK.
www.newnespress.com
Elsevier US Prelims-H8583 3-8-2007 8:31p.m. Page:xiii Trimsize:7.5×9.25in
Fonts:Times & Legacy Sans Margins:Top:48pt Gutter:60pt Font Size:11/14 Text Width:34.6pc Depth:37 Lines
Introduction
Colin Walls
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). In addition,
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 book, we
will look at the inner workings of such software. The application we will use as an example
is from the consumer segment—a digital camera—that is a good choice because whether or
not you work on consumer devices, you will have some familiarity with their function and
operation.

I.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.
I.1.1 Multiple Processors
Embedded system designs that include more than one processor are increasingly common.
For example, a digital camera typically has two: one deals with image processing and the
www.newnespress.com
Elsevier US Prelims-H8583 3-8-2007 8:31p.m. Page:xiv Trimsize:7.5×9.25in
Fonts:Times & Legacy Sans Margins:Top:48pt Gutter:60pt Font Size:11/14 Text Width:34.6pc Depth:37 Lines
xiv Introduction
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.
I.1.2 Limited Memory
Embedded systems usually 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.
I.1.3 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.
Therefore, getting it right is not optional. However, 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. In addition, there
may be many controls, even on a basic model. Therefore, in an ideal world, the development
sequence would be:
1. Design the hardware.
2. Make the prototypes.
www.newnespress.com
Elsevier US Prelims-H8583 3-8-2007 8:31p.m. Page:xv Trimsize:7.5×9.25in
Fonts:Times & Legacy Sans Margins:Top:48pt Gutter:60pt Font Size:11/14 Text Width:34.6pc Depth:37 Lines
xv Introduction
3. Implement the software (UI).
4. Try the device with the UI and refine and/or reimplement as necessary.
However, 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 (for example, RTOS) on your
development computer (Windows, Linux, or UNIX), 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.
I.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.)
However, 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.
I.2.1 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.
www.newnespress.com
Elsevier US Prelims-H8583 3-8-2007 8:31p.m. Page:xvi Trimsize:7.5×9.25in
Fonts:Times & Legacy Sans Margins:Top:48pt Gutter:60pt Font Size:11/14 Text Width:34.6pc Depth:37 Lines
xvi Introduction
We will now take a look at some of the key components that may be licensed and consider
the key issues.
I.3 Real-Time Operating System
The treatment of a real-time operating system (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.
I.3.1 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.
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.
www.newnespress.com
Elsevier US Prelims-H8583 3-8-2007 8:31p.m. Page:xvii Trimsize:7.5×9.25in
Fonts:Times & Legacy Sans Margins:Top:48pt Gutter:60pt Font Size:11/14 Text Width:34.6pc Depth:37 Lines
Introduction xvii
Broad computer processing unit (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.
I.3.2 RTOS Standards

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 book and worthy of a chapter devoted exclusively to it.
OSEK: The short name for the increasingly popular OSEK/VDX standard, OSEK is
widely applied in automotive and similar applications.
miTRON: 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 application-programming interface (API) is understood by
many programmers worldwide. The API may be implemented as a wrapper on top of a
proprietary RTOS.
I.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.
I.5 Universal Serial Port (USB)
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 operating system (OS) was up to.
Whatever its critics may say, Windows is easier to use, but you will find it hard
www.newnespress.com
Elsevier US Prelims-H8583 3-8-2007 8:31p.m. Page:xviii Trimsize:7.5×9.25in
Fonts:Times & Legacy Sans Margins:Top:48pt Gutter:60pt Font Size:11/14 Text Width:34.6pc Depth:37 Lines
xviii Introduction
(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 are 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.
USB has one limitation, which restricts its potential flexibility: a strict master/slave
architecture. This situation will change, as a new standard, USB On-the-Go (OTG), has been
agreed upon and will start showing up in new products. This standard allows devices to
change their master/slave status, as required. Therefore, USB gets easier to use and—guess
what—the underlying software becomes even more complex. Many off-the-shelf USB
packages are available.
I.6 Graphics
The liquid crystal display (LCD) panel on the back of a camera has two functions: it is a
graphical output device and part of the user interface (UI). Each of these functions needs to
be considered separately.
As a graphical output device, an LCD is quite straightforward to program. Just setting red,
green, and blue (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 graphic user interface (GUI), facilities are required to draw screen elements
(buttons, icons, menus, and so forth) and handle input from pointing devices. An additional
library, on top of the basic graphics functions, is required.
I.7 Networking
An increasing number of embedded systems are connected either to the Internet or to other
devices or networks. This may not sound applicable to our example of a digital camera, but
www.newnespress.com
Elsevier US Prelims-H8583 3-8-2007 8:31p.m. Page:xix Trimsize:7.5×9.25in

Fonts:Times & Legacy Sans Margins:Top:48pt Gutter:60pt Font Size:11/14 Text Width:34.6pc Depth:37 Lines
Introduction xix
Bluetooth connectivity is quite common and even wireless local area networks (more
commonly referred to as Wi-Fi)-enabled cameras have been demonstrated.
A basic Transmission Control Protocol/Internet Protocol (TCP/IP) stack may be
straightforward to implement, but adding all the additional applications and protocols is
quite another matter. Some key issues are worthy of further consideration.
I.8 IPv6
Internet Protocol (IP) is the fundamental protocol of the Internet, and the currently used
variant is v4. The latest version is v6. (Nobody seems to know what happened to v5.) To
utilize IPv6 requires new software because the protocol is different in quite fundamental
ways. IPv6 addresses a number of issues with IPv4. The two most noteworthy are security
(which is an add-on to IPv4 but is specified in IPv6) and address space. IPv6 addresses are
much longer and are designed to cover requirements far into the future (see Figure I.1).
Figure I.1: IPv6 Addresses
If you are making Internet-connected devices, do you need to worry about IPv6 yet?
If your market is restricted to nonmilitary/nongovernment customers in North America, IPv6
will not be a requirement for a few years. If your market extends to Asia or Europe or
encompasses military applications, you need to consider IPv6 support now. You also need to
consider support for dual stacks and IPv6/IPv4 tunneling.
I.8.1 Who Needs a Web Server?
The obvious answer to this question is “someone who runs a web site,” but, in the
embedded context, there is another angle.
www.newnespress.com
Elsevier US Prelims-H8583 3-8-2007 8:31p.m. Page:xx Trimsize:7.5×9.25in
Fonts:Times & Legacy Sans Margins:Top:48pt Gutter:60pt Font Size:11/14 Text Width:34.6pc Depth:37 Lines
xx Introduction
Imagine that you have an embedded system and you would like to connect to it from a PC
to view the application status and/or adjust the system parameters. This PC may be local, or
it could be remotely located, connected by a modem, or even over the Internet; the PC may

also be permanently linked or just attached when required.
What work would you need to do to achieve this? The following tasks are above and beyond
the implementation of the application code:
• Define/select a communications protocol between the system and the PC.
• Write data access code, which interfaces to the application code in the system and drives
the communications protocol.
• Write a Windows program to display/accept data and communicate using the specified
protocol.
Additionally, there is the longer-term burden of needing to distribute the Windows software
along with the embedded system and update this code every time the application is changed.
An alternative approach is to install web server software in the target system. The result is:
• The protocol is defined: HyperText Transfer Protocol (HTTP).
• You still need to write data access code, but it is simpler; of course, some web pages
(HyperText Markup Language; HTML) are also needed, but this is straightforward.
• On the PC you just need a standard web browser.
The additional benefits are that there are no distribution/maintenance issues with the
Windows software (everything is on the target), and the host computer can be anything
(it need not be a Windows PC). A handheld is an obvious possibility.
The obvious counter to this suggestion is size: web servers are large pieces of software. An
embedded web server may have a memory footprint as small as 20 K, which is very modest,
even when storage space for the HTML files is added.
I.8.2 SNMP
SNMP (Simple Network Management Protocol) is a popular remote access protocol, which
is employed in many types of embedded devices. The current version of the specification
is v3.
www.newnespress.com
Elsevier US Prelims-H8583 3-8-2007 8:31p.m. Page:xxi Trimsize:7.5×9.25in
Fonts:Times & Legacy Sans Margins:Top:48pt Gutter:60pt Font Size:11/14 Text Width:34.6pc Depth:37 Lines
Introduction xxi
SNMP offers a very similar functionality to a web server in many ways. How might you

select between them?
If you are in an industry that uses SNMP routinely, the choice is made for you. If you need
secure communications (because, for example, you are communicating with your system
over the Internet), SNMP has this capability intrinsically, whereas a web server requires a
secure sockets layer (SSL). On the other hand, if you do not need the security, you will have
an unwanted memory and protocol overhead with SNMP.
A web server has the advantage that the host computer software is essentially free, whereas
SNMP browsers cost money. The display on an SNMP browser is also somewhat fixed;
with a web server, you design the HTML pages and control the format entirely.
I.9 Conclusion
As we have seen, the development of a modern embedded system, such as a digital camera,
presents many daunting challenges. With a combination of the right skills and tools and a
software-component-based development strategy, success is attainable. The challenges,
tools, and some solutions will be considered in the pages of this book.
www.newnespress.com
Elsevier US Prelims-H8583 3-8-2007 8:31p.m. Page:xxii Trimsize:7.5×9.25in
Fonts:Times & Legacy Sans Margins:Top:48pt Gutter:60pt Font Size:11/14 Text Width:34.6pc Depth:37 Lines
This page intentionally left blank
Elsevier US Ch01-H8583 21-7-2007 11:51a.m. Page:1 Trimsize:7.5×9.25in
Fonts:Times & Legacy Sans Margins:Top:48pt Gutter:60pt Font Size:11/14 Text Width:34.6pc Depth:37 Lines
CHAPTER 1
Basic Embedded Programming Concepts
Keith Curtis
The purpose of this first chapter is to provide the software designer with some basic
concepts and terminology that will be used later in the book. It covers binary numbering
systems, data storage, basic communications protocols, mathematics, conditional statements,
state machines, and basic multitasking. These concepts are covered here not only to refresh
the designer’s understanding of their operations but also to provide sufficient insight so that
designers will be able to “roll their own” functions if needed. While this chapter is not
strictly required to understand the balance of the book, it is recommended.

It is understandable why state machines and multitasking needs review, but why are all the
other subjects included? And why would a designer ever want to “roll my own” routines?
That is what a high-level language is for, isn’t it? Well, often in embedded design, execution
speed, memory size, or both will become an issue. Knowing how a command works allows
a designer to create optimized functions that are smaller and/or faster than the stock
functions built into the language. It also gives the designer a reference for judging how
efficient a particular implementation of a command may be. Therefore, while understanding
how a command works may not be required in order to write multitasking code, it is very
valuable when writing in an embedded environment.
For example, a routine is required to multiply two values together, a 16-bit integer, and an
8-bit integer. A high-level language compiler will automatically type-convert the 8-bit value
into a 16-bit value and then performs the multiplication using its standard 16×16 multiply.
This is the most efficient format from the compiler’s point of view, because it only requires
an 8×8 multiply and 16×16 multiply in its library. However, this does creates two
inefficiencies; one, it wastes two data memory locations holding values that will always be
zero and, two, it wastes execution cycles on 8 additional bits of multiply that will always
result in a zero.
www.newnespress.com
Elsevier US Ch01-H8583 21-7-2007 11:51a.m. Page:2 Trimsize:7.5×9.25in
Fonts:Times & Legacy Sans Margins:Top:48pt Gutter:60pt Font Size:11/14 Text Width:34.6pc Depth:37 Lines
2 Chapter 1
The more efficient solution is to create a custom 8×16 multiply routine. This saves the
2 data bytes and eliminates the wasted execution time spent multiplying the always-zero
MSB of the 8-bit value. Also, because the routine can be optimized now to use an 8-bit
multiplicand, the routine will actually use less program memory as it will not have the
overhead of handling the MSB of the multiplicand. So, being able to “roll your own” routine
allows the designer to correct small inefficiencies in the compiler strategy, particularly
where data and speed limitations are concerned.
While “rolling your own” multiply can make sense in the example, it is not the message of
this chapter that designers should replace all of the built-in functions of a high-level

language. However, knowing how the commands in a language work does give designers
the knowledge of what is possible for evaluating a suspect function and, more importantly,
how to write a more efficient function if it is needed.
1.1 Numbering Systems
A logical place to start is a quick refresher on the base-ten number system and the
conventions that we use with it. As the name implies, base ten uses ten digits, probably
because human beings have ten fingers and ten toes so working in units or groups of ten is
comfortable and familiar to us. For convenience in writing, we represent the ten values with
the symbols “0123456789.”
To represent numbers larger than 9, we resort to a position-based system that is tied to
powers of ten. The position just to the left of the decimal point is considered the ones
position, or 10 raised to the zeroth power. As the positions of the digits move to the left of
the decimal point, the powers of ten increase, giving us the ability to represent ever-larger
large numbers, as needed. So, using the following example, the number 234 actually
represents 2 groups of a hundred, 3 groups of ten plus 4 more. The left-most value,
2, represents 10ˆ2. The 3 in the middle represents 10ˆ1, and the right-most 4 represents
1 or 10ˆ0.
Example 1.1
234
2 *10^2= 200
3 *10^1= 30
4 *10^0= + 4
234
www.newnespress.com