I was testing external I2C 24LC256 EEPROM from microchip to see
How long it takes to write each byte. Based on my test writing 30 bytes
Takes 200 ms (6.6 ms per byte). I am not sure if I am in I2C fast mode
but the software setting indicates that I2C is in fast mode. My question
is
does 6.6 ms sounds like I am in fast mode? I was wondering how do I
calculate how fast the clock should be on fast mode. I know it is
400,000 bits per second. I just checked clock speed "on time" is 32us.
Thanks
Andre
IMPORTANT NOTICE: This notice constitutes Proprietary Rights identification of this email including all attachments, which is property that is intended only for the use of the individual or entity to which it is addressed. It also may contain proprietary data or information that is privileged, confidential, or otherwise protected from disclosure under applicable law. The recipient of this data agrees to abide by the United States Export Control of Technical Data and Equipment under the International Traffic in Arms Regulations (ITAR) and Export Administration Regulations (EAR). The recipient agrees to abide by these laws and their regulations not only for export and re-export, but for disclosure to non-U.S. citizens. This email does not grant or assign rights of ownership in the proprietary subject matter herein, nor shall it be construed as a joint venture, partnership, teaming agreement, or other formal business relationship. If the reader of this e-mail transmission!
is not the intended recipient or the employee or agent responsible for delivering the transmission to the intended recipient, you are hereby notified that any dissemination, distribution, copying or use of this e-mail or its contents is strictly prohibited. Please notify the sender you received it in error by responding to the e-mail and then permanently delete it and all copies of the e-mail immediately, including any copies of it in your deleted email folder.
> Hi to all,
>
> I was testing external I2C 24LC256 EEPROM from microchip to see
> How long it takes to write each byte. Based on my test writing 30 bytes
> Takes 200 ms (6.6 ms per byte). I am not sure if I am in I2C fast mode
> but the software setting indicates that I2C is in fast mode. My question
> is
> does 6.6 ms sounds like I am in fast mode? I was wondering how do I
> calculate how fast the clock should be on fast mode. I know it is
> 400,000 bits per second. I just checked clock speed "on time" is 32us.
>
> Thanks
>
> Andre
There are two different issues here. One is the speed of the I2C bus, and
the other is the write time of the chip. The datasheet says the write time
is typically 5ms. If you write a byte at a time, it will typically take
5ms plus the amount of time for you to send the command over I2C. However,
you can write a page at a time (64 bytes) in that same period of time (the
typical 5ms write, it clearly takes more time to send 64 bytes of data
over the I2C than it takes to send one).
As far as the I2C clock speed, I'd look on a scope or logic analyzer to
see what's really going on.
Andre Abelian wrote:
> Hi to all,
>
> I was testing external I2C 24LC256 EEPROM from microchip to see
> How long it takes to write each byte. Based on my test writing 30 bytes
> Takes 200 ms (6.6 ms per byte).
Sounds reasonable, doesn't it ?
The write time is 5 ms, add some time for the transfer.
> Hi to all,
>
> I was testing external I2C 24LC256 EEPROM from microchip to see
> How long it takes to write each byte. Based on my test writing 30 bytes
> Takes 200 ms (6.6 ms per byte). I am not sure if I am in I2C fast mode
> but the software setting indicates that I2C is in fast mode. My question
> is
> does 6.6 ms sounds like I am in fast mode? I was wondering how do I
> calculate how fast the clock should be on fast mode. I know it is
> 400,000 bits per second. I just checked clock speed "on time" is 32us.
>
> Thanks
>
> Andre
>
> IMPORTANT NOTICE: This notice constitutes Proprietary Rights identification of this email including all attachments, which is property that is intended only for the use of the individual or entity to which it is addressed. It also may contain proprietary data or information that is privileged, confidential, or otherwise protected from disclosure under applicable law. The recipient of this data agrees to abide by the United States Export Control of Technical Data and Equipment under the International Traffic in Arms Regulations (ITAR) and Export Administration Regulations (EAR). The recipient agrees to abide by these laws and their regulations not only for export and re-export, but for disclosure to non-U.S. citizens. This email does not grant or assign rights of ownership in the proprietary subject matter herein, nor shall it be construed as a joint venture, partnership, teaming agreement, or other formal business relationship. If the reader of this e-mail transmissio
n!
> is not the intended recipient or the employee or agent responsible for delivering the transmission to the intended recipient, you are hereby notified that any dissemination, distribution, copying or use of this e-mail or its contents is strictly prohibited. Please notify the sender you received it in error by responding to the e-mail and then permanently delete it and all copies of the e-mail immediately, including any copies of it in your deleted email folder.
>
>
> -
To me it doesn't sound reasonable but what can I do. I tested to write 32768
bytes
It takes 4.5 minutes. I tested internal EEPROM takes 3 ms per byte.
I am going to try FRAM like Bob suggested.
> Hi to all,
>
> I was testing external I2C 24LC256 EEPROM from microchip to see
> How long it takes to write each byte. Based on my test writing 30 bytes
> Takes 200 ms (6.6 ms per byte). I am not sure if I am in I2C fast mode
> but the software setting indicates that I2C is in fast mode. My question
> is
> does 6.6 ms sounds like I am in fast mode? I was wondering how do I
> calculate how fast the clock should be on fast mode. I know it is
> 400,000 bits per second. I just checked clock speed "on time" is 32us.
>
> Thanks
>
> Andre
>
> IMPORTANT NOTICE: This notice constitutes Proprietary Rights
identification of this email including all attachments, which is property
that is intended only for the use of the individual or entity to which it is
addressed. It also may contain proprietary data or information that is
privileged, confidential, or otherwise protected from disclosure under
applicable law. The recipient of this data agrees to abide by the United
States Export Control of Technical Data and Equipment under the
International Traffic in Arms Regulations (ITAR) and Export Administration
Regulations (EAR). The recipient agrees to abide by these laws and their
regulations not only for export and re-export, but for disclosure to
non-U.S. citizens. This email does not grant or assign rights of ownership
in the proprietary subject matter herein, nor shall it be construed as a
joint venture, partnership, teaming agreement, or other formal business
relationship. If the reader of this e-mail transmissio
n!
> is not the intended recipient or the employee or agent responsible for
delivering the transmission to the intended recipient, you are hereby
notified that any dissemination, distribution, copying or use of this e-mail
or its contents is strictly prohibited. Please notify the sender you
received it in error by responding to the e-mail and then permanently delete
it and all copies of the e-mail immediately, including any copies of it in
your deleted email folder.
>
>
> -
> To me it doesn't sound reasonable but what can I do. I tested to write
> 32768
> bytes
> It takes 4.5 minutes. I tested internal EEPROM takes 3 ms per byte.
> I am going to try FRAM like Bob suggested.
Consider the read-cycles lifetime spec when using FRAM.
While EEPROM generally has an unlimited read-cycles lifetime, FRAM may not.
On some older models this was finite and caused some people bad surprises.
On newer versions this may be larger or even unlimited - but do be aware
what the spec is for your part and whether it affects your design.
Andre Abelian wrote:
> To me it doesn't sound reasonable but what can I do. I tested to
> write 32768 bytes It takes 4.5 minutes.
That comes out to 8.2mS per byte. That is plausible if you are doing
individual byte writes, but of course you should be doing page mode writes.
That will make things much faster.
> That comes out to 8.2mS per byte. That is plausible if you are doing
> individual byte writes, but of course you should be doing page mode
> writes.
> That will make things much faster.
>> I am going to try FRAM like Bob suggested.
> Or learn to use the EEPROM you have properly.
Surely that's cutting the garment to suit the cloth.
If someone wants to do individual byte writes then being forced to do page
writes to suit a hardware shortcoming *may* justify the use of a different
technology. This obviously depends on the application and resource
availability or perhaps how much the user is happy to have the hardware lead
him by the nose, BUT "using something properly" where the item is of low
capability is not necessarily the same as 'doing the job well'. But, you
know that.
> -----Original Message-----
> From: @spam@piclist-bouncesKILLspammit.edu [KILLspampiclist-bouncesKILLspammit.edu] On
Behalf
> Of Apptech
> Sent: 24 September 2008 13:36
> To: Microcontroller discussion list - Public.
> Subject: Re: [pic:] I2C EEPROM write speed ?
>
> >> ... to write 32768 bytes It takes 4.5 minutes.
>
> > That comes out to 8.2mS per byte. That is plausible if you are
doing
> > individual byte writes, but of course you should be doing page mode
> > writes.
> > That will make things much faster.
>
> >> I am going to try FRAM like Bob suggested.
>
> > Or learn to use the EEPROM you have properly.
>
> Surely that's cutting the garment to suit the cloth.
> If someone wants to do individual byte writes then being forced to do
page
> writes to suit a hardware shortcoming *may* justify the use of a
different
> technology. This obviously depends on the application and resource
> availability or perhaps how much the user is happy to have the
hardware
> lead
> him by the nose, BUT "using something properly" where the item is of
low
> capability is not necessarily the same as 'doing the job well'. But,
you
> know that.
Agreed. The mitigating (but circumstantial!) evidence in this case is
that the OP has complained that it takes 4.5 minutes to fill a 32kbyte
device. If you have 32kbytes of data to write as quickly as possible, I
struggle to think of a good reason not to use the page buffer.
Regards
Mike
=======================================================================
This e-mail is intended for the person it is addressed to only. The
information contained in it may be confidential and/or protected by
law. If you are not the intended recipient of this message, you must
not make any use of this information, or copy or show it to any
person. Please contact us immediately to tell us that you have
received this e-mail, and return the original to us. Any use,
forwarding, printing or copying of this message is strictly prohibited.
No part of this message can be considered a request for goods or
services.
=======================================================================
> Of Andre Abelian
> Sent: 24 September 2008 17:07
> To: Microcontroller discussion list - Public.
> Subject: RE: [pic:] I2C EEPROM write speed ?
>
> What do you think I need to learn more about EEPROM?
> CCS Compiler I am using doesn't support page mode byte mode only.
>
> thanks
>
> Andre
This is an excellent reason not to blindly use the libraries that come
with development tools. Does the library not provide low level I2C
functionality, e.g. start/stop/read byte/write byte etc? If you learn
how the EEPROM works you can use this functionality to invoke page
writes.
Regards
Mike
=======================================================================
This e-mail is intended for the person it is addressed to only. The
information contained in it may be confidential and/or protected by
law. If you are not the intended recipient of this message, you must
not make any use of this information, or copy or show it to any
person. Please contact us immediately to tell us that you have
received this e-mail, and return the original to us. Any use,
forwarding, printing or copying of this message is strictly prohibited.
No part of this message can be considered a request for goods or
services.
=======================================================================
On Wed, 24 Sep 2008 08:20:12 -0700 (PDT), you wrote:
>I've written a few C functions for dealing with external page write
>eeprom. I have these functions:
>
>WriteEepFirstByte(address, data) // sets up address, sends data,
>increments static address counter, leaves /CS low
>
>WriteEepNextByte(data) // sends data, increments static address counter,
>does page write if incremented to new page, leaves /CS low
>
>WriteEepLastByte(data) // sends data, does page write, releases /CS
>
>WriteEepOnlyByte(address, data) // writes the specified byte to the
>specified address.
>
As multiple writes are often from sequential memory, a routine that reads/writes a number of
consecutive bytes will often cover most eventualities. Where you have a block of things like
parameters that need reading seperately, this can be handled neatly by either using a union of an
array and individual chars/ints/whatever, or simply #defining the individual parameters as array
elements.
e.g. char params[16];
#define param1 params[1]
#define param2 params[2]
Another thing that can make things neater is have procedures to read/write <n> bytes to/from memory,
splitting page writes as required so the caller doesn't need to worry about it.
Then have macros that generate <n> from the size of variable used.
below is an example in IAR C for ARM, but the same principle applies for other targets.
do {
kickwatchdog();
lump=(nbytes<=eepagesize)?nbytes:eepagesize;
i=eepagesize-(adr & (eepagesize-1)); // page size - offset within page - max we can write in 1 go
if (lump>i) lump=i; // chop length to page boundary
while(iistart(0xa2)) {I2C0CONCLR=8;} //wait not busy
sendiic(adr>>8);
sendiic(adr);
adr+=lump;
nbytes-=lump;
do sendiic(*dest++); while(--lump);
iistop();
}
while (nbytes);
}
This would be called like
writeeprom(0,param1);
and the correct size of param1 would automatically be fed to the write routine.
Apptech wrote:
> Surely that's cutting the garment to suit the cloth.
> If someone wants to do individual byte writes then being forced to do
> page writes to suit a hardware shortcoming *may* justify the use of a
> different technology.
Right, but so far there has been no evidence of that. He has never
mentioned page mode writes. I think it's a pretty good conclusion that he
either hasn't bothered to read the manual and didn't realize this was
available, or he is scared of it for being "too complicate".
What I have sometimes done is write a low level EEPROM routine that buffers
a whole page in RAM. The accesses to this routine can be random, and it
only does a write if the next address is not on the same page as the
current. Most of the time writes are sequential, but this insulates the
upper levels from the low level detail of the page size and alignment, and
is generally efficient.
Andre Abelian wrote:
> What do you think I need to learn more about EEPROM?
How to use page mode, obviously.
> CCS Compiler I am using doesn't support page mode byte mode only.
Well, duh! So if the compiler doesn't come with a library call to do what
you want, you're screwed? Does this compiler have a special license that
prohibits you from thinking for yourself, accessing the PIC registers
directly, or even writing a subroutine or two in assembler if necessary?
If you can't handle low level stuff like this unless someone supplies it on
a silver platter, go back to Java programming on a large machine and leave
microcontrollers to someone else.
Andre Abelian escreveu:
> What do you think I need to learn more about EEPROM?
> CCS Compiler I am using doesn't support page mode byte mode only.
>
> thanks
>
> Andre
>
>
Write your own routines to deal with the EEPROM (or get someone's else
routines).
Page writes may speed-up things tens of times (depending on your
EEPROM), but only if you write lots of contiguous bytes.
If you are writing only sparse bytes then there is little you may do .
__________________________________________________
Faça ligações para outros computadores com o novo Yahoo! Messenger http://br.beta.messenger.yahoo.com/
According to 24lc256 datasheet EEPROM itself only stores the 64 byte of data
In temporary storage I am assuming in RAM then after the master generates
Stop condition then eeprom itself will write all 64 bytes of data. Here is the copy from the datasheet. This method is good to save CPU time.
Page mode:
The write control byte, word address and the first data
byte are transmitted to the 24XX256 in much the same
way as in a byte write. The exception is that instead of
generating a Stop condition, the master transmits up to
63 additional bytes, which are temporarily stored in the
on-chip page buffer, and will be written into memory
once the master has transmitted a Stop condition.
> Andre Abelian wrote:
>> What do you think I need to learn more about EEPROM?
>
> How to use page mode, obviously.
>
>> CCS Compiler I am using doesn't support page mode byte mode only.
>
> Well, duh! So if the compiler doesn't come with a library call to
> do what
> you want, you're screwed? Does this compiler have a special license
> that
> prohibits you from thinking for yourself, accessing the PIC registers
> directly, or even writing a subroutine or two in assembler if
> necessary?
>
> If you can't handle low level stuff like this unless someone
> supplies it on
> a silver platter, go back to Java programming on a large machine and
> leave
> microcontrollers to someone else.
Thanks for being such a cheery note in our otherwise dreary
conversation!
>I think it's a pretty good conclusion that he either hasn't
>bothered to read the manual and didn't realize this was
>available, or he is scared of it for being "too complicate".
Shades of a guy I once had dealings with many years ago, that didn't
understand DMA, so did not use it when attempting to interface to a floppy
disc controller. The result was he couldn't get the necessary transfer speed
to get the full disc capacity.
>According to 24lc256 datasheet EEPROM itself only stores the
>64 byte of data In temporary storage I am assuming in RAM then
>after the master generates Stop condition then eeprom itself
>will write all 64 bytes of data.
Right, now you are learning. The next trick is that those 64 bytes of data
get written in the same time as a single byte, i.e. the 6.5mS that you have
been seeing. So by writing your 32kB code in 64 bit chunks instead of a byte
at a time, you will speed the write time by 64 times, so your 270 seconds
(4.5 minutes) comes down to 4.2 seconds for 32kB!!!
Maybe I didn't explain clearly. In page mode the EEPROM only takes 64
bytes and doesn't write it just buffers it right after stop condition
showed up
It will spend it's own time to write it. Since it does it by itself we
do not see how long it takes. Make it short there is no fast write this
is just a work around or another method of writing that will free up CPU
time in background. I just tested: right after page right the pic will
turns off the EEPROM Power the EEPROM only stored a few bytes. I am not
too far to find out how long inside external EEPROM takes to write all
64 bytes of data.
The reason I am turning it off because of I need to write data after
power
Disconnection and this is USB device and I only have 10ms time to write
64 bytes.
>Maybe I didn't explain clearly. In page mode the EEPROM only takes 64
>bytes and doesn't write it just buffers it right after stop condition
>showed up
>It will spend it's own time to write it. Since it does it by itself we
>do not see how long it takes. Make it short there is no fast write this
>is just a work around or another method of writing that will free up CPU
>time in background. I just tested: right after page right the pic will
>turns off the EEPROM Power the EEPROM only stored a few bytes. I am not
>too far to find out how long inside external EEPROM takes to write all
>64 bytes of data.
>The reason I am turning it off because of I need to write data after
>power
>Disconnection and this is USB device and I only have 10ms time to write
>64 bytes.
This doesn't make sense.
If you are turning off power to the EEPROM immediately after telling it to
do a write, how has it written single bytes before, and how have you managed
to write 32kB.
The time to write the 64-bytes page is the same as to write one byte,
around 5ms.
The only thing that changes is the transfer time, that is not 64 times
longer, just 17.75 times (71 bytes against 4 bytes).
> Alan,
>
> Maybe I didn't explain clearly. In page mode the EEPROM only takes 64
> bytes and doesn't write it just buffers it right after stop condition
> showed up
> It will spend it's own time to write it. Since it does it by itself we
> do not see how long it takes. Make it short there is no fast write this
> is just a work around or another method of writing that will free up CPU
> time in background. I just tested: right after page right the pic will
> turns off the EEPROM Power the EEPROM only stored a few bytes. I am not
> too far to find out how long inside external EEPROM takes to write all
> 64 bytes of data.
> The reason I am turning it off because of I need to write data after
> power
> Disconnection and this is USB device and I only have 10ms time to write
> 64 bytes.
>
> Thanks
>
> Andre
>
>
__________________________________________________
Faça ligações para outros computadores com o novo Yahoo! Messenger http://br.beta.messenger.yahoo.com/
Isaac Marino Bavaresco escreveu:
> The time to write the 64-bytes page is the same as to write one byte,
> around 5ms.
> The only thing that changes is the transfer time, that is not 64 times
> longer, just 17.75 times (71 bytes against 4 bytes).
>
Oops! 16.75 times, 67 bytes against 4 bytes), sorry!
> To write 1 byte:
>
> <START>, 0xa0, <address high>, <address low>, <data>, <STOP>
>
> To write 64 bytes:
>
> <START>, 0xa0, <address high>, <address low>, <data0>, <data1>, ...,
> <data63>, <STOP>
>
> Be careful to ensure the writes don't overflow from one page to the
> next, that is not allowed.
>
>
__________________________________________________
Faça ligações para outros computadores com o novo Yahoo! Messenger http://br.beta.messenger.yahoo.com/
All of this I am doing to see how the page mode works.
I am turning the power off after the 64 byte routine is completed
to see if it is writing to EEPROM RAM or not.
What I am trying to do is to find out how long it takes inside external EEPROM to complete all 64 byte write. This 5ms that every one is mentioning it is only for writing EEPROM's buffer. After EEPROM got all 64 bytes it starts doing real write. It is very clever idea who ever came up.
That's why after write I turned the EEPROM's power off it didn't even have
enough time to write all data.
On Thu, Sep 25, 2008 at 03:15:52PM -0400, Andre Abelian wrote:
> Alan,
>
> All of this I am doing to see how the page mode works.
> I am turning the power off after the 64 byte routine is completed
> to see if it is writing to EEPROM RAM or not.
It still takes time to write the 64 bytes after they have been transferred.
That time is the same amount to write a single byte, about 5ms.
Try this:
1) Transfer 64 bytes.
2) Send the stop condition.
3) Wait 5ms.
4) Turn off power to the EEPROM.
This is an accurate test of if the 64 bytes get written in that 5ms window.
> On Thu, Sep 25, 2008 at 03:15:52PM -0400, Andre Abelian wrote:
>> Alan,
>>
>> All of this I am doing to see how the page mode works.
>> I am turning the power off after the 64 byte routine is completed
>> to see if it is writing to EEPROM RAM or not.
I'm not sure if I'm missunderstanding here...
> after the 64 byte routine is completed...
Is that the write routine in the *PIC* ?
I guess that the actual write inside the EEPROM
is "self-timed" and you have to either wait (with
some margin) or try to access the device (it will
probably not answer until the self-timed write
is completed) before powering off.
B.t.w, this acual case (saving data on power loss)
is an perfect application for a RAMTRON device
due to it's very fast write time (writes at full
SPI speed with no waits at all).
On Thu, Sep 25, 2008 at 03:15:52PM -0400, Andre Abelian wrote:
> Alan,
>
> All of this I am doing to see how the page mode works.
> I am turning the power off after the 64 byte routine is completed
> to see if it is writing to EEPROM RAM or not.
It still takes time to write the 64 bytes after they have been
transferred.
That time is the same amount to write a single byte, about 5ms.
Try this:
1) Transfer 64 bytes.
2) Send the stop condition.
3) Wait 5ms.
4) Turn off power to the EEPROM.
This is an accurate test of if the 64 bytes get written in that 5ms
window.
Behalf
> Of Alan B. Pearce
> Sent: Thursday, September 25, 2008 9:49 AM
> To: Microcontroller discussion list - Public.
> Subject: Re: [pic:] I2C EEPROM write speed ?
>
> >Maybe I didn't explain clearly. In page mode the EEPROM only takes 64
> >bytes and doesn't write it just buffers it right after stop condition
> >showed up
> >It will spend it's own time to write it. Since it does it by itself
we
> >do not see how long it takes. Make it short there is no fast write
this
> >is just a work around or another method of writing that will free up
> CPU
> >time in background. I just tested: right after page right the pic
will
> >turns off the EEPROM Power the EEPROM only stored a few bytes. I am
not
> >too far to find out how long inside external EEPROM takes to write
all
> >64 bytes of data.
> >The reason I am turning it off because of I need to write data after
> >power
> >Disconnection and this is USB device and I only have 10ms time to
write
> >64 bytes.
>
> This doesn't make sense.
>
> If you are turning off power to the EEPROM immediately after telling
it
> to
> do a write, how has it written single bytes before, and how have you
> managed
> to write 32kB.
>
> And what does USB have to do with an I2C EEPROM?
>
>
> -
I'm positively sure that the 5ms is the real write time to the EEPROM
memory. I used and yet use this type of device, and the data-sheet is
very clear about what time the parameter Twr refers to, which starts
after the STOP condition is generated by the micro-controller.
The time needed to fill the RAM buffer is just the time it takes to
transfer the bytes from the micro-controller.
Perhaps you are turning the device off too soon. Try to wait at least
the 5ms (a little more is better, just to be sure).
Before testing the forced turn-off method, try writing and reading the
data back without powering it off, just to be sure you are doing things
right.
If this do not work, then you are making some mistake.
If I got it right, you have a device that may be unplugged at any time
and you want to ensure that all data get written before the system loses
all its power.
For this, I connect a diode between the system's VCC (anode) and the
chip's VCC (cathode), and add a bulk capacitor between the chip's VCC
and GND.
And of course some circuit to generate an interrupt to the
micro-controller when the power is going off.
Andre Abelian escreveu:
> Isaac,
>
> What I am trying to do is to find out how long it takes inside external EEPROM to complete all 64 byte write. This 5ms that every one is mentioning it is only for writing EEPROM's buffer. After EEPROM got all 64 bytes it starts doing real write. It is very clever idea who ever came up.
> That's why after write I turned the EEPROM's power off it didn't even have
> enough time to write all data.
>
> Thanks
>
> Andre
>
__________________________________________________
Faça ligações para outros computadores com o novo Yahoo! Messenger http://br.beta.messenger.yahoo.com/
> -----Original Message-----
> From: RemoveMEpiclist-bouncesEraseMEEraseMEmit.edu On Behalf Of Andre Abelian
> Sent: Thursday, September 25, 2008 3:26 PM
>
> Isaac,
>
> What I am trying to do is to find out how long it takes
> inside external EEPROM to complete all 64 byte write. This
> 5ms that every one is mentioning it is only for writing
> EEPROM's buffer. After EEPROM got all 64 bytes it starts
> doing real write. It is very clever idea who ever came up.
Assuming you're using a Microchip 24LC256 EEPROM then you should look at the
specs in the data sheet again. From the data sheet "Write cycle time (byte
or page) 5ms". The chip writes the page as bytes in parallel so page mode
really is 64 times faster than byte write when writing 64 bytes.
Paul Hutch
> That's why after write I turned the EEPROM's power off it
> didn't even have
> enough time to write all data.
>
> Thanks
>
> Andre
Gee, that's news to me. I've used the RAMTRON FM24Cxxx for years, and
I can count
on one finger the number of failed devices I found in all that time
from over 20 active designs.
>> To me it doesn't sound reasonable but what can I do. I tested to write
>> 32768
>> bytes
>> It takes 4.5 minutes. I tested internal EEPROM takes 3 ms per byte.
>> I am going to try FRAM like Bob suggested.
>
> Consider the read-cycles lifetime spec when using FRAM.
> While EEPROM generally has an unlimited read-cycles lifetime, FRAM may not.
>
> On some older models this was finite and caused some people bad surprises.
> On newer versions this may be larger or even unlimited - but do be aware
> what the spec is for your part and whether it affects your design.
>
>
> Russell
>
mason-electric.com> wrote:
