Re: Results of "downloading compressed program images" request

[The Chazman <chaz@devastator.extern.ucsd.edu>]

RMS replied:
>
>     >>    me in many instances.  Why not give away the source code?  It is
>     >>    useless without the hardware to run it on.
>     >
>     >I think you're right--I wish that more embedded developers had this view.
>
>     then how do you protect a proprietary hardware design
>
> In general, if something makes it hard for people to keep the specs of
> hardware secret, I would consider that a step forward.  The
> concealment of hardware designs for PC hardware has been a great
> problem for the free software community.  I have little sympathy with
> someone who wants to keep hardware specs secret merely so as to beat
> out someone else.
>

I would agree with you wholeheartedly if we were talking about PC hardware,
but we are not.  The situation with embedded hardware is entirely different,
having near-zero need for the end-user to know anything about the hardware.

#1) Generality of hardware components

PC hardware is generic.  One buys a video card, a SCSI controller, a hard
drive, etc.  One can buy each one separately, plug them into each other,
and expect them to work.  Parts are interchangable and replacable.

Embedded hardware is not generic.  The entire system is designed as one
whole piece, with no interchangable or replacable parts.  One generally
cannot add any new hardware functionality after the fact -- it is not an
upgradable system (except maybe software-only upgrades as now programs are
increasingly stored in flash).

Hardware specs for embedded products don't need to be released because
you can't upgrade them.  Since you can't replace a component, the end user
will never need to go looking for a driver for the new component, so the
OS maintainers will never need to write any drivers for any new components.
All that is required is that the original hardware be supported, which, if
the product is shipping, obviously it is.

#2) Generality of purpose

A PC can be used for anything.  One can play any number of games on it,
develop both software and hardware on it, host web/ftp/other services on
it, or do just anything else a computer is capable of.  As the uses of a
PC change, it can be upgraded to have more resources and hardware to meet
the needs of its new uses.

An embedded system was designed to do exactly one thing.  It has exactly
the bare minimum resources and hardware required to accomplish its one
task.  It has no means to do anything else, ever.  If a 6502 (remember the
Apple II+?) has enough CPU power to manage the task at hand, that's what
will be used.  If the task requires 2k of RAM, 2k of RAM is what's resident,
and no more.  If the status of the box can be effectively conveyed by three
LEDs, then there will be no screen of any kind, just three LEDs.  It cannot
be upgraded, but that's irrelevant -- its task will never change.

Hardware specs for embedded products don't need to be released because the
product's task will never grow or change.  Thus, one would never need to
write completely new software for it (just patch the old software).  Never
needing to write completely new software, an end user would not need to
know the software interface to the hardware.


Admittedly, there are recent products that blur the line.  Things like
handheld PCs and programmable organizers (e.g. Palm Pilot) are somewhere
in-between the generality of a classic PC and the fixed design of a classic
embedded system.  Thus, I feel that the accessibility of hardware of these
intermediate devices needs to be significantly greater than that of the more
single-minded devices I speak of when I say "embedded products", like VCRs,
microwave ovens, or automobile engine controllers.  I make my point for
these single-minded devices, which are the vast majority of embedded
systems.


                   -----  Carl N Miller
                          (chaz@devastator.extern.ucsd.edu)
Embedded software development pays the bills,
Linux free software development occupies the free time.