At 11:55 AM 4/28/00 -0500, you wrote:
>> At 01:08 PM 3/27/00 -0800, Jim wrote:
>> One point to make with the I2C EEPROMs that has not been
>> made during this thread is that the 24C01, 24C02, 24C04, 24c08
>> and 24C16 DO NOT support multiple eeprom devices on the
>> one I2C bus. The reason is that the slave addr byte is used as
>> the upper address byte (even on the 24C00, 24C01 when no upper
>> address is actually required.)
>
>Jim, The MChip 24C01A and the Atmel AT24C01 are not the same.  Even
>the small MChip parts have three address bits that are tied high or
>low to set the slave address.

I have checked this again and in fact microchip listed 5 different
types of 24C01. Only one of the 5 utilized pin strapping for
address selection. This was the 24C01C. The same is true for the
24C02, only the 24C02C has device addressing.

There is no 24C04C, 24C08C or 24C16C as these parts are over 256 bytes
and require high address bit(s) which replace the device slave
addresses thus creating the problem I was taking about.

Some microchip parts appear to have A0,A1,A2 pins but looking at the
fine print we see that they are not internally connected.


With these parts, you CAN put 8 EE
>chips on the bus.  Of course for the 24C01 it would be cheaper and
>probably simpler to use one larger part, but if you needed modularity
>or redundancy for some reason, it is possible.

Right for the 24C01C and 24C02C only. I was right in all but two
cases.


>I mostly use the 64K parts myself, where arraying them for larger
>capacity makes sense.  It takes some address translation logic to use
>several chips as one large area becuase of the need to "increment"
>the DEVICE address when one rolls from one chip to another.

I would have thought it easier to interleave the addressing as Andy
Warren suggested. Especially if the page buffer size is 256 bytes then
you would only need to manipulate the high order address byte.


>The rest of your points are right on.  The page buffer size issue is
>a pain because its nice to write the largest block possible to
>improve throughput, but I've had to settle for "least common
>denominator" write page size to be able to second source.  It sounds
>like you had the same experience.

I think I will provide an option for the user to select the page
size in the next programmer driver. Set it on the lowest common
denominator by default and let the user up it at his/her own risk.


>
>Regards,
>
>Barry
>------------
>Barry King, KA1NLH
>NRG Systems "Measuring the Wind's Energy"
>http://www.nrgsystems.com
>Check out the accumulated (PIC) wisdom of the ages at:
>PIC/PICList FAQ: http://www.piclist.org
>
Regards,

Jim Robertson
NEWFOUND ELECTRONICS
________________________________________
Email: newfound@pipeline.com.au
http://www.new-elect.com
MPLAB compatible PIC programmers.
________________________________________