Go here to sign up for The Embedded Muse.

Embedded Muse 212 Copyright 2011 TGG September 6, 2011

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

Are you happy with your bug rates? If not, what are you doing about it? Are you asked to do more with less? Deliver faster, with more features? What action are you taking to achieve those goals?

In fact 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 .

What crazy times we live in. Companies are reluctant to hire, and even if that were not the case, there just aren't a lot of available embedded people. The implications are scary: each engineer will have to do more work. If we can't increase our productivity, we'll be doomed to more overtime, which is a sure way to lower productivity. Worse, time to market pressures are higher than ever, yet product complexity increases constantly. Companies are going to have to adopt different strategies to stay competitive.

Unfortunately few teams keep detailed metrics, so usually have no quantitative productivity metrics. A few do. On average, these groups report a 40% increase in productivity when they adopt the suggestions from my Better Firmware Faster course.

I'll be conducting public versions of this class in Chicago on October 21 and in London on October 28. Why not rev up your team? There's more info here: https://www.ganssle.com/classes.htm . Act now - there's a discount until September 21 for Chicago and the 28th for London.

Many of you kindly filled out survey data for VDC. The summary of the results is here: http://www.vdcresearch.com/_documents/11_esdt_survey_hl.pdf . A couple of tidbits got my attention:

- 51.9% report using C++ but only 11.9% use object oriented techniques.
- 52% report the current engineering job market is better than last year; only 12% thought it was worse.

Quotes and Thoughts

Be conservative in what you do, be liberal in what you accept from others. From RFC 793

Tools and Tips

Keep those tools and tips coming.

I've been playing with some new scopes and will post reviews. This week we'll look at a new offering from Tektronix; next issue I'll cover an iPhone scope.

The Tektronix MDO4104-6

In the olden days we had scopes. Then digital scopes redefined the landscape, instantly obsolescing entire classes of storage tubes and scope cameras. In the 90s the mixed-signal scope unified both the oscilloscope and the logic analyzer, crucially adding cross-triggering so one could see how analog and digital events interacted in time.

Tektronix has just taken the next logical step, though the idea had never occurred to me. Their new MDO4000 series of scopes marries an MSO to a spectrum analyzer (SA). (MDO is a new TLA for "Mixed Domain Oscilloscope.") Keeping true to the spirit of the MSO, the MDO can trigger off analog, digital or RF inputs.

The company tells me that at least 60% of engineers who use a scope also use an SA. Really? That number seems huge. SAs have historically belonged to the domain of the RF engineer. But Tek says since 2006 the rise of wireless has changed all of this. 60% is still a bit much for me to swallow, so for those of you who have never used a spectrum analyzer, the SA is much like a scope, except it displays amplitude vs frequency, instead of amplitude vs time. The units have lots of associated features, of course, but their essence is working in the frequency domain.

They kindly sent me a loaner MDO4104-6, which has four 1 GHz analog channels, 16 digital, a 5 GS/s sample rate and 6 GHz RF input. (Analog channels 3 and 4 are 2.5 GS/s).

For some applications combining a SA and scope makes a ton of sense. Working on a frequency-hopping radio you could see the digital signals that initiate a hop, the associated analog, and the resulting RF to discover when the signal stabilizes, or if it overshoots, etc. Or you could watch the behavior of a PLL as it establishes a lock, which I did. Watching the PLL in the frequency domain was really enlightening.

Each of the scope's three sections (analog, RF and digital) can be individually enabled. If only RF is on the entire screen becomes a full-featured spectrum analyzer. And what a screen it is, 10.4" of TFT crispness and color. Or just enable the analog to use this as a conventional oscilloscope. If the RF is on as well as analog and/or digital channels, the latter are on the top half of the display, and the spectrum on the bottom.

A lot of scopes today have a built-in FFT math function, which rotates the time domain into the frequency domain. But those have significant limitations, starting with bandwidth. Cross-talk and other issues can (and do) corrupt the display. I find that these FFT functions are only crudely useful. In contrast, Tek's MDO has an RF stage that looks like one from a real SA, with plenty of shielding and lots of gain.

For instance, I connected the RF input to an antenna (a short clip lead) and tuned to the FM band. Here in Finksburg, MD we're pretty far out in the country. A single top 40s station overpowers most of the others, and, sure enough, it popped up with -67 dBm of energy (on the order of 100 microvolts into a 50 ohm load). I enjoy listening to Car Talk Saturday mornings while working with loud woodworking machines in my shop, but my Peltor Worktunes headphones can barely pull the PBS affiliate out of the interference. Turns out that station tunes in with just -104 dBm of power.

This is an impressive tool with all of the quality one expects from Tektronix. With a couple of exceptions I think it's ideal for people blending RF into their embedded systems.

First, the boot time is appalling. A minute and twenty seconds. That's even longer than my old 545 tube scope used to take.

Second, at times it's slow. An example is: if the RF side is enabled the analog channels' vertical positioning lags control inputs by a second or so. With RF on and the unit configured to acquire 20m points, horizontal panning is sometimes jumpy and erratic - and sometimes not.

A hugely important feature is that you can pan through acquired RF spectra. It takes a bit of head scratching to understand, though. Suppose you acquire a single-shot of some analog data while also sucking in signals into the RF section. You can, of course, pan through the analog, and, as on any MSO, see pre-trigger and post-trigger events. The buffer holds up to 20 million points, so you can pan pretty far away from the trigger event. But, as the MDO acquired those 20m points, it also grabbed spectrum data from the RF input. So panning through the analog waveform also pans through spectrums on the bottom display. If you're watching a PLL stabilize you might see the VCO voltage on the top, analog display, and, as you pan across that, watch how the PLL's frequency moves around on the bottom display till it finally locks in.

The spectrogram display (which is not unique to this product) is to die for. If enabled, it's shown immediately above the frequency plot, and is that plot rotated towards the operator. Intensity is shown by color. So each acquisition on the frequency display is rotated into a single line, one pixel high. Successive acquisitions build up so the spectrogram's vertical axis is the history of all of the RF traces. If you're monitoring a slowly-changing input - perhaps the center frequency is changing - the spectrogram shows that change over time. Watching the FM band some extremely weak stations were so buried in the noise that I couldn't pick them out on the frequency display, but the spectrogram clearly showed dim lines at their center frequencies.

Concentric pan and zoom knobs let you waltz through the captured signals with great ease. It's a great interface. Two multipurpose knobs' functions vary depending on which screen is displayed, but the visual prompts are very clear. The one exception is the tiny font used on-screen to indicate whether multifunction knob "a" or "b" is in play; my middle-aged eyes found it very difficult to distinguish the difference.

The unit is packed with features which are detailed on their web site. Those include plenty of math operations, all kinds of automated measurements, bus decoding (depending on options purchased), and markers which automatically identify RF peaks. The RF bandwidth is selectable. I very much like the small keypad that you can use to enter parameters, such as center frequency.

Though I didn't see this mentioned in any of the literature, Tek engineers tell me the MDO captures phase and quadrature data, which can be downloaded to a PC. An application they provide can then demodulate the captured signals.

This is a truly complex piece of test equipment that's quite intuitive to operate. There are so many modes and so much capability that I was disappointed in the manual, which despite being 200 pages long, leaves a lot of questions unanswered.

One of those questions is "what's with the odd proby things?" The TPP1000 probes supplied have the BNC connectors encased in plastic boxes. Instead of pushing a BNC in and twisting to secure it, one just pushes the box thingamajig onto the panel-mounted BNC. No twisting allowed or needed. To release you press a button on the box. It works fine but what is the advantage over the age-old naked BNC connector?

I mentioned that the MDO is, at times, slow to respond. I also experienced some odd behavior where the unit was unresponsive to a control. Twist a knob and nothing happens; wait a few seconds and full functionality is restored. I suspect Tek will fix this in production versions.

Units run a base price of $20k to $28k. Options can drive that cost up a lot. It's a lot of money. But given that Tek's RSA3303B entry-level spectrum analyzer starts at $35k, and the MSO4104B (the same scope without the RF side) runs $20k, the MDO's price seems reasonable. There's more info here: http://www.tek.com/mdo4000 .

Contest!

Microchip has generously donated chipKIT Max32 Arduino-Compatible Prototyping Platforms (see http://www.digilentinc.com/Products/Catalog.cfm?NavPath=2,892&Cat=18) for a contest. I promised to send units to the three readers who send in the best jokes. Well, the esteemed panel of judges couldn't whittle the list to less than four. Here are those:

From Phil Baurer:
C isn't that hard: void (*(*f[])())() defines f as an array of unspecified size, of pointers to functions that return pointers to functions that return void.

Fred Strathmann sent this:
Once upon a time, in a kingdom not far from here, a king summoned two of his advisors for a test. He showed them both a shiny metal box with two slots in the top, a control knob and a lever. "What do you think it is?"

"It is a toaster" he said.

The king asked, "How would you design an embedded computer for it?"

The engineer replied, "Using a four-bit microcontroller, I would write a simple program that reads the darkness knob and quantizes its position to one of 16 shades of darkness, from snow white to coal black. The program would use that darkness level as the index to a 16-element table of initial timer values. Then it would turn on the heating elements and start the timer with the initial value selected from the table. At the end of the time delay, it would turn off the heat and pop up the toast. Come back next week, and I'll show you a working prototype."

The second advisor, a computer scientist, immediately recognized the danger of such short-sighted thinking. He said, "Toasters don't just turn bread into toast, they are also used to warm frozen waffles. What you see before you is really a breakfast food cooker. As the subjects of your kingdom become more sophisticated, they will demand more capabilities. They will need a breakfast food cooker that can also cook sausage, fry bacon and make scrambled eggs. A toaster that only makes toast will soon be obsolete. If we don't look to the future, we will have to completely redesign the toaster in just a few years."

"With this in mind, we can formulate a more intelligent solution to the problem. First, create a class of breakfast foods. Specialize this class into subclasses: grains, pork and poultry. The specialization process should be repeated with grains divided into toast, muffins, pancakes and waffles; pork divided into sausage, links and bacon; and poultry divided into scrambled eggs, hard-boiled eggs, poached eggs, fried eggs and various omelet classes."

"The ham and cheese omelet class is worth special attention because it must inherit characteristics from the pork, dairy and poultry classes. Thus, we see that the problem cannot be properly solved without multiple inheritance. At run time, the program must create the proper object and send a message to the object that says, 'Cook yourself'. The semantics of this message depend, of course, on the kind of object, so they have a different meaning to a piece of toast than to scrambled eggs."

"Reviewing the process so far, we see that the analysis phase has revealed that the primary requirement is to cook any kind of breakfast food. In the design phase, we have discovered some derived requirements. Specifically, we need an object-oriented language with multiple inheritance. Of course, users don't want the eggs to get cold while the bacon if frying, so concurrent processing is required, too."

"We must not forget the user interface. The lever that lowers the food lacks versatility, and the darkness knob is confusing. Users won't buy the product unless it has a user-friendly, graphical interface. When the breakfast cooker is plugged in, users should see a cowboy boot on the screen. Users click on it, and the message 'Booting Ubuntu 11.02' appears on the screen. (Ubuntu 11.03 should be out by the time the product gets to the market.) Users can pull down a menu and click on the foods they want to cook."

"Having made the wise decision of specifying the software first in the design phase, all that remains is to pick an adequate hardware platform the implementation phase. An ARM 9 processor with 16Gb of memory and a 500Gb hard disk should be sufficient. If you select a multitasking, object oriented language that supports multiple inheritance and has a built in GUI, writing the program will be a snap. (Imagine the difficulty we would have had if we had foolishly allowed a hardware-first design strategy to lock us into a four-bit microcontroller!)"

The king wisely had the computer scientist beheaded, and they all lived happily ever after.

Vlad Pambucol had me ROFL:
Job Ad: "Security INC, computer security firm is looking for highly motivated hackers. Please post your resume on the first page of the microsoft.com website."

And Jon Titus sent:
A programmer and a hardware engineer were riding in a bus in a third-world country when guerrillas sprang out of the nearby jungle and took the two hostages. They walked for days until all arrived at the rebels' base camp. After several weeks and no response to ransom requests, the guerrillas decided they had to kill the hostages but would give each one last request. They went to the programmer and asked for his last request. He said, "I'd like to give you all a lecture about my latest Java project." Then they went to the hardware engineer and asked for his last request. He said, "Shoot me first."

Thanks to all who did submit jokes. I'll run them in successive issues of the Muse.

NRE Response

Geoff Patch had a response to the last issue:

"I read your article about using COTS processor boards in embedded systems with interest. In general I concur with your comments, but as you might expect, there are "corner cases" where the general rule does not apply.

"Products in the consumer electronics markets (including the Agilent scopes that you discussed) typically have fairly short lifetimes. On the other hand, some application domains have product lifetimes that are almost absurdly long. We are still supporting products in the field that were originally designed and manufactured in 1991, and we are still successfully selling products that were originally designed in the late 1990's.

"I'm pretty sure that had we used COTS boards in those products then we would no longer be able to support or build them as required. As it is, with very few exceptions, all of the components are still readily available and we can produce our custom boards as required. Component obsolescence is an issue, but not nearly as much of a problem as PCB obsolescence.

"I guess the ultimate issue is about having control over your products. A few years ago we started using a variety of COTS processor boards in a system with an expected 20 year lifespan. We experienced problems with these boards that we had no control over, so we decided that we should go back to designing our own processor boards once again.

"Obviously our application domain is fairly unusual, so perhaps we should just be considered as the exception that proves the rule."

The Dumbest Thing I Did

When interviewing I always ask candidates (those with experience) about their dumbest mistake and what they learned from it. Those with no mistakes are generally those with no experience - or are perhaps truthiness-challenged. Do you have any?

David Bley admitted: "I have done a number of dumb things in my life. One that comes to mind is a design that I participated in. We were designing a product and our schedule was very aggressive and we needed an extensive feature set. I made the suggestion to use a PC motherboard (SX386 16MHz at the time). The product was loved by the users. The problem came when the CMOS battery went bad, and the message came up to press a key on the keyboard - there was no keyboard. The product had to be opened up to plug in a keyboard. The battery also had a tendency to leak and dissolve traces on the motherboard."

Tom Harris submitted this: "But the above reminded me of what seemed to me to be the natural reaction at the time, on my first job (designing a cable modem from wire-wrap up), to the two VAX computers we had in our government lab. They sat in a computer room in the back of our electronics lab, behind a large glass window (of course).

"The door was not locked, but it was restricted access. From a senior person I learned how to log in, and also that you could then log in remotely from one computer to the other. To log off of the second computer, you had to have defined an escape key for that session.

"No sooner after I was left alone, I tried out my new skill. I should mention that the terminal was outside the computer room. I logged into computer A, then from there to computer B. When it asked me to define an escape code, I picked a letter at random, and remembered it. I did a few directory commands on computer B, and then thought, Why not log from there back into computer A? Repeating my steps, I was now in a new world on computer A. I think I got one more step along this path when people came back into the lab.

"I tried to log out by retracing my steps. Needless to say, too many escape codes. I thought I was off the hook when the senior guys walked right past me. They went into the computer room, leaving the door open just enough that I could match some sound to their excited motions through the glass window. Who crashed _both_ VAX machines, they wanted to know.

"But all being engineers, I got to keep my job."

Stefano Zammattio had a story for this section: "A long time ago my department received some shiny new IBM PCs that I had the job of setting up. I showed a colleague how great they were and decide to teach him how to use DOS.

"Later on that evening he rang me up.

"'The computer is behaving really weird and I need it to finish my work for tomorrows deadline..."

"To which I responded: 'Umm try switching it off and back on again....'

"A short period later: 'Oh now it seems completely messed up...it's not doing anything..'

"'What were you doing before it messed up?'

"'Oh I was bored, so I was trying out some of the things you showed me, I was using edlin to look at some files. Some weird stuff in there.'

"'What was the last file you looked at?'

"'Uh, something like command.com....'"

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.

There were no jobs submitted this week.

Joke for the Week

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

David Kramer found a great ad on Craigslist. Though not a joke it's pretty good, and reads, in part:

In order to make sure the applicant has a working knowledge of the above skills, the following questions should be answered correctly. Each successful answer will result in a piece of an email address. Once a complete email address is constructed, the applicant can then use it to send their resume and a link to their A) Facebook page or B) LinkedIn page.

Educational and professional experience qualifications are flexible. If you can solve the 5 puzzles below, and actually enjoy it, you're probably a good fit.

For below, assume unsigned32 X, Y, Z; char foo[];

1. Consider the MPC5674F processor. The 32 bit address of the Flash B Shadow Block starts at X. Use whatever resources you have to find X.

2. Y = ((X >> 16) & 0xFF) - 5; // use X from question 1
What is Y in hex?

3. Consider the S-record: S30B00EFBFFFFE635924182031
Using the above information,
Z = (unsigned32) ( (*(byte *) X ); // use X from question 1
What is Z in hex?

4. sprintf( &foo, "Q%04x%2x\0", Y, Z); // use Z, Y from questions above

5. char foo2[11] = { 0x40,0x79,0x61,0x68,0x6F,0x6F,0x2E,0x63,0x6F,0x6D,x00
};
strcat( foo, foo2 );
puts( foo );

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.