DS1820 interaction

Hi, all.
Recently, I’ve encountered with an issue. BBB can’t detect DS18B20.

Purpose: Develop custom DS18B20 driver.

  • BBB;
  • DS18B20;
  • kernel 5.10.168-ti-r72

1. Based on device tree.
Project structure:
a) Kernel space:

  • gpio driver (.ko);
    Once it is loaded a dedicated gpio pin is set up to communicate with DS18B20.
    Also, the driver creates attributes: direction, value, label under /sys/class/.

b) User space:

  • GPIO library - sets pin direction and value;
  • DS18B20 library - sends commands to DS18B20 and reads data back;
  • Application - reads temperature from DS18B20.

What’s done:

  • .dtsi file created; descibes which pin is used to interact with DS18B20;
  • .dtsi included in the main .dts (am335x-boneblack.dts);
  • main .dts compiled into .dtb and trasfered to BBB;
  • on BBB .dtb moved to boot section;
  • load the driver. After this there is gpio pin in the system under (sys/class/…/gpioX.Y) with attributes;
  • compile and run application.

Result: BBB can’t detect DS18B20.
It turned out that timings don’t correspond to the datasheet, means they exceed max value defined in the datasheet.
For example:
according to the diagram “Reset and Presense” low state duration should be 960 us (max), but in my case it is 1.4 ms.
NOTE: in aforementioned case (.ko) provides an interface to communicate with DS18B20.
Communication protocol implemented in the user space. GPIO lib uses open, read, write, close syscalls to get access to the gpio attributes.

2. Driver with communication protocol implemented in kernel space.
Project structure:
a) Kernel space:

  • Character device driver under /dev/ds18b20;

b) User space:

  • Application;

What’s done:

  • kernel module (.ko) created; communication protocol implemented in .ko file;
  • application reads temperature from /dev/ds18b20;

Result: BBB successfully detects DS18B20 and can read temperature.
NOTE: in both cases timings are the same in microseconds.

Assumption why thete is a difference:
In the first case it is not possible to provide accuracy (in microseconds) b/c application uses syscalls to get access to the HW.
In the second case, all timings are managed by kernel and application just reads the result.

BBB can detect Dallas sensors, your driver can’t.

In order to operate multiple sensors at a single GPIO line, I developed a driver called libpruw1 with mid-level API. The driver handles the hardware line in accurate timing, so that the user can send or receive bytes over the bus, wherefrom the temperature values (or any other result) can get evaluated from.