Re: parport (i2c bus) maximum speed

[Jean Delvare <khali-PUYAD+kWke1g9hUCZPvPmw@public.gmane.org>]

On Fri, 13 Jun 2008 17:55:22 +0200, Petr Jakeš wrote:
> 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.

I don't think the DME1737 can act as an SMBus master, or can it? As far
as I know the DME1737 is an SMBus slave and multiplexer, but not a
master. If I am correct then what matters is the actual SMBus master on
the motherboard.

> 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?

I'm confused now. How is I2C/SMBus speed related to lm-sensors at all?

Most SMBus controllers on PC motherboards run at low speeds (from 10 to
64 kbps), mainly because there's no need for speed when you only have a
hardware monitoring chip and a couple SPD EEPROMs on the bus. So If you
want high-speed you'll have to use an additional controller, but I
don't know of any (except for parallel port or USB do-it-yourself
adapters, but that's not much faster.)

Also note that Linux still misses support for high-speed I2C and
mixed-speed buses in general (except for the compatibility between I2C
and fast I2C which is guaranteed at the hardware level if I remember
correctly.)

-- 
Jean Delvare

_______________________________________________
i2c mailing list
i2c@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/i2c