Design Patterns for Embedded Systems in C

An Embedded Software Engineering Toolkit

Bruce Powel Douglass

• Publisher: Newnes
• Year: 2010
• ISBN:
  9780080959719
• Topic: Ciencia de la computación
• Subtopic: Hardware

A recent survey stated that 52% of embedded projects are late by 4-5 months. This book can help get those projects in on-time with design patterns. The author carefully takes into account the special concerns found in designing and developing embedded applications specifically concurrency, communication, speed, and memory usage. Patterns are given in UML (Unified Modeling Language) with examples including ANSI C for direct and practical application to C code. A basic C knowledge is a prerequisite for the book while UML notation and terminology is included. General C programming books do not include discussion of the contraints found within embedded system design. The practical examples give the reader an understanding of the use of UML and OO (Object Oriented) designs in a resource-limited environment. Also included are two chapters on state machines. The beauty of this book is that it can help you today..

• Design Patterns within these pages are immediately applicable to your project
• Addresses embedded system design concerns such as concurrency, communication, and memory usage
• Examples contain ANSI C for ease of use with C programming code

Chapter 1 What Is Embedded Programming?

Chapter Outline

1. What’s Special About Embedded Systems? 1
   1. Embedded Design Constraints 3
   2. The Embedded Tool Chain 4
   3. OS, RTOS, or Bareback? 5
   4. Embedded Middleware 6
   5. Codevelopment with Hardware 7
   6. Debugging and Testing 8
2. OO or Structured – It’s Your Choice 9
   1. Classes 10
   2. Objects 13
   3. Polymorphism and Virtual Functions 14
   4. Subclassing 15
   5. Finite State Machines 25
3. What Did We Learn? 33

What you will learn

• Basics of embedded systems
• OO versus structured programming
• Implementing classes, inheritance, and state machines in C

This book focuses solely on embedded systems development. In doing so, it is drawing a distinction between “embedded” systems and “others.” Before we get into the depth of the discussion, we need to understand what this difference is so that we can appreciate what it forebodes with respect to the patterns and technologies we will use to develop embedded systems.

1.1 What’s Special About Embedded Systems?

This book focuses solely on embedded systems development. In doing so, it is drawing a distinction between “embedded” systems and “others.” Before we get into the depth of the discussion, we need to understand what this difference is so that we can appreciate what it forebodes with respect to the patterns and technologies we will use to develop embedded systems.

I define an embedded system as “a computerized system dedicated to performing a specific set of real-world functions, rather than to providing a generalized computing environment.” Clearly, this is a broad categorization that includes tiny 8-bit computers embedded in cardiac pacemakers, linked 32-bit computers controlling avionics, communications, fire control for aircraft, and wide-area networks composed of hundreds of powerful computer systems for battlefield management in C⁴ISR (Command, Control, Communications, Computers, Intelligence, Surveillance, and Reconnaissance) systems. Many embedded systems have no disks, human interface, and barely any memory but the scope of the embedded systems market is far broader than such simple devices.

Embedded systems are everywhere:

• In the medical field, embedded systems include implantable devices (e.g., cardiac pacemakers, defibrillators, and insulin pumps), monitoring equipment (e.g., ECG/EKG monitors, blood gas monitors, blood pressure monitors, EMG monitors), imaging systems (e.g., CT, SPECT, PET, TEM, and x-ray imagers), and therapy delivery devices (e.g., patient ventilator, drug vaporizers, and infusion pumps).
• In the telecom market, there are devices ranging from cell phones, switching systems, routers, modems, and satellites.
• In automotive environments, embedded systems optimize engine combustion, manage power delivery in transmissions, monitor sensor data, control anti-lock braking, provide security, and offer infotainment services such as CD and DVD players, and GPS routing (in some locations, they can offer radar and laser detection and even active radar and laser countermeasures).
• In the office, embedded systems manage phones, printers, copies, fax machines, lights, digital projectors, security systems, and fire detection and suppression systems.
• In the home, examples include ovens, televisions, radios, washing machines, and even some vacuum cleaners.

Embedded systems already control, augment, monitor, and manage virtually every high-tech device we have from televisions to trains to factory automation, and their use is on the rise.

An important subset of embedded systems are real-time systems. Many people have the mistaken impression that “real time” means “real fast” but that is not true. A real-time system is one in which timeliness constraints must be satisfied for system correctness. A common, if simplistic, categorization of real-time systems is into two groups. “Hard” real-time systems are ones in which timeliness constraints are modeled as deadlines, points in time by which the execution of specific actions are required to be complete. “Soft” real-time systems are those that are not “hard”¹ ; that is, some other (usually stochastic) measure than deadlines is used to determine timeliness. This may include average throughput, average execution time, maximum burst length, or some other measure. All systems may be modeled as hard real-time systems, but this often results in “over-designing” the system to be faster or have more available resources than is necessary, raising the recurring cost (approximately “manufacturing cost”) of the system.

Even though all systems may be modeled as hard real-time systems, in actual fact, most are not. If the response is occasionally delayed or even an entire input event is missed, most systems will continue to function properly. The primary reason for modeling real-time systems as “hard” is because it eases the assurance of the system’s timeliness through mathematical analysis.

1.1.1 Embedded Design Constraints

From the inside, one of the most striking characteristics of embedded systems is severity of their constraints. Unlike writing software for a general-purpose computer, an embedded system is usually shipped already integrated with al...