From: jgriffitts@spamcop.net   
      
   In article , Lex Spoon writes   
   >Jonathan Griffitts  writes:   
   >> That example works fine for office computers, but for "embedded"   
   >> applications there are usually some extra constraints.   
   >   
   >Yes, I simplified.  But all computers are getting cheaper, and even   
   >with the extra costs you are likely to win by splurging on the CPU   
   >usage.   
    . .   
      
   I don't think you have grasped the whole "embedded computer" mindset.   
   The "bloatware" philosophy is justifiable and economically acceptable   
   with the general-purpose computers you're familiar with, but this is a   
   different situation.  Let me illustrate:   
      
   Your typical design requirement spec for the processor subsystem would   
   include something like:   
   -  100 square cm of board space is available.   
   -  You may use a maximum of X Watts, but never for more than XX seconds   
   continuously, and only when the system state leaves you enough available   
   power, and the rest of the team will all frown at you every time you do   
   it.   
   -  You may use a maximum of XXX milliWatts as an average power over X   
   minutes, again subject to available power.   
   -  Standby power is XX microWatts.   
   -  Thermal environment is . . . , radiation environment . . ., supply   
   voltage tolerance . . ., fault tolerance . . ., blah, blah, blah.   
   -  Schedule is too fast to allow building or qualifying any custom   
   chips.  All parts must be off-the-shelf.   
      
   Be sure the spec numbers are tight enough to give heartburn to the   
   hardware architect.   
      
   Now suppose you arrive at a meeting and say, "We need 50% extra CPU   
   speed and double the RAM to make the programmer's job easier, because   
   programmers are expensive and hardware is cheap."  That argument may not   
   be persuasive.   
      
      
   >> If you're   
   >> getting close to current state of the art, the fast processor may not   
   >> yet be qualified for high-reliability applications, or it may even be   
   >> buggy.  Any of these factors could be critically important.   
   >   
   >Yes.  If you are lanching Crays then my argument breaks down.   
      
   I realize this comment was probably meant to be facetious, but you're   
   illustrating that mindset again.  We are talking *chips* and you are   
   going from office computers to mainframes.   
      
   The situation I'm talking about is not limited to space probes, by the   
   way.  Think about the constraints on the processors in disk drives, or   
   inkjet printers, or automobile engine controllers, or cell phones, or   
   digital hearing aids, pacemakers, . . . the list is endless.  These   
   processors far outnumber office computers.  For many of them, if you   
   insisted on adding $1 of parts cost to make the programming job easier,   
   you would be out of a job.   
      
   I'm not making this up.  I've been involved in this sort of thing for   
   about 25 years.  Even these days, for some jobs I only get 16K of ROM   
   and 1K of RAM, and like it!   
   --   
                           Jonathan Griffitts   
   AnyWare Engineering                             Boulder, CO, USA   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)