 Notice. New forum software under development. It's going to miss a few functions and look a bit ugly for a while, but I'm working on it full time now as the old forum was too unstable. Couple days, all good. If you notice any issues, please contact me. |
Forum Index : Microcontroller and PC projects : I2C eeprom vs I2C fram
| Author | Message | ||||
| viscomjim Guru  Joined: 08/01/2014 Location: United StatesPosts: 925 |
After going through several older posts regarding the use of eeprom and fram chips with the uMite, I am trying to figure out what advantages one has over the other? I want to use some external non volatile memory in a sort of logging situation, (by using the port command and reading 8 bits from the port). I would be logging this 1 byte of data at approximately 10 to 20 times a second for a period of about 5 to 10 minutes. At worst case, this would be 20 x 60 x 10 (12000) bytes of data. I am guessing that this would be a "sequential" type of writing and then later, reading of the data. If speed isn't an issue at this rate, then maybe it would just be a simple send address, write byte, increment address, write byte, etc. Same for reading back the data. Just not sure at this point in the project and my skill level. Does fram or eeprom have an advantage in this type of situation and what are your opinions when to use which. Thanks a million!!!! |
||||
Zonker Guru Joined: 18/08/2012 Location: United StatesPosts: 761 |
Humm... There are differences between the two... EEprom is cheaper than Fram... Both IC's usually increment to the next byte for you during reads and writes... EEprom will take "X" amount of milliseconds to store the data, Fram seems to be able to store data as fast as the data interface will run... Reading some PDF's will help you make the decision on witch way to go... The first thing would be the sample speed... Creating the code is not to bad... I think there are examples in several threads that could be used as starting models... If you use a "fixed" record length then creating the MM subroutines will be easier to do... Also, storing the "cr" "lf" characters, even thou a waste of bytes, makes the subroutine even easier and will make sure you data doesn't get "out of sync"... Just some random thoughts  |
||||
| viscomjim Guru Joined: 08/01/2014 Location: United StatesPosts: 925 |
Thanks for your input Zonker. I know you have experience with the fram chips. Since I don't have a fram here at this time, I am going to try using the eeprom on my ds3231 rtc board and see if speed is an issue. In the mean time, I am going to find the fram that has the rtc built in and order that in. Can you tell me which fram you wound up using on your board? Thanks!!!! |
||||
| Zonker Guru Joined: 18/08/2012 Location: United StatesPosts: 761 |
Yep... It was the FM31256-G part I believe .. I have a few of the DIP-600-28 boards left if you want one to play with... |
||||
Grogster Admin Group  Joined: 31/12/2012 Location: New ZealandPosts: 9066 |
The main advantage of FRAM is it's write endurance and speed. FRAM addresses can be rewritten MILLIONS of times before any failure - the same address. They are also usually perfectly happy at I2C speeds up 1MHz EEPROM is much cheaper, has a limited number of write cycles, and you have to be very careful of page boundaries when writing to them - FRAM has no pages, so you can freely write to anywhere you like, for as long as you like. You can't with EEPROM, as if you cross the page boundary in any one write command, the address pointer will wrap around to the start of that current page, not the NEXT page as you might think would happen. FRAM vs EEPROM: FRAM ADVANTAGES: - Speed - No page boundaries to worry about - address can be rewritten millions of times FRAM DISADVANTAGES: - Cost For a very nice comparrison and explination, use everyone's chum - Wikipedia Smoke makes things work. When the smoke gets out, it stops! |
||||
| twofingers Guru Joined: 02/06/2014 Location: GermanyPosts: 1133 |
@Jim my2c: If it has to be an affordable solution then I would recommend a 24C256 EEProm (32KBytes, costs ~1$ from china). Endurance: Good enough for more than 20 years! Be not afraid of page boundaries! 
Regards Michael |
||||
| viscomjim Guru Joined: 08/01/2014 Location: United StatesPosts: 925 |
When you say that one has to be careful of page boundaries when writing (eeprom), do you mean if you do a sequential type of operation? I have been playing with the code found HERE, just using the byte read and write from particular address and it seems that you can write to 4096 addresses. Can you give me an idea of what you mean by the page boundaries. Zonker, I am going to go thru the thread about your board again and once I get a better handle on this, I might want to get one of those. I don't have the ability to put the parts on so do you have an assembled version and price? As always, thanks. EDIT... Hi TwoFingers, I just saw your post on the 24C256. Looking at the data sheet, it says... This device also has a page-write capability of up to 64 bytes of data. This device is capable of both random and sequential reads up to the 256K boundary. Does this just apply to doing sequential type writes where I am assuming that you set the start address once and spit out a bunch of data and the chip increments the address automatically? But if you send an address and data byte (one at a time) there is no problem with writing and page boundries? |
||||
| twofingers Guru Joined: 02/06/2014 Location: GermanyPosts: 1133 |
That's correct! 
Edit: To care about "page boundries" is only important if you use "fast write" (writing more than 1 byte at the time). "Fast write" is especially usefull if you need to (over-)write many data (eg erasing the whole EEProm). I use "Fast write" in eeErase(). I think it is the job of the library worrying about the details. Michael |
||||
| Grogster Admin Group Joined: 31/12/2012 Location: New ZealandPosts: 9066 |
Page boundaries come into effect, ANY time you cross a page boundary with sequential writing in any one command. As twofingers says: "Be not afraid of page boundaries." - you just have to be aware that they are there and it is something you need to address(pun INTENDED!) for correct operation of the memory. Using your example EEPROM, with 64-byte pages, "Page 1" of the memory will be addresses 00-63 decimal. Lets assume you write four bytes of data to the EEPROM, starting at address 62 decimal.(&H3E) Now, if you sequentially write four bytes at addresses 62,63,64 and 65, you will cross the page boundary at byte 64(byte 3 of 4 being written, and byte 1 of page 2 kind of thing). Instead of the EEPROM writing the last two bytes to addresses 64 and 65, it will write them to addresses 00 and 01 instead, overwriting any bytes stored there. It is known in the trade as buffer overflow. It is ONLY an issue, if you page write, or sequential write AND cross the boundary in one operation. You could write ten bytes starting anywhere inside that 64 byte page, and not have a problem - it is only if you CROSS the boundary during a sequential write. It is something that confused the hell out of me when I was learning EEPROM chips, so I just don't want you having the same issue!
Someone here did a torture-test of an EEPROM chip a while back, and used a MM chip to count how many writes were done to the same address, until the EEPROM failed at that address, and I think that it was a very, very long time before failure. Smoke makes things work. When the smoke gets out, it stops! |
||||
| twofingers Guru Joined: 02/06/2014 Location: GermanyPosts: 1133 |
The burnt child ... 
Conclusion: If you use the (slower than page mode) random read mode you will have no problems. torture-test Michael PS: Idea: Perhaps I should replace the PAUSES with ACKNOWLEDGE POLLING? timeout=0:DO:timeout=timeout+1:LOOP WHILE MM.I2C = 1 and timeout<1000 '(I2c)NAK=1
|
||||
| Grogster Admin Group Joined: 31/12/2012 Location: New ZealandPosts: 9066 |
Oh, it was YOU that did the torture-test, Michael!!! 
I honestly did not remember that, or I would have been more specific when I mentioned it! Smoke makes things work. When the smoke gets out, it stops! |
||||
| twofingers Guru Joined: 02/06/2014 Location: GermanyPosts: 1133 |
never mind! I'm not soo vain! |
||||
| viscomjim Guru Joined: 08/01/2014 Location: United StatesPosts: 925 |
Excellent information. Now off to try this. Twofingers, I like the idea of the ack polling. I will give that a whirl also. |
||||
| twofingers Guru Joined: 02/06/2014 Location: GermanyPosts: 1133 |
This could result in a more reliable code. Because sometimes WRITE works with a very short PAUSE and another time (depending on Vcc??) do I have the PAUSE to increase to avoid errors. Maybe ack polling will prevent this. Michael |
||||
 Print this page |
