Anyone used the ATMEL EEPROMs? Just a curiousity question. I was
wondering why the 8 byte write limitation on a single write (page)?
Not only that, if you write somewhere in the middle of the 8 byte
page, you have to end the write at the end of the page and issue
another write at the beginning of the next, even though the addresses
are sequential. The Read has no such restriction. Why is it designed
like that? I have written all the functions to handle all cases (I
think) so that the top level function call is fully transparent to all
the details. But, it takes up valuable code space because of this
restriction.
Sutton
LPC2148 with SPI EEPROM
Started by ●July 19, 2006
Reply by ●July 19, 20062006-07-19
Page write is an enhancement designed to speed up writing to eeproms.
As you know, EEPROM write access is slow (milliseconds per write).
You are trying to cause tunnelling of hot electrons across an
insulating layer, and waiting until enough have tunnelled across to
reliably shift a transistor threshold voltage up or down.
To speed up writes, rather than organise the eeprom as (say) 8k x 8,
it is organised as (in this case) 1k x 64 with the ability to write
part of a 64-bit word.
So you can preload up to 8 bytes - as long as they all share the same
high 10 address lines - into the write latch and then have the write cycle.
Of course if the bytes to write do not share the same high address
lines then there are two (or more) (partial) 64-bit words to write.
Read is fast. Well it must be because you get the result there and then!
Atmel have chosen the 64-bit width because some circuits need to be
duplicated for each bit. It is a compromise between chip area and
bulk writing speed.
If EEPROM write is too slow / complicated, you might also consider
FRAM from RAMTRON. I have used it without problems.
I have also seen mention of MRAM - Freescale have released one
product. Has anyone tried it (or other MRAM devices)?
Regards,
Danish
--- In l..., "Sutton Mehaffey" wrote:
>
> Anyone used the ATMEL EEPROMs? Just a curiousity question. I was
> wondering why the 8 byte write limitation on a single write (page)?
> Not only that, if you write somewhere in the middle of the 8 byte
> page, you have to end the write at the end of the page and issue
> another write at the beginning of the next, even though the addresses
> are sequential. The Read has no such restriction. Why is it designed
> like that? I have written all the functions to handle all cases (I
> think) so that the top level function call is fully transparent to all
> the details. But, it takes up valuable code space because of this
> restriction.
>
> Sutton
>
As you know, EEPROM write access is slow (milliseconds per write).
You are trying to cause tunnelling of hot electrons across an
insulating layer, and waiting until enough have tunnelled across to
reliably shift a transistor threshold voltage up or down.
To speed up writes, rather than organise the eeprom as (say) 8k x 8,
it is organised as (in this case) 1k x 64 with the ability to write
part of a 64-bit word.
So you can preload up to 8 bytes - as long as they all share the same
high 10 address lines - into the write latch and then have the write cycle.
Of course if the bytes to write do not share the same high address
lines then there are two (or more) (partial) 64-bit words to write.
Read is fast. Well it must be because you get the result there and then!
Atmel have chosen the 64-bit width because some circuits need to be
duplicated for each bit. It is a compromise between chip area and
bulk writing speed.
If EEPROM write is too slow / complicated, you might also consider
FRAM from RAMTRON. I have used it without problems.
I have also seen mention of MRAM - Freescale have released one
product. Has anyone tried it (or other MRAM devices)?
Regards,
Danish
--- In l..., "Sutton Mehaffey" wrote:
>
> Anyone used the ATMEL EEPROMs? Just a curiousity question. I was
> wondering why the 8 byte write limitation on a single write (page)?
> Not only that, if you write somewhere in the middle of the 8 byte
> page, you have to end the write at the end of the page and issue
> another write at the beginning of the next, even though the addresses
> are sequential. The Read has no such restriction. Why is it designed
> like that? I have written all the functions to handle all cases (I
> think) so that the top level function call is fully transparent to all
> the details. But, it takes up valuable code space because of this
> restriction.
>
> Sutton
>
Reply by ●July 19, 20062006-07-19
I'll second the recommendation for FRAM.
Much faster.
No page write size restrictions.
In practice no need to worry about write cycling (no need for wear
levelling).
Cheaper ! Yup that was the case for the 16k parts anyway.
Both SPI and IIC versions.
Lower current writing.
So why would you use an EEprom ?
We did have an issue with data corruption once, but it turned out to be
a bug in our 8051 assembly code, not the FRAM device.
(I have no connection with RamTron other than being a satisfied
customer).
________________________________
From: l... [mailto:l...]
On Behalf Of Danish Ali
Sent: Thursday, 20 July 2006 3:50 AM
To: l...
Subject: [lpc2000] Re: LPC2148 with SPI EEPROM
Page write is an enhancement designed to speed up writing to
eeproms.
As you know, EEPROM write access is slow (milliseconds per
write).
You are trying to cause tunnelling of hot electrons across an
insulating layer, and waiting until enough have tunnelled across
to
reliably shift a transistor threshold voltage up or down.
To speed up writes, rather than organise the eeprom as (say) 8k
x 8,
it is organised as (in this case) 1k x 64 with the ability to
write
part of a 64-bit word.
So you can preload up to 8 bytes - as long as they all share the
same
high 10 address lines - into the write latch and then have the
write cycle.
Of course if the bytes to write do not share the same high
address
lines then there are two (or more) (partial) 64-bit words to
write.
Read is fast. Well it must be because you get the result there
and then!
Atmel have chosen the 64-bit width because some circuits need to
be
duplicated for each bit. It is a compromise between chip area
and
bulk writing speed.
If EEPROM write is too slow / complicated, you might also
consider
FRAM from RAMTRON. I have used it without problems.
I have also seen mention of MRAM - Freescale have released one
product. Has anyone tried it (or other MRAM devices)?
Regards,
Danish
--- In l...
, "Sutton Mehaffey"
wrote:
>
> Anyone used the ATMEL EEPROMs? Just a curiousity question. I
was
> wondering why the 8 byte write limitation on a single write
(page)?
> Not only that, if you write somewhere in the middle of the 8
byte
> page, you have to end the write at the end of the page and
issue
> another write at the beginning of the next, even though the
addresses
> are sequential. The Read has no such restriction. Why is it
designed
> like that? I have written all the functions to handle all
cases (I
> think) so that the top level function call is fully
transparent to all
> the details. But, it takes up valuable code space because of
this
> restriction.
>
> Sutton
>
Much faster.
No page write size restrictions.
In practice no need to worry about write cycling (no need for wear
levelling).
Cheaper ! Yup that was the case for the 16k parts anyway.
Both SPI and IIC versions.
Lower current writing.
So why would you use an EEprom ?
We did have an issue with data corruption once, but it turned out to be
a bug in our 8051 assembly code, not the FRAM device.
(I have no connection with RamTron other than being a satisfied
customer).
________________________________
From: l... [mailto:l...]
On Behalf Of Danish Ali
Sent: Thursday, 20 July 2006 3:50 AM
To: l...
Subject: [lpc2000] Re: LPC2148 with SPI EEPROM
Page write is an enhancement designed to speed up writing to
eeproms.
As you know, EEPROM write access is slow (milliseconds per
write).
You are trying to cause tunnelling of hot electrons across an
insulating layer, and waiting until enough have tunnelled across
to
reliably shift a transistor threshold voltage up or down.
To speed up writes, rather than organise the eeprom as (say) 8k
x 8,
it is organised as (in this case) 1k x 64 with the ability to
write
part of a 64-bit word.
So you can preload up to 8 bytes - as long as they all share the
same
high 10 address lines - into the write latch and then have the
write cycle.
Of course if the bytes to write do not share the same high
address
lines then there are two (or more) (partial) 64-bit words to
write.
Read is fast. Well it must be because you get the result there
and then!
Atmel have chosen the 64-bit width because some circuits need to
be
duplicated for each bit. It is a compromise between chip area
and
bulk writing speed.
If EEPROM write is too slow / complicated, you might also
consider
FRAM from RAMTRON. I have used it without problems.
I have also seen mention of MRAM - Freescale have released one
product. Has anyone tried it (or other MRAM devices)?
Regards,
Danish
--- In l...
, "Sutton Mehaffey"
wrote:
>
> Anyone used the ATMEL EEPROMs? Just a curiousity question. I
was
> wondering why the 8 byte write limitation on a single write
(page)?
> Not only that, if you write somewhere in the middle of the 8
byte
> page, you have to end the write at the end of the page and
issue
> another write at the beginning of the next, even though the
addresses
> are sequential. The Read has no such restriction. Why is it
designed
> like that? I have written all the functions to handle all
cases (I
> think) so that the top level function call is fully
transparent to all
> the details. But, it takes up valuable code space because of
this
> restriction.
>
> Sutton
>
