These are only used in debug rollover logging. Guarding them avoids
unused variable warnings and unnecessary includes in normal builds.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Pure code reorganization — no functional change. Combines the separate
#ifndef ESPHOME_THREAD_SINGLE and #ifdef ESPHOME_THREAD_MULTI_ATOMICS
guards into one if/elif/else chain so each threading model's static
variables are grouped together.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
A std::atomic_flag spinlock is unsafe on preemptive single-core RTOS
platforms (like LN882H) due to priority inversion: a high-priority task
spinning would prevent the lock holder from running to release it.
FreeRTOS Mutex has priority inheritance to handle this correctly.
Added a comment explaining why spinlock can't be used here.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
defer() items go straight into defer_queue_ and never use a timestamp.
Now that millis_64() has its own lock separate from the scheduler,
the call no longer needs to happen before taking the scheduler lock.
Move it inside the non-defer branch so defer() avoids the cost entirely.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
The atomics path only takes the lock during rollover (every ~49.7 days)
for a ~5 instruction critical section. A std::atomic_flag spinlock
(1 byte) replaces the full FreeRTOS Mutex (~80-100 bytes RAM) since
contention is near-zero. The full Mutex is kept only for the
MULTI_NO_ATOMICS path (BK72xx) which needs it for broader locking.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
On ESPHOME_THREAD_SINGLE (ESP8266), the lock is never used.
Guarding it avoids the static local guard variable overhead
(8 bytes RAM + init check on every call).
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
millis_64_impl_() handles 32-bit millis() rollover tracking for
platforms without native 64-bit time (ESP8266, LibreTiny). It was a
Scheduler method using Scheduler fields (last_millis_, millis_major_,
lock_), but has nothing to do with scheduling.
Move it to esphome/core/time_64.cpp as Millis64Impl::compute() with
static local state. Access is restricted via friend to millis_64()
(HAL) and Scheduler only.
Also introduces USE_NATIVE_64BIT_TIME define emitted by ESP32, Host,
Zephyr, and RP2040 platforms, replacing the verbose multi-platform
#if guards throughout scheduler.h/cpp.
time_64.cpp is only compiled on platforms that need it (ESP8266,
LibreTiny) via the build filter in config.py.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
RP2040's Pico SDK provides time_us_64() which reads the hardware
timer registers directly, returning native uint64_t microseconds.
This eliminates the need for 32-bit rollover tracking on this
platform.
millis() is now derived from millis_64() (like Zephyr) instead of
the other way around, unifying the time source.
Also removes IRAM_ATTR from all RP2040 HAL functions. On RP2040,
IRAM_ATTR is a no-op: the functions it decorated (millis, micros,
delayMicroseconds, arch_get_cpu_cycle_count) all call into Pico SDK
functions that reside in flash (XIP), so the attribute had no effect.
Zephyr's k_uptime_get() returns int64_t milliseconds directly,
eliminating the need for 32-bit rollover tracking on this platform.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Zephyr's k_uptime_get() returns int64_t milliseconds directly,
eliminating the need for 32-bit rollover tracking on this platform.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
The host platform already uses clock_gettime(CLOCK_MONOTONIC) for
millis(). Use it directly for millis_64() instead of delegating to
the Scheduler's rollover tracking.
This eliminates the MULTI_ATOMICS rollover code path (CAS/atomic)
on host builds and removes the dependency on App.scheduler for
millis_64() to work.
The fully-qualified friend uint64_t ::esphome::millis_64() syntax
causes 'uint64_t is not a class, namespace, or enumeration' errors
on the ESP8266 clang-tidy toolchain. Use unqualified form which
resolves correctly within the esphome namespace.
millis() on the line above casts esp_timer_get_time() to uint32_t.
Match that pattern in millis_64() with static_cast<uint64_t> to
avoid implicit signed-to-unsigned conversion.
- Use 1000ULL divisor in millis_64() to match millis() style and
avoid implicit signed-to-unsigned conversion
- Clarify next_schedule_in @param: now is unused for 64-bit
extension on ESP32, but still used for 32-bit paths in call()
- Remove unnecessary uint64_t cast on esp_timer_get_time() (already
returns int64_t, always non-negative after boot)
- Fix next_schedule_in @param comment: now is only unused on ESP32,
used for rollover tracking on other platforms
- Use fully-qualified friend declaration (::esphome::millis_64())
Include hal.h directly in scheduler.h instead of forward-declaring
millis_64(), which clang-tidy flags as redundant when both headers
are included in the same translation unit.
On ESP32, millis() truncates esp_timer_get_time() to 32-bit, then
Scheduler::millis_64_() reconstructs 64-bit using 193 bytes of
CAS/atomic/lock rollover tracking code. This is unnecessary since
esp_timer_get_time() already provides native 64-bit microseconds.
Add millis_64() as a HAL-level function alongside millis():
- ESP32: native esp_timer_get_time()/1000 (26 bytes, lock-free)
- Other platforms: delegate to Scheduler::millis_64_impl_() which
retains the existing rollover tracking (renamed from millis_64_)
Saves 344 bytes flash and ~8 bytes RAM on ESP32 by eliminating the
rollover tracking code and associated atomic fields. External callers
(uptime, web_server) now use millis_64() directly instead of
App.scheduler.millis_64().
