Go here to sign up for The Embedded Muse.
Embedded Muse 226 Copyright 2012 TGG May 21, 2012
You may redistribute this newsletter for noncommercial purposes. For commercial use contact email@example.com. To subscribe or unsubscribe go to http://www.ganssle.com/tem-subunsub.html or drop Jack an email at firstname.lastname@example.org.
EDITOR: Jack Ganssle, email@example.com
- Editor's Notes
- Quotes and Thoughts
- EE Demographics
- Tools and Tips
- Joke for the Week
- About The Embedded Muse
UBM's 2012 Embedded Market Study was recently released. It shows that the number one concern of engineers and managers is hitting schedules. Building a higher quality development process and building a profitable development process are also concerns that are not far behind that of schedules.
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 http://www.ganssle.com/onsite.htm .
In one of the stranger uses of embedded systems, a clothing store displays their products on smart hangers, which display the number of "likes" each item has scored on Facebook: http://venturebeat.com/2012/05/06/brazil-facebook-lies/
The Embedded Muse is going on vacation for the summer. This is the last issue until September.
Quotes and Thoughts
Always code as if the guy who ends of up maintaining your code will be a violent psychopath who knows where you live. Damian Conway
The Amp Hour (http://www.theamphour.com/) recently published a link to a US government site that has lots of interesting demographics - including salaries - about the 154,000 EEs in this country: http://www.bls.gov/oes/current/oes172071.htm#st .
In the last issue I posed the question: What is your favorite piece of test equipment and why?
Lots of folks responded, with some useful and often very entertaining replies. Alas, we can only have three winners; each of those will receive a Hydro 5 Smart Razor kindly provided by Microchip. Thanks to everyone for participating!
So, the winners are.
Amanda Wynne, who wrote: My favourite piece of test equipment would be my nose. After years of iterative training, it can distinguish the subtle difference between burnt silicon, burnt resistor, leaky & overheating electrolytic, vaporised copper track and slowly decaying FR4 pcb.
Not to mention the distinctive aroma of mouse & cockroach excretia. Furthermore, it doesn't require batteries, or even a spare mains outlet. Being persistently self-calibrating, I never need to do without it whilst it's away being professionally calibrated or NATA tested.
And Aaron Wolfe, for his detailed response with code and homage to the contest's sponsor: I have been using Microchip for all my designs since I got out of college 13 years ago. What has kept me using microchip is the excellent support I have personally always received, Microchip never has obsoleted anything I have used in a design, and certainly being comfortable with knowing the ins and outs of Microchip uCs helps. In a few designs I have had to use other micros, I won't go into details since that is not the point of this e-mail, but both experiences had obsolete issues within a relatively short time, and the support was not at the same level that I have received from Microchip.
My favorite tool for troubleshooting is the uC itself. OK, you do need some tools to go with it, but how you use the uC can make debugging a lot more efficient. An In Circuit Debugger is OK to use, but many times I cannot find the problem by stepping through the program because the system needs to run in real time. A emulator is out of the budget range for my kind of projects. My solution has been to send out register data on a single pin via asynchronous serial. I almost always have one pin available, or can make one available. This routine takes a little bit of time (101 instruction cycles including call and loading WREG), but it is a very rare circumstance that I cannot spare the little amount of time it takes to send the data. There are many logic analyzers on the market now for a very reasonable price, which can read this data and translate it for you. I use Saleae Logic. It can collect several minutes of data even at the fastest sample rate. Using this method, data can be evaluated to see what was happening real time inside the uC. This data can also easily be exported to a spreadsheet to be graphed or further examined using very handy spreadsheet tools like conditional formatting, IF formulas, data manipulation, and Macros. I personally use Excel VBA a lot in this way. There is a lot of online support and documentation and it has been quick to pick up and learn, especially since you can get started by simply recording a macro.
One other twist that a colleague of mine has used... He had a problem that occurred very sporadically and maybe once every several hours. He used this serial routine (slowed it down to usable baud rate), and hooked it up to a RS232 transmitter and sent the data into the computer. He then used a free program called "Realterm" and logged the data overnight from the serial transmissions. When he came in the next morning he had captured the problem in the data and was able to solve the issue.
I have attached below the code for the serial data routine. This of course could be adapted to any micro, but it was written for Microchip parts.
;Send Debug Data Serially on pin Debug_out------------------------ ; Define a port pin to be Debug_out ; Baud Rate is (Fosc/4)/9 ; Pass this routine the address of the file register to be sent in WREG ; Registers Temp, Send_data, and Loop_cnt must be defined _Send_Debug_Data CODE Send_Debug_Data Bank0 movwf Temp movfw FSR movwf FSR_temp ; Store FSR0 so it doesn't get lost movfw Temp movwf FSR ; Load FSR0 with data to be sent bcf INTCON,GIE ; Disable Interrupts while sending data movfw INDF ; Put the data to be sent in Send data movwf Send_data bcf STATUS,C ; Clear the carry bit, so first bit out will be a 0 movlw 0x09 ; Set up to loop through all the data bits + the carry bit movwf Loop_cnt Debug_Loop btfss STATUS,C ; Is Carry bit set? bra SDD_1 ; No bsf PORTA,Debug_out; Yes, turn output on to match carry bit bra SDD_2 SDD_1 bcf PORTA,Debug_out; Turn output off to match carry bit nop ; Wait so bit timing is consistent SDD_2 ;****************************************************** ; Uncomment this code to add 26 instructions per cycle, making a total ; period of 35 instructions. (4000000/35) = 114286 bps. (Fosc = 16000000) ; This will work properly with HyperTerminal set to 115200 baud. ; nop ; movlw D'8' ; SDD_3 ; decfsz WREG,w ; Is the loop finished yet? ; bra SDD_3 ; No, decrement again ; nop ;*************************************************************** rrf Send_data,f ; Shift right through carry so data goes out LSb first. decfsz Loop_cnt,f bra Debug_Loop ; This loop has a period of 9 instructions nop nop ; Wait so timing for last bit is consistent nop nop bsf PORTA,Debug_out ; Set the port to the stop bit level bsf INTCON,GIE ; Re-enable interrupts movfw FSR_temp ; Restore previous FSR address movwf FSR return
The final contest winner is Jay Hall, for his shocking tale: My favorite piece of test equipment? Left middle and index finger. It does involve a bit of a story. In the 70's (last century!), I worked at a telecommunications company. My first (and only) patent was for a Ring scheduling apparatus for a digital subscriber carrier system. The two output transistors of the design had 300 peak to peak voltage on their collectors. Voltmeters seemed to walk away from me whilst I was in the lab and I used to have to hunt them up and beg to use them. (I was on the lower end of the totem pole.) During my high school years, I built a portable electric fence charger I used for a shock box at school. So I was quite used to and somewhat immune to high voltages. (I should mention here that ringing generators are designed to not kill.) So, being tired of hunting down the elusive spare voltmeter, I used my index and middle finger to test for voltage presence. Making sure the current flowed between them and only them. I was so immune, I actually had to lick my fingers to get a good 'feel'. One day a more senior engineer came by to see if he could borrow my voltmeter AGAIN. I told him I did need one anymore and told him that I used my own fingers to test for the 300 volts. He did not believe me so I wet my fingers and showed him. Needless to say, he thought I was lying. (I did not even jump a tiny bit. My hand tensed a bit but I assume he was not very observant.) He said "You are so full of it!", he then wet his fingers and touched the collectors. He then proceeded to scream like a small child, yank his hand from the board so fast and far he cut himself on the workbench. He then began swearing at me. I was laughing so hard I was crying. Needless to say, I spread this wonderful news around the lab. Made my year. (Also, he stopped snatching my test equipment!) So, the index and middle finger of my left hand are STILL my favorite piece of test equipment.
Here are some of the other submissions:
HP "Pete" Friedrichs: It is possible to pull two new, identical, capacitors, both from the same lot, which measure the same value on a cap meter; yet one functions properly in a circuit, while the other does not. How is this possible?
Capacitors are conceptually simple devices, but are notoriously complex in reality. One of many of the physical attributes of a capacitor that people tend to overlook is equivalent series resistance, or ESR.
One of my favorite pieces of test equipment was a homebrew ESR meter I built some time back. Basically, it functioned as an AC ohmmeter. An op-amp oscillator generated an AC signal which was coupled to the capacitor under test through a small hand-wound transformer. Current through the capacitor was detected and amplified with another op amp, and the resulting signal drove a junk meter movement. I "calibrated" the meter by applying the instrument to several low-ohm fixed resistors, and marked the meter scale with a pencil.
The instrument solved some vexing prototyping problems I had run into (because it turns out that seemingly good parts are sometimes bad). Because the applied AC was so low, it tended not to bias semiconductors into conduction, meaning much of my troubleshooting could be done in-circuit, without having to remove the caps.
A lot of people suggested the scope. For instance, Bob Landman wrote: The oscilloscope, more specifically, my digital processing Agilent MegaZoom 500MGb/s scope.
There's no substitute for an instrument which can show you how an electronic circuit is behaving (or misbehaving). I fell in love with the oscilloscope in 1957 when, thanks to my then "hobby" of repairing TVs and radios, I saved enough money to purchase a HeathKit OM-1 oscilloscope kit! Couldn't wait to assemble it. Always fascinated by the signals I could finally see on it.
One of the happiest times in my life was when I was recruited to be a Tektronix field engineer (1977). Weeks spent in Beaverton getting training on every kind of Tek scope.
Never thought I'd ever like a scope that wasn't Tek blue but years later HP jumped ahead in the scope race with the MegaZoom concept of a very deep digital memory so one could zoom in and see the fine detail of a captured waveform. Then they added the ability to capture 16 channels of digital logic recording with the two analog waveforms triggered externally by my Softaid microprocessor analyzer! Used the combination to debug a dual-ported SRAM memory tied to two Z180 CPUs in the fiber-optic transceiver I was developing.
Bought three more HP/Agilent scopes (fastest is 1.5Gb/s with a Win95 PC inside it). Still have my Tek 465 (for "real" analog work there's nothing like a pure analog scope - fastest in the world was made by Tek for Los Alamos nuclear weapons underground tests).
Also have three "antique" Tek scopes: 565 (dual beam!!), 545 and 547 - rescued them from dumpsters. They work too! Great space heaters for New England's winters.
(Legendary analog guru Jim Williams was famous for his love of old Tek scopes. His bench is now at the Computer History Museum in Mountain View, CA, and can be seen here: http://www.edn.com/article/519496-Computer_History_Museum_honors_Jim_Williams_and_Bob_Pease.php .)
Fred Marshall likes: A wet finger.
Because it's always available - I can't forget to bring it.
Because it doesn't need batteries.
Because it's proven in the field.
Because it's multipurpose.
Next contest: "The longest list of uses for a wet finger"
(In case there's any question: a wet finger is often used to determine the presence of electrical power in a light socket. believe it or not!)
Steve Fairhead: a piezo gas lighter, e.g. <http://www.amazon.co.uk/Piezo-Electric-Lighter-Ignitor-Igniter/dp/B003QR8FFG/ref=sr_1_2?s=kitchen&ie=UTF8&qid=1336514622&sr=1-2> - lots of other examples available.
Testing for EMC/EMI *can* mean investing in some fairly high-end gear, or it can mean spending $5 on a piezo lighter. Same result, usually/often. Although the $5 alternative is a broader brush, sometimes you *want* a broader brush.
A long while back (20+ years), shortly after learning this trick, I was investigating some rack-mounted cards which misbehaved under EMI. A colleague walked in while I was wielding my magic lighter. His face made it clear that he thought I was quite, quite mad.
However: this exercise showed us that the front panels of the rack-mounted modules weren't grounded, and were acting as aerials... saved us thousands in EMC testing, once I'd fixed the problem.
Rationale: think back to M. Marconi and his wideband spark-based transmitters...
Dan Swiger: I started my software engineering career over 17 years ago at Watkins-Johnson, a radio company. I am still at my first job (minus a 5 month "vacation" to Ford Motor Company). While the name on the building has changed several times over the years, one thing has remained constant: our development of some of the best (RF) performing radios in the world. Being a software weenie, I often don't care too much for RF specifications. As a result, my all-time favorite piece of test equipment is the HP-8640B Signal Generator, Circa 1974. Though only rated from 500kHz to 1.024MHz, I've used this beast to test radios up to 6GHz. How you ask? Well, simply crank up the output amplitude to +20dBm and look at the harmonics! You can see easily out to the 6th harmonic of 1000MHz (* 6 = 6GHz). With it, I can tell that my software is properly tuning anywhere and everywhere in the radio's valid tuning range.
My second favorite part about this wonderful piece of equipment is the analog-amplitude fine adjustment. With most "current" signal generators, you get a nice push-button to click up and down in 1dB or even as low as 0.1dB steps. Even if you're adjusting your amplitude in 0.1dB steps, you get to that point and you hear "CLUNK!" inside the generator. Guess what? Yep, it just switched out 9.9dB of a small (most-likely digital step) attenuator and switched in a huge 10dB pad. Guess what just happened to the Automatic Gain Control (AGC) circuit/algorithm you were trying to test? Yep, it just went nuts! Well, that's when the 8640B comes to the rescue! It is good for about 10-15dB of smooth signal level transition without the CLUNK-factor, making it perfect for testing my AGC algorithm's hysteresis and proper tracking of slow-fading signals. I love it for that!
It has other great features too, like very slowly modulating both the AM and wide-band FM, allowing you to introduce a "now I'm here, now I'm gone, now I'm somewhere else" signal into your radio, really testing out your signal detection capabilities. Think of it as a poor-man's frequency hopper!
Finally, and probably the most-obvious reason I love it is because nobody else wants it! In the Engineering Land of Midnight-Requisitions, who in the world is going to steal an 8640B? I never have to worry about my bench being raided by other engineers, jealous of my impressive rack of test equipment.
That's right, the HP 8640B, a piece of equipment introduced when I was 2 years old, is still very useful 38 years later (please don't do the math), and is, by far, my favorite piece of test equipment.
Kevin Ryan: Not sure if they'd like being described as equipment, but I'd go for "my wife and kids". She's great on testing if something is intuitive to use. They test robustness. (They use to be great for waterproof type tests, but they've grown out of it.)
Steve Sala: My favorite piece of test equipment weight about three pounds---far less than my laptop. It contains an estimated 100 billion "transistors," though this number varies from unit to unit. Though many attempt to replace it with high-powered DSP-enabled spectrum analyzers, logic analyzers, DSOs, emulators, and other highly useful tools, there is no substitute for it. It doesn't need batteries, it is highly portable, and I never misplace it. Although there are no user-serviceable parts inside and repairs are difficult at best, with proper care and feeding, it will last a lifetime. Though some complain I don't use it nearly enough, I must say.
The human brain is clearly my most valued tool for solving challenging engineering problems.
Dale Wright: My favourite (non-typical) piece of test equipment is the ever-versatile paper clip. I always carry half a dozen in my wallet for emergencies:
- need to clip a scope or multimeter probe to a pin in a female D sub connector? open out the paper clip and you have a pin, just the right size to insert and to clip onto, no matter what your clip size.
- do you need a quick 900/2400MHz antenna for that radio modem? open out said paper clip and there you go - fits nicely into a BNC or TNC female connector.
- missing a jumper? you guessed it paper clip can be bent to short 2 or more pines with ease.
- small lock missing a key - the paper clip has also been known to assist in this area too.
- and finally, the paper clip can also conveniently hold loose sheets of paper together!
Claude Galinsky: My favorite piece of test equipment is my training in experimental psychology. As a result of all those hours spent learning to design testable hypotheses and experiments which will distinguish between possible causes for am effect, I am able to "divide and conquer" problems in hardware and software. Since the most expensive part of product development is the salaries paid to engineers during the debug phase, knowing what to test and how to test it is the single most cost-effective way to complete a project.
Finally, Martin Meier wrote: Oh man, when the E-bomb comes, I won't even be able to shave anymore...
Tools and Tips
ARM, in their attempt to assimilate the entire world of embedded systems, has a software stack called the Cortex Microcontroller Software Interface Standard (CMSIS) that simplifies and standardizes access to common on-board peripherals. Amr Bekhit has created a tool called the CMSIS Configuration Wizard, which is a free and open-source tool for easily configuring ARM CMSIS files (or other files that use the same structured comment format) without the need to use Keil's uVision IDE. More information can be found at http://helmpcb.com/software/cmsis-configuration-wizard.
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.
David Good added to last issue's language jokes:
I'm sorry, but shooting yourself in the foot is not available in this
edition of Visual Studio. You need to upgrade to Ultimate for that
Ruby on Rails...
A robust open source community to help you shoot yourself in the foot.
In fact better check github first. There is a good chance someone
already shot themselves in the foot and you can reuse their gem.
About The Embedded Muse
The Embedded Muse is a newsletter sent via email by Jack Ganssle. Send complaints, comments, and contributions to me at firstname.lastname@example.org.
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 email@example.com for more information.