Maximum length 1 wire. Connecting temperature sensors to the Loxone smart home. Limitations and interfacing with industrial networks

1-Wire is a protocol for transferring data in both directions over a single wire.

This protocol was developed by Dallas Semiconductor Corporation (now Maxim Integrated) in the distant 90s, but is still actively used now: it is on 1-Wire that most of the "tablets" work - intercom chips (DS1990A), access cards, and also communicate via 1-Wire popular temperature sensors (DS18S20 and DS18B20), transistor switches (DS2405, DS2406), programmable I/O ports (DS2408), ADC and DAC, real time clock (DS2417) and much more.

The communication mode in this protocol is asynchronous and half-duplex (more on this), as well as "spiky" (when sending multibyte integers, the transfer goes from the low byte to the high byte).

At the same time, we always have a leader - one device on the bus that sends commands, and slaves - devices that receive these commands and respond to them, if necessary; each of the slave devices is connected directly to the common bus.

We emphasize once again that there can only be ONE master on the bus - otherwise conflicts will arise when both masters pull the blanket over themselves (in fact, there are some methods for organizing 1-Wire networks in multimaster mode - for example, using a DS2409 network brancher - but in "ordinary" life, it is still preferable to have only one master on the bus).

The 1-Wire protocol is good because it is not difficult to implement and requires only two or three wires for communication (data bus, ground and, if necessary, power); however, at the same time, it is not without its drawbacks - this protocol is very sensitive to time and interference. Also, 1-Wire is not designed to transfer large amounts of information and for high-speed data exchange - the maximum speed is 9600 Baud / s.

The 1-Wire protocol describes the physical, channel, network and transport layers of interaction (see the OSI model).
At the physical level, descriptions of connection methods, data bus and power requirements, etc. are given.
The link layer describes how bits are read and transmitted over a protocol.
The network layer describes how to address various devices on a line.
Finally, the transport layer describes the functional commands used by 1-Wire devices.

Protocol physical layer

Figure 1. An example of connecting a master and slave devices using the 1-Wire protocol.

By the way, about power - according to the datasheet, the data bus should be pulled up to power with a 4.7 kΩ resistor, however, this value is used for relatively short lines; if the distance between the devices is large enough, then the resistance of the resistor can be reduced.

Protocol link layer

The exchange of information is carried out by the so-called temporary, or time slots (60 μs): one time slot is used to exchange one bit of information. Data is transferred bit by bit, starting with the least significant bit of the least significant byte - this, by the way, quite often leads to errors for beginners - it seems that you need to transfer data from left to right, as it is stored in memory (that is, watch out for words: it seems , that you need to start with the high bit of the low byte (you are already confused, right?) - but no! When transmitting over 1-Wire, for example, a two-byte number, the order of transmission will be as follows:
We have the number 1023410 - in binary form it looks like this: 00100111 11111010 2
In memory (since we have a "spiky" data storage order) it looks like this: 11111010 00100111.
A 1-Wire transmission will look like this:
0→1→0→1→1→1→1→1→1→1→1→0→0→1→0→0
If you are as confused as I am, it's time to drink tea with a chocolate bar and settle everything in your head a little.

Move on. When exchanging information, the master initiates each communication at the bit level. This means that the transmission of each bit, regardless of the direction (transmit or receive), must be initiated by the master. The data bus is pulled up to "one" by default, so to start both receiving and transmitting, the master lowers the line to "zero" for a while.

Attention: neither the master nor the slaves set "one" on the bus - this is fraught with a short circuit: if one device sets "1" on the bus, and the other - "0"; therefore, both the master and the slave can use only two states: "to exit to zero" and "z-state" (to input without pullup). The pull-up to the power supply is carried out by a resistor (!).

Let's look at the 5 basic commands for 1-Wire communication: Write 1, Write 0, Read, Reset, and Presence. At the same time, in the drawings red line control from the master is allocated, blue– control of the line from the slave, black- a free line (with the help of a tightening, the tire automatically switches to "one").

Signal "Record 1". The master goes low for 1…15 µs. After that, during the remainder of the timeslot, it releases the bus.

"Write 0" signal. The master generates a low level for at least 60 µs, but no longer than 120 µs.

"Read" signal. The master goes low for 1…15 µs. After that, the slave, if it wants to send 0, holds the bus low for up to 60 µs; if the subordinate wants to transfer 1, then he simply releases the line. The master typically scans the bus state 15 µs after the bus goes low.

So, the slave holds the line to ground if it wants to send a "0", and simply releases the line if it wants to send a "1".
Thus, when reading, we get the following diagrams.

"Read on Receive 1" signal:

"Read on Receive 0" signal:

The main problems that arise in the implementation of read-write are problems with time, that is, "underexposure", or vice versa, "overexposure" of time delays when reading a line. These problems arise due to the fact that often do not make allowance for the slowness of high-level programming languages. This is especially true of various "additional" functions and nishtyakov. More

Reset/presence signal. Here, the time intervals of the pulses are different. The master pulls low for 8 time slots (480 µs) and then releases the bus. This long period of low state is called the "Reset" signal.
If there is a slave on the bus, then it must, within 60 µs after the bus master releases, go low for at least 60 µs. This response is called "Presence". If no such signal is detected, then the master must assume that there are no devices connected to the bus and no further communication is possible.
This bunch of signals always starts any exchange of information between devices.
In addition, it must be taken into account that any slave device, after receiving power, immediately issues a presence signal.
The "Reset" signal allows the host to prematurely complete the exchange of information - for example, if the temperature sensor sends us all of its memory, and we need only the first two bytes that contain the temperature value, then after receiving these two bytes, the microcircuit can simply lower the line to zero by the right amount of time - the sensor will understand that nothing more needs to be sent.

About the implementation: it is usually necessary to program the microcontroller as a master device, so there are a few tips: the microcontroller should generate signals (lowering the bus to the ground) a little more than the required minimum in time, and wait for responses from slave devices according to the worst forecasts - then protocol interaction will be optimal.
At the same time, the master should not forget to periodically check the state of the data line - that it returns to a pulled state over time - otherwise a situation may arise, for example, that some slave has broken down and is shorting, for example, the line to zero - and in principle , the protocol does not check this problem itself, errors may not occur - but more on that below.

Network and transport protocol layers

Let's consider the "higher" level of the 1-Wire protocol - the sequence of actions during the interaction of the master and slave, as well as the main commands. It should be noted that all data, including commands, are sent bit by bit sequentially, starting from the least significant bit.

Interaction algorithm:

The master sends a reset signal to the line. After the line is released for "retaliatory actions". If a slave is present on the bus, it reports "presence" within 60 µs.
If the master does not receive a "presence" response, then he considers that there are no devices connected to the bus.
Next comes the network layer of the protocol: the master must determine which of the devices on the data bus he will then access. This choice is provided by sending one of the ROM commands (1 byte long) that work with unique device codes:
- Search ROM ($F0)– "ROM search". If the codes of the connected devices are not known, then this command allows the master to determine them. A detailed description of this command is provided below.
- Read ROM ($33)- "read ROM" - the command is used if we know for sure that we have only one slave device (for example, only one temperature sensor or one intercom key), then to read its code, you can not worry about searching for ROM. Upon receipt of this command, all slave devices on the bus send their unique code.
- Skip ROM ($CC)– "ROM skip". This command is used when it is necessary to give a command to all devices on the bus - for example, it is necessary that all connected sensors simultaneously read the temperature.
- MatchROM ($55)– "ROM match". Used to select a specific slave device on the bus. After sending the command, the master sends a 64-bit code. Upon completion, only the slave device that received its ID is allowed to respond after receiving the next reset pulse - the rest silently wait for the reset pulse.
Naturally, for individual devices, some ROM commands can be added.
If "Match ROM" or "Skip ROM" commands were sent, then the host then sends some functional command - this is the transport layer of the protocol; however, the set of functional commands and further behavior (whether the master should be ready to receive data from the selected slave device, for example) depends on the specific 1-Wire device.

So, for example, if we have a microcontroller and DS18S20 - a temperature sensor, and we want to get a temperature value from this sensor, then the operation algorithm will be as follows:

MK sends a reset pulse
- since we have only one sensor on the line, we do not need to work with "addresses"
The MC sends the "Convert T" functional command - by this command, the temperature sensor will start a single temperature conversion; the result of this transformation will be written to the sensor memory
The microcontroller is waiting for the sensor to finish the conversion (the slave device in no way can itself report that it is "freed", so the microcontroller simply waits for the time indicated in the datasheet)
MK sends a reset pulse
The sensor responds with a greeting pulse
MK sends address command "Skip ROM"
The MC sends the "Read Scratchpad" functional command - by this command the sensor sends 9 bytes of its memory
MK reads the required number of bytes (the temperature value is contained in the first two)
If necessary, the MC terminates the communication session by sending a reset pulse

At the same time, it must be remembered that the slave devices can break down and, for example, always lower the line to 0. Let's say that the temperature sensor in the oven thermostat is short-circuited in this way. Then, if the leader does not check that the line returns to one, then the following situation is likely:

MK sends a reset pulse
The sensor shorts the line to zero - the MK detects that there is a hello pulse
MK sends the address command "Skip ROM" - without checking the line, of course
MK sends the function command "Convert T" - the sensor is still in a coma
MK is waiting
MK sends a reset pulse
history repeats, sensor sends zero
MK sends address command "Skip ROM"
MCU sends "Read Scratchpad" function command
MK reads the required number of bytes - and, of course, receives all zeros. Even if we read the entire memory along with the CRC, the CRC from zero will be zero - that is, no error will occur. The MK converts the temperature, receives zero, sends a command to heat the furnace. And so on ad infinitum!

It all looks pretty sad - and fraught with big problems! So rely on the protocol, but don't make a mistake yourself.

Let's return to the algorithm of interaction between the master and the slave according to the protocol. As you can see, it is not so difficult to implement the operation of the master device - at the same time, there are both ready-made libraries with code and hardware implementations - for example, from the same company Maxim Integrated. So, for example, for AVR-ok, a whole datasheet was written for the implementation of 1-Wire.

But it’s not so easy to implement a slave device - and if libraries exist (for example,), then I have not seen hardware implementations of the 1-Wire protocol. The principle of operation of slave devices is described in detail in their documentation, usually in the form of a block diagram.

There are a number of devices that use the 1-Wire interface, for example, the well-known "tablet" - an intercom key - in most cases works through this protocol: the microcontroller in the lock simply asks for a unique "tablet" code, and if this code is contained in the list of allowed devices, the microcontroller opens the lock.

In addition to various devices for identification and authorization (keys, pass cards), many sensors - whether they are temperature sensors, humidity sensors, lighting sensors, etc. - also use the 1-Wire interface for communication. In addition, there are also a number of microcircuits for "monitoring, management, protection and control of the restoration of the charge of autonomous power supplies of various types and purposes."

Unique 1-Wire device codes

A few words about the unique device codes that ROM commands work with. Each "single" device has its own 64-bit code, consisting of three parts:

The low byte is the code of the family to which the device belongs, the next 6 bytes are the serial number unique in the family, and finally, the high byte is the CRC, which serves to verify that the entire code was received correctly. So, for example, on native Dallos (now Maksimov's) "pills" part of the unique code - namely, the 48-bit serial number - is written on metal in hexadecimal form (everyone looked at their intercom keys together).

Let's take a closer look at what 1-Wire device family codes are:

Family code (HEX)	iButton device	Description
01	DS1990A, DS1990R, DS2401, DS2411	Unique serial number-key
02	DS1991	Multikey, 1152-bit secure EEPROM
04	DS1994, DS2404	4 KB NV RAM + clock, timer and alarm
05	DS2405	Single addressable key
06	DS1993	4 KB NV RAM
08	DS1992	1 KB NV RAM
09	DS1982, DS2502	1 KB PROM
0A	DS1995	16 KB NV RAM
0B	DS1985, DS2505	16 KB EEPROM
0C	DS1996	64 KB NV RAM
0F	DS1986, DS2506	64 KB EEPROM
10	DS1920, DS1820, DS18S20, DS18B20	temperature sensor
12	DS2406, DS2407	1 KB EEPROM + dual channel addressable key
14	DS1971, DS2430A	256 bit EEPROM and 64 bit PROM
1A	DS1963L	4 KB NV RAM + write cycle counter
1C	DS28E04-100	4 KB EEPROM + dual channel addressable key
1D	DS2423	4 KB NV RAM + external counter
1F	DS2409	Two-channel addressable key with the possibility of switching to the return bus
20	DS2450	Four-channel ADC
21	DS1921G, DS1921H, DS1921Z	Thermochronic sensor with data acquisition function
23	DS1973, DS2433	4 KB EEPROM
24	DS1904, DS2415	Real time clock
26	DS2438	Temperature sensor, ADC
27	DS2417	Real time clock with interrupt
29	DS2408	Bidirectional 8-bit I/O port
2C	DS2890	Single channel digital potentiometer
2D	DS1972, DS2431	1 KB EEPROM
30	DS2760	Temperature sensor, current sensor, ADC
37	DS1977	32 KB password protected EEPROM
3A	DS2413	Dual Channel Addressable Switch
41	DS1922L, DS1922T, DS1923, DS2422	High-resolution thermochronic and hygrochronous sensors with data acquisition
42	DS28EA00	Digital thermometer with programmable resolution, serial link capability and programmable I/O ports
43	DS28EC20	20 KB EEPROM

NV RAM - Non-Volatile Random-Access Memory (non-volatile RAM)
PROM - Programmable Read-Only Memory (once programmable ROM)
EEPROM - Electrically Erasable Programmable Random-Access Memory (Electrically Erasable Programmable ROM)

For one of the automation projects, it was necessary to make a device that is a slave 1-Wire device, receives commands from the master and sets an analog signal value in the range from 0 to 10V at its outputs.
After analyzing the line of standard 1-Wire microcircuits from Maxim, it became clear that there is no microcircuit that will allow such functionality to be implemented.
Therefore, it was decided to implement a 1-Wire slave on a microcontroller. I hope this material will be interesting and useful to people who make a "smart home" with their own hands, because. 1-Wire is a fairly popular bus in such projects. The MK Cortex M0 + ATSAMD20G16 from Atmel was chosen as a stone, but we will talk about the implementation in the code in the second part. Looking ahead a little, I will say that in the third part of the cycle we will talk about the implementation of our own family of devices for the OWFS (One Wire File System) Linux library. And today we will talk about some hardware solutions that we came up with in the development process.

This will mainly focus on how to connect the leg of the microcontroller to the 1-Wire bus with minimal harm to health. Let's move from simple to complex.

Level Conversion

The simplest option is a bidirectional transistor level converter. It will require somewhere to take 5V from the side of the 1-Wire bus.
The first option is to make 5V on your device (in addition to 3.3V) to "power" the bus. As a result, the complication of circuitry.
The second option is to run the 1-Wire bus in three wires. The third wire is the +5V power line. Of the problems - an extra wire, a voltage drop on a long wire.

Level matching

If you really don’t want to use + 5V, you can divide the signal line into 2 components (input and output)

It is important to consider that with such a scheme, the lines from the controller side are inverted.
As a bonus, dividing the data line into 2 parts allows you to somewhat simplify further software debugging, because. allows you to see the oscilloscope separately coming from us signals (line 1-Wire Tx) that are not mixed with other devices on the bus.

Building resilience

In order to make data reception over 1-Wire more confident, it is necessary to make steep pulse fronts from the microcontroller. To do this, we use a comparator from TI LMV331, which will provide a more accurate and sharp transition between logical "0" and "1", as well as a hysteresis of 160mV. We will also replace the output bipolar transistor BC547 with a field-effect IRLML6346 and put a protective TVS diode ESD5Z6 at 6V.

For this circuit, the comparator will need to be powered from 5V. Where can I get them was said above.

Decoupled 1-Wire

To ensure the electrical isolation of the 1-Wire bus and the internal electronics of the device, we will use an isolated level translator ADuM1201, and an isolated DC / DC converter TES 1-1211. As in the previous case, we divide the 1-Wire data line into 2 lines: 1W_Rx and 1W_Tx.

DC / DC converter from 12 to 5 volts is taken as an example, you can use the same 3.3 / 5.

The rest of the circuitry

To complete the picture, we will show the circuitry for connecting the microcontroller, as well as output analog channels 0-10V.

Because 1-Wire protocol requires a unique address for each device on the bus, we put 1-Wire UID from Maxim DS2411 on the board. Being the bus master for it, we will read its UID and use it as our own address. The DS2411 has a family code of 0x01 (family code is the high byte of the UID). On the OWFS website, we will select an unoccupied family code for our new device and will replace the first byte.

As already mentioned, in the second part we will proceed to the software implementation of the 1-Wire Slave protocol.

Tell me, the problem is the following, 4 DS18B20 temperature sensors are connected to the WB5 by 1 wire, they are not sealed, they work and are detected normally. I additionally connect your sealed sensor DS18B20 together with 4 me, the sealed sensor is not detected and does not display data. (connection directly to WB5) Separately, everything works, but together in no way.

Leaky sensors (GND-GND, 1W - DAT, +5V - VCC)
Sealed (GND - black, 1W - yellow, + 5V - red), the pinout on your site is not correctly indicated, the only way it works for me is one.

I just took two of the same sensors with a three-meter cable, additionally took an output DS18B20 without a cable, clamped everything into the Wiren Board terminal blocks, and everything worked together.
Actually, the fact that the sensor bought from us works alone, already most likely meant that the matter was not in it, but in the bus configuration. The main way to “fix” it is to check out the detailed 1-Wire bus organization guide: https://www.maximintegrated.com/en/app-notes/index.mvp/id/148 .
The case is definitely non-warranty, but together with you we can try to understand what is the matter here. Let's start with four questions:

I hope that all sensors are connected with three wires (that is, each is connected with a separate wire to 5V, none is powered by the data bus)?
What are the cable lengths to your sensors?
What kind of cables do they use? Could there be clues?
Does the configuration “our sensor + one of your sensors” work?

Can you analyze under what conditions a checksum error occurs? How often is it repeated? What sensors are included? Can you measure the voltage drop across the sensors? On the data bus with respect to ground and power (this is when everything is not working).

Distances of 30 cm - 1 for the 1-wire bus are generally invisible for any connection topology, if everything is in order.
Does the configuration “our sensor + one of your sensors” work?

in wirenboard-ABZ4PE4F logs user.warn kernel: [ 1484.461380] w1_slave_driver 28-0000073ba74b: Read failed CRC check. Voltage when everything is not working exactly 5.00

wirenboard-ABZ4PE4F user.info kernel: [1242.799168] w1_master_driver w1_bus_master1: w1_search: max_slave_cou
nt 64 reached, will continue next search. Also this

wirenboard-ABZ4PE4F user.info kernel: [1242.799168] w1_master_driver w1_bus_master1: w1_search: max_slave_count 64 reached, will continue next search. Also this

This usually means that you have zero potential on the 1-Wire line. Somewhere KZ.

Please write the identifiers of all sensors, ours and yours.

I looked at your link: you don’t actually have the DS18B20 sensor itself, but a module (scarf) on which there is also a resistor (as I understand it, this is a 4.7KΩ pull-up of the DATA line to VCC), and another capacitor (most likely between VCC and GND) .
If so, then four such modules give a total pull-up of 1.2KΩ. At the same time, there should be one pull-up on the line - in the master (Wiren Board controller), and it is already there - 3KΩ. The final pullup is 0.8KΩ, and our sensor on a three-meter cable cannot “pull” it.

Check which lines the components on the board are connected to. If everything is really as I said, then try to unsolder them on one of your modules, and try connecting this module together with our sensor.

The purpose of this article is to explain how to use these sensors (or other network devices) in harsh "field conditions". It's no secret that there is a bright digital sensor on the table under the lamp. DS18B20 or his budget brother DS18S20 works remarkably with minimal binding on the part of the microcontroller in the so-called. two-wire scheme:

An additional dedicated power line promises us the following "bonuses":

The length of the network cable is 100 meters or more;
The number of simultaneously connected sensors - at least 32 pieces;
ADC resolution - 0.0625°C and measurement accuracy - 1°C.

However, there is still a struggle with interference on long lines connections. The simplest protection is a Schottky diode connected in the opposite direction between the given line and the common wire, this is exactly what it advises to do. Brian C. Lane, author of the popular project DigiTemp. We will only slightly expand this solution for a three-wire connection:

L1, L2- ferbids BLM21AG221SN1D- inductance for protection against high-frequency interference that occurs when switching high-current consumers;

C1- a ceramic capacitor, a natural companion of the power supply legs of a digital microcircuit;

IC1- actual digital temperature sensor DS18B20Z in SOIC8 package.

All components are SMD (0805 and SOT23) to reduce the size of the sensor board:

After assembly, the temperature sensor board looks like this:

Necessarily protect the sensor board from moisture (zaponlak or acrylic varnish):

Self-vulcanizing rubber tape is very suitable for mounting the sensor on a surface, such as a pipeline. In addition, the sensor installation point must be well insulated. I use porous self-adhesive tape.

Contact pads for soldering 1-Wire network cable consciously made big and here's why...

Treatise on cable wiring

The most common mistake when building a 1-Wire network is choosing a Cat.5 Ethernet cable! The vast majority of readers will say - " everything works very well for us and cheerfully works on scraps of the network card". I do not argue in any way, a Cat.5 cable with a length of 10..30 m is quite suitable for 3 wire way to connect sensors, moreover - here is the recommended scheme for using a folk cable, which I myself use in the country for water supply at home:

"Well, what's the matter?" - the astute reader will say. But in what: in a cardinal difference"physics and logic" of Ethernet and 1-Wire networks. Without going into complexity of the organization Ethernet networks, just please believe (and with a multimeter about believe) that due to the significant voltage drop on the long and very thin wires of the Cat.5e cable, the 1-Wire network sensor is trite lackssupply voltage!

The article provides a detailed description of the integral temperature sensor DS18B20 in Russian. The information was translated into Russian from the official documentation of the sensor manufacturer, Dallas Semiconductor.

General description.

DS18B20 is a digital temperature meter with 9 to 12 digit conversion resolution and temperature monitoring alarm function. Control parameters can be set by the user and stored in the non-volatile memory of the sensor.

DS18B20 communicates with the microcontroller via a single-wire communication line using the 1-Wire interface protocol.

The temperature measurement range is -55 to +125 °C. For the range from -10 to +85 °C, the error does not exceed 0.5 °C.

Each DS18B20 chip has a unique 64-bit serial code that allows multiple sensors to be connected to one common communication line. Those. through one port of the microcontroller, it is possible to exchange data with several sensors distributed over a considerable distance. The mode is extremely convenient for use in environmental control systems, temperature monitoring in buildings, equipment nodes.

Briefly about the features of the DS18B20.

For a single-wire 1-Wire interface, one communication port with the controller is sufficient.
Each device has a unique 64-bit serial code.
Possibility to connect several sensors via one communication line.
No need for external components.
Ability to receive power directly from the communication line. Supply voltage within 3.0 V ... 5.5 V.
Temperature measuring range -55 ... +125 °C.
The error does not exceed 0.5 °C in the range -10 ... +85 °C.
Conversion resolution 9 ... 12 bits. Set by the user.
The measurement time does not exceed 750 ms, with the maximum possible resolution of 12 bits.
Possibility of programming alarm parameters.
The alarm signal transmits data about the address of the sensor whose temperature is out of the specified limits.
Software compatibility with DS1822.
Extremely wide areas of application.

Assignment of conclusions.

Overview of the DS18B20 sensor.

Figure 1 is a block diagram of the DS18B20 sensor. The 64-bit ROM stores the device's unique serial code. RAM contains:

measured temperature value (2 bytes);
upper and lower alarm thresholds (Th, Tl);
configuration register (1 byte).

Through the configuration register, you can set the conversion resolution of the temperature sensor. The resolution can be set to 9, 10, 11 or 12 bits. The configuration register and alarm thresholds are stored in non-volatile memory (EEPROM).

Mode - temperature measurement.

The main function of the DS18B20 is to convert the temperature of the sensor into a digital code. The conversion resolution is set to 9, 10, 11, or 12 bits. This corresponds to a resolution of 0.5 (1/2) °C, 0.25 (1/4) °C, 0.125 (1/8) °C and 0.0625 (1/16) °C. On power-up, the state of the configuration register is set to 12 bits of resolution.

After power up, the DS18B20 is in a low-power dormant state. To initiate a temperature measurement, the master (microcontroller) must issue a TEMPERATURE CONVERSION command. After the conversion is completed, the result of the temperature measurement will be in 2 bytes of the temperature register, and the sensor will again go to rest.

If the DS18B20 is externally powered, the master can monitor the status of the convert command. To do this, it must read the state of the line (perform a temporary read slot), upon completion of the command, the line will go into a high state. The line is held low while the convert command is being executed.

DS18B20 measures temperature in degrees Celsius. The measurement result is presented as a 16-bit, signed number in an additional code (Fig. 2.) . The sign bit (S) is 0 for positive numbers and 1 for negative numbers. With a resolution of 12 bits, the temperature register has all significant bits, i.e. have valid values. For a resolution of 11 bits, bit 0 is not defined. For a resolution of 10 bits, bits 0, 1 are not defined. With a resolution of 9 bits, bits 0, 1, and 2 have an invalid value. Table 2 shows examples of how digital codes correspond to a temperature value.

For people who are not experienced in binary mathematics, I will write that to calculate the temperature you need:

For a positive value (S=0), convert the code to decimal and multiply by 0.0625 °C.
With a negative value (S=1), you must first convert the two's complement code into a direct one. To do this, invert each digit of the binary code and add 1. And then convert to decimal and multiply by 0.0625 ° C.

Mode - transmission of an alarm signal.

After executing the temperature conversion command, the measured value is compared with the upper and lower thresholds from the Th, Tl registers (format in Figure 3). These are byte values, signed, in two's complement, S=0 means the number is positive, and S=1 means negative. Threshold values are stored in non-volatile memory (EEPROM). Th and Tl are available for reading and writing through bytes 2, 3 of RAM. More about this in the section.

Due to the different lengths of the TH, TL and temperature registers, they only compare against bits 11 to 4 of the temperature register. If the value of the measured temperature exceeds TH or is lower than TL, then an alarm symptom is generated in DS18B20. The attribute is overwritten with each temperature measurement, and if the temperature returns within the specified limits, it is reset.

The master can check the status of the alarm symptom using the SEARCH FOR ALARM command. Any sensor with an active flag will respond to the search command. In this way, the wizard will determine exactly which DS18B20 is generating the alarm. After changing the values of the TH and TL registers, only the next temperature conversion will generate a valid alarm indication.

Power supply for the DS18B20 temperature sensor.

However, when the DS18B20 performs a temperature conversion or memory copy to EEPROM operation, the current consumption may be as high as 1.5mA. Such a current can cause a decrease in the supply voltage of the device to an unacceptable value. The pull-up resistor current and the energy stored in Cpp is not enough to power these two modes. In order to ensure sufficient power to the device, it is necessary to provide a powerful pull-up of the bus to a high level at the time when the temperature conversion or memory data copying to EEPROM is in progress. This can be done with a MOSFET, as shown in the schematic (Figure 4). The data bus must be connected to a powerful power supply:

within 10 µs after the commands CONVERT and COPY MEMORY ;
during the conversion time (tconv) and data transfer (not less than t WR =10ms).

No other operations can be allowed on the bus during this time.

As a rule, for modern microcontrollers, the output current of a high level is quite enough to power the DS18B20. Then there is no need for a MOSFET.

To power the DS18B20, the usual method can be used - connecting an external power supply through the V DD pin (Figure 5). The obvious advantages of this method are that there is no need for a MOSFET and that the bus remains free during conversion and can be used for other purposes.

I, in such cases, use the following DS18B20 connection diagram.

In this circuit, the temperature sensor operates in the external power supply mode, which is stored on an additional capacitor through a diode. The circuit works fine in my devices.

The 64-bit serial code of the device.

sensor memory.

The organization of the DS18B20 memory is shown in Figure 7. All memory includes random access (SRAM) and non-volatile (EEPROM) memory. The EEPROM stores the TH, TL registers and the configuration register. If the alarm function is not used, the TH and TL registers can be used as general purpose registers. All memory management commands are described in detail in the section.

Bytes at addresses 0 and 1 store the low and high bytes of the measured temperature register. These bytes are read-only. 2nd and 3rd bytes - TH and TL registers. Byte 4 is the configuration register. More details about this register in the CONFIGURATION REGISTER section. Bytes 5, 6, 7 are reserved, cannot be written and, when read, always return 1.

Byte 8 is read-only. It contains the cyclic code (CRC) for the first eight bytes. DS18B20 generates this code according to the method described in part .

Data is written to bytes 2, 3 and 4 by the WRITE MEMORY command. Data must be transmitted starting with the least significant bit of byte 2. To check the data write, the memory can be read with the READ MEMORY command [code BEh]. When reading, data is transferred over the bus, in sequence starting from the least significant bit of byte 0. Data TH, TL and the configuration register are written to EEPROM by the COPY MEMORY command.

When the power is turned on, data from the non-volatile EEPROM memory is reloaded into random access memory (SRAM). Reloading data from EEPROM can also be done with the RELOAD E 2 command. The master must monitor the state of the bus to determine if the reboot is complete. A low level read slot means that the reboot has not finished yet. Upon completion of the reboot, the DS18B20 hands over read slot 1.

Temperature sensor configuration register.

Byte 4 of the memory is the configuration register (format in Figure 8). Bits R0, R1 can set the conversion resolution (codes in table 3). When the power is turned on, the state of bits R0, R1 = 11, which corresponds to a resolution of 12 bits. It must be remembered that there is a direct dependence of the conversion time on the resolution. Bits 7 and 0…4 are reserved, cannot be used, they return 1 when read.

Cyclic code generation(CRC)

The cyclic code (CRC) bytes are located in the 64-bit ROM code and in the ninth byte of SRAM. The cyclic code from ROM is calculated for 56 bits of the ROM code and is located in the high byte of the ROM. The cyclic code from SRAM is calculated from bytes 0…7 of SRAM. The cyclic code allows you to control the correctness of reading data from the DS18B20. The master calculates the cyclic code for the received data and compares it with the received code. Based on this, a decision is made about the correctness of the data.

The generating polynomial of the cyclic code looks like this:

C R C = X 8 + X 5 + X 4 + 1

The wizard can calculate the cyclic code using the polynomial generator, as shown in Figure 9. It consists of a shift register and XOR gates. The shift register is initially in state 0. Bits enter the shift register, starting with the least significant bit, code from ROM or from SRAM, one bit per shift cycle. After shifting the 56th bit of ROM or the high bit of the 7th byte of SRAM, the calculated cyclic code will be in the shift register. If you shift 8 bits of ROM or SRAM received from DS18B20 into the generator, then in case of correct data, the shift register will contain all 0.

Single-wire interface 1-Wire

A 1-Wire bus system consists of one master device (MASTER) that controls one or more slave devices (SLAVES). DS18B20 can only be slave. A system with one slave is called a single point. Multi-slave system - multipoint. All commands and exchange data are transmitted over the bus with the least significant bit first. Further information about the 1-Wire interface is divided into three sections: hardware configuration, workflow, and signals (types and timing requirements).

hardware configuration.

The 1-Wire interface has one communication line. Each device (master or slave) is connected to the data bus with an open collector or tri-state output port. This configuration allows each device in the system not to occupy the communication line when it is not active, and keep the bus free for other devices. In the DS18B20 chip, the output (DQ) is an open drain. Its equivalent circuit is shown in Figure 10. The 1-Wire bus requires an external pull-up resistor of approximately 5 kΩ to provide a high signal level when the devices are inactive. If an operation is to be suspended, the bus must be set to idle until the next operation. The bus can be in a high level state for an arbitrarily long time. Driving the bus low for more than 480 µs will cause all system components to reset.

Sequence of operations.

The sequence of operations for accessing the DS18B20 temperature sensor looks like this.

Initialization.
ROM command (required for any communication).
Function command (required for any communication).

This sequence must be strictly observed. Otherwise, the DS18B20 will not respond to commands. ROM SEARCH [code F0h] and TROUBLE SEARCH [code ECh] are exceptions. After generating these two commands, the master device must return to the first step (initialization).

Initialization.

Bus communication always starts with an INITIALIZE operation. For initialization, the master generates a reset pulse, followed by a presence pulse from the slave. The presence pulse informs the master that the slave is present in the system and is ready to perform an operation. The reset and presence pulse timings are described in section .

ROM code commands.

After the master device receives a presence pulse, it can operate on ROM commands. These are commands for operations on the 64-bit individual codes of each slave. They allow the master to select a particular slave from many others. Also, using these commands, you can find out how many slave devices are connected to the bus, their types, select devices in alarm. There are 5 ROM instructions, each 8 bits long. The master must send a ROM command before executing the DS18B20 function commands. The block diagram of the execution of ROM commands is shown in Figure 11.

Search ROM

After power up, the master device must read the ROM codes of all slave devices connected to the bus. This will determine the number of slave devices and their types. The master device learns the ROM codes through the process of identifying the codes of each device on the bus. It must execute the search ROM command as many times as necessary to identify all slaves. With only one slave in the system, it is easier to use the READ ROM command. After searching for the ROM, bus operations must start again with initialization.

Reading ROM

The command is used in single point systems with one slave. It allows the host device to read the 64-bit ROM code without using the SEARCH ROM command. Using the READ ROM command in a multidrop system will result in data conflicts between slaves.

ROM match

The ROM MATCH command, followed by a 64-bit ROM code, allows the master to address a particular slave. Only one slave whose code matches the transmitted code will respond to the function commands. Other slaves will be inactive until the next reset pulse.

Skip ROM

The command allows the master device to access all devices on the bus at the same time, without using ROM codes. For example, you can run a temperature conversion operation on all devices by executing the ROM SKIP followed by TEMPERATURE CONVERSION. A READ MEMORY command can only follow a ROM SKIP command with one slave connected to the link. This sequence of commands significantly saves the exchange time with the sensors. It is especially effective when using a single slave device in the system.

Alarm search

The command is identical to the SEARCH ROM command. It differs in that only slaves in the alarm state will respond to it. The command allows the slave to determine which temperature sensors are in alarm since the last temperature conversion. After each ALARM SEARCH, it is necessary to return to INITIALIZATION.

Function Command Group

After executing the ROM command to select the DS18B20 with the desired code, the master device can send sensor function commands. They allow you to write and read data from the DS18B20 RAM, initiate temperature conversion and determine the power mode. The functional commands of the DS18B20 are described below, collected in Table 4, the algorithm for working with them is shown in Figure 12.

Temperature conversion

Memory recording

The command allows loading 3 bytes into the sensor's RAM. The first byte is written to the Th register (memory byte 2), the second byte to Th (memory byte 3), and the third byte to the configuration register (byte 4). The master transmits data from the least significant bit. All three bytes must be written before the master generates a reset signal.

Memory reading

The command is used to read the device's memory. The data transfer starts from the least significant bit of byte 0 of memory, and continues until all 9 bytes have been read. If only a portion of the data is needed, the host can abort the transmission by issuing a reset pulse.

Memory copy

The command reloads the values of the Th, Tl registers and the configuration register from EEPROM to RAM. After sending the RESET command, the master can execute the read slot and the DS18B20 will report the reset status. Passing 0 will mean that the operation is still in progress, 1 - the operation is completed. The reset operation automatically occurs when the power is turned on. Therefore, the RAM contains valid data immediately after power is applied.

Read power mode

Table 4. DS18B20 function commands.

TEAM	DESCRIPTION	THE CODE	BUS OPERATIONS	NOTE
TEMPERATURE CONVERSION COMMAND
Temperature measurement	Initializes temperature measurement	44h	DS18B20 sends the temperature conversion operation status to the master	1
MEMORY COMMANDS
Memory reading	Reads all RAM, including cyclic CRC code	BEh	DS18B20 sends up to 9 bytes to master	2
Memory recording	Writes bytes 2, 3 and 4 to RAM (TH, TL and configuration register)	4Eh	The master sends 3 bytes to the DS18B20.	3
Memory copy	Copies TH, TL, and configuration register from RAM to EEPROM	48h		1
Reloads TH, TL, and configuration register from EEPROM to RAM.	B8h	DS18B20 sends reset status to master
Read power mode	Informs the master about the power mode of the DS18B20.	B4h	DS18B20 send power mode to master

Notes.

1-wire interface

The DS18B20 uses the 1-Wire interface protocol for data exchange, which provides data integrity control. This protocol defines signals:

reset pulse,
presence momentum,
writing a bit with a value of 0,
write bit with value 1,
read bit with value 0,
read bit with value 1.

All these signals, except for the presence pulse, are generated by the master.

Initialization - reset and presence pulses

Any communication operation of the DS18B20 begins with an initialization sequence that consists of a reset pulse from the master to the slave and a presence response pulse from the DS18B20. This process is shown in Figure 13. The temperature sensor sends a presence pulse in response to the reset pulse to tell the master that it is connected to the bus and ready for use.

During the initialization sequence, the master transmits a reset pulse (Tx), driving the bus low for at least 480 µs. Next, the master releases the bus and enters receive (Rx) mode. When the bus is released, it is pulled up to a high logic level by a 5 kΩ resistor. The sensor detects a positive edge, waits 15-60 µs and transmits a presence pulse, holding the line low for 60-240 µs.

Temporary read and write slots.

Data exchange on the 1-Wire bus occurs in time slots (time slots). One timeslot carries one bit of information.

Temporary recording slots.

The protocol defines two types of data write time slots in the DS18B20: write value 1 and write value 0. The write slot duration is at least 60 µs with a recovery pause between slots of 1.0 µs as a minimum. Any write slot is initiated by the falling edge of the bus signal (Figure 14).

To form write slot 1, after driving the bus low, the master must release the bus for 15 µs. The 5 kΩ pull-up resistor will create a high level voltage on the bus.

To form a write slot 0, after driving the bus low, the master must continue to hold the bus low for the duration of the slot (at least 60 µs).

The DS18B20 checks the signal status between 15 and 60 µs, counting from the start of the write slot. The state of the bus on this segment corresponds to the value of the bit to be written to the sensor.

Temporary read slots.

The duration of the read slot, as well as the write slot, must be at least 60 µs with a recovery pause between slots of 1 µs, at least. Any read slot is initiated by the falling edge of the bus signal (Figure 14).

After the host has initialized the read slot, the DS18B20 transmits a data bit. For a transmission of 1, the sensor leaves the bus free (in a high state), and for a transmission of 0, it forms a low level on the bus.

When transmitting 0, the DS18B20 must release the bus at the end of the slot. The pull-up resistor will form a high level on it. The output of the DS18B20 is valid for 15 µs from the start of the read slot.

On fig. 15 shows that the total sum of the Tinit , TRC and TSAMPLE read slot times must be no more than 15 µs.

Rice. 16 shows that for maximum reliability of data reception, it is necessary to reduce Tinit and TRC and read the bus state at the end of the 15 µs segment.

Example 1 of working with DS18B20.

MASTER MODE

BUS DATA

EXPLANATIONS

TX reset RX Presence TX 55h TX 64-bit ROM code TX 44h The master sends a temperature conversion command. TX TX reset The master generates a reset pulse. RX Presence DS18B20 respond with a presence pulse. TX 55h The master executes the ROM code matching command. TX 64-bit ROM code Master sends ROM code DS18B20. TX BEh RX 9 data bytes

Example 2 of working with DS18B20.

MASTER MODE	BUS DATA	EXPLANATIONS
TX	reset	The master generates a reset pulse.
RX	Presence
TX	CCh
TX	4Eh	The master executes a memory write command.
TX	9 bytes of data	The master sends three bytes (TH, TL, and the configuration register).
TX	reset	The master generates a reset pulse.
RX	Presence	The DS18B20 responds with a presence pulse.
TX	CCh	The master issues a skip ROM command.
TX	BEh	The master sends a read memory command.
RX	9 data bytes	The master reads all RAM, including the cyclic CRC code. It then calculates the CRC for the first eight bytes and compares it with the received code. If the codes are not equal, the master repeats the read operation.
TX	reset	The master generates a reset pulse.
RX	Presence	The DS18B20 responds with a presence pulse.
TX	CCh	The master issues a skip ROM command.
TX	48h	The master executes a memory copy command.
TX	DQ line connected to power rail	The master connects the DQ to the power rail for the duration of the conversion.

Maximum permissible parameters DS18B20

The limit values of the parameters are indicated. Exceeding these parameters is unacceptable. Operation for a long time at the limit values of the parameters may reduce the reliability of the device.

Notes:

AC EEPROM electrical data (- 55 ... + 125 °C, V DD = 3.0 ... 5.5 V).

PARAMETER	SYMBOL	CONDITIONS	MIN.	TYPE.	MAX.	ED. MEAS.
Write cycle time	twr			2	10	ms
Number of records	NEEWR	-55°C - +55°C	50000			cycle
Storage time	t EEDR	-55°C - +55°C	10			years

AC electrical data (- 55 … + 125 °C, V DD = 3.0 ... 5.5 V).

PARAMETER	SYMBOL	CONDITIONS	MIN.	TYPE.	MAX.	ED. MEAS.	PRIME CHANIE
Temperature conversion time	tCONV	resolution 9 bit			93.75	ms	1
		permission 10 bit			187.5	ms	1
		permission 11 bit			375	ms	1
		permission 12 bit			750	ms	1
Power connection time	t SPON	Sending a temperature conversion command			10	ms
Slot time	tSLOT		60		120	ms	1
Recovery time	tREC		1			ms	1
Recording time 0	r LOW0		60		120	ms	1
Recording time 1	tLOW1		1		15	ms	1
Data reading time	tRDV				15	ms	1
Reset high time	t RSTH		480			ms	1
Reset low time	t RSTL		480			ms	1,2
High Presence Time	tPDHIGH		15		60	ms	1
Low Presence Time	t PDLOW		60		240	ms	1
Capacity	C IN/OUT				25	pkf

Notes:

Figure 18. Timing diagrams.

The description is great. Sensors are not easy to work with. They require quite complex software functions, but from a hardware point of view, the DS18B20 is easy to connect, measure accurately, do not require an ADC, etc.

As an example of using DS18B20 temperature sensors, I can cite my development -. Two temperature sensors are used. One measures the air temperature in, the second - the temperature of the radiator.

Category: . You can bookmark.

Categories

Popular