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
Hi, at first I want to thank you for the driver. I have the problem on my heltec esp32 lora v2.1 board, that i can't use the standard IOMUX spi pins. So i switched over to use gpio spi pins cs-17, clk-2, miso-22. Everything is working fine so far, exept for the first measurement readout being always 0 degrees celsius. This is a problem for my battery driven sensor, because after wakeup it's always the first readout. Digging deeper into the case my results seems to be the following problem: after startup/wake from sleep state esp32 has to switch over from muxed to gpio pin driven spi (initiated by the aqurire spi bus command), which results in an signal level change on the cs signal output. This initiates a new adc sampling on the MAX6675 resulting in a up to 220ms pause (datasheet MAX6675) before you can readout the results. To avoid this, I added a vtask delay command of 220ms right after the spi_device_acquire_bus command in your driver and the problem is gone. I haven't tested the behavior with standard spi pins weather it's the same. However I hope I could help.
The text was updated successfully, but these errors were encountered:
Hi, at first I want to thank you for the driver. I have the problem on my heltec esp32 lora v2.1 board, that i can't use the standard IOMUX spi pins. So i switched over to use gpio spi pins cs-17, clk-2, miso-22. Everything is working fine so far, exept for the first measurement readout being always 0 degrees celsius. This is a problem for my battery driven sensor, because after wakeup it's always the first readout. Digging deeper into the case my results seems to be the following problem: after startup/wake from sleep state esp32 has to switch over from muxed to gpio pin driven spi (initiated by the aqurire spi bus command), which results in an signal level change on the cs signal output. This initiates a new adc sampling on the MAX6675 resulting in a up to 220ms pause (datasheet MAX6675) before you can readout the results. To avoid this, I added a vtask delay command of 220ms right after the spi_device_acquire_bus command in your driver and the problem is gone. I haven't tested the behavior with standard spi pins weather it's the same. However I hope I could help.
The text was updated successfully, but these errors were encountered: