Detailed article about Mars Rover falure in EE Times

Using a commercial RTOS does not really add complexity. And I personnally thing you go better by a mature (and widely uses) RTOS than writing your own task-switching routine. _But_ I'd say, don't use every gimmick an RTOS offers. E.g. don't mix different kinds of synchronistation between tasks (semaphores, mailboxes, events and so on). And be supsicious if the RTOS is larger than your own code :-)

Someone said: Keep it simple, but not too simple ! (IIRC it was this Freak who said we will never reach Warp 1 for travelling).

--
42Bastian
Do not email to bastian42@yahoo.com, it's a spam-only account :-)
 Click to see the full signature
Reply to
42Bastian Schick
Loading thread data ...

This is precisely the myth I'm trying to debunk.

All problems, hardware or software, tend to be complex until the complexity is designed out. If it's still complex at the end of the exercise, then the exercise has failed.

Steve

formatting link
formatting link

Reply to
Steve at fivetrees

Why task-switch at all? A cooperative roundrobin scheduler offers determinism and synchronism - both are desirable attributes in robust code. Too simple for complex jobs? Nope - each scheduled job can be as complex as you like.

Re "mature RTOS" - for whatever reason, when it comes to robust mustn't-ever-fail code, I'd rather write my own (or better still, re-use my own "mature" code). My quality standards seem to be higher than most (possibly all) third-party code I've come across. I only feel comfortable with using 3rd-party code in non-critical apps these days. I've found too many bugs in "mature" code to have implicit confidence...

Steve

formatting link
formatting link

Reply to
Steve at fivetrees

I totally agree. It's just as possible to write a half-page of C that is totally undecypherable or 50 pages of easily understood assembly code.

As to the software being more complex than hardware, the most complex hardware designs are in silicon and are done in VHDL or Verilog. So you're back to virtually the same issues as software.

Reply to
Jim Stewart

It's hard to disprove the truth.

OK, that's a bit glib. But it seems pretty obvious to me that in order for software to fully exploit the hardware for which it was written, it must be at least an order of magnitude more complex than said hardware.

This statement is true. To a point, anyway. Hoare said there are two ways to write software: so complex there are no obvious deficiencies, or so simple there are obviously no deficiencies. But Einstein said you should make your system as simple as possible, but no simpler. (Note: both paraphrases)

But that says nothing about the relative complexity of hardware and software.

Regards,

-=Dave

--
Change is inevitable, progress is not.
Reply to
Dave Hansen

"Scott Moore" schrieb im Newsbeitrag news:Ddh%b.409433$xy6.2338451@attbi_s02...

exist

Have

You're right this makes a difference. Reaching 100% coverage can be a challenging task if the problem is not trivial. This applies to hardware as well as software. I just wanted to point out, that every non-trivial system tends to have bugs, be it hardware or software.

- Rene

Reply to
Rene

I understand your point though I don't fully agree with it. A software with hundreds/thousands of functionalities will be complex no matter how much you break it down into smaller/simpler pieces. Still your approach, if realizable, can potentially make better software even though it remains complex. :-)

Reply to
Elder Costa

I suspect we mean different things by "complex". The point I'm making is that complex functionality can be achieved by hierarchical collections of simple things. A case in point is the TCP/IP stack - everyone seems scared of it, and the tendency is to buy it in or use an RTOS that includes it. But layer by layer, it's not rocket science.

I'm strongly in the "so simple there are obviously no deficiencies" camp ;) - as a conscious survival strategy, not as naive idealism. As for the Einstein quote, I'm not sure how it applies to engineering - if it meets the spec, and does what is required, why does it need to be any less simple?

Steve

formatting link
formatting link

Reply to
Steve at fivetrees

I'm not sure I understand.

I find that most of the "complexity" of my designs is vertical , structural - I essentially design as a collection of black boxes that do clever things once hooked up vertically. The individual black boxes are quite trivial and easily understood. Once hooked up, they deliver complex functionality.

And it does. But as I've said before, good decomposition is a hard-won skill. It seems (in my experience) relatively rare. I'm not sure why this is.

Steve

formatting link
formatting link

Reply to
Steve at fivetrees

Practice, and the habit of top-down design and successive refinement, help.

--
Chuck F (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net)
   Available for consulting/temporary embedded and systems.
 Click to see the full signature
Reply to
CBFalconer

course,

problem)

I fear I've either expressed myself badly, or we're getting into semantics.

I fully agree that a problem has a given complexity. But how that problem is expressed is extremely subjective. Some people have a knack for making something simple appear complex, and vice versa. I don't believe I'm saying anything new, or controversial - perhaps I'm just saying it badly ;).

I'll concede the point with respect to the defined problem. I would nitpick just a little - I've frequently sat down with customers and focussed them on requirements, rather than expectations, and simplified the spec with no loss (frequently even a gain) of functionality, just subtly differently expressed. Stage #1 of complexity management.

I don't concede that the *design* has to be complex, though, at least not when well decomposed. In hardware terms, discrete components are not hard to understand individually. Collectively it needn't get any tougher, depending on the skill of the designer - and of the person doing the schematic, if not the same. We've long since developed the art of partitioning to enhance understanding and hence reliability. Nothing new there. Divide and conquer etc.

That's really all I'm say>> All problems, hardware or software, tend to be complex until the

complexity is designed out. If it's still complex at the end of the exercise, then the exercise has failed.

Reply to
Steve at fivetrees

If you let the sales droids write the requirements, you are in a big trouble :-), since they want _every_ feature that _any_ competitor are using.

You have to figure out what the customer _really_ needs and write the specification in a way that can be implemented. You may even have to hint the customer in the right direction so that he/she can "invent" the feature that can be implemented, in order to avoid the NIH (Not Invented Here) syndrome.

Paul

Reply to
Paul Keinanen

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.