Re: Entering the embedded world... help?


Tim Wescott wrote:

First off, what's a good processor?

Why does _everyone_ ask that. There's gazillions to choose from.

Different people ask it for different reasons. Almost half of my
upcoming book talks about roughly half a dozen different processors,
and why those specific chips might be one "correct" answer to the
question "which CPU should I learn? [to get into the embedded world]"
That's about 60,000 words on the topic, and it's only an introduction.

I'd like to code in C++ or C, but I can learn assemblers. Coding is not
a problem for me; blowing up hardware occasionally is. Because I like

Most everyone uses C or C++ these days.

I take a bit of exception to the idea that "everyone uses C++",
especially in the embedded arena. I guess it's been a few months since
this particular chestnut was sizzled on the coals in c.a.e., so maybe
we should just cut and paste the last argument thread to save
everyone's time.

I'm starting to see an approach that approximates sanity with regards
to the use of Java in high-end embedded projects, rather than C++ (a
language which is abhorred on any architecture by all right-thinking
embedded engineers - and of course, only an exceptionally jaded
masochist who has lost the phone number of his dominatrix or can no
longer afford her dungeon rates would contemplate C++ on an 8-bit
micro).

If you're prepared to live with the overhead of C++, and you're
convinced that there is something to be gained in your application from
a language that has OO syntactic elements (like C++) rather than merely
OO capability (like C), using Java instead can be a pleasant surprise.
Among other advantages of Java over C++, it is occasionally possible to
find someone who can answer a Java question both exactly and correctly.
Furthermore, positively several Java questions do not have as their
"real" answer a 5,000 word argument amongst five language lawyers. No
C++ question can be answered without either:

a) employing several language lawyers of opposing viewpoints, and/or

b) developing a new draft standard defining a version of the language
with the desired functionality.

Dogma is a wonderful thing, isn't it?

In Australian universities, they [used to?] teach a subject called
creative accounting. The core of this subject is: Your company bought
$X, sold $Y and received $Z over the past year. Your CEO, stockbroker
or drug dealer wants the company to show a profit of $F. Obtain this
result in a GAAP-compliant way.

In the past, I've seen vast practical use for this coursework in terms
of justifying (or killing) value engineering projects, obfuscating
projected bill-of-materials costs, and demonstrating that a department
has met its budgetary goals. But the single most useful fact it taught
me is that all metrics not directly derived from underlying measurable
physical phenomena are nonsense - and cost/productivity/reliability
savings realized by moving to C++ are at the bad end of the spectrum.

Moving from assembly to C at a certain [fuzzy] size/complexity point
can be justified merely in terms of the number of people that are
comfortable programming in the language (though I am quite convinced
that there's more gain than merely this one point, and most c.a.e
readers would agree with this).

Moving to C++ in embedded projects(*) requires justifications that
typically end in the words "MY GOD! A MAUVE DOLPHIN ON A BICYCLE IS
FLYING PAST THE WINDOW!" (Alt-F4 PowerPoint drivel while everyone looks
out the window). "This concludes the presentation; in summary, you
should do what I say".


(*) Special exceptions apply. These are mostly ludicrous, e.g.
designing a project that is not a PDA around Windows CE.

.

Relevant Pages

  • Re: Entering the embedded world... help?
    ... a language that has OO syntactic elements rather than merely ... using Java instead can be a pleasant surprise. ... of justifying value engineering projects, ... savings realized by moving to C++ are at the bad end of the spectrum. ...
    (comp.arch.embedded)
  • Re: Designer generated code and partial class
    ... language. ... >I have to say that I hate how VS2005 uses partial classes to hide the ... > now I'm deleting the partial class and moving the code back to the ... > window. ...
    (microsoft.public.vb.general.discussion)
  • Re: Comparing Lisp conditions to Java Exceptions
    ... All the ISO standards in the world will not make the world ... Nothing keeps you from annotating your program with exceptions based on what ... language should adhere to your theory. ... Curiously, although you don't say it, Java has the opposite problem. ...
    (comp.lang.lisp)
  • Re: casts
    ... This is why most shit programmers refuse to learn languages including ... C Sharp and Java. ... compiler in a later edition of Visual Basic, ... language for processing data. ...
    (comp.lang.c)
  • Re: C, really portable?
    ... > Wait, is Java a modern language superior to C, or is it still ... It is a much better OO language than C++, ... It depends what you are doing, Java aims for rigorous portability - the same ... regardless of platform. ...
    (comp.lang.c)