Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
ONEWIRE_PRESENCE_TIME_MIN issue #72
Even though the
It seems like the library's
Other timing/delay functions of this library seem to work OKish (
So it seems safe to me to lower the
BTW, original DS18B20 can cope with the extended PRESENCE pulse of this library but the Chinese fake/counterfeit clones that started appearing in 2018 do not have proper timing and fail in a scary way. Unfortunately noone but me yet has documented that Chinese "geniuses" copied the Dallas/Maxim DS18B20 and started spreading the buggy copies around the world.
I rewrote this a bunch of times already and I am a bit confused now.
Well, I dug out my old configs and notes, and remembered what's going on.
After that I started to think how tunings can be implemented. Also I wanted to figure out which config parameters correspond to which real IPL value. For it I decided to rewrite calibration sketch a bit and expose waitLoopsWhilePinIs() into it. That required moving function definition into header file (as I was told by linker error, sigh). At this stage I noticed that relatively new arduino IDE's enable Link Time Optimisation (-flto key). And then it hit me! LTO is a very powerful post-compilation optimisation tool, with its help I managed to pack atmega16's old program into atmega8 not so long ago! And i believe it became enabled by default after this lib was initially written. Even though I did not have a chance yet to study LTO vs non-LTO generated assembly codes, it's highly likely it had some kind of impact. Mainly because after moving function into header this sketch
gives precise showPresence timing and precise 1mS!
P.S. All required functions are moved to public section in OneWireHub.h
@kutukvpavel I'm not sure what's the point. I reported that
You say that if you replace
I am most happy that I managed to debug the communication issues with Chinese fake "waterproof" DS18B20. That was the most challenging piece.
FYI, LTO is not enabled by default because it causes serious issues, AFAIK.
P.S. BTW, I suspect the
The point was I thought I've found the cause of the bug and a clean solution. Maintainer pretty much abandoned this lib, last commit was 2 years ago, he responds to issues in comments once in about 6 month and that's all. So there is almost no hope anything will get fixed "on its own". Especially because for most of the users it works and issues are rare and complicated.
but are off by 15% for this
Contraversely, LTO in this case not breaks, but makes the first variant work. Without LTO both are 850uS.
@kutukvpavel I gave it a second thought and I agree with you that the
Sorry for the LTO confusion - I have another AVR target installed in the IDE (for ATMEGA328PB support), it comes with newer GCC and the LTO is specifically disabled there because otherwise it caused weird issues.
Anyway, I compile this library with stock AVR target and since I'm getting 850-ish µs it's apparently not LTO-fixed.
BTW, if 1ms is 850 µs then all OneWire timings are off by another 15 %. It would be great to fix the library for AVR to get 1 ms = 1000 µs.
It would perhaps make sense to test/focus on Arduino IDE 1.8.8 with much newer GCC. Things might be quite different there again.
Keep researching. Having a 100% working OneWire slave is always a good thing.