Lesson 0 / Assy 101

[Teller.John at orbital.com]

The flight software I write is all in C (with a smattering of assembly).
Spacecraft CPUs are not particularly powerful (mine go as high as 1 MIPS -
smokin'), they are just very resistant to single event upsets.  A single event
upset is what happens when a highly charged particle speeds through a memory or
CPU register and flips it.  The code we write has to be efficient (not much
memory or CPU clock cycles), robust and fault tolerant.  The limited resources
do not lend themselves to accomodating languages that require a large amount of
memory allocation, manipulation and garbage collection.  Also, flight software
tends to be more procedural than data oriented, thus further mitigating the
obvious advantages of OOP.

Finally, just because NASA does something one way does not make that the best
and only way to do it.  They tend to concentrate on massive, multi-year, Mega-$$
missions.  They have to take heroic measures to manage the software development
effort, as it usually includes large teams of Software engineers and contractors
working all over the U.S.  Many of our satellites are built on a short schedule,
a few of them in less than a year from contract award to launch.  It can take
NASA that long just to figure out how they are going to get the job done!

--- John


Tom Sharpe wrote:

>The equivalent in the software world is object code written in higher level
>languages such as Ada, Pascal, Modula, Forth, or Cobol (or even Basic if there
>was an OO version). Certainly not C or assembler. C++ can be OO but most coders
>use C conventions and write procedural code. Most patches are written write in
>assembler, hence the "hooks".  That is why I am always pushing for "Other
>Languages" for EFI332 or DIYEFI. NASA writes 15 million lines of code for each
>shuttle mission. Guess what language they use?????? (it's not C/C++)   Just my
>.02  TomS