You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Thanks. However, the convention is to read sensor input from the "mcu" code and not directly from the host hardware. There was a similar discussion on this at PR Klipper3d#3462 . (And it may be possible to extend te ds18b20 code for the dh22 functionality.)
This distinction is also important because there are reports that the dht22 kernel code blocks the calling process during reads. The host code can't tolerate blocking reads - it could cause subtle failures.
-Kevin
The text was updated successfully, but these errors were encountered:
Hi,No I haven’t had time sorry. Feel free to give it a try.On 30 Dec 2022, at 19:19, Amar Takhar ***@***.***> wrote:
Hello, did you get anywhere on making this an MCU sensor? Thanks.
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: ***@***.***>
Per comment in PR Klipper3d#4320:
Thanks. However, the convention is to read sensor input from the "mcu" code and not directly from the host hardware. There was a similar discussion on this at PR Klipper3d#3462 . (And it may be possible to extend te ds18b20 code for the dh22 functionality.)
This distinction is also important because there are reports that the dht22 kernel code blocks the calling process during reads. The host code can't tolerate blocking reads - it could cause subtle failures.
-Kevin
The text was updated successfully, but these errors were encountered: