SLTF Consulting
Technology with Business Sense

 Home | Bio | Contact Us | Site Map


PC Cards as EPROM replacements remove one last code-development bottleneck

Scott Rosenthal
August, 1996

If you’re like me, the tool budget is always slim. There never seems to be enough money to buy all the "proper" tools for working with each new processor. Still, you must finish the job while keeping within the project's time and money constraints. One of the most insidious drains on precious engineering resources is the time needed to program the target system's EPROMs. Who can adequately express the frustration of having the biggest, fastest PC for software development and then sitting on your hands for 10 min at a time while burning an EPROM? And how often do you go through the "burn and test" cycle on each project? At a dollar or two per minute for an engineer's time, it's not long before hundreds of dollars disappear down the drain while you’re waiting for a device programmer to finish. At my firm this waiting game became so obnoxious that we decided to take a different route—instead of EPROMs we now use PC Cards (also known as PCMCIA cards).

Burn and test

In the old days of the PC, the traditional limiting factor on programmer productivity was host speed. I remember walking away from an XT for as long as half an hour while the FORTRAN compiler crunched my program into an executable. In that environment, who notices a measly 10 min? It's barely enough time to saunter over to the coffee machine and back. Today's PCs are so fast that they’re no longer the main hang-up to programmer productivity. Hence, EPROM programming has stepped forward into the limelight it so richly deserves.

To be fair, manufacturers of chips and device programmers have done their best to keep the pain to a minimum. For example, at one point when chips seemed to be doubling in capacity every other month, programming times quickly climbed to absurd levels, taking as long as 30 min to program one device. To address this problem, manufacturers released improved programming algorithms such as the Quick-Pulse technique. Although these algorithms soon returned programming time to manageable levels by replacing brute force with a combination of statistical and feedback techniques, a lag of a dozen minutes while waiting for an EPROM is a major disruption in a programmer's creative flow.

To address this problem, we turned several years ago to using PCMCIA memory cards—and their predecessors such as Starcard—for updating programs in embedded systems and collecting data. The result of this shift has been an almost complete elimination of EPROM programming and swapping. In addition, knowing that this technique is available has allowed us to tweak our delivered programs to take advantage of it. For example, one of our clients can update a 350k-byte program in his ten instruments in less than a minute using just one memory card. He simply puts the card into the first instrument, flips on the power, waits 2 sec, removes the card and goes on to the next instrument. It couldn't be easier—no need to open cases, no broken wires, no sales people complaining about doing field service, and finally, no more bent EPROM pins!

Some designs, though, don't lend themselves to a PCMCIA connector. Therefore, in the past on these projects we would also burn and test some programs in ROMs. Lately, though, program and data sizes have grown to the point that programming ROMs becomes a serious roadblock. So instead of complaining, I did something about it—I replaced the EPROM during our burn and test cycles with a PC Card.

PC-card ROM

The cards I use are battery-backed SRAM PCMCIA cards. They program quickly and retain data for months—features that make them ideal as EPROM replacements during development. If you look past the PCMCIA packaging, these cards look to the rest of the hardware just like standard static RAM memory or an EPROM. The only real difference is that the access time is 200 nsec instead of maybe 120 nsec for an EPROM.

To use these cards in an embedded system you must first design a jig that allows one of them to plug into a ROM socket. In the first application where we tried this approach, the ROM was a DIP part. To create the jig, one of my people took an old PC board that had a PCMCIA connector paralleled with a DIP ROM socket and used a hacksaw to cut the relevant section out of the board. He next populated the board "segment" with the PCMCIA connector, the connector's active and passive support devices and soldered connecting pins to a DIP socket such that it stuck out the bottom of the board. In use, the jig plugs into the existing ROM socket, and a PCMCIA memory card containing the embedded system's program plugs into the onboard connector to replace the ROM.

Of course, all of this effort is useless if you can't get the program into the memory card to begin with. Sticking the card into a standard PCMCIA slot won't really help for that job. In PC applications, the OS treats the memory card much like a floppy disk. Hence, DOS sticks into the card all types of formatting information, boot records and FAT tables. You simply need a way to poke code into the right memory locations.

One tool we use for this task is a PCMCIA PC Card reader and writer from Steele Creek Technologies Inc (Charlotte, NC (704) 588-1780) that attaches to a PC's parallel port. Taking the software that came with the device, I modified the code so we can write data into the memory card as if it were one very large chip.

A risky way to perform this same task would be to use a PCMCIA slot on a computer or laptop, load the data you want to program into dos debug and copy the data from memory into the card using absolute sector writes. While this technique doesn't require any additional hardware, its cost is potentially far greater. Remember, just once making the mistake of specifying the wrong disk drive could write over parts of your hard-disk's directory, resulting in a complete loss of all the information on the drive! A safer variation is to create a small utility that writes the data file to absolute sectors in the PC Card, but only after verifying that the disk formatting isn't valid.

In hindsight, this technique seems so obvious that I can't imagine somebody isn't manufacturing this kind of adapter. However, PC Cards have made a fundamental change in how we develop products. My process is to compile and link a target program, and within the make file include a line to automatically copy the program to a PCMCIA memory card. Within seconds the transfer is finished, and I get to try my newest programming attempt in the embedded design. No more 10-min coffee breaks! Now the only EPROM I burn is when I’m ready to deliver the project.

This technique works so well around here that I've even made a small PC board (from some scrap cutouts on the board for a different project) that allows us to build jigs without hacksawing apart boards. In addition, to extend the cards’ functionality, I purchased an adapter to allow the jig's DIP connection to plug into a PLCC socket. PE&IN

About Us | What We Do | SSM | MiCOS | Search | Designs | Articles

Copyright © 1998-2014 SLTF Consulting, a division of SLTF Marine LLC. All rights reserved.