Making best use of EEPROM Page Memory

[Tom Gonser]

Folks:

I have a program that collects 36 bytes per pass, and wants to write this to EEPROM. I am using a big chip, the 24LC512 which can hold:

512000 bits or 64000 Bytes

BUT, its page size is 128... So I am forced to increment my address by 128 each time I write 36 bytes!!

Therefore, If i use the page write [string\36], I use only a little bit of the total chip capacity -- only 36 bytes of each 128. Really only able to use 28% of the memory...

SO, what to do?

1. Write a byte at a time? I suppose I could make a loop after I pick up the 36 byte string, and :

oldaddress ' where we last wrote

for X = oldaddress to (oldaddress+35)
I2cwrite DPIN, CPIN, Chip1, X, string[x],failw
wait 10
next x

The problem is that this will take 36 * 10 ms or .36 seconds.. tooo long!


2. Somehow store up 3 strings and write them every 3rd pass?
bigstring[108] = string[36] + string2[36] + string3[36]

...then write bigstring\108 into memory on each page, thereby only wasting 20 bytes per page??

Problem there is I think the biggest array is 96.. (and I don't know how to make a big array out of smaller ones.

3. ?????

Someone must have some really good ideas about how to deal with this as I am sure it is really common.

Thanks

Tom

[mister_e]

if timing is really important, you can use Ramtron's FRAM that don't need any delay between each byte write. They work the same way or almost as your 24LC512

BUT there's probably somebody else here who can provide a better solution.

question only for my own knowledge here... for once... AND NO I DIDN'T compare both... i feel lazy today Is there a big difference between SRAM and FRAM in access speed? OR i'm just comparing orange and potatoe?

[Tom Gonser]

Thanks --

I have some FRAM coming for testing. I was wondering if there were other programming methods folks have tried (Like cramming data into 128byte pages) somehow to use the less expensive serial EEPROMS..

The FRAM is 3x the cost!!

[Dave]

Tom, I beg to differ. The page size of the 24LC512 is 64 bytes. I know this as I have been using it for logging depth and temperature of a towable apparatus used for fishing.

Dave Purola,
N8NTA

[Tom Gonser]

Hmm.. Mine fail at 64b page writes, and a review of the data sheet it clearly says 128. The 24LC51*5* is 64by pagewrite... but it also needs to switch address blocks at 256kbits (upper and lower). the 512 is one block of bits.

TG

So nobody has invented a better scheme of using EEPROM pages... ack. Has anyone used Compact Flash with PB Pro then? I see the Proton+ development environment supports CF commands but I don't know about PBP...

[Archilochus]

Has anyone used Compact Flash with PB Pro then? I see the Proton+ development environment supports CF commands but I don't know about PBP...

Hi Tom,
Check here for PicBASIC code to write/read MMC / SD cards. The 'free' software version does not handle FAT formatting of the cards for use with Windows.

http://www.compsys1.com/workbench/On_top_of_the_Bench/MMC_Project/mmc_project.html

Arch

[Tom Gonser]

Thanks for the pointer. I assume with this kind of setup, the strategy is to write 512bytes or so to EEPROM, (in my case 14.2 records) actually 14 records, and I guess nothing goes in the last '.2'.. (also what happens when I read it back? Does the extra unused space show up in read data as $ffff or something?)

Then, a routine writes from EEPROM to the SD card. Then we'd increment the sector on the SD card and keep going?

I see that there is code available to write to FAT 16 formatted cards also - for my project this would be a big benefit. However, I don't know much about the SD formats, etc.

1. Are SD cards pre-formatted as Fat16?
2. If it is not formatted as FAT16, is there ANY way to read the data from a PC?
3. What does 'write only one file' mean? I assume just a contigous block of incrementing addresses?

Why does one use SHIFTIN or SHIFTOUT?? Is it for SPI mode?

Tom

[Dave]

Tom, I'm sorry, you are right. I must have been having a serior moment..... I am using the 24LC515.... Oh well, Next time I'll keep my mouth shut......

Dave Purola,
N8NTA