Continue to Site

Welcome to our site!

Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

  • Welcome to our site! Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

AT24C32 True Write Cycle Time

Status
Not open for further replies.

MrAl

Well-Known Member
Most Helpful Member
Hello there,

Recently i was testing the DS3231 breakout board and because that also has this EEPROM on it i thought i would test out the EEPROM as well.

This EEPROM has 4096 bytes and they can be written byte by byte or in page style. I usually need to write one byte at a time so i am looking into the actual write cycle time to store (save) one byte only.

The write cycle time is the time it takes for the EEPROM to actually get the data written so that when it is read back the new byte data will be recovered. The question becomes how long this actually takes, because the data sheet says for a 5v power supply "10 milliseconds max" so i write a program to measure the microseconds it takes to return from the "WriteByte" function i wrote using the Wire library.

What is surprising is the time it takes to return from a call to the write function clocks in at 432 microseconds. There's a little overhead for the call, but it is probably not much, so most of that number is probably the write cycle time, but i am not sure about any of this yet.

So the question is, has anyone else attempted to measure this time ?
I know i could turn to a more statistical measuring technique, but i dont want to have to write a ton of data just to get this tested. I need to know how long the program will hang while it writes a couple bytes to the EEPROM.

Any ideas or suggestions?

Thanks.
 
Why not try writing the whole EEPROM. If your calculation is right it should take about 2 seconds. I suggest this as there may be some internal tidying that makes sequential writes slower.

Mike.
 
432 us is very fast for EEPROM.

The time may depend on whether you write a byte which is already erased (set to 0xff), or an arbitrary byte which needs erasing before write.

It is also possible that they have a volatile buffer, which would actually be a very bad feature.
 
Its weird..... One, two, hundred.... The housekeeping is the same.. EEPROM have scratch memories ( a page ) so you write to the page. I think pages are up to 128 bytes... The page is then written internally ( housekeeping ) ...

If you poll the busy ack you will get much faster writes.. I have several EEPROMS and the write time's specified is from 5mS to 20mS..

Since I moved to FRAM... No write delay's atall....
 
432 us is very fast for EEPROM.

The time may depend on whether you write a byte which is already erased (set to 0xff), or an arbitrary byte which needs erasing before write.

It is also possible that they have a volatile buffer, which would actually be a very bad feature.

Hi,

I didnt try too many combinations yet, but i did try writing from 0xFF to 0x01, from 0x01 to 0x03, then from 0x03 to 0x02, so one bit changed from 0 to 1 at least once, and all the writes took 432us, which seemed to be too fast.
I dont think they have a buffer like that, because they spec 10ms write cycle time as a max. Maybe some addresses work faster?
 
Why not try writing the whole EEPROM. If your calculation is right it should take about 2 seconds. I suggest this as there may be some internal tidying that makes sequential writes slower.

Mike.

Hi,

I was hoping i would not have to do that, but i suppose i could try it. If it took 10ms it would take about 40 seconds to write all 4096 bytes. I didnt want to write the whole thing yet, but maybe i have no choice. There's something else going on.
 
Its weird..... One, two, hundred.... The housekeeping is the same.. EEPROM have scratch memories ( a page ) so you write to the page. I think pages are up to 128 bytes... The page is then written internally ( housekeeping ) ...

If you poll the busy ack you will get much faster writes.. I have several EEPROMS and the write time's specified is from 5mS to 20mS..

Since I moved to FRAM... No write delay's atall....

Hi,

Are you saying that the EEPROM has a ram register in there to buffer the byte? That would mean one byte would return fast, but 200 bytes would take much longer per byte.
In the data sheet they state that the EEPROM does not respond until the byte is written, but maybe one byte is faster when there are no bytes following it within the 10ms time space.
 
Hi,

Are you saying that the EEPROM has a ram register in there to buffer the byte? That would mean one byte would return fast, but 200 bytes would take much longer per byte.
In the data sheet they state that the EEPROM does not respond until the byte is written, but maybe one byte is faster when there are no bytes following it within the 10ms time space.

How do you know how long the write actually takes? - essentially you load the data (one byte or more) to the EEPROM, then instruct it to do the write - presumably the initial loading is to RAM (or similar), the chip itself then times the write sequence internally. As already suggested, if you're using EEPROM then use the busy ACK to get the fastest timing - are you perhaps already using that to actually time the write cycle?.
 
Are you saying that the EEPROM has a ram register in there to buffer the byte? That would mean one byte would return fast, but 200 bytes would take much longer per byte.
In the data sheet they state that the EEPROM does not respond until the byte is written, but maybe one byte is faster when there are no bytes following it within the 10ms time space.

The way I read it.... There is some flash inside... Flash cannot be singularly addressed, you have to write a page..

So write a byte to address 6..
End communication..
internal circuitry reads the page alters the byte and puts it back! ( some time passes)

Ready!

Write a compete page..
end communication..
internal circuitry reads the page alters the page and puts it back! ( some time passes).

Time difference = the time it takes to load all the bytes..

Flash has always been this way..
 
It is possible that the page size is 1 (as in old PICs for example).

Never believe the marketing men :p

The old PIC's used EEPROM technology, and NOT FLASH technology (as did the earlier AVR's) - however, Atmel (and others) marketed their EEPROM devices as FLASH, and after a while MicroChip started doing the same.

This was obvious if you wrote PIC programming software (as I did back then), as Ian mentioned the FLASH technology requires block writes, and the EEPROM technology single writes. For anyone who might be vaguely interested?, as I recall you simply write a block at a time, with the last block including any blanks words (all ones) to pad it if required.
 
I suspect the reason behind the hybrid is that EEPROM cells need transistors to read / write every cell.. Flash only need two per page... Nowadays EEPROM's are flash designed to behave like EEPROM's... To write to flash the entire page has to be erased and then re-written... So a small amount of sram as a buffer is an excellent trade off...

I believe a technology called M RAM is available... A bit pricey though.... I'll stick with FeRAM...
 
This was obvious if you wrote PIC programming software (as I did back then), as Ian mentioned the FLASH technology requires block writes, and the EEPROM technology single writes.

They had program memory, which Microchip usually called FLASH, which is written by pages, though pages could be as small as 8 bytes. These devices also had so called "Data EEPROM", which you would erase/write one byte at a time. If you wanted to program "Data EEPROM" with an external device you still would have to erase/write byte-by-byte. Therefore, it could take much longer to program 256 bytes of "Data EEPROM" than it would take to program the entire program FLASH area even if it was several K.
 
They had program memory, which Microchip usually called FLASH, which is written by pages, though pages could be as small as 8 bytes.

You are confused, as I said, early re-programmable devices used EEPROM (single word at a time) technology, only the later ones use FLASH - it's nothing whatsoever to do with the data EEPROM.

The first such device was the 16C84 (which was the device that really started the hobbiest micro-controller scene), this was EEPROM - this was replaced by the 16F84, which also used EEPROM, and was just a later silicon revision of the 16C84 (with some bug fixes). The next device was the 40 pin 18F877, another entirely EEPROM device.

I can't remember now when the first FLASH PIC arrived, but there were a LOT of EEPROM ones before it did - and as I said, all other manufacturers 'FLASH' devices were also EEPROM and not FLASH as well.

Perhaps you are too new to PIC's to remember the earlier ones?.
 
You are confused, as I said, early re-programmable devices used EEPROM (single word at a time) technology, only the later ones use FLASH - it's nothing whatsoever to do with the data EEPROM.

Exactly. You're talking about FLASH. I'm talking about data EEPROM.

Perhaps you are too new to PIC's to remember the earlier ones?.

No. I've never worked with 16C. 16F84 looks very old to me, even 16F84A does :)
 
Exactly. You're talking about FLASH. I'm talking about data EEPROM.

No, as I said you're confused, I'm talking about EEPROM program memory, as all devices were prior to FLASH - even those claiming to be FLASH were originally just EEPROM.

As I said, the transition was obvious if you were writing programming software, as FLASH uses a different method to EEPROM.

No. I've never worked with 16C. 16F84 looks very old to me, even 16F84A does :)

Again, the A version was EEPROM, as was it's later replacement the 16F628 - any FLASH devices are relatively 'recent' :D

I presume anything current has long since been FLASH?, although they still sell 16F84A's (at silly high prices), and I would presume they are still EEPROM else they couldn't be programmed as 16F84A's - could explain their high price, thinking about it.
 
any FLASH devices are relatively 'recent' :D.

That is a different time perspective.

All devices I have ever used were FLASH devices. Among these devices, word "EEPROM" only applies to data storage :)

Most of the devices which I perceive as 'recent' don't even have data EEPROM, only FLASH program memory which is programmable from inside.
 
As far as I'm aware... There is very little difference between flash and EEPROM One uses NOR the other uses NAND!!

The only real difference is the ability to write at speed.... It would appear that over 1Mb serial flash is used.. If it were due to die space I can see why..... If you gated every cell the chip would be the size of a 40 pin micro!!!

MrAl was particular in the EEPROM... The AT24C32.. Nothing to do with pic16f84 vs pic16c84....
 
How do you know how long the write actually takes? - essentially you load the data (one byte or more) to the EEPROM, then instruct it to do the write - presumably the initial loading is to RAM (or similar), the chip itself then times the write sequence internally. As already suggested, if you're using EEPROM then use the busy ACK to get the fastest timing - are you perhaps already using that to actually time the write cycle?.

Hi again,

I used "micros()" in the Arduino library. For example:
Addr=0x02; //address
Bin=0x01; //one byte of data

mst1=micros();
EEprom_WriteByte(Addr,Bin);
mst2=micros();

That is followed by a loop that counts 100's of microseconds using delayMicrosseconds(100); It breaks out of the loop when it finds that a read of the EEPROM produces the same value as Bin above, and the value to start with in the EEPROM before the write is always different than what is being written. It counts the number of times through the loop and then displays that number. the loop starts at zero:
for(int j=0;j<100;j++)
Then i print 'j' just before it breaks:
Serial.println(j);
Serial.println(mst2-mst1);

So the actual call to the EEPROM write byte is timed as well as any extra time it might take for the byte to actually change. what it looks like so far is that the call to the WriteByte takes 432us and then there is no other delay because 'j'y is always zero on exit.

What else i dont know is if the read (which comes later) or the write hangs up the "micros()" function and therefore does not register all the microseconds. I'll have to test more using Ian's idea of writing a whole bunch of bytes i guess and finding the average time.
 
It is possible that the page size is 1 (as in old PICs for example).

Hi,

All i know is what the data sheet says, and it says there is a page size of 32 bytes. So 32 bytes can be written to in one shot, but i will not need that i just need to write one byte to four bytes then not write again for possibly as long as an hour. However, i'd like to know how long it will take in the write loop, even if i decide to write more bytes than four.
 
Status
Not open for further replies.

Latest threads

New Articles From Microcontroller Tips

Back
Top