From 6a6d9bb80876f6445ae877a0d1a24235758d1943 Mon Sep 17 00:00:00 2001 From: "J. Nick Koston" Date: Tue, 14 Apr 2026 21:58:22 -1000 Subject: [PATCH] cleanup --- esphome/core/scheduler.h | 14 ++++++++------ 1 file changed, 8 insertions(+), 6 deletions(-) diff --git a/esphome/core/scheduler.h b/esphome/core/scheduler.h index 0372e06066e..432a488a387 100644 --- a/esphome/core/scheduler.h +++ b/esphome/core/scheduler.h @@ -284,12 +284,14 @@ class Scheduler { bool cancel_retry_(Component *component, NameType name_type, const char *static_name, uint32_t hash_or_id); // Extend a 32-bit millis() value to 64-bit. Use when the caller already has a fresh now. - // On platforms with native 64-bit time (ESP32), ignores now and uses millis_64() directly. - // This means the Scheduler uses the esp_timer clock (via millis_64()) for all scheduling, - // even though the caller's 32-bit now came from xTaskGetTickCount (via millis()). Safe - // because scheduling only compares millis_64 against millis_64 — never against millis(). - // On other platforms (ESP8266), extends now to 64-bit using rollover tracking, so both - // millis() and scheduling use the same clock. + // On platforms with native 64-bit time (ESP32, Host, Zephyr, RP2040 — see + // USE_NATIVE_64BIT_TIME in defines.h), ignores now and uses millis_64() directly, so the + // Scheduler always works in 64-bit time regardless of what the caller's 32-bit now came + // from. On ESP32 specifically, millis() comes from xTaskGetTickCount while millis_64() + // comes from esp_timer — two different clocks — but that is safe because scheduling + // compares millis_64 values against millis_64 only, never against millis(). + // On platforms without native 64-bit time (e.g. ESP8266), extends now to 64-bit using + // rollover tracking, so both millis() and scheduling use the same underlying clock. uint64_t ESPHOME_ALWAYS_INLINE millis_64_from_(uint32_t now) { #ifdef USE_NATIVE_64BIT_TIME (void) now;