I understand the MB85 is structured to be a linear 32k bytes. And with the FRAM_I2C I can write multibyte values.
So if I write a int8_t then an uint16_t then 4 more int8_t values. Then its up to my program to “remember” where each value is.
Is this correct?
Thanks
John
Yes.
A way to make this easier and less error prone is to put all the variables you want to store in the FRAM into a struct, and read/write the entire struct.
It depends on whether you do a random read/write or a sequential read/write
You could write a uint_32 (four bytes) and then only read out the 2nd byte.
Thanks. I’ll look into this, however I don’t think a struct will be helpful for the type of data I’m storing.
I’m storing sensor data, like “ max today, max last 24 hours, max 7 days, max all time.
Likely some other data.
But in the end won’t the program have to somehow “know” where the data is? Even if I used a struct (as suggested by Paul) I will need to know where the structs are?
You can't write data to the FRAM witout giving it an address to write to, so you will already know where you put the data.
This was my original assumption. Basically the memory is simply addresses, each one pointing to a 8 bit byte.
Correct.
Can you explain why you think using a struct will not be helpful? I think it will, based on your description of the data in the first post.
Why would there be more than one? From your description, I don't see the need for more than one.
Normally (most used) your application has fixed addresses for your data.
So you always write e.g. the max 7 days on position 7 etc.
Another way to solve your question is is to make an index with all the addresses of the data stored in the FRAM. Just like the root directory for a file system. Not trivial but good implementable. The advantage would be that multiple sketches can store their own variables in FRAM and leave the other as is.
I have 3 sensors, some with more than one reading, resulting in 8 items I wish to keep some history on. There are 4 different update times. So I guess I could use a struct made from all 8 numbers and simply update the whole structure if one changes, but Its not clear how much easier that would be over just using 8 different addresses.
If you do sequential read/writes then you only need to know the address of the first data byte. The addresses are automatically incremented by the FRAM on subsequent reads
I think the answer is yes, your code has to somehow keep track of where everything is. If the records are of different lengths, you could begin each one with a special character, and perhaps a record number. A lot depends on whether you need to do random access, or can just write sequentially, and then read back sequentially later.
Anyway, I hope you will come back and report what you end up doing.
For me data in FRAM is organized into logical blocks. Access is performed by first selecting the desired block and then indexing into the data within that block. Each block typically corresponds to a read operation, with the returned data stored in a buffer structure (e.g., an array). This approach simplifies addressing and allows structured access to FRAM resident data.
I align the logical blocks on even boundaries, then I simply specify an offset into FRAM where the data starts. This allows me to move the blocks at will.
Sounds like it might be good for my application. I’ll look into it.
Thanks,
It does not matter how much data you have or how it is organized, you still need to supply an address.
Ok. You could use an array of structs, or a struct containing one or more arrays, or even a struct containing one or more arrays of structs! This would avoid having to deal with addresses (you would always read and write the entire thing to one fixed address, like zero).
There would be no danger of wearing the FRAM out like there would be with EEPROM. But there might be a time penalty because of reading/writing the whole thing instead of only the bytes that actually changed.
If that time penalty is a problem, then the solution could be to calculate and use addresses.
That FRAM and the others I have used are all byte accessible, no additional time is required for write or read, the normal cycle is fine. You need to be careful the offset pointer is 16 bits. You can read or as much as you like, but remember it has a 8 bit data path. FRAM does not require write delays (unlike EEPROM), it can sustain continuous transfers at bus speed.
Consider you have a project that reads and writes 60 times per second, FRAM rated for 10¹⁴ cycles would last roughly: ≈ 53,000 years. Older FRAM at 60 read/write cycles per second would only last ≈528 years.
Thanks to all who provided information. I’m using simple linear addressing within blocks of space. Being in blocks seems to not make any difference but it is more comfortable in my mind. And seeing I have almost x1000 the memory I actually need it really doesn’t matter much.
I’m using Rob Tillaart’s “FRAM_I2C” library making the read and writes to memory programably trivial.