> From: Aaro Koskinen [mailto:aaro.koskinen@xxxxxxxxx] > Sent: Tuesday, February 24, 2009 6:47 AM > ext Nishanth Menon wrote: > > Aaro Koskinen said the following on 02/24/2009 11:09 AM: > >>> TRM: > >>> tHigh = ( sclh +5 )*iclk period > >>> tLow = ( scll +7 )*iclk period > >>> > >>> But my question is this: why are we trying to a different equation > >>> here compared to the equation in the TRM? > >> The problem with TRM (the table 18-13 you referred earlier) is that it > >> assumes 50% duty cycle while the correct one is more like 33%. This is > >> corrected by Eero's patch: > > Gentle query - could you point me to the place where the 33% duty cycle > > is mentioned in i2c spec? spec mentions minimum timing, but I don't seem > > to find a constraint on duty cycle requirement.. :( > > Well, it's implicite... Check the i2c spec table 7 for speeds 3400 and > 1700. If you use TRM calculcations so that tLow == tHigh you get too > tLow that's below the minimum in both cases. So you must increase tLow, > and when you do that you must make tHigh shorter, otherwise you don't > match the rate. ... I didn't take a deep study but I did just skim a couple sections. And it looks like it I2C spec does NOT require the clock high/low to be unbalanced (or balanced). It would seem to recommend it being unbalanced because doing so should allow timing requirements to be more easily met for a range of frequencies. This would allow a more general equation. In the end it is a question if rise/fall times and relative clock-line/data-line requirements are met. It does seem to say in the spec that after 100pf of bus capacitance all bets are off and you need to measure and degrade speed unit conditions are met. Regards, Richard W. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
