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? Regards Petr
_______________________________________________ i2c mailing list [email protected] http://lists.lm-sensors.org/mailman/listinfo/i2c
