Suggestions for Non Volatile Memory

[Noway2]

Here is the second question. For the project I will require some non volatile memory for temporary storage while the unit is unpowered. I designed the board using a Dallas-Maxim part, but it is only a byte wide part. Since just about every device on the system is 16 bits wide and the processor isn't byte addressable, this becomes a real inconvenience. The problem is that in x16 sizing, or with two devices in parallel, Dallas chips get very expensive.

The present device on the board is only 32K x8, but it does have a real time clock which is a plus. If I use a different device, I will need to use a clock chip too, which isn't too big of a deal.

I was wondering if anybody has any suggestions or recommendations for NV ram that they have had a good experience with?

 

[melone]

Can you move to a NOR flash interface?

 

[Noway2]

At the risk of sounding stupid, I don't know what a NOR flash is. I understand the concept of flash memory but I am not up on the different architectures.

Would you be willing to elaborate please?

 

[sreid]

A pretty complete answer here.

http://en.wikipedia.org/wiki/Flash_memory

 

[IRstuff]

If the part has sufficient memory, you could split the access, e.g., lower half for MSB, upper half for LSB, but your design complexity and access times go up.

TTFN

 

[Noway2]

From reading the article, thanks sreid, it looks like NOR flash is what I considered to be standard flash. The block erase associated with flash would probably be an issue, though it was certainly a good suggestion! The problem is that the application will hold a file allocation table and also various datalog readings both of which have some header blocks that are rewritten a lot.

I am also hesitant to go with anything that will require special access handling because the memory chips connect to the processor's external interface very cleanly and the only thing I have to do is make sure the wait states for that address range are within the timing paramaters of the memory.

It looks like TI (not reknown for memory), Maxim, and Simtek (aquired ZMD) make a form of battery backed ram, so the choice is slightly limited.

I also received a suggestion to look at Ramtron, which I understand used to have issues associated with very limited rewrites, that apparently have been solved. It is limited in size, about 32K x8 but a $10 per device is about half the price of the battery memories. I was wondering if anyone has had any experience with these devices?

 

[itsmoked]

I'm pretty surprised to hear you're not using serial flash. That is pretty much the standard now. You can get a truck load of memory in a tiny 8 pin part for next to nothing.

The key is that you only update the memory when it changes.

 

[felixc]

Yeah, unless you have access speed contraints, why wouldn't a serial EEprom do the job?

 

[itsmoked]

This is my first up choice for serial EEPROM.
Many companies have this one.

SPI very easy to use. You can bit bang at 10MHz or use your processor's SPI port.

It has a chip select so you can use multiple ones.

If you're into I2C (yuck) you can get 16bit I think, and 128K X 8

http://ww1.microchip.com/downloads/en/devicedoc/21822e.pdf

 

[Warpspeed]

If you need sixteen bits of high speed access non volatile RAM, why not just double up on the eight bit wide Dallas battery backed parts ?

Anything else will be a lot slower, but bang for your buck and minimal board space, the serial EEPROMs will be hard to beat.

 

[Noway2]

I hadn't really considered a serial eprom because it is really clean to put a device on the parallel bus. With a parallel device, all I have to do in the software is map a pointer or 16 bit array to the device and accessing is a simple read or write statement.

My initial thought was to use two Dallas chips, but I am looking for alternatives that would be less expensive. I hear that Simtek and Ramtron are about 1/3 to 1/4 the price of Dallas_Maxim, though I don't have experience with either of them to personally attest to their reliablity.

Using a serial eeprom is a good suggestion, though.