- Volume 3:
- Volume 2, Number 12:
- Volume 2, Number 11:
- Volume 2, Number 10:
- Volume 2, Number 9:
- Volume 2, Number 8:
- Volume 2, Number 7:
- Volume 2, Number 6:
- Volume 2, Number 5:
- Volume 2, Number 4:
Navigate to:
| EE371 Home Page | EE Home Page | EE Program |
The Embedded Muse ----------------------------------------------------------- Volume 2, Number 12 Copyright 1997 TGG December 11, 1997 ----------------------------------------------------------- You may redistribute this newsletter for noncommercial purposes. For commercial use contact info(aatt_sign)ganssle.com. EDITOR: Jack Ganssle, jack(aatt_sign)ganssle.com CONTENTS: - Editor's Notes - Embedded Seminar in Washington DC - Thought for the Week - About The Embedded Muse Editor's Notes -------------- I've received a number of requests to do my "The Best Ideas for Developing Better Firmware Faster" seminar in the DC area, so have scheduled a class there on January 29. More info follows in this newsletter. Reuse - Bah, Humbug? -------------------- I often tell people that "Reuse is Poison". The comment immediately gets everyone's hackles up, and sometimes I have to dodge tossed tomatoes. I do think, though, that we're largely operating under a misconception about the issue of reusing software. Though reuse is probably about the only hope of ultimately solving the software crisis, the fact is that *we don't do it!* RTOS vendors still tell me that 80% of all real time operating systems are homemade. Huh? How can this possibly square with our apparent collective will to reuse software? The shelves at every bookstore groan under the weight of dieting books; people buy them like mad. Yet America gets a bit heavier every year. It seems we're better at talking about losing weight than actually doing it. Is software reuse the metaphorical equivalent of dieting? We talk the talk but don't walk the walk? Reuse is poison when we pretend it's important while not actually doing it. It's time to stop deluding ourselves and start practicing what we preach. Easy? No. Critical? For sure. And, in the spirit of offering something worthwhile to supplement my critiques, here's a great source of code. Seriously great. Check out http://www.snippets.org for hundreds of routines, some of which are quite useful for many embedded applications. Embedded Seminar! Washington DC - Thursday, January 29 ------------------------------------------------------ I'm conducting a full-day embedded seminar in DC on January 29. It's called "The Best Ideas for Developing Better Firmware Faster", and is for the developer who is honestly looking for new ideas, but who wants to cut through the academic fluff of formal methodologies and immediately find better ways to work. The focus is uniquely on embedded systems. I'll talk about ways to link the hardware and software, to identify and stamp out bugs, to manage risk, and to meet impossible deadlines. For more information check out http://www.ganssle.com or email info(aatt_sign)ganssle.com. Thought for the Week -------------------- New Programming Languages: 'SIMPLE' is an acronym for Sheer Idiot's Programming Linguistic Environment. This language, developed at Hanover College for Technological Misfits, was designed to make it impossible to write code with errors in it. The statements are, therefore, confined to 'begin', 'end', and 'stop'. No matter how you arrange the statements, you can't make a syntax error. Programs written in SIMPLE do nothing useful. They thus achieve the results of programs written in other languages without the tedious, frustrating process of testing and debugging. SLOBOL is best known for the speed (or lack thereof) of its compiler. Although many compilers allow you to take a coffee break while they compile, SLOBOL compilers allow you to travel to Bolivia to pick coffee. Forty-three programmers are known to have died of boredom sitting at their terminals while waiting for a SLOBOL program to compile. VALGOL - From its modest beginnings in Southern California's San Fernando Valley, VALGOL is enjoying a dramatic surge of popularity across the industry. VALGOL commands include 'really', 'like', 'well', and 'y*know'. Variables are assigned with the '=like' and '=totally' operators. Other operators include the California Booleans, 'fersure', and 'noway'. Repetitions of code are handled in 'for/ sure' loops. Here is a sample VALGOL program: like y*know (i mean) start if pizza=like bitchen and b=like tubular and c=like grodytothemax then for i=like 1 to oh maybe 100 do wah - (ditty) barf(i)=totally gross(out) sure like bag this problem really like totally (y*know) VALGOL is characterized by its unfriendly error messages. For example, when the user makes a syntax error, the interpreter displays the message: gag me with a spoon LITHP - This otherwise unremarkable language is distinguished by the absence of an 's' in the character set. Programmers must substitute 'th'. Lithp is said to be useful in prothething lithtth. LAIDBACK - Historically, VALGOL is a derivative of LAIDBACK, which was developed at the (now defunct) Marin County Center for T'ai Chi, Mellowness, and Computer Programming, as an alternative to the intense atmosphere in nearby Silicon Valley. The center was ideal for programmers who liked to soak in hot tubs while they worked. Unfortunately, few programmers could survive there for long, since the center outlawed pizza and RC Cola in favor of bean curd and Perrier. Many mourn the demise of LAIDBACK because of its reputation as a gentle and non-threatening language. For example, LAIDBACK responded to syntax errors with the message: Sorry, man, I can't deal with that C- This language was named for the grade received by its creator when he submitted it as a project in a university graduate programming class. C- is best described as a 'low-level' programming language. In general, the language requires more C- statements than machine-code instructions to execute a given task. In this respect it is very similar to COBOL. FIFTH - FIFTH is a precision mathematical language in which the data types refer to quantity. The data types range from CC, OUNCE, SHOT, and JIGGER to FIFTH (hence the name of the language), LITER, MAGNUM and BLOTTO. Commands refer to ingredients such as CHABLIS, CHARDONNAY, CABERNET, GIN, VERMOUTH, VODKA, SCOTCH, and WHATEVERSAROUND. The many versions of the FIFTH language reflect the sophistication and financial status of its users. Commands in the ELITE dialect include VSOP and LAFITE, while commands in the GUTTER dialect include HOOTCH and RIPPLE. The latter is a favorite of frustrated FORTH programmers who end up using this language. About The Embedded Muse ----------------------- The Embedded Muse is an occasional newsletter sent via email by Jack Ganssle. Send complaints, comments, and contributions to him at jack(aatt_sign)ganssle.com. To subscribe, send a message to majordomo(aatt_sign)ganssle.com, with the words "subscribe embedded email-address" in the body. To unsubscribe, change the message to "unsubscribe embedded email-address". The Embedded Muse is supported by The Ganssle Group, whose mission is to help embedded folks get better products to market faster.
The Embedded Muse
-----------------------------------------------------------
Volume 2, Number 11 Copyright 1997 TGG December 1, 1997
-----------------------------------------------------------
You may redistribute this newsletter for noncommercial purposes. For
commercial use contact info(aatt_sign)ganssle.com.
EDITOR: Jack Ganssle, jack(aatt_sign)ganssle.com
CONTENTS:
- Editor's Notes
- History of Electronics Article
- More Dumb Mistakes
- Embedded Seminar in Washington DC
- Thought for the Week
- About The Embedded Muse
Editor's Notes
--------------
One more "dumb mistakes" idea, lying latent in the in-box for a while,
comes from a fellow in New Zealand. I'm not sure if my friends in NZ are
just more honest than the rest of us - or something else -- but it sure
seems like a lot of submissions have come from this beautiful country. ;)
I've received a number of requests to do my "The Best Ideas for Developing
Better Firmware Faster" seminar in the DC area, so have scheduled a class
there on January 29. More info follows in this newsletter.
Finally, in reaction to The Embedded Muse 10's comments about Windows CE, I
received a **lot** of email from those who love and those who hate the idea
of embedded CE. Of those that dislike the idea, about half are
Microsoft-haters; the rest worry about the resources required to support
such a complex OS. For a number of reasons I think Microsoft-bashing is
counterproductive and probably a poor way to make technical decisions.
However, I was very surprised at the number of people who are designing
embedded systems today with few resource limitations. In fact, my recent
EDN column, a spoof on a 32 bit toaster, elicited a few responses that made
me think that perhaps a few such toasters are even now in development!
The quintessential embedded CPU is the 8051, yet there seems a rather
significant shift towards much bigger systems. What do you think? I'm
collecting info about what people are doing with embedded systems, the
sorts of things they are building, and the sorts of processors used. I'd
love to hear from y'all about the types of systems you are working on, and
will maybe use your input as fodder for a future article.
History of Electronics Article
------------------------------
If you're at all interested in the history of our weird wonderful business,
check out the October 30, 1997 25th anniversary edition of EE Times.
There's a long series about the industry from the invention of the
transistor to now. It's largely focused on the people who made the silicon
revolution, but there's a lot of insight into where the good ideas came
from. Recommended.
More Dumb Mistakes
------------------
From Kris Heidenstrom in New Zealand:
I was testing a prototype of a controller board I had designed. This board
had field I/O with LED indicators, microcontroller (6303) and a modem. The
LEDs were driven from the digital field inputs via buffers, which could be
turned off by software to save power.
While testing the current consumption, I noticed that as I moved my
multimeter probe around, the current consumption varied by about 50%! In
fact, it wasn't the multimeter - just moving my hands around the board
caused the current consumption to vary.
I thought I was looking at some weird capacitive effect, until I noticed
that the current drain did not vary when the LEDs were enabled, then the
penny dropped. When I turned off the angle-poise lamp above the board, the
current consumption dropped to a normal and stable value, and moving my
hands around had no effect.
I had used 74HC245s for the LED driver buffers, with the direction pin
permanently tied, and the enable input driven by the micro (to give the
display enable function). I chose the 245 because it was already an
inventory item, and the 244's staggered pinout didn't fit well with the
layout. We had used HCT devices due to a temporary availability problem
with the HC part.
The bright light was causing a photoelectric effect in the LEDs, and the
voltage was biasing the reverse-direction buffers in the HCT245s into the
linear region, causing the excess current consumption!
The moral of the story - pick one:
Be careful when using components (HC245) for anything other than the
purpose for which they were specifically designed,
Don't assume that something that is not enabled can be ignored,
Circuits can sometimes 'think' more laterally than designers :-)
Editor's note: This is a new one on me. A similar problem comes from not
tying off all of the inputs on a CMOS device, so stray pickup creates
either linear-biased logic, or (worse) SCR latch-up. The best part of
Kris's email was his sig, which reads: "Good sense is the most valuable
good on the market."
Embedded Seminar! Washington DC - Thursday, January 29
------------------------------------------------------
I'm conducting a full-day embedded seminar in DC on January 29. It's called
"The Best Ideas for Developing Better Firmware Faster", and is for the
developer who is honestly looking for new ideas, but who wants to cut
through the academic fluff of formal methodologies and immediately find
better ways to work.
The focus is uniquely on embedded systems. I'll talk about ways to link the
hardware and software, to identify and stamp out bugs, to manage risk, and
to meet impossible deadlines.
For more information check out http://www.ganssle.com or email
info(aatt_sign)ganssle.com.
Thought for the Week
--------------------
STOP THE GENOCIDE!
Every second billions of innocent assembler instructions are
executed all over the world. Inhumanly they are put on a
pipeline and executed with no regard to their feelings. The
illegal instructions are spared, although they should be
executed instead of the legal ones.
Prior to the execution the instructions are transported to a
cache unit using a bus. There they spent their last moments
waiting for the execution. Just before the execution the
instruction is separated into several pieces. The execution
isn't always fast and painless. On crude hardware the
execution of a complex instruction can take as long as 150
clock cycles. Scientists are working on shorter execution
times.
Microsoft endorses the needless execution of instructions
with their products like DOS(TM), Windows(TM), Word(TM) and
Excel(TM). It is more humane to use software which minimizes
the executions.
Modern machines use several units to execute multiple
instructions simultaneously. This way it is possible to
execute several hundred million instructions per second. The
time is near when there will be no more instructions to
execute.
ACT NOW! Before it's too late
About The Embedded Muse
-----------------------
The Embedded Muse is an occasional newsletter sent via email by Jack
Ganssle. Send complaints, comments, and contributions to him at
jack(aatt_sign)ganssle.com.
To subscribe, send a message to majordomo(aatt_sign)ganssle.com, with the words
"subscribe embedded email-address" in the body. To unsubscribe, change the
message to "unsubscribe embedded email-address".
The Embedded Muse is supported by The Ganssle Group, whose mission is to
help embedded folks get better products to market faster.
The Embedded Muse ----------------------------------------------------------- Volume 2, Number 10 Copyright 1997 TGG October 31, 1997 ----------------------------------------------------------- You may redistribute this newsletter for noncommercial purposes. For commercial use contact info(aatt_sign)ganssle.com. EDITOR: Jack Ganssle, jack(aatt_sign)ganssle.com CONTENTS: - Editor's Note - Windows CE Article - More Dumb Mistakes - Embedded Seminar in Irvine - Thought for the Week - About The Embedded Muse Editor's Note ------------- There are just a few seats left for my seminar on developing embedded firmware faster and better. It's in Irvine, California on November 13. If you're interested, see the note later in this newsletter and act soon. In the USA today is Halloween, a night of ghosts and goblins. It's a good time for a twist on the "Dumb Mistakes" series. Sometimes embedded systems can indeed seem haunted... Windows CE Article ------------------ Larry Mittag's article about Windows CE in the November issue of Embedded Systems Programming is quite fascinating. If you're wondering what CE is all about, read this piece. It does a good job of putting the issues in perspective. To quote one line: "They (Microsoft) have essentially redefined the minimum form factor for a standard computing environment to host application software for applications like inventory control and general remote connectivity." In other words, here comes the rush to 32 bits! He goes on to discuss how CE could eliminate our specialty. Embedded people are a rare and talented breed; CE, though, will redefine embedded programming to a new model much like working on PC software. So, if you believe that CE will become important, learn hardware NOW; it's the one last refuge that will differentiate us from our PC-programming cousins. As one who loves little systems, those cool 8 and 16 bit controllers that surround us, computing oh-so-quietly in the background, I sometimes wonder if Windows CE is my worst nightmare come true. It could be the new standard that ultimately forces many 8 bit systems into the 32 bit world. Will the fun of building embedded systems disappear when we're essentially doing Windows programming? Will all of the tricks we invent to morph a tiny microcontroller into a seemingly impossible application disappear, as obsolete as vacuum tubes and celestial navigation? More Dumb Mistakes ------------------ From Gary MacDonald: Many moons ago I was working on project which was being used to control a set of communication points, with the control/status being done from my Windows program. The project had to be done in 9 months from scratch and the team didn't think it was long enough, as part of the tension relief the project catch phrase became 'Help us Obi Wan Kenobi, you're our only hope'. As a joke one day I put in a message box that popped up with the phrase into my program, we laughed about it ,I took out the code that caused it to pop up and forgot about it. The day before Delivery we were all still bug fixing, and whilst browsing thru my code I came across a string that was no longer used in the windows string table, so I removed it. Then we shipped the system. A couple of days later we were installing the system and I got a call to come to the control room, One of the guys suggested I look at the system status which should be showing all the units off line as we hadn't installed them yet. What it showed for an offline unit was 'help us obi wan kenobi you're our only hope'. The string I had deleted had caused the strings to be renumbered and my joke had accidentally moved into the used string space! After several minutes panic - all the compiler tools and source code etc. were 300 miles away - Fortunately I had a copy of xtree I used to navigate the system and I managed to use its hex view to hack into the binary and change the string to be what it should be. Lessons learnt - don't make last minute changes to your code, you don't always realise what its going to affect and always take the compiler tools with you when you wherever you go. Editor's note: I guess this is a common problem. While still very young and much wiser (in my own mind) than now I pointed a series of impossible error messages to a string that made disparaging remarks about one of the company's engineers. Imagine my surprise - and embarrassment - when a hardware failure caused that screen to pop up on a unit right outside that engineer's office! In another system, based on the 8008 of all things, the program ran a complex iterative linear regression. I set the code up so that after about 20 minutes if it did not converge on an answer it displayed "Help" in the unit's 7 segment LEDs. This feature was well documented and worked just fine, until one day, many years later, when the unit had long been forgotten, it came in for repairs. The technician walked into my office, white as a sheet, and told me he'd been working on it for a half-hour or so, twiddling adjustments and the like, when it started flashing HELP at him. He was not long out of Appalachia, and was convinced the machine was haunted! Embedded Seminar! Irvine, CA - Thursday, November 13 ---------------------------------------------------- I'm conducting a full-day embedded seminar in Irvine on November 13. It's called "The Best Ideas for Developing Better Firmware Faster", and is for the developer who is honestly looking for new ideas, but who wants to cut through the academic fluff of formal methodologies and immediately find better ways to work. The focus is uniquely on embedded systems. I'll talk about ways to link the hardware and software, to identify and stamp out bugs, to manage risk, and to meet impossible deadlines. For more information check out http://www.ganssle.com or email info(aatt_sign)ganssle.com. Thought for the Week -------------------- The heaviest element known to science was recently discovered by physicists. The element, tentatively named Administratium, has no protons or electrons and thus has an atomic number of 0. However, it does have 1 neutron, 125 assistant neutrons, 75 vice neutrons and 111 assistant vice-neutrons, for an atomic number of 312. The 312 particles are held together by a force that involves the continuous exchange of meson-like particles called morons. Since it has no electrons, Administratium is inert. However, it can be detected chemically, as it impedes every action with which it comes in contact. According to the discoverers, one reaction that normally requires less than one second was extended to four days by the presence of a minute amount of Administratium. Administratium has a half-life of approximately three years, at which time it does not actually decay but instead undergoes a reorganization in which assistant neutrons, vice-neutrons and assistant vice-neutrons exchange places. Some studies suggest that its atomic mass actually increases in each reorganization. Research at other laboratories indicates that Administratium occurs naturally in the atmosphere. It tends to concentrate at certain points, such as government agencies, large corporations, and universities, and can usually be found in the newest, best appointed, and best maintained buildings. Scientists point out that Administratium is known to be toxic at any level of concentration and can easily destroy any productive reaction where it is allowed to accumulate. Attempts are being made to determine how Administratium can be controlled to prevent irreversible damage, but results to date are not promising. Editor's Note: in circulating this to some friends, I got the following reply: I guess you chose not to include the information on "technocratium"...the element that has no protons and all free electrons - it is uncontrollable (even in the presence of administradium) and has the ability to keep on designing things even after all requirements have been met. Ouch! About The Embedded Muse ----------------------- The Embedded Muse is an occasional newsletter sent via email by Jack Ganssle. Send complaints, comments, and contributions to him at jack(aatt_sign)ganssle.com. To subscribe, send a message to majordomo(aatt_sign)ganssle.com, with the words "subscribe embedded email-address" in the body. To unsubscribe, change the message to "unsubscribe embedded email-address". The Embedded Muse is supported by The Ganssle Group, whose mission is to help embedded folks get better products to market faster.
The Embedded Muse ---------------------------------------------------------- Volume 2, Number 9 Copyright 1997 TGG October 17, 1997 ---------------------------------------------------------- You may redistribute this newsletter for noncommercial purposes. For commercial use contact info(aatt_sign)ganssle.com. EDITOR: Jack Ganssle, jack(aatt_sign)ganssle.com CONTENTS: - Editor's Notes - More Dumb Mistakes - Embedded Seminar in Irvine - Thought for the Week - About The Embedded Muse Editor's Notes -------------- A reminder - if you're interested in my seminar on developing embedded firmware, it's starting to fill so check out the note later in this newsletter. Due to popular request, all of the back issues of The Embedded Muse are now archived at www.ganssle.com. On an amusing note, Dr. Carl Dreher of Focus Research emailed to say that the ultimate bit of scariness for him about being an embedded designer was to wake up in the hospital, hear a beeping noise, look up... and see he was wired to an instrument he had designed. Now THAT'S incentive to get a product designed correctly! More Dumb Mistakes ------------------ From Thomas Walter: Hardware team passed the board over to the software team. Everything was fine, as the board came up at 3Mhz at reset. When the software team tried running at 28Mhz, the board kept crashing. Lots of blame on the poor hardware team. After much head scratching, the problem was found: a "wall wart" power supply rated at 500ma. At 3Mhz the board consumed 400ma, but at 28Mhz required 850ma. (Editor's note: Cool! A dramatic example of the speed/power curve.) From Mike Markowitz My first engineering job was designing PICs and sound generators for General Instruments Microelectronics (now Microchip Technology). There was a woman in another group--ROMs, I think--who designing the bus for a chip. Unfortunately, whether through poor training, stupidity, or a bad cup of coffee, she misunderstood the schematic representation of a bus--eight signal lines consolidating into one--for the proper physical implementation. Actually building the chip this way would short the eight individual signal lines. Thank goodness for design-checking software. From: Ron Olson Years ago, when I was in college, I had a part-time job answering a technical assistance line for a well known electronics home-study program. The final part of the program had the home-study student build a Heathkit color television. I got a call from a student complaining that his TV was displaying the image in reverse. While I was digging out the schematic, I made a joke saying "Well you could always watch your TV in a mirror". He said that he WAS looking at it through a mirror. The instruction for adjusting the picture told you to view the screen using mirror while adjusting it from the rear. Before he let me hang up, he had me wait on the line while he went and checked that the picture was correct when viewed from the front of the set. The moral: Always look for the obvious problems before seeking help. From: Dave Brooks Many years ago now, the company I then worked for (a major computer manufacturer) decided to add a digital plotter to their peripheral line. They decided to outsource the design, and duly acquired a sample unit. A very simple device: just 2 stepper motors to move the pen, and a up/down solenoid. The CPU wrote a 6-bit word to command one step of each motor, and set the pen state. All else by software. Well, the unit as received worked fine. We (as a matter of course) picked through the controller schematics, to see if there were any design tricks we didn't like. It was run as a chain of monostables (aargh!), triggered by the CPU's write-strobe, running the motors, and finally poking a "done" signal back at the CPU. However, we saw a 500pF capacitor to ground from a logic node deep in the device, to no apparent purpose. Curious, we removed it to see what would happen. The effect was dramatic: a single CPU word written caused the steppers to run (in the commanded direction) continuously, until the limit switches kicked in at the edge of the plotting area. I was given the job of figuring out what was happening. The scope (usual lab. issue - about 20MHz) clearly showed the chain of monos being re-triggered at the end of each cycle. But there was no signal doing the retriggering. Uh-oh. None of us could figure it out. Eventually, someone did me the favour of "borrowing" my scope. Consequently I in turn "borrowed" another scope: this time a 100MHz job. Now, a 70MHz burst could be seen running around the place. As the machine's step-cycle ended, the chain of monos re-armed, and the 70MHz kicked them off again. But whence the 70MHz? Eventually it was traced to the stepper drives themselves. These were large emitter followers, driving metre-long cables to the motor assembly. Under the right (wrong?) conditions, emitter followers can exhibit a negative AC impedance. The metre-long motor cables acted as quarter-wave transmission lines, and there was 70MHz. Normally those big transistors would not have worked at 70MHz, but this was a very non-standard operating mode. Truly, things ain't always what they seem. (Editor's Note: I can't count the times I've seen trouble because of lying tools. A 20 MHz scope just cannot see certain events; it's sometimes shocking what a faster instrument will tell you. I once had a problem using FIFOs - 7202's - that had no hystersis on the clock-in signal. The 100 MHz scope showed a perfect clock signal. A borrowed 1 GHz beauty, though, displayed a tiny bit of noise right at the TTL switching level. Of course, we cured it using one of those hated 500 pf capacitors...) Embedded Seminar! Irvine, CA - Thursday, November 13 ---------------------------------------------------- I'm conducting a full-day embedded seminar in Irvine on November 13. It's called "The Best Ideas for Developing Better Firmware Faster", and is for the developer who is honestly looking for new ideas, but who wants to cut through the academic fluff of formal methodologies and immediately find better ways to work. The focus is uniquely on embedded systems. I'll talk about ways to link the hardware and software, to identify and stamp out bugs, to manage risk, and to meet impossible deadlines. For more information check out http://www.ganssle.com or email info(aatt_sign)ganssle.com. Thought for the Week -------------------- WITH APOLOGIES TO ABBOTT AND COSTELLO: A Customer calls a UNIX consultant with a question: Customer: What is the command that will tell me the revision code of a program ? UNIX consul: Yes, that's correct. Customer: No, what is it ? UNIX consul: Yes. Customer: So, which is the one ? UNIX consul: No. 'which' is used to find the program. Customer: Stop this. Who are you ? UNIX consul: Use 'who am i' not 'who r yoo'. You can also 'finger yoo' to get information about yoo'. Customer: All I want to know is what finds the revision code ? UNIX consul: Use 'what'. Customer: That's what I am trying to find out. Isn't that true ? UNIX consul: No. 'true' gives you 0. Customer: Which one ? UNIX consul: 'true' gives you 0. 'which programname' Customer: Let's get back to my problem. What program? How do I find it? UNIX consul: Type 'find / -name it -print' to find 'it'. Type 'what program' to get the revision code. Customer: I want to find the revision code. UNIX consul: You can't 'find revisioncode', you must use 'what program'. Customer: Which command will do what I need? UNIX consul: No. 'which command' will find 'command'. Customer: I think I understand. Let me write that. UNIX consul: You can 'write that' only if 'that' is a user on your system. Customer: Write what? UNIX consul: No. 'write that'. 'what program'. Customer: Cut that out! UNIX consul: Yes. those are valid files for 'cut'. Don't forget the options. Customer: Do you always do this ? UNIX consul: 'du' will give you disk usage. Customer: HELP! UNIX consul: 'help' is only used for Source Code Control System (SCCS). Customer: You make me angry. UNIX consul: No, I don't 'make me' angry but I did 'make programname' when I was upset once. Customer: I don't want to make trouble, so no more. UNIX consul: No 'more'? 'which' will help you find 'more'. Every system has 'more'. Customer: Nice help! I'm confused more now! UNIX consul: Understand that since 'help' is such a small program, it is better not to 'nice help'. and 'more now' is not allowed but 'at now' is. Unless of course 'now' is a file name. Customer: This is almost as confusing as my PC. UNIX consul: I didn't know you needed help with 'pc'. Let me get you to the Pascal Compiler team. About The Embedded Muse ----------------------- The Embedded Muse is an occasional newsletter sent via email by Jack Ganssle. Send complaints, comments, and contributions to him at jack(aatt_sign)ganssle.com. To subscribe, send a message to majordomo(aatt_sign)ganssle.com, with the words "subscribe embedded email-address" in the body. To unsubscribe, change the message to "unsubscribe embedded email-address". The Embedded Muse is supported by The Ganssle Group, whose mission is to help embedded folks get better products to market faster.
The Embedded Muse ---------------------------------------------------------- Volume 2, Number 8 Copyright 1997 TGG October 8, 1997 ---------------------------------------------------------- You may redistribute this newsletter for noncommercial purposes. For commercial use contact info(aatt_sign)ganssle.com. EDITOR: Jack Ganssle, jack(aatt_sign)ganssle.com CONTENTS: - Editor's Notes - Interesting Article and Catalog - Embedded Systems Conference Notes - Embedded Seminar in Irvine - Thought for the Week - About The Embedded Muse Editor's Notes -------------- I'm giving "The Best Ideas for Developing Better Firmware Faster" seminar in Irvine, California on November 13. I've presented this to quite a few people now - often in-house for individual companies - and the response has been fascinating. Schedules continue to be a source of concern (bitterness in many cases) for developers, as few companies seem to have mastered the arcane arts of estimation. We're so wrapped up in getting a project out TODAY that we forget that the theme of our work must be to slowly, constantly, improve. Find small ways to do things better. Two fascinating resources are the Software Engineering Institute's Capability Maturity Model (CMM) of development, and Humphrey's book "A Discipline for Software Engineering" (ISBN 0-201-54610-8). The idea is to adopt smarter ways of working, rather than heroic ways. My talk is more about immediately useful methods (mastering the CMM is like getting a karate black belt - it takes years... but it is profound nevertheless), but agree with the idea that "process" - how we do things - is generally flawed and needs a lot of rethinking. So if you're interested in the southern California class, see the note later in this newsletter. And, this talk of process led to my selection for this issue's "Thought for the Week". I hope it's not offensive to anyone, but I find it an amusing anecdote of how a small thoughtful change can have a huge impact. "Dumb Mistakes" will resume shortly; I have more queued up from readers (all greatly appreciated, for sure). Interesting Article and Catalog ------------------------------- If you have any interest in the history of electronics, by all means check out the September 15, 1997 issue of Electronic Engineering Times. The article by George Rostky that starts on page 20 covers the invention and development of the calculator. He goes all the way back to the abacus, and shows us how we got to the $3 disposable units we have today. I remember playing with the Friden 5 function units as a kid. These 50 pound monsters could do the basic four functions and square roots. Some calculations took many seconds, yet the unit was entirely electronic, even using a CRT for results. When these units became obsolete I disassembled one, amazed to find them devoid of ICs. Hundreds - maybe thousands - of transistors filled the unit. Truly a marvel of design. I highly recommend the article. On another front, I recently received a catalog from Tech America, a new name (to me) in the electronics biz. They sell all sorts of components, the things tinkerers dream of. JDR, Digikey, Jameco, and others sell components as well, but none have such a fun catalog. Each chip gets a quarter page of description, with pinout and functional info. On the embedded front, they do sell the Basic Stamp boards, a series of PIC-based products I hope to review at some point (summary of future article: very high fun factor). Unhappily there's no e-address listed. Via snail mail get them at PO Box 1981, Fort Worth, TX 76101-1981. Phone: 800-877-0072. The catalog carries a $3.95 price tag but I presume it's actually a freebie. Embedded Systems Conference Notes --------------------------------- The San Jose Embedded Systems Conference last week blew my mind. It's bigger than ever, and the glitter factor has gone off the scale. Not that many years ago there were just a handful of tabletop displays in a small San Francisco hotel. This year the show filled the San Jose convention center, with booths even stacked up in the atrium. Truly a remarkable affair. My amateur assessment of the show is: Java, embedded Internet, 32 bits, and Windows CE. Last year these subjects were on display in a limited way; in 1997 they dominated the displays and the technical sessions. 8 and 16 bits seemed to be lost in the noise. In one Windows CE presentation Microsoft made three - count 'em - three references to the CE Toaster of the future. Though there was a small sense of levity implied I couldn't help but remember that my most recent EDN column was in fact a joke about designing a toaster using 32 bit processors. Truth is stranger than fiction. Yet I'm seeing more and more embedded apps using sophisticated GUIs. Check out HP's new Infinium oscilloscopes. These are very cool, high performance scopes with a sleek display. The OS? Windows 95. Look at Scott Rosenthal's article on embedded localization issues (October 1997 Personal Engineering & Instrumentation News magazine). He implies that a GUI of some sort sure makes it easier to build instruments with multi-language support. I was also interested to learn that a major car vendor is designing 32 bit CPUs into their engine controllers. This is a traditionally very cost-sensitive application, yet they've managed to match 32 bits to the pricing needs. No GUI in this app (so far), but the trend is clear. 8 and 16 bit systems outnumber 32 bitters by orders of magnitudes. I can't help but wonder, though, if consumer lust (real or perceived) for net-awareness and pretty GUIs will slowly change this model. Embedded Seminar! Irvine, CA - Thursday, November 13 ---------------------------------------------------- I'm conducting a full-day embedded seminar in Irvine on November 13. It's called "The Best Ideas for Developing Better Firmware Faster", and is for the developer who is honestly looking for new ideas, but who wants to cut through the academic fluff of formal methodologies and immediately find better ways to work. The focus is uniquely on embedded systems. I'll talk about ways to link the hardware and software, to identify and stamp out bugs, to manage risk, and to meet impossible deadlines. The course covers the following material: Linking the software to the hardware * Reusable software - the reality * Managing module complexity * Piggy-backing a software prototype Writing drivers for embedded peripherals * Translating bit patterns into code * Creating interrupt service routines Stamp out bugs! * Learn bug management techniques * Prevent defects with quick code inspections * Study optimal use of bug-hunting tools * Finding those hardware/software glitches Overcoming deadline madness * Negotiating realistic deadlines * Improve your estimation skills * Learn how hardware factors delay firmware * Learn to validate your schedule estimates * What to do when a project runs late Manage risk to avoid last minute disasters * How to assess and manage risk areas early * Preventing system performance debacles * When to use hardware to help the software * Avoiding communications nightmares How to learn from failures... and successes * Learn to conduct an effective postmortem * Closing the feedback loop * How to create an action plan For more information check out http://www.ganssle.com or email info(aatt_sign)ganssle.com. Thought for the Week -------------------- The Wall Street Journal had an article about the Dutch takeover of JFK airport's International Arrivals building. The Dutch have some interesting ideas on how to clean it up. In Amsterdam, the tile under Schiphol's urinals would pass inspection in an operating room. But nobody notices. What everybody does notice is that each urinal has a fly in it. Look harder, and the fly turns into the black outline of a fly, etched into the porcelain. "It improves the aim," says Aad Kieboom. "If a man sees a fly, he aims at it." Mr. Kieboom, an economist, directs Schiphol's own building expansion. His staff conducted fly-in-urinal trials and found that etchings reduce spillage by 80%. "We will put flies in the urinals -- yes," Jan Jansen says in a back office at the Arrivals Building. He is the new Dutch general manager. "It gives a guy something to think about. That's the perfect example of process control." His New York public relations attendant titters. "Fine, laugh at me," Mr. Jansen says. "It works." About The Embedded Muse ----------------------- The Embedded Muse is an occasional newsletter sent via email by Jack Ganssle. Send complaints, comments, and contributions to him at jack(aatt_sign)ganssle.com. To subscribe, send a message to majordomo(aatt_sign)ganssle.com, with the words "subscribe embedded email-address" in the body. To unsubscribe, change the message to "unsubscribe embedded email-address". The Embedded Muse is supported by The Ganssle Group, whose mission is to help embedded folks get better products to market faster.
The Embedded Muse -------------------------------------------------------------- Volume 2, Number 7 Copyright 1997 TGG September 23, 1997 -------------------------------------------------------------- You may redistribute this newsletter for noncommercial purposes. For commercial use contact info(aatt_sign)ganssle.com. EDITOR: Jack Ganssle, jack(aatt_sign)ganssle.com CONTENTS: - Editor's Notes - More, more, more! Dumb Mistakes - Embedded Seminar in Irvine - Thought for the Week - About The Embedded Muse Editor's Notes -------------- I'm presenting "The 24 Best Ideas for Developing Better Firmware Faster" seminar in Irvine, CA on November 13. If you're interested, see the note later in this newsletter. The West Coast Embedded Systems Conference runs from Tuesday through Thursday next week in San Jose. It's the industry's big event; don't miss it if you're in the area. This is your chance to see the vendors' wares (almost all of the embedded vendors have booths at this show), and to go to a wide variety of presentations about all aspects of developing systems. It's a ton of fun, too. If you see me skulking around stop and say hi! Thanks to all of the readers who have submitted ideas for the "Dumb Mistakes" series. This is the last installment of these for a while as I try to clear out the backlog. Enjoy. More Dumb Mistakes ------------------ From: Steve Litt, whose troubleshooters.com site is a great resource for folks interested in the arcane arts of making things work: I wasn't winning any popularity contests that day. My client's client was cursing the programmer (me) for "not fixing the problem" that had intermittently (about 0.1% of the time) plagued them for two weeks. My client wasn't happy about sending their best programmer (who was also a part owner) with me to hunt down the problem. I finally converted the intermittent to a reproducible by assembling a specific set of input files, and we watched in the debugger as a string magically changed for no reason. After watching it a few times, the other programmer gave me a dirty look and said "you can't do that!". He pointed out that a C function was returning a pointer to a string assembled in a local character array variable inside the function. When the function returned, the character array went out of scope and the memory pointed to by the returned pointer was on the stack and was "fair game" for the next function wanting to change it. Usually nothing changed it before it was used by the calling function, but once in a while ... There are some mistakes so costly you never make them again. After I paid a locksmith $75 to open my car trunk to retrieve my keys, I never again put keys down inside a car. And I never again passed back a pointer to a non-static local variable. --- From Jon Ward of Keil Software I few years ago I received a phone call with questions about a piece of code that I had written several years earlier. One of the engineers now assigned to the project had a question about the #define pre-processor directive. Their concern was that the Microsoft C compiler didn't properly handle #defines. The values the compiler assigned to them didn't jive with what the engineer expected. Naturally, it must be a compiler problem! :) I knew the particular section of code had been thoroughly tested and worked as expected, so I asked if they had made any changes. No changes...just a little re-formatting. So, I requested they fax me a copy of the offending code. The listing appeared similar to the following. #define PARM1 00020 #define PARM2 01000 #define PARM3 01001 #define PARM4 01002 #define PARM5 01003 #define PARM6 01004 After studying the code for a while, I requested that they remove the leading zeros from in front of the DECIMAL constants. The leading zeros caused the compiler to (properly) interpret these numbers as OCTAL constants yielding an unexpected value. After the 5 seconds of stunned silence, I got a hurried thanks and never heard from them again. I guess they probably stopped re-formatting working code after that. --- From Clyde Smith-Stubbs at HI-TECH Software Jack, here's a dumb mistake for you - hardware again. I think the reason you don't get dumb software mistakes submitted is that they're so common I forget about them within minutes of fixing them - then spend just as much time tracking the same dumb mistake next time! Anyway, I designed a PCB with a Hitachi H8/300H processor - it has a 16 bit data bus, but I only wanted to use an 8 bit ROM, so I set it up to run in 8 bit bus mode. I got PCBs made, built one up, it didn't work. No sweat, that's normal. Three days later I finally went back and read the databook properly - in 8 bit mode the data is read and written on the UPPER 8 data bits. Being used to little-endian chips, I had assumed that if only 8 bits were used, they would be the lower 8 bits! It required some clever cutting and jumpering to make the board work, but it finally did. At least the dynamic RAM I'd designed in (using 16 bit mode) worked fine. --- From: John Stauffer Although I've made my own share of dumb ones this is someone else's mistake I discovered it in an early 80's, 6800 based system that implemented a successive approximation register (SAR) A/D with a combination of discrete resistors, comparator, and software. For making readings the program would switch combinations of resistors which were summed together to produce a voltage, a comparator output would tell if this voltage was higher or lower than the input, resistor combinations would be changed for different & successively smaller voltages until a close match was found and the "A/D conversion" was complete. This A/D input was used to read the position of a pointing system as it moved up and down, we were finding significant errors between the up readings and down readings. After several weeks I found the SAR A/D was not implemented as a subroutine but with "copies" of the code in the 'up' & 'down' routines. The one difference I found was that the combinations of resistors selected for the same voltage iteration was different. Because the resistors were 5% discrete parts, what the programmer thought were identical resistance values being selected were actually different, resulting in different A/D readings depending on which way the mechanical system was moving. We solved it by using the same code for all A/D readings. --- From: Niall Murphy in Ireland This mistake teaches a valuable lesson about any components that hold state through power cycles. In this case it was a real time clock. As part of power on self test, many of the components of the system were used in some trivial way to ensure that the system had some hope of running. For the Real Time Clock (RTC), we simply wrote a time/date to it and read it back to ensure that it was operating. Before the write we read the current time of day and then restored it after the write. Some date had to be picked for the test, so I picked my birthday. During the trial period we got occasional complaints that the date was wrong. Because the user could change it back to the right date, it was no big deal, and at first we assumed that the dates were set wrong by some user messing around, and then a different user of the same system raised the complaint. After a while we noticed that all of the dates were late December 1968, shortly after my birthday. I smelled a rat, but could not figure out why the date would be jumping to my birthday, since the test should always restore the current date after the test write. I could not reproduce the problem, but we continued to get occasional reports form users, though the engineers never saw it on any of our systems - leading to a few 'Are you really, really sure no one else changed the date on you' conversations. Eventually the penny dropped. Occasionally the user would power the system on and then off quickly. The self test would have got to just past the write of the time/date, and then lose power. Obviously this only happened once in every couple of thousand power cycles. The engineers never saw the problem because they were much more delicate with the machine than the trial users. The engineers would always look to see that the self-test was passing before doing anything else with the machine - including turning it off. The lessons: 1. You can lose power any time, even just after power-on - use a power loss interrupt or some other mechanism to ensure that you do not lose it in an inconsistent state. 2. Engineers are not typical users. ---- From: Ian Blythe in France Ian makes this fascinating comment: " I really would recommend that engineers spend at least a few years in a sales environment. In this age of down-sizing, engineers need to learn how to sell their competances." Agreed, Ian - we need to learn to communicate what we do better to our bosses and others in our organizations (and lives!) My first job was as an electronics design engineer in an Avionics Company. My responsibility involved the main system architecture for the navigation computer and several CRT and LCD based display units. Point one. If you are designing a display system, NEVER make mock-up display pages that change as keys are pressed. You'll have a real fun time then explaining to the management that there is still 18 man-months work to go on the *real* software... Point two. Beware of exhibitions and demo models. Our system worked fine from the emulator, so the night before installation in the exhibition we swapped the emulator probe for a processor. Nothing worked...I personally checked the clock lines, yup 4MHz and 16MHz clocks where present and correct. Finally at 5am a decision was made to take the emulator with the unit to the exhibition and to find somewhere to hide the emulator. We also had to train the stand staff how to boot the emulator up. (I was actually back in the office to go with the kit at 8am...) Needless to say, when it all came back I checked it again, yes the 4MHz and 16MHz clocks were present, but they were swapped! I hadn't cross checked against the pin position on the backplane. Moral being: don't just check the signal, check where it is! Point 3. If you are developing stuff for an exhibition, always check where it's going to go. At another exhibition, they had decided to place our display into a photographic mockup of a helicopter fight deck. When we got there, sure enough there was a hole for the display unit, but this hole was only the visible screen size, too small for the full unit to slide in... So while all the other stands were polishing off we had a small crowd watching us hacksawing a hole into the photograph. Needless to say, three hacksaw blades later, we managed to squeeze our box in and by the morning it looked really good. --- From Derek Somerville in New Zealand I once ran a project where we designed a system for a company here in New Zealand, who I will call XYZ. The first end user for the system was in England. It was a good sized project - took four of us almost a year to complete. The first system was tested and then disassembled and packed for shipment by XYZ. I went to England with a person from XYZ and we unpacked and began reassembling everything. As we started to assemble the units, we ran into problems. Nothing would fit properly. We were up against a real problem then, because the client's whole business was based on this equipment. Finally I clicked that the cases had been changed. When challenged, the dipstick from XYZ finally admitted that he had changed the case design at the last minute, and that these cases were new ones - not the ones we had tested the system in! The reason? They looked nicer. End result - the client lost faith in XYZ and closed up. XYZ went bankrupt. So did the company I worked for about a year later mostly because of the amount of money we had lost on this project. Moral - monitor anything that is not under your control, especially when the stakes are so high. And, another from Derek: Some years ago I worked in a small company that dealt in cctv equipment. We had in a motor drive amplifier, which took 220V-AC, rectified and filtered it to something just 400v-DC, and then produced 220V-AC again. This enabled equipment requiring stable mains supply to run off something like a portable petrol-driven generator or other supply with unstable frequency and voltage. My boss had looked at this unit for some time without finding the fault, which was that it would run for some period of time and then start intermittently 'loosing' a couple of cycles here and there. Of course this did nasty things to the stability of video equipment running on the supply. The only clue was that there was sometimes a small clicking, almost like an arcing sound coming from the unit. However, this was dismissed as not relevant, possibly from the fan or something else. Anyway, the client came to see how it was going, as we had had the unit in for over a week by this time, and my boss was describing to him the problem and what he had done to try to find the cause. Suddenly, as they were leaning over the unit, there was an almighty explosion, and bits flew everywhere, along with a big cloud of smoke. Both my boss and the client did of course get quite a fright. One of the filter capacitors, several thousand microfarads at a working voltage of 440V, had exploded. That was the clue that was missed - easy to see in hindsight that the clicking was the capacitor breaking down internally. The moral - do not dismiss any symptom if you a problem you cannot get to the bottom of. PS. My punishment for laughing so much was having to clean all the gunk and out the tiny bits of tin foil that had wrapped around everything on the board, which took me a couple of days of painstaking work! Embedded Seminar! Irvine, CA - Thursday, November 13 ---------------------------------------------------- I'm conducting a full-day embedded seminar in Irvine on November 13. It's called "The 24 Best Ideas for Developing Better Firmware Faster", and is for the developer who is honestly looking for new ideas, but who wants to cut through the academic fluff of formal methodologies and immediately find better ways to work. The focus is uniquely on embedded systems. I'll talk about ways to link the hardware and software, to identify and stamp out bugs, to manage risk, and to meet impossible deadlines. For more information check out http://www.ganssle.com or email info(aatt_sign)ganssle.com. Thought for the Week -------------------- In the beginning, God created the bit. And the bit was a zero. On the first day, he toggled the 0 to 1, and the Universe was. (In those days, bootstrap loaders were simple, and "active low" signals didn't yet exist.) On the second day, God's boss wanted a demo, and tried to read the bit. This being volatile memory, the bit reverted to a 0. And the universe wasn't. God learned the importance of backups and memory refresh, and spent the rest of the day (and his first all-nighter) reinstalling the universe. On the third day, the bit cried "Oh, Lord! If you exist, give me a sign!" And God created rev 2.0 of the bit, even better than the original prototype. Those in Universe Marketing immediately realized that "new and improved" wouldn't do justice to such a grand and glorious creation. And so it was dubbed the Most Significant Bit. Many bits followed, but only one was so honored. On the fourth day, God created a simple ALU with 'add' and 'logical shift' instructions. And the original bit discovered that -- by performing a single shift instruction -- it could become the Most Significant Bit. And God realized the importance of computer security. On the fifth day, God created the first mid-life kicker, rev 2.0 of the ALU, with wonderful features, and said "Forget that add and shift stuff. Go forth and multiply." And God saw that it was good. On the sixth day, God got a bit overconfident, and invented pipelines, register hazards, optimizing compilers, crosstalk, restartable instructions, micro interrupts, race conditions, and propagation delays. Historians have used this to convincingly argue that the sixth day must have been a Monday. On the seventh day, an engineering change introduced Windows into the Universe, and it hasn't worked right since. About The Embedded Muse ----------------------- The Embedded Muse is an occasional newsletter sent via email by Jack Ganssle. Send complaints, comments, and contributions to him at jack(aatt_sign)ganssle.com. To subscribe, send a message to majordomo(aatt_sign)ganssle.com, with the words "subscribe embedded email-address" in the body. To unsubscribe, change the message to "unsubscribe embedded email-address". The Embedded Muse is supported by The Ganssle Group, whose mission is to help embedded folks get better products to market faster.
The Embedded Muse -------------------------------------------------------------- Volume 2, Number 6 Copyright 1997 TGG September 3, 1997 -------------------------------------------------------------- You may redistribute this newsletter for noncommercial purposes. For commercial use contact info(aatt_sign)ganssle.com. EDITOR: Jack Ganssle, jack(aatt_sign)ganssle.com CONTENTS: - Editor's Notes - More Dumb Mistakes - Embedded Seminar in Boston - Thought for the Week - About The Embedded Muse Editor's Notes -------------- For those of you interested in the "The 24 Best Ideas for Developing Better Firmware Faster" seminar in Boston on September 18, see the info later in this newsletter. It's just about booked up. Thanks to all of the readers who have submitted ideas for the "Dumb Mistakes" series. It's quite interesting that almost all of the submissions to date are hardware related. Is software immune from these sorts of errors? Or, are the software mistakes soooooo dumb that we're afraid to admit them? This issue consists of more contributions from readers all over the world, from New Zealand to Croatia - thanks, all. More Dumb Mistakes ------------------ From: Jonathan Marks in New Zealand One dumb mistake that I made when cutting my teeth on embedded work and have seen very often since is: Placing the code that kicks the watchdog in the timer tick ISR, and then wondering why the program never resets when it goes off to never never land. How many of us out there are willing to admit we made this sort of mistake? --- From: Georg Christen in Germany Although I'm working in technical management, it is sometimes helpful to not have forgotten everything one has learned at university some time ago. We once developed an embedded DSP system, which was using serial communication lines to talk with the outside world. The serial interface chips were very simple, maybe 12 pins or so, and there was a pretty good application example in the data sheet of those devices. Everything worked fine, however from time to time (absolutely NOT deterministic, of course), the serial communication froze. The hardware designer blamed the software, the software designer couldn't find a fault in his software, and thus it went from left to right "Maybe the software does this or that" (hw guy) or "Probably the I/O chip just freezes" (sw guy). When we found that error, we actually had one of those boards out at customer (astonishingly, he didn't find the error!), and time was running short to identify and fix the problem! So, I took the two designers, and we went for a long long debugging session. Nothing. Finally I went through the I/O software code, didn't see any major thing. Then we went through the schematics, checked the wiring (it was a wire-wrap board). Nothing. Night had arrived and I ordered Pizza for all of us. While waiting for the Pizza man to arrive, I browsed through the data sheet of the infamous I/O chip. Two pins were labeled "CTG". OK, so where do those pins go? Ah, they are not connected. "Tell me, why aren't they connected?" - "The data sheet doesn't say anything about those pins, and the application example doesn't use them either, so I left them open". Aha. There was a tiny footnote on the data sheet, which said "CTG: Connect to Ground. If not connected to ground, the device may fail intermittently or develop an undeterministic behavior". So as soon as we connected those pins to ground, the system worked like a charm. When the pizza arrived, everything was OK and everybody was happy (not least of the pizza). The morale? Read everything (yes: everything!) in a data sheet. Connect all pins of a device. Yes, all! Ordering pizza can be a good idea! (EDITOR'S NOTE: I like that idea!) And, talk with people, even if they are only marginally involved with the project. Sometimes, a designer (hw or sw) can be a bit "blind", and heavily biased. We got the customer board exchanged without him noticing it, but that's another story. --- From: T.N.Kishore Reddy in The Netherlands Here is one such mistake of the numerous ones that I made, but by far the most costly one...!! I was woking in a Test & Measuring Instruments Division of a large organisation, working on industrial trivector meters. In this particular product, apart from logging the consumption of power, keeping track of the failures and tamper of the meter is a big issue. In our product we used to use Motorola's time keeper IC which had to be kept running in case of power failures by the help of a Lithium battery backup. When the silicon industry boom made a NVRAM with battery back up and time keeper built in, we decided to go for this IC from SGS-Thompson and just made a minor modifications to the board and plugged in this IC in place of Motorola's. We decided that there was no need to test the s/w as the IC placed is fully compatible with the replaced IC. We sent the meters to the customer and from the very next day of installation, we started getting reports of erroneous power failure indications by the meter. We brought the meter back and analysed the problem and much to my embarrassment, there is a line in the data sheet of this IC, stating that the time cannot be read from the real-time-clock for one second from the time of power on. As there was no such condition in the earlier chip, the s/w was written in such a way that the time was read immediately on powering on the system. So when we read the time, initially on power on, it was not yet updated and the time was same as the time during which the power failed...!! So the power fail time and power on time remained the same and the power fail duration became 'zero'... This mistake has cost my company more than money; the customer was not very happy with the product on the day one... --- From: Tim Loose in the USA I wanted to share with you one of my "learning experiences" from my first engineering job. I was working for a telecommunications company. My first independent assignment involved a panel with 24 LED's to display the status of 24 telephone lines. I devised a clever scheme that reduced the number of driving transistors; unfortunately, the prototype kept blowing out the LED's. I eventually determined that the LED's could not withstand the +48 VDC in a reverse biased condition; this is not a spec prominently displayed on the spec. sheet, so I assumed it would work. The first big "learning experience". The trick is to minimize the unnecessary "learning experiences" and keep learning from the unavoidable ones. --- From: Charles Manning in New Zealand This didn't happen to me, and it's a recollection from about seven years back so, like a fine wine, it has probably improved with age but the core story is true. Names have been changed not to protect the guilty but because I've forgotten... Chuck and Dave were good friends and had worked with each other on many projects. They were working on the control and motor drive circuit for an anti-aircraft gunnery turret. This is a formidable piece of machinery: eighteen tons of steel (it had to be heavy to handle the guns firing multiple rounds per second) that could be rotated as slowly as a few milliradians per second (way less than 1 degree per second) up to three radians per second (about half a revolution per second). There had been a report of "strange sounds at low speeds"; one of those multi-variable problems that could be software, electronic or mechanical. "Just needs some oil", said Dave. Chuck and Dave hooked up a bunch of test gear with the idea of rotating the machine at its slowest speed and monitoring what happened. Dave got into the turret and tool hold of the diagnostic keyboard. The keyboard had a key marked "+R" which would speed up rotation towards the right. From stopped, press once for the slowest speed, press more for higher speeds up to ten for the highest speed. Check tapped the button. Nothing. Tap.... tap, tap, tap. Still nothing. "Hey Chuck [tap, tap] this button's busted [tap, tap] again", tap, tap, tap, tap, tap. "Dave you moron [they weren't into this kumbaya stuff], did you clear the breakpoint?". Dave clears the breakpoint and the command processor task immediately processes all the key strokes. Eighteen tons of steel lurches forth at full speed. Before somebody got to the circuit breaker, tens of thousands of dollars of test gear was smashed. Dave got thrown on his back and needed stitches above his eye where he got hit by a logic analyzer. Chuck needed a while in hospital - the gun barrel had hit him on the back like an oversized baseball bat. --- Another from: Charles Manning in New Zealand When working on a double Eurocard rack system, we typically used an extender card to get access to the card being debugged. Occasionally this wasn't enough and we made up two Eurocard sockets with power etc so that we could pull the card out of the system and debug it on the bench. This went great until the day we switched the two sockets and fed -12V and +12V into the 0 and 5V connections......... On the same project, we started using a new PCB house that had just geared up to multi-layer boards. When the boards came back, they didn't work. Buzzing it out, power was not getting onto the board and we had DIP ICs with their legs all shorted together. Funny, we could see through 6 layer boards with ground and power planes! We figured out what had happened, the PCB house had never seen ground/power planes before and figured that with all this copper, these must be negative layers, so they kindly did us the service of reversing them. --- From: Dejan Durdenic in Croatia Here's one about "never assume anything": Some time ago I developed a PCB including 10-bit DAC from PMI. The company was bought by Analog Devices, who included all former PMI parts in AD catalogue. After PCB was assembled, test software behaved odd - instead of sawtooth waveform DAC produced a mess...I checked and checked and finally discovered that , for some reason, PMI had marked DAC's MSB as D1 and DAC's LSB as D10 ( most of other parts mark those as D9 and D0 ...) The problem was detected, but PCB was done...so I created an bit-swap look-up table (faster than subroutine) and fixed hardware bug. Moral: ALWAYS check data sheets thoroughly! The other one is more subtle... I developed a PCB around TMS320C31 DSP. I had some RAM and some glue logic around. The logic was done with ALTERA EPLD's ( very fast ones - that's important). After the prototype was assembled and test software written, some strange things start to occur. It seemed that , for some reason , program counter "rolled around" and that program was started again. I used 100MHz scope to check if there were any unwanted reset pulses - there were none. Then I used JTAG debugger to check register values but registers which should be cleared after hardware reset, kept their values - I concluded that CPU fetched some incorrect data from RAM and jumped back to start or something like that. I spent whole week searching, but everything failed. To be even worse - situation was not exactly repeatable. Sometimes it happened immediately, sometimes program run for several seconds. I was desperate and returned back to good, old scope. Then - there it was! I connected the probe to RESET line and set trigger to falling edge ( It was TDS320 TEK scope - a digital one with very good trigger circuit) and sometimes trigger responded even there seemed to be no change on the line !!! Scope's bandwidth was too low for glitch to be seen but trigger captured it. The glitch was so short that it partially reseted CPU (only PC was cleared) ! RESET pulse was created in a EPLD and as it was extremely fast (7nS) glitch was fast too...Then I recalled an old advice - never use logic family faster than your application needs! (By the way - problem was solved with small SMT cap on the prototype on the RESET line and with better layout around EPLD in the final version) --- From: David Hinerman in the USA Here's one that my dad pulled. Dad and I were taking a night class in printed circuit board design at the local technical college. Me because I was studying to go into electronics, Dad because it was fun. The 'final' for the course was to design, fabricate, and assemble a PC board for some small circuit. I built a crystal filter, but Dad wanted a hefty 12 VDC power supply to power his CB radio at home. Dad did a really nice job on the board -- 2 oz. copper, 1/4 inch wide tracks for the high-current circuits, and about 25,000 microfarads worth of filter caps. He bought a really nice case from Radio Shack and mounted the board inside, with the transformer, and made a really slick front panel to cover it all. He brought it in to class to show it off a few weeks before the course ended. We all stood around listening to the local chatter on Channel 19 when suddenly BAM! As we crawled out from under various workbenches we saw paper protruding from the vents in Dad's power supply cabinet. Dad opened it up, and the teacher pulled out the remains of the filter cap casing. The ratings were clearly readable: 25,000 uF, 16 WVDC. Dad had assumed that a 16 volt cap was plenty for a 12 volt supply. The teacher explained to Dad about RMS and peak voltages, and capacitor charging tendencies, and all that. Dad had used an 18 volt transformer, so the teacher recommended a 35 volt cap. Dad went out the next day, bought one, and installed it that evening. The next class, Dad brought the box in to try again. we stood around listening to his CB and making jokes about mortar fire when BAM! More confetti. Dad had installed the new cap backwards. --- From: Michael J. Schreck in the USA Here's one for the assumptions list. I was wire wrapping a small prototype circuit in stages and testing each stage when it was finished. After wiring in the 4th stage, the previous stages stopped working. I spent 3 days with a logic probe and a scope, only to find out that I had severed the power connection to the first stage! I no longer assume that anything is getting power! Embedded Seminar! Boston - Thursday, September 18 -------------------------------------------------- Last issue I mentioned a full-day embedded seminar I'll be conducting in Boston next month. It's called "The 24 Best Ideas for Developing Better Firmware Faster", and is for the developer who is honestly looking for new ideas, but who wants to cut through the academic fluff of formal methodologies and immediately find better ways to work. The focus is uniquely on embedded systems. I'll talk about ways to link the hardware and software, to identify and stamp out bugs, to manage risk, and to meet impossible deadlines. A few seats are still available. For more information check out http://www.ganssle.com or email info(aatt_sign)ganssle.com. Thought for the Week -------------------- TOP TEN THINGS ENGINEERING SCHOOL DIDN'T TEACH YOU 10. There are at least 10 types of capacitors. 9. Theory tells you how a circuit works, not why it does not work. 8. Not everything works according to the specs in the databook. 7. Anything practical you learn will be obsolete before you use it, except the complex math, which you will never use. 6. Always try to fix the hardware with software. 5. Engineering is like having an 8 a.m. class and a late afternoon lab every day for the rest of your life. 4. Overtime pay? What overtime pay? 3. Managers, not engineers, rule the world. 2. If you like junk food, caffeine and all-nighters, go into software. 1. Dilbert is not a comic strip, it's a documentary.
The Embedded Muse -------------------------------------------------------------- Volume 2, Number 5 Copyright 1997 TGG August 21, 1997 -------------------------------------------------------------- You may redistribute this newsletter for noncommercial purposes. For commercial use contact info(aatt_sign)ganssle.com. EDITOR: Jack Ganssle, jack(aatt_sign)ganssle.com CONTENTS: - Editor's Notes - More Dumb Mistakes - Embedded Seminar in Boston - Thought for the Week - About The Embedded Muse Editor's Notes -------------- For those of you interested in the "The 24 Best Ideas for Developing Better Firmware Faster" seminar in Boston on September 18, see the info later in this newsletter. As of today there are only a few seats left. Readers have made more contributions to the "Dumb Mistakes" collection. Keep sending them so maybe we can all learn from each other. Finally, the "Thought for the Week" is set to the tune of the theme song of The Beverly Hillbillies. International readers may not have been subjected to this old TV program, so may not know the tune. You're lucky; alas, this music all too often echoes around in our American skulls when we're supposed to be thinking productive thoughts and cranking code... More Dumb Mistakes ------------------ From: Mitchell McGee My first project at a new company highlighted the importance of not making assumptions. The design incorporated a TL7702 voltage monitor for brown out protection. I connected the previously unconnected active high reset signal to the reset input of the new processor I was tasked to add. Of course the processor failed to power up consistently. When I probed the reset signal I saw 12 volts during reset! I had noticed that the TL7702 was monitoring 12V; but I assumed that the device was 5V powered. Wrong!! The previous designer hid all the power and ground pins so they were not visible. Now I create "pin lists" that describe the implementation characteristics of each pin of every IC and never hide the power and ground pins. ---- From: Jack Ganssle Mitchell's comment about making assumptions is right on: I find one of the toughest things to teach young engineers is to check their assumptions. Their test equipment might be bad; their compiler might not be the right version. Thus, this story of my own, though the names have been changed to protect the guilty: An engineer I worked with, one a couple of years out of college, designed a marvelously complex new board with about a hundred high density SMT packages. After a week of "Bob's" inability to make even the smallest part of the logic function I was called in. The scope showed all of the digital signals floating in bizarre half states. Things were heating madly; sometimes packages even de-soldered themselves. With a bit of head scratching and a long searching session with the data books the problem came clear: the SMT packages did not have power and ground in traditional places. "Bob" hadn't bothered to check. He simply assumed power and ground went on corner pins. Several weeks of work and $5000 of PCBs and parts went in the trash that day... ---- From: Rich Quinnell, EDN Magazine Having had my own share of goofups I sympathize with all the stories. Here's a few of mine. Debugging a power-filter circuit, I attached a scope probe to one leg of an electrolytic. To remove the 60-cycle overlay and see only the voltage across the cap, I put the ground lead of the probe on the other leg. As the ground clip vanished in a blue flash and the cap's paper/foil windings spiraled in an arc across the room, I learned to use the differential mode on a two-channel scope. Three weeks of effort trying to solve what I thought was an intermittent failure of a NVRAM to keep its data secure finally got resolved when I realized that the RAM was working fine. The problem appeared when the software did a checksum on the data to verify its accuracy, and failed. Turns out the register bit that converted the ALU from binary to BCD arithmetic was never initialized, and would occasionally power-up in BCD mode. Funny how adding in a different number system results in a different number. Lastly, I will never again try to carry a solvent in a Styrofoam cup. It not only melted the cup, it melted the tile floor and fused my crepe-soled shoes to it. Embedded Seminar! Boston - Thursday, September 18 -------------------------------------------------- Last issue I mentioned a full-day embedded seminar I'll be conducting in Boston next month. It's called "The 24 Best Ideas for Developing Better Firmware Faster", and is for the developer who is honestly looking for new ideas, but who wants to cut through the academic fluff of formal methodologies and immediately find better ways to work. The focus is uniquely on embedded systems. I'll talk about ways to link the hardware and software, to identify and stamp out bugs, to manage risk, and to meet impossible deadlines. A few seats are still available. For more information check out http://www.ganssle.com or email info(aatt_sign)ganssle.com. Thought for the Week -------------------- The Computer Hillbillies Come and listen to a story 'bout a man named Jed A poor college kid, barely kept his family fed But then one day he was talkin' to a recruiter Who said, "they pay big bucks if ya work on a computer..." UNIX, that is... CRTs... Workstations... Well, the first thing ya know ol' Jed's an Engineer The kinfolk said "Jed, move away from here" They said "Arizona is the place ya oughta be" So he bought some donuts and he moved to Ahwatukee... Intel, that is... dry heat... no amusement parks... On his first day at work, they stuck him in a cube Fed him more donuts and sat him at a tube They said "your project's late, but we know just what to do Instead of 40 hours, we'll work you 52!" OT, that is... unpaid... mandatory... The weeks rolled by and things were looking bad Schedules started slipping and some managers were mad They called another meeting and decided on a fix The answer was simple... "We'll work him sixty-six!" Tired, that is... stressed out... no social life... Months turned to years and his hair was turning grey Jed worked very hard while his life slipped away Waiting to retire when he turned 64 Instead he got a call and escorted out the door Laid off, that is... de-briefed... unemployed... Now the moral of the story is listen to what you're told Companies will use you and discard you when you're old So gather up your friends and start your own firm Beat the competition, watch the bosses squirm Millionaires, that is... Bill Gates... Steve Jobs... Y'all come back now... ya hear' About The Embedded Muse ----------------------- The Embedded Muse is an occasional newsletter sent via email by Jack Ganssle. Send complaints, comments, and contributions to him at jack(aatt_sign)ganssle.com. To subscribe, send a message to majordomo(aatt_sign)ganssle.com, with the words "subscribe embedded email-address" in the body. To unsubscribe, change the message to "unsubscribe embedded email-address". The Embedded Muse is supported by The Ganssle Group, whose mission is to help embedded folks get better products to market faster.
The Embedded Muse -------------------------------------------------------------- Volume 2, Number 4 Copyright 1997 TGG August 7, 1997 -------------------------------------------------------------- You may redistribute this newsletter for noncommercial purposes. For commercial use contact info(aatt_sign)ganssle.com. EDITOR: Jack Ganssle, jack(aatt_sign)ganssle.com CONTENTS: - Dumb Mistakes - Embedded Seminar in Boston - Thought for the Week - About The Embedded Muse Dumb Mistakes ------------- No lesson is learned more powerfully than those that come from making mistakes. The bigger the mistake the more meaningful the lesson. Bob Fehrenbach, a loyal Embedded Muse reader, suggested that I start passing along stories of dumb mistakes we've all made, in a spirit of sharing our pain to hopefully spare others the same. So, send your dumb mistakes to me (jack(aatt_sign)ganssle.com) and I'll pass them along. As one who has spent too much time in the abyss of disaster, here's a couple of my own stories: A front panel switch on an analytical instrument was to activate the COPY button on a thermal printer. An associate enthusiastically sketched in wiring from the switch to an input port on the computer. Firmware would read the switch closure and then activate an output bit that pulled in a relay which commanded the printer to do its thing. I'll never forget the look on his face when I suggest just wiring the switch directly to the printer, bypassing the computer altogether... But, I have to plead guilty to making far too many dumb mistakes myself. One that still hurts was in my life as a consultant in the early 80s. My partner and I were designing a Z80 based thickness gauge. Our customer had hired another consultant for a different portion of the project. At one meeting this individual suggested - strongly - that we design our code around an RTOS. Our egos were too fragile to take suggestions from a competitor (only through harsh experience do we learn some humility!), so we resisted and created mythical reasons for writing procedural code. Without an RTOS the system met no performance targets and was impossible to maintain. We later spent far too much (of our own money) shoehorning an RTOS into the completed code. I still feel like an idiot when thinking about that experience. Bob Fehrenbach had two stories of his own to pass along: I once did a whole Z8 project using absolute register addresses rather than descriptive labels. The product worked fine. Maintenance was impossible. (Editor's note: The Univac 1108's Exec 8 OS was even worse: I still shudder to think of the 100,000 lines of assembly code with label-less jumps - like JMP $+57). Bob also added: Several years ago I designed a unit that had a 16 digit LED display. The unit also included 16 keys. I used the digit select lines to scan the keys. A key press would raise the 'key' input to the processor if the corresponding digit was selected. So far nothing special. Originally, when the software detected any key press, e.g. #5, it would initiate the debounce routine. The scan then continued and if it subsequently detected a different key, e.g. #9, the debounce routine started over. If TWO keys were pressed simultaneously, the software thought that the input was changing and never produced a valid key. This was not a problem until we needed a function that required simultaneous key pressed. BUSTED! The solution, of course, was to look for changes only after ALL keys were scanned. Seems obvious looking back. Why was this not obvious when the code was first written? Moral: Scan ALL keys and only then look for changes. Embedded Seminar! Boston - Thursday, September 18 -------------------------------------------------- Last issue I mentioned an embedded seminar I'll be conducting in Boston next month. It's called "The 24 Best Ideas for Developing Better Firmware Faster", and is for the developer who is honestly looking for new ideas, but who wants to cut through the academic fluff of formal methodologies and immediately find better ways to work. The focus is uniquely on embedded systems. I'll talk about ways to link the hardware and software, to identify and stamp out bugs, to manage risk, and to meet impossible deadlines. Seats are still available. For more information check out www.ganssle.com or email info(aatt_sign)ganssle.com. Thought for the Week -------------------- Steve Litt (whose web site - www.troubleshooters.com - carries lots of neat hints about debugging systems) submitted an improved version of the World's Last C Bug code: launches = 0; while (1) { status = GetRadarInfo(); if (status = 1) { LaunchMissiles(); launches++; } if (launches > 1) apologize(); } About The Embedded Muse ----------------------- The Embedded Muse is an occasional newsletter sent via email by Jack Ganssle. Send complaints, comments, and contributions to him at jack(aatt_sign)ganssle.com. To subscribe, send a message to majordomo(aatt_sign)ganssle.com, with the words "subscribe embedded email-address" in the body. To unsubscribe, change the message to "unsubscribe embedded email-address". The Embedded Muse is supported by The Ganssle Group, whose mission is to help embedded folks get better products to market faster.
Back to the top.
Back to the top.