Hi !
what a weird question
Let me first describe my issue. I made a small project with a PWM dimmer and a DHT sensor, all communicating with MQTT.
I found that when I trigger the DHT measure the PWM has issues (goes to max intensity for a few milli secs). This issue is noticeable enought to push me to try to understand what's behind DHT driver.
The dialog itself is made with hardware ticks measurements and, not to be disturbed, the IRQ are switched off. This lasts for 3 ms worst case, so the glitch would be so small that I couldn't notice it.
BUT before that there is a low time of the communication pin of 250ms made with mp_hal_ delay_ms() wich ends up in mp_hal_delay_us().
This last function does a loop and calls repetively ets_event_poll() which does a lot of IRQ switch on switch off...
So I think I found the root of my issue.
Then the question is what is this ets_alt_task.c doing ??? It seems it is used nowhere ! I'd like to remove the call to ets_event_poll() in mp_hal_delay_us() but I want to be sure ir is really useless !
Thanks for any hint on that.
What is this ets_alt_task.c stuff doing
-
- Posts: 3
- Joined: Thu Jan 04, 2018 7:16 pm
Re: What is this ets_alt_task.c stuff doing
let me answer to myself
Actually, even if most of the symbols do not appear in the esp port, it is used by the firmware library of the ESP.
So nothing can be removed ...
On the original reason of this thread, I still have my PWM issues when DHT is accessed even after the removal of the useless 250ms delay. This delay is here to ensure that pin is really high before issuing start signal. This is useless since after a measure, the line is already put back in high state.
I'll try to find another solution...
Actually, even if most of the symbols do not appear in the esp port, it is used by the firmware library of the ESP.
So nothing can be removed ...
On the original reason of this thread, I still have my PWM issues when DHT is accessed even after the removal of the useless 250ms delay. This delay is here to ensure that pin is really high before issuing start signal. This is useless since after a measure, the line is already put back in high state.
I'll try to find another solution...