[i2c] parport (i2c bus) maximum speed

Petr Jakeš petr.jakes at tpc.cz
Fri Jun 13 17:55:22 CEST 2008

Jean, thanks for prompt reply

> Our current i2c-algo-bit implementation can't go faster than 250 kbps
> by design. I think I remember trying it and it was working fine. But if
> memory serves the actual speed ended up being significantly less than
> 250 kpbs, maybe 160 kbps. Just like you don't actually get 100 kbps
> when you ask for 100 kbps. I guess that there's latency in switching
> the parport pins, which becomes visible as the speed increases.
> If you plan on doing fast I2C over parport, then I think you want to
> give up on bit-banging and instead control an I2C master beyond the
> parallel port. That way you take benefit of the parallel aspect of
> parport and you should be able to reach 400 kbps. Using a chip we
> already have abstracted support for (PCF8584 or PCA9564) this shouldn't
> be too difficult.

Now we do SMBus communication through dme1737 (we have compatilbe chip on
the motherboard). I guess it is not possible to change the bus speed because
the master (DME1737) is generating the clock frequency of the SMBus.

Just for your information we have PIC 16F887 connected to the bus as a slave
(which was really pain and a lot of SW hacking on the PIC side - it looks
like Microchip I2C HW/SW implementation does not work properly "sometimes").

The good thing is we have slaves connected directly to the system SMBus and
we are doing MISSIVE communication on the bus (motors control, keyboard, LCD
display, I/O) and we have not observed any single problem (we are using
py-smbus binding for the communication).

Are there some other ways (HW interfaces etc.) to get lm-sensors work on the
higher speed?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.lm-sensors.org/pipermail/i2c/attachments/20080613/bb40bfdd/attachment.html 

More information about the i2c mailing list