A simple digital thermometer / hygrometer on AM2302 (DHT22), ATtiny13 and MAX7219

The AM2302 (DHT22) digital temperature and humidity sensor is quite popular in the DIY segment, since at low cost (if you look at replicas made in China), it provides good measurement accuracy and is very simple to connect (three wires, including power). However, most of the examples of using this sensor are designed for Arduino and written in the C / C ++ programming language. This is perfect if you want to familiarize yourself with the functionality of the sensor or “quickly” screw the thermometer to an existing device. But if you want to assemble the thermometer / hygrometer and only it, the use of the whole Arduino board (or just a large MK with a couple of dozen of conclusions) may well seem superfluous.

This article will discuss a simple thermometer / hygrometer (hereinafter - just a thermometer), performed on one of the “smallest” microcontrollers - ATtiny13 with very modest characteristics - 1Kb of program memory, 64 bytes of RAM and 5th (6th if disable reset pin) interface pins. The article assumes that the reader is already a little familiar with AVR microcontrollers and their programming, but the article is mainly aimed at beginners in this field. By the way, about the programming language - the thermometer program is completely written in assembler.

So, let's begin. To display information on temperature and humidity, an 8-bit 7-segment LED indicator was selected, allowing you to display both parameters at once without having to switch between them. This indicator has 16 pins (8 segments + 8 digits), which is clearly “beyond the power” of the small ATtiny13 controller. Fortunately, Maxim manufactures the MAX7219 chip, specially designed for such cases - inside the chip contains all the functionality of the dynamic display for 8 bits plus a serial interface compatible with SPI. Thus, with this microcircuit, all of our indicator can be connected to an MK with just three wires (not counting ground and power). This is quite suitable for a controller with 5 interface outputs. By the way, the cost of one set of indicator, chip and PCB assembly was only $ 1.3 on aliexpress.
')
As mentioned above, AM2302 is used as a temperature and humidity sensor. It connects to the MK using only one wire. Thus, from the available 5 interface outputs of the MK, only 4 are used, and for the remaining 5th one can “hang” any additional function. Also, if you have an HVSP programmer available, you can disable the reset pin and use it as the 6th interface pin, but this will make the MK firmware update a bit difficult.

So, the whole scheme of the thermometer is shown in the figure below:


Since all interfaces for working with external devices of the MK are implemented programmatically, the choice of conclusions (pins) to which this or that signal is connected is purely arbitrary and made, most likely, according to the principle “where it was more convenient to insert this wiring on the breadboard”. So you can safely choose other conclusions, it will be necessary only to correct their number in the code. The only restriction - you should not connect the temperature sensor to one of the conclusions used for programming the MK via SPI - this can create a conflict, because the outputs of the two devices will be connected together, which is unacceptable from an electrical point of view.

Now that everything is clear with the connection of the sensor and the indicator, let's start writing the code directly. And here we are waiting for a new “challenge” - ATtiny13 does not have any serial interfaces on board, i.e. all their logic will have to be implemented programmatically. Fortunately, the implementation of the SPI for the MAX7219 is not difficult, since the synchronous protocol, the microcircuit operates at a frequency of up to 10 MHz, and the interface in our circuit works only for output. But communication with AM2302 will be a more difficult task, because it is connected only by one wire, the data on which are transmitted in both directions and the transmission speed is completely determined by the sensor itself. It should be said that most libraries for working with AM2302 follow a “simple path” - they prohibit interruptions and read all information from the sensor with a single function call. This is a simple and reliable solution, but it is hardly suitable if any other real-time functions are assigned to the MC (for example, dynamic display or continuous analysis of data from other sources), because the whole cycle of reading information about temperature and humidity takes from 4 up to 6 milliseconds (depending on the transmitted data). Despite the fact that there are no other real-time functions in this thermometer, it was decided to write a universal code that would read the information from the sensor “in the background”, i.e. on interrupts.

For maximum simplification of the circuit, the ATtiny13 is clocked from the built-in RC generator, issuing about 9.6 MHz. This allows, by causing an interrupt every 128 processor cycles, to obtain a sampling rate of AM2302 75KHz or 13.33 microseconds between adjacent polls. According to the AM2302 specification, the minimum pulse duration at its output is 26 microseconds, which is almost twice the polling interval and ensures stable data reading. Of course, 128 clocks between two interrupts are not very much to implement the polling algorithm, but AVR performs most of the commands per 1 clock, so it is quite possible to write a working program under such conditions, and there will be time to execute the main program.

AM2302 according to the specification can be interrogated no more than once every two seconds. However, practice shows that he is quite capable of giving the result, and more often - up to several times per second, provided that after power is turned on he will be given 1-2 seconds (according to the specification - 2) for initialization. In this thermometer, the sensor is polled once per second, but the polling interval is easily changed to any other value.

Unfortunately, AM2302 (perhaps its Chinese origin has an effect) has a rather large error of the result - two consecutive temperature queries can return a difference of 0.5 or even more degrees, so it was decided to programmatically average the data of the last 8 measurements so that the thermometer readings do not jump .

Now let's go directly to the code. The original asm and the resulting hex-file is located in the appendix at the end of the article, here I will explain the main points. It will be convenient to open the source code of the program in another window and look there while reading the article.

At the beginning of the program are two important definitions:

#define SKIPNEXT1W (PC + 2) #define DS(var) Y + var - _dataStart 

The first allows conditional transition through the next 16bit command (1 word, most AVR commands), i.e. skip it without introducing an additional label, for example:

  inc R16 cpi R16, 5 brne SKIPNEXT1W dec R16 ... 

The second allows you to access the first 64th bytes of RAM MK using 16-bit commands. Here I will tell you in more detail - usually to read or write to the RAM of the MK, the lds / sts commands are used, which take 2 words (32 bits) and are executed in 2 cycles. They allow you to address up to 64Kb (without extensions) of RAM. Unfortunately, the size of 32 bits (4 bytes) is already quite a lot for MKs with only 1KB of program memory. Therefore, to save program memory, the start address of the RAM (0x60 for ATtiny13) is placed in the Y register of the MK at startup, this register does not change any more, and access to the first 64 bytes of RAM is performed using indirect addressing with an offset in the Y register , eg:

  ldd R16, Y + 6 

The ldd / std commands are also executed in 2 clock cycles, but only occupy 16 bits (2 bytes), i.e. compared to the lds / sts commands, this type of addressing saves half the amount of program memory. In order not to calculate the offset of any variable manually in each command, at the very beginning of the data segment the mark _dataStart is put:

 .dseg _dataStart: ... testVar: .byte 1 

And the command uses the DS macro (short for Data Segment):

  ldd R16, DS (testVar) 

The compiler converts this to a string:

  ldd R16, Y + testVar - _dataStart 

Automatically calculating the desired offset. It should be noted that this type of addressing is limited by the capabilities of the ldd command itself, and these are the first 64 bytes relative to the base register. But, in the case of ATtiny13, which has just 64 bytes of RAM on board, it allows you to address all the memory. However, in other MCs with a larger amount of RAM, it is also possible to apply this method by placing the most frequently addressed variables in the first 64 bytes of the data segment. The price paid for this type of addressing is the Y register (two 8-bit registers R28 and R29), the value of which cannot be changed at any point of the program.

Further, the program determines the number of bits of port B (namely, the bits inside the byte, not the physical outputs of the chip) to which external devices are connected. Since all protocols of interaction with software devices are software, the bit numbers can be changed without any restrictions.

A special feature of AVR MK is that the first 16 registers R0 - R15 are “inferior”, commands that contain an operand - for example, ldi or subi - do not work with them. Those. to even load a value other than 0 into one of these registers, you must use an additional register:

  ldi R16, 32 mov R0, R16 

Therefore, such registers are often used as “fast access variables”. To do this, the compiler has a .def directive that allows you to assign an additional symbolic name to the register, for example:

 .def R_TS = R0 

In the thermometer program, the R0 register always stores the data receiver AM2302, the R1 register is used to calculate the signal reception time, R2 contains the received data, R3 is used as a counter of the timer, increasing with a frequency of 100 Hz, and R4 and R5 are counted as 75 KHz timer counting from 749 to 0.

The MK data segment is divided into 4 parts - a block of data received from AM2302 (5 bytes), a buffer for decimal printing of numbers (4 bytes), a buffer for averaging the readings of the thermometer and hygrometer by 8 values ​​(8 * 2 * 2 = 32 bytes) and stack MK (all remaining memory is separated to it, ie 23 bytes). In fact, of course, the stack takes up less, and in memory you can still find a few bytes for additional functions, but you should not get carried away.

Now let's go directly to the code segment. It traditionally begins with the interrupt table, for ATtiny13 it is 10 vectors, including the reset vector. Unused interrupts immediately contain the reti command, used (and there are two of them) - the transition command to the handler. The thermometer uses two interrupts serviced by one handler — this is the timer overflow interrupt and the timer equality interrupt with the OCRA value. It would be possible to do with one, but this method is 2 commands shorter (it is not necessary to change the timer operation mode from normal to ITS).

Immediately after the interrupt vectors, there is a table of translation of numbers into codes for ignition of 7-segment indicators. The decoding function built into MAX7219 could be used, but then it would be more difficult to display string messages on the indicator.
After the table, the program of the thermometer initialization begins, which is executed immediately after the reset of the MC It performs the initial installation of the MK stack pointer, the watchdog watchdog timer (set to 4 seconds), the entry of initial values ​​into the MK registers, as well as the initialization of I / O ports, MAX7219 and the main timer MK. After that, the program waits 2 seconds while AM2302 is initialized (demonstrating a simple animation of the dying minus signs on the display) and goes into its main loop.

The main loop begins with the initiation of a request to AM2302 by changing the state of the data receiver in the R_TS (R0) register. The closest timer interrupt will detect a change in state and begin a sensor polling cycle. Upon its completion, the value of TMS_NONE will be placed in the status bits of the R_TS register, and until this point, the main program can perform any actions. In this case, there is nothing to do, so the program simply puts the MK into sleep mode (sleep) and waits for the end of the polling cycle.

After polling is completed, bit 3 of the status register determines whether the data was received successfully (value 1) or an error occurred (value 0). In case of successful data acquisition, the program checks their checksum and, if necessary, transfers control to the error handler. The error handler counts the number of errors in a row, and as soon as this value becomes three, it displays the message “Sn Error”, indicating a sensor or connecting line malfunction. As soon as temperature and humidity data is received successfully, the error counter is reset. Such a mechanism allows ignoring single sensor errors that occur from time to time in real life.

In case of successful data acquisition, previous measurements in the data averaging buffer are shifted up, and new data is added to its beginning. In parallel, average values ​​are calculated, which will be shown on the display. It should be noted here that AM2302 produces a negative temperature not in the additional code, which is customary for processing by processors, but as an absolute value of temperature and a separate bit of its sign. In order to add such numbers and calculate their average values ​​using ordinary MK commands, the data must be translated into an additional code.

Since the initial averaging buffer is not initialized, the average values ​​of temperature and humidity are displayed only after eight successful measurements. Up to this point, the display shows the current values. In practice, this means that in the first 8 seconds after turning on the thermometer, the values ​​of temperature and humidity can jump within a degree, after which the readings stabilize. It should be said that the averaging of the last 8 values ​​has a very beneficial effect on the thermometer readings - now they mostly change by no more than 0.1 degrees per second.

The temperature is displayed in the “x.x”, “xx.x”, “xxxx.x”, “- x.x” or “-xxx” format, depending on its value. Humidity is displayed in the format "x.x" or "xx.x." To convert a binary number in the X register to decimal form (in accordance with the codes for the 7-segment indicator), use the printDecX function. Since the MC does not have a division command, the function is based on the successive subtraction from the original number of values ​​1000, 100 and 10. The maximum number that the function can output is 9999, if when it is called in the X register there is a greater number, the function will return an overflow error by setting the flag transfer.

To work with MAX7219, the maxWriteWord function is used, which writes the value from the XL register MK to the MAX register, the number of which is specified in the XH register. After displaying the values ​​of the current temperature and humidity on the display, the program makes a delay of 1 second and repeats the main loop again. To implement the delay, the function wait100Hz is used, which performs a delay for the time R16 * 0.01c using the counter R_TICK100, which is increased by interrupting the timer.

Data retrieval from the temperature sensor is performed using the function am2302proc, which is called from the timer interrupt handler. The function is a finite state machine whose state is stored in the R_TS (R0) MC register. Depending on the state, the function waits for a certain signal level from the sensor, initiating the transmission and consistently receiving all 40 bits of the transmitted information. Synchronization occurs at every change in the input signal level, so special accuracy from the timer interrupt frequency is not required (which allows the MC to work from the built-in generator). The function consists of a fast idle state handler (TMS_NONE), which allows minimizing the load on the MK processor when there is no communication with the sensor, a timeout handler designed to reset the machine to its original state, if the expected signal does not come for a long time (about 3 ms), and handlers for each individual state of the machine. It should be noted that this function does not have noise immunity - even if the impulse noise will change the level of the data line for a short period of time, but it is he who gets into the read operation from the port, the function will read the incorrect data. To compensate for this, the main program checks the checksum of the read data, so the display of incorrect information is almost impossible. However, such an implementation may not be the best if you want to take the sensor out of the thermometer and connect it to the MC with a long connecting line.

At the moment, the thermometer is assembled on a breadboard and looks like this:



In the future, it is planned to place the thermometer inside the case of the existing electronic clock, organizing its power supply from the power supply of the clock.

The current program takes about 75% of the program memory of the MK. What can I add to the program? It may be useful for someone to change the brightness of the display (this is implemented directly in the driver MAX7219) by the external button or the light sensor (using the built-in ADC in the MC and free interface output), it may be useful for someone to memorize and display the minimum and maximum temperature. For small improvements the place is still there. Larger improvements may require changing the MC to another, having on board more software and RAM. As for the interface pins - at the moment, the MC has one completely unused output and one more can be obtained by turning off the RESET. Also two pins from the SPI interface (DATA and CLK) can be used for other functions, since until the CS pin is low (specifically for MAX7219 the transition from low level to high is important) the signals at these pins do not matter. That is, in principle, replacing the MK with a more powerful one, for example, ATtiny85, can be connected to a Real Time Clock (RTC) thermometer and up to four buttons.

My goal was to create a simple thermometer / hygrometer, so, most likely, I will keep it for myself in this form.