Tweet Follow @jack_ganssle
Go here to sign up for The Embedded Muse.
TEM Logo The Embedded Muse
Issue Number 260, May 5, 2014
Copyright 2014 The Ganssle Group

Editor: Jack Ganssle, jack@ganssle.com
   Jack Ganssle, Editor of The Embedded Muse

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

Contents
Editor's Notes

Court testimony about the recent Toyota ruling makes for interesting - and depressing - reading. A lot of code was involved and some of it was safety critical. Yet it seems the firmware was poorly engineered. No doubt the typical mad rush to get to market meant shortcuts that, at the time, were probably seen to save money. A billion dollars later (with many cases still pending) that judgment looks more foolish than sage.

After over 40 years in this field I've learned that "shortcuts make for long delays" (an aphorism attributed to J.R.R Tolkien). The data is stark: doing software right means fewer bugs and earlier deliveries. Adopt best practices and your code will be better and cheaper. This is the entire thesis of the quality movement, which revolutionized manufacturing but has somehow largely missed software engineering. Studies have even shown that safety-critical code need be no more expensive than the usual stuff if the right processes are followed.

This is what my one-day Better Firmware Faster seminar is all about: giving your team the tools they need to operate at a measurably world-class level, producing code with far fewer bugs in less time. It's fast-paced, fun, and uniquely covers the issues faced by embedded developers. Information here shows how your team can benefit by having this seminar presented at your facility.

Quotes and Thoughts

John Black sent this one: Every program has at least one bug and can be shortened by at least one instruction – from which, by induction, one can deduce that every program can be reduced to one instruction which doesn't work. - Anonymous

Tools and Tips

Please submit clever ideas or thoughts about tools, techniques and resources you love or hate. Here are the tool reviews submitted in the past.

Agilent has a free 89 page application note called "Spectrum Analyzer Basics" that I recommend. Spectrum analyzers (SA) look like oscilloscopes, but the the horizontal axis is frequency rather than time. You have to register to get the app note but if an SA is in your future - or if you're curious about this aspect of electronics - this is a great resource. If you're not familiar with heterodyning you'll be lost. Wikipedia has a good article about heterodyning, which is something all EEs should understand as it has been a staple of radios for just under 100 years.

Most digital oscilloscopes can compute the FFT of the input waveform, transforming it from the time to the frequency domain, in effect simulating a spectrum analyzer. However, scopes don't have the exquisitely-sensitive RF front end of an SA. A scope digitizes voltage and displays the result; an SA sweeps a local oscillator over a wide range of frequencies and mixes it with the input. In effect it's a radio with a swept local oscillator, so is internally much different from a scope.

FFT of the FM radio band

This is a typical FFT on an oscilloscope simulating a spectrum analyzer. The top trace is the signal in normal volts vs time format. The bottom trace is its Fourier Transform and is shown as dBV vs frequency. The input is just a meter of wire acting as an antenna; the displayed FFT is for the commercial FM radio band. The peak at 91.5 MHz is WBJC, Baltimore's classical station; at -47.5 dBV that's about 4 millivolts. A rock 'n roll station at 100.7 MHz is quite a bit stronger. But do notice how the FFT extracts useful information from the scope signal that looks like meaningless noise.

More on Reenabling Interrupts

In the last issue Phil Koopman graciously let me run his blog piece about not re-enabling interrupts inside an ISR until the routine has completed. It created a lot of dialog.

Most of the correspondents addressed two points. The first is that modern CPUs do support multiple priority levels, so much of Phil's argument didn't pertain. That was my initial thought, too, except that at the very end, prefixed with "UPDATE," he specifically dealt with those architectures.

The second point is that if an ISR is longer than a handful of lines of code, there's a design problem. Keep 'em short! I completely agree. But, in general, it's hard to generalize about embedded systems, and I have seen a few cases where long, even very long, ISRs were the only choice. Those cases are rare.

Perhaps the shortest ISR ever written consisted of one line of code, except that there was no code. Decades ago we built instruments that used the 8008 and later the 8080 processors. When a device requested an interrupt the CPU responded with an interrupt acknowledge cycle, which was a normal fetch with an INTA strobe line asserted. External hardware would usually drop a single-byte call instruction on the bus that invoked one of seven ISRs. The overhead required for a call far exceeded the few microsecond response time we needed, and happily the system had nothing to do while awaiting the interrupt. So the code would execute a HALT instruction and stop till the interrupt occurred. In response to the interrupt-acknowledge cycle the hardware placed a NOP on the bus; the code restarted and carried on, reading the A/D and doing all of the other stuff that had to happen when the event occurred.

Rigol Scope Mini-Review

Robert Burke likes his Rigol scope:

I read that you plan on reviewing the SDS 1000CML oscilloscope. I bought a Rigol DS1102E last fall ($399). It looks about the same as the SDS 1000, probably made at the same factory.

I use mine a lot and think it is a good scope for $400. The bandwidth limit of 100 MHz does limit looking at high speed clocks, but for most of my embedded designs, it is fast enough. I could use 4 channels sometimes, but I get 90% of the work done with 2 channels. The measurement features are good, I especially like the "Display All" button, it shows all 24 measurement features at once (takes up 1/3 of the screen).

As for quality, the Rigol has worked well for me the last six months, and I do take it home when I plan to work at home. Nice to avoid the commute. The size and weight makes it easy to carry.

I looked at 2 channel USB oscilloscopes, which cost around $150 - $250. I read many reviews of the USB scopes; several users complained about the quality & units failing. A few bad reviewers suggested the Rigol. For $100 - $200 more, I get a stand alone oscilloscope that does not need a laptop to run it.

Conclusion: I am happy with the Rigol and I recommend it.

Free Ride Into Space

What could be better than winning a free trip into space! The folks at Hackaday are sponsoring a contest for the coolest bit of electronics; you have to build the gizmo and show it works. A number of prizes are offered. The grand prize winner will receive a trip to space on their carrier of choice, or US$196,418 cash. Other prizes include team skydiving, an all-expense paid trip to the Akihabara electronics district in Japan, and essential hardware hacking tools such as milling and tooling machines and 3D printers. The contest closes August 4.

Jobs!

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 www.ganssle.com/jokes.htm.

More of what you DON'T want to hear your System Administrator say:

40. We're standardizing on AIX.
39. Yes, I chowned all the files to belong to pvcs. Is that a problem to you?
38. I didn't think anybody would be doing any work at 2am, so I killed your job.
37. Do you really need your home directory to do any work?
36. What do you mean /home was on that disk? I umounted it!
35. What do you mean you needed that directory?
34. Well, MY files were backed up.
33. Hmmm, curious...
32. Why is my "rm -r *" taking so long?"
31. Hmm, maybe if I do this...
30. Oops! (said in a quiet, almost surprised voice)
29. My leave starts tomorrow.
28. You might as well all go home early today...
27. I remember the last time I saw it do that.
26. I don't think it should be doing that!
25. I have never seen it do THAT before!
24. What's that grinding sound?
23. Do you smell something?
22. What's this "any" key I'm supposed to press?
21. I cleaned up the root partition and now there's LOTS of free space.
20. The drive ate the tape but that's OK, I brought my screwdriver.
19. Where's the DIR command?
18. .. and I just bought that Coke.
17. Where's the GUI on this thing?
16. It didn't do that a minute ago...
15. What do you mean that wasn't a copy?
14. Sorry, the new equipment didn't get budgeted.
13. Management says...
12. I got a better job at Lockheed.
11. Wow...that seemed fast.
10. Well, it's doing SOMETHING.
9. What software license?
8. Terminated?!?
7. Hey!! The Suns don't do this.
6. Wow!! Look at this!
5. That's SOOOOO bizarre.
4. Go get your backup tape. (You DO have a backup tape?)
3. What the heck?!?
2. Oh nooooooo!
1. Uh-oh...

Advertise With Us

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

About The Embedded Muse

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. 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 info@ganssle.com for more information.