Hi Chris,
> How about a range of -4% to +2% ?
I am fine with a range in general, but I don't like +x% because we should never
be faster than requested. Clients may have problems with that.
> Technically, to do it right, to calculate the ACTUAL I2C baud rate, you
> have to take into effect the load resistance and capacitance of the
> lines in order to factor in the rise and fall times correctly. Of course
We have those generic bindings upstream:
- i2c-scl-falling-time-ns
Number of nanoseconds the SCL signal takes to fall; t(f) in the I2C
specification.
- i2c-scl-internal-delay-ns
Number of nanoseconds the IP core additionally needs to setup SCL.
- i2c-scl-rising-time-ns
Number of nanoseconds the SCL signal takes to rise; t(r) in the I2C
specification.
- i2c-sda-falling-time-ns
Number of nanoseconds the SDA signal takes to fall; t(f) in the I2C
specification.
So far, that was all that is needed, however...
> Just live with the fact that the speed might be off by 4%.
... as I said before, I won't force it on you for the frequencies you want to
support.
Regards,
Wolfram
Attachment:
signature.asc
Description: PGP signature
