11-bit temperature problem

Mark M. Hoffman mhoffman at lightlink.com
Thu Aug 14 06:34:18 CEST 2003


* Jean Delvare <khali at linux-fr.org> [2003-08-14 00:14:45 +0200]:
> * Mark M. Hoffman <mhoffman at lightlink.com>:
> > 
> > 10kHz smbus speed (conservative - spec'ed minimum according to
> > datasheet) 40 bits per read (smbus write + smbus read incl.
> > start/stop/ack bits) 22 registers to read (conservative - probably
> > need only 15)

<snip>

> Two remarks. First, when you say "10kHz smbus speed, conservative", I
> don't quite agree. To me, the conservative value is the highest possible
> bus speed. This is where the one-shot conversion will increase the
> overall time more (relatively). So, let's consider a bus speed of
> 100kHz. How do you come to 40 bits? I count 29 (3 9-bit bytes, plus 1

According to the datasheet timing diagrams on p 11...

(a) is i2c_smbus_write_byte_data() ~29 bits
(b) is i2c_smbus_write_byte() ~20 bits
(c) is i2c_smbus_read_byte() ~20 bits

I.e. i2c_smbus_read_byte_data() is not supported by this chip, so you
need to use (b) + (c) to read a register.

And I say ~40 instead of exactly 40 because there are limits to how close
one can stack transactions (the bus driver/hw should take care of that).

> start and 1 stop). There are 17 registers we want to update (3 volatile,
> 14 non-volatile). So the update time would be 4.93ms (4.06 non-volatile,
> 0.87 volatile). Now we can consider that 31.25 extra ms for the
> conversion is something significant, isn't it?
> 
> Of course you can object my reasonment is pointless, and I agree ;) We

Indeed. ;)

> don't really care what takes time as long as the overall operation fits
> in a reasonable amount of time. But I don't like the idea much, while I
> would have if the conversion time was less than the non-volatile
> registers update.
> 
> BTW is there a way we can know at what frequency the bus really works?

The simplest correct answer is "no".

A more useful answer is "look at the bus datasheet".

But this is actually not a simple topic at all.  Even if you know the
nominal bus speed, the protocol allows for the master or slaves to
"stretch" any single bit-time to arbitrary lengths (in theory).  Of course
in practice a master or slave will not wait forever; the amount of time
they *will* wait is published.  E.g. 10kHz minimum for LM90 implies
that the master better not stretch a bit-time longer than 100uS.

If I managed to get you interested about what's "on the wire", look here:
http://www.semiconductors.philips.com/buses/i2c/

> Anyway, my main objection against one-shot mode is the hardware
> protection. The LM90 is supposed to have its ALERT output wired to the
> SMBus master, and its T_CRIT_A output wired to shutdown control. It is
> obviously meant for hardware temperature regulation and overtemperature
> shutdown. If we configure the LM90 in one-shot mode, it means that the
> status registers will only be updated when someone asks the driver to
> update. What if a user loads the driver and never use it? (I do that all
> the time.) Then the hardware protections will be disabled. I don't want
> to be held responsible for that!

You're right - I withdraw my suggestion.

> > > The solution I have come to is:
> > > 
> > > Read first byte, read second byte, read first byte again. If the new
> > > first byte matches the old one, it's ok, we have our reading (most
> > > cases). If not, read the second byte once again. If the conversion
> > > rate is low enough (and I'll make sure it is) the second try should
> > > not fail. The good point there is that we don't have to wait for any
> > > event nor monitor any flag. The bad point is a 50 to 100% overhead.
> > > Still I believe it's overall better than the other possibilities (if
> > > you can call them that way).
> 
> Any objection to that? I expect this to make me read 18 (or 19)
> registers instead of 17, this ain't much of an overhead it seems.

Looks good then.

<snip>

> Thanks a lot for helping me think about all the possible solutions :)

You're welcome; regards,

-- 
Mark M. Hoffman
mhoffman at lightlink.com



More information about the lm-sensors mailing list