Bit timing inaccurate with multi threading

[ssharks]

The bit timing is arranged with delayMicroseconds(500);. On a single threaded application this works reasonable stable although rounding errors tend to accumulate.
As soon as multiple threads are used on an ESP32 or ESP8266, this is no longer guaranteed to take 500 us. Depending on the OS scheduling this causes some communication to work, sometimes not to work.

Would it be better to use a timer for the bit timing? This guarantees the bit timing independent of scheduling and does not accumulate timing errors.

A workaround on the ESP32: Ensure all Opentherm communication is on 1 core, ensure the parrallel tasks are running on the other core.

[Laxilef]

delayMicroseconds() blocks the core, unlike delay() which calls vTaskDelay():

void ARDUINO_ISR_ATTR delayMicroseconds(uint32_t us) {
  uint64_t m = (uint64_t)esp_timer_get_time();
  if (us) {
    uint64_t e = (m + us);
    if (m > e) {  //overflow
      while ((uint64_t)esp_timer_get_time() > e) {
        NOP();
      }
    }
    while ((uint64_t)esp_timer_get_time() < e) {
      NOP();
    }
  }
}

[ssharks]

Thank for the suggestion. vTaskDelay() does not work in this situation as the resolution for vTaskDelay() is either 1 or 10 ms, which prohibits from implementing a 0.5 ms delay.

A more accurate time is achievable using the timers of the ESP32, like with https://docs.espressif.com/projects/arduino-esp32/en/latest/api/timer.html

[Laxilef]

delayMicroseconds() does not call vTaskDelay().

[ssharks]

I'm aware, delayMicroseconds expects full access to the processor. On the ESP32 multiple thread can be running on a single core. This means that a task can be interrupted and scheduled away. Therefore the delayMicroseconds can sometimes take 4 ms instead of 500 us. This breaks the functionality.

[Laxilef]

For strict timing compliance and maintaining compatibility with all Arduino platforms, this is the optimal implementation, IMHO.
You can propose your own implementation for ESP32 by correcting the code with #ifdef ARDUINO_ARCH_ESP32 and create a PR. From my experience Ihor is not against PRs.

[Phunkafizer]

I had this problem on ESP32 with higher network traffic (see image from logicanalyzer below), so I changed the TX routine using timer IRQs. I bit dirty though, suggestions welcome:

https://github.com/Phunkafizer/opentherm_library

[ssharks]

I had this problem on ESP32 with higher network traffic (see image from logicanalyzer below), so I changed the TX routine using timer IRQs. I bit dirty though, suggestions welcome:

https://github.com/Phunkafizer/opentherm_library

Look great, exactly what it should be. I've looked thought your code and I think it is just what I need.

The construction with the txbuf I would have made into a uint64_t / unsigned long in combination with some bitshifting. That would have made the code a little cleaner I think.

If you could make a pull request, it could maybe be merged.

[Laxilef]

@ssharks can you test this?

[ssharks]

@ssharks can you test this?

I'll try to find a moment to test this soon.

[ssharks]

I had this problem on ESP32 with higher network traffic (see image from logicanalyzer below), so I changed the TX routine using timer IRQs. I bit dirty though, suggestions welcome:

https://github.com/Phunkafizer/opentherm_library

Are you OK if I transform it into a pull request?

[Laxilef]

I tested Phunkafizer's implementation, it works too, but it introduces changes that break backward compatibility. Also, hwtimer is deprecated for idf 5, so I used gptimer in my implementation.

Before creating a PR, testing is necessary.

[ssharks]

I tested Phunkafizer's implementation, it works too, but it introduces changes that break backward compatibility. Also, hwtimer is deprecated for idf 5, so I used gptimer in my implementation.

Before creating a PR, testing is necessary.

Could you share your code?

[Phunkafizer]

@ssharks can you test this?

I did a quick try but was not able to compile in platformio. The gptimer is not found, maybe because I'm using arduino framework.

[ssharks]

@ssharks can you test this?

I did a quick try but was not able to compile in platformio. The gptimer is not found, maybe because I'm using arduino framework.

Hmmm... I pretty much get the opposite result. For me on the arduino framework the gptimer_handle_t is found, but the timerBegin(numTimer, 80, true) does have the wrong number of arguments.

I'm using arduino 1.8.19 and Arduino ESP32 2.0.18, @Laxilef can you share your version? Is it this one: https://github.com/Laxilef/opentherm_library/tree/esp32_timer, and what is the state? At least this one builds for me.

[Laxilef]

I am using pioarduino/platform-espressif32 latest stable version (Arduino core 3.1.3 based on IDF 5.3.2.250210). This is a great fork of platformio/platform-espressif32 with Arduino 3.x. The original repository uses Arduino 2.x, which is incompatible with newer boards like ESP32 C6, C3(?), etc.

platformio.ini:

platform = https://github.com/pioarduino/platform-espressif32/releases/download/53.03.13/platform-espressif32.zip
lib_deps = 
        ;...
	https://github.com/Laxilef/opentherm_library#esp32_timer

OTGateway compilation result:

Environment    Status    Duration
-------------  --------  ------------
d1_mini        SUCCESS   00:01:06.390
d1_mini_lite   SUCCESS   00:01:06.005
d1_mini_pro    SUCCESS   00:01:08.229
nodemcu_8266   SUCCESS   00:01:42.671
s2_mini        SUCCESS   00:00:54.064
s3_mini        SUCCESS   00:01:25.675
c3_mini        SUCCESS   00:01:22.168
nodemcu_32     SUCCESS   00:01:22.740
d1_mini32      SUCCESS   00:01:20.585
esp32_c6       SUCCESS   00:03:16.234
otthing        SUCCESS   00:01:16.083

Tested on s2, s3 - works correctly.
Community reports that the number of TIMEOUT/INVALID responses has decreased.

P.S. I used a preprocessor condition to test gptimer's support:

#if defined(SOC_GPTIMER_SUPPORTED) && SOC_GPTIMER_SUPPORTED
// ...
#endif

If gptimer's are not supported, then the default solution with delayMicroseconds() is used.