> > > > 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 relay.
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 at least 12 user space packages. This is millions of lines of code, some quite poor (I wrote that), some mature (other packages) some stable (linux kernel). 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. Jon ------------------------------------------------------------------------------ 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 step-by-step tutorial videos with LearnDevNow. Subscribe today and save! http://pubads.g.doubleclick.net/gampad/clk?id=58040911&iu=/4140/ostg.clktrk _______________________________________________ Sdcc-user mailing list Sdcc-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sdcc-user
