Lecture 8

Uli Raich

UCC semester 2017/2018

programmed as output pin or how we can read its state

through another GPIO pin, programmed as input pin.

Can one do more with a single pin?

• initiate a measurement
• read humidity and temperature data
• make sure the data are correct?

DHT11 data sheet

Most of the following information is just a copy from the data sheet.

• Variations in relative humidity produce changes variations
  of resistivity,which is measured.
• The resistance of certain hygroscopic materials such as
  hygroscopic salts have such a property
• These materials are mounted as thin films on
  the substrate with metal contacts
• The devices can be very small

and send them to the end user through a serial protocol,

a preprogrammed micro-controller must be implemented on the chip.

In the case of the DHT11 this is an 8 bit micro-controller,

which does the conversion into binary and which creates the serial protocol

can be directly connected to the cobbler 3.3V (or the 5V) line

• Program the GPIO pin onto which we connected our DHT11 as output
• We must pull this line done (send a login level zero) and
  keep it low for a minimum of 18 ms
• We must pull it high again and wait for another 20-40 μs
• Finally we must re-program the pin as input and wait for the DHT11 to respond.

Let's start slowly:

• Initiating a measurement seems do-able
• Why not just read the data from the device every 5 µs
  and print out the information?

all these details. He wants functions to

• Initialize the device
• Start a measurement
• Make sure the checksum is ok
• Read temperature and humidity values
• Maybe know when the measurement was made

• an include file (dht11.h)
• and implementation file (dht11.c)

• dht11Init simply calls wiringPiSetup()
• dht11Measurement
• Programs the gpio pin as output and sends the start sequence
• Switches back the gpio pin to input and reads the data coming from the dht11 every 5 µs and saves the data into an array
• Analyses the data and extracts temperature, humidity and the checksum
• Calculates the checksum and compares it with the one coming from the device
• If checksums are ok, sends the data to “validData”
• Keeps the time stamp of the measurement

• dht11GetValidTemperature()
• dht11GetValidHumidity()
• dht11getValidMeasTime()
• dht11getChecksum()
• dht11getDeviceChecksum()

You can print these data and have a look at them with gnuplot. Try analyzing be hand.

routine reading a single bit, which is called 40 times for all the 40 bits in the data.

Please note one nasty problem:
Linux is a multi-tasking system and permanently receives interrupts.

While these interrupts are treated the DHT11 data are continuing to flow

but are not taking into account, leading to corrupt data.

Since the duration of the protocol takes ~ 4 ms the probability is non negligible

and the checksum test in obligatory to make sure the data are consistent.

In case of a checksum error you must repeat the measurement

and the library in /opt/ucc/lib.

These are non-standard directories and must be declared in the Makefile

-I /opt/ucc/include for the include file in CFLAGS

-L /opt/ucc/lib for the library path

Since the shared library is loaded separately when running the

main program, it must be found by the system:

export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/opt/ucc/lib

documentation is of utmost importance

Of course the function prototypes in the include file give

some indication but this normally not enough.

I use the doxygen in code documentation system which allows to

generate documentation from the source layout and

comments in the code with special tags.

It creates html of latex doc