Incompatibility between PWM and DHT22 library

[bgouhier]

I am using Sming framework to program a simple IoT chip with a DHT22 sensor. It is working fine until I try to use PWM on another pin. As soon as I add these lines in the code:

#include <HardwarePWM.h>         // Library for PWM
#define LED_PIN 2
uint8_t pinsPWM[1] = { LED_PIN }; 
HardwarePWM HW_pwm(pinsPWM, 1); // Enable PWM on these pins

I am not able to read anything from the DHT22 sensor. I dont know if the fault is in the PWM library or in the DHT22 library, but it seems they are incompatible. Maybe there is a timing issue in the DHT functions when the PWM is active?

If you want to test it (you'll need a DHT sensor), compile the sample/Humidity_DHT22 example, adding the lines above.

[etmmahi]

I have seen similar behavior when using HW_pwm and OneWire (ds1820 sensor) Removing the HW_pwm from my code re-established correct onewire behavior.

I suspect the the timing of the onewire is influenced by the HW_pwm driver.

[hreintke]

@bgouhier @etmmahi : Not worked with onewire but checked the code in that. There are lot of delay(..) statements in there to get the timing of the protocol right. HW_pwm, although the name from espressif suggests otherwise, is implemented in the SDK by software.

With your experience mentioned above, the conclusion would be indeed : HW_pwm & onewire cannot be used in one application.

If you have alternative libaries for onewire, that might be an option.

[bgouhier]

I though as much...

Do you know if other protocols are affected? I have SPI in mind particularly.. I believe it should be a true hardware SPI right? (the pins are called HSPI)

[harry-boe]

There are two SPI implementation in Sming one is software based and the other is hardware based.

None of them are using delays. The hardware SPI uses a clock devider therefore the SPI frequency hardware controlled. The software SPI does bit banging as fast as the sw GPIO allows (resulting in approx 2MHz SPI frequency.

So if the SW implementation get's disturbed by some HW_pwd delays or interrupts it might impact the protocol. However it depends on the SPI client how sensitive the reaction is on this kind of "jitter".

About the compatibility with HW_pwm. Not sure but i guess the HW_pwn implementation is indeed using the ESP PWM HW registers behind the scene inside the espressif SDK. As the time intervals are usually relatively long (a few hundred Herz) it's easy to mess that up with a delay controlled one wire interfaces and vice versa.

[hreintke]

Issue resolved.