Memory as a Device

Clever use of memory devices can really enhance your products.

Published in Embedded Systems Programming, December 1990

For hints, tricks and ideas about better ways to build embedded systems, subscribe to The Embedded Muse, a free biweekly e-newsletter. No hype, just down to earth embedded talk. 23,000 other engineers subscribe. It takes just a few seconds (all we need is your email address, which is shared with absolutely no one) to subscribe to the Embedded Muse.

In my October column I wrote about eliminating potentiometers from embedded systems, replacing them with smart software to automatically compute calibration values. Tis a noble endeavor, this removal of analog components. But, where do we store the calibration coefficients?

The great attraction of a potentiometer is its ability to "store" an analog value. Once set, it supplies a constant voltage or current whose value is determined by its shaft's position. The value is remembered even when the system is deprived of power for long periods.

Given that most embedded systems don't include classic mass storage devices like disks, we'll have to find some way to save our digital pot equivalent data. Memory is the obvious choice, but data stored in RAM is lost when power is removed.

AT and 386 class machines all include a "setup" program that determines fundamental operating parameters like disk size and configuration. This information is usually stored in conventional low power RAM, whose contents are maintained using a simple battery circuit. When power goes down, the battery takes over.

Most CMOS static RAMs enter an ultra low power standby mode when not selected. Usually, they'll maintain their contents even at 2 to 3 volt Vcc levels, so two or three AA cells gives more than enough voltage to keep the data intact.

There are a lot of battery-backed up systems around. Quite a few suffer from poor design which exhibits itself by occasional data dropouts. This is unforgivable: nobody, but nobody, messes with my data! When my three year old destroyed the dishwasher, I could understand. When he broke the VCR, I figured that, well, he has to learn even at the expense of some electronics. But then he innocently disassembled a floppy disk - that was hard to forgive!

Most designs isolate the RAM's main power supply from the battery circuit using a diode or equivalent transistor circuit. Without the diode, when power is down the battery will be called on to run the entire computer. Silicon diodes have a junction drop equal to around .7 volts. A 5.0 volt supply will be only 4.3 or so when measured on the diode's cathode. While more than enough to retain data, it is less than needed to run the RAM during normal operation. Anything less than 4.75 volts is just too low. Unfortunately, most RAMs will more or less run with Vcc below specification, so these circuits sometimes seem to work; usually, just until 500 production boards are built.

The solution is to use a Shottkey diode. Though slightly more expensive, it only loses .1 volt in the junction. It's a simple, well known solution, but most of the systems we see still use silicon diodes.

The other important ingredient of successful battery backup is a circuit to shut down the processor as soon as power goes below 4.75 volts. A CPU will run wild with low power. Sooner or later, as the power slowly decays it will execute an instruction that wipes out your carefully preserved RAM data.

In fact, battery backup is not always an ideal solution. The batteries are physically big, hard to mount on a circuit board, and must be replaced every so often. Some great lithium batteries with direct PC board mounting are available, and indeed are a good choice when lots of data must be remembered, but a number of other interesting solutions exist.

EPROM

EPROMs get easier to program all the time. Most of us take them for granted, figuring they make great program repositories and nothing else. In some cases, particularly those involving really harsh environments, EPROMs make ideal data storage devices.

In fact, a properly designed circuit can easily program an EPROM. Sure, a 12 volt supply is needed on the Vpp pin, but all other signals are TTL compatible.

While EPROMs are easy to program, erasing them is impossible under program control. Only a heavy dose of UV light will reset all of the programmed bits, so in most cases you can view these chips as write-once memories.

One of our customers sells a single board computer with an on-board Basic language. The only mass storage device is a conventional EPROM connected directly to the data and address bus. It forms a random access read device, and a sequential access write one. In his case, the user saves the Basic code in the EPROM when developing code. Since the EPROM is essentially a write-once media (you can only write zeroes), each successive program save is stored after the previous one. A simple directory structure maintains pointers to each saved program, and to free space after the last.

Incidentally, don't expect any semiconductor memory device to remember forever. A looong time ago, in a galaxy very far away, I wrote an 8008 program for an industrial controller. The 1702 EPROMs were guaranteed to remember for 10 years, which seemed an eternity at the time. Almost exactly a decade later they did forget. Although I was long gone from that company, the customer was hysterical and I agreed to reprogram the 1702s from a brittle paper tape someone miraculously saved. I'm waiting now for February of 1993 when they are due to drop bits once again....

EEPROM

EEPROM stands for Electrically Eraseable Programmable Read Only Memories, quite a mouthful even in our industry of huge monikers. EEPROMs have been used for years in TV sets as channel memories, which explains the strange 83 bit by 1 device found in most data books.

EEPROMs retain their data indefinitely, but can be erased and rewritten at will. They are a sort of hybrid between a static RAM and EPROM, in that the data can be changed fairly easily, but is remembered forever (well, at least for 10 years).

Unlike a RAM, EEPROMs have a limited number of write cycles. After 10,000 to 40,000 writes, the chip will be completely dead and unusable. This, combined with the slow write cycle (many milleseconds), pretty much limits their usefulness to applications where data changes only slowly. Saving the TV channel is one (if you turn the TV on more than 10,000 times, your brain will be so game-show fried it doesn't make any difference how the damn thing powers up). Another is replacement of DIP switches. Assuming there is some alternate way of entering the DIP parameters (like a keypad), then why not eliminate switches wherever possible? Storage of calibration constants is the application that started off this whole discussion, and is a natural use.

EEPROMs are available in all sorts of styles. Obviously, the RAM and ROM-like "by 8" configuration (some number of 8 bit bytes accessed a byte at a time) is quite popular. These parts are almost as easy to use as a RAM. Hardware is needed to prolong the write signal and data, but the only real problem is insuring that the program never runs wild. If it does, a short loop could consume all 10,000 writes in a few seconds.

To my way of thinking, the parts in National's NMC93CSxx family represent a fascinating approach to long term storage of small amounts of data. These 8 pin devices use a serial interface to the computer. A single data bit, with clock and control lines, is all that's needed to interface the chip to a micro.

Scott Rosenthal of Microsol, a Columbia, Maryland hardware/software developer, came up with a fascinating and brilliant use for National's EEPROMs. One of his instruments uses interchangeable optical sensors, each of which requires its own unique set of calibration constants. Users change sensors frequently; in competing instruments each sensor change requires manual entering of several dozen coefficients. Scott, however, puts a little 8 pin EEPROM inside of the sensor's connector. The device is so small the connector's size is unchanged. Now, the calibration stays with the sensor, even if changed between different instruments. A dollar or two of silicon makes Scott's instruments leapfrog the competition's in ease of use.

Another possible application is a digital serial number. Recorded once, it gives your software a constant check on the PC board revision, software version, etc. As an aside, Intel's 386 includes a built-in version number stored in a register on power-up. As systems and chips get more complex, with constant changes and revisions, it is sometimes useful for the software to track the current hardware version.

If your system has a high integration CPU with a spare UART, consider using it to interface to the EEPROM. Or, use a few spare parallel bits and some smart software to control the device. Sure, this is slow, but presumably little data will be transferred, so who cares? In a complex system you can even control it in a background task. Since EEPROMs are synchronous (i.e., you supply the clock), if the task gets preempted the resulting skewing of the software-generated clock will not cause any problems. Actually, the parts all conform to National's Microwire serial protocol, which is supported on all of their COP series of embedded controllers. As I mentioned in another article, serial interfaces are ideal for a number of applications.

National's parts are quite intelligent, and support a number of commands (See the table). All are downloaded, with the data, over the serial link. It is a bit unusual to see a memory with a command set, but in this case there are good reasons to add this small amount of complexity.

Read and write commands needed for simple data transfers are of course supported. Most of the other commands have to do with protecting the contents of the EEPROM. You can prevent writes to the entire device under program control, or to selected parts of it. As we've all learned, painfully, programs can indeed run away, usually causing the maximum amount of damage. It's conceivable that a rogue program could enable write protected access, and then issue a stream of serial commands to trash the data. If you're really paranoid about data loss, consider using the hardware protect pin which takes precedence over all software commands.

Writing code to simulate a UART is really quite trivial. Simulating a real UART for a standard serial link is much harder, since the timing is so critical. By generating the clock signal in the software, all timing constraints are removed. For example, to shift a byte to the EEPROM the code will look like:

	Data_value=byte to shift out
	Loop_count=8		
loop:	Put LSB of Data_value to port
	Set clock pin high
	Set clock pin low
	Shift Data_value right one bit
	Loop_count=Loop_count-1
	Branch to loop if Loop_count <> 0

What could be easier? Troubleshooting this sort of code is easy if you put the send routine in an infinite loop, and then use an oscilloscope to check the timing of the data bits and clock. All embedded software folks should be proficient with a scope, as this sort of application is not uncommon.

Reading data is similar. The code cycles the clock pin up and down, and then reads data from the EEPROM, shifting it into a result register a bit at a time.

Most EEPROM manufacturers have applications notes about their products. National's AN-507 is one of the best for information about software issues.

Flash EPROM

Leave it to Intel to come up with a new EPROM that is neither fish nor fowl. Conventional EPROMs can only be erased by dosing them with UV light. This is a nuisance, and worse, the thermal coefficient of the little quartz window is quite a bit different than that of plastic. That's why EPROMs are always delivered in expensive ceramic packages.

Flash EPROMs can be erased in circuit much like an EEPROM. They are a bit harder to program, as a 12 volt programming source is still needed. Their plastic packages will some day make them cheaper than conventional EPROM. Flash looks to be a technology that will be with us for a long time, as it combine all of the advantages of EPROM with many of those of EEPROM.

Conclusion

Non-volitile storage of data presents a problem for many applications. Look into these new technologies for a solution, but apply a good dose of common sense.

******************************************************
Instruction	Command
READ		Reads data stored in memory
WEN		Write enable
WRITE		Write data (if not protected)
WRALL		Write all registers
WDS		Disable all programming instructions
PRREAD		Read address in protect register
PRCLEAR		Clear protect register
PRWRITE		Program address into protect register
		to specify which registers to protect
PRDS		One time instruction to lock the protect register
*****************************************************

Table: NMC93CSxx Instructions