Differences

This shows you the differences between two versions of the page.

--- en:iot-open:practical:hardware:sut:stm32:emb4_1 [2024/04/22 17:38] – created ktokarz
+++ en:iot-open:practical:hardware:sut:stm32:emb4_1 [2024/04/22 17:56] (current) – [Result validation] ktokarz
@@ Line 1: / Line 1: @@
 ====== STM_4: 1-Wire Temperature Sensor =====
-The temperature-only sensor **DS18B20** uses a 1-wire protocol. "1-wire" applies only to the bidirectional bus; power and GND are on separate pins. The sensor is connected to the MCU using GPIO 6 only. Many devices can be connected on a single 1-wire bus, each with a unique ID. Except plastic version, which we have in our laboratory (enclosure TO-92) **DS18B20** also comes in a water-proof metal enclosure version that enables easy monitoring of the liquid's temperature.
+The temperature-only sensor **DS18B20** uses a 1-wire protocol. "1-wire" applies only to the bidirectional bus; power and GND are on separate pins. The sensor is connected to the MCU using GPIO D0 only (PA_3 in Nucleo numbering). Many devices can be connected on a single 1-wire bus, each with a unique ID. Except plastic version, which we have in our laboratory (enclosure TO-92) **DS18B20** also comes in a water-proof metal enclosure version that enables easy monitoring of the liquid's temperature.
 ===== Prerequisites =====
 To handle operations with **DS18B20**, we will use a dedicated library that uses a 1-wire library on a low level:
 <code ini>
-  lib_deps =
+  lib_deps = milesburton/DallasTemperature@^3.11.0
-             milesburton/DallasTemperature@^3.11.0
 </code>
 Sensor readings can be sent over the network or presented on one of the node's displays (e.g. LCD), so understanding how to handle at least one of the displays is essential:
@@ Line 39: / Line 38: @@
 #include <DallasTemperature.h>
 </code>
-<note important>Also, remember to add the LCD handling library, as present in the EMB9 scenario, unless you decide to use another output device.</note>
+<note important>Also, remember to add the LCD handling library, as present in the STM_9 scenario, unless you decide to use another output device.</note>
 === Step 2 ===
 Declare the 1-Wire GPIO bus pin, 1-Wire communication handling object, sensor proxy and a variable to store readings:
 <code c>
-#define ONE_WIRE_BUS 6
+#define ONE_WIRE_BUS D0
 static OneWire oneWire(ONE_WIRE_BUS);
 static DallasTemperature sensors(&oneWire);
@@ Line 56: / Line 55: @@
   sensors.begin();
 </code>
 === Step 4 ===
 Read the data:
 <code c>
+  sensors.requestTemperatures();
   if (sensors.getDeviceCount()>0)
   {
     tempDS = sensors.getTempCByIndex(0);
-  }
-  else
-  {
-    // Sensors not present (broken?) or 1-wire bus error
   }
 </code>
@@ Line 76: / Line 71: @@
   * ''sensors.getAddress(sensorAddress, index)'' - reads device address given by ''uint8_t index'' and stores it in ''DeviceAddress sensorAddress''.
-The library can make non-blocking calls, which can also be implemented using timers, as presented in the scenario [[en:iot-open:practical:hardware:sut:esp32:adv1_1|]].
 ==== Result validation ====
 The observable temperature is usually within the range of 19-24C. If you find the temperature much higher, check your code, and if that is okay, please contact our administrator to inform us about the faulty AC.
+===== FAQ =====
+**I've got constant readings of value 85.0. What to do?**: Check if GPIO is OK (should be D0), check if you initialised controller class and call the function ''sensors.requestTemperatures();''. Give the OneWire bus and the sensor some recovery time (at least 250ms) between consecutive readings.
 <WRAP noprint>

en/iot-open/practical/hardware/sut/stm32/emb4_1.1713807509.txt.gz · Last modified: 2024/04/22 17:38 by ktokarz