Project Logs

Collapse

• Interfacing a DHT22 (AM2302) temperature and humidity sensor

  Ken Yap • 07/22/2025 at 11:21 • 0 comments

  There are a few spare I/O lines on the STC89C52 board and looking at my small collection of sensors, I formed the idea to interface a DHT22 sensor, also known as an AM2302, for temperature and humidity and display them on request.

  Electrically this sensor is easy to wire up. It only requires 3.3 V to 5 V power and one data line. A one-wire protocol is used to read it. However this uses a custom one-wire protocol and not any of the ones supported by MCU hardware. Probably because the maker wanted to avoid paying licensing fees. The datasheet has all the needed details. 40 bits of data (16 each for humidity and temperature, plus 8 bits of checksum) are sent by the sensor serially. 0 is represented by high for 26-28 µs while 1 is represented by high for 70 µs. The relative humidity is multiplied by 10 and sent as an unsigned 16-bit integer, while the temperature is multiplied by 10 and sent as a sign bit followed by an unsigned 15-bit integer. For example, 765 represents a RH of 76.5%, while 234 represents a temperature of 23.4 C. For my use case I ignore negative temperatures. The checksum is the sum of the previous 4 unsigned bytes truncated to 8 bits.

  The tricky operation is how to measure the high times of the 40 bits. This is a time-critical part of the code as the sensor will not wait. The decoding can be done afterwards. For this I thought I could enlist Timer 2 in the 8052 architecture. This can be configured as a counter incrementing at the rate of crystal frequency ÷ 12. With a 12 MHz crystal, this means one count per µs. We also need to detect a non-responsive sensor so that the clock doesn't freeze waiting for a data line that won't change. We can use the overflow flag of the timer for this; 16 bits gives up to 65 ms to complete the read. So my first attempt was something like this:

  start timer at 0
  for i from 0 to 39 
          wait for high or overflow
          start_time = timer 
          wait for low or overflow
          end_time = timer 
          duration[i] = end_time - start_time
  stop timer
  

  On overflow, the loop terminates prematurely and the function signals a failed read.

  First I coded synthetic test data to test the decoding routine that could be enabled by setting a #define. This showed that my decoding was correct.

  Next I wired up the sensor to my development board, described in #Adventures with a STC89C52 development board , as depicted in the photo.

  Unfortunately in testing I often got overflow timeouts and even when I didn't the data didn't pass the checksum validation.

  Eventually I realised that this MCU wasn't fast enough. Most instructions take 1 µs and some take 2 µs. This means precious few instructions can be completed in the core of the loop. This included reading the 16-bit counter with two 8-bit reads and also taking care of the carry race condition.

  I could configure this MCU to 6T mode instead of normal 12T mode, meaning that instructions run twice as fast. But there is no scaler for the clock so it would also overflow twice as fast.

  I decided to ditch the timer for duration measurement, but retain it for timeout detection. Instead in the heart of the loop I did the simplest thing possible: increment a counter. So the value of the counter would not represent µs but some fraction of it. Hopefully there would be enough difference in count between a 0 and a 1 bit. They turned out to be around 2-3 and 8 respectively. So in the decoding I used a threshold of 5. Here's the loop in question.

  for (uchar i = 0; i < 40; i++) {
          while (!TF2 && !DHT22D) // wait for 1
                  ;       
          uchar count = 0;
          while (!TF2 && DHT22D)  // wait for 0
                  count++;
          hightime[i] = count;
          if (TF2) {      // timed out, didn't collect bits
                  TR2 = 0;// turn off T2
                  TF2 = 0;// clear overflow
                  DHT22H; // pull up 
                  return i + 1;
          }       
  } 

  With this change I could reliably read the sensor. But the code is working at the limit of this MCU's power. A more modern and faster MCU would break no sweat. For sure the Atmega 328P in the...

  Read more »

• Refactoring the code for multiple MCU targets

  Ken Yap • 01/25/2024 at 09:47 • 0 comments

  As mentioned in #Adventures with a STC89C52 development board  I bought that development kit because it could accept some AVR MCUs that are almost pin-compatible with the STC89C52. This got me thinking of how I could use the couple of ancient AVR chips that I have. Ideally I would like to reuse firmware that I have written and not have to develop from scratch. So as an exercise in learning more about AVR architecture, I decided to see if I could modify the STC89C52 code so that it could be compiled for more than one type of MCU.

  My requirements are:

  • Make it possible to select MCU type with a #define.
  • Restrict the MCU specific code to as few files as possible. This means that lots of #ifdefs in the main functions of the code are not acceptable.
  • Share the rest of the files unmodified. It's ok for these files to contain macro invocations that expand differently depending on the target.

  I went in and hacked at it until I had something acceptable. I was lucky in some respects:

  • The STC89 and AT90S families are similar in that 4 8-bit GPIO ports are exposed. They both also have two timers. If the families had been more disparate, it would have been a harder job.
  • Both avr-gcc and SDCC accept a fairly comprehensive set of C language features, and the differences are easy to use macros to hide.
  • The business logic (which is for a clock) is quite independent of the MCU architecture so large chunks of code contain no hardware specific manipulation.
  • The hardware specific parts of the code only have to deal with GPIO ports, timers, and interrupt handlers. A more complex MCU application might have more MCU specific code.

  Some constants, like those used for time constants for the button UI can be defined in common include files. Other constants, such as the values loaded into MCU registers, are in MCU specific include files.

  The overhead is very acceptable, only increasing the binary size by tens of bytes due to some inline code being turned into functions.

  I noted that for avr-gcc it's ok for static functions to be defined in .h files because avr-gcc is smart enough to not emit code for the body if the function is not used later in the .c file. In SDCC the functions need to be in a .c file and global rather than static otherwise if in a .h file there will be a copy for every .c file it's included in.

  The changes have been pushed to the Github archive.

View all 2 project logs