beginWriteBit not setting zeros to be written during future read time slots, ones are written instead #2

Youen, I have a question about the function beginWriteBit. It takes two parameters: what bit to send and whether it will be written to the bus only during the next read time slot imposed by the master, or during all future read time slots until reset or another beginWriteBit.

So, as per the DS18B20 data sheet, since in this situation we are not using parasitic power, the master can send a Convert T command (0x44) and then provide read time slots to the bus on which the selected slave writes zeros until the conversion is done (the other option would be waiting a few ms but I would rather make this in a tidy manner).

My situation: Arduino Uno running the official OneWire library as master, and FakeDS18B20 (your library) on an Arduino Nano slave. On the master I use the the read_bit method, using a cheap logic analyzer I see that all reads after even 10 milliseconds past the Conversion T command return ones, not zeroes. Your code mimics the DS18B20 with a 12-bit resolution, so ones should be expected only after about 750 ms, not 10 ms. I see a one every time, looping the read_bit function on the master after a conversion T command always returns one, even after forcing write_bit(0, true) on the slave.

Are you sure the beginWriteBit function is working correctly? As per the logic analyzer measurements, the master is working fine. I don't quite understand the way beginWriteBit works, I'm looking at the low level code but it's a little too overwhelming for me. As per the documentation you provide, it just sets what bit to write to the bus on future time slots. Maybe the value is initialized to 1 instead of zero and I'm failing to set it to zero properly? I have not touched the code on your example. I can provide any extra information and logic analyzer measurements you need for us to debug this.

Thank you very much.

BTW, it would have been impossible to get anywhere without a cheap 5 USD logic analyzer. Guys, get one before you even attempt to debug any One-Wire related issues.

Edit to my previous comment (edits don't work for some reason):

ALright, after a few hours of testing I have finally solved it. The sad thing is that I don't know what did the trick. I am sure it was software-based because I had two Arduino Nanos, one had the fix and the other didn't. Both had OneWireArduinoSlave on them. Upon doing a diff between the files in the original library files and mine, there are no differences that could have caused the bug. At first I thought it was an electrical issue because I did swap Arduinos and changed what USB ports I was using and such, but after that I also swapped Arduinos back without touching anything else, one having the bug and the other not, so that's why I say it's software-based.

The good thing is that I'm sure the issue was software-based (I'm an electrical engineer so I know what I'm doing) and the error could have been made in a modification I've made to FakeDS18B20.ino, so it's not a bug in the library. The only thing I can do now is wait until the issue happens again.

Thank you anyways, the library is working fine.

Yep, a logic analyzer is a requirement for this kind of work. I used a $30 second-hand USB oscilloscope for the task, not the best tool, but works.

Glad you "fixed" your issue. We have a saying in France, "c'est tombé en marche" (by opposition to "c'est tombé en panne"). I guess a translation would be "it broke up". Don't touch anything now it's working ;)

I'm pretty sure beginWriteBit works in some cases because I use it on some of my projects, which have been running flawlessly for years. But that doesn't mean there wouldn't be some kind of bug in other/untested cases. Maybe you'll find the explanation later.