Re: C++ in embedded systems

From: Lewin A.R.W. Edwards (larwe_at_larwe.com)
Date: 08/14/03


Date: 14 Aug 2003 10:22:18 -0700


> My personal (and possibly controversial) view is that OOD is a complete

In embedded systems, pretty nearly any view is controversial, because
the field covers such a wide variety of needs and capabilities.

I'll give you two instances in a current 32-bit project of mine where
OOD is useful:

1. Network interfaces. When I was working on the first version of this
project, our hardware had one wired Ethernet interface. I chose to
implement the network functions and variables as a set of "methods"
and variables encapsulated in a network I/F "class". Soon after
release, we started to work on units with dual Ethernet, and units
with a mix of 1,2 or 4 Ethernet ports and 0, 1 or 2 wireless Ethernet
ports.

There are two places where this has saved me effort:

a) Startup code. Instead of having to call disparate functions to
bring up the interfaces and load configurations, I simply call the
load-config and bring-up methods of each object.

b) UI code. I wrote a single piece of UI code to edit network
interface configuration. It's easier for me to call the same function
with different config pointers than it is to craft slightly different
functions for the same net result.

2. GUI
The GUI is encapsulated in a "GDI" object, which contains methods to
identify if the environment is compatible with the GDI's code, and
various display parameters, as well as primitives for line draw,
flood-fill, various simple shapes, image scaling and rotation, text
rendering, and other functionality. So far, we've written two
substantially different GDIs optimized for different types of
framebuffers. I'm looking at a third GDI that will use OpenGL.

In both cases, I believe that the thought and planning that went into
encapsulating the relevant data and functions were an enormous help in
keeping platform-specific code isolated from platform-dependent code.
We're looking at porting down to an ARM or XScale design (from x86) in
the near future, and in this world every day of development time
counts. I don't believe there is any significant overhead; one extra
32-bit pointer on the stack is about it.

At its simplest, OO implementation can just be deciding to put
everything in a struct and passing a pointer to that struct to every
function that needs it (equivalent of C++'s "this") rather than
declaring a bevy of global variables.