Go Down

Topic: i2c FRAM (Read 1 time) previous topic - next topic

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...

tbillion

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...

chucktodd

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.
Currently built mega http server, Now converting it to ESP32.

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.

Quote
fast is access/write?
Code: [Select]
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 :)

chucktodd

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.

Code: [Select]
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.
Currently built mega http server, Now converting it to ESP32.

jlsilicon

#5
Oct 05, 2018, 08:21 pm Last Edit: Oct 05, 2018, 08:23 pm by jlsilicon
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:
1. Check if CS0==0 then Abort, Return  // - global CS0 reserved so Abort
2. Set CS0=0
3. Use Loop : to Check if CS1==0 then set CS0=1, Abort, Return  // - Eeprom CS1 reserved so Abort
4. Set CS1=0
5. Read & Write Eeprom
6. 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.

Go Up