Subject: a few words about embedded software development

re-format: 2_May_2002
Date: 15_June_ 1999 04:02:45 +0000

by: "Bill_Schell_RHL6.0Gn_NEC" <bill@vikingasia.org>

Note: - may contain occasional references to Motorola 
       - please disregard these

==================================================================

In the 'traditional' realm of "software development" in the
primarily end-user computing / desktop arena, software source code
is written, edited, compiled & debugged on the "target platform". 
That means that the same hardware & operating system is used for
both development and by the end-user that purchases and uses the
software once development is complete.

The world of embedded software, however, operates on a much
different basis. The foundation of that model is that the software
is typically not developed on the target platform, since target
platforms such as MCORE, Firewire, MC68HC11's and the like don't
"normally" have operating systems, compilers (for high level
languages such as "C") and debuggers that run native on those
cpus.

So -the model is that typically someone (sometimes Motorola
divisions, sometimes outside-third-party companies) will write an
"emulator" for the target platform, (lets take the CPUs in our
hand-held radios, for instance) and the emulator runs on
(typically) a Unix platform of a very high CPU / Memory
configuration, in order to achieve the performance of the target
CPU in the delivery system (say a 2-way radio).

Then the development work is done on the Unix platform (since
that's where the emulator, compilers, debuggers, etc. run).   THis
paradigm for embedded software development is sometimes
accomplished in the desktop-Unix-platform method, and sometimes
accomplished as X-terminals attached to Unix servers. The delivery
of the development methodology to the developer depends quite a
bit on both GSD' assessment of what is economical for development
expenses, as well as what the customer wants and also dependent on
the number of developers (and their geographica location(s)) that
need to have access to the data (and consequently be managed by
our software development configuration management tools.

SO - as has been outlined before, there are not only two distinct
computing arenas within GSD; the Office-Automation - primarily
Microsoft based arena and the Techical computing or primarily
Unix-Gnu based arena; there is also, within the Technical
computing arena two more sub-areas of embedded and traditional
software development.

Additionally - many customers (such as CIG - Network Management
(of GSM-roaming authentication software)) require our development
activities on Tandem computers, (for their high-reliability aspect
of network management & roaming-customer authentication work).

So - we are frequently asked to develop software (for the majority
of our projects) on non-Intel platforms (by definition all of
Motorola's embedded software runs only on Motorola platforms,
therefore we are probably not going to use an Intel platform to
develop software for a Motorola chip.

However, some of our Motorola divisions (again such as the 2-way
radio group(s), DOES ask us, sometimes, to deliver what we call
the "programming" software on Windows NT.  This need stems from
the fact that Motorola's end-customers for 2 way radios need an in