<snip>
Actually, some interesting things can be done in FPGAs alone these
days, without procedural programming. Interesting and stunningly fast.
That's one of the options a design engineer can consider.
But if all you do is program, you have no say about the other things.
Indeed, you have no say about the program itself, except the
implementation details.
You are making the important argument for why I think that embedded
programmers need to have at least some passing understanding of
electronics, as well as mathematics, as well as numerical methods, as
well as signal processing, as well as sensor and transducer physics,
as well as....
In order for someone who's more primary responsibility is writing
embedded code for what is otherwise just an electronic device to an
end-user, they must be able to accept specifications from physicists,
electronics designers, etc. and to be able to understand the deeper
intents. A physicist is not going to fathom well the numerical
details of floating point, nor really care that much about the exact
implementation details of his or her equations. But the programmer
must be able to accurately reflect them in the resulting code. An
electronics designer needs to be able to pass along a schematic and
expect that the embedded programmer can navigate it with reasonable
proficiency, as well as understand other specifications. Details
about the physical model of transducers often are reflected back into
details of software design to cope properly with them. And it is the
embedded programmer which has to take in all this information and is
often the last step in fusing all of this information into a final
product that works as expected. They are at the center of this
integration step and it takes a fair degree of knowledge to keep
things from "falling through the cracks."
Often enough, this job falls upon an electronics designer. But it
doesn't have to, if the embedded programmer has broad enough knowledge
and experience.
I am not a designer, I'm an embedded programmer. But I continually
study sensor physics, mathematics, signal processing and closed loop
control methods, optics, and electronics, as well as the usual
material associated with the core programming skills or required for
current projects at hand. It's part of what keeps things interesting.
And most anybody can do embedded programming... it's sort of routine.
Much of it is, for an electronics designer. There are facets of it
that may not be, but are easier for someone with broader experience in
programming. For example, I can whip up a very fast multi-process
operating system, with inter-process messaging, sleep and run queues,
dead accurate delta-timing queues, etc., customized to the application
in just a matter of hours. I just had to do this, recently, in fact.
Not all electronics designers will have that experience to rely upon.
One uses what tools they know. "To a man with a chainsaw, everything
looks like a tree." If you only know some programming skills, you
will apply them to every project ahead of you and you won't even know
what other tools might exist to improve the project. Someone who
specializes on the embedded side, but with good familiarity on all the
same issues that an electronics designer must cope with (however, with
a different emphasis), can apply a broader range of tools to the trade
and, in some cases, help make a better overall product working as part
of a team.
There remains a lot of creativity available on the programming side,
but I think the real fun comes in always finding new ways to stretch
yourself. In my case, it's learning about what surrounds embedded
programming work. And that's not so routine.
Jon
