When to use SRAM, SD Card, SPI flash, and EEPROM?
groggory
Posts: 205
Ok, here are my ideas on the three major types of external data storage that we use on this platform. Please chime in and tell me when it's right...
SRAM - When you essentially need more HUB memory add SRAM. Alternatively, if you have large pre-compiled programs that would not otherwise be loadable, load them into SRAM. So let's say I wanted to make a GIANT array of longs and wanted to be able to access that array from any of my cogs. The HUB memory would be a great use for this as long as it were enough. If it weren't enough then SRAM would be a great way to make this happen. Of course, you could potentially treat SRAM as external RAM dedicated to a cog ... but it is really accessible through any of the cogs. :-/ Please fill me in more on how this works. I've never used SRAM but am trying to wrap my head around how to use it. It is addressable by memory address pointers. Price - $1.62 / 256 kbit
SD Card - You cannot access this directly by memory address pointers. You need to use some sort of file system for this. Most people who use the SD card are using a version of the FAT16 file system. This is relatively fast, can write to one file at a time (but can have multiple 'open' files). You can read files from this directly on a windows computer. SD drive is a bit heavy because there is a fair amount of overhead to access and write to it. Price - $5/ 2GB + $4/ Socket
SPI Flash - Has an onboard memory controller so you can treat it like SRAM. Takes numerous clock cycles to read and write to (unlike SRAM), but for all intents and purposes can be used in lieu of SRAM...it just isn't as fast. What you lose in speed you make up for in storage per dollar. It is easy to use, inexpensive, and relatively large.
Price - $1.12/ 4 megabyte
EEPROM - This is what the propeller expects to pull from in terms of booting. You can only read from one page of memory at a time, so for large storage applications EEPROMs are a pain in the butt. Also, you can only write to them so many times before they start wearing out. They are not good for repeated mass storage, but they are good for storing of variables or settings at boot-time. Inexpensive but useful. It seems to me that if you are planning to use FLASH memory that an additional 'storage' EEPROM would just be frivilous. Price 512kbyte/$1.28 or 1megabyte/ $2.88
SRAM - When you essentially need more HUB memory add SRAM. Alternatively, if you have large pre-compiled programs that would not otherwise be loadable, load them into SRAM. So let's say I wanted to make a GIANT array of longs and wanted to be able to access that array from any of my cogs. The HUB memory would be a great use for this as long as it were enough. If it weren't enough then SRAM would be a great way to make this happen. Of course, you could potentially treat SRAM as external RAM dedicated to a cog ... but it is really accessible through any of the cogs. :-/ Please fill me in more on how this works. I've never used SRAM but am trying to wrap my head around how to use it. It is addressable by memory address pointers. Price - $1.62 / 256 kbit
SD Card - You cannot access this directly by memory address pointers. You need to use some sort of file system for this. Most people who use the SD card are using a version of the FAT16 file system. This is relatively fast, can write to one file at a time (but can have multiple 'open' files). You can read files from this directly on a windows computer. SD drive is a bit heavy because there is a fair amount of overhead to access and write to it. Price - $5/ 2GB + $4/ Socket
SPI Flash - Has an onboard memory controller so you can treat it like SRAM. Takes numerous clock cycles to read and write to (unlike SRAM), but for all intents and purposes can be used in lieu of SRAM...it just isn't as fast. What you lose in speed you make up for in storage per dollar. It is easy to use, inexpensive, and relatively large.
Price - $1.12/ 4 megabyte
EEPROM - This is what the propeller expects to pull from in terms of booting. You can only read from one page of memory at a time, so for large storage applications EEPROMs are a pain in the butt. Also, you can only write to them so many times before they start wearing out. They are not good for repeated mass storage, but they are good for storing of variables or settings at boot-time. Inexpensive but useful. It seems to me that if you are planning to use FLASH memory that an additional 'storage' EEPROM would just be frivilous. Price 512kbyte/$1.28 or 1megabyte/ $2.88
Comments
Catalina C supports several board types and is functional.
Zog C supports C3 and SDRAM and is functional.
BigSpin targets different hardware, but it is in early prototype stage with SDRAM, and others.
PropellerJVM can run Javelin programs stored in EEPROM.
There are others ....
There is no external memory that is directly addressable; all external memory uses I/O to communicate with the Prop.
SPI memory normally uses 4 prop pins, and the address has to be shifted out serially.
Parallel ram needs the address supplied however it is implemented.
Prices vary depending on type/size of memory, it is not as simple as $1.62/256kbits (32KB)
You can address it 512 byte block at a time, you do not need a file system. Prices vary.
Just as fast for read as SPI ram, slower for write.
There is a limit on how many times a sector can be erased.
Prices vary. SD cards are much cheaper, and take care of "wear levelling" for you.
One EEPROM is needed to boot.
Takes approx. 10x longer to wear out than FLASH.
I2C version is MUCH slower for reads than ram or flash.
"You need to use some sort of file system for this" - this is not true. It's only desirable to use FAT16 or 32 because then you can simply put the card into an SD card reader and copy stuff from and to the card with a PC. If you don't need that, you can live without a filesystem.
I wrote some addon functions for FSRW which access one big file by simple address pointers inside of the file. So, it's a mixture - it is a regular FAT file, but when accessing it the functions no longer care about FAT. It simply reads/writes in 512 byte sectors. By the way the functions support up to 4 files (full access) plus the original FSRW functions can deal with an open file at the same time.
Not quite. Flash ram wears out as it has a limited number of writes. EEPROM and SD memory also wears out.
SRAM never wears out.
But SRAM loses its memory when you power off. Flash/SD/EEPROM keep their memory when powered off.
Choose the one that fits your application.
SRAM - serial is like you say, $1.62 per 256kilobit. You could also use parallel SRAM - faster and price is about $3 for 4 megabits.
That is an intriguing idea. You could put an sram driver in a cog and that would use a certain percentage of the cogs memory. Maybe 10 to 20%?
You could also have a dedicated cog doing external sram access, and talk to that cog from other cogs via hub ram. Request a byte from this address etc.
I don't think either of these have been coded but they could be. They only increase data storage space though, not code space.
The third option does increase code space and data spacefor a cog, and is called LMM. This allows huge Pasm programs, hundreds of kilobytes long, but it is slower than standard cog speeds. If you want to know more about this please let us know.
There is no cheap universal solution for adding SRAM. There are many solutions out there offering different compromises, some of which are supported by alternate development environments but none of which are as fast or versatile as Hub RAM.
SPI RAM is fast and lasts forever but is only available in relatively small packages; at 32K per 8-pin DIP you're not expanding by much and you quickly end up having to do something creative to herd CS pins. Bill Henning (who already posted) has a product called FlexMem which is pretty neat, using 4 SPI RAM chips to get 4 times the throughput with a reasonable number of pins.
As others have noted you don't have to use a file system for SD card. In fact, you don't even need one to offload data to a PC; just preformat the card with a large contiguous file, and all you have to tell the Prop is what sector its data starts at. It's very cheap, but does have that block oriented 512 byte at a time thing going. It you start churning blocks it can get very time consuming to access SD.
Don't use SPI flash. Just don't.
EEPROM lasts longer than flash when churned and can be accessed a byte at a time. In some applications this can make up for a lot of the difference between 1 MHz I2C and the 20 MHz SPI speeds. Since the Prop needs EEPROM anyway you can often get 96K for free just by changing out the 32K chip a board came with with a 128K chip. And you can go all the way to 512K without using any more pins. EE does wear out but it takes about a million operations to wear out a bit compared to 10,000 for flash, and you can access it in much smaller blocks than any form of flash so it's not too hard to manage that.
Large EEPROMs have 128 byte pages and it's not too hard to code a driver to automatically re-address when "next byte please" crosses a page boundary.
Originally heater used the SD card directly with no FAT16. You maybe able to find his original code in the thread.
As for SRAM, any cog can access it so you will have to ensure that more than 1 cog does not try this. It is fast but you waste I/O pins for the address. For instance, my RamBlade uses 512KB so 19 pins are address, 8 pins data, 2 pins for control (varies CE, WE, OE depending on config). I then use another pin for CS control of the microSD, which shares the 3 spi pins with the data pins. That leaves 2 pins for communications with another prop. You cannot access both SD and SRAM simultaneously as they share pins.
Your SD socket is overpriced. Try Digikey HR1941CT-ND for an easy to solder by hand smt microSD socket.
I use the SPI flash on the C3 to hold ZOG code and the SPI SRAM to hold the data. This lets me run programs with up to 1mb of code and 64k of data. I don't attempt to put volatile data in flash so I don't expect to have much trouble with wearing out the flash chip. Is that what you are worried about?
Even so, $/byte, parallel ram works out cheaper than serial ram, even when you add the overhead of support chips. (To our original poster, jazzed has a design with 32megabytes of sram)
Re using SPI ram, @David, that is an interesting model using the flash for code and the hub for data. I pondered this recently when looking at a netbook computer running windows. How do they stop all the hard disk thrashing, because since about windows 3.1 there has been a temporary disk file that has been used to emulate the memory (that was going to be cheaper a few years later but wasn't at that point). Either they have rewritten windows, or maybe the netbook is designed to wear out? The perfect inbuilt obsolescence?
Do you have zog code that has been designed to separate code and data memory? (because I'm not sure Spin or C or Basic can do this)
Re localroger I tend to agree with that. $/byte, I think SD works out a lot cheaper than Flash memory. Plus, if ever a card wears out you can replace it. Plus the wear levelling is done internally. Plus, once you get over about a megabyte, it is much quicker to pop out an sd card and put it in a USB reader than it is to download data via a serial port.
SDRAM is essentially free on that scale too.
ZOG can use Flash and SRAM or just SRAM (both with SD Card support) - Good work David Betz!.
While that's a lot better than some of the flash out there that's only good for 10,000 cycles, it's not as much as it sounds like. I develop from the bottom up and so through the entire process I am generally rebuilding every 5 to 10 minutes as I test additions and edits. It would really not be unusual for me to rebuild 100 times a day. For a Forth-like environment where the bottom/built stuff doesn't change that's not a problem, but in most compiled languages making a small change can move everything around.
That means I'd be likely to break the C3 flash limit in about 3 years. That may sound like a lot of use but it really isn't, especially if I have a unit I keep for myself that I use for development of project after project.
I know another programmer who thought "they'll never weigh a million trucks" and stored the truck count for a highway state scale system in an un wear-leveled EEPROM. This was on a very busy stretch of Interstate 12, and they wore the chip out very regularly at about 6 month intervals. The original manufacturer was shrugging and selling them new main boards for $800 when the counter would stop working. When they called us in and I realized the problem could be fixed for $2 by replacing the EEPROM, the state guys were rather upset with our competitor :-)
As for eeprom and flash wearout, it will take a long time. As long as you are aware of the consequences, they are fine to use. For instance, some of the chip manufacturers with inbuilt flash for program memory advise not to send out a "used" development chip. When you do the maths, you really have to do a lot of writes to wear it out.
Andre'
"So, let's actually do stuff that uses it that much before worrying about it
It is good to be mindful of it for a professional application. Also, remember it if you have problems.
However, unless it is a critical operation, or you expect to burn it out, forget about the verify mode.
I recall the modifcation we did on the minis I worked on. We devised a modification to disable the read-after-write-verify mode on the disk drives (10MB $16,000 washing machines for you younger people). The speed gain was quite significant. The errors were next to none, and those probably would have been errors anyway.
The access method and speed is far more important
However, I would agree that it probably wouldn't be a good idea to use the SPI flash for any kind of data logging that is likely to write data to the chip constantly. You can reach 100k quite quickly that way!