high speed memory selection MCU

[Vindhyachal.takniki]

1. I have data coming at speed of 4 bytes every 30us. So around 133kHz.
I need to store 10 min of data. So around 80 mega bytes.

2. I am looking for some non volatile memory where I can store it by MCU.

3. I had looked at below memories, but they are max of 2 mega BITS. 

http://www.microchip.com/ParamChartSearch/chart.aspx?branchID=270221&mid=&lang=en
http://www.cypress.com/?id=4984
http://www.cypress.com/?id=4986


4. What else solution can be used or I can use SDHC card only now.

[suicidaleggroll]

There are plenty on digikey/mouser, what kind of interface and package are you looking for?

For example, this one:
http://www.mouser.com/ds/2/380/S70FL01GS-272907.pdf

Is a 1 Gb NOR flash with a SPI interface in BGA-24 or SO-16 for $10 in single quantities.  They have all the way up to 8 Gb with SPI and parallel interfaces.

[that_guy]

If this is a continuous data logging system then definitely do not use an SD card because it will fail very quickly.

[Skimask]

If this is a continuous data logging system then definitely do not use an SD card because it will fail very quickly.

Define "quickly".
And support your argument with hard data.

Throw out some numbers...

Use a 2GB SD card.  Keep it SD vs SDHC for simplicity on the firmware side of things.

4 bytes @ 30us = ~133 1/3 KBPS, call it 150KBPS to keep the math simpler.

10 minutes of 150KBPS = 90 MB, call it 100MB, again, keep the math simple.

2GB card, ~2000MB (maybe the card ain't so great and has bad spots, whatever works).

2000 MB / 100 MB = 20 data dumps before the card is full

20 data dumps * 10 minutes = 200 minutes, simple math, call it 3 hours.

About an average of 100,000 write cycle endurance for a good quality SD card.  Call it 10,000 write cycle endurance, even with wear leveling that most decent SD manufacturers have in there.

10,000 * 3 hours = 30,000 hours = 1250 days of continuous writes/over-writes = ~3.4 years.

How quickly will it fail again?

[suicidaleggroll]

Define "quickly".
And support your argument with hard data.

...

How quickly will it fail again?

I think far too many people buy the absolute CHEAPEST no-name knockoff SD card they can possibly get their hands on, then when it fails after 3 write cycles they blame the entire technology instead of the POS they chose to purchase.  Same goes for USB flash drives.

I only buy Sandisk (u)SD cards, and I've never had one fail.  Some are running operating systems (RPi, gumstix, etc) 24/7, some are just used for data logging in other applications at rates up to 4 GB/day for months/years.  Never a hiccup.

[that_guy]

2000 MB / 100 MB = 20 data dumps before the card is full

Yes indeed, and if he's writing data sequentially a few bytes at a time as it arrives then he's going to suffer from very high write amplification as each operation will perform an erase-program cycle on an entire page, not just the few bytes that are written. If he's able to determine the page size of the NAND in the SD card then he could mitigate this by caching locally until he's able to write out a full page worth of data. Then of course if he's using a file system, probably FAT, there's the additional amplification that goes with the constant modification of the pages holding the cluster chain table.

I would trust the quality manufacturers (Sandisk, Lexar etc) to have thought of this and written smart algorithms to mitigate the effect. The cheapo manufacturers? I doubt it.

[bktemp]

About an average of 100,000 write cycle endurance for a good quality SD card.  Call it 10,000 write cycle endurance, even with wear leveling that most decent SD manufacturers have in there.

100k cylces is for SLC. Modern flash memories use MLC with 10k or even 1k cycles.
Together with the already mentioned write amplification I would expect less than 1k cycles even from a good quality card.
By the way: Avoid the newest and fastest cards for datalogging and better get some old ones with an older and slower flash technology using smaller page sizes.

[Scrts]

There are even more options:
1) Store data into internal memory until a large chunk of data is gathered -> push this buffer to the Flash. This will reduce the number of cycles to RW the Flash.
2) Take a microcontroller with SDRAM interface, hook up 128Mbit RAM and then push even larger portions of data to the SD/MMC/Flash.

[mariush]

I'd go with Flash (128 MB chips are cheap, at about 3-4$, but most require a lot of IO, 16 io for data + rest).

If your microcontroller is powerful enough, and has some amount of RAM, and depending on what kind of data you receive so often, you may want to consider some form of compression. For example, wait until you have 128-512 bytes in ram, then run some run length encoding or some other kind of simple/fast compression.
It would be doable to use some form of interrupt to always receive and queue the new data, while your mcu is compressing or saving data to flash/whatever in the background.

[vaualbus]

133khz high speed? Maybe in the '70...??
i would rather call the thread low speed memory...
though a sd would be fine.