can you think of anything that you would do on arduino that would use 8Mb of ram ? just trying to get ideas while the pcbs come back from the manufacturer...
wonder how hard it would be to have a single bank of ram shared between 2 arduinos... one having write control and the other read only...
this would be handy if one arduino were using a high end adc say 50ksps writing it to the ram and thats all it did then the other would read from it...
1 Like
tbillion:
can you think of anything that you would do on arduino that would use 8Mb of ram ? just trying to get ideas while the pcbs come back from the manufacturer...
What is the interface?
I have written a FAT file system for EEPROMs(4k .. 64k). I have integrated support for SdFat (SDcards). My next step is to support FLASH W25Q64(8MB), W25Q128 (16MB) SPI (24bit command, 4KB Erase pages).
What is the command set for your module? and how fast is access/write?
I am using this file system in a Mega2560 Ethernet webserver. I am having problems accepting files from Android Phones, the SdFat + my code has an upper speed limit of about 10KB/s. After about 300 to 400KB of uploading pictures, the phone stop sending data. My Server code times out after 60seconds of inactivity. PC's don't have any problem uploading, just slow. I have successfully uploaded using Mozilla, Chrome, and Curl on Window PC's.
But everyone has a Phone!
I had been looking at 23LCxx SPI Ram devices, but they max out at 128KB. (can't hold a 4MB photo!)
Chuck.
the modules i have comming in are FM24C256-G by ramtron. datasheet here >> http://www.ec66.com/market/sheet/FM24C256.pdf interface is i2c, im not looking for all that much super speed plus being one of those lazy noobs (lol, not really) i just dont like spi, you only ger one whole spi master per device. the prototype i am working on right now is the i2c expasion stack for arduinos. along with two more hardware products that are scheuled to hit the market sometime arouns july. after that we begin the spi expansion, but it will be much bigger as more devices run on spi and there are alot fewer "types" of devices for i2c. plus now a days the less wires it has the more people want it. i mean look at sata over IDE or sas over scsi 320. technologically our devices (arduino) are 10 years old but someday we eill have some serious speed in those 2 wires.
that fat file system for EEPROMS sounds awesome, how does it work from a user perspective they see a "volume" and write to it like a drive while the underlying soft ware does all the heavy lifting? that would be amazing because i have a board that is part of the stack that is 4Mbit deep for configurations of the stack, writing them all in one "file" that spans the entire 4 chip array would be wonderful. i havent gotten to looking at sd fat as a library itself but i have been using sd.h that comes with the ide v1.8
the FM24C256 is 256Kbits and has a sister chip that has 512Kbits as well but the draw down is that the 512Kbit chip can have 4 sister chips and the 256 can have 8 on one bus, obviously for our prototype we plan to use a bus switch to control 16 "Channels" of 2Mbit each. like i say i dont have the hardware in my grubby little hands yet but the i2c swithc board has 8 4 channel switches switching 1 arduino bus into 32 i2c buses. so theoretically we are talking a max FRAM size of 32Mbit. and one hell of a pcb cost because i struggled to fit the 8Mbit onto a 10cm x 10cm. stupid thing cost 2x what it cost to make it on shipping. these board houses are brutal on the protype man.
fast is access/write?
256Kbit Ferroelectric Nonvolatile RAM
•
Organized as 32,768 x 8 bits
•
High Endurance 10 Billion (10
10
) Read/Writes
•
45 year Data Retention
•
NoDelay™ Writes
•
Advanced High-Reliability Ferroelectric Process
"Description
The FM24C256 is a 256-kilobit nonvolatile memory
employing an advanced ferroelectric process. A
ferroelectric random access memory or FRAM is
nonvolatile and performs reads and writes like a
RAM. It provides reliable data retention for 45 years
while eliminating the complexities, overhead, and
system level reliability problems caused by
EEPROM and other nonvolatile memories.
The FM24C256 performs write operations at bus
speed. No write delays are incurred. The next bus
cycle may commence immediately without the need
for data polling. In addition, the product offers write
endurance orders of magnitude higher than
EEPROM. Also, FRAM exhibits much lower power
during writes than EEPROM since write operations
do not require an internally elevated power supply
voltage for write circuits.
These capabilities make the FM24C256 ideal for
nonvolatile memory applications requiring frequent
or rapid writes. Examples range from data collection
where the number of write cycles may be critical, to
demanding industrial controls where the long write
time of EEPROM can cause data loss. The
combination of features allows more frequent data
writing with less overhead for the system.
The FM24C256 is available in a 8-pin EIAJ SOIC
package using an industry standard two-wire
protocol. Specifications are guaranteed over an
industrial temperature range of -40°C to +85°C. "
"Unlike other nonvolatile memory technologies,
there is essentially no write delay with FRAM.
Since the read and write access times of the
underlying memory are the same, the user
experiences no delay on the bus. The entire memory
cycle occurs in less time than a single bus clock.
Therefore, any operation including a read or write
can occur immediately following a write.
Acknowledge polling, a technique used with
EEPROMs to determine if a write has completed is
unnecessary and will always return a ready
condition. "
there is no delay with read or write it is proverbially instantaneous 
on a chip leve i assume there is a hardware time frame but to the user an its applications poof nothing. another great thing to these chips is if you have the hard ware to push it we are talking clock speeds of 1MHZ .. it is a truely amazing piece of hardware. 1mhz clockspeed though could probably only be envisioned on a Due, which i dont have + wont be buying for a few more years. 32bit stuff is too much like a real computer for me. i wanna stay down here in 8 and 16bit land
tbillion:
the modules i have comming in are FM24C256-G by ramtron. datasheet here >> http://www.ec66.com/market/sheet/FM24C256.pdf interface is i2c, im not looking for all that much super speed plus being one of those lazy noobs (lol, not really) i just dont like spi, you only ger one whole spi master per device. the prototype i am working on right now is the i2c expasion stack for arduinos. along with two more hardware products that are scheuled to hit the market sometime arouns july. after that we begin the spi expansion, but it will be much bigger as more devices run on spi and there are alot fewer "types" of devices for i2c. plus now a days the less wires it has the more people want it. i mean look at sata over IDE or sas over scsi 320. technologically our devices (arduino) are 10 years old but someday we eill have some serious speed in those 2 wires.that fat file system for EEPROMS sounds awesome, how does it work from a user perspective they see a "volume" and write to it like a drive while the underlying soft ware does all the heavy lifting? that would be amazing because i have a board that is part of the stack that is 4Mbit deep for configurations of the stack, writing them all in one "file" that spans the entire 4 chip array would be wonderful. i havent gotten to looking at sd fat as a library itself but i have been using sd.h that comes with the ide v1.8
the FM24C256 is 256Kbits and has a sister chip that has 512Kbits as well but the draw down is that the 512Kbit chip can have 4 sister chips and the 256 can have 8 on one bus, obviously for our prototype we plan to use a bus switch to control 16 "Channels" of 2Mbit each. like i say i dont have the hardware in my grubby little hands yet but the i2c swithc board has 8 4 channel switches switching 1 arduino bus into 32 i2c buses. so theoretically we are talking a max FRAM size of 32Mbit. and one hell of a pcb cost because i struggled to fit the 8Mbit onto a 10cm x 10cm. stupid thing cost 2x what it cost to make it on shipping. these board houses are brutal on the protype man.
256Kbit Ferroelectric Nonvolatile RAM
•
Organized as 32,768 x 8 bits
•
High Endurance 10 Billion (10
10
) Read/Writes
•
45 year Data Retention
•
NoDelay™ Writes
•
Advanced High-Reliability Ferroelectric Process
"Description
The FM24C256 is a 256-kilobit nonvolatile memory
employing an advanced ferroelectric process. A
ferroelectric random access memory or FRAM is
nonvolatile and performs reads and writes like a
RAM. It provides reliable data retention for 45 years
while eliminating the complexities, overhead, and
system level reliability problems caused by
EEPROM and other nonvolatile memories.
The FM24C256 performs write operations at bus
speed. No write delays are incurred. The next bus
cycle may commence immediately without the need
for data polling. In addition, the product offers write
endurance orders of magnitude higher than
EEPROM. Also, FRAM exhibits much lower power
during writes than EEPROM since write operations
do not require an internally elevated power supply
voltage for write circuits.
These capabilities make the FM24C256 ideal for
nonvolatile memory applications requiring frequent
or rapid writes. Examples range from data collection
where the number of write cycles may be critical, to
demanding industrial controls where the long write
time of EEPROM can cause data loss. The
combination of features allows more frequent data
writing with less overhead for the system.
The FM24C256 is available in a 8-pin EIAJ SOIC
package using an industry standard two-wire
protocol. Specifications are guaranteed over an
industrial temperature range of -40°C to +85°C. "
"Unlike other nonvolatile memory technologies,
there is essentially no write delay with FRAM.
Since the read and write access times of the
underlying memory are the same, the user
experiences no delay on the bus. The entire memory
cycle occurs in less time than a single bus clock.
Therefore, any operation including a read or write
can occur immediately following a write.
Acknowledge polling, a technique used with
EEPROMs to determine if a write has completed is
unnecessary and will always return a ready
condition. "
there is no delay with read or write it is proverbially instantaneous :) on a chip leve i assume there is a hardware time frame but to the user an its applications poof nothing. another great thing to these chips is if you have the hard ware to push it we are talking clock speeds of 1MHZ .. it is a truely amazing piece of hardware. 1mhz clockspeed though could probably only be envisioned on a Due, which i dont have + wont be buying for a few more years. 32bit stuff is too much like a real computer for me. i wanna stay down here in 8 and 16bit land :)
Currently I treat each 24LC512 as a separate volume. The maximum is of course 64k. Even a 23LC1024 is actually two LC512 in the same package, there is a 64k read boundry.
I had not considered allowing chip spanning.
I can think of a way to simply achieve it. Currently each mountPoint contains the I2C chip address, I could adjust the routines to add the 17th, 18th or even 19th address bit to the I2C address.
I am already handling the writepage issue with EEPROMs, to span chips I would have to add a readPage support, and increase the memory address variable size from uint16_t to uint32_t. I haven't needed it.
I am working on SPI Flash 64Mbit and 128Mbit. These are a little more complicated because the have a minimum erase page of 4KB. So to change a 0 back to a 1, requires 4KB of data to be triangle buffer written. Currently I use part of a 23LC512 SPI RAM (64KB) as my triangle buffer. So, a lot of data has be transferred across the SPI bus during 4K erases. My whole file system is designed to minimize these rewrites. I have designed in 'appending' files that have an extra cluster appended at close that contains the current eof, modified date.. when the file is reopen in write_append it loads this info into the RAM open filebuffer, then erases the 'extra' cluster. the program can continue append data from the current EOF through this 'extra' cluster, so no wasted space 
It looks like your FRAM board would not do what I want. I'll just see if I can figure some way that I can support Phone uploads with my slow hardware.
Chuck.
I like the idea - of using (2) or more Arduinos sharing (1) eeprom chip.
Been wanting to try this.
My theory is that you can use the CS to reserve the Eeprom.
If the CS is High then set CS=0 and use the Eeprom,
if the CS is Low, then abort and check again later.
To avoid Race Conditions between Arduinos, use an additional CS (CS0) - to verify the Reserving of the Eeprom.
So:
- Check if CS0==0 then Abort, Return // - global CS0 reserved so Abort
- Set CS0=0
- Use Loop : to Check if CS1==0 then set CS0=1, Abort, Return // - Eeprom CS1 reserved so Abort
- Set CS1=0
- Read & Write Eeprom
- Set CS1=1 , Set CS0=1 , return /// - done
If #3 has alternate Loop Times between Arduinos, then there should Never be a conflict.
QED.
I will try it tonight.