Hmmm, why are these so hard to find?

I already have 16megabit SPI serial EEPROMs, cheap enough and they come in a 8pin package.

I'm working on a datalogger app and need similar storage, ie 16Mbit or maybe 32Mbit, but don't want to use EEPROMs as this logger has internal rechargable battery so is never powered down, and I don't want the power and time costs of "saving" data to EEPROM, both of which are significant.

So what I am after is a static RAM that will be permently powered, and draws a handful of uA in standby. That is common enough, but I need it to have serial input so it only uses 3 or 4 input pins, and a small footprint ie 8 pin package preferred.

I checked Microchip as they have a serial static RAM but it is stupidly tiny! Can anyone please suggest a small pin count SPI serial static RAM with a large memory?

Thank you!

 

and I'd be thinking employing mass storage and a USB stick. Added bonus of portability to plug into your analysis software.

 

Weird but the largest chip I could find as serial RAM is only 128K.

Of course, an SD card also has a serial interface and comes in gigabyte sizes.

 

Have you considered SD cards?
http://en.wikipedia.org/wiki/Secure_Digital
Yeah, more pins than you're looking for, but the microSD card is really teensy, and you can interface with them several ways.
[eta]
ErnieM beat me to it...

 

Stupidly expensive, but might fill the bill?, FRAM.

 

Stupidly expensive, but might fill the bill?, FRAM.

Ferroelectric Random Access Memory???

Going to thread a bunch of iron donuts?

 

Ferroelectric Random Access Memory???

Going to thread a bunch of iron donuts?

Correct! but it depends on your appetite.

EDIT: TI (bought out...ooops!) I mean uses Ramtron FRAM, and now you can eat the donuts onboard with a micro..mmmmmm.

 

I had to do a remote data logger once, multiple sensors some distance from the logger, battery operated, rugged conditions, accessible once a year only to retrieve the memory while continuing to log data.

The solution was CF memory cards. Someone had to travel six hours over very rugged terrain to get at the logger and swap memory cards. We did not need a lot of storage but the cheapest we could find were 8MB.

 

Weird but the largest chip I could find as serial RAM is only 128K.
...

Yeah, thanks Ernie that was similar to my experience. I can buy a 16000k or 32000k EEPROM in 8pin but am limited to a 128k RAM in 8 pin. Where's the justice?

Thanks for the suggestion (everybody!) of using SD card or uSD card etc, I have used those in a few apps but this is for a small encapsulated weatherproof logger, and that means no card socket.

I also don't particularly like the reliability of SD cards in a hot environment, or the reliability of cards in general, especially when it could never be replaced. I also didn't want the high energy and time costs of EEPROM or cards; 20mA and XmS etc every 512 bytes.

Currently the best bet looks like the 16Mbit 8pin EEPROM, and I may just have to swallow the annoying current and time costs to save data to EEPROM.

It's a real bummer.

PS. Regarding the FRAM, isn't that just another type of EEPROM that still requires extra current and time for a "programming" cycle? If you know a FRAM that has 16Mbit in 8pin package and doesn't need a programming cycle please speak up.

 

PS. Regarding the FRAM, isn't that just another type of EEPROM that still requires extra current and time for a "programming" cycle? If you know a FRAM that has 16Mbit in 8pin package and doesn't need a programming cycle please speak up.

Here is the data sheet for the Ramtron 2Mb device in an 8 pin package http://www.ramtron.com/files/datasheets/FM25V20_ds.pdf

I'm not in anyway suggesting FRAM fits all your needs. It is an alternative to eeprom, just like the sd card, or flash drive others have mentioned. It is synchronous to the SPI bus, so it is fast, and just so-so on power it looks like from the data sheet. Never used one, but have had a small I2C Ramtron chip in the parts bin for a long time.

 

SRAM needs at least 1mA while EEPROM needs about 20 to 30 mA when writing.
Byte write for large serial flash chips is about 10uS. I have used all of these 3 different technologies myself, and parallel SRAM as well.

What I suggest is to use SRAM as buffer, and write to serial FLASH when it is full.

Digital cameras etc. which do indeed need large RAM, all use 8bit or 16bit parallel chips.

 

Thanks Nickelflipper for the FRAM info, it's interesting but not ideal for this application I think.

Takao, thanks for the input. I have large parallel RAM chips in stock but they are very heavy on pin count, and size too once you stack up enough chips to get Mbytes.

The 16Mbit SPI EEPROMs I have in stock are 15mS 20mA for a write cycle to write 500 bytes, so by your terms "byte write time" is about 30uS. Still it's a bit power hungry for memory that could be low-current Static RAM.

 

Takao, thanks for the input. I have large parallel RAM chips in stock but they are very heavy on pin count, and size too once you stack up enough chips to get Mbytes.

PDIP chips? I have 4-bit SRAM ICs here, SOIC, you would hate them, they need 150mA, while only having 32K x 4 bit.

You can build a bank using serial SRAM, but for as many as you need for 16 Mbits, there is not much current saved anymore.

 

Perhaps an experiment in VHDL is in order -- roll your own SRAM + controller and package it inside a small FPGA with only the necessary pins? Here's some info on the memory controller with VHDL included..

 

To Takao; I have 128kbyte SRAMs here, they are reasonably low power but still high pin count, and multiple packages needed to get 16Mbit.

To Osx-addict; That's a clever suggestion but I don't think it will provide the 16Mbit of RAM needed in a 8pin package!

 

This thread is more that 5 years old, and serial RAM still seems to not be common, but for others who might find this via searching, I'll add my two cents. I do know of two options,

1. HyperRAM with a HyperBus interface, from Cypress (previously Spansion) and recently ISSI, is a pseudo dram in a BGA25 package. It uses a minimum of 11 signals, 8 of which are a dual edged bidirectional data bus, so maximum transfer rates around 200+ MB/sec if you run the clock at 100 Mhz, not too bad for eleven 3.3V signals. These are available on Digikey/Mouser (Cypress part S27KL0641DABHI020). I had Proto Advantage solder a couple onto BGA25 to DIP26 adapter boards, which after I melted the first BGA25 adapter board trying to get the BGA balls to melt, seemed like a way forward.
2. There also are SPI/QSPI interface versions of pseudo dram in a soic-8 package (much more prototype soldering friendly that the BGA25), but they are not available from Digikey/Mouser. The part number is VTI7064MSME from Vilsion. They are available on lcsc.com. The SPI/QSPI interface is way slower than the HyperBus interface, but easier.

Both these devices are 8 MBytes of self refreshing DRAM, and both cost a few dollars. They do have a sleep mode, but since they are DRAM inside, they need to consume power refreshing.

I'm playing with the Cypress part currently, and am seeing if I can gpio port bang an interface from an STM32 and/or AVR microcontroller. I have a couple of the SPI interfaced chips on order, but it may take a month for shipping. The main timing constraint that's not flexible is you can't hold chip select asserted longer that about 4 microseconds, for either part, as that blocks the self refresh too long. This is long enough to read/write bytes via port banging, assuming you directly access the port registers. The Cypress/ISSI docs say the chip is ok with with the clock pausing. Initial tests seems to say it's also ok with erratically timed clock edges, although the docs mention a 5% clock jitter limit, which perhaps doesn't matter if the clock is way slow.

I have some initial code making the HyperRAM work, and it does read/write, but it's all on a ugly breadboard and I'm seeing assorted glitches.This is probably not surprising considering the chip normally runs at 100 Mhz. I have done 10 Mhz signals on a breadboard although I think this has way faster edges. A scope is saying my clock edge risetime is like 100 ns, so the digital timing is likely junk, and reading/writing the data bus does have some timing relationships to the clock edges. I'd make the whole thing just go real slow, except a read/write transaction must complete within 4 uSec. To port bang the interface, you basically have to raise CSEL, test a signal for additional latency (are we in the middle of a refresh), toggle out 6 bytes of cmd/address, toggle out some latency wait clocks, and then read/write the data bytes with a clock toggle per byte, and make sure you never take more than 4 uSec doing this (interrupts will need to be inhibited). The STM32 I'm using seems to have a gpio output square wave limit of 18 Mhz (72 Mhz core). Unless I have some inspiration on how to get a solderless breadboard to have better signal integrity, I'll need to have a little pcb made to get the 11 signals (and too many power pins) connected with better signal integrity between the BGA25 and the uProc (probably starting with a STM32 BluePill module).

I'll put things up on github if it all eventually works well. If not, it was a curious experiment. I have a Cypress PSOC 5 which I might experiment with too, which has the big advantage of Verilog programmable logic, so should be able to run things at much higher speed and with timing accuracy, and with DMA. Seems odd Cypress PSOC's can't talk to Cypress HyperBus memory directly, although the PSOC 5 was likely designed before the Spansion merger.

Jan