Unnecessary use of a magic number (9) - instead consider using _read_scratchpad() and refactoring to support CRC checking.

Hi.

First off, great library. I had no trouble getting my external ds18b20 module working.
I'm using the ds18b20 in external supply mode so I'm providing a dedicated 3.3v supply to the device. My data line has a 4.7k pullup per the datasheet recommendation.

Before some recent code changes to totally unrelated code I was seeing only very rare crc errors. After some recent code changes to other tasks the device isn't detected at power up even after three retries.

As the change was outside of the temperature reading task that I'm using to call the ds18b20 read function I suspect a timing change is causing the issue here but I'm not seeing anything particularly suspicious in my traces. Any thoughts where to look? I'm wondering if there is other timing sensitive code in your library that may need to be protected from interruption from outside tasks, or maybe if its related to a lack of full gpio pin configuration? I'm not doing any gpio configuration in my code and it looks like the esp32-owb only does direction and level configuration and doesn't touch the optional pullup/pulldowns that are on most gpio pins.

&temp must be replaced with value here:

Hi!

I'm using one parasistic power sensor, without strong pull up, with a pull-up resistor of 4.7k to 3.3.

In GPIO mode it works fine and I see during the conversion a voltage of about 3.2V.

In RMT mode the voltage does down to 2V, so it means only the pull-up resistor is giving current, and not the I/O GPIO.

I didn't debug yet, I guess you might know why RMT is not staying High during conversion.

Also I'm using IDF 5.1-rc1 and I get this warning:

esp-idf/components/driver/deprecated/driver/rmt.h:18:2: warning: #warning "The legacy RMT driver is deprecated, please use driver/rmt_tx.h and/or driver/rmt_rx.h" [-Wcpp]

Could we include an adaptation to read MAX31850 devices too?
I believe the only difference is that data is 14-bits resolutions. But in the code there are so many checks to ensure its 9-12.
What would be proper places to change in order to adapt?
Thank you

So, with same wiring, with external power (no parasitic mode) the same sensor works on Arduino but does not work on ESP32 with your library.
On Arduino i'm using DallasTemperature library and it works solid, reliably every time. With esp32 board - no way, i cant get a reading.

The problem is i have no idea what goes wrong. The wiring is correct because onewire detects the sensor and initializes it, but reading the temperature doesnt work. The sensor always returns 85 degrees celcius (which is the 'default' value returned by dallas in case of setup problems).
My code for initialization and reading of sensors:
https://github.com/lafar6502/esp_playground/blob/master/main/temp_sensors.c

Another thing - your example doesn't work either. It doesn't even detect the sensor.
No idea why, basically my code is almost exactly the same as in your example, but i suspect some differences in build/compilation/linking? Tried modifying your example in various ways but no success, sensor is not found at all. Sorry i cant put more information in because there's no more information available to me - i have no idea how to diagnose the problem and i cant find any issue with my side of things - wiring is verified, checked with Arduino, code is basically borrowed from your example. And example is not working out of the box. My board is esp32-wrover

Hello, I have issue with all of my DS12B20 sensors: they all are about 5 degrees too high: I get 28-30 as my room temperature. I am sure that all wiring is done correct, I have tested it with sensors from 2 different sources. TO-92 is soldered directly to male header on PCB carefully at low temperature using tweezers as a heatsink to prevent it from overheating.
Using sensor in solo mode.

Debug information:
ds18b20: temp_LSB 0xbf, temp_MSB 0x01, temp 27.937500

Thank you for your help

Hi @DavidAntliff, I have a suggestion:

I find error-prone using two different return types, bool and DS18B20_ERROR, specially since their values mean the opposite of each other. Furthermore, the compiler doesn't even throw a warning if you check one against each other.

As an example, these 2 functions are normally used together but their return types are inconsistent:

bool ds18b20_convert(const DS18B20_Info * ds18b20_info);
DS18B20_ERROR ds18b20_read_temp(const DS18B20_Info * ds18b20_info, float * value);

I believe all ds18b20 functions should use the DS18B20_ERROR return codes for code legibility (which I admit I am obsessed with). However, the change would potentially break existing code checking for true or false, since DS18B20_OK == false. If anything, I would change the value of DS18B20_OK to be 1 so it also equals true. That way the only code that would break is if it checks the return code just relying on it being != 0 or != false in case of error.

If this is something you are willing to consider, I don't mind making the changes and doing a PR. What do you think?

Functionality-wise it works great. Thank you for sharing.