Re: Books / Articles on Embedded SW Architecture

"Usenet Groups" <myusenetaccount@xxxxxxxxx> wrote in message
news:449adee7$0$11067$9b4e6d93@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Steve at fivetrees wrote:
"Usenet Groups" <myusenetaccount@xxxxxxxxx> wrote in message
news:449acfdb$0$11066$9b4e6d93@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx
I'm looking for information (good articles, books, websites)
concentrating on SW architecture themes related to Embedded platforms.

Primarily SW architecture discussion seem almost solely devoted to the
PC world and object orientated languages. I do find some of these topics
also apply to the embedded world however I'm missing topics on issues
like the list below.

:Multi-processor communication
:Multi-processor System Partitioning
:Protocol Handling
:POST (Power On Self Test)
:Distributing System events (i.e. power up)
:ISO Network Model
:Debug/Trace Strategies
:Error Handling
:How to benchmark sufficiently
:Event-Driven Systems
: ...

Which books do you use when tackling problems such as those mentioned?
Which issues should be added to the list?

You missed the most important one:
- Designing demonstrably bug-free software and systems

Steve interesting but I think we should accept that with the
tools/languages we use 'bug-free' isn't going to happen, except on trivial
projects.

No. Absolutely, categorically, emphatically not. The "complex software must
be buggy" myth is one I absolutely, categorically, emphatically refuse to
accept.

I deliver products, of any level of complexity, when they're bug-free. Not
before.

"Trivial projects" only? No. That's an example of the Wrong Attitude. Sorry,
but you failed ;).

The thing I find weird is that designing reliable systems (with "thou shalt
not crash" in mind) takes less time, mainly because it cuts out the whole
asymptotic "reducing bugs to nearly but not quite zero - until we run out of
time" phase. This seems to be a well-kept secret. I find this weird. All
branches of engineering I've been involved in have been driven by economics,
except this one. (I think I know the reason, and it ain't pretty.)

To add just a little: robustness is always the key attribute. *Design*
for zero errors; debugging is something that you do when you fail, so aim
not to. The hack/debug approach must be seen for what it is: amateurish
tinkering.

I don't accept that. We should build mechanisms into our systems in order
to 'see' our systems in work. If you or someone in your team does happen
to 'fail' then do you have the right tools/procedures for fixing that
error? Logging tools, printing debug lines to stdout etc all have their
usefulness and should be designed in from the ground up.

What you're describing is debugging, which has its use during development
(mostly against typos). But again - a properly designed system won't need
debugging (other than the typos). Period. "Proper design", however, is
rare - and rather beautiful.

Achieving this is not always easy, but *should* be what we all aspire to.
Acceptance of failure is far too common in s/w design, and simply
unacceptable in embedded work.

Of course you can always over design a system. The more non-functional
modules you include, the more complex the system the more chances you have
to fail. Like everything it's a balancing act.

Bollocks. To be blunt.

A complex system is a collection of simple parts, or or complex parts
consisting of simple elements. It's the interactions between these parts
that confuse us. Which is dumb. We should be designing in terms of
interactions and simple things. Complexity doesn't exist - unless you don't
understand the problem, or the solution offered.

As for over-designing - no, again. Equating "it shall not crash" with
"overdesigning" is precisely the kind of attitude I'm up against on a
regular basis, and one I frankly despair of. Paraphrasing what I said
earlier, acceptance of failure is a malignancy.

I would be interested in techniques people use to debug their systems.
Printing to a serial port is OK if you have a spare port but it also can
be CPU intensive if the developers over do it with the debug lines.

I mostly use a single LED. Otherwise, I endeavour to ensure that the effects
of a simple failure are catastrophic - which means I won't miss it.
Seriously - I try hard to ensure things don't get overlooked.

Steve
http://www.fivetrees.com


.

Relevant Pages

  • Re: Delphi-debugger-limit: 65534 lines in file ?
    ... I use Delphi "only" for debugging and designing forms. ... linker / include TD debug info = false ... compiler / debug information = true ...
    (borland.public.delphi.non-technical)
  • Re: Visual Basic Compiler Errors
    ... I am constantly getting VB Compiler errors when I am ... just coding - no debugging, no designing. ...
    (microsoft.public.vsnet.general)
  • Re: advice
    ... >> Designing or debugging? ... > although i am good at it, debugging sends a chill down my spine ... The technique might indeed also send chills down your spine... ...
    (comp.programming)
  • Re: advice
    ... Designing or debugging? ... Phlip ... Prev by Date: ...
    (comp.programming)
  • Re: iPhone and the swalowing whole of the RDF
    ... not to mention the political risks of being found ... I'm not talking about designing to fail; more like not putting in the ... and buckling-surface switches are prone to failure ...
    (uk.comp.sys.mac)