Users/westf/AppData/Local/Arduino15/packages/esp32/hardware/esp32/2.0.7/cores/esp32$ gid delay
esp32-hal.h:134:void delay(uint32_t);
esp32-hal-misc.c:176:void delay(uint32_t ms)
esp32-hal-time.c:93: delay(10);
esp32-hal-touch.c:182: delay(20); //delay needed before reading from touch channel after config
FirmwareMSC.cpp:361: delay(100);
FirmwareMSC.cpp:364: delay(100);
HWCDC.cpp:82: // Otherwise, USB is still unplugged and the timeout will be kept as Zero in order to avoid any delay in the
HWCDC.cpp:210: // used for the workaround with unplugged USB and TX Queue Full that causes a delay on every write()
HWCDC.cpp:309: delay(5);
HardwareSerial.cpp:394: delay(100); // Give some time...
HardwareSerial.cpp:452: delay(10);
Tone.cpp:38: delay(tone_msg.duration);
westfw@ww-gaming:/mnt/c/Users/westf/AppData/Local/Arduino15/packages/esp32/hardware/esp32/2.0.7/cores/esp32
(for an index built in that "cores" directory. If you search from further up, there are a lot more occurrences.)
The definition is that one in esp32-hal-misc.c
It might not be very useful. Since the esp32 core builds on freertos, you get:
and vTaskDelay is defined off in the depths of FreeRTOS somewhere (source for freertos is not included in the Arduino distribution, although it is open source.) At least it's probably well documented!
And it is a non-blocking implementation in a multi-tasking system. I.e. the calling task is suspended for that time, leaving the core for other tasks. In this case delay() is preferable to polling time().
so through executing a delay() on an ESP32 the arduino-code is suspended but WiFi and other tasks including softwarewatchdog-timer are continued which means using a delay() will block my own arduino-code but will not trigger the softwarewatchdog?
I only know of an example where polling time() instead of using delay() has triggered the watchdog. Perhaps a too long delay should be splitted for insertion of watchdog care?
delay() works as vTaskDelay() on a ESP32 when using a freeRTOS task. If, on a esp32, no tasks are being used and delay() is in loop() then delay stops execution of the code.
loop() is indeed run as a freeRTOS task. How loop() is used will be dependent on whether it has any code in loop(). If loop() is the only task running on core1 and delay() is called on core1, core1 comes to a halt. If using freeRTOS tasks and loop() is empty then vTaskDelay() will cause the freeRTOS task switcher to switch to another task for the duration of the vTaskDelay(). If using freeRTOS tasks and loop() is not empty, loop() is not guaranteed to run as loop() has the lowest priority of all tasks.