Re: [PATCH 1/2] iio: dht11: forked a driver version that polls sensor's signal from GPIO

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



I understand that the first priority is in finding out if there is actually a proper use case for a polling implementation at all. Only then, it might be worth to extend
the existing dht11 module by an polling alternative.

Am 31.01.23 um 11:18 schrieb harald@xxxxxxxxx:
On 2023-01-30 21:42, Andreas Feldner wrote:
On a BananaPi M2 Zero, the existing, IRQ based dht11 driver is not working,
but missing most IRQs.

That's quite surprising as the driver works well on many similar systems
based on Allwinner SoCs. I suspect the problem is with your setup. Maybe
some other (polling?) driver is slowing everything down.

Can you give me a hint how to look for signs of such a situation?

BTW I took some pride in building the board's system image from reproduceable sources: Debian kernel package linux-image-5.10.0-20-armmp-lpae, and the device tree from 

arch/arm/boot/dts/sun8i-h2-plus-bananapi-m2-zero.dts

So the setup should be reproducible, unlike other approaches advertised in the BananaPi forum...

What I did is

- check /proc/interrupts. The highest volume interrupts there are two instances of sunxi-mmc, one generating about 50 interrupts per second, the other about 25. Those (and most) interrupts are GICv2, but the GPIO releated are sunxi-pio-{level,edge}

- check dmesg: literally no messages apart from dht11_poll itself

- check top: sugov:0 is reported to eat 10% of one cpu, but I understand that's expected and an artifact anyway. Changing the scaling governor to "performance" eliminates this, but does not help in making the irq driven dht11 work.

- check vmstat: ir is between 50 and 200 apart from short spikes, those probably related to a certain cron job

- check sysstat cpu, mem, threads, mutex: each of the 4 cores has a low performance (a factor of 15 lower than a Raspberrypi 3), but constant, low stddev, etc. No surprises running e.g. 8 threads instead of 4.

So, apart from the fact that it is missing about 3/4 of the IRQs the dht11 driver should get, I have no indication that something might be wrong with the board or its setup. Where else should I look?

Some additional remarks of questionable relevance:

Prior to attempt to put the logic into a kernel module, I implemented a polling PoC in userspace using libgpiod by nailing together parts of gpioset, gpiomon, and the dht11 kernel module:
https://github.com/pelzvieh/banana_resources/blob/main/poll_dht11.c

This works "reasonably", once in a few shots, but the diagnostics show that there are only typically 5 to 7 samples for a high pulse corresponding to a zero bit (26-28 µs). My naive interpretation was that the board is just quite slow for this task.

BTW the constant timing of the low pulse of 50 µs was confirmed by that experiment as well. It seems to work as given in the DHT22 datasheet floating arount in internet (e.g. for download at https://www.mikrocontroller-elektronik.de/dht22-am2302-luftfeuchte-und-temperatursensor/).

Following the hints in Harald Geyer's comments I
tried to implement a version of the driver that is polling the GPIO
sensor in a busy loop, not using IRQ altogether.

IIRC one readout takes about 80 milliseconds. That's a very long time for
a busy loop. I doubt this is acceptable for inclusion in the kernel. Of
course also Jonathan's comments apply.

Seems to be a bit less, just in case that matters. Given the timing chart I'd expect

on average: 200µs + 40 * 100µs = 4,2ms

worst case (device trying to send all one-bits): 200µs + 40 * 120µs = 5,0ms

Yours,

Andreas.




[Index of Archives]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Input]     [Linux Kernel]     [Linux SCSI]     [X.org]

  Powered by Linux