parport (i2c bus) maximum speed

parport (i2c bus) maximum speed

[Petr Jakeš]

[-- Attachment #1.1: Type: text/plain, Size: 383 bytes --]

I am thinking about to build an I2C-parport HW adapter. I would like to
know, what is the maximum speed one can get on the I2C bus using parport HW
adapter. I expect 100kbps is a standard speed but if it possible to go to
400k it will be great.
If it is not possible to get 400kbps speed using the parport, other hints
are appreciated of course :-)
Thanks for your reply

Petr Jakes

[-- Attachment #1.2: Type: text/html, Size: 400 bytes --]

[-- Attachment #2: Type: text/plain, Size: 157 bytes --]

_______________________________________________
i2c mailing list
i2c-GZX6beZjE8VD60Wz+7aTrA@public.gmane.org
http://lists.lm-sensors.org/mailman/listinfo/i2c

Re: parport (i2c bus) maximum speed

[Jean Delvare]

Hi Petr,

On Fri, 13 Jun 2008 15:44:12 +0200, Petr Jakeš wrote:
> I am thinking about to build an I2C-parport HW adapter. I would like to
> know, what is the maximum speed one can get on the I2C bus using parport HW
> adapter. I expect 100kbps is a standard speed but if it possible to go to
> 400k it will be great.
> If it is not possible to get 400kbps speed using the parport, other hints
> are appreciated of course :-)

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.

-- 
Jean Delvare

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

Re: parport (i2c bus) maximum speed

[Petr Jakeš]

[-- Attachment #1.1: Type: text/plain, Size: 1656 bytes --]

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

[-- Attachment #1.2: Type: text/html, Size: 2898 bytes --]

[-- Attachment #2: Type: text/plain, Size: 157 bytes --]

_______________________________________________
i2c mailing list
i2c-GZX6beZjE8VD60Wz+7aTrA@public.gmane.org
http://lists.lm-sensors.org/mailman/listinfo/i2c

Re: parport (i2c bus) maximum speed

[Jean Delvare]

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

Re: parport (i2c bus) maximum speed

[Petr Jakeš]

[-- Attachment #1.1: Type: text/plain, Size: 2632 bytes --]

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

Maybe I was not specific enough. Actually there is an SCH3114 chip on our
motherboard (http://www.smsc.com/main/catalog/sch311x.html ) and lm-sensors
need dme1737 module for this chip.
This chip acts as a SMBus master.

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


I am confused as well :-)
My feeling was lm-sensors are here to:

   1. enable SMBus/I2C communication (mainly using HW masters presented on
   the motherboards)  to communicate with SMBus slaves (mainly presented on the
   PC motherboards, ie clock, temperature, fans ....).
   2. enable SMBus/I2C communication with some other chips which one can
   connect to the bus

Because of above mentioned we have done some development and we are able,
using lm-sensors, to communicate with PIC microcontrolers (they are acting
as I2C slaves) on the VIA and Unicorn motherboards. From our test it looks
like we are communicating close to the 100kbps.

I was just wondering if it is possible to set the lm-sensors to communicate
faser, so I posted my question to this discussion group.


> 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.)


OK, thanks for this info

Petr Jakes

[-- Attachment #1.2: Type: text/html, Size: 3435 bytes --]

[-- Attachment #2: Type: text/plain, Size: 157 bytes --]

_______________________________________________
i2c mailing list
i2c-GZX6beZjE8VD60Wz+7aTrA@public.gmane.org
http://lists.lm-sensors.org/mailman/listinfo/i2c

Re: parport (i2c bus) maximum speed

[Jean Delvare]

On Fri, 13 Jun 2008 20:04:02 +0200, Petr Jakeš wrote:
> Maybe I was not specific enough. Actually there is an SCH3114 chip on our
> motherboard (http://www.smsc.com/main/catalog/sch311x.html ) and lm-sensors
> need dme1737 module for this chip.
> This chip acts as a SMBus master.

I seriously doubt it. I have the SCH311x datasheet under the eyes and
it doesn't even mention SMBus. Neither as a slave nor as a master.
Unless you are using GPIO pins to implement a bit-banged I2C bus using
a custom kernel driver...

The dme1737 driver supports the hardware monitoring block of the
SCH311x. This functionality is accessed over the LPC bus, not the SMBus.

> > I'm confused now. How is I2C/SMBus speed related to lm-sensors at all?
> 
> 
> I am confused as well :-)
> My feeling was lm-sensors are here to:
> 
>    1. enable SMBus/I2C communication (mainly using HW masters presented on
>    the motherboards)  to communicate with SMBus slaves (mainly presented on the
>    PC motherboards, ie clock, temperature, fans ....).
>    2. enable SMBus/I2C communication with some other chips which one can
>    connect to the bus

Today, lm-sensors is a library and a set of tools to let users monitor
their hardware, i.e. watch the temperatures, voltages and fans. These
monitoring devices can either be on the SMBus, or on the LPC bus. In
the former case, an additional driver is needed, but that's an
implementation detail. The I2C (SMBus) bus drivers are provided by the
kernel, and so are the hwmon drivers. I would be tempted to say that
the hwmon drivers no longer belong to "lm-sensors", but if you want to
think of them as belonging to lm-sensors, why not.

In the past, the lm-sensors package has included i2c bus drivers,
because they were not yet merged in the kernel and we needed them. But
that was years ago. Thinking of the i2c bus drivers as being part of
lm-sensors today is no good, because then you forget that many hardware
monitoring chips don't need I2C/SMBus at all, and that many I2C/SMBus
devices are not hardware monitoring chips.

The i2c mailing list and the i2c-tools SVN repository are hosted on
lm-sensors.org for historical reasons only. They are completely
independent from the lm-sensors project.

> Because of above mentioned we have done some development and we are able,
> using lm-sensors, to communicate with PIC microcontrolers (they are acting
> as I2C slaves) on the VIA and Unicorn motherboards. From our test it looks
> like we are communicating close to the 100kbps.

You are not using lm-sensors for that. You are using the kernel's i2c
bus drivers. lm-sensors is for hardware monitoring only.

-- 
Jean Delvare

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

Re: parport (i2c bus) maximum speed

[Petr Jakeš]

[-- Attachment #1.1: Type: text/plain, Size: 2394 bytes --]

>
> I seriously doubt it. I have the SCH311x datasheet under the eyes and
> it doesn't even mention SMBus. Neither as a slave nor as a master.
> Unless you are using GPIO pins to implement a bit-banged I2C bus using
> a custom kernel driver...
>
> The dme1737 driver supports the hardware monitoring block of the
> SCH311x. This functionality is accessed over the LPC bus, not the SMBus.
>

Yes, you are right, I was writing my mail and I did not re-check our
installation and my memory did not work properly. Sorry for that mistake.
Now, after checking it I see we are using scx200_acb and i2c-dev modules for
the I2C communication (using i2cdetect, i2cdump, i2cget commands for the
basic recognition of devices on the bus and the py-smbus binding for the
main communication on the bus) and the dme1737 to read the voltage and
temperature from the SCH311x chip


> Today, lm-sensors is a library and a set of tools to let users monitor
> their hardware, i.e. watch the temperatures, voltages and fans. These
> monitoring devices can either be on the SMBus, or on the LPC bus. In
> the former case, an additional driver is needed, but that's an
> implementation detail. The I2C (SMBus) bus drivers are provided by the
> kernel, and so are the hwmon drivers. I would be tempted to say that
> the hwmon drivers no longer belong to "lm-sensors", but if you want to
> think of them as belonging to lm-sensors, why not.
>
> In the past, the lm-sensors package has included i2c bus drivers,
> because they were not yet merged in the kernel and we needed them. But
> that was years ago. Thinking of the i2c bus drivers as being part of
> lm-sensors today is no good, because then you forget that many hardware
> monitoring chips don't need I2C/SMBus at all, and that many I2C/SMBus
> devices are not hardware monitoring chips.
>
> The i2c mailing list and the i2c-tools SVN repository are hosted on
> lm-sensors.org for historical reasons only. They are completely
> independent from the lm-sensors project.


I feel terribly bad I did not study the details on the web before asking
"basic" questions and wasting your time... thanks for your patience...

>
> You are not using lm-sensors for that. You are using the kernel's i2c
> bus drivers. lm-sensors is for hardware monitoring only.


Anyway, if I understand it properly, there is not the way how the set up the
speed of the i2c bus.

Petr Jakes

[-- Attachment #1.2: Type: text/html, Size: 3090 bytes --]

[-- Attachment #2: Type: text/plain, Size: 157 bytes --]

_______________________________________________
i2c mailing list
i2c-GZX6beZjE8VD60Wz+7aTrA@public.gmane.org
http://lists.lm-sensors.org/mailman/listinfo/i2c

Re: parport (i2c bus) maximum speed

[Jean Delvare]

On Sat, 14 Jun 2008 00:32:38 +0200, Petr Jakeš wrote:
> > I seriously doubt it. I have the SCH311x datasheet under the eyes and
> > it doesn't even mention SMBus. Neither as a slave nor as a master.
> > Unless you are using GPIO pins to implement a bit-banged I2C bus using
> > a custom kernel driver...
> >
> > The dme1737 driver supports the hardware monitoring block of the
> > SCH311x. This functionality is accessed over the LPC bus, not the SMBus.
> 
> Yes, you are right, I was writing my mail and I did not re-check our
> installation and my memory did not work properly. Sorry for that mistake.
> Now, after checking it I see we are using scx200_acb and i2c-dev modules for
> the I2C communication (using i2cdetect, i2cdump, i2cget commands for the
> basic recognition of devices on the bus and the py-smbus binding for the
> main communication on the bus) and the dme1737 to read the voltage and
> temperature from the SCH311x chip

OK, that makes sense.

> (...)
> I feel terribly bad I did not study the details on the web before asking
> "basic" questions and wasting your time... thanks for your patience...

No problem... The history of the project makes things confusing. I've
made my best to clarify the situation but I know we're not there yet.

> > You are not using lm-sensors for that. You are using the kernel's i2c
> > bus drivers. lm-sensors is for hardware monitoring only.
> 
> Anyway, if I understand it properly, there is not the way how the set up the
> speed of the i2c bus.

If there is a way, it's specific to the scx200_acb driver and the
underlying hardware. I am not familiar with this hardware myself, so I
can't tell.

-- 
Jean Delvare

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

Re: parport (i2c bus) maximum speed

[Cyrille Derory]

Petr Jakeš a écrit :
>
> 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").
> _______________________________________________
> i2c mailing list
> i2c@lm-sensors.org
> http://lists.lm-sensors.org/mailman/listinfo/i2c
Hi Petr,

I am interrested in your work on PIC 16F887. I have to connect a 
PIC16F88 with the i2c parport adapter. Do you have more informations.

Thanks in advance.

Cyrille DERORY

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