Community
cancel
Showing results for 
Search instead for 
Did you mean: 
JSEO8
Beginner
1,768 Views

How to use DHT22 (temperature&humidity sensor) with IO Expansion sheild V7.1

Jump to solution

Hi, there.

I am working with Edison to measure temperature and humidity, DHT22.

I read other posts but i didn't understand how to use. I confirmed I can't use I2C communication( ).

I search information and got C code. I correct the code.(http://www.i-programmer.info/programming/hardware/9200-exploring-edison-bit-banging-the-dht11dht22-.... Exploring Edison - Bit Banging the DHT11/DHT22 )

# include "mraa.h" 

# include  # include   uint getByte(int,int[]);

 

int main() {  const struct sched_param priority={1};  sched_setscheduler(0,SCHED_FIFO,&priority);  mraa_gpio_context pin = mraa_gpio_init(2);  mraa_gpio_use_mmaped(pin,1);  mraa_gpio_dir(pin, MRAA_GPIO_OUT_HIGH);    mraa_gpio_write(pin, 0);  usleep(1000);  mraa_gpio_dir(pin, MRAA_GPIO_IN);

int buf[40]; 

 

int i, j;

 

for(j=0;j<40;j++){<p>  for(i=1;i<200;i++){<p>  if(mraa_gpio_read(pin)==1)break;

 

};

 

for(i=1;i<200;i++){<p>  if(mraa_gpio_read(pin)==0)break;

 

}

 

buf[j]=0;

 

if(i>75)buf[j]=1;

 

}

 

  for(j=0;j<=40;j++){<p>  printf("%d %d \n",j,buf[j]);  }   int byte1=getByte(1,buf);  int byte2=getByte(2,buf);  int byte3=getByte(3,buf);  int byte4=getByte(4,buf);  int byte5=getByte(5,buf);   printf("Checksum %d %d \n",byte5,  (byte1+byte2+byte3+byte4) & 0xFF);    float humidity= (float) (byte1<<8 |byte2)/10.0;<p>  printf("Humidity= %f \n",humidity);    float temperature;  int neg=byte3&0x80;  byte3=byte3&0x7F;  temperature= (float) (byte3<<8 |byte4)/10.0;<p>  if(neg>0)temperature=-temperature;  printf("Temperature= %f \n",temperature);   return MRAA_SUCCESS; }  uint getByte(int b,int buf[]){  int i;  uint result=0;  b=(b-1)*8+1;  for(i=b;i<=b+7;i++){<p>  result<<=1;<p>  result |= buf[i];  }  return result; }

However, I didn't get the useful result. all bits are 1.

Maybe, I need to configure Linux environment such as pin mode. Otherwise, controlling timing to receive 40bits data.

Is there anyone who used the sensor with edison?

If My thought is wrong, Please give me advice.

Thanks.

0 Kudos
1 Solution
KMill10
Valued Contributor II
167 Views

This question comes up a lot.

The basic problem you are facing is that you are trying to interface a real-time device to a non-real-time operating system.

Edison is not like a micro-controller which has deterministic timing of the GPIO, the timing of the GPIO on Edison is totally non-deterministic.

In other words, you cannot determine how long it will take to do any particular bit-banged GPIO operation, and therefore you shouldn't use bit-banged GPIO to interface to devices on Edison.

Edison is a computer, not a micro-controller, not a microprocessor. It runs an operating system, and that operating system can slice and interrupt your code at (almost) any point. Any talk of converting microseconds to clock cycles is meaningless on a system with a multi-tasking operating system.

Think of how you would interface a DHT22 to a desktop PC - you certainly could not use bit-banged GPIO there. It's the same with Edison - for 100% deterministic, and therefore reliable, communications with real-time devices you need a dedicated interface.

Now, edison does have some dedicated, realtime interfaces such as SPI, I2C, USB and UART - all of which require deterministic timing, but none of which are suitable for interfacing to a DHT22.

The best solution is probably to build a small UART-to-DHT22 interface and talk to that via UART. You can see an example of just that being done /thread/55975 here on galileo. However that interface would require some careful consideration of the Edison's 1.8V GPIO levels.

Of course, you may get acceptable, if not 100% reliable, results using bit-banged GPIO but the code would certainly not be portable as the timing will vary significantly from one system to another, depending on what other software was running on said system.

View solution in original post

8 Replies
KMill10
Valued Contributor II
168 Views

This question comes up a lot.

The basic problem you are facing is that you are trying to interface a real-time device to a non-real-time operating system.

Edison is not like a micro-controller which has deterministic timing of the GPIO, the timing of the GPIO on Edison is totally non-deterministic.

In other words, you cannot determine how long it will take to do any particular bit-banged GPIO operation, and therefore you shouldn't use bit-banged GPIO to interface to devices on Edison.

Edison is a computer, not a micro-controller, not a microprocessor. It runs an operating system, and that operating system can slice and interrupt your code at (almost) any point. Any talk of converting microseconds to clock cycles is meaningless on a system with a multi-tasking operating system.

Think of how you would interface a DHT22 to a desktop PC - you certainly could not use bit-banged GPIO there. It's the same with Edison - for 100% deterministic, and therefore reliable, communications with real-time devices you need a dedicated interface.

Now, edison does have some dedicated, realtime interfaces such as SPI, I2C, USB and UART - all of which require deterministic timing, but none of which are suitable for interfacing to a DHT22.

The best solution is probably to build a small UART-to-DHT22 interface and talk to that via UART. You can see an example of just that being done /thread/55975 here on galileo. However that interface would require some careful consideration of the Edison's 1.8V GPIO levels.

Of course, you may get acceptable, if not 100% reliable, results using bit-banged GPIO but the code would certainly not be portable as the timing will vary significantly from one system to another, depending on what other software was running on said system.

View solution in original post

JSEO8
Beginner
167 Views

Thanks for your good advice about my question.

Now we are considering for buying UART, but we rarely have information about UART.

We need your help again for buying UART. Can you recommend a device which is for DHT22 measuring using by Edison?

I know you really explained well, but if you have other option for solving this problem, Can you tell me about it?

idata
Community Manager
167 Views

Hi Jinyeol,

 

 

What do you mean when you mention that you're considering buying UART? As I can see from Spider's post on his other thread, you'll just need the PIC12F629 for the conversion (following his schematic that is). You then communicate with the Edison once the data has been converted.

 

 

Regards,

 

Pablo M.
JSEO8
Beginner
167 Views

Thank you

You mean i need the PIC12F629 to operate the sensor. Is that right?

So i will have bread board to fit the PIC12F629.

idata
Community Manager
167 Views

Hi Jinyeol,

 

 

Yes, that is correct. You should mount Spider's circuit (I guess that's the one you'll be using) in a breadboard.

 

 

Regards,

 

Pablo M.
YLiu57
Novice
167 Views

Hi SpiderKenny ,

hope you are still active online. I recently need to read DHT11 sensor data in a project, your explanations in several threads do solve my confusion that why reading with MRAA has a very high likelihood to fail. Your solution of adding a PIC interface is an alternative, but I wonder if it's possible to read the data with the embedded MCU in Edison board? Since it's an independent MCU, it should have accurate timings. I have not tried to use it to fetch data, but one problem could be, that both MCU and CPU can access pins, so it's programmer's duty to manage the pin's direction and make sure they are consistent. When I implement the simple blink led sample, even though the program in MCU is already running, the LED doesn't blink until I set the GPIO to output under LINUX. This poses a challenge to dealing with DHT sensor since we need to change the pin direction in a very short time and it's almost impossible to change it at the same time in LINUX.

Do you have experiences on this? Thank you in advance.

/Yu

KMill10
Valued Contributor II
167 Views

Hi hitworld yes - I am still here, although not so active in the Edison forum while I frantically try to re-build my devices for a new controller now that Edison has gone end-of-life.

I think you will get better performance using the embedded MCU, and indeed the GPIO should be much more deterministic. I think you should be able to get reliable readings from the DHT11 using the MCU, but I don't have much experience in using the MCU.

YLiu57
Novice
167 Views

Thank you for your very quick reply, even earlier than I re-edit my question. As I mentioned in the modified question, it seems not possible to handle the GPIO directions at the same time at both MCU level and CPU level...

Reply