|
|
||||
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. |
||||
| 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. 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.
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:
|
||||
| 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. |
||||
| Advertise With Us | ||||
Advertise in The Embedded Muse! Over 23,000 embedded developers get this twice-monthly publication. . |
||||
| 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. |
