Searching \ for 'External EEPROM Choices' 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/mems.htm?key=eeprom
Search entire site for: 'External EEPROM Choices'.

Truncated match.
PICList Thread
'External EEPROM Choices'
2000\03\27@092647 by David E. Olson

flavicon
face
OK. Now I have to get some configuration and calibration data for my speedo
into EEPROM. Fortunately, our friends at Microchip have a 100 or so choices.
I've done it with an F84 but, this time I'm on a 16C73B.

I don't need to store all that much, so figuring out the size isn't a big
deal. The big deal is which one is better?

SPI, I2C, 3-wire? (I'm passing on Parallel) I've got plenty of pins
available and I'd like to read/write as fast as possible.

I'm already doing asynch to my display so I'm not sure if I can used
hardware-based comms...

-DO

2000\03\27@094429 by Andrew Kunz

flavicon
face
I2C usually has page-write modes (multiple bytes per write command).  Contact me
offline about the code.

Andy











"David E. Olson" <spam_OUTdolsonTakeThisOuTspamPROGRESS.COM> on 03/26/2000 12:21:52 PM

Please respond to pic microcontroller discussion list <.....PICLISTKILLspamspam@spam@MITVMA.MIT.EDU>








To:      PICLISTspamKILLspamMITVMA.MIT.EDU

cc:      (bcc: Andrew Kunz/TDI_NOTES)



Subject: External EEPROM Choices








OK. Now I have to get some configuration and calibration data for my speedo
into EEPROM. Fortunately, our friends at Microchip have a 100 or so choices.
I've done it with an F84 but, this time I'm on a 16C73B.

I don't need to store all that much, so figuring out the size isn't a big
deal. The big deal is which one is better?

SPI, I2C, 3-wire? (I'm passing on Parallel) I've got plenty of pins
available and I'd like to read/write as fast as possible.

I'm already doing asynch to my display so I'm not sure if I can used
hardware-based comms...

-DO

2000\03\27@115235 by Michael Rigby-Jones

flavicon
face
part 0 3334 bytes
<P><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">Well, for simplicity I'd forget the 16C73B and go for the 16F873.&nbsp; It's an easy upgrade from the 73 and has 256 bytes of eeprom on board, addressable in the same way as a F84.&nbsp; This would probably be the fastest solution as well, as no serial transfers are involved.</FONT></P>

<P><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">If you are determined to use the 73B, then SPI/Microwire is your best bet for speed, although for any reasonable speed you should only be reading out the cal factors into file registers at startup.</FONT></P>

<P><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">The SPI/Microwire devices tend not to be available in very small sizes, a 93LC46 will give you 1kbyte.&nbsp; If you want I2C then a 24C00 will give you 128 bytes.</FONT></P>

<P><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">Mike</FONT>
</P>
<UL>
<P><FONT SIZE=1 FACE="Arial">{Original Message removed}

2000\03\27@133053 by Andrew Warren

face
flavicon
face
Andrew Kunz <.....PICLISTKILLspamspam.....MITVMA.MIT.EDU> wrote:

> I2C usually has page-write modes (multiple bytes per write
> command).

Andy:

Most of the SPI EEPROMs do, too.  Personally, I prefer using I2C
EEPROMs in general... But for this application, I'd probably use a
93C46, just because the code to access it is smaller and faster.

-Andy


=== Andrew Warren - EraseMEfastfwdspam_OUTspamTakeThisOuTix.netcom.com
=== Fast Forward Engineering - San Diego, California
=== http://www.geocities.com/SiliconValley/2499

2000\03\27@134525 by Andrew Kunz

flavicon
face
Shows you how frequently I use SPI stuff.

I prefer having the extra pin(s) available too.

Andy








Andrew Warren <fastfwdspamspam_OUTIX.NETCOM.COM> on 03/27/2000 01:31:34 PM

Please respond to pic microcontroller discussion list <@spam@PICLISTKILLspamspamMITVMA.MIT.EDU>








To:      KILLspamPICLISTKILLspamspamMITVMA.MIT.EDU

cc:      (bcc: Andrew Kunz/TDI_NOTES)



Subject: Re: External EEPROM Choices








Andrew Kunz <RemoveMEPICLISTTakeThisOuTspamMITVMA.MIT.EDU> wrote:

> I2C usually has page-write modes (multiple bytes per write
> command).

Andy:

Most of the SPI EEPROMs do, too.  Personally, I prefer using I2C
EEPROMs in general... But for this application, I'd probably use a
93C46, just because the code to access it is smaller and faster.

-Andy


=== Andrew Warren - spamBeGonefastfwdspamBeGonespamix.netcom.com
=== Fast Forward Engineering - San Diego, California
=== http://www.geocities.com/SiliconValley/2499

2000\03\27@142906 by Mike Mansheim

flavicon
face
Andrew Kunz <TakeThisOuTPICLISTEraseMEspamspam_OUTMITVMA.MIT.EDU> wrote:

> I2C usually has page-write modes (multiple bytes per write
> command).

Andy Warren wrote:

>Most of the SPI EEPROMs do, too.  Personally, I prefer using I2C
>EEPROMs in general... But for this application, I'd probably use a
>93C46, just because the code to access it is smaller and faster.

I've only used the 24LC01, which is an I2C device.  If it is typical,
one should also keep in mind that a write cycle takes upwards of 10ms.
Obviously this can be done in the background if you have other stuff
to do, but if you are looking for "constant" quick access, like ram,
this is VERY slow.
Something that tripped me up for a while with this part is that the
pages in the page-write mode have to be on 8 byte boundaries - you
can't just write the next 8 consecutive bytes.  For instance, if,
using page-write mode, you write 5 bytes starting at address 5, the
data will be written to eeprom addresses 5, 6, 7, 0, 1.
btw, the 10ms is for any size write from 1 to 8 bytes.

2000\03\27@194008 by Andrew Warren

face
flavicon
face
Mike Mansheim <RemoveMEPICLISTspamTakeThisOuTMITVMA.MIT.EDU> wrote:

> I've only used the 24LC01, which is an I2C device.  If it is
> typical, one should also keep in mind that a write cycle takes
> upwards of 10ms.

   Actually, Mike, it takes a MAXIMUM of 10 ms from the end of
   your "write" command until the write is actually complete.

> Obviously this can be done in the background if you have other
> stuff to do, but if you are looking for "constant" quick access,
> like ram, this is VERY slow.

   Yes, BUT... If you have lots of data to write (which is the usual
   reason for needing high-speed access to the EEPROM), you're
   probably going to use multiple EEPROMs, and you can interleave
   your writes to them in order to "pipeline" the slow write cycles.

   For instance, let's say you're using an EEPROM with a 16-byte
   block-write mode.  If you write one byte at a time to that chip,
   it takes 10 ms/byte.

   If you use the 16-byte block-write mode, each 16-byte write to
   the chip takes 10 ms, for an average write time of .625 ms/byte.

   And... If you have eight of those chips (the maximum that one
   pair of I2C lines can handle) and you write your data to them by
   sending 16 bytes to each of them consecutively, you can
   theoretically get a maximum throughput of 128 bytes/10 ms, or
   0.078125 ms/byte.

   If even that isn't fast enough, chips with 32- or 64-byte
   block-write modes can cut those times by a factor of 2 or 4.

   -Andy


=== Andrew Warren - fastfwdEraseMEspam.....ix.netcom.com
=== Fast Forward Engineering - San Diego, California
=== http://www.geocities.com/SiliconValley/2499

2000\03\27@194114 by David E. Olson

flavicon
face
> Well, for simplicity I'd forget the 16C73B and go for the 16F873.  It's an
easy upgrade from the 73 and
> has 256 bytes of eeprom on board, addressable in the same way as a F84.
This would probably be
> the fastest solution as well, as no serial transfers are involved.

Duh. I don't know why I didn't think of that...Maybe got 73B on the brain.

Is the 873's EEPROM rated the same as external EEPROM for durability? Since
I'm primarily shuttling odometer values up there, I need to make sure I get
good read/write cycle endurance. Then again, since I'd be storing a 32 byte
value, I could move it around to different locations from time to time.

Thanks Michael.

-DO

2000\03\27@194122 by David E. Olson

flavicon
face
[From Andy Warren...]

> Most of the SPI EEPROMs do, too.  Personally, I prefer using I2C
> EEPROMs in general... But for this application, I'd probably use a
> 93C46, just because the code to access it is smaller and faster.

Smaller and faster is good. In theory, I have to write the odometer value
every .1 mile. I could also gamble that I wouldn't lose power and write the
odometer value at periodic intervals. I could also write the odometer on
shut down. That gets tricky if I power the shutdown routine from the vehicle
battery and it somehow gets disconnected.

.1/mile writes would be close to the million write endurance if we go for
100,000 miles too.

-DO

2000\03\28@105612 by Mike Mansheim

flavicon
face
Andrew Warren wrote:

>   Yes, BUT... If you have lots of data to write (which is the usual
>   reason for needing high-speed access to the EEPROM), you're
>   probably going to use multiple EEPROMs, and you can interleave
>   your writes to them in order to "pipeline" the slow write cycles.
<snip>
>   And... If you have eight of those chips (the maximum that one
>   pair of I2C lines can handle)...

Clever - yet another thing that had not occurred to me.
Why is eight the limit for a pair of I2C lines?


>   Actually, Mike, it takes a MAXIMUM of 10 ms from the end of
>   your "write" command until the write is actually complete.

I know it is a maximum spec - however, I typically just make sure
enough time has elapsed before accessing the eeprom again - and in
that case, I use the 10ms number.  Again, I can only comment on the
24LC01, but it does not have a convenient "I'm done writing" flag.
You need to keep sending the eeprom's address (assigned by Phillips!)
until an ack is received to know when it is ready for you.  This
certainly doesn't take much more effort than making sure 10ms has
elapsed, but in my application, there is the possibility of
another master being connected any time, so I like to minimize
bus traffic (just my preference).

2000\03\28@105626 by Andrew Kunz

flavicon
face
David,

That's EXACTLY what I did with one '84-based product.  The first byte was a
pointer to the start of the real data.  If we got a write error
(read-after-write to verify), we moved to the next segment of the EE and updated
the pointer.  The pointer was always usable, as it was only written about
1millionth of the times as the data portion.

If the pointer write failed, the chip was non-functional.  Hasn't happened to
date.

Andy










"David E. Olson" <EraseMEdolsonspamPROGRESS.COM> on 03/26/2000 09:27:59 PM

Please respond to pic microcontroller discussion list <RemoveMEPICLISTEraseMEspamEraseMEMITVMA.MIT.EDU>








To:      RemoveMEPICLISTspam_OUTspamKILLspamMITVMA.MIT.EDU

cc:      (bcc: Andrew Kunz/TDI_NOTES)



Subject: Re: External EEPROM Choices








> Well, for simplicity I'd forget the 16C73B and go for the 16F873.  It's an
easy upgrade from the 73 and
> has 256 bytes of eeprom on board, addressable in the same way as a F84.
This would probably be
> the fastest solution as well, as no serial transfers are involved.

Duh. I don't know why I didn't think of that...Maybe got 73B on the brain.

Is the 873's EEPROM rated the same as external EEPROM for durability? Since
I'm primarily shuttling odometer values up there, I need to make sure I get
good read/write cycle endurance. Then again, since I'd be storing a 32 byte
value, I could move it around to different locations from time to time.

Thanks Michael.

-DO

2000\03\28@105633 by jb

flavicon
face
Seems like there was a discussion on this some time ago - check the
archives/uChip app notes. I think the solution was to have a large cap
diode-isolated from the main supply with an input port monitoring the mains
voltage. If it dropped off, the pic would write to flash in the time it had
before the cap was drained. That way you didn't write to flash unless you
were powering down.

JB


> .1/mile writes would be close to the million write endurance
> if we go for
> 100,000 miles too.

2000\03\28@105731 by Andrew Warren

face
flavicon
face
David E. Olson <RemoveMEPICLISTTakeThisOuTspamspamMITVMA.MIT.EDU> wrote:

> I have to write the odometer value every .1 mile .... [which]
> would be close to the million write endurance if we go for 100,000
> miles

David:

Since your odometer is always counting upward, it'd be trivially easy
to move to a new set of EEPROM addresses every 100,000 miles.  Even
the smallest external EEPROMs have more than enough memory for 10
sets, or 1,000,000 miles... And most of the PICs with onboard EEPROM
do, too.

-Andy


=== Andrew Warren - EraseMEfastfwdspamspamspamBeGoneix.netcom.com
=== Fast Forward Engineering - San Diego, California
=== http://www.geocities.com/SiliconValley/2499

2000\03\28@105736 by andy howard

flavicon
face
{Quote hidden}

This seems to be one major advantage of the FRAM. Its block mode can
write a chipful at one time, so the write speed is as fast as you can
squirt it down the serial line.

I've not tried this yet but my next project will be using FRAM and
writing large-ish chunks of data each time, so the wait-free write could
be a bonus here.

















.

2000\03\28@121534 by Andrew Warren

face
flavicon
face
Mike Mansheim <RemoveMEPICLISTKILLspamspamMITVMA.MIT.EDU> wrote:

> Why is eight the limit for a pair of I2C lines?

   Mike:

   It's not an I2C limit, it's a 24-series EEPROM limit; each EEPROM
   has only 3 address lines (A0, A1, and A2) which can be tied high
   or low to give the chip its own address.

{Quote hidden}

   Correct, but since the EEPROMs generally complete their write
   cycles in much less than 10 ms, it pays to do the address/ack
   thing if you need speed.

   Also... The most efficient way to do it is to check the busy
   flag (with that address/ack protocol) just BEFORE you access the
   EEPROM, rather than just after you perform a write.

   -Andy


=== Andrew Warren - fastfwdSTOPspamspamspam_OUTix.netcom.com
=== Fast Forward Engineering - San Diego, California
=== http://www.geocities.com/SiliconValley/2499

2000\03\28@125946 by David E. Olson

flavicon
face
> On Behalf Of jb
>
> Seems like there was a discussion on this some time ago - check the
> archives/uChip app notes. I think the solution was to have a large cap
> diode-isolated from the main supply with an input port monitoring
> the mains voltage. If it dropped off, the pic would write to flash in the
> time it had before the cap was drained. That way you didn't write to flash
unless you
> were powering down.

A lot better than having to put a battery in it. I'm also using a 16C73B
that has BOD too - that could be used to fire off the EEPROM write routines.

-DO


'External EEPROM Choices'
2000\04\01@184314 by Marc
flavicon
face
> > Why is eight the limit for a pair of I2C lines?
>
>     Mike:
>
>     It's not an I2C limit, it's a 24-series EEPROM limit; each EEPROM
>     has only 3 address lines (A0, A1, and A2) which can be tied high
>     or low to give the chip its own address.

You can assign 4 addresses to 4 devices, and wire the 3rd bit all together
and to a spare PIC pin. Do that with another pool of 4 devices, and yet
another, etc.

When doing an EEPROM access, select the destination pool by configuring
only that pool signal low, and all the others high.  Then talk to the
particular device with its address and adr.2=0.

2000\04\01@200922 by Andrew Warren

face
flavicon
face
Marc <spamBeGonePICLISTSTOPspamspamEraseMEMITVMA.MIT.EDU> wrote:

> > it's a 24-series EEPROM limit; each EEPROM has only 3 address
> > lines (A0, A1, and A2) which can be tied high or low to give
> > the chip its own address.
>
> You can assign 4 addresses to 4 devices, and wire the 3rd bit all
> together and to a spare PIC pin. Do that with another pool of 4
> devices, and yet another, etc.
>
> When doing an EEPROM access, select the destination pool by
> configuring only that pool signal low, and all the others high.

Marc:

Yes, I suppose that would work... But why not just use pools of EIGHT
devices, and a separate CLK line for each 8-device pool?  It seems
more efficient:

                  # of PIC pins    # of PIC pins
   # of devices:   (shared A2)      (shared CLK)

        8               4                2
       12               5                3
       16               6                3
       20               7                4
       24               8                4
       28               9                5
       32              10                5

-Andy


=== Andrew Warren - KILLspamfastfwdspamBeGonespamix.netcom.com
=== Fast Forward Engineering - San Diego, California
=== http://www.geocities.com/SiliconValley/2499

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