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().
