>
> Wolfgang Grandegger wrote:
>
> > I did not follow the thread yet, sorry. I implemented AN2819 for Linux
> > (see http://lxr.linux.no/#linux+v2.6.31/drivers/i2c/busses/i2c-mpc.c)
> > some time ago using Timur's table approach. But there is no difference
> > between the table and the algorithm to calculate the value. The table is
> > actually derived from the same algorithm.
>
> The problem with the table is that it does not allow for flexibility in
> choosing dfsr. When I implemented the table code, I did not think that this
> was a problem, but apparently it is.
Yes, it is a problem for us as our board is out of spec. The rise time is way
off
spec. By trial and error with the DFSR/FDR I managed to get a stable connection.
What is less funny though is that I need to program FDR/DFSR differently
in u-boot resp. kernel. to make it work.
I suspect it is due to kernel being IRQ driven and has longer pause
between chars, but it is a guess.
In any case, the revised AN2819 dictates a different algorithm but I feel
it is a bit incomplete w.r.t Condition 2:
• Condition 2: B × T ≥ tI2CRM + 3 × C × T.
Given a suitable value of DFSR, chosen to satisfy Condition 1, this inequality
must also be met to guarantee
that the SCL frequency matches the SCL frequency calculated by the divider
equation. It is important to
note that tI2CRM is the measured rise time of the SCL signal, which is defined
as the time for the signal to
rise from 10% to 70% of VCC.
NOTE
Note that the rise time must not exceed 300 nanoseconds and
that the above
two conditions must both be satisfied to ensure that the
actual SCL
frequency values align with the calculated values. By
meeting these
conditions, the measured SCL frequency will match the
calculated
frequency to within 5 kHz. Ignoring either of these
conditions may result in
larger discrepancies between these frequency values.
How important is Condition 2 and what to do with rise times > 300 ns? The MAX
rise time
for 100 KHz is 1000 ns so there is a gap here.
My testing suggests that this is not important. Bigger DFSR, in my case 0x6 or
0x10, is key
to get a stable I2C bus.
Jocke
PS.
Wolfgang, I sent a test program to calculate the new DFSR/FDR values in the
thread, you
might find it useful if you are going to try out the new AN2819
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
