TFT library is somehow blocking DS18B20 libraries from being able to read temperature sensor

Other Hardware Science and Measurement
1

DS18B20 - pretty standard common sensor, right?

Well I want to read it, on a NodeMCU ESP-12E module, at full 12 bit resolution, and display it on an LCD.

An obscure Chinese LCD that only one person has ever written a library for:

Problem: he has used some "low level hardware commands" that have blocked either the Onewire or the DallasTemperature libraries from being able to read DS18B20 sensors.

I know this because in my setup routine, I am able to run:

sensors.begin();
sensors.requestTemperatures(); 
float temperatureC = sensors.getTempCByIndex(0);
Serial.print(temperatureC);

Over and over no problem. The moment I add

...
tft.begin();
...

sensors.getTempCByIndex(0); suddenly reads -127.000.

I have managed to find ONE "library" (actually just an ino) that can read this DS18B20 sensor while the TFT is running, it doesn't use Onewire or Dallastemperature or ANY library, it just bitbangs the GPIO pin:

Problem: It only returns 9-bit values, and I need 12-bit.

Can anyone help me either: fix this TFT code so that it stops blocking the Onewire/Dallas code, or fix this new bitbang code so that it actually returns the full 12-bit value, or find another way of reading the DS18B20 sensor?

I have tried:

  • Every other DS18B20 library
  • Every other GPIO pin
  • Changing pullup from 10k to 5k

I have no idea why that bitbang code works and the Onewire/Dallas libraries do not.

2

The -127 indicates no connection or, by extension - no, or inadequate, power. You had best look in that direction first.
The 12 bit resolution is by default - no code required.
The requisite pullup is 4.7k. Why you would use anything else is unclear.
I bet you never had any reason to use anything other than the Miles Burton library that everybody else uses. It is however quite reasonable to dispense with a library altogether if you are only using one sensor, and I believe that approach uses less resources.

You mention two different LCDs, one on I2C bus and the other SPI. Since you imply the display is the problem, it would be a good idea to be more specific about what you are using - and how. Further, the simple projects diagram shows the I2C display not using the I2C bus, and it might be best not to ask the reason behind this.

3

I have heard 10k pullups can be substituted and it was all I had. I put a second 10k in parallel to make 5k to see if that closer to spec pullup would help, it did not.

The original DallasTemperature library that everyone references is the one that didn't work as long as the TFT was initialized.

Sorry, the link I gave was only for someone else's code I found that worked for reading the sensor - I was unclear, that is my fault. I only have one LCD on SPI. This linked website's code, to display on some other i2c TFT that I have no business with, was just linked for the DS18b20 code that was unique and I tried it and it worked.

But good news! I answered my own question in the time being lol. In that website's code's ds18b20_read_byte(void) command, where the for loop counts i < 8, I changed it to i < 12. And it just works. I get a full 12 bit reading out of my DS18B20 sensor, when no other library on earth could do it while this TFT of mine is running.

I still have no idea how my TFT library's code blocks the classic Onewire/DallasTemperature combo from working, and instead making them only return -127.000, it is a curiosity, but the desired result is now solved :slight_smile:

I'm also curious how I was getting half degree increments out of the sensor if the for loop was only counting i<8, since 8 bits would imply dropping the half degree bit.

4

This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.