Searching \ for '[EE] serial eeprom writing speed' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/io/serials.htm?key=serial
Search entire site for: 'serial eeprom writing speed'.

Exact match. Not showing close matches.
PICList Thread
'[EE] serial eeprom writing speed'
2005\04\27@021446 by Aadu Adok

flavicon
face
hi,

I need to store some data (hundreds of bytes) in my PIC interrupt
handler. New byte arrives every 600us. What you think - is serial eeprom
(like 24LC16B) right choice for handling this task?

I looked around but did'nt find how fast can 24LC16B store one byte. Any
ideas?

thanks

2005\04\27@031532 by Jinx

face picon face
> Any ideas?

24AA16/24LC16 datasheet, 370kB

http://ww1.microchip.com/downloads/en/DeviceDoc/21703E.pdf

Twc = 5ms, about the same as the EEPROM in a PIC

The 18Fs have quite abit of RAM, from 512 bytes to at least 3840.
If you're able to use one of these, the data could be stored until you
have time to write it to EEPROM. Otherwise you'll need to maybe
look at external RAM

eg NVRAM

http://www.st.com/stonline/products/families/memories/nvram/

or roll your own with a battery and something like a 6116 or 6264
(out of an old HDD for instance) or cache RAM off an old MoBo

Perhaps even Flash RAM. Entry-level device capacities are much
larger than they used to be though. Don't actually know what the
smallest RAM is now

2005\04\27@054821 by Jose Da Silva

flavicon
face
On April 26, 2005 11:14 pm, Aadu Adok wrote:
> hi,
>
> I need to store some data (hundreds of bytes) in my PIC interrupt
> handler. New byte arrives every 600us. What you think - is serial
> eeprom (like 24LC16B) right choice for handling this task?
>
> I looked around but did'nt find how fast can 24LC16B store one byte.
> Any ideas?

Technically speaking, you should be able to manage if you use "page"
writes of 16 bytes instead of attempting to try and write 1 byte at a
time. You will need to store a page of 16 data bytes on your PIC while
the 24xx chip is writing.

Is this something you plan on doing long term?
Reason asking is that the part is specified reliable for about 100,000
writes, which comes out to about a very short 15 minutes of use:

100,000 x 16 x 600uS = 960 Seconds worth of "reliable" use.

2005\04\27@061004 by Jinx

face picon face
> Technically speaking, you should be able to manage if you use
> "page" writes of 16 bytes instead of attempting to try and write

Twc = 5ms is for byte or page

> 100,000 x 16 x 600uS = 960 Seconds worth of "reliable" use.

x 2048 for the 24LC16

2005\04\27@064013 by Russell McMahon

face
flavicon
face
> Is this something you plan on doing long term?
> Reason asking is that the part is specified reliable for about
> 100,000
> writes, which comes out to about a very short 15 minutes of use:
>
> 100,000 x 16 x 600uS = 960 Seconds worth of "reliable" use.

Note that where maximum possible write times are needed, close
attention to relevant factors that affect cell life can greatly extend
available write cycles.


       RM

2005\04\27@064839 by Wouter van Ooijen

face picon face
> Is this something you plan on doing long term?
> Reason asking is that the part is specified reliable for
> about 100,000
> writes, which comes out to about a very short 15 minutes of use:
>
> 100,000 x 16 x 600uS = 960 Seconds worth of "reliable" use.

Shouldn't that be 100.000 writes *per cell*?

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu


2005\04\27@073701 by olin_piclist

face picon face
Aadu Adok wrote:
> I need to store some data (hundreds of bytes) in my PIC interrupt
> handler. New byte arrives every 600us. What you think - is serial eeprom
> (like 24LC16B) right choice for handling this task?
>
> I looked around but did'nt find how fast can 24LC16B store one byte. Any
> ideas?

A single byte write will almost certainly be slower, but most EEPROMs can
write a "page" of bytes for the same write time.  Pages vary, but I vaguely
remember some of the 24LC series has pages in the 8,16,32 byte size, and the
the write time was a few mS.  This means the average rate is probably
adequate.

A knee jerk architecture that comes to mind is using two buffers each the
size of the EEPROM page.  When the interrupt routine fills one, it sets a
flag and starts filling the other.  The foreground code writes the filled
buffer to the EEPROM when the flag is set, with appropriate bookkeeping
about swapping buffers.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

2005\04\27@093020 by Paul James E.

picon face

All,

Use FRAM.   It's as fast as RAM, pin compatible, and non-volaitle.

Regards,

Jim


{Quote hidden}

> --

2005\04\27@103928 by ThePicMan

flavicon
face
At 22.34 2005.04.27 +1200, you wrote:
>>Is this something you plan on doing long term?
>>Reason asking is that the part is specified reliable for about 100,000
>>writes, which comes out to about a very short 15 minutes of use:
>>
>>100,000 x 16 x 600uS = 960 Seconds worth of "reliable" use.
>
>Note that where maximum possible write times are needed, close attention to relevant factors that affect cell life can greatly extend available write cycles.

Temperature?


2005\04\27@134240 by Byron A Jeff

face picon face
On Wed, Apr 27, 2005 at 08:30:16AM +0500, Paul James E. wrote:
>
>  All,
>
>  Use FRAM.   It's as fast as RAM, pin compatible, and non-volaitle.

And now specifies unlimited writes for many of the parts.

Does anyone know where to get some samples, or small quantities?

BAJ

2005\04\27@142354 by Jose Da Silva

flavicon
face
On April 27, 2005 03:09 am, Jinx wrote:
> > Technically speaking, you should be able to manage if you use
> > "page" writes of 16 bytes instead of attempting to try and write
>
> Twc = 5ms is for byte or page

at 1 byte received per 600uS, you would receive 16 bytes in:
16 x 600uS = 9.6mS which leaves you about 4.6mS to verify the last
write, setup the next 16 to write and 5mS (max) for writing a page.

4.6mS is short for a 2nd write, so it would have to be some elaborate
software routine in case the last write didn't verify as correctly
written.

> > 100,000 x 16 x 600uS = 960 Seconds worth of "reliable" use.
>
> x 2048 for the 24LC16

I forgot that....thanks... that extends life-time to about 22days.
960seconds x 2048 = about 22days
Even then, I would consider using checksums just to make sure you don't
save corrupt data which drops the number of useful days due to more
bytes written, but extends the life due to the checksums
"saving-the-day" if bad page writes were found to happen.

2005\04\27@152433 by Paul James E.

picon face

BAJ,

Go to Ramtron.com and use the sales pulldown menu to get a supplier
in your state.   Kruvand Associates is the local rep here in Houston.
You might even be able to get samples from the factory.  I had a couple,
but have already given them away.  If I still had them, I'd send them
to you.   As a matter of fact, I'll contact the person I gave them to,
and see if he still needs them.  If not, I'll see if I can get you one
or two of them.  

Actually, I should ask what density and what interface you need first.
ie serial or parallel I/F?   2K 4K 8K bit density ?

I just checked the website for the parts I had and it looks as though you
can order samples right from the factory.   Let me know if you need me to
check further.  


                                          Regards,

                                            Jim






{Quote hidden}

> --

2005\04\27@174816 by Jinx

face picon face
> > Twc = 5ms is for byte or page
>
> at 1 byte received per 600uS, you would receive 16 bytes in:
> 16 x 600uS = 9.6mS which leaves you about 4.6mS to verify the
> last write, setup the next 16 to write and 5mS (max) for writing a
> page.

The scheme suggested by Olin would be workable. Two page-sized
buffers, alternately collecting/writing. To shift the whole 16 bytes in
one 600us IRQ would mean running the I2C at 400kHz, or at least
well over 100kHz, haven't done the maths. Although whatever the
transfer speed to the EEPROM's buffer, it takes longer to collect 16
bytes than to write them. If there's any kind of write/verify failure
the s/w should have time to find and correct that in the next available
IRQ period(s)

More... (looser matching)
- Last day of these posts
- In 2005 , 2006 only
- Today
- New search...