Re: Version Control in Embedded Systems - Page 2

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

Wow.  Must be nice to be perfect.  To never make a mistake.  To
have an unlimited memory with inifinite accuracy.  

What's it feel like to be god.  Could you perhaps do something
about the weather in the midwest?  It's been a bit too hot
lately.

--
Grant Edwards                   grante             Yow!  .. I think I'd
                                  at               better go back to my DESK
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


Perhaps you should have read the whole post before replying?

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

Re: Version Control in Embedded Systems
Thanks Chris, they don't read very well in Minnesota.

Quoted text here. Click to load it



Re: Version Control in Embedded Systems
Quoted text here. Click to load it

Do they have a lot of intellectually challenged cows where you live ;+)

--
Robert Cowham


Re: Version Control in Embedded Systems

Quoted text here. Click to load it

As opposed to your locality, where the cows clearly have a regrettable
tendency to overacting. Either that or the pigs have been genetically
engineered to produce beef-flavoured bacon.

d

_____________________________

http://www.pearce.uk.com

Re: Version Control in Embedded Systems
Maybe "Mooron" is the elementary particle of cattle.

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

The Microsoft mantra, that all software has bugs, is an excellent
mind-set for making bugs. If one assumes that bugs are undesirable and
in fact a disgrace, coding can be designed to minimize errors first
pass. I do that, because I like to lie in bed and nibble chocolate and
review my code, and I hate to sweat over emulators and stuff in the
lab. More important, if you depend on testing to find bugs, you'll
never find all of them.

Quoted text here. Click to load it

Comments perform that function.


John


Re: Version Control in Embedded Systems


Quoted text here. Click to load it

Now here's a guy with a work ethic I can understand! I even think what yo=
u have20%
to say has the ring of profundity: if one has so many bugs that one can't=
 fix20%
them through simple insight into the code, they have already infiltrated =
the20%
product to such a degree that you can no longer cure them. You can only r=
inse20%
them, a process that removes a more or less constant ratio of them (and l=
eaves a20%
ratio of them). I've worked on more than a few such projects. Once this h=
appens20%
you can forget about getting the code squeaky clean.

I like the bit about troubleshooting while nibbling chocolate in bed, too=
!

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
process -
Quoted text here. Click to load it
cost.

I ALWAYS design for no bugs.  But I wouldn't be so rash as to say that the
result is always bug-free.



Re: Version Control in Embedded Systems
On Mon, 14 Jul 2003 12:47:36 -0700, "RP Henry" <richard.p.henry@saic
Quoted text here. Click to load it

But is is, absolutely literally, the thought that counts.

John


Re: Version Control in Embedded Systems

Quoted text here. Click to load it
of
process -
Quoted text here. Click to load it
cost.

I'm curious (honestly).  Other than your mindset, what do you do differently
than
the "hack-and-debug" majority.  John suggested thorough code reviews.
Anything else?

Do you actually test your software?  If so do you find bugs during testing?

Is it your experience that hardware designs are normally right the first
time?

How complex are your software designs relative to your hardware designs?

 -- Kevin



Re: Version Control in Embedded Systems
On Mon, 14 Jul 2003 23:00:27 -0400, "Kevin Kramb"
Quoted text here. Click to load it


It's interesting to compare. If I design a PC board full of parts, and
anything's wrong, I have to write an ECO to manufacturing to kluge the
board, and that's a very public admission of error. If it's too
serious or ugly to kluge, we have to roll the PCB rev - lots of work -
re-release the drawings, wait for new boards, build the next
iteration, etc. Again, very public and very expensive. So most
hardware works the first time, because the economic and social
pressures punish sloppy work.

Software, on the other hand, can be patched forever without traces
peeling off, and the entire process is pretty much done in private. So
software, even short routines, are seldom right the first, or even the
second, time. Interestingly, FPGA designs often tend to be like
software, sloppy and buggy on the first pass, at least by some people.
Anybody who designed a hard ASIC this way would be unemployed pronto.

Debugging just tells you about where in your code to look for
blunders, at which time you read the code, smack yourself in the head,
say "of course", and fix it. So why not do that *before* you test the
code?

John



Re: Version Control in Embedded Systems

Quoted text here. Click to load it


Interesting.  I've worked in both the hardware and software camps, and at
most of the software jobs we had even more elaborate release procedures for
software than for hardware.  ECOs required in both cases, but the hardware
release process didn't usually include releasing modified test plans and
test reports, as well as updated design documents (use cases, specs,
whatnot, marketing and sales signoffs, etc).  Of course, I've worked in
software environments where whatever we installed on the master server was
what the customer got, and there wasn't even any source code control
system - just nightly backups of the server.

After trying it a variety of ways, I prefer a strong ECO process with the
QA-maintained document control library for released documents, and both
user-level (ie, just for me and my private use) and group-level (ie, for
everyone on the team) source code control systems.  But when it comes down
to it, I'll do whatever the customer wants.  If he doesn't care, then I do
it my way ;)

Quoted text here. Click to load it

It all depends how you work and how your project runs.  If your
specifications are rigid, you can do a lot of analysis and design checking
up front and save debug time in the long term.  If your project is a
never-ending series of "we like this but not that and can it also do this
other thing?" it gets harder to maintain design discipline nd analysis.  I'm
a big fan of writing self-tests and test stubs in all of my classes now so
that by the time I start integrating things I've already got a high level of
confidence that my components actually work.  "Baby Steps" is my work
mantra.

Kelly



Re: Version Control in Embedded Systems
Quoted text here. Click to load it

Most ICs seem to take at least a couple of expensive tries to get right and
many take more than that. It may vary between ASICs and full custom designs.

Ever considered how to apply a software patch to a few million TVs? Once it
really goes out you are not going to patch it unless it is something very
serious.

--
Stephen Baynes       CEng MBCS
DTG-S&S, Philips Semiconductors Southampton
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

It does happen though. The first software version for the new Teac DVB-T
STB recently released in Australia sucked so badly that users demanded
an upgrade, and got it. You couldn't skip unused channels, and settings
didn't save correctly.

Rob

Re: Version Control in Embedded Systems

: >
: > > On Mon, 14 Jul 2003 23:00:27 -0400, "Kevin Kramb"
: > > >
: > > >Is it your experience that hardware designs are normally right the
first
: > > >time?
: > >
: > >
: > > It's interesting to compare. If I design a PC board full of parts, and
: > > anything's wrong, I have to write an ECO to manufacturing to kluge the
: > > board, and that's a very public admission of error. If it's too
: > > serious or ugly to kluge, we have to roll the PCB rev - lots of work -
: > > re-release the drawings, wait for new boards, build the next
: > > iteration, etc. Again, very public and very expensive. So most
: > > hardware works the first time, because the economic and social
: > > pressures punish sloppy work.
: > >
: > > Software, on the other hand, can be patched forever without traces
: > > peeling off, and the entire process is pretty much done in private. So
: > > software, even short routines, are seldom right the first, or even the
: > > second, time. Interestingly, FPGA designs often tend to be like
: > > software, sloppy and buggy on the first pass, at least by some people.
: > > Anybody who designed a hard ASIC this way would be unemployed pronto.
: >
: > Most ICs seem to take at least a couple of expensive tries to get right
and
: > many take more than that. It may vary between ASICs and full custom
designs.
: >
: > Ever considered how to apply a software patch to a few million TVs? Once
it
: > really goes out you are not going to patch it unless it is something
very
: > serious.
:
: It does happen though. The first software version for the new Teac DVB-T
: STB recently released in Australia sucked so badly that users demanded
: an upgrade, and got it. You couldn't skip unused channels, and settings
: didn't save correctly.
:
: Rob

Hardware *bugs* are always more costly upfront because of the loss of
material(say boards and other inputs) than software. Few years back Philips
(one of my previous employer) had to move the DVD player out of the
AsiaPacific market because it wouldnot play pirated VCDs, reason :
developers coded only to the specification, which did not include the
pirated format, but there were competetive products playing, so we needed to
do the same to stay in the market. No one to blame but at the end Customer
rules.



Re: Version Control in Embedded Systems
Koushik:

yes, many embedded systems can be designed to be easily field
upgradable  - you just need a fixed bootstrap routing and enough
hardware that works to communicate.  FPGA's may be easily fixed in the
same manner, if one loads them from a piece that can be field upgradable
- i.e. - load the thing from flash via a micro, and your VCS can be
implemented in all of your software.  ASIC and mask ROM people come from
a different world, because the mask charges are outrageous, and you
can't fix burned silicon in the field, but for volume production, it's
the only way to go.

Andrew

Koushik Banerjee wrote:

Quoted text here. Click to load it


Re: Version Control in Embedded Systems
Quoted text here. Click to load it

A good verification team would eliminate the "couple of expensive
tries to get it right."  Our ASIC group has put out three ASICs that
were first pass successes.

Of course, we're talking about pretty big designs for non-consumer
products - so development time is on the order of many quarters (4 or
5), not months as Philips would be doing.  But that still doesn't
excuse a good verification team.

   Marc

Re: Version Control in Embedded Systems

Quoted text here. Click to load it

Open Source has the virtue of not being done in private. Real authors leave
their name on their work, for better or for worse. They participate in the
support groups for their work, and their email is public.

Imagine if the creator of "Clippy" (the Office paperclip character) were so
exposed! ;)

--
Kenneth Porter
http://www.sewingwitch.com/ken /

Re: Version Control in Embedded Systems
Quoted text here. Click to load it

Or worse yet, MS Bob!

--
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.

Site Timeline