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...
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...
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. 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.</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. If you want I2C then a 24C00 will give you 128 bytes.</FONT></P>
> 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.
> 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.
> 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.
> 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.
> 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.
> 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.
> 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).
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.
> 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.
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.
> 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.
> > 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.
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.
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.
> > 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.
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.
> 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.
> > 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.
> > 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)
PROGRESS.COM> on 03/26/2000 12:21:52 PM
