LSB of scratchpad[0] is always high, causing CRC checks to occasionally fail about onewire

[fuchsnj]

I tested a bunch between an Arduino and my STM32F103. It actually looks like the first byte of the scratchpad is being occasionally read wrong by the STM32. The least significant bit is always 1 (it's always an odd number). For all of the rows where CRC match is false, if you set the LSB to 0, the CRC matches. I'm still not sure what is causing this though.

[fuchsnj]

With the exact same wiring on the same device, when I use an Arduino library to interface with the ds18b20 it works fine, but when using this library, the LSB of scratchpad[0] is always 1 (causing the CRC check to fail ~50% of the time). So I'm fairly confident I've ruled out hardware issues, but this also isn't an issue with the CRC algorithm so I'll update the issue name.

[fuchsnj]

I wrote my own onewire implementation, and used all of the timing values provided by the Maxim 1-wire document (https://www.maximintegrated.com/en/design/technical-documents/app-notes/1/126.html) and all of the readings look correct for me now. I suspect there is a timing issue in this library, since it doesn't use the recommended timings in some places.
I'll publish my implementation in the next few weeks when it's more complete if you want to reference it.

[fuchsnj]

The root cause was timing issues because the default clock speed on the stm32f103 (which I was using for testing) was too low.
See stm32-rs/stm32f1xx-hal#169 for more details. Closing since this shouldn't be an issue with this library.

[kellerkindt]

Hi there, great to hear you could fix your issue. I know that using DelayUs is not great, and it can cause runtime issues on hardware that is faster/slower as the one I am testing it on locally (stm32f103) #11.