Design Article

The basics of programming embedded processors: Part 1

Wayne Wolf

7/24/2007 1:00 AM EDT

Designing and implementing embedded programs is different and more challenging than writing typical workstation or PC programs. Embedded code must not only provide rich functionality, it must also often run at a required rate to meet system deadlines, fit into the allowed amount of memory, and meet power consumption requirements.

Designing code that simultaneously meets multiple design constraints is a considerable challenge, but luckily there are techniques and tools that we can use to help us through the design process. Making sure that the program works is also a challenge, but once again methods and tools come to our aid.

Presented in this series of six articles we will contentrate on high-level programming languages, specifically the C language. High-level languages were once shunned as too inefficient for embedded microcontrollers, but better compilers, more compilerfriendly architectures, and faster processors and memory have made highlevel language programs common.

Some sections of a program may still need to be written in assembly language if the compiler doesn't give sufficiently good results, but even when coding in assembly language it is often helpful to think about the program's functionality in high-level form. Many of the analysis and optimization techniques that we study in this chapter are equally applicable to programs written in assembly language.

Future parts in this series will discuss (1)  the control/data flow graph as a model for high-level language programs (which can also be applied to programs written originally in assembly language) with a particular focus on design patterns; (2) the assembly and linking process; (3) the basic steps in compilation; (4) optimization techniques specific to embedded computing for energy consumption, performance and size.

Design Patterns
A design pattern is a generalized description of a way to solve a certain class of problems. As a simple example, we could write C code for one implementation of a linked list, but that code would set in concrete the data items available in the list, actions on errors, and so on.

A design pattern describing the list mechanism would capture the essential components and behaviors of the list without adding unnecessary detail. A design pattern can be described in the Unified Modeling Language (UML); it usually takes the form of a collaboration diagram, which shows how classes work together to perform a given function.

Figure 5-1 below shows a simple description of a design pattern as a UML class diagram. The diagram defines two classes: List to describe the entire list and List-element for one of the items in the list. The List class defines the basic operations that you want to do on a list.

The details of what goes in the list and so forth can be easily added into this design pattern. A design pattern can be parameterized so that it can be customized to the needs of a particular application. A more complete description of the pattern might include

  • state diagrams to describe behavior and
  • sequence diagrams to show how classes interact.
Figure 5-1. A simple description of a design pattern

Design patterns are primarily intended to help solve midlevel design challenges. A design pattern may include only a single class, but it usually describes a handful of classes.

Design patterns rarely include more than a few dozen classes. A design pattern probably will not provide you with the complete architecture of your system, but it can provide you with the architectures for many subsystems in your design:

By stitching together and specializing existing design patterns, you may be able to quickly create a large part of your system architecture.

Design patterns are meant to be used in ways similar to how engineers in other disciplines work. A designer can consult catalogs of design patterns to find patterns that seem to fit a particular design problem.

The designer can then choose parameters suited to the application and see what that implies for the implementation of the design pattern. The designer can then choose the design pattern that seems to be the best match for the design, parameterize it, and instantiate it.

  • Design patterns can be of many different types. A few are listed below.
  • The digital filter is easily described as a design pattern.
  • Data structures and their associated actions can be described as design patterns.
  • A reactive system that reacts to external stimuli can be described as a design pattern, leaving the exact state transition diagram as a parameter.
  • Douglass [Dou99] describes a policy class that describes a protocol that can be used to implement a variety of policies.

Next:




j.arantes

10/11/2007 9:19 AM EDT

This article series is a really valuable reference source.

Would it be possible to have all of this downloadable anywhere? A single PDF perhaps?

Thanks!

Sign in to Reply



SRambo

10/11/2007 10:55 AM EDT

We used this text with the permission of the publisher, Newnes/Elsevier. This series of nine articles is based on copyrighted material from "Computers as Components: Principles of Embedded Computer System Design" by Wayne Wolf. The book can be purchased on line.

--SRambo
Managing Editor
Embedded Systems Design

Sign in to Reply



sreehari.98

11/7/2007 9:58 AM EST

it's good.

Sign in to Reply



Santosh_soc

11/19/2007 5:08 AM EST

Provides good introduction of Design Patterns especially for a newbie...

Sign in to Reply



kikiran

12/6/2007 9:51 AM EST

gives an idea on the programming technique

Sign in to Reply



ahsandar

12/6/2007 10:50 AM EST

indeed a very informative article

Sign in to Reply



AZ_Paul

1/7/2008 12:37 PM EST

Good info, generally, but does anyone proofread these articles? Several mistakes. For example, where do the variables ibuff and 1buff come from? They're not defined in the example buffer code. Did the author mean ibuf?
Also, the quote, "The FIR filter of the example shown above", leaves me wondering where is the example shown above?

Sign in to Reply



penguinman

1/26/2008 11:19 PM EST

Design Patterns are a form of code re-use applicable to object orientated programming.

C is not an object orientated programming language, and design patterns are irrelevant to it's use in an embedded application.

Embedded applications are a mix of specific hardware and software for a specific application.

Design patterns and generic software design approaches are often used as a way of bypassing proper specification and design required to make an efficient low cost product for a specific purpose.

It is my opinion that object oriented programming, UML and design patterns result in bulky code and over-specified hardware.
.. there is a premise that all the effort required for one application can be re-used in another un-related application, this premise tends to make code more generic and bulky, to account for as yet undetermined uses in other un-related projects.

Sign in to Reply



bausin

1/28/2008 6:38 PM EST

Also, it's extremely bad form to cram code that properly belongs in the loop into the "update" statement of a for loop.

Sign in to Reply



nscwa

1/14/2009 9:11 AM EST

Fully agree with penguinman. Thanks for good comment.

Sign in to Reply



Please sign in to post comment

Navigate to related information

Datasheets.com Parts Search

185 million searchable parts
(please enter a part number or hit search to begin)

Feedback Form