1 of 1 people found this helpful
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 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.
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?
This message was posted on behalf of Intel Corporation1 of 1 people found this helpful
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.
You mean i need the PIC12F629 to operate the sensor. Is that right?
So i will have bread board to fit the PIC12F629.
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.
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.
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...