Tick time when ESP-IDF is built under Arduino

[RobMeades]

As indicated in this topic, we have a lump of code which works fine under ESP-IDF native but is unstable when built under Arduino ESP32.

One of the clear differences between the two is the tick time: 10 ms under ESP-IDF native and 1 ms under Arduino ESP32.

I have a test which runs around a loop 100 times sending a message to two queues at the end of which are two tasks: on ESP-IDF native this test has never failed, on Arduino ESP32 I get no more prints back from the target after the loop begins running. The tasks at the end of the queues do nothing other than each set a global that I can check once the test has completed; no debug prints, nothing heavy. Yet if I add a few milliseconds of RTOS delay (vTaskDelay(2000/portTICK_PERIOD_MS)) in the loop it passes fine under Arduino ESP32.

Questions:
1. Is there a reason why ESP-IDF uses 10 ms as its tick, rather than the more conventional 1ms?
2. Is there a reason why the sdkconfig for Arduino sets it to 1ms? Since Arduino does not use task-like things itself it seems a strange change to make.
3. If I set the sdkconfig under Arduino to use 10ms will that actually propagate into the build, given that the ESP-IDF code is a pre-built .a file?

[RobMeades]

FYI, the test also passes if I make the priority of the tasks at the end of the queues higher than the task that is sending to the queues (rather then being the same priority); it is not clear to me which this should make any difference, FreeRTOS should round-robin should it not [and of course this passes when run under plain-old ESP-IDF]?

[boarchuz]

1. "100 is a good tradeoff between ISR overhead and responsiveness" https://github.com/espressif/esp-idf/is ... -367507724
2. 1000Hz would've been preferred for Arduino because the platform seems to be based on 1ms resolution, as in the ubiquitous dependency on millis() and delay(). It's only a very thin layer over FreeRTOS there; it's simply a FreeRTOS task that invokes the user's setup() and loop(). There would be (even more) confusion and frustration if delay() didn't appear to do anything or had poor resolution, and/or beginners were hammered with frequent task watchdog timeouts.
3. No.
4. That could explain it. https://docs.espressif.com/projects/esp ... scheduling (you might want to follow https://github.com/espressif/esp-idf/pull/7351)

[RobMeades]

That is _excellent_ information @boarchuz, many thanks; (1), (2) and (3) are pretty much as I thought but (4) is rather a blow I must say. When we are running our tests normally I have a feeling we disable FreeRTOS on the baby core, which I guess is not the case with the sdkconfig used to build the ESP-IDF library here.

I will search through the code-base to look for places where we might have tasks of the same priority; could be many places since there's often no clear need to prefer one task over another, just let the RTOS sort it out.

I will definitely follow (4)...