Tweet Follow @jack_ganssle
Go here to sign up for The Embedded Muse.
Logo The Embedded Muse
Issue Number 236, February 18, 2013
Copyright 2013 The Ganssle Group

Editor: Jack Ganssle,
Jack Ganssle, Editor of The Embedded Muse

You may redistribute this newsletter for noncommercial purposes. For commercial use contact To subscribe or unsubscribe go to or drop Jack an email.

Editor's Notes

Barr Group

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


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 Strangely, they felt it was inappropriate for their home page. The article is here.


Miro Samek is running a free embedded C programming course for the ARM Cortex M series.

Quotes and Thoughts

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

Tools and Tips

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:


A quick note regarding the ongoing "personal knowledgebase" discussion: A little while back I found a great article over at Lifehacker about using Evernote in that capacity - keeping track of / filing "everything", and in a searchable fashion, and of course, accessible everywhere. What's All the Fuss about Evernote? Should I Be Using it?

For another possibility, Trello seems to have some similar uses, and has also been used for project management and event planning and many other things - see this page for some ideas. I think the basic idea behind Trello is a "list of lists", but that simple idea is very powerful. Make lists, long documents, categorize, add notes, images and other attachments, etc. etc. It also has an added benefit of being designed specifically for collaboration between multiple people - again, in the cloud, and iPhone, Android, PC, Mac, etc. etc.

Personally, I presently just have a mess of gazillions of web bookmarks plus a few semi-sorted folders (both real and virtual, as well as email) of useful resources. But I may work on a better system.

Bill Gatliff noted:


Regarding your tools and tips, I've been a gmail user via the web interface for a long time. I send emails to myself after taking meeting notes, and use "draft" messages (with no recipients to guard against accidental sending) for working documents and journals. I get interrupted a lot, and those journals are often the only way I can quickly pick up where I left off a few days earlier.

Since it's a web interface, I can get to those documents from anywhere. And the search feature is pretty good. Finally, since I also carry Android phones I'm pretty agnostic to what device connects me to those documents too.

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


"On the down side, recently moving to Windows 7 means that we have USB based instruments that no longer work because there will never be a Windows 7 driver released for them. So we have an XP based laptop we are likely to
keep forever (meaning 5 years top) just to keep supporting these. This includes some digital oscilloscopes."

NOT true.

I have used some USB devices including the Saleae and USB to RS232/485 and PE Micro programmer I use for Kinetis work with my W7 pro-64 bit Workstation and on some laptops.

It may be a key point to run the driver install as Administrator and in XP Compatibility mode and run the Application in XP compatible mode too. (change in properties for the .exe).

Also for some old dos programs like ORCAD for dos The Virtual PC XP emulation mode works fine with PRO versions.

For the non pro and even to run old Dos programs: There are also dualBoot and DosBox work arounds so one does not need to keep and old machine "forever". Just about as easy as having a second machine.

Dave Scott wrote:


I accumulated a large number of text files ("memos") when I carried a Palm PDA. I later moved this to Evernote but found that when you lose your internet connection you don't have access to your data. SimpleNote solved this although it will not handle much of the non-text info that can be stored in Evernote.

Cagri Tanriover submitted this:


While reading the text editor reviews on your website, I was surprised to see that Notepad ++ was not listed ( so I decided to provide my brief overview here a humble contribution to your website. Maybe you may want to share it with your readers.

Notepad++ is a really powerful text editor and it is free. I particularly like being able to add many bookmarks to different parts of the text and to be able to quickly jump across them using the F2 key. This editor also supports split screen feature whereby you can layout two views either horizontally or vertically. Furthermore, this editor allows multiple tab control which allows the user to open many documents simultaneously. I use this feature a lot while code editing. For code developers, one handy feature is keyword colouring. Notepad++ supports multiple programming languages including C, C++ and Java and colour codes the text accordingly to improve readability.

Once you open a document on one split view, you can either move it or clone it to the other view using the context menu. One last thing I must mention about this powerful editor is it comes with "Go to line number" feature, which lacks in some popular IDE editors.


Quantum Leaps

What I'm Reading

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.

Yet More on the Analog Discovery

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: .

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:

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.


Joke For The Week

Note: These jokes are archived at

Deliver yesterday, code today, think tomorrow.

Advertise With Us

Advertise in The Embedded Muse! Over 23,000 embedded developers get this twice-monthly publication. For more information email us at

About The Embedded Muse

The Embedded Muse is Jack Ganssle's newsletter. Send complaints, comments, and contributions to me at

The Embedded Muse is supported by The Ganssle Group, whose mission is to help embedded folks get better products to market faster. We offer seminars at your site offering hard-hitting ideas - and action - you can take now to improve firmware quality and decrease development time. Contact us at for more information.