Spirit rover OS problems - Page 8

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
Re: Spirit rover OS problems ( a reliable language )

Quoted text here. Click to load it


Not particularly more correct than Grant's answer.  They're both
correct, because:

    expression ::= assignment_expression
                 | expression, assignment_expression

Quoted text here. Click to load it

No. The condition in the if is indeed an "expression", not an
assign-expression.  The difference is that

    if (a = b, f = fopen(...))
       e = f;

is allowed, too.  And that is *not* an assignment expression.

--
Hans-Bernhard Broeker ( snipped-for-privacy@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.

Re: Spirit rover OS problems ( a reliable language )

Quoted text here. Click to load it

What's the question?

Quoted text here. Click to load it

Sure.  "=" is basically just another binary operator, so

  a = 5

and

  a == 5

can be used anywhere the language calls for an "expression".

--
Grant Edwards                   grante             Yow!  RELATIVES!!
                                  at              
We've slightly trimmed the long signature. Click to see the full one.
Re: Spirit rover OS problems ( a reliable language )
Quoted text here. Click to load it

Ah, pedantic mode on.

Quoted text here. Click to load it

No, its both. Reread your C grammar. Expression is one of the legal
statements.

Quoted text here. Click to load it

How many C compilers have you written ?



Re: Spirit rover OS problems ( a reliable language )

Quoted text here. Click to load it

Twaddle. Please point to a compiler that will accept:

for (;;)
  {
  a = val * 10 /* not a statement - just an expression */
  }

Perhaps you would like to look at the productions for "statement" at
(in BNF):
http://lists.canonical.org/pipermail/kragen-hacks/1999-October/000201.html
or look in the back of K&R or the ANSI/ISO standard.
An expression is not a statement. A left-most expression followed by a
semi-colon DOES reduce to a statement.

Quoted text here. Click to load it

Three. Plus two C++, one BCPL, Pascal, ADA, and a couple of "midnight
specials". I'm currently writing a portable C# v2 compiler as a
background activity (because I like the idea of type-safe genericity).

Compiler writing was a regular part of how I earned my crust for seven
years or so in my earlier career. It isn't hard, particularly if you
use YACC/LEX or similar tools. Second-year CS students write simple C
compilers for term projects. Global data-flow analysis and code
optimisation are the only really tricky bits in a C compiler.

Why, anyway? Is this some sort of "who's got the biggest conker"
debate?

--
  Max

Re: Spirit rover OS problems
Quoted text here. Click to load it

Certainly.  But some languages make it hard to write bulletproof code, while
other languages make it hard to screw up.

C is like a table saw missing the finger guard.  An expert can use it most of
the time without losing fingers, but you wouldn't turn a beginning shop class
loose with it.

http://www.brouhaha.com/~eric/editorials/software_reliability.html

Re: Spirit rover OS problems
On 11 Feb 2004 10:19:01 -0800, Eric Smith

Quoted text here. Click to load it
An interesting comparison, as I consider the blade guard on a table
saw to be very dangerous, and always remove it.

--
Al Balmer
Balmer Consulting
We've slightly trimmed the long signature. Click to see the full one.
Re: Spirit rover OS problems

Quoted text here. Click to load it
of
class

Agreed. Trouble is that too many people let that same "beginning shop class"
loose on projects of major importance. The only way to get decent software
is to put the novices alongside great designers and programmers who have the
wisdom to know what they can delegate and the patience to review the
novices' code from time to time. Of course, they should also have their own
code reviewed by the novices, so that both may learn something. Most people
would use "better" languages if they could get close enough to the
hardware - and the memory and performance requirements with them. That day
is not yet here, for most projects.
--
Peter Bushell
http://www.software-integrity.com /



Re: Spirit rover OS problems

Quoted text here. Click to load it

Well, with Ada (a "better" language) you can get as close or closer to
the hardware as you can with any other language above "assembly". As
for memory footprint, if you don't need the Ada runtime just leave all
or part of it out.  The main technical barrier to use of Ada in small
embedded applications is the near total lack of Ada compilers for 8
and 16 bit targets.  Some people have toyed with GNAT (Ada 95) ports
that target Motorola 68HC11 and Atmel AVR but that's about as far as
its gone.

Britt

Re: Spirit rover OS problems
all I know is that they use a VME rack and VxWorks.
At all, no information about the cards in the slots.
Believe the public will never hear the truth on what
happened. Nasa did many experiments on flash reliablity
under extreme temperature, xray and other particles
influence but there is still the question if the fault
was HW or SW caused.

In todays press release the announce the have a
"undefined workaround" and I assume in the meantime
they know the exact reason

However, last days I experimented with the Infineon XC16
chips and was suprised to find a HW flash error correction.
That uC contains a 8 bit HW ECC for each 64 bit flash
array. Single bit errors can be corrected on the fly
and double bit errors indicated. I did not see such a
feature at uC flash before and it seems they are
aggrieved by the former Siemens SAB 87C166 debacle
(not for new designs)

Nasa wrote in earlier tech docs, they have error correction
in RAM, they wrote about eeprom, but now, its the first
time they talk from flash and probably there is no hard-
ware ECC available.

Assume critical data like file system is always
available as a second copy. With other words: Crashing
a complete system like they had, would require more
than one bug.

Re: Spirit rover OS problems

Quoted text here. Click to load it

The last description of the problem by Nasa was that
the flash file storage system did not correctly handle
being full or nearly full. Most software does not handle
these edge conditions properly. Windows itself would
reliably crash if you insisted on leaving main memory or
the disk full or nearly full. In C language terms, all
you have to do is look at how many times malloc is called
with no checking for a return of zero (meaning no more
memory available), and that is only the most obvious case.
Most code that does handle the out of memory condition
does nothing but abort the program currently running,
which is not much improvement on not handling the zero
case, since that will lead to an invalid address exception and
program termination.

Quoted text here. Click to load it



Re: Spirit rover OS problems
Quoted text here. Click to load it

I saw that to.  And I thought they said at that time that the longest
test of the system had been 8 days (if my memory serves me right).

A 90+ day mission to Mars and you never run a test for more than 8 days?
  That seems a bit short to me.


Re: Spirit rover OS problems

Quoted text here. Click to load it

Yes, I would expect aborting the program to lead to its termination,
but I'd be surprised if it got any address exceptions after being
aborted ;-)

Actually, we (or at least I) don't know that the Rover problems had
anything to do with improperly handled out of memory conditions. I
know you have a thing about C, but I really doubt that the problems
had anything to do with failure to check the return from malloc. Even
if the programmers aren't capable of remembering this simple rule,
lint will pick it up.

Anyway, depending on the system design, aborting the program and
letting the system-wide fail mechanism take over can indeed be the
best way to handle a problem. (In general terms - I don't know about
Mars Rovers.)

--
Al Balmer
Balmer Consulting
We've slightly trimmed the long signature. Click to see the full one.
Re: Spirit rover OS problems
Quoted text here. Click to load it

I am glad I am not the only one.  I have used WindRiver a couple of
times in jobs, but I was always very disappointed by the nature and
level of support.  Once I was trying to get some info on why a wait on a
resource was consuming nearly a milisecond after the resource became
available, using a 66 MHz 486 processor.  In the end they would only
tell me that "there are no known bugs" in that OS code.  The refused to
discuss it further.  After that, I swore I would never use another
WindRiver product again.  

Seems that great minds think alike... no, wait, NASA is still using it!

--

Rick "rickman" Collins

snipped-for-privacy@XYarius.com
We've slightly trimmed the long signature. Click to see the full one.
Re: Spirit rover OS problems

Quoted text here. Click to load it

Nasa should require that Wind River perfom on-site maintenence on the
product :-)




Re: Spirit rover OS problems

Quoted text here. Click to load it

Travelling expenses and daily allowance paid by customer?

aha
--
Every program has at least one bug and can be reduced by at least one
line.  By induction, then, every program can be reduced to a single
We've slightly trimmed the long signature. Click to see the full one.
Re: Spirit rover OS problems
Quoted text here. Click to load it

we already know that bug. If you have a valid maintenance contract,
we will ship a new eprom ...

Re: Spirit rover OS problems
On Sat, 7 Feb 2004 10:18:48 -0000, "Steve at fivetrees"

Quoted text here. Click to load it

Just as an aside. I wonder what's that object on the horizon.

http://marsrovers.jpl.nasa.gov/gallery/all/2/n/033/2N129300816EFF0327P1730L0M1.JPG

Probably a spec of dust on the lens.

--

Reply to

dmmilne at ozemail dot com dot au



Re: Spirit rover OS problems

Quoted text here. Click to load it
http://marsrovers.jpl.nasa.gov/gallery/all/2/n/033/2N129300816EFF0327P1730L0M1.JPG
Quoted text here. Click to load it

I hope your not trying to spin up some UFO theory, it's obviously just a
weather balloon.  Right there in Death Valley, where the two rovers were
recently deployed.  ;-)


Re: Spirit rover OS problems - OT: Priority Inversion
Quoted text here. Click to load it
memory/OS
Quoted text here. Click to load it
$100
Quoted text here. Click to load it
the

Well, being a newbee - I searched the archives on Comp.Arch.Embedded and
found nothing. Google gave lots of hits. For example:

Http://www.embedded.com/story/OEG20020321S0023

I'm using a Keil C compiler - so I was just wondering if its an issue with
that OS?

Thanks

Klaus



Re: Spirit rover OS problems - OT: Priority Inversion

Quoted text here. Click to load it

By the way, look at the first reference in that article ("What really
happened on Mars"). Boiled down to its essential points, it says:

* This problem was due to an internal OS design decision by Wind River.
* The workaround was not a documented feature.
* The workaround could only be known about - let alone applied - if you
had studied the [closed] OS source.

In summary: Mere mortals cannot create reliable software with
closed-source operating systems.


Site Timeline