Re: Towards better embedded software (long)(was: Re: Where does C++ fit in?) - Page 3

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

Translate This Thread From English to

Threaded View
Re: Towards better embedded software (long
Quoted text here. Click to load it

<snip lots of good stuff>

I claim that my software is bug-free, regardless of complexity. Always. I
guarantee it.

Paradigm shift: hardware logic designer, lots of async logic. Is it bug
free? Who knows? Conversion to sync logic: "is it bug free?" becomes "how
long is the longest propagation delay?".

Back at software: given a suitable design methodology, and (of course) an
adequate spec, bug-free code is perfectly attainable. Every time.

It's the defeatist acceptance of failure that I'm on a mission to... err...
rant about ;).

Steve
http://www.sfdesign.co.uk
http://www.fivetrees.com



Re: Towards better embedded software (long
Quoted text here. Click to load it

We're about a rat's whisker away from a sticky semantic argument about
the definition of "bug-free". I can pretty much guarantee that some
combination of circumstances will put your bug-free code into an
undesirable state. But if you define the specification to exclude all
such circumstances by inclusively listing all allowable ranges of
inputs and combinations thereof, your code can be said to be bug-free
up to the limits of the spec. The trick is therefore to know whether
the spec includes all real-world possibilities, or if it is possible
for the real world to violate the spec.

For instance (yes this is a gross and silly example) if the
specification says "Button A will always be pressed before button B",
your program is off the hook and free to misbehave if button B is
pressed first.

Re: Towards better embedded software (long
Quoted text here. Click to load it

Yep, we did that one a while back ;).

Quoted text here. Click to load it

I take your point in general. However, possibly due to my hardware
background, I'm hot on excluded states and I guard against 'em. I ensure (as
part of my general methodology and emphasis on defensive design) that
unforeseen circumstances won't result in undesirable states. Regardless of
the spec, I would consider such a failure to be a bug.

This might be a pretty good example of what I was talking about earlier -
that good engineering is a skill that should be learned independently of
software coding/design issues.

Steve
http://www.fivetrees.com
http://www.sfdesign.co.uk



Re: Towards better embedded software (long
Quoted text here. Click to load it

I do agree it's an independent skill, but I think actually it's easier
to learn it in the context of software design - because it's cheaper.
As a student you can create the software equivalent of a bridge that
oscillates to death without actually having to go through the hassle
of acquiring the funds, dealing with the bereaved, etc.

Re: Towards better embedded software (long
Quoted text here. Click to load it
earlier -
Quoted text here. Click to load it

Of course. But that's not quite what I mean. I learned the benefits of
finding a problem early, first as a production test equipment designer, then
as a product designer feeding that same production line. I really think that
many software people have yet to learn this lesson.

Steve
http://www.fivetrees.com
http://www.sfdesign.co.uk



Re: Towards better embedded software (long
... if you define the specification to exclude all
Quoted text here. Click to load it

That's fine for a programmed logic device, but doesn't come close
for software of say 2000 lines of code or more. When the spec  is
not met that's a 'priority1'/defect/fire-somebody-time.

I offer the reason that most "Bugs" are genuinely unexpected and
unspec'd interactions with other parts of code and with the
environment (including new users poking buttons when the programmer
didn't expect it).

- RM


Re: Towards better embedded software (long
1.2347225@attbi_s51:

Quoted text here. Click to load it

One of the most valuable members of one software team I worked with wasn't
even a software engineer - he was a student working in the lab who had a
talent for "pressing the wrong buttons" and finding errors.

Someone with an unbounded curiousity who refuses to follow instructions is
good to have around "just in case" you haven't foreseen every eventuality -
it may be traumatising putting your baby in his hands, but better he finds
a mistake than your customers :)

*Waiting for someone to tell me we shouldn't have needed this sort of
testing ;)

Peter.

Re: Towards better embedded software (long
Quoted text here. Click to load it
   <snip>
Quoted text here. Click to load it

Heh ;). Nah, testing (especially this kind of insightless testing) is a Good
Thing - if only to reassure you that your defensive excluded-state
protection logic is working ;).

Someone (Pete, I think) mentioned "The Practice of Programming" by Kernighan
and Pike (which I also wholeheartedly recommend). One of the stress tests
mentioned therein, for stream input, is to fire garbage (and/or carefully
contrived illegal data) at it and see what happens. I routinely do this -
again I'm not expecting my code to fail, but I do want to test and exercise
my defenses. Surely we all do?

Back at button pressing: one system I worked on had upto 32 buttons on each
of upto 64 attached outstations, and another set of buttons on the master
panel. There was no realistic way of testing every combination ;). The code
simply had to deal with whatever it was given, in any order, logically. (I
always do this. I'm a little surprised at the inference that anyone might do
otherwise.) It was a legacy system, and the original code did indeed fail
when buttons were pressed in unexpected ways. I watched in calm amusement
when the customer tried to make my new code fail.

I consider these kind of defenses an essential part of any embedded code.
Sadly far too many embedded products from otherwise reputable companies lack
them (example: the Nokia set-top box which my teenage daughter, whose
button-pressing abilities are fearsome [presumably from texting practice],
manages to crash daily). Hence my rant.

Steve
http://www.fivetrees.com
http://www.sfdesign.co.uk



Re: Towards better embedded software (long

Quoted text here. Click to load it

I have a "War Story" on my web site about a similar case of where I
jiggled a connector on a comm link to ensure my code and the hardware
could handle all the garbage that was generated. I eventually won the
argument with the hardware manager who thought I was crazy.

http://www.Surreal-Time.com/WarStories/CableDrum.html

...Tom

--
Tom Sheppard
Real-Time Fundamentals instructor-led and web-based training courses
We've slightly trimmed the long signature. Click to see the full one.
Re: Towards better embedded software (long
Quoted text here. Click to load it

I've read and enjoyed your war stories before, Tom, but I've just enjoyed
reading them again.

Quoted text here. Click to load it
attitude with which they approach a problem. <<

Indeed.

Steve
http://www.fivetrees.com
http://www.sfdesign.co.uk



Re: Towards better embedded software (long

Quoted text here. Click to load it

Thank you. I'd love to add to them if others are willing to write
something up, anonymously or not.

...Tom

--
Tom Sheppard
Real-Time Fundamentals instructor-led and web-based training courses
We've slightly trimmed the long signature. Click to see the full one.
Re: Towards better embedded software (long

Quoted text here. Click to load it

On a similar "real man's hardware" test vein :
  Way back in the days when I did SMPS designs, I recall a visiting
designer from Philips who said they used a metal-working file to test
SMPS ? - How, you wonder ?












  They added croc-clips to a mains power lead, and a bare-furry-cable
end was stroked along the file teeth. => Sparks by the truck load!
  - but it did separate the wheat from the chaff in SMPS circuits that
coughed on that....

-jg


Re: Towards better embedded software (long
Quoted text here. Click to load it

We used to have a spark generator that could greate about 3 cm
long arcs (useful in vacuum leak testing).  The acid test was
pointing that at the chassis of some new instrumentation.  It was
usually quite enough to point it at the local ground.

--
fix (vb.): 1. to paper over, obscure, hide from public view; 2.
to work around, in a way that produces unintended consequences
We've slightly trimmed the long signature. Click to see the full one.
Re: Towards better embedded software (long
Quoted text here. Click to load it

Heh ;). We had a somewhat safer version: a 24Vdc-operated contactor, whose
(unquenched) relay contacts drove an inductive mains-operated load. We'd
hook the 24V up to a flying lead with a stripped bare, untwisted/untinned
end acting as a brush, and the contactor to a manky old aluminium plate.
Brushing the wire lightly over the ally made the contactor chatter, made
glorious sparks both on the plate and the relay contacts, and generated a
burst of nasty noise. Anything that could survive close exposure to this was
deemed shippable ;).

Later on we became a little bit more scientific and bought a Schaffner...

Steve
http://www.fivetrees.com
http://www.sfdesign.co.uk



Re: Towards better embedded software (long

Quoted text here. Click to load it

Yes, I'm sorry but I didn't make myself clear - I chose too silly an
example. Let me amplify a bit: The "genuinely unexpected and unspec'd
interaction" is precisely the thing I'm saying lies outside the spec,
and therefore the place where the "bug-free" (meets spec) code can
fall over.

A tighter definition of "bug-free" might be "by design and intention,
never, ever misbehaves under any combination of conditions that can be
thrown at the device, regardless of whether these conditions were
mentioned in the original specification", which I think is basically
what Steve was claiming (that's how I read it, anyway). This
essentially states that the code is so robust that it can be
guaranteed not to act up even when operated in an out-of-spec
environment. But we have merely shifted the burden from defining
"bug-free" to defining "misbehaves" and placing limits on "out of
spec". :) And I don't think anything can be made to meet this
definition of bug-free, because the real world is so malleable. For
instance, I load your code onto a nominally compatible, but subtly
different masking of the microcontroller. This is out of spec. Can I
expect your code to run correctly? Can you blame me for not guarding
against this condition? What if you run my hardware 30 degrees Celsius
above its absolute maximum rating, thereby altering numerous critical
oscillator frequencies in just the right proportions to cause serious
communications errors and total lockup? What if you run it at Vcc=4.1V
when I designed it for Vcc=5V +/-10%?

In summary: The further the environment deviates from the
specification, the greater the chance of failure. It is not possible
to avoid this. We might say that the goal of a good engineer is to
design the system to behave absolutely 100% identically and
predictably right up to the outer border of input conditions beyond
which predictable operation cannot be sustained, and more importantly
to be able to define accurately where that border lies.

We might further say that a bad engineer designs code that follows
some other kind of curve than a square-wave - it gradually (or more
likely exponentially!) becomes more likely to fail as environmental
conditions deviate from the nominal environment for which the device
was designed.

Anyway, I'm basically saying the same thing as you, but approaching it
from the other end.

Re: Towards better embedded software (long
snipped-for-privacy@larwe.com (Lewin A.R.W. Edwards) writes:

Quoted text here. Click to load it

The original point seemed to imply that having experience at fixing
bugs wasn't a good thing.  However, 99% of all the programming I do
involve code someone else has written, even if only peripherally.
Ie, maintenance (the vast majority of programming falls into this
category), using a library, integrating software, porting software,
etc.

Thus, I wouldn't necessarily want to a hire programmer who had little
experience in debugging due to never creating bugs.  I'd first think
they were lying or a bit too arrogant to work in a team.  But second,
being able to deal with imperfect code is an essential skill.
Being able to work without a specification or a formal list of
requirements is a very useful skill also :-)

--
Darin Johnson
    "Floyd here now!"

Re: Towards better embedded software (long
Quoted text here. Click to load it

I didn't mean to imply that troubleshooting was not a useful skill. Like
you, I've done a fair amount of alien legacy code maintenance (although not
99%); my views are very much coloured by this experience ;). I think it's
clear, though, that a tendency to rely on debugging as an alternative to
good design is not a desirable attribute in a job candidate.

Quoted text here. Click to load it

I've occasionally run into something like this. Occasionally there is a gulf
between what I consider "Best Practice" and what is actually going on. Years
ago I probably would have frightened them; in my dotage I've learned
diplomacy and I figure I can help them. I love mentoring... it's how I learn
too. Is this arrogance? Not sure. I consider myself a craftsman; I'm proud
of my skills, certainly.

Quoted text here. Click to load it

Agreed!

Steve
http://www.fivetrees.com
http://www.sfdesign.co.uk



Re: Towards better embedded software (long
Quoted text here. Click to load it

Nice post, sir. I see your point, and agree with some of it ;).

Quoted text here. Click to load it

Pretty much. But there are levels of robustness that I'd expect of any piece
of embedded code, just as Best Practice, and not as a function of a spec.

Quoted text here. Click to load it

By this definition (which wouldn't be mine, incidentally), I agree.

Quoted text here. Click to load it

I wouldn't expect code to run on an alien CPU without a review ("Best
Practice"). However I wouldn't expect code to be so dependent on subtle
features as to fall over when they shift - without at least some sort of
defensive #pragma (and documentation) to guard against changes in any such
features.

Quoted text here. Click to load it

The product would then be out of functional spec, and cannot be expected to
work correctly. Even the customer knows this ;). OTOH, I wouldn't expect a
robust design to be sensitive to changes in independent clock frequencies.

Quoted text here. Click to load it

I *always* include a rail-monitoring watchdogging reset controller, and
always ensure the worst-case threshold is above the minimum Vcc. (Best
practice again.) They're cheap, and guard against a huge range of problems.
I feel naked and exposed without one.

This illustrates a philosophical point: if the kinds of environmental
changes you describe can cause problems, then it's better to stop the code
operating at all than to allow it to run incorrectly. (I've occasionally
seen this idea extended to temperature sensors, but this is not done as
routinely as monitoring rails.)

Quoted text here. Click to load it

I'd buy that. But one can define the envelope and guard against going
outside it.

However: most of the problems you've described are hardware-related. I was
thinking more in terms of the software environment, but I accept that they
are both inextricably linked. Both have to work ;).

Steve
http://www.fivetrees.com
http://www.sfdesign.co.uk



Re: Towards better embedded software (long

" snipped-for-privacy@Signature.Below" does not contain an email address.

Quoted text here. Click to load it

Re: Towards better embedded software (long
writes
Quoted text here. Click to load it

Perhaps they mean "testing"  Rigorous unit integration and system test
is essential and is often referd to as "debugging" by many.



/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England    /\/\/\/\/\
/\/\/ snipped-for-privacy@phaedsys.org       www.phaedsys.org \/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Site Timeline