On Mar 23, 3:30 pm, Jonathan Kirwan <jkir...@easystreet.com> wrote:
> On 23 Mar 2007 11:31:39 -0700, "Ed Prochak" <edproc...@gmail.com>
> wrote:
>
> ><snip>
> >It is not how close to the metal you program, but what the end user
> >sees IMHO.
>
> Thanks for going to so much trouble. I'm sorry it worked out that way
> and you have my sympathies -- been there, myself.
>
> I just cannot agree with you, though. What 'defines' embedded to me
> has NOTHING to do whatever with what the end user sees. That's
> because this work is my life and my joy and much as a gunsmith has so
> much more to being a gunsmith than what a user of a gun can possibly
> know about, so it is with my work, as well. I grant you can try and
> define things the way you choose to, but then that definition wouldn't
> be of much value to me, personally, and I'd need to find another
> phrase for it. And frankly, I don't think it really makes much sense
> to let end-use define what my work and practice mean to me. It's
> about what I see in the work, not what others see in their use of
> products and applications.
I also have enjoyed nearly all of my embedded programming
assignments.
The enduser provides the context.
to use your analogy.
Whether you hand craft the gun or mass produce it, you are a gun
maker.
Whether you program the software for a device using assembler or a
high level language, you are an embedded programmer.
>
> To me, the term carries real meaning to practitioners. (I was careful
> in my earlier comment to point out that this is how I see it and folks
> can choose their own way, of course.) There is quite a range of
> difference in mindset, skills, interests, talents and so on that work
> to make _embedded_ work different.
YES, it is the mindset.
Knowing that the end product should be perceived as something in it's
own right and not as a computer that does something makes the programs
in that system embedded.
> .... There is and has for quite some
> time been a difference between programming work performed upon general
> purpose programming systems and work which is performed where this
> supporting infrastructure is to some degree or even nearly completely
> absent and where also the needs require other tools and skills not
> normally required on general operating systems.
The first part about missing supporting infastructure is true in many
cases but not all.
I want to be able to include those systems that have an OS, are
programmed in a high level language, that are field upgradable by
installing new software, that have remote diagnostic
interfaces(including internet connections) as embedded systems.
Yes ther are skills not normally needed. A common example is error
recovery. You cannot simple throw an error up on the screen (there
might not be one), and ask the user to fix the problem. Programming in
that environment takes different skills and a different mindset. We
agree a lot here.
>
> The example I gave about having to deal with linkers can be expanded
> to make this point. On general purpose computing systems, one does
> not need to even understand well the programming model that a compiler
> conforms to and that an operating system assumes and doesn't need to
> know about memory segments (and here I'm using the term NOT in the
> narrow sense of an Intel x86 processor's hardware, but in the far more
> general meaning that a linker writer uses the term) and the ability to
> duplicate them intact to other memory regions without pointer
> adjustment or to deal with memory aliasing sometimes found in systems
> that ignore some addressing lines, but where this is meaningful in an
> embedded application and quite useful.
So then in your definition, a compiler writer is an embedded
programmer because he has to think about these things. Any programmer
having to interface between different languages may have to be aware
of these things.
And by this you specifically exclude those writing application code on
the higher level. What happened to picking the right tool for the job?
Note in this context that application code might be meaningless
outside of the device, IOW it is not general progamming.
>
> It is the fluency of the differing tools and knowledge applied that
> makes the difference, from my long experience in the field. It's that
> reason why I personally use the term 'embedded.' You are free, of
> course, to use your meaning. It just isn't helpful to me to see
> things that way. I understand where you are coming from, I just must
> disagree with it.
I see your point, but I suggest it is rather limiting. Some of the
things you mentioned in an earlier post could easily fall under the
category of scientific programming. You would, I think, agree that not
all scientific programming is embedded.
Also your definition limits you in the search for possible solutions
to developing a new embedded system. It reminds me of an earlier
experience I had. I do not think you would react this way, but someone
following your definition might be tempted to do this:
On a new embedded project, a contract engineer said he did not want
the overhead of the company's embedded kernal. He claimed to be able
to program a statemachine that coule deal with everything. I pointed
out two things, first that his statemachine would have to also handle
programming all teh included devices, like interrupt controllers and
that this was thus new and untested code, lenghtening the project
schedule. Then secondly I demonstrated for him the low overhead of our
kernal. He realized his statemachine would not be able to perform as
well, or be as flexible. His statemachine required applications to be
aware of one another saving state in the application code, not quite
as flexible as a priority driven OS where context switches were all
handled in the OS. In the end he accepted programming under the OS and
the product was produced. All of this was due to his mindset that
embedded sytems were written on the bare metal, with little or no
infrastructure provided. That may be the case for very small
controller devices, but not for all embedded systems.
>
> Think of this like you might think about the difference between a
> common homebuilder using modern tools and someone trained to build a
> home without nails or screws or electrical power tools, but using
> wooden pegs and mortise and tenon and using tools, such as chisels,
> that can be built from much more prosaic and less technological tools.
> There would be a difference in practical skills and tools used worth
> nothing here and this difference would have little to do with what a
> home-buyer sees in the finished product (though there will be
> differences there, as well.)
>
> Jon
SO, do I understand this analogy of your correctly? the programmer
that does it by programming in assembler, without an OS or BIOS, and
develops his own library routines (including those for common features
like printf() calls) is an embedded programer. Another programmer that
installs a BIOS, ports an OS, and programs in high level languages is
by this analogy not an embedded programmer.
Do I have that right. If not I really don't see this analogy at all in
the context of this discussion.
Bottom line. BTW is that a agree that you need more awareness of the
hardware when programming embedded, than when doing general
progamming. It seems you think that should be the primary focus of the
embedded programmer. And I think the focus is on the final product,
the hardware is considered only within that context.
We are not that far apart really, just s shift of focus. And I'm sure
we would have a great time discussing this and other things over a
beer sometime.
Ed Prochak