Sonsivri
 
*
Welcome, Guest. Please login or register.
Did you miss your activation email?
March 28, 2024, 09:17:14 21:17


Login with username, password and session length


Pages: [1]
Print
Author Topic: Ferroelectric RAM and data reading  (Read 3451 times)
0 Members and 1 Guest are viewing this topic.
Droneman1982
Newbie
*
Offline Offline

Posts: 23

Thank You
-Given: 3
-Receive: 12


« on: February 23, 2015, 02:18:53 14:18 »

I have read that reading a FeRAM deletes the current value (if it is a logic "1") https://it.wikipedia.org/wiki/FeRAM, but no mention about this i done in the datasheets that compare the I2C reading of the memory almost identical (although much more faster) to reading an I2C EEprom.

Can anyon clarify this point? Does the FeRam I2C memory refreshes the value after reading to avoid deletion?

Logged
vern
V.I.P
Active Member
*****
Offline Offline

Posts: 144

Thank You
-Given: 7
-Receive: 41


« Reply #1 on: February 24, 2015, 09:17:55 21:17 »

If you use for example a TI MSP430 controller with an integrated FRAM it has an inherent mechanism that restores the original data after reading.
That might not be the case if you use just an FRAM, I guess you have to rewrite after reading.
Logged
Droneman1982
Newbie
*
Offline Offline

Posts: 23

Thank You
-Given: 3
-Receive: 12


« Reply #2 on: February 25, 2015, 10:19:00 10:19 »

In the I2C FRAM modules I have read, no mention is done about this fenomena... it is somewhat confusing...
Logged
aplank
Active Member
***
Offline Offline

Posts: 111

Thank You
-Given: 137
-Receive: 193


« Reply #3 on: February 25, 2015, 11:45:25 11:45 »

Doesn't that effect relate to the (very) old core magnetic memory?

As far as I'm aware, the current FRAM devices do not suffer from this effect.

Reading is advertised as being full speed - But they could hardly say that if every read had to be followed by an immediate write.
Logged
Droneman1982
Newbie
*
Offline Offline

Posts: 23

Thank You
-Given: 3
-Receive: 12


« Reply #4 on: February 25, 2015, 01:15:09 13:15 »

Exactly. Probably the best way to go is to try to write, read and re-read to see if anything has changed.
Logged
bigtoy
Active Member
***
Offline Offline

Posts: 238

Thank You
-Given: 320
-Receive: 297


« Reply #5 on: February 26, 2015, 05:02:14 05:02 »

The current parts don't erase on read. I don't think the manufacturers would sell many if they did!
Logged
Droneman1982
Newbie
*
Offline Offline

Posts: 23

Thank You
-Given: 3
-Receive: 12


« Reply #6 on: February 26, 2015, 10:55:35 10:55 »

probably it was a problem of the early FRAMs...
Logged
flyback
Junior Member
**
Offline Offline

Posts: 84

Thank You
-Given: 73
-Receive: 39


« Reply #7 on: February 27, 2015, 11:19:06 23:19 »

Yes, the FRAM loses info after a read, and must be  written back. Thankfully, the MSP430 FRAM handles the process automatically. You can find more info in http://www.ti.com/lit/an/slaa649/slaa649.pdf
Hereunder an excerpt from it:

... In the process of reading the data, the crystal that is polarized in the
direction of the applied field loses its current state. Hence, every read must be accompanied by a writeback
to restore the state of the memory location. With TI's MSP430 FRAM MCUs, this is inherent to the
FRAM implementation and is completely transparent to the application. ...

Best


Posted on: February 28, 2015, 12:02:34 00:02 - Automerged

Additional info:
The standard I2C FRAM datasheet from Fujitsu don't mention the rewrite process. But at Spansion (which is Fujitsu!), they describe it, in chapter 3.2 of the following document (The number of Rewrite operations)

http://www.spansion.com/marketingdownloads/appnotes/public/fm3/an706-00053_control_fram_by_i2c_and_spi/an706-00053-1v0-e.pdf




Logged
Droneman1982
Newbie
*
Offline Offline

Posts: 23

Thank You
-Given: 3
-Receive: 12


« Reply #8 on: March 02, 2015, 09:39:18 09:39 »

I'm going to use this type of FRAM
FM24V01-G

No mention about the need of Rewrite is done in the DS, http://www.cypress.com/?docID=48193
« Last Edit: March 02, 2015, 09:50:57 09:50 by Droneman1982 » Logged
vern
V.I.P
Active Member
*****
Offline Offline

Posts: 144

Thank You
-Given: 7
-Receive: 41


« Reply #9 on: March 02, 2015, 10:41:37 22:41 »

it's a direct replacement for an I2C EEprom, it has the rewrite after read mechanism internally, you don't have to do anything from the outside. Just write and read.
We used a similar type to store debugs in the event of power failure in a device, because you can't use flash memory in the short time between a power bad signal and loss of power, it's just to slow.
With an FRAM you are fast enough, worked great.
Logged
jumulab
Junior Member
**
Offline Offline

Posts: 77

Thank You
-Given: 91
-Receive: 74


« Reply #10 on: March 03, 2015, 07:53:50 19:53 »

Hi, Droneman1982,
You can take a view to the new Everspin MRAM devices like  MR25HXX.
There are some SPi and parallel  memory's  easy to use.
See at manufacturer www page.  www.everspin.com
Logged
Droneman1982
Newbie
*
Offline Offline

Posts: 23

Thank You
-Given: 3
-Receive: 12


« Reply #11 on: March 04, 2015, 09:29:18 09:29 »

Thank you all guys :-)

The purpose to use the FRAM (actually my initial idea was to use a DRAM) is to buffer/store data between two microcontrollers. One microcontroller is devoted only to IMU calculation and ESC control (for a drone), that needs minimum delay to ensure stability, with the attutude setpoints and PID parameters read from the FRAM (set by the other "AI" microcontroller). This way the IMU operates ad the fastest speed and the "IMU" microcontroller reads data only when it is ready to do it. The "AI" microcontroller reads GPS data, RC data (in ppm or SBUS) and the angle (or quaternion) from the "IMU" microcontroller (to parse it to telemetry or OSD and to check if there is some motor problem).

The rest of the memory of the FRAM (thanks to its non-volatility) will be eventually used to store "no fly zones" and "magnetic declination data grid" and other useful parameters

Logged
Pages: [1]
Print
Jump to:  


DISCLAIMER
WE DONT HOST ANY ILLEGAL FILES ON THE SERVER
USE CONTACT US TO REPORT ILLEGAL FILES
ADMINISTRATORS CANNOT BE HELD RESPONSIBLE FOR USERS POSTS AND LINKS

... Copyright © 2003-2999 Sonsivri.to ...
Powered by SMF 1.1.18 | SMF © 2006-2009, Simple Machines LLC | HarzeM Dilber MC