robtillaart / fram_i2c

Arduino library for I2C FRAM

FRAM_I2C

Arduino library for I2C FRAM.

Description

FRAM is a library to read from and write to (over I2C) an FRAM module. Since 0.5.0 the library provides four classes:

• FRAM for 16 bit address devices.
• FRAM32 for 32 (17) bit address devices.
• FRAM11 for 11 bit address devices.
• FRAM9 for 9 bit address devices.

Currently only the MB85RC1MT is known to use 32 bit. FRAM32 can also address 16 bit devices although there is some overhead in footprint.

FRAM stands for Ferroelectric RAM - https://en.wikipedia.org/wiki/Ferroelectric_RAM

FRAM memory is much faster than EEPROM and almost as fast as (Arduino UNO) RAM. Another important feature FRAM has in common with EEPROM is that FRAM keeps its content after a reboot as it is non-volatile, even for years. That makes it ideal to store configuration or logging data in a project.

Last but not least FRAM allows much more write cycles than any EEPROM. Typical FRAM allows 10^12 write cycles (see datasheet) where an ATMEGA328 (UNO) supports 10^5 write cycles (https://docs.arduino.cc/learn/built-in-libraries/eeprom). That is a factor of 10 million more write cycles.

Fujitsu

Types of FRAM tested with this library:

TYPE	SIZE	TESTED	NOTES	uses	ref
MB85RC04	512	Y	no deviceID register	FRAM9	#35
MB85RC16	2 KB	Y	no deviceID register	FRAM11	#28
MB85RC64T	8 KB	Y		FRAM
MB85RC64V	8 KB	Y	no deviceID register	FRAM	#38
MB85RC128A	16 KB	N	no deviceID register	FRAM
MB85RC256V	32 KB	Y		FRAM
MB85RC512T	64 KB	Y		FRAM
MB85RC1MT	128 KB	Y		FRAM32	#19

MB85RC128A and MB85RC64V have no size / deviceID, clear() will not work correctly, unless one calls setSizeBytes(16 * 1024) or setSizeBytes(8 * 1024) to set the size manually.

For the FRAM9 and FRAM11 the size problem is solved (hard coded) in their class.

Ramtron / Cypress / Infineon

Types of FRAM tested with this library:

TYPE	SIZE	TESTED	NOTES	uses	ref	Notes
24CL16B	2 KB	N	no deviceID register	FRAM11	#28
FM24C256-G	32 KB	Y	no deviceID register	FRAM	#45	test with ESP32
FM24V10	128 KB	Y		FRAM32	#49

Notes

• Not all types of FRAM are tested. Please let me know if you have verified one that is not in the list.
• If there is no deviceID getSize() will not work correctly.
  • ==> fixed for FRAM9 and FRAM11 by hardcoding the size.
• Address = 0x50 (default) .. 0x57, depends on the lines A0..A2.
• MB85RC1MT uses even addresses only as it uses the next odd one internally. So 0x50 uses 0x51 internally for the upper 64 KB block. This latter will not be shown on an I2C scanner (to be tested).
  Not tested: expect the MB85RC1MT can be addressed with 2 instances of FRAM too with adjacent addresses.

Related

• https://github.com/RobTillaart/I2C_EEPROM (eeprom)
• https://github.com/RobTillaart/I2C_24LC1025 (eeprom)

Interface

#include "FRAM.h"

Constructors

• FRAM(TwoWire *wire = &Wire) Constructor with optional Wire interface.
• FRAM32(TwoWire *wire = &Wire) Constructor with optional Wire interface, specific for MB85RC1MT type of device, 17 bit address.
• FRAM11(TwoWire *wire = &Wire) Constructor with optional Wire interface, specific for devices with 11 bit address e.g. Cypress/Infineon 24CL16B.
• FRAM9(TwoWire *wire = &Wire) Constructor with optional Wire interface, specific for devices with 9 bit address e.g. MB85RC04.

Begin

The user has to call Wire.begin() before FRAM.begin()!

• int begin(uint8_t address = 0x50, int8_t writeProtectPin = -1) address and writeProtectPin is optional. Note the MB85RC1MT only uses even addresses.

Write & read

Support for basic types and two calls for generic objects, use casting if needed.
In the FRAM32 class these functions have an uin32_t memAddr.

• void write8(uint16_t memAddr, uint8_t value) uint8_t
• void write16(uint16_t memAddr, uint16_t value) uint16_t
• void write32(uint16_t memAddr, uint32_t value) uint32_t
• void write64(uint16_t memAddr, uint64_t value) uint64_t
• void writeFloat(uint16_t memAddr, float value) float
• void writeDouble(uint16_t memAddr, double value) double
  • For boards that have an 8 byte double.
• void write(uint16_t memAddr, uint8_t * obj, uint16_t size) other types / sizes.
  • typical used for structs or text.
• uint8_t read8(uint16_t memAddr)
• uint16_t read16(uint16_t memAddr)
• uint32_t read32(uint16_t memAddr)
• uint64_t read64(uint16_t memAddr)
• float readFloat(uint16_t memAddr)
• double readDouble(uint16_t memAddr)
  • For board that have 8 byte double.
• void read(uint16_t memAddr, uint8_t uint8_t * obj, uint16_t size)
  • One needs to allocate memory as the function won't.
• uint32_t clear(uint8_t value = 0) clears the whole FRAM by writing value to all addresses
  • default value is all zero's.
  • Returns the number of bytes written.
  • clear() does not work for MB85RC128A unless setSizeBytes() is used.

Template functions

See issue #13, #42

• uint16_t writeObject(uint16_t memAddr, T &obj) writes an object to memAddr (and following bytes).
  • Returns memAddr + sizeof(obj) to get the next address to write to.
• uint16_t readObject(uint16_t memAddr, T &obj) reads an object from memAddr and next bytes.
  • Returns memAddr + sizeof(obj) to get the next address to read from.

ReadUntil, readLine

Experimental 0.5.1, see issue #30

• int32_t readUntil(uint16_t memAddr, char * buffer, uint16_t bufferLength, char separator) Reads FRAM from an address into buffer until separator is encountered. The separator is replaced by an '\0' - end of char array. ReadUntil() returns the length of the buffer. To get the address of the next "field" one must add memAddr += (length + 1).
  If the separator is not found after bufferLength characters the function returns -1. However the buffer does contain the data read, which might be useful. Handle with care as buffer has probably no '\0' end char.
• int32_t readLine(uint16_t memAddr, char * buffer, uint16_t bufferLength) Similar to readUntil(), reads a line from FRAM including the '\n'. This '\n' is mandatory as end separator!. Note: The buffer needs one extra char for the delimiting '\0' end char. To get the address of the next "field" one must add memAddr += length. This is an minor but important difference with readUntil(). Note: the returning buffer contains the '\n' so one need to take care when printing the buffer.

ReadUntil

readUntil() can be used to read lines and/or fields from an FRAM filled with text. For example logging written with the FRAM_logging.ino example. Note: if memAddr + bufferLength >= size of FRAM, memory address wrapping may occur. The library does not check, so the user should.

Note: internally readUntil() reads bufferLength bytes to fill the buffer. Then it searches for the separator. This is chosen to optimize performance for relative small buffers that are used most. For large buffers this fetching of the whole buffer will take much time. This can results in less responsiveness. Increasing the I2C bus speed might compensate this a bit.

Finally the FRAM_readUntil.ino sketch has a readUntil() implementation that uses a per byte fetching.

Write-protect

Will work only if a writeProtectPin was defined in begin()

• bool setWriteProtect(bool b) make the FRAM write-protected by pulling the WP line HIGH or LOW.
  • Returns true if a writeProtectPin was defined in begin(). Otherwise the FRAM cannot be write protected.
• bool getWriteProtect() get current write protect status.
  • returns status (true/false).
  • Returns false if the writeProtectPin was not defined.

Metadata

These may not work for devices that have no deviceID register.
So use with care.

• uint16_t getManufacturerID() see table below. Returns 0x0FFF means getMetaData() had a read error.
• uint16_t getProductID() idem. Proprietary. Returns 0x0FFF means getMetaData() had a read error.
• uint16_t getSize() returns the size in kiloBYTE. If the FRAM has no device ID register, the size cannot be read.
  • FRAM9 will return 0 as it is less than 1 KB. use GetSizeBytes() instead.
• uint32_t getSizeBytes() returns the size in BYTES.
  • Useful for iterating over the whole memory, or testing the upper boundary.
• void setSizeBytes(uint32_t value) sets the size in bytes for getSizeBytes(). To be used only if getSize() cannot determine the size. As far as known this is for the MB85RC128A and MB85RC64V only. See also remark in Future section below. Can also be used to "virtually" reduce the size, e.g. to speed up clear() if the FRAM is used only partial.

Manufacturers ID

Name	ID	Notes
Fujitsu	0x00A
Ramtron	0x004	shared
Cypress	0x004	shared
Infineon	0x004	shared
getMetaData read error	0xFFF	See #38

Additions for manufacturers ID's are welcome.

Sleep

(0.3.6 added - experimental)

• void sleep() puts the FRAM in sleep mode so it uses less power. Still needs a power test for several types of FRAM.
• bool wakeup(uint32_t trec = 400) tries to wake up the device with a default recovery time of 400 microseconds. Returns true if connected after the call.

According to the data sheets there are only three FRAM devices support the sleep command. So use with care.

TYPE	SIZE	SLEEP (datasheet)	CURRENT	CONFIRMED	NOTES
MB85RC04	512	not supported	-	N
MB85RC16	2 KB	not supported	-	N
MB85RC64T	8 KB	Y Page 11	4.0 uA*	N
MB85RC128A	16 KB	not supported	-	N
MB85RC256V	32 KB	not supported	-	Y
MB85RC512T	64 KB	Y Page 12	4.0 uA*	N
MB85RC1MT	128 KB	Y Page 12	3.6 uA	Y	See #17
FM24C256-G	32 KB	not supported		Y	See #45

current with * are from datasheet

Current

Indicative power usage in uA in three modi (if supported).

TYPE	SIZE	STANDBY	WRITE	SLEEP	NOTES
MB85RC04	512			-
MB85RC16	2 KB			-
MB85RC64T	8 KB			4.0 uA
MB85RC128A	16 KB			-
MB85RC256V	32 KB	10.22 uA	93.48 uA	-
MB85RC512T	64 KB			4.0 uA
MB85RC1MT	128 KB	11.7 uA	46-721 uA	3.6 uA	See #17
FM24C256-G	32 KB	100 uA			See #45

TODO: fill the table

FRAM_RINGBUFFER

Since version 0.4.2 a separate class FRAM_RINGBUFFER is added to this repo. Its interface is straightforward and described in FRAM_RINGBUFFER.md. The FRAM_ringbuffer.ino examples shows how the class can be used.

FRAM_MULTILANGUAGE

Since version 0.5.2 the FRAM_ML class is added. Its purpose is to store tables of strings in FRAM. Its interface is described in FRAM_MULTILANGUAGE.md.

See examples.

FRAM32

Since version 0.8.0 the FRAM32 internal readBlock() and writeBlock() guard for memory addresses that are out of range. This prevents interference with valid address ranges. These will just be ignored for now and no error flag whatever is set.

FRAM11 + FRAM9

• 0.5.0 added, see issue #28
• 0.5.3 redo FRAM9 and FRAM11, see #35

Experimental support for smaller FRAM's with 11 and 9 bits addresses.

• FRAM11 e.g. Cypress/Infineon 24CL16B (see #28)
• FRAM9 e.g. MB85RC04 (see #35) Note getSize() will return 0 as it is only 0.5 KB and rounded down. Use getSizeBytes() to get 512.

Future

Must

• improve documentation
• test more types of FRAM (continuous action)
  • FRAM11 / FRAM9
  • other people might provide input.

Should

• FRAM32 invalid memory address handling.
  • user should be notified of success / failure? how?
  • bool validAddress(uint32_t memAddress) as preventive strategy.
  • or setting an error flag? return value? (impact in class hierarchy).
• Improve getSize() to have clear() working properly.
  • MB85RC128A only (hard code fall back?).
  • getSize() scanning FRAM like EEPROM library?
• investigate a faster strategy for readUntil()
  • search for separator per block (e.g. 16 bytes) read.
• Investigate getManufacturerID() and getProductID() for FRAM9/11.
  • need hardware + data sheets.

Could

• improve FRAM32 that can write over the 64 KB border without problems.
  • Would need extra checking ==> overhead.
  • now it is responsibility of the user.
  • do we want/need this?
• write() and writeBlock() might write beyond the end of FRAM
  • now it is responsibility of the user.
  • range check would degrade performance
  • error flag ?
• extend examples
  • FRAM (8x) concatenated as one continuous memory.
    • a wrapper class?
• fill power usage table (documentation)
  • is in data sheet.
• improve comments where needed.
• move the device address parameter to the constructor so it becomes " "? would break the interface (even more).

Wont

• extend current clear() with partial clear(begin, end, value)?
  • can be done by writeBlock() calls by user too
  • would need more complex end checking
  • ==> wont for now
• dump(stream) or printable interface?
  • Print interface? expensive in performance per char..
  • see example FRAM_hexdump.ino
• remember last written address? why?
• do we need a write(memAddr, char * buffer) for completeness?
  • it is just a wrapper

Support

If you appreciate my libraries, you can support the development and maintenance. Improve the quality of the libraries by providing issues and Pull Requests, or donate through PayPal or GitHub sponsors.

Thank you,

fram_i2c's Issues

sleep mode

Hi,

Are you considering adding suport for sleep?

(I've tried based on
https://www.fujitsu.com/jp/group/fsm/en/documents/products/fram/lineup/MB85RC1MT-DS501-00027-4v0-E.pdf
page 12, but am misunderstanding something!)

[I'm an infrequent github user, sorry if an issue like this isn't the right way to ask this question!]

Michael

add readObject, writeObject APIs

You should steal implement the readObject and writeObject methods from Adafruits FRAM_I2C library, only implementing them properly with the multibyte read and write primitives you already have.
See https://forum.arduino.cc/t/re-fast-data-logging-using-fram/968962/25

Support of different FRAM sizes

Hello
As I wrote on the forum, I interesting in your code, because you take into account different types of addresses for chips of different sizes. Oddly enough, most similar libraries do not have this.

But why make separate classes for Fram9, Fram11 and Fram16? And where then are the classes for Fram8 and Fram10? :)
In fact, the principle of addressing i2c FRAM/EEPROM chips is the same for any size and follows a simple rule:
FM24с02 - has 8 bits cell address
FM24c04 - 9 bits
c08 - 10 bits
c16 - 11 bit
c32 -12 bit
c64 -13 bit
...
c512 - 16 bit
c1024 - 17bit
c2048 - 18 bit

For chips c02-c16, one byte is used for the cell address, and additional bits are added to the device i2c address.
For chips from c32 to c512 - two bytes are used.
For c1024 and c2048 chips - additional bits, in addition to two bytes, are added to the device i2c address, as is done for c04-c16 chips

Thus, it is quite possible to make a single library for all chip sizes. To use the correct addressing for each size, it seems to me that the simplest thing is to ask the user to provide a chip size as parameter to the initialisation of the FRAM object.

Error by reading internal Metadata

Your old Function is invalid. The new Fuction should be like this:
// metadata is packed as [....MMMM][MMMMDDDD][PPPPPPPP]
// M = manufacturerID
// D = density => memsize = 2^D KB
// P = product ID (together with D)

uint16_t FRAM::getMetaData(uint8_t field)
{
  if (field > 2) return 0;

  Wire.beginTransmission(FRAM_SLAVE_ID_);
  Wire.write(_address << 1);
  Wire.endTransmission(false);
  int x = Wire.requestFrom(FRAM_SLAVE_ID_, (uint8_t)3);
  if (x != 3) return -1;

  uint32_t value = 0;
  value = Wire.read();
  value = value << 8;     // <--- new insert line by me on 11.01.2021
  value |= Wire.read();
  value = value << 8;     // <--- new insert line by me on 11.01.2021
  value |= Wire.read();
  // MANUFACTURER
  if (field == 0) return (value >> 12) & 0xFF;
  // PRODUCT ID
  if (field == 1) return value & 0x0FFF;
  // DENSITY
  if (field == 2) return (value >> 8) & 0x0F;
  return 0;
}

Add clear() function

Requirement

The function should write zero's to all memory places to remove previous usage data.

must

minimal version should "format" the whole FRAM - void clear()

should

• be able to format a part - void clear(begin, end)
• be able to write another value instead of zero void clear(value) - void clear(begin, end, value)

So the ideal API is - void clear(begin = 0, end = 0, value = 0) and one wrapper void clear(value)

[Question] Begin after deepsleep produces an error

After recovering from deepsleep fram.begin produces the error:
[ 68][E][Wire.cpp:499] requestFrom(): i2cWriteReadNonStop returned Error -1

This doesn't happen after a hard reset, only when waking from deepsleep.

Any idea?

I use a begin with pins only int rv = fram.begin(I2C_SDA, I2C_SCL);
This because I use non standard pins on an ESP32-C3
Before adding FRAM management all was good.
My code is too big to paste it here.
It must be related to the use of FRAM, but how?

Fram address question

Rob

I am trying to work out your addressing. I have a MB85RC64A FRAM 64KBIT. I note that this is unsupported on your list. I can report that your library's basic functionality works on this chip other than getsize and getID. I am trying to work out how your addressing works. I ran this code below that writes a byte FF and then read FF and looks for a failure to write/read as the top of memory.

    // Write Fram FF

 for (uint32_t addr = 0; addr < 1000000; addr++)
    {
        FRAM.write8(addr, 0xFF);
        uint8_t framtestread = FRAM.read8(addr);
        Serial.print(addr);
        Serial.print(":");
        Serial.println(framtestread);

        if (framtestread != 0xFF ) {
            Serial.println("fram read fail");
            break;
        }
    }

Results:
0:255
...
131071:255
131072:0
fram read fail

I found that the FRAM.write and FRAM.read printed results up to 131071 Dec or 0x1FFF. I can't work out how this relates to the 8,192 word s × 8 bits structure of the IC.

On a 1 byte read, why am I getting a result above the addr = 8196?

Thanks
Jason

FRAM size error

Rob

This FRAM is unsupported, I'm just reporting a result here. I have a MB85RC64A on a custom board. It's 8,192 word s × 8 bits FRAM. When I run sizeInBytes = FRAM.getSize() * 1024; it returns 0 bytes. I will use the set function.

uint32_t framID = FRAM.getProductID() returns 4096 DEC. // The size of Device ID is 3 bytes and consists of manufacturer
ID and product ID.

Regards

Jason

second I2C port on ESP32, working with BM280E not with FRAM

Hello,

I tested my code with an BM280E sensor on I2C2 port the code compiled and worked, now I want to replace the BM280E sensor for an FRAM. I thought this wil be easy one only change adres and name.

This gives me an error, sorry it was easier maybe to copy the errorcode, I can do that later if thats neccesary.

The part of the code where I obviously mis something, I tried a lot of things but cant figure it out, I am busy with this for a whole day.
I am not so good in coding, I do my best, but sometimes I get stuck too long :-)

So I tested this on a ESP32:

#define I2C_SDA              21
#define I2C_SCL              22

// FRAM Memory
#define I2C_SDA_2            16
#define I2C_SCL_2            17

// I2C1
TwoWire I2CPower = TwoWire(0);

// I2C2 for FRAM sensor
TwoWire I2CFRAM = TwoWire(1);
FRAM fram;

// Start I2C communication
I2CPower.begin(I2C_SDA, I2C_SCL, I2C_Freq);
I2CFRAM.begin(I2C_SDA_2, I2C_SCL_2, I2C_Freq);

// You might need to change the FRAM I2C address, in our case it's 0x50
if (!fram.begin(0x50, &I2CFRAM)) {
Serial.println("Could not find a valid FRAM sensor, check wiring!");
while (1);
}

getMetadata() not working on MB85RC64V

I have a MB85RC64V FRAM chip and although I am able to read and write it, the metadata information is not working.
The exact component I am using is this but the datasheet does not say anything about a metadata address code to send, so I would assume that it does not supply this information.
In

FRAM_I2C/FRAM.cpp

Line 352 in b536e63

if (x != 3) return -1;

the number of read bytes is always 0 so the function returns -1. The datasheet says, that the device only uses 13 bits for the addresses and I am wondering if it would be necessary to have a FRAM13 class (with fixed memory size like in FRAM9) as well for this case although it does not work fundamentally different from the base FRAM class?

In addition I am wondering if it would make sense to return the number of written bytes returned by _wire->write in all the write* methods to give the user the ability to check if something went wrong during the write operation?

FRAM32 and read / write object

Hi

I'm using FRAM32 library on a MB85RC1MT to read/write STRUCT objects. When compiling i get this error:

undefined reference to `unsigned long FRAM32::readObject(unsigned long, LogDataStructure&)'

The same for writeObject.

Can you please advise?

Support for Additional FRAM Devices and Addressing Modes

I would like to request the addition of support for additional FRAM devices and addressing modes in the FRAM_I2C library. This would enhance the library's versatility and compatibility with a wider range of FRAM modules.

Currently, the library supports FRAM devices with 16-bit, 32-bit, 11-bit, and 9-bit addressing modes. However, there are other FRAM devices available in the market with different addressing modes and sizes that are not yet supported.

I propose the following features to be added to the library:

1. Support for FRAM devices with custom addressing modes: Extend the library's capabilities to accommodate FRAM devices with unique addressing modes that deviate from the existing supported modes (16-bit, 32-bit, 11-bit, and 9-bit). This would enable users to interface with a wider variety of FRAM devices and unlock their full potential.

2. Compatibility with additional FRAM sizes: Enhance the library to work seamlessly with FRAM devices of different sizes, including but not limited to the MB85RC128A, which currently requires manual configuration using the setSizeBytes() function. Automating the size detection process would simplify usage and improve the overall user experience.

By incorporating these enhancements, the FRAM_I2C library would become more adaptable and accessible to a larger user base. It would empower developers to utilize a wider range of FRAM devices in their projects, ensuring optimal performance and flexibility.

I believe these additions would greatly benefit the library's functionality and increase its usefulness in various applications. Thank you for considering my feature request.

failing to write a float value, but don't know why

Trying to write a floating point value and reading it back.
But somehow it dosn't work.

this is my code i use .

i'm i doing sothing wrong.
the value i'm writing is 31.12

as you can see the writen and readed value's aren't the same as the sended value.
How can i fix it.

[12:00:53][I][I2C-FRAM:071]: write value 31.120001 to memory addres 
[12:00:58][I][I2C-FRAM:064]: read value 31.000000 from memory addres 1

float readfromfram(uint32_t memaddr)
{
  float value;
  value = fram.read32(memaddr);
  ESP_LOGI(TAG, "read value %f from memory addres %d", value, memaddr);
  return (value);
}

void writetofram(uint32_t memaddr, float value)
{
  fram.write32(memaddr, value);
  ESP_LOGI(TAG, "write value %f to memory addres ", value, memaddr);
  // ESP_LOGI(TAG, "to memory adres %d ", memaddr);
}

Connection to FRAM stopped working with version 0.7.0

Hi,

I'm currently using the FRAM_I2C library on a custom board based on the Adafruit Feather M4 CAN board. Since a couple of days, I'm unable to connect to the FRAM whereas it worked before. Whenever I try to connect to it using "fram.begin(0x51)" it returns me "-12" as an error code. Subsequent tries to read from or write to the FRAM fail as well.

I was able to find out that the connection was possible with version 0.6.1, but not with the latest version 0.7.0 (I updated the library a couple of days ago). Here are some additional information:

Base Board: Adafruit Feather M4 CAN
FRAM: Fujitsu MB85RC256VPNF-G-JNERE1)
I2C address: 0x51

I know that it's not much information, but I hope it helps you find the issue. If you need any more information, feel free to reach out.

MB85RC04 FRAM9

Hi!

First of all, I highly appreciate the time you spend doing good libraries!

I have tried MB85RC04 FRAM (with ESP32) with FRAM9_Test example.
Changes before run:
It is not possible to get the sizeInBytes = fram.getSizeBytes(); so I have set it to sizeInBytes = 100 and changed the printout, of read, to Serial.println(x); instead of Serial.println(value); to actually see what is read.

The result I get is:

15:03:18.301 -> Write 95 48
15:03:18.301 -> Write 96 49
15:03:18.301 -> Write 97 49
15:03:18.301 -> Write 98 50
15:03:18.301 -> Write 99 50
15:03:18.301 -> Read 0 50
15:03:18.301 -> Read 1 50
15:03:18.301 -> Read 2 50
15:03:18.301 -> Read 3 50
15:03:18.301 -> Read 4 50
15:03:18.301 -> Read 5 50
15:03:18.301 -> Read 6 50
15:03:18.333 -> Read 7 50

I have tried to only write one address and the result is the same.

Tested device: FM24C256-G (Ramtron) Works

Rob,

For your supported table: the Ramtron FM24C256-G works with this library. I'm using it in several projects and It's *much cheaper than the Fujitsu devices. Despite the datasheet stating Vcc=4.7-5.5V I've only ever used the device with an ESP32 and ESP8266 at 3.3V.

It does not have a device register so there's no device metadata.
It does not support sleep.

Standby current 100uA
Active current SCL=100kHz 200uA, SCL=400kHz 500uA, SCL=1MHz 1.2mA

Bug with reading

Hello!

I found a bug with reading from FRAM from the second half of the addresses (1 Mbit). Please look and correct.

Issues with FRAM's that use Page Addressing

Good day,

This is a great library, well done! That said, it does not work with a number FRAM devices that use page addressing such as those from Cypress/Infineon 24CLxx or the Fujistu MB85RCxx devices. To address this, I made some changes to your fram.cpp and fram.h files and they are attached. Effectively I created a private variable called _usesMemAddressPages that when set changes the _writeBlock and _readBlock functions to correctly access those FRAM devices that use page addressing.

To use, all one has to do is call the "setUsesAddressPages(true)" function and the appropriate page addressing I2C sequences are followed. If the "setUsesAddressPages" is not called then your original library functions like before.

Cheers,

Sam

ModifiedFramFiles.zip

Stewrat

I have been using FRAM_I2C, on a ESP32-WROVER with a I2C MR44V100A (128Kx8) FRAM, for some time now without any problems whatsoever. However with the release of FRAM_I2C version 0.3.0, PlatformIO has refused to update from version 0.2.2 returning an "Update to 0.3.0 (Incompatible)" message.

When I look a little deeper into the problem, it appears that an error ('PCF8574' has not been declared) is occurring at line 37 of FRAM.cpp. At present I do not use a PCF8574.

Thank you for such a great library,

Stewart

FM24V10

Hello!

I'm trying to start FM24V10, but it is not detected correctly. Can this be fixed?

interface for ESP32 is lacking

See other I2C libraries.

getSize returns wrong value

I tested getSize() with the MB85RC64TAPNF chip which is 64k in size and getSize returns "8".
I can confirm that the chip is actually 64k by writing and reading from address 0xFFFF.

esphome port or I2C/GPIO abstraction

Hello,
I am planning to use this in esphome, but I want it to work on esp-idf framework as well.
So, obviously I will have to port it to esphome universe (components, i2cdevice, etc).

Are there any plans to do something similar?
Like, take out low level i2c write/read out of the main class, so an esphome (or other) integration could be implemented through a small bridge class.

I am not a fluent C++ programmer (I do PHP and JS well), but I've managed to frankenstein working code for some other "side projects" and I think I can port this one.
But, I don't want to do double work for something that is already in the pipeline and probably implemented better than I can.
I'd rather help with the pipeline and wait, than do the work and scrap it because upstream did it better :)

memory addressing for MB85RC1MT

It would be handy to be able to easily access the whole memory of the MB85RC1MT!

Ringbuffer

Hi Rob

I'm very interested in using FRAM as ring-buffer. Have you already started coding in that direction?

Regards

Matthias

[Wish] - read back logging

In FRAM_logging.ino:
// todo - read back sketch.

Can you add such example sketch?

Nice lib!
I have strange behaviors on my electronic assemblies. I want to use this library to determine the causes.