Richard Weinberger writes: > 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. 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. > 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. > > 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. Thanks, Harald -- To unsubscribe from this list: send the line "unsubscribe linux-iio" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
