I'm a bit limited with just one ram chip. Just storing x,y,z data, I can get 14,221 data set entries before the ram is full. At 5 ms per measurement, in 71 seconds the ram is full.
It's been a long time since I messed around with ram, (perhaps 1978), but is seems with this stuff, we can solder another chip on top of the first one. Just keep CS isolated. I Have 4 ram chips. I guess I could build a ram stack 4 high! Will that work? Will RamDisk work without any discontinuities?
I guess I could build a ram stack 4 high! Will that work?
Not with the current version of RamDisk.
I will soon post a version of RamDisk that supports multiple chips. This will allow you to create one large volume. I am testing with four chips but the design is only limited by the number of pins used for chip selects.
I am also developing a version for 256 KB FRAM chips. Four FRAM chips will have a capacity of 1 MB.
Could use a multiplexer to select the right "chip selects" => 4 lines to select one of 16 memory banks!
I looked at 16 pin 3:8 decoder chips and decided for fewer than eight chips I would directly handle chip select.
For eight or more chips a decoder makes sense. I bought several 74HC138 decoders and may try to get the 16-DIP decoder and eight SRAM chips on a proto shield. For 16 SRAM chips you need a 24 pin DIP decoder so a custom PCB would be nice.
I wouldn't use the chips as staple, that was my first idea as well; look in the thread linked above, there are photos especially in the last post showing the bus system on the back of my PCB. For 5 chips I already use a 74HCT138 3:8 demuxer (had to save pins on the µC - in the end I've still too little left and changed to a bigger STM32F0 / STM32F103, the last ones are very cheap available on eBay for ~6 Euros/8 USD). As I reworked my RAM bank a little, I had 2 outputs left over (one has to be spare in my project for the SPI chip deselect function) that I attached to the SPI bus and Vcc/GND/CS. Now I can add other SPI devices like an SD/Micro-SD-card shield for finally writing the captured data away more permanently.
The speed is quite constant. 5ms per measurement is close to eternity! No need for optimizing the code much. Anyhow, switching to the next chip takes at least 4 additional byte writes, if you prepare the chips for sequential mode before starting the writing. I'm doing that on another µC platform currently (pseudo-code):
P.S.: fat16lib, are there 256kByte FRAM chips publically available? That sounds very interesting! Edit: Nevermind, just found the thread about the prototype.
Thanks for your work on the multiple ram chip library. Right now I have a stack of two ram chips. The examples work great. I'm using RamDiskToSdFat as a basis to load ram data into the SD card. I believe I'm only writing from the first ram chip and not from the second. The max SD file size remains at 125KB. That's what I got with just one ram chip.
Does this code work for multiple chips?
Serial.println(F("Copying ramFile to sdFile"));
int n;
while ((n = ramFile.read(buf, sizeof(buf))) > 0) {
if (sdFile.write(buf, n) != n) {
Serial.println(F("sdFile.write failed"));
return;
}
}
ramFile.close();
sdFile.close();
sd.ls(&Serial, LS_DATE | LS_SIZE);
Serial.println(F("Done"));
The file size stops at 125k. That's just one ram chip of data.
I believe my hardware is working OK. When I use the MultipleChipTest example, I get:
with 1 chip 32,000 numbers
with 2 chip 64640 numbers
when I tell it 3 chips (and have just 2) the data stops at 64512.