The approach in this commit is different:
- it creates a new method ameasure() that is meant to be called from a uasyncio task as
Code: Select all
await dhtobj.ameasure()
- it addresses the concern of @dpgeorge that the initial approach still had an 18ms blocking wait,
- moves everything that does not need to be in the critical section out of the C code into Python,
- unifies the usage of the HAL code across ports,
- works backwards compatible even if the uasyncio module is not available at all.
This implementation works with the current uasyncio as well as with the new one, that is in the pipeline.
I don't know where that "18ms" low signal is really coming from. The DHT22 datasheet says "MCU will
pull low data-bus and this process must beyond at least 1~10ms" (which is probably another Chinglish dialect for "you try, if error you try again with different waiter"). The sensors I tested here work with anything from 1ms to 30ms. Since the timing of that low phase is done with an await asyncio.sleep_ms() call, there is no guarantee that the task will be scheduled again soon enough. I think therefore it is necessary to make that duration configurable (parameter start_us in __init__(). If a particular sensor works with 2ms, then that will buy the user an additional 16ms of spare time for delays caused by other tasks.
I did not have a chance to test the stm32 port (lacking a board). I looked over the code and from all I can tell it should work. Can someone else please check that it does?
This implementation still has a blocking phase of about 4..5ms. This is unavoidable since receiving the data from the DHT module is bitbanging inside of a critical section.
Questions and comments, please, Jan