Re: [PATCH 2/2] iio: dht11: IRQ fixes

[Richard Weinberger <richard@nod.at>]

Harald,

Am 02.12.2014 um 20:49 schrieb Harald Geyer:
>> Yeah, if the sensor starts transmitting data before we've setup
>> the IRQ we'll lose edges.
> 
> Yes, but you missunderstood me. That's not the point.
> 
> The point is that now the edges that the driver generates while
> the gpio is configured as output are part of the preamble of the
> data transmission. I think with your patch applied this is no longer
> the case (we don't get interrupts for these edges anymore). So the
> decoding needs to be changed to work with a shorter preamble.

Hmm, I get always 84 edges.
This value makes sense to me, 40 bits (80 edges) plus 4 preamble edges.

>> But AFAICT the DHT is much slower than we are with setting up the IRQ.
>> The DHT is a rather stupid device so we cannot use proper interrupting.
>> But I can think of adding also polling support to the driver.
>> Such that one can select whether she wants to use IRQ or polling...
> 
> I don't like the idea of a polling driver. Also I don't think it will
> be necessary.

Of course polling is ugly, if IRQ works let's keep it as is. :)

>>> Since it seems you have some interesst in working on these parts,
>>> let me mention an unrelated issue: The DHT22 stops sending data
>>> after a random time (think of days here) which AFAIK only can be
>>> worked around by power-cycling the sensor. I mean to add something
>>> for this to the driver but couln't make up my mind about what the
>>> proper ABI for this would be, so right now I'm using some userspace
>>> hack for this. (The issue was already discussed on the linux-iio
>>> mailing list a few month ago, if you want to look into this.
>>> Anyway: You have been warned ... ;)  
>>
>> Oh, that's a very valuable information!
>> Currently I'm evaluating some sensors for a private project.
>> You can recommend a better temp/humidity sensor?
> 
> No really. When I noticed these cheap little parts are actually
> *cheap* parts, I looked which sensors are already supported by
> hwmon, but none appealed to me, so I decided to try and work
> around this in software as far as possible. It's not hard to do, just
> hard to do right. ;)
> 
> The best I can recommend you is to have a look at the list of
> humidity sensors supported by hwmon yourself.

Ok!

Thanks,
//richard