For novel ideas about building embedded systems (both hardware and firmware), join the 27,000+ engineers who subscribe to The Embedded Muse, a free biweekly newsletter. The Muse has no hype and no vendor PR. It takes just a few seconds (just enter your email, which is shared with absolutely no one) to subscribe.
By Jack Ganssle
Using Slow Downloads
So you're leaning back in that uber-recliner facing the 20" monitor, IR keyboard in your lap, editing, compiling, and debugging at warp speed. The nifty 3 Ghz Pentium 4 stuffed with a couple of gig of RAM and enough disk to hold every recipe about to spew forth from Martha Stewart's cell screams through compilations and links. A quick alt-tab to the debugger window and a single button press starts the download.
But then you wait. And wait some more.
In the good old days when in-circuit emulators reigned supreme vendors competed on ultra-fast downloads. 64kbps went to 128 and then 1mbps and beyond. It wasn't long before we expected nearly instantaneous transfers. But today most developers use a JTAG or BDM debugger, a serial device with sometimes pathetically slow download speeds. Worse, even the zippiest protocols collapse to a glacial pace when writing to Flash memory.
So what do you do while waiting for the tool? Click over to Slashdot? Search for those Paris Hilton pictures? Send angry emails to your boss through an anonymizer?
One friend does jumping jacks.
I can tell when things are going badly for him. He buffs up. Large projects with lots of bugs and thus plenty of fixes and resultant downloads morphs his usual skinny frame into a figure more like a governor of a large Western state than that of a typical nerd.
Buried in a hole of a lab with no windows - other than those supplied by Microsoft -a sickly fluorescent-light pallor, inch-thick glasses sliding down a narrow nose, at 56 years old "Bob" felt that first scary chest twinge. It wasn't a heart attack, but after presenting a clean cardiovascular bill of health the doctor admonished him to cut the cholesterol and above all to get some exercise. "Exercise?" he wondered, "is there a pill for that?"
Global competition means Bob spends far too many hours hunched over the keyboard. A 90 minute commute followed by that first desperately needed cocktail leave neither time nor incentive for any sort of workout.
But he figures any problem has an engineering solution. Doing jumping jacks during those wasted downloading minutes reduces stress and keeps him healthy.
I was thinking about this (instead of doing jumping jacks) and realized:
Clearly this formula tells us that big buggy code == buffer. But "buffer" doesn't mean that thing malloc() allocates from the heap.
Suppose we wish to optimize variable exercise (we are engineers, after all, and wish to improve, well, everything). Various sources (http://www.fitness2live.com.au/default.asp?pg=fitnesszone&spg=newsdisplay&articleid=5785) suggest 60 minutes a day. Transforming equation 1:
Atmel's AT29C256 (http://www.atmel.com/dyn/resources/prod_documents/DOC0046.PDF) programs about 6400 bytes/sec. I'll assume that most JTAG tools are pretty fast and this 150 usec/byte is the limiting speed factor. The following chart shows how many downloads per day we need to achieve 60 minutes of exercise and those killer abs:
The data is stark. Early in the project before there's much code seed your programs with bugs. Lots of bugs. Taper off as the project grows. If you don't, if you maintain a fixed bug rate, not only with the project be hideously late, you'll get the grotesque shape of those monsters that adorn the covers of bodybuilding magazines.
Managers beware. Hire only the weak and infirm. Ultrafit programmers write lousy code.
(Full disclosure notice: "Bob" exists and does do jumping jacks during downloads. I've played with the facts of his description a bit).