Adverse effects of CONFIG_FREERTOS_HZ = 1000?

[DrMickeyLauer]

I'm working on the firmware of an ESP32C6-based CAN-Bus-Adapter for ECU reprogramming in vehicles. When talking to ECUs over CAN, it's pretty important to get the CAN-bus timing right. In order not to talk too fast (many ECUs are slow), the protocol provides an inter-frame-delay flow control of millisecond granularity.

I recently found out that with the default `CONFIG_FREERTOS_HZ = 100`, cooperative delays of less than 10ms are impossible, since, e.g., `vTaskDelay(2)` seems to return immediately.
I tried busy waiting 2000000µs with `esp_delay_us(2000000)`, but that always lead to asserts in the `esp_timer` task:

Code: Select all

Assert failed: prvProcessReceivedCommands timers.c:862 (xResult)

Now it looks like the only way(?) to get cooperative delays of millisecond-granularity is to bump the tick frequency to 1000Hz. I wonder which kind of adverse effects I'm going for if I do that. Does it really significantly reduce the overall performance (which I have read in some places)?

[MicroController]

I tried busy waiting 2000000µs with `esp_delay_us(2000000)`

You're busy-waiting for 2 seconds?!

[DrMickeyLauer]

Whoops… a couple of zeroes too many. That might have killed it.

[MicroController]

Another option for non-busy waiting would be to use the esp hr timer (micro-second resolution), i.e. set a timer to send your task a notification after X us, then have the task wait for that notification before continuing.