Extend the ESP32 lwip_select() replacement (direct rcvevent reads +
FreeRTOS task notifications) to all LibreTiny platforms (bk72xx,
rtl87xx, ln882h).
All LibreTiny platforms have LwIP >= 2.1.3 with
lwip_socket_dbg_get_socket() and FreeRTOS task notifications. The
thread safety argument is actually stronger on LibreTiny since all
platforms are single-core ARM Cortex-M, eliminating cross-core
memory ordering concerns entirely.
Introduces USE_LWIP_FAST_SELECT feature define (set from Python
codegen for ESP32 and LibreTiny) replacing per-platform USE_ESP32
guards. The only platform-specific difference is FreeRTOS header
paths (freertos/FreeRTOS.h on ESP-IDF vs FreeRTOS.h on LibreTiny).
Expected impact on LibreTiny (same as ESP32):
- ~17x faster socket polling (direct rcvevent vs lwip_select)
- ~3.5 KB flash savings (dead code elimination of lwip_select)
- ~56 bytes static RAM savings (fd_set members excluded)
- ~200-300 bytes heap savings (UDP wake socket eliminated)
Move tests that use make_us_central(), set_global_tz(), ParsedTimezone,
and DSTRuleType into esphome::time::testing namespace where those symbols
are declared.
Remove the runtime POSIX TZ string parser and all associated bridge code
now that timezone data is sent as pre-parsed structs via protobuf.
Removed:
- parse_posix_tz() and internal parsing helpers (skip_tz_name, parse_offset,
parse_dst_rule, parse_uint, parse_transition_time)
- RealTimeClock::set_timezone() overloads and apply_timezone_()
- API connection fallback path for string-based timezone
Kept:
- All conversion functions (epoch_to_local_tm, is_in_dst, calculate_dst_transition)
- Internal helpers used by conversion functions
- localtime_r/localtime overrides
- Tests for all permanent functions
On ESP8266, .rodata is mapped to DRAM (RAM), not flash. When
StructInitializer is used with all compile-time constant fields,
the compiler places the entire struct as a const blob in .rodata,
silently consuming ~20 bytes of RAM.
Switch to field-by-field assignment on ESP8266 so the IP address
values are encoded as immediate operands in flash instructions
instead of a .rodata blob. Other platforms continue to use the
aggregate initializer since their .rodata is flash-mapped.
The Beken/RTL SDKs ship lwIP defaults tuned for a general-purpose WiFi
SoC: TCP_SND_BUF=10*MSS (14.6KB), MEM_SIZE=32KB, 12 TCP + 22 UDP
sockets. These waste significant RAM on memory-constrained chips.
ESPAsyncWebServer allocates malloc(tcp_sndbuf()) per response chunk,
and at 14.6KB this causes OOM on BK7231N.
This tunes lwIP to match ESP32/ESP8266 ranges:
- TCP_SND_BUF/TCP_WND: 4*MSS (was 10*MSS)
- MEM_SIZE: 12KB BK72XX / 16KB RTL,LN (was 32KB)
- Socket counts: dynamic from component registrations
- All derived pool sizes adjusted accordingly
Also splits socket consumer tracking into TCP/UDP, adds
get_socket_counts() API, and updates ESP32 to use it.
Closes https://github.com/esphome/esphome/issues/14095
Tracks heap usage per component during both construction and setup() phases.
Logs deltas inline as components are registered and set up, then prints a
sorted summary after setup() completes. Storage is freed after the summary.
This is a diagnostic tool - not intended for production use. It was used to
discover the logger's unused UART event queue allocation (#14168).
Reverts the frame header synchronization added in #14135 and #14136
in favor of a simpler fix: increasing MAX_LINE_LENGTH so that the
existing footer-based resynchronization can recover after losing sync.
Both components already check for frame footers at every byte position,
which naturally resyncs the parser. The problem was that the buffers
were sized exactly to fit the largest frame, so a desynced parser's
footer could land at the overflow boundary and get discarded. Increasing
the buffer by 4 bytes (footer size) ensures the footer always lands
inside the buffer.
- ld2450: 41 -> 45 (zone query response = 40 bytes + 1 null + 4 footer)
- ld2410: 46 -> 50 (engineering data frame = 45 bytes + 1 null + 4 footer)
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com>
Co-authored-by: pre-commit-ci-lite[bot] <117423508+pre-commit-ci-lite[bot]@users.noreply.github.com>
The batch UART read change in #13818 exposed a latent bug where the
UART parser could start accumulating bytes mid-frame after module
restart, causing an infinite cycle of "Max command length exceeded"
warnings that prevented initialization.
Add header validation for the first 4 bytes of each frame, ensuring
the parser only accumulates data starting from a valid DATA_FRAME_HEADER
(AA FF 03 00) or CMD_FRAME_HEADER (FD FC FB FA). Non-matching bytes are
discarded until a valid frame start is found.
Fixes#14131
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
