* DHT module: fix the handling of negative temps.
The macro handling the conversion from the 2 bytes buffer to a double
was handling negative values by checking the sign bit and taking the
negative value of the number minus the sign bit.
Unfortunately this does not work as the negative values are represented
in 1's complement, so for instance -1 was becoming -32767
* +1 = b0000_0000_0000_ 0001
* -1 = 1111_1111_1111_1111
This replace the spacial code with a signed 16 bits value.
* Refactoring: removes some code duplication.
* Fixed the conversion of the 8/16 bits values
Co-authored-by: Marco Dondero <marco@dondero.eu>
The PR removed the bulk of non-newlib headers from the NodeMCU source base.
app/libc has now been cut down to the bare minimum overrides to shadow the
corresponding functions in the SDK's libc. The old c_xyz.h headerfiles have been
nuked in favour of the standard <xyz.h> headers, with a few exceptions over in
sdk-overrides. Again, shipping a libc.a without headers is a terrible thing to do. We're
still living on a prayer that libc was configured the same was as a default-configured
xtensa gcc toolchain assumes it is. That part I cannot do anything about, unfortunately,
but it's no worse than it has been before.
This enables our source files to compile successfully using the standard header files,
and use the typical malloc()/calloc()/realloc()/free(), the strwhatever()s and
memwhatever()s. These end up, through macro and linker magic, mapped to the
appropriate SDK or ROM functions.
* DHT11 read sometimes failed with checksum error.
The code assumed DHT11 devices only ever return zero in the temperature and humidity decimal fraction bytes. The datasheet doesn't guarantee this is the case, and by observation I have noticed that indeed the DHT11 may sometimes return another number, usually close to zero. This means that the code would fail with a checksum error, as the fraction bytes were not included when the checksum was calculated. These bytes are now taken into account and also returned as part of the measurement.
This also means that the related dht.read() function is non-functional. If you have a DHT11 device that returns a non-zero decimal part, dht.read() will interpret it as a DHT22 result and return the wrong measurement. For this reason dht.read() should be retired. This patch does not address this issue.
Emdioh
Johny Mattsson
Arnim Läuger
sergio
TerryE