Re: [RFC] Issues with Zephyr Sensors API and ways to resolve them
Nashif, Anas
I am fine with humidity unit change and now that I see the original author’s reply I am more comfortable with this.
toggle quoted messageShow quoted text
Anas
On 26/01/2018, 02:10, "Paul Sokolovsky" <paul.sokolovsky@linaro.org> wrote:
Hello Anas, On Thu, 25 Jan 2018 14:16:20 +0000 "Nashif, Anas" <anas.nashif@intel.com> wrote: > Hi, > If I remember correctly, the PCM units for humidity are coming from > Linux sysfs. Yes, the original author of Sensors API, Vlad Dogaru, replied on Github and pointed that is the case https://github.com/zephyrproject-rtos/zephyr/issues/5693#issuecomment-360461449 . However, Linux uses milli-degrees for temperature, but we degrees. > When this interface was originally proposed, it tried to > follow a few things from the Linux world. > > See https://www.kernel.org/doc/Documentation/hwmon/sysfs-interface > > In general and for other units, you really need to think about high > accuracy sensors. We don't have problems with that, allowing for precision of one millionth of a unit. Of all physical (well, let's say "environmental") quantities, relative humidity is the least to worry about re: precision - it's a challenge to find a sensor offering precision of 0.1 unit (unit being a percent). > I do not think it is terribly bad how the units are > defined as long as they are defined and are consistent. So this is > basically not a bug, but if there is a general agreement that it > should be changed and for a good reason other than avoiding > additional calculation, I am fine with that. They aren't consistent, that's the problem. It's not a bug indeed, but an inconsistency, which can only become more glaring going forward. Even now, few have few confused samples and even one driver which mix up milli-percents and percents. So far, nobody seems to object to the change, and it seems that's last reasonable chance to do it, to allow one release of "stability" before the expected 1.12 LTS. > > Anas > Thanks for the comments. Any thoughts on the 2 other points? > 2. By extension, we may want to re-review unit of > measurements used for other values too. > 3. Definition of struct sensor_value is vague, leading to > confusion. [] -- Best Regards, Paul Linaro.org | Open source software for ARM SoCs Follow Linaro: http://www.facebook.com/pages/Linaro http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog
|
|