[PATCH] W1: w1_therm.c standardize units to millidegrees C

[PATCH] W1: w1_therm.c standardize units to millidegrees C

[David Fries]

Here is the patch to standardize the temperature units to millidegrees
C for the two sensor conversion routines.  Previously the routines
were,

w1_DS18B20_convert_temp degrees C
w1_DS18S20_convert_temp millidegrees C

Unfortunately this will break any program using the ds18b20 value as
it will now be 1000 times bigger.  Fortunately there can't be that
many users out there, or some of these bugs will have been fixed by
now, such as the negative C error (see previous patch) that makes me
think the ds18b20 is the better choice to change because of the
current bugs.

Signed-off-by: David Fries <david@fries.net>

Index: slaves/w1_therm.c
===================================================================
RCS file: /home/david/kernel/k/spacedout/patches/linux/drivers/w1/slaves/w1_therm.c,v
retrieving revision 1.5
diff -u -p -r1.5 w1_therm.c
--- slaves/w1_therm.c	24 Jan 2008 01:23:46 -0000	1.5
+++ slaves/w1_therm.c	24 Jan 2008 01:57:39 -0000
@@ -92,6 +92,7 @@ struct w1_therm_family_converter
 	int			(*convert)(u8 rom[9]);
 };
 
+/* The return value is millidegrees Centigrade. */
 static inline int w1_DS18B20_convert_temp(u8 rom[9]);
 static inline int w1_DS18S20_convert_temp(u8 rom[9]);
 
@@ -113,7 +114,7 @@ static struct w1_therm_family_converter 
 static inline int w1_DS18B20_convert_temp(u8 rom[9])
 {
 	s16 t = (rom[1] << 8) | rom[0];
-	t /= 16;
+	t = t*1000/16;
 	return t;
 }
 

-- 
David Fries <david@fries.net>
http://fries.net/~david/ (PGP encryption key available)

Re: [PATCH] W1: w1_therm.c standardize units to millidegrees C

[Ville Syrjälä]

On Wed, Jan 23, 2008 at 08:03:30PM -0600, David Fries wrote:
> Here is the patch to standardize the temperature units to millidegrees
> C for the two sensor conversion routines.  Previously the routines
> were,
> 
> w1_DS18B20_convert_temp degrees C
> w1_DS18S20_convert_temp millidegrees C
> 
> Unfortunately this will break any program using the ds18b20 value as
> it will now be 1000 times bigger.  Fortunately there can't be that
> many users out there, or some of these bugs will have been fixed by
> now, such as the negative C error (see previous patch) that makes me
> think the ds18b20 is the better choice to change because of the
> current bugs.

Why isn't w1_therm presented as a hwmon device?

-- 
Ville Syrjälä
syrjala@sci.fi
http://www.sci.fi/~syrjala/

Re: [PATCH] W1: w1_therm.c standardize units to millidegrees C

[Evgeniy Polyakov]

On Thu, Jan 24, 2008 at 02:39:09PM +0200, Ville Syrjälä (syrjala@sci.fi) wrote:
> Why isn't w1_therm presented as a hwmon device?

First, because it was created way earlier, second, because it is not a
hardware monitor :)
Feel free to create a driver to bind thermal sensors to hwmon framework,
but I'm not sure it worth time.

-- 
	Evgeniy Polyakov

Re: [PATCH] W1: w1_therm.c standardize units to millidegrees C

[David Fries]

[-- Attachment #1: Type: text/plain, Size: 3708 bytes --]

On Thu, Jan 24, 2008 at 05:53:32PM +0300, Evgeniy Polyakov wrote:
> On Thu, Jan 24, 2008 at 02:39:09PM +0200, Ville Syrj??l?? (syrjala@sci.fi) wrote:
> > Why isn't w1_therm presented as a hwmon device?
> 
> First, because it was created way earlier, second, because it is not a
> hardware monitor :)
> Feel free to create a driver to bind thermal sensors to hwmon framework,
> but I'm not sure it worth time.

They aren't typically found on motherboards.  With their long cable
length they are more commonly used for personal weather stations.  The
guidelines list 750 meters as the longest distance signal wise, and
one example listed example 100 meters and 100 iButton devices as
possible.

The same one wire sensors are part of the OpenBSD equivalent sysctl
command to get hardware information and sensor data.  I added support
for the ds18b20 sensor to OpenBSD.  Interestingly they also had a bug
when reading negative C values, but it was a different implementation
of the bug.  In their implementation the temperature sensor has a
hardcoded 5 second sleep between temperature conversions.  When the
temperature is read the syctl data store is updated.

I did not care for the method which OpenBSD merged the sensor data in
with the other temperature conversions.  Their argument is that the
a user program doesn't block when it goes to read the sensor data.
But the program can't find out how old the data is.  It can't find out
if the temperature didn't change or if there just hasn't been an
updated temperature reading.  The temperature readings are also always
taking place no matter if anyone is reading the results or not.  It
might not be a big deal except the conversion for one sensor is 750ms
and blocks the 1-wire bus for the duration when using parasite power.
Both the Linux and OpenBSD assume parasite power.  In practice it
takes about one second per sensor.  On an otherwise idle system the
one wire scanning and temperature conversion was obvious in top and
vmstat in OpenBSD even if nothing is using the data.  Just think, if
they did have those 100 sensors, the data would be over 105 seconds
old and there would be no way to know just how old.

I'm seeing the applications using these devices as custom written
programs that can easily be written to the current sysfs interface.
That allows the application to initiate a conversion on the sensor it
wants when it wants it.  If anyone does want to pull it into the hwmon
framework please make it optional and allow the application the same
control of which sensor, when to poll, and don't do so when no one is
reading the data.

I'm interested in putting a few sensors around the house to log
temperatures and control the furnace based on that data.  I'm
expecting to poll the sensor connected to the furnace duct much more
frequently than the others.  By default the w1 driver scans the bus to
detect missing and or new devices.  I let it scan once and then
disable it as my network hardly ever changes, especially as right now
it only has the one sensor on it.  I would like to be able to give the
driver a sensor id when it isn't scanning the bus and let it do a
targeted scan for present or not present and then report back to the
program.  That way a program that has a list of what devices should be
there can find out if they are detected without the driver constantly
scanning the bus for the same old devices.  By the way the default bus
scan takes 7.7 seconds to complete and then sleeps 10 seconds before
the next scan leaving the bus idle for only 56% of the time.

-- 
David Fries <david@fries.net>
http://fries.net/~david/ (PGP encryption key available)

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]