PicDude writes:
 > On Tuesday 20 September 2005 07:58 am, Bill Freeman scribbled:
 > Okay, but some devices (looking at Digikey's search tool) are specified as 
 > "100khz", some as "400khz" and yet others as "100khz & 400khz".  Seems odd as 
 > if it met the 400khz specs, it would automatically handle the 100khz timing.

	Yea, well, I don't think that the copy writers at Digikey
spend a lot of time understanding the datasheets.  They probably just
extract the title, or even a line item from a product brief.  It would
be nice if you could get competitive information summarized for you
like that, but there's no substitute for research.  I'd be very surprised
to learn that any slave only fast rated device failed at standard speed.
(There might be system level considerations for long buses in which
fast mode capable drivers have too small a Tf and make the bus ring
excessively, but hooking an EEPROM to the adjacent PIC isn't going to
be a problem.)

 > More odd is that the Taa parameter shows how fast the slave EEPROM will have 
 > its data ready during a read -- and that number is smaller for the fast mode.  
 > Seems like the device would have the data valid in maximum so many seconds, 
 > regardless of the mode, if there is no way to select/switch modes.  Or are 
 > you saying that these numbers are from the spec as what the device is 
 > required to meet to be compliant in any mode, and it should just be accepted 
 > that it does?

	Again, I think that if you look closely, the two (or more) values for
Taa for a given part are ratings for different supply ranges.  At low Vcc
the gates are slower.  (Never mind that at low Vcc you could actually build
faster gates.  They have sized the transistors to not fry at high Vcc, and
they don't switch to others when Vcc changes.)

	Note, too, that Taa isn't the memory access time, it's a
parameter of the serial interface.  For example, acknowledging the
command byte with the acknowledge bit at the end of the byte is done
in Taa.  The ROM itself accesses, at least partially (row select may
already be done before the whole command and/or command and address
info is clocked in) in the times that it takes to send the last
acknowledge.  Taa applies to the interface shift register plus the
clock receiver plus the data driver.

 > Gotcha.  Only possible exception to that is a small note near the end of the 
 > datasheet (section 7.3) that indicates that for power reduction, the eeprom 
 > will power down automatically after a transaction.  It can also do this 
 > during error conditions or timeouts, so too long of a delay between changes 
 > on the lines may possibly be interpreted as a timeout.  I'll check the spec 
 > to see for sure.

	Still, the interface portion of the chip stays powered (CMOS
static logic, really low power anyway), since it has to recognize the
next command directed at it.  Note that these are pretty slow speeds
for modern PROMs (e.g.; flash), and I'll bet that the sum of the power
up time and the ROM access time is well less than the acknowledge bit
time.  Taa is still just an serial interface parameter (which, since
it stays powered up, is worth keeping low power and thus as slow as
meeting the I2C spec over temperature and voltage allows).  Oh,
there's probably some scaling of the ROM to not be much faster than
needed, but that first bit still has to make it out as fast as all of
the others, and has to pass through the same final shift register flip
flop (or MUX) and driver as subsequent ones, so I'll bet that the
design has the read ready by the end of the acknowledge.  Of course,
the manufacturer can implement the chip any way that they like, so
long as it meets the appropriate I2C spec.

 > "clocked on rising SCL" ?
 > Let me clarify this -- Master sends SDA HI (to free that line), then sends SCL 
 > HI, then back LO, then wait Taa, then the master reads the SDA line. ... 
 > right?

	Can do, I'm sure.  I generally take the tact of reading SDL
during the subsequent SCL high time, or, if doing it in hardware on
the rising SCL edge of that clock high time.  You have plenty of time.
The slave is guaranteed to keep driving the same SDL value until it
sees the falling SCL edge of that subsequent SCL high time.  That way
I can just obey the SCL low minimum, and read the data at my leisure
while I delay to satisfy the SCL high minimum of that subsequent clock
pulse.  But if you absolutely need that bit at the earliest possible
nanosecond...

	Remember, for normal bit transfers (the only time that slaves
drive SDL), data is guaranteed to be stable while SCL is high.  And
your master implementation had better make the same guarantee for 
data (including acknowledge bits), except when you are sending start
or stop (ore re-start) conditions, explicitly defined as SDL changes
while SCL is high.

	Let me try one other description.  If you are building an
interface in hardware, you might use a D flip flop or latch clocked or
latched on the rising edge of SCL to sample SDL.  That device will
have a minimum stable data to SCL high requirement.  Adding Taa to
that setup time will tell you if you have to stretch SCL low minimum.
Conversely, subtracting Taa from SCL low minimum will tell you how
slow a flip flop you can get away with, or whether you have to feed a
delayed version of SCL to the flip flop, etc.  Otherwise SCL low
minimum governs, and you don't care about Taa (especially for the
master, who doesn't have to lower SCL again until it has sampled SDL).

							Bill
-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist