lkml.org 
[lkml]   [2004]   [Jul]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRE: --- (or anyone else) one small i2c question.
    Date
    Hm, Greg must be on virtual holiday.

    Yoo-hoo?

    Anyone else, then alive?

    I hope open source doesn't mean "Closed community :)"
    Here I am. I want to contribute some code. But I need some help, because not
    everything can be done alone on this planet. Sometimes you need guidance.

    It's better to talk, and send people away on a search, then to ignore
    people.

    And all I want is some small help with i2c.

    Reinder.







    -----Original Message-----
    From: linux-kernel-owner@vger.kernel.org
    [mailto:linux-kernel-owner@vger.kernel.org] On Behalf Of Reinder
    Sent: Saturday, July 17, 2004 16:30
    To: linux-kernel@vger.kernel.org
    Subject: Greg (or anyone else) one small i2c question.

    Greg,

    While having some fun, with the old 2.4 vt8231, ""porting"" that to the 2.6
    Branche, my eyes raised some strange question, which I hope you can answer.

    From the Sysf-Interface, it states:

    temp[1-4]_max Temperature max value.
    Unit: Milidegrees Celsius
    Read/Write value.


    I far as I know, one Milidegrees is one thousand Grade Celsius.

    The actual Reading, from the vt8231 inside the io space is an 8 bit value.
    It contains for example a number "78" in "Celsius" for de 1f CPU temp
    location.

    Now, from various documentations floating around, for some undocumented or
    well hidden reason, this mostly is multiplied by 0.88 giving a reading of
    68.84

    I assume somebody thought about it and calculated that m that was a nice
    correction value.

    Converting it to the required units, would be 68.84*1000 = 68840
    Or, to avoid Floating points: ( (68*1000)*880)/1000 = 68840 Milidegrees
    Celsius


    That was, when life was easy.

    However, my bet is somebody figured out, that bit 7 till 6 in the reserved
    area from area 4b, contains also bits of temperature information. (Although
    the datasheet I have, describe that area as "Reserved")

    The value is readed, Anded with 192, then shifted to right by 6 to get the
    reading. "0,1,2,3". We assume the value is 3.

    Assuming that, this Value is stored in the same Magic Celsius Value,
    Multiplied by 880, this gives a correction of 2640 Milidegrees.

    That is, if it where separate 8 and 2 bit values. But As I can see, from the
    original code, it assumed as 1 10bit value.

    Thus the first value 79 is shifted to left by 2, and the second value is
    orred into it. Which gives (79>>2) = 316.
    Plus the low value "3" = 319

    Returning, this, in the old version, to Human readable format, it was
    multiplied by 10, and then divided by 4. Giving 797.5

    I assume, that something has changed, with the sensor output format.
    Thus, the new return formula would be:
    Multi by 1000, divide by 4.
    Now we have 79750.



    Throwing in the 0.088 Correction Factor the final result is:
    79750* 0.088 = 70180 Milidegrees Celsius

    Or 319 * 880 /4 = 70180

    Or 319 * 220 = 70180

    If this was "temp3" , it would result in 1 sensors.conf line:

    Compute temp3 @



    Is my final concussing Right?

    If so, I will move on to the voltage part :)
    If not, I Hope somebody can point me out where to go...


    http://tser.org/vt8231/

    Regards
    Reinder Kraaij.





    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2005-03-22 14:04    [W:0.023 / U:90.760 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site