Re: Version Control in Embedded Systems - Page 5

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

Translate This Thread From English to

Threaded View
Re: Version Control in Embedded Systems


Quoted text here. Click to load it

It is tempting to take an easily found bug as a sign of programming20%
incompetence. But the programmer's ability to do system or integration te=
sting20%
is often limited. The only thing the prorammer can always be charged with=
 is20%
unit testing. I would think all of us on this newsgroup have seen bugs cr=
op up20%
because of integration or system issues that weren't the fault of the pro=
grammer.

Dwain

Quoted text here. Click to load it


--20%
Dwain Wilder
Bear Meadow Folk Instruments
http://www.bearmeadow.com
_______________________________
I arise in the morning torn between a desire to improve (or save) the wor=
ld and20%
a desire to enjoy (or savor) the world. This makes it hard to plan the da=
y.
   97%E. B. White


Re: Version Control in Embedded Systems
Quoted text here. Click to load it
[snip]
Quoted text here. Click to load it
programmer.

Yes. That's all the more reason to keep the software development as
closely coordinated with the hardware as possible in embedded systems.
Version control (and every other development discipline) needs to be
applied across the whole project, not just each piece separately.

--
Paul Hovnanian     mailto: snipped-for-privacy@Hovnanian.com
note to spammers:  a Washington State resident
We've slightly trimmed the long signature. Click to see the full one.
Re: Version Control in Embedded Systems
Quoted text here. Click to load it
programmer.
Quoted text here. Click to load it

   i had to repair a crappy test fixture a couple years ago.  The
engineering tech that built it had sent it to the production floor with
over half the tests mis-programmed.  He would be looking for the right
voltage, but the wrong polarity, and other obvious mistakes.

   The test techs had a list of tests that were bad, and the fixture
missed a lot of defects.  I replaced the worn out wiring harness and
fixed the software. I ran about 100 boards to verify that it worked
perfectly. That is, till someone in SMD assembly swapped some .01 µF
caps with resistors that fed one of the analog MUX inputs.

   It was the first thing tested, and the boards passed, but when they
were installed in the equipment, they slowly charged, and caused a
severe DC offset problem.  The test supervisor came to my bench waving a
board, claiming it had never been tested.

   I set it up and ran the test for him, and it passed. He told me what
it was doing, so a quick look at the schematic, and another board
revealed the assembly errors. While he was ranting about defective
software, I copied the test to the end of the test. By repeating the
test I verified the initial test, and that there were no swapped parts.
I had it ready and running before he stopped long enough to catch his
breath.  After he saw it was fixed, he just walked away shaking his
head.
--


Its August 5, 2003, so I'm 51 today!
Michael A. Terrell
We've slightly trimmed the long signature. Click to see the full one.
Re: Version Control in Embedded Systems



Koushik Banerjee wrote:
Quoted text here. Click to load it
someone
coding
maintainable

It is tempting to take an easily found bug as a sign of programming
incompetence. But the programmer's ability to do system or integration
testing
is often limited. The only thing the prorammer can always be charged with is
unit testing. I would think all of us on this newsgroup have seen bugs crop
up
because of integration or system issues that weren't the fault of the
programmer.

Dwain

But who handles the integration ?  I suppose it is someone from the
development group. And to end it there is a integration testing, where we
are supposed to test what would be typical integration issues. I understand
that there would be still some which could miss this, but the idea is to
have them at minimum. I cannot comment much on the hardware perspective, but
in software, a domain expert would know what cases need to be tested out of
the system test cases to catch bug in this phase.

Koushik.



Re: Version Control in Embedded Systems
On Wed, 6 Aug 2003 12:54:47 +0530, "Koushik Banerjee"

Quoted text here. Click to load it

The optimum development team size is one.

John


Re: Version Control in Embedded Systems


Quoted text here. Click to load it

For a project requiring several man-millenia of effort?

By no means all embedded software efforts are of low enough complexity to be
handled by a single person. Nor are the various aerospace, transportation,
nuclear or medical regulatory agencies likely to be sympathetic to the
argument that you can provide an IVV capability or guarantee QA
independence/oversight with a team of one.



Re: Version Control in Embedded Systems
Hi, Paul:

Paul E. Bennett escribió en comp.software.config-mgmt:

Quoted text here. Click to load it

Yes, there is: it's call "the compiler".

Quoted text here. Click to load it

The surgeon approach works because:
1/ They are working in a very narrow place (so communication problems are
minimized)
2/ They are working on a very repetitive and specialized manner, so
surprises and "conflicts" go to a minimum (the chances of the anaesthesist
jumping for the scalpel crying "me! me! I'll open his belly!" are quite
reduced)

I bet that's not the usual environment for a development team (and yes, it
has been tried to mimic the advantages of the surgical teams into the
programming field: the XP two programmers per PC and trying to specialize
the members of the team and the project tasks so overlap is minimum has
been tried with varied success).
--
SALUD,
Jesús
***
We've slightly trimmed the long signature. Click to see the full one.
Re: Version Control in Embedded Systems


Quoted text here. Click to load it

To be sure, Koushik, a developer does the integration testing. My point w=
as that20%
one can't simply blame a programmer when his/her work is going to integra=
te with20%
other system components. There may be integration or system level issues =
beyond20%
his knowledge. He/she may well do the integration test and have to fix a =
problem20%
in code he/she created or changed. But that does not necessarily imply th=
at he20%
or she should have fixed the problem at unit test if the problem arose be=
causse20%
of integration or system issues. Does that make my point clearer?

Dwain

Quoted text here. Click to load it


--20%
Dwain Wilder
Bear Meadow Folk Instruments
http://www.bearmeadow.com
_______________________________
Hypocrisy is the homage vice pays to virtue.
   97%FranE7%ois de La Rochefoucauld


Site Timeline