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

[Richard Weinberger <richard@nod.at>]

Harald,

Am 02.12.2014 um 13:58 schrieb Harald Geyer:
> Richard Weinberger writes:
>> Harald,
>>
>> Am 02.12.2014 um 11:19 schrieb Harald Geyer:
>>> Hi Richard,
>>>
>>> thanks for the patch.
>>>
>>> I think (haven't tried yet) that your patch changes the number of
>>> edges recorded per transmission. So probably the decoding function
>>> needs to be adapted too...
>>
>> Can you explain your thought?
>> I'll happily dig into that.
> 
> Part of the reason to have the IRQ enabled during output was to
> get consistent timestamps (all timestamps would be taken via the
> same codepath). While this isn't essential, the current code expects
> that the start command we generate is in the list of edges. I think
> your changes will cause that start command not to be in the list of
> edges.

Yeah, if the sensor starts transmitting data before we've setup
the IRQ we'll lose 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...

> Note: There have been issues with some sensors (DHT11s?) not to
> send proper start bits, so the driver tries to be liberal about
> what it expects and you probably haven't seen any decoding errors
> if your sample sensor works to specification. (Now that I come to
> think about it: Undefined behaviour of IRQs on output lines could
> have been involved too...)
> 
> This is a bit of a mess and I'd rather clean this up than add more
> to it. Maybe I'm overly fussy about this, but it has bitten me in
> the past.

I can feel your pain. I've wasted some hours with half baked
user space drivers for the DHT22.

> 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?

>>> I won't be able to ACK this before testing on real HW. Of course
>>> confirmation that your changes work reliably on both DHT11 and DHT22
>>> will do as well. The debuging code present in the initial submission
>>> of the driver might be helpful to anybody trying to verify the
>>> timing.
>>
>> I have only DHT22 sensors. Of course I've tested the driver with these.
> 
> Ok, so I'll test DHT11 first. It would still be nice to confirm how
> many edges are recorded from DHT22 though.

Of course, I'll run some tests later.

Thanks,
//richard