Re: Version Control in Embedded Systems - Page 3

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
On Mon, 04 Aug 2003 23:10:06 GMT, Kenneth Porter

Quoted text here. Click to load it

Extreme Programming is done, in one version, by pairs of programmers.
Again, better code gets done whan it's done in public. It's
interesting that a 2:1 increase in manpower is justified by the better
quality.

Quoted text here. Click to load it

Is lynching legal in Washington State?

John

whose wife thinks Clippy is "adorable."



Re: Version Control in Embedded Systems
In comp.arch.embedded John Larkin
[...]

Quoted text here. Click to load it

I don't think you're getting that thing about the manpower increase
right.  Just because "Extreme Programming" has two people working
together, at the same screen, all the time, doesn't imply one of those
two would have been unemployed otherwise.  The key to XP is not how
many people work on the code, but how they *do* that work.

It's more like this: XP uses half as many development machines
compared to other methods, because two team members always share one
box, at all times.  I.e. it's not a 2:1 increase in manpower; if at
all, it's a 2:1 *decrease* in machine power.

The only real drawback is that you can't use the typical cubicle
office space pattern easily --- XP teams need more space per cubicle,
and they'll be talking all the time, so you need better sound
isolation between cubicles.  In other words: you need actual offices,
not cubicles.
--
Hans-Bernhard Broeker ( snipped-for-privacy@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.

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

"Mindset" is probably the key thing. Other elements include:
  - Planning: I design before I code.
  - Defensive design: I use a variety of techniques to ensure robustness,
and insensitivity (and hyper-sensitivity) to change.
  - Synchronism: I use all the same techniques I learned doing ASIC design
to ensure synchronism i.e. positive data handover.
  - Maintainability & readability: if I can't read the code at a glance, I
consider it broken.

Quoted text here. Click to load it
testing?

Of course ;). But the bugs I find tend to be glaring and easy to find. I
almost never introduce, or indeed need to find, subtle bugs. I emphasise
that my testing tends to be code verification, rather than active debugging.

Quoted text here. Click to load it

Mine tend to be - I've had right-first-time design drummed into me, and with
hard ASIC design, you tend not to get a second chance. This presupposes that
the spec was correct, of course ;).

Quoted text here. Click to load it

I get asked this a lot, and I understand why - but my response is always the
same: I break complex things down until they're a collection of simple
no-brainers ;). An example: I did a revision of a rack-based product
involving up to 70-odd intercommunicating processors, in 4 classes, designed
in C and hand-compiled in assembler - with no debug tools at all. All I
could do was turn the system on and see if it worked. Apart from one typo
which positively yelled at me, it did indeed work first time. The product
has since been extensively field-tested (the '98 World Cup TV coverage
depended in part on it working correctly); no bugs were reported or have
surfaced since.

Complexity isn't the issue. I've seen poorly-designed 2-page programs.
Perhaps the most constructive thing one could do to ensure bugfree design is
to take the debug tools away ;).

So what's special about me? Nothing. I just hate debugging. As another
poster said, there will always be bugs that debugging won't find *unless
they're designed out*.

With apologies for thread drift and soapboxing...

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



Re: Version Control in Embedded Systems
           snipped-for-privacy@ra.rockwell.com.invalid "Kevin Kramb" writes:

[%X]

Quoted text here. Click to load it

Yes. Very thorough review of the original requirements specification
and contract details in the first place. Until the original specification
is as right as it can be it is pointless designing any part of the
system. From that point it is just a matter of factoring the design so
that you end up with a clearly defined functional modularity and thus
removing the apparent complexity of system by improving your understanding.
 
Quoted text here. Click to load it

Absolutely yes. Probably more than most. Each individual routine is
tested as soon as it is written (one of the beautiful things about
working with Forth is the lack of need for coding test stubs). That
way if the code does not fulfil the criteria of the requirements it
is easily modified, retested and improved before it is submitted for
inclusion in the intergated product (Edit Code->Compile->Test->Edit
Code->Compile->Test.......).
 
Quoted text here. Click to load it

Mostly yes. Usually when the design problems have been very thoroughly
understood and the solution becomes very apparent. It is usually better
to think a little longer rather than go through making several versions
of the PCB or chip (costs too much money that way).
 
Quoted text here. Click to load it
 
Mine range from equal to the software doing very highly complex things.
However, I never feel that my software is, itself, highly complex.

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

I agree completely. One further point: I can plan (i.e. allow time) for
verification; but I can't plan for debugging. Therefore I prefer the former
;).

Quoted text here. Click to load it

I've done both ;). Also, as a consultant, I guarantee my work - if any bugs
do show up, I will fix them - whatever it takes - at no cost to the
customer.

I *much* prefer the formal approach - deliverable/demonstrable test
harnesses that get maintained along with the code, and a structured
bottom-up code walkthrough. However, I've had to learn to "wing it"
sometimes - see my earlier post re software testing with no debug equipment.
As a consequence, and as a survival strategy, I've wound up making my code
as clean and as clear as I can from the start, and actively avoiding bugs
while coding. I don't actually recommend this no-safety-net approach - but
sometimes I've had to perform the impossible in ridiculously short
timeframes knowing that I wouldn't get a second chance.

Clarity and maintainability are now probably my two most important
buzzwords. They're the same thing, really.

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



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

I'll agree with the above, but there is another factor at work here.
In most cases, hardware engineers have a better understanding of the
overall system requirements. This also extends to those of us who do
embedded s/w development, where there is very tight coupling between
the s/w development and the overall product development.

I've worked in everything from the embedded world to business systems
s/w. The most significant factor affecting the success (or failure) of
the software is whether those that do the analysis, design and testing
understand the domain for which they are developing.

Tools and formal practices are good, but they will fail to produce a
quality product if the developers don't understand the problem to be
solved. Unfortunately, there is a trend in some industries to separate
system, hardware and software development, sometimes separated by many
time zones.


--
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
On Tue, 15 Jul 2003 10:07:08 -0700, "Paul Hovnanian P.E."

Quoted text here. Click to load it


This is validation -- that is checking whether the proposed solution
is appropriate. There are analysis tools available that help the
engineer address this, but I think you're correct in asserting that
this is a poorly travelled area.

Business is driven by economics and the Capitalism of the Western
World calls for businesses to seek a competitive edge. That's why US
companies employ Indian programmers or have their goods manufactured
in China. Typically a business must view itself as global rather than
provincial, because an outside company could come in and quickly
acquire a reasonable market share. Obviously to capitalise on global
resources & skills, a company needs to acquire the organisational
skills, but it can be done and in fact (as you have pointed out) many
companies are doing it.

I actually see the separation of hardware & software development as a
good thing, mainly because systems are becoming so complex that
finding people who have the right skillset in both hardware & software
is becoming very difficult. Also "software" today is no longer about
"cutting code" which only really consumes about 5% to 10% of
engineering effort. It's about producing a deliverable that will make
the customer happy. So most of the effort goes into analysis, design
and testing. To do this properly you basically need a trained Software
Engineer rather than a hardware engineer who's a weekend programmer
;-)

Ken.

Quoted text here. Click to load it


+====================================+
I hate junk email. Please direct any
genuine email to: kenlee at hotpop.com

Re: Version Control in Embedded Systems
On Tue, 15 Jul 2003 19:59:16 -0700, "Paul Hovnanian P.E."

Quoted text here. Click to load it
<snip>
Quoted text here. Click to load it

When I say "validation", I actually did mean validation and not
verification. The process you describe is one of verification. In
recent years the use of the term "validation" has become synonymous
with that of "verification"  -- even the FDA has done this. However by
definition, validation is not verification.

Quoted text here. Click to load it

Not at all -- I'm assuming that there is a Systems Engineering phase.
Also I'll dispute that "in practice" that these requirements are NOT
"done long before the system architecture is established".  Why do I
say that -- well Systems Engineering is not done in a lock-up in
isolation. For a good System Spec to be produced it involves the
collaboration of all stakeholders. The Systems Engineer acts as the
mediator of the Domain Experts. He/she looks at the marketing
requirements and with the inputs from the hardware, mechanical &
software representatives (etc) produces a System Spec which would have
a manageable development risk. What do the engineers do during this
time? Well they're not sitting at their desks twiddling their thumbs
or playing solitaire. They may be:
o ringing up vendors for parts & availability
o preparing & running prototypes
o researching development tools
o compiling a list of prospective micros to use
o preparing pseudo Bills of Materials for costing

I do agree that a good System Spec should be produced before "real"
development starts.

It should be noted that engineers are lazy sods (me included). To
mitigate against development risk, they typically adopt a modus
operandi or pattern of behaviour that has this tendency. This
includes:
o Adopting tried & proven methods
o Utilising domain experts
o Using mature architectures
o Using mature components
o Utilising a previous projects artefacts such as documents & code
o Working within a reasonable comfort zone, that is, working with
equipment that you know how to use, working with people you know, etc.

Now reading this you may think that engineers are pretty boring people
(ever been to a party with one ;-)  ), but obviously they do venture
out and try new things. The point I'm getting to here, that is, it may
be that the new project is similar to the previous one. This is the
case for a company that is producing a limited product range. So the
System Spec for the new product may be reasonably predictable.

Contractors are probably the laziest sods of all ;-)    ---  have you
ever notice how they re-use aspects of their previous projects.
However this usually isn't reflected in their invoice.   (For the
record, I have been a contractor :-) )

Quoted text here. Click to load it

The above is great for "design" and I'm all for it, but the analysis
of say, the Software system, still has to be done by an entity with a
brain. Sure there are analysis tools which help greatly. I've used
iLogix's Rhapsody and can appreciate the benefits of such technology.

Ken.

Quoted text here. Click to load it


+====================================+
I hate junk email. Please direct any
genuine email to: kenlee at hotpop.com

Re: Version Control in Embedded Systems
           snipped-for-privacy@DELETEMEfivetrees.com "steve at fivetrees" writes:

Quoted text here. Click to load it

Trouble is those that just sit and hack at code tend to introduce nearly
as many new bugs as they are eliminating old ones. Never mind that once
you have written and released buggy code you will probably never rid
yourself of it.
 
Quoted text here. Click to load it

A well thought out system design will have eliminated 99% of all the
bugs in specification and design before you have even laid one line of
production code. It should also, despite complexity of the problem, be
simple enough to understand fully. This will assist in elimination of
the final 1% of bugs during the integration testing. Factory testing
and Commissioning testing can then be "REALLY" proving to the customer
that you have completed a system to his requirements.
 
Quoted text here. Click to load it

I for one do not consider hiring "software only types". I always go
for those who have an aptitude in hardware topics as well (whether
electrical, mechanical or electronic). Note that on team projects
you have to have some balance in the team and the team must be able
to understand each others work in order to peer review it.

--
********************************************************************
We've slightly trimmed the long signature. Click to see the full one.
Re: Version Control in Embedded Systems
snipped-for-privacy@amleth.demon.co.uk ("Paul E. Bennett") wrote in

Quoted text here. Click to load it

The extreme programming guys would take issue with this in that until
you start delivering releases to the customers they tend to be very
unclear as to what the sepcifications should be. Their approach is to
have a development process that can cope with change, as that is a fact
of life.

Quoted text here. Click to load it

It can all depend on what you are doing with software. I have a worked
on a number of systems where I have had to rely on third party
components (ranging from middleware to Microsoft Office), and indeed the
operating system and compilers. I have come across bugs in the
compilers, bugs in Office, etc, etc. These are nasty and my ability to
persuade Microsoft to fix things somewhat limited - I have to find the
bug, find what caused it, and then find workarounds...

Software these days tends to depend on a heap of other stuff around it.

--
Robert Cowham

Re: Version Control in Embedded Systems
On Wed, 16 Jul 2003 09:54:52 -0700, John Larkin

Quoted text here. Click to load it

An excellent point, highlighted many, many times in my own
experience, as well.  Few people really know what they want
before they get to touch and feel what they don't want.

There are a few wonderful customers who have been down the road
a few times and can provide both an excellent definition to
start and an excellent background of experience to draw from.
Some of those are even able and willing to pay for the job at
hand, too.  If anyone has a magic formula for causing that
select set of customers to track you down and hire you, I'd love
to hear it.  I know one when I see one, but they are as rare as
hen's teeth and I can't base a business on just that group.

But give someone something they don't want and they'll often
find out some one fact quickly and let you know.  Fix that and
come back and they'll find yet another one that "slipped
through" the last time.

Knowing this up front and still managing to get the right thing
done in the end, on an acceptable schedule and cost, is some of
what keeps the work interesting.

Jon


Re: Version Control in Embedded Systems

: An excellent point, highlighted many, many times in my own
: experience, as well.  Few people really know what they want
: before they get to touch and feel what they don't want.
:
: There are a few wonderful customers who have been down the road
: a few times and can provide both an excellent definition to
: start and an excellent background of experience to draw from.
: Some of those are even able and willing to pay for the job at
: hand, too.  If anyone has a magic formula for causing that
: select set of customers to track you down and hire you, I'd love
: to hear it.  I know one when I see one, but they are as rare as
: hen's teeth and I can't base a business on just that group.
:
: But give someone something they don't want and they'll often
: find out some one fact quickly and let you know.  Fix that and
: come back and they'll find yet another one that "slipped
: through" the last time.
:
: Knowing this up front and still managing to get the right thing
: done in the end, on an acceptable schedule and cost, is some of
: what keeps the work interesting.
:
: Jon
:

It is right to get a customer "who knows what he wants" in software
industry, but it is not the case for hardware. It is very expensive, and the
customers _usually_ knows "what they want" in the hardware industry. Most
companies into hardware do their own design and manufacturing, and others
usually are already big and long-time players to know what would work with
their design. The difference with a software and hardware can be tested on
cost terms as:
Software (say a particular version) once written can be used/sold "n" number
of times with out any additional costs(barring packaging/shipping and other
such costs),
BUT
Hardware except the designing , the actual hardware needs to be produced "n"
number of times if you plan to sell it so many times (along with other costs
of packagin/shipping ...)

So fixing a software bug when released into the market/into production even
for embedded systems is easy , but for the hardware it is impossible since
you need to replace the whole stuff or maybe if possible write something new
in software to achieve the same functionailty , though not quite possible
always, and any function thru hardware is performance efficient than done in
software.

Koushik.



Re: Version Control in Embedded Systems
On Wed, 30 Jul 2003 22:08:29 +0530, "Koushik Banerjee"

Quoted text here. Click to load it

It's rare to find them, though.  So one cannot base their
software business on such customers unless one has a magic
formula here or a narrow enough market where this is often the
case.  I think some of the same issues hound hardware, as well.
(In fact, I know some do, since I work in designing and building
scientific and commercial instrumentation and I see the same
issues come up in finding the _right_ system specifications.)

Quoted text here. Click to load it

Ah, you mean the opposite of what I thought you mean.  In other
words, you mean that in hardware you *must* have a customer who
knows what they want?

Quoted text here. Click to load it

Plus, there is nature working for you.  Nature/physics pretty
much is the same where ever you go in the world and problems
have a certain set of well known boundaries for their solutions.
Software has to deal with physics, too, of course (the embedded
work I do, for example), but facets can also often be more about
addressing human likes and dislikes, which are vastly more
fickle than nature.  But then, so does hardware have to deal
with this (ease of use.)

Quoted text here. Click to load it

Indeed.  Hardware is tangible.

I'm not sure exactly where you were going.  I tend to understand
and agree with you about the details you've mentioned.  So
perhaps all you wanted to do is highlight another aspect I'd
failed to address.

The only thing I take issue with, if at all, is if you are
saying that customers of hardware generally know what they want
and that you *can* rely on having such customers when you do
hardware design.  If that is what you think or are arguing, then
I have to disagree.  Hardware customers are not always (or
often, perhaps) all that knowledgeable about what they want.
[Some are trained over time to _want_ only what can actually be
made well!]

But the street of bankruptcy is littered with companies failing,
in part, because of building what their perceived customers
_told_ them they wanted.  Failing to ask questions about what
they are willing to pay for or failing to understand who the
real customer (the one willing to actually pay) is and getting
their information from the wrong base... and so on.

It's wonderful, as always, when one's customers are all well
informed about their requirements, know what they need/want,
know what they are willing to pay and for what, and have the
where-with-all to actually pay a good price.

Still, I think many of the same problems exist in both domains,
as far as customers are concerned.  There are differences, of
course.  And you've painted some of those well.

Jon


Re: Version Control in Embedded Systems

:: >It is right to get a customer "who knows what he wants" in software
: >industry,
:
: It's rare to find them, though.  So one cannot base their
: software business on such customers unless one has a magic
: formula here or a narrow enough market where this is often the
: case.  I think some of the same issues hound hardware, as well.
: (In fact, I know some do, since I work in designing and building
: scientific and commercial instrumentation and I see the same
: issues come up in finding the _right_ system specifications.)
:
: >but it is not the case for hardware.  It is very expensive, and the
: >customers _usually_ knows "what they want" in the hardware industry.
:
: Ah, you mean the opposite of what I thought you mean.  In other
: words, you mean that in hardware you *must* have a customer who
: knows what they want?
:
: >Most
: >companies into hardware do their own design and manufacturing, and others
: >usually are already big and long-time players to know what would work
with
: >their design.
:
: Plus, there is nature working for you.  Nature/physics pretty
: much is the same where ever you go in the world and problems
: have a certain set of well known boundaries for their solutions.
: Software has to deal with physics, too, of course (the embedded
: work I do, for example), but facets can also often be more about
: addressing human likes and dislikes, which are vastly more
: fickle than nature.  But then, so does hardware have to deal
: with this (ease of use.)
:
: >The difference with a software and hardware can be tested on
: >cost terms as:
: >Software (say a particular version) once written can be used/sold "n"
number
: >of times with out any additional costs(barring packaging/shipping and
other
: >such costs),
: >BUT
: >Hardware except the designing , the actual hardware needs to be produced
"n"
: >number of times if you plan to sell it so many times (along with other
costs
: >of packagin/shipping ...)
: >
: >So fixing a software bug when released into the market/into production
even
: >for embedded systems is easy , but for the hardware it is impossible
since
: >you need to replace the whole stuff or maybe if possible write something
new
: >in software to achieve the same functionailty , though not quite possible
: >always, and any function thru hardware is performance efficient than done
in
: >software.
:
: Indeed.  Hardware is tangible.
:
: I'm not sure exactly where you were going.  I tend to understand
: and agree with you about the details you've mentioned.  So
: perhaps all you wanted to do is highlight another aspect I'd
: failed to address.
:
: The only thing I take issue with, if at all, is if you are
: saying that customers of hardware generally know what they want
: and that you *can* rely on having such customers when you do
: hardware design.  If that is what you think or are arguing, then
: I have to disagree.  Hardware customers are not always (or
: often, perhaps) all that knowledgeable about what they want.
: [Some are trained over time to _want_ only what can actually be
: made well!]
:
: But the street of bankruptcy is littered with companies failing,
: in part, because of building what their perceived customers
: _told_ them they wanted.  Failing to ask questions about what
: they are willing to pay for or failing to understand who the
: real customer (the one willing to actually pay) is and getting
: their information from the wrong base... and so on.
:
: It's wonderful, as always, when one's customers are all well
: informed about their requirements, know what they need/want,
: know what they are willing to pay and for what, and have the
: where-with-all to actually pay a good price.
:
: Still, I think many of the same problems exist in both domains,
: as far as customers are concerned.  There are differences, of
: course.  And you've painted some of those well.
:
: Jon
:
You are right in saying that the problem exists in both domain, but I feel
the problem exists more in software domain considering the knowledge base of
the software companies, customers and the engineers (I am not saying the h/w
engineers are better than s/w ones, but the number of new things done in h/w
is less than in s/w)and this contributes to the artifacts that are needed to
get a job done.
My belief is that a company investing in h/w  is dollar ($$) rich first to
get all the right setup (say you need more than few computers and a garage
to start with, you need a dust-free environment, some special dress, h/w and
other stuff to get started), and after investing in all these, if they are
not sure about their customers and their requirements, it is pretty much a
ruin for the company. That is the company is likely to close down any day
because of lack of business. But in sofware, you can rent a few machines,
set up few tables in a garage, and get some hackers to start with. Once you
feel that you are getting good business , you can expand, or simply stop
paying the rent of the computers and garage, and you would be thrown out
with very little to lose. The investment pattern is very different.
But yes, hardware does get effected by software these days, say when the
e-crash took place in 2000, all the switch manufacturing companies took a
hit, since their customer was maily companies into e-commerce, and those
either cancelled or postponed their orders. Lucent, Cisco took hits that way
then.

And if you are talking of "usuability" case in hardware, I think the core
functionality is what drives a product, other than the look & feel factor.
And the core costs more than the UI factor, like how the front-panel looks
like in a DVD player or the box looks like can be different in different
regions, but most people would be more interested in what it can do (the
core part), which is the expensive part.

Well otherwise both of them are same in most ways. You are right about that.

Koushik.



Re: Version Control in Embedded Systems
On Thu, 31 Jul 2003 19:25:00 +0530, "Koushik Banerjee"
Quoted text here. Click to load it

Hardware design tends to have fewer (lots fewer!) bugs, but there may
be another explanation: hardware is generally parallel and
synchronous, while software is sequential within separate concurrent
threads, and essentially asynchronous. So hardware logic designers
have much better visibility and control over system states.

John



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

... Which is exactly why I design my code to be synchronous. And why I have
so few software problems.

I consider that designing hardware (esp. ASICs) taught me the most about
writing good software ;).

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



Re: Version Control in Embedded Systems
On Thu, 31 Jul 2003 16:54:50 +0100, "steve at fivetrees"

Quoted text here. Click to load it

Me too. I design embedded software the same way as I design logic: run
nice clean little state machines at a regular rate, run each to
completion every shot, and never assign resources dynamically. Fully
decode states. "Inter-task" communications is via variables shared
between state machines. No queues. No abstraction. No glamour. No
bugs.

I've written a few RTOSs, but I find lately that I really don't need
them. Luckily, I'm an engineer most of the time, so I view programming
as a mildly tedious task to be finished, not as a lifelong career. So
I just want to get it over the quickest, most reliable way, even if
that involves simplistic grunt work that wouldn't look good on a
resume.

John


Re: Version Control in Embedded Systems
Hi again Koushik:

Koushik Banerjee escribió en comp.software.config-mgmt:

Quoted text here. Click to load it

[and a lot of uneeded text follows]

First of all, I would ask you NOT to answer after the text.  Just leave what
is relevant for your answer and do it just where it do has any mean!

Quoted text here. Click to load it

What Steve was telling you was that he had found his "best possible way" by
doing the way he was doing it: going to the point it was about the most
direct and simply way he could think about!

Quoted text here. Click to load it

As it has already been answered to you, that isn't really true: there are
two famous "idioms" regarding programing that never will really be repeated
too enough: Do it as simply as possible (but not simpler); and do it the
most expectable way.  Ten lines for a clear and expectable 'while-then'
loop will be less bug-prone than a "clever" 'for' oneliner for sure!
Someone named it "programming-on-jeans" versus the "too clever"
"programming-on-smoking" concept.

Quoted text here. Click to load it

Again, that's what you're teached in school.  When you affront a 4-6K lines
project (hardware or embebbed projects tend not to be too long) the
"formal" OO approach not only isn't too efficient (if you tend to be too
"formal" you cannot take advantages from the oddities of the hardware
you're managing) but it tends to be too buggy too (all your formalities,
being such a "little" project is overload -the percentage of API-related
code lines vs. "productive" code lines is too high, that can fit well
within your "the more code lines, the more bugs" theory).
--
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

I disagree - "making best use of the language" is not a factor. Writing
reliable code often involves using a *subset* of the language. This is
especially true of C++, which is poorly suited to embedded work and has many
constructs that simply have no place in embedded work.

Quoted text here. Click to load it

Again I disagree. I write object-oriented C (and assembler) all the time.
Design is separate from coding - except with languages like C++ where the
distinction is blurred. (Is this a good thing? Discuss ;).)

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



Re: Version Control in Embedded Systems
Quoted text here. Click to load it
variables,
controlled
you
the
you,
since

Frankly, the only thing that is going to give *me* sleepless nights, it not
having complete control of what runs on the systems I design, and the faults
that can result.  What looks simple and clean in an HLL may not be, in terms
of the code that actually runs, on the MCU.

Now, I will grant that there are benefits to compile-time checking over run-
time "defensive programming"--particularly for "access methods", which can
resolve to simple inline fetches; but understanding the system is far more
important than the programming language used to implement it.

Quoted text here. Click to load it
or
the

No, it depends on understanding the meaning (and in embedded work, often
the implementation) of the lines of code one writes.  In many cases, it also
depends on the availability of tools.



Site Timeline