From 81f38566a64002ae82228d9fd6550126d62d1b94 Mon Sep 17 00:00:00 2001 From: MarekZegare4 Date: Wed, 24 Jun 2026 21:39:46 +0200 Subject: [PATCH] revert(companion): trail buffer back to 512 points The 1024-point trail buffer (16 KB in .bss, since ui_task is a global) doubled the static footprint of the GPS trail for little practical gain on a RAM-tight nRF52 build. Revert CAPACITY to 512 (8 KB) and sync the Tools docs. Heap headroom is better spent elsewhere; in-stream simplification already lets 512 vertices cover a long route. Co-Authored-By: Claude Opus 4.8 --- docs/solo_features/tools_screen/tools_screen.md | 2 +- examples/companion_radio/Trail.h | 11 ++++++++--- 2 files changed, 9 insertions(+), 4 deletions(-) diff --git a/docs/solo_features/tools_screen/tools_screen.md b/docs/solo_features/tools_screen/tools_screen.md index afe7a30a..dccabdfa 100644 --- a/docs/solo_features/tools_screen/tools_screen.md +++ b/docs/solo_features/tools_screen/tools_screen.md @@ -79,7 +79,7 @@ Because it is the same list, all the same keys apply — **UP/DOWN** to navigate | :-----------------------: | :-----------------------: | | ![](./trail_summary_oled.png) | ![](./trail_summary_eink.png) | -Records your route in a RAM ring buffer (up to 1024 points, sampled every 1 s). The track is **simplified as it's recorded** — a long straight stretch is kept as just its two endpoints while curves keep their detail (bounded to within the **Min dist** tolerance of the real path), so the buffer covers a far longer route than a flat point budget would suggest. Tracking runs in the background — a blinking **G** appears in the status bar. The trail survives display auto-off but is lost on reboot unless saved to flash first. +Records your route in a RAM ring buffer (up to 512 points, sampled every 1 s). The track is **simplified as it's recorded** — a long straight stretch is kept as just its two endpoints while curves keep their detail (bounded to within the **Min dist** tolerance of the real path), so the buffer covers a far longer route than a flat point budget would suggest. Tracking runs in the background — a blinking **G** appears in the status bar. The trail survives display auto-off but is lost on reboot unless saved to flash first. > [!TIP] > The **Map** view is also reachable directly from the home carousel — the **Map** page shows a live mini-preview (your position, trail, and tracked contacts) with a **north marker** and a bottom-left **scale tick**. The status line below reads `Track:N` (tracked-node count) and, when you have a fix and at least one tracked contact, an **arrow + distance** to the **nearest** one (e.g. `Track:3 →120m`). If a **Locator/Nav target** is set it's drawn as a **flag marker** (see **Locator**). Press **Enter** to open the full Trail Map; **Hold Enter** shares your position (see **Live Share**); **Back** returns home. diff --git a/examples/companion_radio/Trail.h b/examples/companion_radio/Trail.h index 5a0600ae..7c3b8ed9 100644 --- a/examples/companion_radio/Trail.h +++ b/examples/companion_radio/Trail.h @@ -8,8 +8,13 @@ #include "GeoUtils.h" // RAM-only GPS trail ring buffer. -// Storage cost: CAPACITY(1024) × sizeof(TrailPoint)(16 B, padded) = 16 KB, -// always resident (UITask::_trail member). The trail survives auto-off (only +// Storage cost: CAPACITY(512) × sizeof(TrailPoint)(16 B, padded) = 8 KB, +// always resident in .bss (UITask::_trail, and ui_task is a global object — +// see main.cpp). Because the nRF52 heap region starts just above .bss, every +// byte added here is a byte taken from the heap: at 1024 points (16 KB) free +// heap fell to ~4 KB and the input/menu path started failing its allocations +// while the periodic redraw kept running. Keep this conservative. The trail +// survives auto-off (only // the display blanks) but is lost on reboot — user explicitly snapshots to a // LittleFS slot before powering down to keep it. // @@ -29,7 +34,7 @@ static const uint8_t TRAIL_FLAG_SEG_START = 0x01; class TrailStore { public: - static const int CAPACITY = 1024; + static const int CAPACITY = 512; // _count is serialised as uint16_t in the save header — fail the build loudly // if CAPACITY is ever grown past what that can hold, rather than truncating. static_assert(CAPACITY <= 0xFFFF, "TrailStore::CAPACITY must fit in the uint16_t save-header count");