w1_gpio/w1_therm can return incorrect data

[Andrew Russell]

Problem:
Using w1_gpio + w1_therm in python3 on Raspberry Pi, the driver occasionally returns the value from the previous sample instead of the current sample.
Important: This is a 'silent problem', you won't usually know that it has occurred unless you look at the smoothness of a temp/time graph (see attached pdf).

Linux RPi02 4.9.28+ #998 Mon May 15 16:50:35 BST 2017 armv6l GNU/Linux

My findings:
This problem happens on both RPi V3 and RPi Zero W, but happens much more frequently on the Zero.
What seems to be happening:
The 1-wire bit stream has occasional pauses in it, as if the driver is being interrupted. I have seen pauses from 150us to 1ms.
If the pin is high when the pause occurs, it's ok.
If low, it breaks the protocol and the packet will be ignored.
If that happens during the 'read scratchpad' command (0xBE), I expect it will cause a CRC and the driver will re-read.
If that happens in the 'convert' command (0x44), we have a problem.
 The driver will assume the convert has been issued, and will issue a read command (0xBE) approx 780ms later.
 However, the convert command was not successfully issued, so the data read will be from an older point in time.
The attached pdf has examples from the pulseview logic analyzer.

In my tests:
RPi V3: Executed 477 samples, 3 of which were old data (0.6%).
RPi Zero: Executed 522 samples, 45 of which were old data (8.6%).

Possible remedy:
 driver should disable interrupts during critical operations, such as sending a low bit.
 driver should issue a readBit() after 'convert' to check that the DS18B20 has gone busy.

Testing:
You need to apply a changing temperature to the DS18B20 in order to spot what seems to be an old sample. I have built a reasonably simple test rig to do this. I am happy to test any new code on my rig, or I can describe how to build the test rig.

Many thanks!