dangernoodle-io / breadboard / 30726091807

97%

push

github

refactor: migrate platform/espidf/ vTaskDelay call sites onto bb_task_delay_ms (#1185)

Replaces 21 hand-rolled vTaskDelay(pdMS_TO_TICKS(N)) call sites across 13 platform/espidf/ files with bb_task_delay_ms(N), per rules/esp-idf.md (no raw FreeRTOS when a bb_* wrapper exists, B1-1350/B1-1352).

All configured smoke sdkconfigs run CONFIG_FREERTOS_HZ=1000, where pdMS_TO_TICKS(N) == N ticks exactly for any N >= 1 (no truncation), so every migrated site is a like-for-like swap, not a behaviour change. That 1000Hz value is explicit in every in-repo board file, not an ESP-IDF default -- ESP-IDF itself defaults CONFIG_FREERTOS_HZ to 100 when unset, so a future board file that omits it would drop to 100Hz and could retroactively make some of these sites truncate; the tick-rate assumption this migration leans on is a repo convention, not a platform guarantee.

Two vTaskDelay(1) literal-tick spins (bb_ota_pull.c, bb_ota_push.c) migrate to bb_task_delay_ms(1), which is exact at 1000Hz and, unlike the raw literal, still guarantees a minimum 1-tick block at any other tick rate (bb_task_delay_ms's own min-1-tick-for-nonzero-ms contract) -- these are deliberate delay-for-a-tick spins (comments: WDT/TCP-window relief), not yield-only call sites, so bb_task_yield() would be the wrong target. ESP-IDF also caps CONFIG_FREERTOS_HZ at 1000, so for ms=1 the ms*tick_rate_hz product can never exceed one tick and the min-1-tick floor always fires -- the two conversions are exactly equivalent to the raw literal at every reachable tick rate, not merely at the configured 1000Hz, which is the one semantic change in this diff and the reason it is safe.

Deliberately left as raw vTaskDelay (not migrated): platform/espidf/bb_task/bb_task_espidf.c:89 (bb_task_delay_ms()'s own espidf implementation); platform/espidf/bb_ota_boot/bb_ota_boot.c:441 (vTaskDelay(portMAX_DELAY), an infinite block, not a millisecond delay, no bb_task_delay_ms() equivalent); components/bb_core/include/bb_once... (continued)

8113 of 8686 branches covered (93.4%)

Branch coverage included in aggregate %.

13764 of 13919 relevant lines covered (98.89%)

2580.25 hits per line