> > Just my 2c worth :-) Other may agree to differ....
> Well...I work as a design engineer, usually on industrial control
> applications. Complexity is the enemy of stability, and unnecessary
> complexity is a design flaw...that's my usual mindset. Cost is often a
> secondary consideration for anything other than bulk consumer
> electronics. When a bug in someone else's huge volume of code can
> result in a multi-hundred-ton machine to jerk in the wrong direction and
> kill people, and it comes down on ME, I don't want
anything but the bare
> minimum on the board that controls it.
Yes, I hope you design my medical equipment and fly by wire boxes. But
in the example I was giving the task was an Ethernet driven 8 channel
I built such a box a while back, its used to control mains lights. So
far its run for 5+ months with no problems, but the application does not
required a high reliability, its not directly a safety critical system.
If it fails it needs fixing but nobody has died.
You can tend to make unwise or rash decisions if you miss understand
complexity, risk, provability and testability.
Lets take complexity for example. I designed and built (commercially) a
CCTV system based on embedded linux. The complexity is HIGH, in fact
its huge.... you have a Linux kernel, 6MB of additional source - none of
it proven or formally tested.... it depends for its function on
12 user space packages. This is millions of lines of code, some quite
poor (I wrote that), some mature (other packages) some stable (linux
As it happens this systems have run of 5 years, they fail only when the
hardware fails, complexity is not the enemy of stability but is the
enemy of provability and testability ! It might have been unreliable,
you can't tell in advance - a percentage of the testing was in the field
so to speak.
For some applications I use a watchdog processor monitoring I/O (PIC for
example, good stable choice) with a few hundred lines of C. Plus an ARM
linux box... in this design the PIC is used to watch over and second
guess the control system. The control system can then be a sprawling
mess with networking and back end databases all kinds of unprovable
stuff. The PIC will catch unwise I/O events and halt the system. This
half way house design is very
effective. You spend the time and effort
on the PIC code to test it and as much as possible prove it.
Its not required to build everything to one tolerance, I have met people
with that attitude, most design for defence. Also most are the type of
people who piss away a month writing something in assembler just to have
it cough in the field with a unchecked buffer overrun that wasn't caught
in testing .....
You can move the sliders around between complexity, provability, cost,
speed of development... the best outcome is the compromise that suits
the task, it nearly always is a compromise.
Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
Discover the easy way to master current and previous Microsoft technologies
and advance your career. Get an incredible 1,500+ hours of
tutorial videos with LearnDevNow. Subscribe today and save!http://pubads.g.doubleclick.net/gampad/clk?id=58040911&iu=/4140/ostg.clktrk
Sdcc-user mailing listSdccfirstname.lastname@example.org://lists.sourceforge.net/lists/listinfo/sdcc-user