C++ in embedded systems

... snip ...

Replacing a few words in your statement, we have: "doing hi-level programming in a non-hi-level language demands ..." This applies to using assembly, and equally to using C.

The better programmers in both languages impose exactly that sort of discipline on themselves, and get very irritated at languages that do not allow them to ignore those disciplines when needed. Unfortunately many such programmers have a poor perception of 'when needed' and thus leave many incipient bugs and insecurities.

The C programmers attitude to Pascal, and the inverse, are examples. The languages are highly similar, with very similar end capabilities. Escape hatches in Pascal need to be carefully thought out to preserve reliability. External routines, file drivers, etc. come to mind. A system which allows controlled intermixing is Ada.

--
Chuck F (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net)
   Available for consulting/temporary embedded and systems.
 Click to see the full signature
Reply to
CBFalconer
Loading thread data ...

Modula-3 is another good example.

--
Grant Edwards                   grante             Yow!  My uncle Murray
                                  at               conquered Egypt in 53
 Click to see the full signature
Reply to
Grant Edwards

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.

Don't quite understand this comment.

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.

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

Should be normal practice :-)

... snip ...

I have been wrong before, but I believe that Ada modules (or am I thinking of Java, or both?) have to specify all exceptions that they may generate. Thus code linking to such modules knows what it must cater for.

--
Chuck F (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net)
   Available for consulting/temporary embedded and systems.
 Click to see the full signature
Reply to
CBFalconer

Or even the Ada spec... ;-)

Reply to
Robert Wessel

I think I have met 3 of them.

Reply to
Richard Henry

You might find this article interesting:

formatting link

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++):

formatting link

Tim

Reply to
Tim Clacy

As a C++ developer for embedded systems with some twenty years of toil behind me, I have nothing but respect for Forth developers. I envy the fact that they can develop interactively and be running code on new hardware in minutes. We have many more obstilces in our way (compiler, linker, debug target, download agent, debug client; all of these have to work before anything works). We work far from the hardware; forth developers are in contact with it.

Reply to
Tim Clacy

You are entitled to your opinion as am I.

Ian

Reply to
Ian Bell

Which is now part of ANSI C IIRC.

Ian

Reply to
Ian Bell

Including that one?

Ian

Reply to
Ian Bell

CBFalconer wrote: snip

This is the crux of the matter and the key word is gainfully. My view is that the OO metaphor/paradigm (PYO buzzword) does not of itself provide any gains in the development of embedded systems. It is not proven that it is better in this context than other design methodology.

Ian

Reply to
Ian Bell

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.

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

I agree, but again OO is neither necessary nor desirable to achieve this.

Ian

Reply to
Ian Bell

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

Reply to
Ian Bell

Tee hee. But if it was true, I would have been out of business long ago. Modern Forth compilers produce good code, and where code density matters, Forth still produces applications that are often half the size of C applications. And yes, I do have numbers to back this up for a payment terminal (8051) and an embedded web server (68xxx, H8S and ARM).

Very true. I would also add that with the exception of web weenies, very few junior programmers have used any languages other than C/C++ and perhaps Java. This in distinct comparison from 15 years ago, when most programmers in any field had actually used a much wider range of languages and had the experience to be able to select an appropriate language for a job. If you have never used interactive languages, you will never be able to appreciate what they have to offer. Remember Smalltalk, Eiffel, BASIC ... Any community misses out if its focus is on a range of culturally similar languages, programming or spoken.

Apart from OO (the current silver bullet), there is little to separate any of the batch compiled languages such as C, C++, Pascal and so on. At least Modula 2 dealt with the dependency issues.

It is August and the silly season is upon us :-)

Stephen

-- Stephen Pelc, snipped-for-privacy@mpeltd.demon.co.uk MicroProcessor Engineering Ltd - More Real, Less Time

133 Hill Lane, Southampton SO15 5AF, England tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691 web:
formatting link
- free VFX Forth downloads
Reply to
Stephen Pelc

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 "

Reply to
Tim Clacy

Yes. No absolute statements are true.

:-)

--
Chuck F (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net)
   Available for consulting/temporary embedded and systems.
 Click to see the full signature
Reply to
CBFalconer

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 ---> /* ... */

Reply to
goose

We seem to have rediscovered recursion.

Ian

Reply to
Ian Bell

Hehe. No, it just means that absolute claims are meaningless, not false or true.

Jon

Reply to
Jonathan Kirwan

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.