- Number 41:
- Number 40:
- Number 39:
- Number 38:
- Number 37:
- Number 36:
- Number 35:
- Number 34:
- Number 33:
- Number 32:
- Number 31:
- Volume 3:
- Volume 2:
Navigate to:
| EE371 Home Page | EE Home Page |
The Embedded Muse
------------------------------------------------------------
Embedded Muse 41 Copyright 1999 TGG December 24, 1999
------------------------------------------------------------
You may redistribute this newsletter for noncommercial purposes. For
commercial use contact info@ganssle.com.
EDITOR: Jack Ganssle, jack@ganssle.com
CONTENTS:
- Metastability - The Facts and a Question
- Thought for the Week
- About The Embedded Muse
Metastability - The Facts and a Question
----------------------------------------
Our digital world is marred by weird effects that's the stuff of
nightmares. Simple timing errors can transform our "perfect" logic designs
into nests of lurking disasters, disasters whose frequency is so rare
we're inclined to call the failures "glitches" and dismiss them out of hand.
One of the more insidious problems lies in violating a flip flop's setup
time. EVERY flop has a specified minimum setup time: the number of
nanoseconds that data must be present at the device's input before the
clock signal transitions. If the data appears inside of this window (say,
if the min setup time is 2 nsec and data changes 1 nsec before clock
changes) then the output of the flip flop is undefined. This condition is
called "metastability", and is clearly a profound issue.
Fully synchronous systems don't suffer from metastability issues since, by
definition, data changes at safe times. Instead, metastability comes into
play when data is asynchronous to clock. Suppose a parallel encoder goes
into a 12 bit latch that is clocked by the CPU when the processor is ready
to read the data. The encoder is asynchronous to the CPU's clock, so
there's no reasonable way to insure that the changing encoder data will
meet the latch's setup time. Occasionally - not often - the latched data
will be corrupt.
Now, let's examine the meaning of "corrupt". As a young engineer I learned
that violating a flop's setup time would yield an unpredictable output:
that is, try to clock in a one, and the output could be either a one or a
zero. However, most papers on the subject suggest metastability yields very
long propagation times. That is, instead of taking 5 nsec to clock the data
through, the time can rise to many tens or hundreds of nanoseconds, the
amount of time being a function of the device's construction and how badly
the setup time is violated.
Well, a long propagation time can be a problem but sure seems less
disastrous than having the device switch incorrectly. While giving an
on-site seminar to a company in the southwest recently this question came
up. Since then I've been rereading the literature trying to understand if
metastability yields ONLY long prop times, or if it can indeed cause the
flop to settle in a random state.
My favorite book on high speed design ("High Speed Digital Design" by
Howard Johnson and Martin Graham) talks only about an increase in prop
delay. But scope pictures on pages 129 and 130, which show how the delay
increases, also demonstrate the flop's output switching correctly only
about half the time. They're trying to clock a one through, but the flop
unpredictably seems to stabilize in either a one or a zero condition.
Another great reference on the subject is TI's "Metastable Response in 5-V
Logic Circuits" (http://www-s.ti.com/sc/psheets/sdya006/sdya006.pdf). This
work, too, discusses the increase in prop delay without specifically
referring to a flop possibly assuming an incorrect state. Timing diagrams 3
and 4, though, clearly suggest that such an error can and does happen.
Metastability problems were once at least somewhat visible, back when we
used individual flip flops. Now, with hundreds or thousands of registers
deeply buried inside of FPGAs, PLDs and ASICs, the ever lurking peril of
metastability is much more difficult to diagnose.
So, here's an end-of-year question for you gurus out there: we know that
prop delay in the metastable region increases exponentially. Can the flop
indeed also settle into an incorrect state? I'll share the results in
another issue of the Muse.
Thought for the Week
--------------------
From Mike O'Brien:
Twas the night before Y2K, and all through the nation
We awaited The Bug, the Millennium sensation.
The chips were replaced in computers with care,
In hopes that ol' Bugsy wouldn't stop there.
While some folks could think they were snug in their beds,
Others had visions of dread in their heads.
And Ma with her PC and me with my Mac,
Just logged onto the Net, and kicked back with a snack.
When over the server, there arose such a clatter,
I called Mister Gates to see what was the matter.
But he was away, so I flew like a flash
Off to my bank to withdraw all my cash.
And what with my eyes should I unhappily see?
My good old Mac looked very sick to me.
The hack of all hackers was looking so smug,
I knew that it must be the Y2K Bug.
His image downloaded in no time at all,
He whistled and shouted, Let all systems fall!
Go Intel! Go Gateway! Now HP! Big Blue!
Everything Compaq And Pentium too!
All processors big, All processors small,
Crash away! Crash away! Crash away all!
As I drew in my breath and was turning around,
Out through the modem, He came with a bound.
He was covered with fur, and slung on his back,
Was a sackful of viruses, all set for attack.
His eyes - how they twinkled! His dimples - how merry!
As midnight approached, things soon became scary.
He had a broad little face and a round little belly,
And his sack filled with viruses quivered like jelly.
He was chubby and plump, perpetually grinning,
And I laughed when I saw him (though my hard drive stopped spinning).
A wink of his eye, and a twist of his head,
Soon gave me to know a new feeling of dread.
He spoke not a word, but went straight to his work,
He changed all the clocks, then turned with a jerk.
With a twitch of his nose, and a quick little wink,
All things electronic soon went on the blink.
He zoomed from my system, to the next folks on line,
He caused such a disruption, could this be a sign?
Then I heard him exclaim, with a loud, hearty cry,
Happy Y2K to all, kiss your PC good-bye!
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@ganssle.com.
To subscribe, send a message to majordomo@ganssle.com, with the words
"subscribe embedded email-address" in the body. To unsubscribe, change the
message to "unsubscribe embedded email-address". BUT - please use YOUR
email address in place of "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 ------------------------------------------------------------ Embedded Muse 40 Copyright 1999 TGG December 1, 1999 ------------------------------------------------------------ You may redistribute this newsletter for noncommercial purposes. For commercial use contact info@ganssle.com. EDITOR: Jack Ganssle, jack@ganssle.com CONTENTS: - New Embedded Books - Thought for the Week - About The Embedded Muse New Embedded Books ------------------ Jean LaBrosse is back with an update of his "Embedded Systems Building Blocks" (R&D Books, ISBN 0-87930-604-1), hot off the press within the last week or two. I've always been a fan of his articles and books, and think this latest is a valuable addition to any embedded library. The book is a collection of drivers for some of the more common embedded problems. It starts with a 40 page introduction to managing real time problems, largely in the context of using a RTOS. This section alone is worthwhile for anyone trying to learn about using an RTOS, though I'd also recommend getting his "uC/OS-II, The Real Time Kernel". Included code (also on the companion CD-ROM) covers the following: - Keyboard handler, for keypads arranged in matrices that are software scanned. - Seven segment LED driver, for multiplexed arrays of LEDs - A complete LCD driver package for units based on Hitachi's HD44780 chip - A time of day clock package, which manages time in an year:month:day and hours:minutes:seconds format. It's Y2K compliant, to boot! - If your real time code works with multiple delay and timeout issues, his timer manager is a useful chunk of code. It manages up to 250 software timers; all are driven off a single timer interrupt source. His example shows this running from a 1/10 second interrupt rate; I'd be interested to see if it can be scaled to higher rates on reasonably small CPUs. - Discrete I/O drivers for inputs and outputs, with edge detection code. I like the way he abstracts the hardware to "logical channels", which makes it so much easier to change things, and to create software stubs for testing before hardware is available. - Fixed point math - one of the best discussions I've seen on this subject, which is critical to many smaller embedded apps. Fixed point is a sort of poor man's floating point: much smaller code that runs very fast, but you sacrifice resolution and range. - ADC and DAC drivers, with a good discussion of managing these beasts in engineering units rather than un-scaled bits. An appendix includes Jean's programming conventions, a firmware standard. I passionately feel that firmware standards are the starting point of writing decent code. An alternative standard is available at www.ganssle.com/misc/fsm.doc. Much of the code is targeted at applications using the uC/OS RTOS. It's rather easy to port the code to any RTOS, and in many cases even to use it with no RTOS (though you'll have to delete some of the OS function calls). When I read the first version of his book my gut reaction was "well, I could write this stuff easily myself." That's true; most of this code is not terribly complex. But why bother? Why re-invent the wheel? The best developers find ways to buy, recycle, and borrow code, rather than write every last routine. Another new book is one I'll avoid reviewing... as it's my latest! "The Art of Designing Embedded Systems" (Butterworth-Heinemann, ISBN 0-7506-9869-1) is finally out, and is available from Amazon.com. The book is not an update to my earlier work; the two volumes are quite distinct and cover very different subjects. Thought for the Week -------------------- Klingon Programming Proverbs: Specifications are for the weak and timid! This machine is a piece of GAGH! I need dual Pentium processors if I am to do battle with this code! You cannot really appreciate Dilbert unless you've read it in the original Klingon. What is this talk of 'release'? Klingons do not make software 'releases'. Our software 'escapes' leaving a bloody trail of designers and quality assurance people in its wake. Debugging? Klingons do not debug. Our software does not coddle the weak. I have challenged the entire quality assurance team to a Bat-Leth contest. They will not concern us again. A TRUE Klingon Warrior does not comment his code! By filing this bug report you have challenged the honor of my family. Prepare to die! Our users will know fear and cower before our software! Ship it! Ship it and let them flee like the dogs they are! 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@ganssle.com. To subscribe, send a message to majordomo@ganssle.com, with the words "subscribe embedded email-address" in the body. To unsubscribe, change the message to "unsubscribe embedded email-address". BUT - please use YOUR email address in place of "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 ------------------------------------------------------------ Embedded Muse 39 Copyright 1999 TGG October 23, 1999 ------------------------------------------------------------ You may redistribute this newsletter for noncommercial purposes. For commercial use contact info@ganssle.com. EDITOR: Jack Ganssle, jack@ganssle.com CONTENTS: - Embedded Seminars in Chicago and Boston - Floating Point Approximations - Thought for the Week - About The Embedded Muse Embedded Seminars in Chicago and Boston --------------------------------------- I'll present the seminar "The Best Ideas for Developing Better Firmware Faster" in Chicago and Boston on November 8 and 9, 1999. 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. If you're interested reserve early as these seminars fill completely. For more information check out www.ganssle.com or email info@ganssle.com. A lot of folks have asked me to bring this seminar to their company. Email me at jack@ganssle.com if you're interested. Floating Point Approximations ----------------------------- I was surprised to find that one of my favorite programming books is no longer in print. "Computer Approximations" by J.F. Hart (John Wiley & Sons, 1968, ISBN 0-88275-642-7) is the bible of floating point approximations. Amazon.com claims they might be able to find used copies, and any decent university library will have a copy. C libraries include all of the standard math functions for trig, exponentiation, and the like. That's not much help to assembly-language programmers or C coders who had to delete the math library to save space. And, the C libraries are typically aimed at the mass of developers, offering high precision answers despite long execution times. Need a particularly fast trig function, and are you willing to sacrifice some precision? Hart's book is the place to find an appropriate algorithm. Hart's book gives polynomial solutions for all sorts of functions, including logs, trig, roots, etc. He also presents a number of variants, so you can select for a longer polynomial of high accuracy (and slower execution) or a shorter one that solves quickly but not so accurately. For instance, the COSINE function can be calculated to about 5 decimal digits of accuracy by: Cos(x)=.9999932946 -.4999990534*x**2 + .0414877472*x**4 - .00127120948*x**6 Need more speed? Try the following which gives 3.2 digits of accuracy: Cos(x)=.99940307 -.49558072*x**2 + .03679168*x**4 These approximations are valid for the range of 0 to 90 degrees. The argument "x" is in radians. He gives 46 different approximations for the cosine alone, with accuracies ranging from 2 to 23 decimal digits. For low resolution integer-only applications scale his coefficients to integers and save the space of lookup tables. Consider square roots: most of us write these as iterative algorithms that eat up tons of execution time. All of Hart's square root algorithms (88 variants are presented) use polynomial solutions, that execute in more or less fixed times. I've found references in runtime libraries to Hart's book going all the way back to the PDP-11 Fortran products from DEC 30 years ago. It's the best source of algorithms for these sorts of problems. Hart will frustrate some readers as he presents derivations that are deeply mathematical. I find the tables of polynomial coefficients tremendously useful though, and rarely bother with the math details. Thought for the Week -------------------- Thad Badowski sent this gem along. I thought it was particularly useful considering the recent loss of the Mars Climate Observer spacecraft due to a metric conversion problem. "Useful Metric Conversions" Americans (defined as residents of the USA) frequently have problems with metric conversions. In an attempt to clarify the conversion process I now submit some "Useful Metric Conversions." 1 million microphones = 1 megaphone 2000 mockingbirds = two kilomockingbirds 10 cards = 1 decacards 1 millionth of a fish = 1 microfiche 453.6 graham crackers = 1 pound cake 1 trillion pins = 1 terrapin 10 rations = 1 decoration 100 rations = 1 C-ration 10 millipedes = 1 centipede 3 1/3 tridents = 1 decadent 2 monograms = 1 diagram 8 nickels = 2 paradigms 2 wharves = 1 paradox 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@ganssle.com. To subscribe, send a message to majordomo@ganssle.com, with the words "subscribe embedded email-address" in the body. To unsubscribe, change the message to "unsubscribe embedded email-address". BUT - please use YOUR email address in place of "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 ------------------------------------------------------------ Embedded Muse 38 Copyright 1999 TGG September 20, 1999 ------------------------------------------------------------ You may redistribute this newsletter for noncommercial purposes. For commercial use contact info@ganssle.com. EDITOR: Jack Ganssle, jack@ganssle.com CONTENTS: - Embedded Seminars in Chicago and Boston - Embedded Systems Conference - Thought for the Week - About The Embedded Muse Embedded Seminars in Chicago and Boston --------------------------------------- I'll present the seminar "The Best Ideas for Developing Better Firmware Faster" in Chicago and Boston on November 8 and 9, 1999. 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. If you're interested reserve early as these seminars fill completely. For more information check out www.ganssle.com or email info@ganssle.com. A lot of folks have asked me to bring this seminar to their company. Email me at jack@ganssle.com if you're interested. Embedded Systems Conference --------------------------- Next week the 10th annual West Coast Embedded Systems Conference will be held in San Jose. I remember the first of these conferences, held in the beautiful Sir Francis Drake hotel in downtown San Francisco. The cable cars stopped outside, their cheerful bells sounding out to us as we sat in the few classes then offered. A mere handful of vendors had nothing more than small tabletop displays. This year almost 300 vendors will parade their latest nifty embedded tools, software and gadgets. Don't miss the 150 classes on all aspects of embedded development. This is a highly recommended event. Come and visit the show floor and attend the sessions. I'm looking forward to Clifford Stoll's keynote address: "Stalking the Wily Hacker". You may have read his most famous book, The Cuckoo's Egg. I'll be giving two classes on debugging ISRs (Monday and Wednesday). Monday at 7:30 AM I'm hosting the Shop Talk session "Debugging Tricks and Techniques for 8 and 16 bit Processors". This is a chance to sit around and share your coolest debugging ideas; it's NOT a lecture! See www.embedded.com for more info. Thought for the Week -------------------- Once upon a midnight dreary, fingers cramped and vision bleary, System manuals piled high, and wasted paper on the floor, Longing for the warmth of bedsheets, Still I sat there, doing spreadsheets, Having reached the bottom line, I took a floppy from the drawer. Typing with a steady hand, I then invoked the SAVE command, And waited for the disk to store, Only this and nothing more. Deep into the monitor peering, long I sat there wond'ring, fearing, Doubting, while the disk kept churning, turning yet to churn some more. "Save!" I said, "You cursed mother! Save my data from before!" One thing did the phosphorous answer, only this and nothing more, Just "Choose Abort, Retry, Ignore?" Was this some occult illusion? Some maniacal intrusion? These were choices undesired, ones I'd never faced before. Carefully, I weighed the choices, as the disk made impish noises, The cursor flashed, insistent, waiting, baiting me to type some more, Clearly I must press a key, choosing one and nothing more, From "Choose Abort, Retry, Ignore?" With my fingers pale and trembling slowly toward the keyboard bending, Longing for a happy ending, hoping all would be restored, Praying for some guarantee, timidly I pressed a key, But on the screen there still persisted, words appearing as before, Ghastly, grim, they blinked and taunted, haunted, as my patience wore, Saying "Choose Abort, Retry, Ignore?" I tried to catch the chips off-guard. I pressed again, but twice as hard I pleaded with the cursed machine. I begged and cried and then I swore. Now in desperation, trying random combinations, Still there came the incantation, just as senseless as before. Cursor blinking, angrily winking, blinking nonsense as before. Reading "Choose Abort, Retry, Ignore?" There I sat distraught, exhausted, by my own machine accosted, Getting up I turned away and paced across the office floor. And then I saw a dreadful sight; a lightning bolt cut through the night, a gasp of horror overtook me, shook me to my very core, The lightning zapped my previous data, lost and gone forevermore. Not even "Choose, Abort, Retry, Ignore?" To this day I do not know the place to which lost data goes, What demonic nether world is wrought where data will be stored, Beyond the reach of mortal souls, beyond the ether into black holes, But sure as there's C, Pascal, Lotus, Ashton-Tate and more, You will one day be left to wander, lost on some Plutonian shore, To "Choose, Abort, Retry, Ignore?" 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@ganssle.com. To subscribe, send a message to majordomo@ganssle.com, with the words "subscribe embedded email-address" in the body. To unsubscribe, change the message to "unsubscribe embedded email-address". BUT - please use YOUR email address in place of "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 ------------------------------------------------------------ Embedded Muse 37 Copyright 1999 TGG September 13, 1999 ------------------------------------------------------------ You may redistribute this newsletter for noncommercial purposes. For commercial use contact info@ganssle.com. EDITOR: Jack Ganssle, jack@ganssle.com CONTENTS: - Embedded Seminars in Chicago and Boston - Book Review - Write Only Memory - Thought for the Week - About The Embedded Muse Embedded Seminars in Chicago and Boston --------------------------------------- I'll present the seminar "The Best Ideas for Developing Better Firmware Faster" in Chicago and Boston on November 8 and 9, 1999. 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. If you're interested reserve early as these seminars fill completely. For more information check out http://www.ganssle.com or email info@ganssle.com. A lot of folks have asked me to bring this seminar to their company. Email me at jack@ganssle.com if you're interested. Book Review ----------- An excellent new book, "An Embedded Software Primer", by David E. Simon (1999, Addison, Wesley, ISBN 0-201-61653-X) came across my desk this month. Embedded titles are becoming more common - not so long ago ANYTHING embedded was worthy of attention - but this book is a standout. It's aimed at the novice or nearly novice embedded person, one with experience in C but little feel for the unique issues of embedded systems. The book starts with the standard introduction to microprocessor hardware (which could have been left out), but quickly moves on to a very good description of interrupts; this section alone is quite worthwhile. Three of the 11 chapters are devoted to real time operating systems. The included CD has a copy of the older version of Jean LaBrosse's uC/OS RTOS. Whether you use uC/OS or a commercial product, Mr. Simon's discussion of RTOS issues is a very good introduction to the subject. If you've never used an RTOS, this is a pretty good reference (but also check out MicroC/OS-II, LaBrosse's new companion volume to his upgraded RTOS). If you're trying to figure out what firmware is all about, and get a sense of how one should write code, this book is for you. Write Only Memory Many years ago Signetics issued a data sheet for their "write only memory" (think about it!), a device appropriately introduced on April fools' day. It's an amazing part, which requires the normal 5 volt power as well as 6.3 volts AC (for the filaments), and whose reliability is shown as a function of what customers pay for it. Years ago I had the datasheet posted on another web site. Quite a few folks have written and asked for a link to that site, which is now defunct. So it's now back on-line, at http:\\www.ganssle.com. Follow the link under "Articles About Embedded Systems". Thought for the Week -------------------- YESTERDAY Yesterday, All those backups seemed a waste of pay. Now my database has gone away. Oh I believe in yesterday. Suddenly, There's not half the files there used to be, And there's a milestone hanging over me The system crashed so suddenly. I pushed something wrong What it was I could not say. Now all my data's gone and I long for yesterday-ay-ay-ay. Yesterday, The need for back-ups seemed so far away. I knew my data was all here to stay, Now I believe in yesterday. 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@ganssle.com. To subscribe, send a message to majordomo@ganssle.com, with the words "subscribe embedded email-address" in the body. To unsubscribe, change the message to "unsubscribe embedded email-address". BUT - please use YOUR email address in place of "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 ------------------------------------------------------------ Embedded Muse 36 Copyright 1999 TGG August 24, 1999 ------------------------------------------------------------ You may redistribute this newsletter for noncommercial purposes. For commercial use contact info@ganssle.com. EDITOR: Jack Ganssle, jack@ganssle.com CONTENTS: - Editor's Notes - Virus warning - Optimists, Pessimists and Engineers - Microsoft To Sell Ad Space In Error Messages - About The Embedded Muse Editor's Notes -------------- Thanks to the many Embedded Muse readers who inquired about the state of this e-newsletter. The Muse took a sabbatical while I was off sailing for the last couple of months. Mark your calendars for the upcoming Embedded Systems Conferences in California and Holland. San Jose hosts the biggest of all embedded shows September 26-30. The European show now has a new venue in Maastricht, from November 16-18. I'll be at both shows and look forward to meeting many of you there. Virus Warning ------------- There is a new virus going around, called "work". If you receive any sort of "work" at all, whether via email, Internet or simply handed to you by a colleague...DO NOT OPEN IT! This has been circulating around for months and those who have been tempted to open "work" or even look at "work" have found that their social life is deleted and their brain ceases to function properly. If you do encounter "work" via email or are faced with any "work" at all, then to purge the virus, send an email to your boss with the words "I've had enough work... I'm off to the pub." If you receive "work" in paper-document form, simply lift the document and drag the "work" to your garbage can. Put on your hat and coat and skip to the nearest bar with two friends and order three pints of Guinness. After repeating this action 14 times, you will find that "work" will no longer be of any relevance to you and that "Scooby Doo" is still the greatest cartoon ever! Send this message to everyone in your address book. If you do NOT have anyone in your address book, then I'm afraid the "work" virus has already corrupted your life. Optimists, Pessimists and Engineers ----------------------------------- To the optimist, the glass is half full. To the pessimist, the glass is half empty. To the engineer, the glass is twice as big as it needs to be. Microsoft To Sell Ad Space In Error Messages -------------------------------------------- Microsoft (Nasdaq: MSFT) announced that it is selling advertising space in the error messages that appear in Windows. Acknowledging for the first time that the average user of their operating system encounters error messages at least several times a day, Microsoft is trying to take financial advantage of the unavoidable opportunity to make an ad impression. "We estimate that throughout the world at any given moment several million people are getting a 'General Protection Fault' or 'Illegal Operation' warning. We will be able to generate significant revenue by including a short advertising message along with it," said Microsoft marketing director Nathan Mirror. He also mentioned that Microsoft is intending to add banner ads into its Blue Screen of Death in the near future. The Justice Department immediately indicated that they intend to investigate whether Microsoft is gaining an unfair advantage in reaching the public with this advertising by virtue of its semi-monopolistic control over error messages. 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@ganssle.com. To subscribe, send a message to majordomo@ganssle.com, with the words "subscribe embedded email-address" in the body. To unsubscribe, change the message to "unsubscribe embedded email-address". BUT - please use YOUR email address in place of "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 ------------------------------------------------------------ Embedded Muse 35 Copyright 1999 TGG April 27, 1999 ------------------------------------------------------------ You may redistribute this newsletter for noncommercial purposes. For commercial use contact info@ganssle.com. EDITOR: Jack Ganssle, jack@ganssle.com CONTENTS: - Embedded Seminar in Baltimore/DC - Book Review - Thought for the Week - About The Embedded Muse Embedded Seminar in Baltimore/DC -------------------------------- I'll present the seminar "The Best Ideas for Developing Better Firmware Faster" in the Baltimore/DC area on May 12, 1999. 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. If you're interested reserve early as these seminars fill completely. For more information check out http://www.ganssle.com or email info@ganssle.com. A lot of folks have asked me to bring this seminar to their company. Email me at jack@ganssle.com if you're interested. Book Review ----------- Here's an older book, copyright 1988, yet one whose ideas are timeless: "Principles of Software Engineering Management", by Tom Gilb (ISBN 0-201-19246-2, The Bath Press, Avon). One quote that shows some of the book's tenor follows a discussion about beating deadline pressure. Gilb's partial solution is to decline responsibility - in writing - for impossible deadlines. Now, we know management will often go right ahead and impose the schedule anyway. He says "If this diplomatic attempt to avoid responsibility doesn't work, don't worry. The project is sure to be late, or there will be some kind of disaster. You can then prove that you were wise enough to disclaim responsibility in advance. If, by some miracle everything succeeds, you can safely assume that your disclaimer will be forgotten in the euphoria of success." Gilb shows how evolutionary delivery can help deal with schedule issues, using such aphorisms as the Mountain Goat Principle: Take one step at a time up the slippery mountainside, and make absolutely sure that each hoof is on solid ground before you take the next step. Specification, solution, and risk management are all critical components in the success of any software project, yet in the embedded world these areas just don't get the attention they deserve. A number of chapters give practical "how to" advice. Gilb, famous as an advocate of Inspections, devotes a very succinct and worthwhile chapter to these as well, giving lots of quantitative assessments of how Inspections will get the project out better and faster. If you're having trouble getting people to buy-into the idea of Inspections, this chapter alone makes the book worthwhile. The style is generally readable and often fun, though not as breezy as what we've come to expect from authors like Tom DeMarco. It deserves a place on every embedded developer's desk. Thought for the Week -------------------- Abbott and Costello Meet Windows 95 Costello: Hey, Abbott! Abbot: Yes, Lou? Costello: I just got my first computer. Abbot: That's great Lou. What did you get? Costello: A Pentium II-266, with 40 Megs of RAM, a 2.1 Gig hard drive, and a 24x CD-ROM. Abbot: That's terrific, Lou. Costello: But I don't know what any of it means!! Abbot: You will in time. Costello: That's exactly why I am here to see you. Abbot: Oh? Costello: I heard that you are a real computer expert. Abbot: Well, I don't know- Costello: Yes-sir-ee. You know your stuff. And you're going to train me. Abbot: Really? Costello: Uh huh. And I am here for my first lesson. Abbot: O.K. Lou. What do want to know? Costello: I am having no problem turning it on, but I heard that you should be very careful how you turn it off. Abbot: That's true. Costello: So, here I am working on my new computer and I want to turn it off. What do I do? Abbot: Well, first you press the Start button, and then- Costello: No, I told you, I want to turn it off. Abbot: I know, you press the Start button- Costello: Wait a second. I want to turn it Off. I know how to start it. So tell me what to do. Abbot: I did. Costello: When? Abbot: When I told you to press the Start button. Costello: Why should I press the Start button? Abbot: To shut off the computer. Costello: I press Start to stop. Abbot: Well Start doesn't actually stop the computer. Costello: I knew it! So what do I press? Abbot: Start. Costello: Start what? Abbot: Start button. Costello: Start button to do what? Abbot: Shut down. Costello: You don't have to get rude! Abbot: No, no, no! That's not what I meant. Costello: Then say what you mean. Abbot: To shut down the computer, press- Costello: Don't say, "Start!" Abbot: Then what do you want me to say? Costello: Look, if I want to turn off the computer, I am willing to press the Stop button, the End button and Cease and Desist button, but no one in their right mind presses the Start to Stop. Abbot: But that's what you do. Costello: And you probably Go at Stop signs, and Stop at green lights. Abbot: Don't be ridiculous. Costello: I'M being ridiculous? Well. I think it's about time we started this conversation. Abbot: What are you talking about? Costello: I am starting this conversation right now. Good-bye. 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@ganssle.com. To subscribe, send a message to majordomo@ganssle.com, with the words "subscribe embedded email-address" in the body. To unsubscribe, change the message to "unsubscribe embedded email-address". BUT - please use YOUR email address in place of "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 ------------------------------------------------------------ Embedded Muse 34 Copyright 1999 TGG April 13, 1999 ------------------------------------------------------------ You may redistribute this newsletter for noncommercial purposes. For commercial use contact info@ganssle.com. EDITOR: Jack Ganssle, jack@ganssle.com CONTENTS: - Embedded Seminar in Baltimore/DC - Programming Resources on the Net - Thought for the Week - About The Embedded Muse Embedded Seminar in Baltimore/DC -------------------------------- I'll present the seminar "The Best Ideas for Developing Better Firmware Faster" in the Baltimore/DC area on May 12, 1999. 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. If you're interested reserve early as these seminars fill completely. For more information check out http://www.ganssle.com or email info@ganssle.com. A lot of folks have asked me to bring this seminar to their company. Email me at jack@ganssle.com if you're interested. Programming Resources on the Net - Take 2 ----------------------------------------- In the last issue I gave some links to code and other resources available on the net, as I feel we're all busily re-inventing the wheel. Several readers came back with additional links. Here they are, and thanks everyone! (Note: the entire set of the links are at http://www.ganssle.com/links.html). From Fred Cady: http://www.geocities.com/ResearchTriangle/1495/ - The EE Compendium: Home of Electrical Engineering and Embedded System Programming http://www.ezl.com/~rsch/ - Roger's Embedded Microcontrollers Home Page http://www.troubleshooters.com - Lots of neat hints about debugging systems http://www.ultracad.com/tech.htm - App notes for creating circuit boards for high speed systems http://www.sigcon.com - This is Dr. Howard Johnson's home page. High-speed Digital Design, a Handbook of Black Magic. On the site you can sign up for his email newsletter (Editor's note: this is the best book ever on high speed design) http://www.eg3.com/index.html - EG3 provides information on embedded, realtime, DSP (digital signal processing), Board-level (PC/104, VME, STD, CompactPCI) http://www.realtime-engineering.com/ - Articles and information on real-time systems http://www.pc104-embedded-solns.com/ - Embedded Solutions Magazine - PC/104 embedded systems http://www.microcontroller.com - "Resources for the Professional Embedded Developer" site features links and information on everything from cores to development tools. You'll also find downloads for freeware/shareware, links to conferences and, of course, your favorite engineering comedian: Dilbert. From Andre Felipe Machado: http://www.geocities.com/ResearchTriangle/Forum/1353/ - A retargettable compiler http://mazsola.iit.uni-miskolc.hu/~drdani/embedded/ - A simulator for 51 and another compiler From Daniel Mathieu: http://www.wotsit.org/ - This site contains ***file format information on hundreds of different file types** and all sorts of other useful programming information; algorithms, source code, specifications, etc. From Thomas Niemann: http://members.xoom.com/thomasn/s_man.htm - Sorting and searching algorithms. From Sara Killingsworth: sourceware.cygnus.com - All sorts of programming resources from the GNU folks. Thought for the Week -------------------- 5 surgeons are taking a coffee break... 1st surgeon says: "Accountants are the best to operate on because when you open them up, everything inside is numbered." 2nd surgeon says: "Nah, librarians are the best. Everything inside them is in alphabetical order." 3rd responds: "Try electricians, man! Everything inside THEM is color coded." 4th intercedes: "I prefer lawyers. They're heartless, spineless, gutless and their heads and their butts are interchangeable." To which the 5th surgeon, who has been quietly listening to the conversation, says: "I like engineers... they always understand when you have a few parts left over at the end." 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@ganssle.com. To subscribe, send a message to majordomo@ganssle.com, with the words "subscribe embedded email-address" in the body. To unsubscribe, change the message to "unsubscribe embedded email-address". BUT - please use YOUR email address in place of "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 ------------------------------------------------------------ Embedded Muse 33 Copyright 1999 TGG April 1, 1999 ------------------------------------------------------------ You may redistribute this newsletter for noncommercial purposes. For commercial use contact info@ganssle.com. EDITOR: Jack Ganssle, jack@ganssle.com CONTENTS: - Embedded Seminar in Baltimore/DC - Programming Resources on the Net - Thought for the Week - About The Embedded Muse Embedded Seminar in Baltimore/DC -------------------------------- I'll present the seminar "The Best Ideas for Developing Better Firmware Faster" in the Baltimore/DC area on May 12, 1999. 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. If you're interested reserve early as these seminars fill completely. For more information check out http://www.ganssle.com or email info@ganssle.com. A lot of folks have asked me to bring this seminar to their company. Email me at jack@ganssle.com if you're interested. Programming Resources on the Net -------------------------------- One of the most frustrating, silly things we all engage in is re-inventing the wheel. Often we just do not know that others have written an application or algorithm we need, so wind up recoding it ourselves. Worse are the times when we just KNOW that the code must exist out there somewhere! So, I'm collecting links to sites that contain code and algorithms. Here are a number of interesting links; but send me your favorites as well, and I'll pass them along to readers. http://www.embedded.com - Embedded Systems Programming http://www.ddj.com - DR Dobb's Journal http://www.cuj.com - C Users Journal http://www.snippets.org - A great collection of code and routines. You MUST check this out. http://www.mibsoftware.com/reuse/ - The Reuse RKT. This site has over 3000 of the most popular open source and reusable software items along with functions, libraries, FAQs, and references. You MUST check this out. http://www.trumphurst.com/cpplibsx.html - A List of C++ Libraries available on the web. http://www.halcyon.com/cliffg/uwteach/index.html - Cliff's Teaching Info and Technical Resources http://www.cs.rpi.edu/~musser/stl.html - STL source and info http://netlib.bell-labs.com/netlib/master/readme.html - A repository of mathematical software, data, documents, and other useful items. http://lib.stat.cmu.edu/ - StatLib, statistical software and datasets. http://zeus.enst-bretagne.fr/Services/How_to_find_sources.html - How to find source code via the internet FAQ Thought for the Week -------------------- EXPERTS WARN OF THREAT FROM 100GigaBurg BUG Experts warned today of a new and deadly threat to our beleaguered civilization: the 100GB Bug. As most people know, McDonald's restaurant signs show the number of hamburgers the giant chain has sold. That number now stands at 99 billion burgers, or 99 Gigaburgers (GB). Within months or even weeks, that number will roll over to 100GB. McDonald's signs, however, were designed years ago, when the prospect of selling one hundred billion hamburgers seemed unthinkably remote. So the signs have only two decimal places. This means that, after the sale of the 100 billionth burger, McDonald's signs will read "00 Billion Burgers Sold." This, experts predict, will convince the public that, in over thirty years, no McDonald's hamburgers have ever in fact been sold, causing a complete collapse of consumer confidence in McDonald's products. The ensuing catastrophic drop in sales is seen as almost certain to force the company into bankruptcy. This, in turn, will push the teetering American economy over the brink, which, finally, will complete the total devastation of the global economy, ending civilization as we know it, and forcing us all to live on beetles. "The people who know -- the sign-makers -- are really scared of 100GB," one expert said. "I don't know about you, but I'm digging up a copy of THE FIELD GUIDE TO NORTH AMERICAN INSECTS and heading for the hills." 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@ganssle.com. To subscribe, send a message to majordomo@ganssle.com, with the words "subscribe embedded email-address" in the body. To unsubscribe, change the message to "unsubscribe embedded email-address". BUT - please use YOUR email address in place of "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 ------------------------------------------------------------ Embedded Muse 32 Copyright 1999 TGG February 1, 1999 ------------------------------------------------------------ You may redistribute this newsletter for noncommercial purposes. For commercial use contact info@ganssle.com. EDITOR: Jack Ganssle, jack@ganssle.com CONTENTS: - Embedded Seminar in San Jose - The Trouble with Open Source (again!) - Thought for the Week - About The Embedded Muse Embedded Seminar in San Jose ---------------------------- I'll present the seminar "The Best Ideas for Developing Better Firmware Faster" in San Jose on February 18, 1999. 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. If you're interested reserve early as these seminars fill completely. For more information check out http://www.ganssle.com or email info@ganssle.com. The Trouble with Open Source ---------------------------- Last issue I went off about issues I have with the "open source" movement, generating a staggering volume of replies. Several folks asked if the article was a troll, an attempt to get folks riled up. Well, *of course* it was a troll - there's nothing more fun than hearing strong opinions from smart people... though that doesn't mean I don't think that some of the reasoning used for distributing source code is flawed. Others accused me of being a Microsoft stooge, which is funny since my Windows 95 machine crashed three times in reading these emails! Of the respondents, about a third agreed with me; two thirds were firmly at odds. There was no middle ground. Many people made a number of very good points. To summarize the most common threads: - Few developers trust the vendors. As one reader put it "I feel better trusting part-time hobbyists than the vendor to get it right." - No one forces you to modify the source, so there's no downside to having it. - Open source means you can port the code to another CPU or platform. - The code from vendors is buggy. Developers need the code to fix it. One reader mentioned that 90% of coding time is debugging, especially with purchased code, so there's a quality Vs source issue. Also, documentation errors often can't be resolved without the source. And so, since it's only fair to give equal time to others, here are some excerpts from readers' comments. All are reprinted with permission of the authors. And thanks to everyone for writing. I wish there was room to share more of people's thoughts. Randy Brei writes: The other day, one of my co-workers was singing the praises of Linux ... and one of (supposed) virtues was that you get all the source code. I'm thinking to myself, "that's the last thing I want to have: zillions of lines of source code". I've written an OS and I've studied a handful of other OSes. I don't want to work on another OS. I just want to be a user. Also, it is not a comforting feeling to me ... knowing that a thousands ... or millions ... of people have been messing about with the source code. I particularly liked Bob Kodner's rephrasing of a Freak Brothers saying: Source and No Money will get you through the hard times better than Money and No Source. Gary Bergstrom said: I'm aware of the trap that many engineers fall into: NIH. and two corollaries: I can do it better & everyone else does it wrong. I try hard to not fall into these. What is important is getting the job done. If it's faster to work on my tools, so be it. If it's not, then I hope that my experience will let me know that before I waste time. Donald Kerns and numerous others said: The engineers get much better "kicks" releasing the "free" LINUX version (just because it's COOL) than the death marched commercial release. John Ford spoke for a lot of readers: I contend that if you rely on a vendor to fix bugs, you're doomed. I have NEVER had a vendor fix anything for me. I have found bugs in VxWorks, Solaris, and Microsoft products. I was never given a fix. I'm waiting right now (2 weeks!) for help on a bug in one of our purchased non-source products. If I had the source, I could fix it myself in a few hours. From Scott Finneran: I do however have a reason for wishing that I had the source to the cross-compiler that we use here. I am working on a project which has been going for about 10 years now (customers just keep asking for more functions... you know the story). Our cross-compiler (status: NO LONGER SUPPORTED) runs under an ancient version of an OS (status: NO LONGER SUPPORTED) on an old underpowered machine (status: NO LONGER SUPPORTED). The answer is obvious... go back to the compiler vendor and get them to port it to the latest version of their OS. Their response to our requests is "that product is no longer supported". As they no longer sell the compiler, we requested the source so that we could port it ourselves. We were willing to sign NDAs and agree to only use it in house. The response: "that product is no longer supported". As we don't have the source to the compiler nor the budget to port our code to a new compiler (a massive effort due to compiler "quirks"), we are stuck. If however we had chosen for example EGCS - the Cygnus supported variant of GCC, we would be in far better shape. We could simply get any qualified contractor (for example Cygnus) to port the compiler to the new platform. Not only that, but we would be getting EXACTLY THE SAME COMPILER on our new blindingly fast platform. This also avoids the other problem of vendors coming back with "we have a new version which runs on your new platform..... their are just a couple of MINOR differences". I guess what I am getting at is, no I don't want to tinker with the guts of my compiler but having the source is an insurance policy against my product outliving the tools that I use to build it. Andrew Mayo wrote: As someone who has been watching the recent emergence of the Open Source movement, I think you have been a little harsh on the idea of access to the source code. While some misguided souls might indeed consider that they can hack into their compiler etc. and improve it, most of us don't want the source code for that reason. Instead (and if you've ever tried to get support through Microsoft, for example, you'll see the point), the availability of Open Source means that support organisations will be able to properly resolve issues in a much more effective way. Suppose you have a bug in your compiler. You ring the support organisation (you are paying either per incident or via a contract, so they get to make some money, of course). The experienced techie at the other end can examine the source code to determine the problem and then either patch it, have you patch it, and/or notify the author(s) so that the next release will have the fix. Whereas with Microsoft, the source code is locked up in Redmond. The support people in Singapore don't have access to it. So most problems take a lot longer to resolve. Would you rather have your bug fixed today or next year? Open Source will clearly result in higher-quality software and quicker release cycles. In addition, access to the source will allow budding programmers to examine work done by professionals (hopefully). I submit that if you look, say, at the source for PGP or Perl, you are looking at quality software developed by experts. You will do well to copy their styles and techniques. Also, here are a million wheels already invented for you so you can just take the routines and re-use them. Want a really good random number generator? A hashing algorithm? A set of B-Tree routines?. Here they are. Oh, and perhaps you'd like something running on another platform. Microsoft might not choose to do that for marketing reasons. For example, Internet Explorer 4 has been ported to Solaris but will we ever see it on Linux?. Not likely, I'd say. But Netscape's browser is publicly available in source form so of course it's already been ported. Open Source is already a concept most embedded systems developers are familiar with, anyway. For example, take the PIC chip. Look at all the stuff Microchip provide on their web site in source form - clearly, this encourages developers to get started quickly. The Open Source movement simply takes this concept to an extreme. Finally you have to look at the cost. With Linux, you could set up an engineering workstation a lot cheaper, spending the money on better design tools etc. Isn't this a good thing, or do you want Mr. Gates to earn even more than he does? Thought for the Week -------------------- See http://www.duh-2000.com for the latest on Y2K. 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@ganssle.com. To subscribe, send a message to majordomo@ganssle.com, with the words "subscribe embedded email-address" in the body. To unsubscribe, change the message to "unsubscribe embedded email-address". BUT - please use YOUR email address in place of "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 ------------------------------------------------------------ Embedded Muse 31 Copyright 1999 TGG January 7, 1999 ------------------------------------------------------------ You may redistribute this newsletter for noncommercial purposes. For commercial use contact info@ganssle.com. EDITOR: Jack Ganssle, jack@ganssle.com CONTENTS: - Embedded Seminar in San Jose - The Trouble with Open Source - Thought for the Week - About The Embedded Muse Embedded Seminar in San Jose ---------------------------- I'll present the seminar "The Best Ideas for Developing Better Firmware Faster" in San Jose on February 18, 1999. 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. If you're interested reserve early as these seminars fill completely. For more information check out http://www.ganssle.com or email info@ganssle.com. The Trouble with Open Source ---------------------------- One of the reputedly great things about a lot of public domain software is that it often comes with the source code. I don't want the source code. What am I going to do with it? Fix bugs? Most of us are far too busy just doing our own work to worry about maintaining someone else's code. I personally have written half a dozen compilers, yet I'd never, in a million years, want to dig into the innards of a freebie compiler to find some obscure optimization bug, or into an OS to figure out why context switches corrupt registers. No way. 80% of all embedded systems are delivered late. If we figure that maintaining public domain software is now another required part of developing our own systems, well, disaster looms. Now, the argument that open source means lots of people - *other* people - are correcting bugs is certainly valid. Just don't let it be me, or anyone else concerned with getting a product to market on time. A healthy software world means we buy development products for cold hard cash. That money goes into other developers' pockets; part of the service they provide is a useful support group that efficiently deals with bugs. Admittedly many commercial products don't live up to this ideal. I'm convinced, though, that as long as we're all mucking around in each others' code the software crisis will never go away. This philosophy goes to modules that we include in our own products, like communications packages and real time OSes. Yeah, a lot of these off-the-shelf products are less than perfect. But as long as we demand access to the source we'll never be truly productive developers. Fact: Time to market pressures grow daily; it's almost impossible to get a product out the door on-time. Fact: Buggy tools and software packages are schedule-killers. Fact (well, at least this is my contention): If we are forced to maintain our tools we're doomed. Too many developers have bought into the "I can fix it" school of thought for dealing with the reality of poor tools. Better solutions exist. GNU tools show the yin and yang of the "open source" model. Sure, you can download all of the GNU source and build your own compilers. Better, send Cygnus some money. Let them provide you with the tools, and then you get to hold them responsible for maintaining the products. Cygnus has leveraged the best of open source while still providing support. Another option might be better communication between developers. If the problem is that people don't trust commercial products, perhaps we need a repository for success and failure stories. A registry of tools versus real developer experiences. One sailing magazine tracks hundreds of boats and their owners, so that a prospective buyer can contact a dozen or more owners to get the real scoop on the product. I'd like to see something similar for commercial products so we can get a vendor-independent, real "in the trenches" view of how well a particular product stands up in real use. But don't give me the source code. I want to go home at nights. Thought for the Week -------------------- News Release January 4, 1999 Redmond, Washington Bill Gates, Chairman and CEO of Microsoft Corporation, announced today that the latest version of their Windows operating system, Windows 2000, would be delayed until the second quarter of 1901. No reason was given. 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@ganssle.com. To subscribe, send a message to majordomo@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. ------------------------------------------------------------------ Jack Ganssle, jack@ganssle.com, (410) 675-1481, fax (410) 675-2245 Showing people how to develop better embedded systems, through seminars, workshops, articles, musings, and humor. See http://www.ganssle.com for seminar and other information.
Back to the top.