W1: w1_therm.c standardize units to millidegrees C
PATCH 1/1 W1: w1_therm.c standardize units to millidegrees C
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 Cw1_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.
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
w1_therm.c +2 -1
@@ -92,6 +92,7 @@ struct w1_therm_family_converterint (*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_converterstatic inline int w1_DS18B20_convert_temp (u8 rom[9 ]) {s16 t = (rom[1 ] <<8 ) | rom[0 ]; - t /=16 ; + t = t*1000 /16 ;return t; }
Signature · 2 lines
David Fries <[email protected]> http://fries.net/~david/ (PGP encryption key available)
Quoted 7 lines · 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_tempdegrees Cw1_DS18S20_convert_tempmillidegrees C
Quoted 6 lines
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?
Signature · 3 lines
Ville Syrjälä [email protected] http://www.sci.fi/~syrjala/
Quoted 1 line · Ville Syrjälä
Why isn't
w1_thermpresented 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.
Signature · 1 line
Evgeniy Polyakov
Quoted 7 lines · Evgeniy Polyakov
Quoted 1 line · Ville Syrj??l??
Why isn't
w1_thermpresented 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.
Signature · 2 lines
David Fries <[email protected]> http://fries.net/~david/ (PGP encryption key available)