Using slow download time - Embedded.com

Using slow download time

Click here for reader response to this article

So you're leaning back in that über-recliner facing the 20-inch monitor, IR keyboard in your lap, editing, compiling, and debugging at warp speed. The nifty 3 gigahertz 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. Then 64kbps went to 128 and then to 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:

Equation 1

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 suggest 60 minutes a day. Transforming equation 1:

Equation 2

Atmel's AT29C256 programs about 6400 bytes/second. I'll assume that most JTAG tools are pretty fast and this 150 microseconds/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 ).

Jack G. Ganssle is a lecturer and consultant on embedded development issues. He conducts seminars on embedded systems and helps companies with their embedded challenges. Contact him at . His website is .

Reader Response


Sounds like some unit testing of the code could save the full download time. Of course, it would be nice if ourtoolset included this capability. Unfortunately, it's the hardware guys that have the neat simulators, likeModelSim. But, we software types could build a small test bench in 'C' and accomplish much of the same thing. Thetest bench would still have to be loaded, but it would be at least an order of magnitude smaller in size, and wouldload much quicker. Then, those long downloads would at least be loading code that had been tested, and the numberof whole system downloads could be a lot fewer.

My favorite download story was in 1976, with my Imsai 8080, an ASR33, and Microsoft Basic. At 10 characters persecond, loading MS Basic into the 4Kbytes of RAM in the Imsai took almost 35 minutes. Unfortunately, just a coupleof errant keystokes could crash the interpreter, and it was time for another download. One of my first projectswas to convert the paper tape into a binary format, and write a new loader program. The binary format loaded inabout 10 minutes. It made life a little more pleasant. I soon had a pair of floppy disks and CP/M, which was muchbetter. I learned 'C' using the BDS 'C' compiler. That was a lot of fun, because a edit-compile-debug cycle couldtake as little at 30 seconds. Things have really changed since then.

– Howard Smith

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.