add CONFIG_FREERTOS_HZ=1000 to sdkconfig.defaults

[andresv]

By default it is 100 Hz, which means all thread sleeps under 10 ms do not work as expected. So this would just busy wait and does not give other threads chance to run. And it can be very confusing for the user.

loop {
   thread::sleep(Duration::from_millis(9))
}

So from user perspective it makes sense to explicitly define CONFIG_FREERTOS_HZ here. It would be less surprising then.

I learned it hard way here: https://github.com/esp-rs/esp-idf-sys/issues/71

[ivmarkov]

I'm not really sure switching to 1000Hz by default is such a good idea:

• If the ESP-IDF folks did choose 100Hz as default, perhaps they had a good reason for that
• Even after the 1000Hz adjustment you still have the issue. How long until somebody comes in and says "Hey! I'm doing thread::sleep(Duration::from_micros(500)) and the IDLE tasks' watchdogs are barking at me!"

If you really really insist on having this parameter in esp-idf-template, I would suggest it to be commented out by default.

And then, as per the other issue, this would've not been a problem in the first place, if your tasks were sleeping a bit more. Having such short sleep times are a bit concerning. Why do you need that? E.g. in my not-yet-revealed-yet-complex-pet-project, the shortest sleep time I have is precisely 10ms, and this is only because our esp-idf-hal does not yet have support for GPIO interrupts, so I have to poll 'em damn buttons real quick (but - GPIO interrupts are coming!). The next shortest sleep time is ~ 200ms, which is a whole lot more bearable (that's for the ULP program I'm running).

[ivmarkov]

Oh, sorry. You've explained it all in the other issue. Let me take a look.

Still: having this as a commented out parameter is what I feel most comfortable with.

[andresv]

Now it is commented out.

[mickeyl]

@ivmarkov Just stumbled over this here using a GitHub wide search for CONFIG_FREERTOS_HZ=1000. Although I don't use esp-rs, I thought I might answer your question "Having such short sleep times are a bit concerning. Why do you need that?" with my use case:

I'm building an ESP32-based CAN-Bus adapter that talks via a protocol named ISOTP (ISO15675-2), which is a fragmentation protocol. In this protocol, there is a mechanism called flow control, which indicates how long a sender should wait between sending consecutive CAN-frames. It is indicated in milliseconds, often in the single digit regions. So, for some hardware, it's indeed a necessity to have millisecond-granularity for sleep times.

[Vollbrecht]

@ivmarkov Just stumbled over this here using a GitHub wide search for CONFIG_FREERTOS_HZ=1000. Although I don't use esp-rs, I thought I might answer your question "Having such short sleep times are a bit concerning. Why do you need that?" with my use case:

I'm building an ESP32-based CAN-Bus adapter that talks via a protocol named ISOTP (ISO15675-2), which is a fragmentation protocol. In this protocol, there is a mechanism called flow control, which indicates how long a sender should wait between sending consecutive CAN-frames. It is indicated in milliseconds, often in the single digit regions. So, for some hardware, it's indeed a necessity to have millisecond-granularity for sleep times.

If you need shorter sleep times, you should not try to poll your system more often. You have to keep in mind that any given context switch takes x amount of computing. By lowering this value you allow the system to context switch "more often" and not "faster". The context switch time itself is still the same length.

So you probably should use another method for waiting between frames. For example using the Ets delay - or another Timer that you are getting a signal from. You should try to stay in one context for the time you are running your frames.