Re: 16/32 bit processor for OS development

On Sep 6, 6:53 am, "Steve at fivetrees" <st...@xxxxxxxxxxxxxxxxxxxxx>
"Jonathan Kirwan" <jkir...@xxxxxxxxxxxxxx> wrote in message


On Thu, 6 Sep 2007 00:49:13 +0100, "Steve at fivetrees"
<st...@xxxxxxxxxxxxxxxxxxxxx> wrote:

"Ed Prochak" <edproc...@xxxxxxxxx> wrote in message

The key point is, as I like to phrase it, that an embedded system
looks like a "whatever" device to the end user. The end user should
not perceive that there is a computer involved. They might be aware
there is a computer used but they do not interact with the device
they do a PC. That's what makes it embedded, not the size, cost,
realtime constraints, custom peripherals or other contstraints.


Hi, Steve. I hadn't been reading this thread but I do take the time
to read you. Anyway, I think this remains a matter of from whose
perspective the question is asked. If you are asking about it from a
user's perspective, then all the above seems true enough. If you are
asking about it from a programmer's perspective, then the question of
"what is embedded" takes on a different frame to me. I'll explain.

The above definition, using the user's perspective, might be somewhat
meaningful when you are talking to non-technical folks. In other
words, they often have an idea about computers. If you are using
'embedded' with them to admit the fact that there is a computer
inside, but to also point out that it's not like their "home computer"
in the sense that they don't notice it being there (for example, as in
a new, green energy washing machine) then I suppose the term has value
for that. An end user can "get it" that there probably is a computer
in there and they might like to hear more, now that they know it. (You
might like to tell them that it is, for example, a cpu that is capable
of playing video games sitting inside their washer. They might like
to hear that and could understand the idea.)

But in that case, embedded is just another way of saying that a user
doesn't immediately recognize the presence of a computer. Which you
can already say by simply saying it, instead of adding another meaning
to the word and then having to teach it to user after user after user.
In other words, it's not a term users use much and they don't need it,
really. They can say the same thing to each other without ever
knowing the word, by just telling each other about the "computer in
there." Trying to say that the word, embedded, should be defined by
the needs of end users for such a term, and I mean end users otherwise
unfamiliar with the idea, is really nonsense to me. They don't need
that word, would take education to get them to user it properly, etc.
Why bother, at all?

Now, on the other hand, the term has a great deal of practical need
and everyday use within the programming world. Why? Because of the
tool differences involved, programming proximity to as well as
personal hardware familiarities required, mathematical and signal
processing skills not uncommonly required, etc. In other words, it's
not like prorgamming a very general purpose minicomputer or
workstation. In that arena, the term has real purpose to it in
dividing those with and without good experience here (a lack of which,
of course, does not reflect in any way their experience in other
arenas.) You might actually want to hire an embedded programmer and,
by that if you are using the term without conflating it to the point
of near uselessness, you usually mean someone who isn't unfamiliar
with the range of skills and background associated with programming
closer to hardware than those using general purpose operating systems
often do. This often includes, for example, understing a little more
about the linking process. Just as an example of what I'm talking

The short of it is that I don't see allowing a user perspective to
define a word they frankly don't even need. On the other hand, we
programmers DO need the distinction and to my mind that need is what
should shape the meaning of it. Users can go get their own words for
needs they really do have. ;)

Your point totally taken. My earlier one-word response was obviously a
tad minimal ;).

My take: to the user, it's a black box. Whether the implementation is
fully analogue, fully digital, or a CPU and code, is of no interest. It
does the job. The contents are a matter of economics and pragmatism.

To the designer, yes, it's a whole nuther ballgame. I'm actively wary of
allowing programmers from a desktop background loose on an embedded
project. For me, the key difference is not in the technicalities of
linkage or tools (although these of course matter), it's in the degree
of code quality needed. The malloc issue comes up. Exception handling
comes up. My maxim of "It Must Not Crash" comes up ;). If the product
were fully analogue or fully digital, and it crashed, it would be
considered broken. The same MUST apply to the CPU+code platform. This is
often very alien to the desktop people who have become immune to BSODs

... All of which I've said many times before. Still, I hadn't yet had my
daily rant ;).


Yes, it is less a matter of the tools used and more a matter of
tooling the mind of the programmer. The guide I always use (which is
not mine, but comes from ancient programming history) is this:
It's not how well it works when it works that matters.
It's how well it works when it doesn't work that is the real issue.

A program with poor memory management works fine in unit and initial
integration testing, but that memory leak will show in the field when
the product is running continously for months and years at a time. You
can't always ask the user to have to reboot(or power cycle) the
product to gloss over your memory leak.

What does you process controller do when a sensor that is never
supposed to fail sends spurious signals? (e.g. the engine controller
getting signals from a bad O2 sensor)

Embedded is only a word for defining the kind of programming. It
entails, as Steve points out, a unique mindset. The measure of our
success, IMHO, is the extent to which the end user can totally ignore
the fact there is a computer involved.