Go here to sign up for The Embedded Muse.

Embedded Muse 218 Copyright 2012 TGG January 3, 2012

You may redistribute this newsletter for noncommercial purposes. For commercial use contact jack@ganssle.com. To subscribe or unsubscribe go to https://www.ganssle.com/tem-subunsub.html or drop Jack an email at jack@ganssle.com.

EDITOR: Jack Ganssle, jack@ganssle.com

Editor's Notes

Lower your bug rates. And get the product out faster.

Sounds too good to be true, but that's the essence of the quality movement of the last few decades. Alas, the firmware community didn't get the memo, and by and large we're still like Detroit in the 1960s.

It IS possible to accurately schedule a project, meet the deadline, and drastically reduce bugs. Learn how at my Better Firmware Faster class, presented at your facility. See https://www.ganssle.com/onsite.htm .

I wish everyone a very happy New Year. It sure is hard to figure out what 2012 will be like, but reports I'm reading suggest that at least in the world of semiconductors conditions should improve. For 2011 semi sales were up only 2%. EETimes reports that sales at the top 20 vendors were up 6%, accounting for $225B in revenue. Intel alone sold more than $50B last year.

Quotes and Thoughts

"Don't worry if it doesn't work right. If everything did, you'd be out of a job." - Mosher's Law of Software Engineering

Tools and Tips

Michael J. Linden responded to my calls for input on USB scopes: "I've been using a CleverScope CS328A USB MSO for a few years now and my decision to purchase it over some less expensive units has been validated time and time again. (http://www.cleverscope.com/products/CS328A).

"This is a 100 MHz USB MSO with two analog channels, eight digital channels (nine if you include the external trigger which can be displayed along with the other digital channels), and 4 mega-points of memory. The sampling rate is 100 MSa/sec (one-shot = 10 MHz) which is more than enough for the embedded work I do. In my case I opted for the 14-bit samplers and 10 MHz signal generator options.

"This USB MSO just seems to be better thought-out than others on the market. It also has a beautiful and intuitive user interface that seems leaps beyond the others I've looked at. In particular, I find the time and voltage scales that are displayed on the edges of the graph to be very useful. The CleverScope folks are also very good at updating the firmware and software. When I bought this unit it had no serial decoding capabilities. However, thanks to updates, I can now decode UART, SPI, and I2C communications (this has come in handy more than once) with this scope. I can also stream captures (trigger-by-trigger) to disk files for later evaluation. All in all, a very nice and capable unit that I use on a daily basis.
"Also, it looks like PicoScope just came out with this one (their first MSO). Nice feature set, but not much sample memory. Fair price, though: http://www.picotech.com/mixed-signal-oscilloscope.html ."

Jerry Isdale wrote: "I recommend taking a look at the offerings from Seeed Studios...

"In particular the DSO Nano and DSO Quad, but their other (board only, no enclosure) products are quite cool and inexpensive. I have one of the original DSO Nano scopes and find it quite useful. The V2 is a wholly reworked version and includes a signal generator. The whole thing easily fits in a pocket, which is hard to beat for on-the-go or cluttered bench jobs."

From Tom LeMense: "You asked about USB-based tools in your latest Embedded Muse - here are my comments regarding the Saleae Logic USB logic analyzer. I think I may have seen this analyzer mentioned by another of your readers in an earlier Embedded Muse issue, but I just cannot help but take the opportunity relate my positive experience with this tool:

"I simply cannot say enough good things about the Saleae "Logic". The unit itself is small and travel-friendly, packaged in a rugged aluminum housing, uses a standard 0.1" header for probe interconnects, and has wonderful support software (Windows, Mac, and Linux OS are all supported). At 24 MHZ acquisition rate, it's certainly not fast enough to handle external address/data busses on a high-speed modern uP or uC - for that, you need to shell out big bucks for a "real" logic analyzer. Logic is more than adequate, however, for snooping CAN, SPI and I2C busses; examining multi-phase bridge driver inputs; or observing Manchester baseband signals from RF remote control units, as examples. (I've used Logic for all of these purposes). For $150, I'm completely satisfied with my purchase, and have recommended Logic to numerous other engineers as well.

"http://www.saleae.com/logic/

"There's also a 16-channel version, Logic16, but I haven't had a good reason to buy one...yet!

"Disclosure: I have no relationship with Seleae other than being a very satisfied owner of one of their products."

John Johnson sent this: "Peter Hiscocks, a former prof of mine (digital design circa 1972) has left teaching and has entered private business.

"You can check out his company and products at: http://www.syscompdesign.com/

Philip Freidin sent a very comprehensive chart of products, which is here: https://www.ganssle.com/misc/usb_instruments.pdf .

Topsy Turvey

Computers are amazing things. My desktop executes billions of instructions per second, even when sitting more or less idle. It reliably - perfectly, actually - moves data to and from a billion bytes of DRAM in nanoseconds while sucking huge files from TB of hard disk space. Days and at times even weeks go by without a single glitch, yet every second of each of those days the machine slams vast amounts of data around. A single bit error will crash the machine. Yet the occasional problems arise (mostly) from imperfect software; the hardware operates flawlessly.

The engineers who design computers work with imperfect components. No one really knows the characteristics of the ICs, capacitors and every other element they use. That 1k resistor might actually be 1024 ohms, and though it's rated at 1/4 watt odds are it'll handle a bit more than that, if used in a reasonably-ventilated space in a non-extreme environment. The power supply might be putting out 50 mV less than spec'd, and that figure is likely to change as components age over the years, and as the mains vary due to summer air-conditioning demands. The track on the PC board doesn't really act like a wire at all; it's a complex transmission line which reflects, attenuates and distorts the digital signal it carries.

But the PC operates reliably because engineers realize their components are less than perfect. They design margin into every aspect of the system. In an ideal world perhaps just a single electron is enough to distinguish a zero from a one, but in the grimy reality of engineering EEs push thousands or millions of electrons down each wire. Capacitors are hard to make precisely, some come with wild tolerances like -20/+80%. We're not really sure how many microfarads the vendor will provide, so design in plenty of margin to ensure success.

Margin is the essence of reliable engineering. Civil engineers don't know exactly how strong a bridge beam will be, especially when it's a concrete structure poured on-site by bored and careless laborers. The bridge stands because the beam is two or three times stronger than absolutely needed. When building the Brooklyn Bridge Roebling (see The Great Bridge by David McCollough for a wonderful book) discovered the wire used to suspend the entire bridge was of inferior quality. Yet his design had so much margin that the bridge still stands a century later, still held up by some of that bad wire.

In the firmware world we work with perfect components. A one is a one is a one. But there's no margin in the world of firmware engineering. One unitialized variable, a single miscomputed bit, just one mismatched push/pop pair, causes the application to crash. If the user types in unexpected data or operates knobs out of sequence our code might kill someone.

Our programs are like bridges without margin, likely to collapse under the most feeble stress.

In truth, there are some techniques that add a bit of margin to our code. Build the system around an MMU and individual tasks might fail, but a very smart OS can save the system. Pepper the code with asserts() to find error conditions and then take corrective action. Add redundant execution streams to identify and repair software errors. Include stack monitors, malloc() traps, and plenty of other instrumentation to build fault-tolerant code. Plenty of firmware people reset output bits every loop iteration in case ESD or some other factor causes a bit flip.

Yet these strategies reveal that firmware is topsy turvy compared to any other form of engineering. Software margins come at the expense of vastly increased design costs, with, in these days of cheap transistors, little in the way of increased production expenses. The Shuttle's code is probably the best software ever written. Price tag: $1000 per line.

Bridge-building, though, is all about materials cost. A mere stroke of the designer's pen increases the size of a beam, but perhaps doubles production costs. The wise EE who's worried about pushing .2 watts through a � watt resistor simply uses the next size up. There's zero design effort but substantial recurring costs.

Perhaps software engineering is somewhat akin to automotive design. The car industry must minimize recurring costs - which includes the costs due to recalls and repairing defects. They spend billions engineering a new product. Or maybe it's like building a spacecraft; of the $800 million spent on the Mars Expedition Rovers, only a pittance is in materials cost. Engineering sucked up the largest chunk, because failure is intolerable.

Both automotive and spaceflight share the same philosophy: perfection is worth plenty of engineering dollars. Sadly, that's a far cry from the approach of most firmware engineering projects, where nothing is more important than minimizing NRE and the schedule.

What do you think? Can we put more margin into our firmware? Is it worth the extra time and effort?

Jobs!

Let me know if you're hiring firmware or embedded designers. No recruiters please, and I reserve the right to edit ads to fit the format and intents of this newsletter. Please keep it to 100 words.

Lab126 designs high-profile, portable, hand-held consumer electronics products, like the Kindle. We are looking for software engineers who will be responsible for the development and maintenance of key system features.

- Bachelor's Degree in Computer Science, Computer Engineering or related field, or 4+ year relevant work experience
- 5+ year's professional experience in software development building production software systems. Computer Science fundamentals in object-oriented design, data structures, algorithm design, problem solving, and complexity analysis
- Proficiency in, at least, one modern programming language such as C, C++, C#, Java, PHP or Python
- Experience working with networking or communications devices in an embedded environment.
- Experience porting firmware to new hardware platforms and integrating new hardware capabilities.
- Excellence in technical communication with peers and non-technical cohorts.
- Development experience on multiple Linux platforms and mobile devices (Android, iOS).
- Experience in applying open-source technologies (Linux, SQLite, MySQL, OpenGL, Spring, Hibernate).
- Knowledge of professional software engineering practices & best practices for the full software development life cycle, including coding standards, code reviews, source control management, build processes, testing, and operations.
- Ability to take a project from scoping requirements through actual launch of the project.

Lab126, part of the Amazon.com, Inc. group of companies and is an equal opportunity employer. Contact Michelle McCain (mmccain@lab126.com).

Crestron is currently seeking experienced developers with 3 to 10 years active development with embedded systems to be added as team members whose sole task is to write code for products in Rockleigh, NJ. Crestron is also looking for Working" Project Leads with 5 or more years experience to manage the day to day activities of small product development teams with 3 to 10 developers on each. These candidates should have some real project management experience. These candidates will also write code at least 50% of the time.

- Must have proven experience with Real time operating system (RTOS) development
- Must have experience writing code for products that ship - (not test code)
- Must have C or C# coding experience
- Must have experience working with debugging tools and emulators
- Must have experience writing code to interface directly to hardware devices
- Must have experience working with i2C and/or SPI hardware interface busses
- Knowledge of Windows CE 5.0 or 6.0 a plus
- 5+ years experience with Ethernet Stack or VLAN
- BS or BE in Engineering or Computer Science
- Must be able to work in the U.S. without sponsorship

Send resumes to tcook@crestron.com

Software Engineer, Digital Monitoring Products in Springfield, MO.

DMP is seeking the right individual who is detail oriented, creative & can write error free code. As a developer of the industry's most advanced Intrusion Alarm Panels, you will have the opportunity to design cutting edge technology within our industry. The right candidate will be responsible for designing, writing, maintaining, testing, and debugging software that is modular, maintainable, and easy to understand.

Skills:
- Experience with C/C++ required. Assembly language a plus.
- TCP/IP, Ethernet, GPRS and other data networks a plus.
- Microprocessor, digital, and software design and troubleshooting experience.
- Experience with microprocessor emulators, logic analyzers, and oscilloscopes a plus.

BS in CS, Engineering or related, or equivalent experience.

Minimum 2 years design experience.

Contact Andrea Burnett, Human Resources at aburnett@dmp.com

Joke for the Week

Note: These jokes are archived at www.ganssle.com/jokes.htm.

Steve Casey sent this:

In any embedded project involving more than one engineer, there is always disagreement about where the *real* bug lies. In one project, for a military application, this is how an argument was settled...

A system had been designed to measure the time of flight for bullets. Upon triggering, a gun would be automatically fired, and a sensor built into the target logged the time of impact. But, no impact was ever registered by the logger. A heated discussion ensued, with each party blaming the other. Then one guy said, 'I know how to solve this once and for all. Go back to your target, and fire it again.' He then went to the gun, and put his finger over the end of the barrel. The target guy pressed the button, immediately blowing the other guy's finger off, who then shouted, 'See? I told you. My end's fine. There's no problem with the output. The problem is definitely at your end...'

About The Embedded Muse

The Embedded Muse is a newsletter sent via email by Jack Ganssle. Send complaints, comments, and contributions to me at jack@ganssle.com.

The Embedded Muse is supported by The Ganssle Group, whose mission is to help embedded folks get better products to market faster. can take now to improve firmware quality and decrease development time.