Oh, my.....I just realized I expected the Galileo too much and I found the webpage too late......
DHT sensor cannot work with Galileo.
But, any work around if I still want to use the DHT sensor?
I haven’t seen a workaround for the DHT sensors. I would suggest you using a temperature sensor with an analog output rather than with a serial output. An analog output would work continuously and will not be affected by the latency of the pins.
Galileo isn't like the more basic Arduino boards - it's a full fledged computer.
How would you interface a DHT22 to a Windows PC ? You'd need some form of interface, same with Galileo.
You could try connecting the data pin to the Serial UART pins and experimenting with various baud rates to see if it can be read reliably. Simply connect TX and RX together and then transmit a single 0x00 byte to get it to start responding. You'll read something back, but whether it will be abel to be decoded is another matter.
It has nothing to do with interface. It has everything to do with the fact that the pin comms are EXTREMELY slow by a factor of at least 100. With a few tweaks you can make it work, but with the 1-wire type sensors, they just don't work well on the galileo primarily due to emulation induced slowness.
zoopster There is some slowness introduced by the Arduino library, which could be removed by writing your own libraries that, for example, do not need to set the MUX and IO Level shifter with every pin change, or you could even get some speed increase by using system() calls instead of arduino pin functions. You can even use Fast GPIO, but what if you need more than 2 pins?
The fact remains, you simply cannot get deterministic timing from a computing system without using an interface. The DHT sensors need deterministic timing. Galileo is a computing system, not a micro processor or micro controller. No matter how fast you could get the GPIO to work, you will never get deterministic timing reliably because your process can (and WILL) get de-scheduled regularly. In fact, in linux, the more agressively you try to hog the processor, the more aggressively the process scheduler will try to stop you doing exactly that.
How much is a day or your work worth? You could spend many days trying to optimise the GPIO libraries and building code to detect that a reading wasn't made and re-trying it, or you could spend less than $5 making a small interface which would work reliably 100% of the time.
You couldn't connect a DHT sensor to a Mac or PC without an interface, so why expect to connect it to Galileo without one?
True, but the Galileo IS billed as a microcontroller and IS billed as being arduino uno r3 compatible. The Galileo is not billed as a "full fledged computer". What you are saying is that the OS running ON the Galileo is not designed to support RT operations and in order to do simple RT calcs one needs to build a RT interface.
You answered the question, sort of. In order to run the DHT sensor on the Galileo, one must create a interface that handles what the Galileo cannot.