C++ in embedded systems - Page 2

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
Re: C++ in embedded systems
Quoted text here. Click to load it

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.

Re: C++ in embedded systems
Quoted text here. Click to load it

One thing I forgot to mention: I am using the traditional C/asm
combination. I don't believe C++ brings anything to the party except
additional headaches. I haven't read any conclusive proof that C++ is
more maintainable than C, and my personal feeling is that C++ is
slower to develop and harder maintain.

Re: C++ in embedded systems

Quoted text here. Click to load it

Yes it is controversial. Whether you accept it or not, the OO approach
is the current vogue. Graduating Software Engineers are conversant
with OOA & OOD. A common language, UML, has been developed so that
analysis & design can be better expressed. There are a plethora of OO
tools available now.

Also why is software developed for embedded system any different in
quality  requirements from that of other fields? It isn't. The same
process that is adopted in the OO methodology is applicable for
embedded development. The name of the game is to produce "quality"
software. OO in itself doesn't guarantee this, but it's the associated
process & approach (in using modelling) that empowers the Software
Engineer with the ability to achieve this goal.

Quoted text here. Click to load it

Don't quite understand this comment.

Quoted text here. Click to load it

I disagree. Sure for embedded systems there is an association between
the hardware & software, but like any software system the hardware can
be mapped to drivers. I can imagine that one can write software for an
embedded system where hardware access is spaghetti-ed throughout the
code. If you do, then one is not writing their software in a fashion
that would make it easily testable. Sure one has In-Circuit Emulators
& alike, but I regard them as belated options in testing.

Where I work, we write the software such that it can be readily ported
to other platforms which may employ different micros and/or different
hardware and/or different operating systems. To remotely achieve this,
one has to delineate the hardware from the software application. Also
I'm not talking about monster applications but embedded systems based
on micros like Hitachi's SH-1, Tiny H8 & Motorola's 6805.

In a current project with the Tiny H8, we are achieving about 98%
structural (branches & conditional) unit test coverage of the Software
Application, with a test harness that runs in a console window on a PC
and about 95% structural unit test coverage of drivers that run on the
target system. That's the current status, but our goal is to achieve
100% coverage -- which we expect to do. The integrated system does fit
& run on a Tiny H8, but unfortunately, there isn't enough ROM space to
accomodate a full test harness on the target system & so it has to be
broken up.

Ken.

Quoted text here. Click to load it


+====================================+
I hate junk email. Please direct any
genuine email to: kenlee at hotpop.com

Re: C++ in embedded systems
Quoted text here. Click to load it

I agree with everything you say.  However you appear to make the
erroneous assumption that OO is the only and best methodology available.
  it is neither in my view.

Quoted text here. Click to load it

I agree.  But a hardware driver is not an OO concept.

Quoted text here. Click to load it
I agree, but again OO is neither necessary nor desirable to achieve this.

Ian


Re: C++ in embedded systems

Quoted text here. Click to load it
[snip]
Quoted text here. Click to load it

Not my intention. I was attempting to point out that the OO methology
was more likely to have supporting tools & Software Engineers that
have been trained to use it.

Quoted text here. Click to load it

Yes you are correct -- drivers are an implementation of a design goal.
The context of my point was a response to the previous poster's
comment that for embedded systems, that the dilution of the
association of the hardware & software was undesirable (in my
paraphrasing).

Quoted text here. Click to load it

Strictly speaking it isn't OO, but I see a close association with the
total Software Development Process. Chances are, if you're into OO
then you would have probably read Fowler & Scott's  "UML Distilled".
From there, if you're into producing "quality" software then you may
have perused Rational Unified Process methodology.

Now none of these "quality" methodolgies need be exclusive used with
OO, it's just that this is where it all started for me.

Ken.

Quoted text here. Click to load it


+====================================+
I hate junk email. Please direct any
genuine email to: kenlee at hotpop.com

Re: C++ in embedded systems
snip
Quoted text here. Click to load it

Now I understand you, but the point is at best moot.  Don't get me
started on tools and Software Engineers.

Quoted text here. Click to load it

We may be going round in circles here because I think it was I who
expressed that sentiment.

Quoted text here. Click to load it

THat's fine and exactly my point.  The overall objective is to design a
system which functions and performs correctly.  OO is just one way this
can be done but it is by no means the only one nor in my view the best
one for embedded systems.


Ian


Re: C++ in embedded systems
Quoted text here. Click to load it

You might find this article interesting:

http://www.codeproject.com/gen/design/theWrongObject.asp

Essentially, it's saying that OOD is good... but you need to be very
experienced before you really see the benefit. I tend to agree with that.

You might also find this article interesting (taken from a reply to a
similar C++/embedded thread in comp.lang.c++):

http://www.objectmentor.com/resources/articles/WhyAreYouStillUsingC.pdf


Tim



Re: C++ in embedded systems
Quoted text here. Click to load it

Coundn't get this url to work.  Can you confirm it is correct?

Quoted text here. Click to load it


Re: C++ in embedded systems
Quoted text here. Click to load it

Yes, it is correct. Unfortunately the entire CodeProject web-site seems to
have gone breast-up. Do try later; it's an interesting article: "A Look At
What's Wrong With Objects "

Quoted text here. Click to load it



Re: C++ in embedded systems

Quoted text here. Click to load it
It's working now.  Fascinating stuff.  Just proves that a design is
still only as good as the people doing it.

Ian


Re: C++ in embedded systems
I have the same type of background, HW designer converted to SW but I tend
to think that OOD obscures things rather than making them clear.  I have had
my engineers do a couple of embedded projects using OOD implemented in C,
but everything about it became too abstract, from the design docs to actual
code.

One of our newer engineers (competent in C++) commented that the OOD/C++
techniques that were used in C on our projects also confused the design for
him.  He thought that it got in the way of the job and added unnecessary
code in an attempt to maintain the C++ ideas in a C project.

We do projects ranging from a few hundred to a hundreds of thousands of
lines of code and I haven't yet been convinced of the value of C++ or OOD in
the type of projects we do.  Granted, I'm 50 and some of you think I'm the
dinosaur in the Dilbert cartoons, but I just don't see "objects" fitting
into the typical embedded design.  As far as I'm concerned abstraction is a
negative when you're dealing with ports, pins and low to medium level
protocols.

On the other hand, I love the // single line comment token...

--
Scott

We've slightly trimmed the long signature. Click to see the full one.
Re: C++ in embedded systems


Quoted text here. Click to load it

Which is now part of ANSI C IIRC.

Ian


Re: C++ in embedded systems
Ian Bell <ianbell> wrote in message
Quoted text here. Click to load it

only c99, and since I haven't yet come across a
c99 compiler (for embedded systems or otherwise)
that generates native object code (comeau(sp?)
generates c89 code which you must then compile
with a c89 compiler), I tend to stick to using
/* these comments */ just in case some c89
compiler out there cant be persuaded to accept
// comments at the drop of a compiler switch.


goose,
   comment of the day ---> /* ... */

Re: C++ in embedded systems
snipped-for-privacy@webmail.co.za (goose) wrote in message
Quoted text here. Click to load it

What?! Have a look at GCC. They have a lot of C99 already in, plus
they target a boatload of processors. I use it to cross-compile for
Atmel's AVR on the Windows platform.

Re: C++ in embedded systems

Quoted text here. Click to load it

ARM's RealView compilation tools have fuller C++ template support than
Visual Studio 6.0



Re: C++ in embedded systems
Hi!

Quoted text here. Click to load it

VS 6.0 was released in '98. RealView is a current product, released in '03 I
think. It's not a fair comparision. I have no experience with RealView (I
use GCC for ARM targets) but the newest VC++ (7.1) is quite
standard-conformant. As far as I remember the standard came out in '98 so VC
6.0 could hardly be fully compilant.

Regards,
Andras Tantos



Re: C++ in embedded systems
Quoted text here. Click to load it

I'll duck from which part is fair, but yes, when all is said and
done, it's up to vendors, and it is good to see that it is not
always the so-called mainstream companies.
--
Greg Comeau/4.3.3:Full C++03 core language + more Windows backends
Comeau C/C++ ONLINE ==>     http://www.comeaucomputing.com/tryitout
We've slightly trimmed the long signature. Click to see the full one.
Re: C++ in embedded systems
Quoted text here. Click to load it

Right, a "c89" compiler is not required to accept // comments.

And right, Comeau C/C++ can produce c89 c code.
Of course, it must still be custom tailored for your
platform.    Technically, that's neither here nor
there though, since the same would have to be true of
a native code compiler, although we can be many times
quicker to market.
--
Greg Comeau/4.3.3:Full C++03 core language support + more Windows backends
Comeau C/C++ ONLINE ==>     http://www.comeaucomputing.com/tryitout
We've slightly trimmed the long signature. Click to see the full one.
Re: C++ in embedded systems
Quoted text here. Click to load it

I am getting confused.. I see C99 and C98. What is the difference?

which one (if either ) is ISO C?


/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England    /\/\/\/\/\
/\/\/ snipped-for-privacy@phaedsys.org       www.phaedsys.org \/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Re: C++ in embedded systems
Quoted text here. Click to load it

I'm not sure what you're asking, since I'm not sure if you
have a typo above.   There is no C98, but there is a C++98.
That's the first C++ standard.   The second one is C++03.
C has worked similarly, and in fact is more involved.
In short, the first C standard was C89, which was "ANSI C".
It (the same document with some editorial changes) quickly
because the first "ISO C" in 1990, hence it being called C90.
Progress to C occurred a few times including 2 Technical
Corrigenda to C (I think C94 and C96), an Amendment (C95),
etc. with the last being a "major" revision of ISO C in 1999,
hence C99, which is supposed to replace all previous versions
from a formal viewpoint.   This doesn't include variants such
as POSIX aspects, but that's the general nutshell from an
ISO perspective.   Please note that these CXX names are
slang references, and not a formal name, though they do
reflect distinct changes are discussed above.
--
Greg Comeau/4.3.3:Full C++03 core language + more Windows backends
Comeau C/C++ ONLINE ==>     http://www.comeaucomputing.com/tryitout
We've slightly trimmed the long signature. Click to see the full one.

Site Timeline