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.

• Editor's Notes
• Quotes and Thoughts
• Tools and Tips
• What I'm Reading
• Yet More on the Analog Discovery
• Specialization
• Jobs!
• Joke for the Week
• Advertise with us
• About The Embedded Muse

The average embedded software project devotes 50% of the schedule to debugging the code. It's stunning to realize that half of the project's time is wasted fixing mistakes.

Perhaps the other half should be called "bugging."

Unfortunately that debugging just doesn't work. Most organizations ship with about ten bugs per KLOC, two orders of magnitude worse than best-in-class outfits. A focus on fixing bugs will not lead to a quality product.

How do you get projects done faster? Improve quality! Reduce bugs. This is the central observation of the quality movement. The result is a win-win-win: faster schedules, lower costs and higher quality. Firmware engineering, too, can - and must - profit from the same win-win-win.

Learn how (and far more) at my Better Firmware Faster class, presented at your facility. See https://www.ganssle.com/onsite.htm.

The trade magazines run tear-downs all the time... but mostly these address the same sort of products over and over. Mobile phones. Tablets. Yawn. I recently did a tear-down of a personal astable multivibrator on embedded.com. Strangely, they felt it was inappropriate for their home page. The article is here.

"I love deadlines. I like the swooshing sounds they make as they fly by." Douglas Adams

Please submit neat ideas or thoughts about tools, techniques and resources you love or hate.

The tips for storing random data continue to pour in!

Chris Jones wrote:

Bill Gatliff noted:

Jack Everett has had more luck with Windows 7 than others:

Dave Scott wrote:

Cagri Tanriover submitted this:

The current "crisis" in Moore's Law is that below 20 nm there may not be much cost savings, if any.

Fighting physics - the speed of light is a real bottleneck in networking, and what we can do about it.

Overcoming the embedded CPU performance wall - dealing with multicore issues.

Doug Mercer of Analog Devices had some corrections and clarifications to my review of Digilent's Analog Discovery USB scope in Muse 233.

You said:

"Analog bandwidth is rated at 5 MHz. I found that the displayed amplitude was within 5% of the correct value all the way to 9 MHz. At 10 MHz it's off by 10% and rapidly gets worse. But that's a lot better than the spec."

Yes - the scope inputs are +/- 0.1dB out to 5MHz on the units we have looked at. Analog Devices is a little more of a purist when it comes to measurement instruments; if you put in one Vp-p, we want you to measure 1 Vp-p - not 0.707 (which is the -3dB point). The typical -3dB point will be higher - but for most first touch experimenters (the target for the product - engineering students taking Circuits 1 and 2, and Electronics 1 and 2) 5 MHz is plenty.

You Said:

"The device is a mixed signal scope in a novel way. I couldn't figure out how to put digital inputs on the scope screen (as a normal MSO does), but an alternative is to open both the logic analyzer application and the scope, and then put the windows next to each other. Like any MSO, the unit will cross trigger."

To get both analog and digital signals on a common time axis all you need to do is click on the Data icon on the tool bar:

You Said:

"The analog waveform generator is limited to 20 KHz."

You may have been misled by a quirk in the AWG UI where the min and max of the sliders can be set to values less than the actual Max or greater than the actual Min. The actual maximum AWG frequency using the standard waveforms is 10 MHz, 10 samples per cycle. This is done to keep well below the amplitude roll off due to the sine X / X nature of the DAC. Note this user's application: http://www.jensign.com/Discovery/bode .

If you load a user defined waveform data set with more than one cycle then even higher frequencies can be generated but the bandwidth of the amplifiers will of course be factor.

You said:

"There are a few things I didn't like. The probes, as mentioned, are very weak."

Your point is well taken. I'm not very fond of the supplied "fly-wire" connector. The wires are too thick and stiff. The main intended use of the Discovery platform is to teach Electrical Engineering students in their first 2 or 3 years of undergraduate education. In these classes they build their experiment circuits on solderless breadboards. We have many years experience working with top EE departments to base this on. Using simple jumper wires makes more mechanical sense than using long coax cables and scope probes with BNC connectors to make connections to the breadboards. While there are not many pre-made commercially available alternatives to the supplied connectors, I've found that it is not hard to assemble variations from separate components that work very well with breadboards. As an even better way, note my breadboard adapter PCB:

http://ez.analog.com/community/university-program/blog/2012/10/12/analog-discovery-breadboard-adapter

Digilent is of course offering the BNC adapter (based on my suggestion) now which allows easy connections to more traditional cables found in labs.

You said:

"Helpful tips pop up when mousing around. Too much so. They get in the way of reading the measurements."

These can of course be turned off once you know your way around the software under the Help drop down tab or using the F1 key.

You said:

"The documentation is via a help file, and is incomplete."

Unfortunately, Help files always seem to be the last thing on the to-do list. More fun to add new features then to write the help file.

What's your system's clock rate?

About a third of the firmware developers I poll can't answer this question. Yet the clock rate is a basic aspect of a system. Firmware people use that figure to program timers, serial channels and PWMs. Sometimes we're required to select a clock frequency as part of the setup procedure for our debugging tools. And it's tough to do performance estimations without some idea of the system's speed.

But the shifting landscape of embedded systems development has changed everything. The olden days of 4k programs is largely history (though some MCU vendors do tell me a significant number of their developers still write tiny applications). Multi-million line products are common. Those products often have a huge engineering team, with many individual experts on narrow aspects of the technology, yet with no one with a complete systems-level view of the entire product. Perhaps it's impossible to expect such vast knowledge. Yet the dearth of such breadth of experience means hideous troubleshooting sessions spanning dozens or hundreds of individuals.

Developers are changing, too. In my firmware seminars I'll often ask how many attendees are EEs. A few years ago more than 50% answered "aye." That number is decreasing, especially in the USA. The IEEE is nearly frantic at how few students enroll in EE today.

We're specializing. That's often a symptom of a healthy, maturing market segment. Networking experts don't dirty their hands with device drivers so just don't need to know the system's clock rate. Application level developers never delve beneath a high-level API, and might not even know what CPU is used. Some signal processing experts are more mathematicians than programmers and work at a very high level of abstraction indeed.

In Controlling Software Projects, Tom DeMarco urged software developers to embrace specialization. Some people are terrible coders but great testers. Some fumble in debugging while others zap bugs lightening-fast. Isn't it silly that each engineer analyzes requirements, designs, codes, inspects, debugs, tests and documents. and then provides tech support? How many of us are really experts at so many diverse specialties?

You'd never go to a GP when confronted with a diagnosis of cancer or heart disease. Specialties abound: cardiologist, podiatrists, gynecologists, sports injury practitioners, dermatologists, ophthalmology, plastic surgeons and many, many more. The field of medicine is so vast that only by specializing can a doctor know enough about one single area to provide good care.

The embedded world is nearly as vast: networking (TCP/IP, I2C, CAN, Bluetooth, Zigbee, Wi-fi and a hundred others), network management, data acquisition, signal processing, C, C++, Java, any of a hundred different assembly languages, motor control, electromagnetics, PCB design, Verilog, ASIC design, and more. Each demands a high level of expertise that can take years to acquire. Any one could consume an entire career.

Yet in the embedded world resumes are expected to be acronym soup; we're specialists who are expert at everything. Realistic? Probably not.

IBM's Chief Programmer Teams of the 60s and 70s tried unsuccessfully to divide a team into a group of developers each practicing one specialty. Developers rebelled and the practice soon lost cachet. We like doing it all. I rather miss the early embedded days. It was a kick to design the hardware, tape out PCBs on great sheets of mylar (that was before CAD and autorouters), troubleshoot the boards while simultaneously writing assembly-language device drivers, and then implementing the rest of the firmware. Unlike the cardiologist who wearily sees the same handful of problems day in and day out, building an entire system means exercising a wide array of skills. There's never a chance to get bored.

But engineering is a business affair. Managers only care about the most efficient way to create embedded systems. Do we rely on broadly-educated developers doing all phases of the project, or should we specialize?

Specialization can be a career yin or yang. The world's expert on embedded Android development will ride the gravy train, at least until the Next Great Thing appears. My dad relates a story from the 60s when he worked at Grumman with an engineer who knew everything about wheels for lunar roving vehicles. What happened to him when Apollo imploded around 1970?

In my opinion, such specialization will save the company money, but sure sucks the fun out of projects. What do you think?

Let me know if you’re hiring embedded engineers. 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.

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

Deliver yesterday, code today, think tomorrow.

Advertise in The Embedded Muse! Over 23,000 embedded developers get this twice-monthly publication. .

The Embedded Muse is Jack Ganssle's newsletter. 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.