2026-01-27 06:02:38 -05:00
|
|
|
#pragma once
|
|
|
|
|
|
|
|
|
|
#include <functional>
|
|
|
|
|
#include <memory>
|
|
|
|
|
#include <string>
|
|
|
|
|
|
|
|
|
|
#include "activities/ActivityWithSubactivity.h"
|
|
|
|
|
#include "network/CrossPointWebServer.h"
|
|
|
|
|
|
|
|
|
|
enum class CalibreConnectState { WIFI_SELECTION, SERVER_STARTING, SERVER_RUNNING, ERROR };
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* CalibreConnectActivity starts the file transfer server in STA mode,
|
|
|
|
|
* but renders Calibre-specific instructions instead of the web transfer UI.
|
|
|
|
|
*/
|
|
|
|
|
class CalibreConnectActivity final : public ActivityWithSubactivity {
|
|
|
|
|
CalibreConnectState state = CalibreConnectState::WIFI_SELECTION;
|
|
|
|
|
const std::function<void()> onComplete;
|
|
|
|
|
|
|
|
|
|
std::unique_ptr<CrossPointWebServer> webServer;
|
|
|
|
|
std::string connectedIP;
|
|
|
|
|
std::string connectedSSID;
|
|
|
|
|
unsigned long lastHandleClientTime = 0;
|
|
|
|
|
size_t lastProgressReceived = 0;
|
|
|
|
|
size_t lastProgressTotal = 0;
|
|
|
|
|
std::string currentUploadName;
|
|
|
|
|
std::string lastCompleteName;
|
|
|
|
|
unsigned long lastCompleteAt = 0;
|
fix: prevent infinite render loop in Calibre Wireless after file transfer (#1070)
## Summary
* **What is the goal of this PR?**
Fix an infinite render loop bug in CalibreConnectActivity that caused
the e-ink display to refresh continuously every ~421ms after a file
transfer completed.
* **What changes are included?**
- Added lastProcessedCompleteAt member variable to track which server
completion timestamp has already been processed
- Modified the completion status update logic to only accept new values
from the server, preventing re-processing of old timestamps
- Added clarifying comments explaining the fix
## Problem Description
After receiving a file via Calibre Wireless, the activity displays
"Received: [filename]" for 6 seconds, then clears the message. However,
the web server's wsLastCompleteAt timestamp persists indefinitely and is
never cleared.
This created a race condition:
After 6 seconds, lastCompleteAt is set to 0 (timeout)
In the next loop iteration, status.lastCompleteAt (still has the old
timestamp) ≠ lastCompleteAt (0)
The code restores lastCompleteAt from the server value
Immediately, the 6-second timeout condition is met again
This creates an infinite cycle causing unnecessary e-ink refreshes
## Solution
The fix introduces lastProcessedCompleteAt to track which server
timestamp value has already been processed:
Only accept a new status.lastCompleteAt if it differs from
lastProcessedCompleteAt
Update lastProcessedCompleteAt when processing a new value
Do NOT reset lastProcessedCompleteAt when the 6-second timeout clears
lastCompleteAt
This prevents re-processing the same old server value after the timeout.
## Testing
Tested on device with multiple file transfer scenarios:
✅ File received message appears correctly after transfer
✅ Message clears after 6 seconds as expected
✅ No infinite render loop after timeout
✅ Multiple consecutive transfers work correctly
✅ Exiting and re-entering Calibre Wireless works as expected
## Performance Impact
Before: Infinite refreshes every ~421ms after timeout (high battery
drain, display wear)
After: 2-3 refreshes after timeout, then stops (normal behavior)
## Additional Context
This is a targeted fix that only affects the Calibre Wireless file
transfer screen. The root cause is the architectural difference between
the persistent web server state (wsLastCompleteAt) and the per-activity
display state (lastCompleteAt).
An alternative fix would be to clear wsLastCompleteAt in the web server
after some timeout, but that would affect all consumers of the web
server status. The chosen solution keeps the fix localized to
CalibreConnectActivity.
---
### AI Usage
Did you use AI tools to help write this code? _**< YES >**_
2026-02-27 06:34:11 +01:00
|
|
|
unsigned long lastProcessedCompleteAt = 0; // Track which server value we've already processed
|
2026-01-27 06:02:38 -05:00
|
|
|
bool exitRequested = false;
|
|
|
|
|
|
|
|
|
|
void renderServerRunning() const;
|
|
|
|
|
|
|
|
|
|
void onWifiSelectionComplete(bool connected);
|
|
|
|
|
void startWebServer();
|
|
|
|
|
void stopWebServer();
|
|
|
|
|
|
|
|
|
|
public:
|
|
|
|
|
explicit CalibreConnectActivity(GfxRenderer& renderer, MappedInputManager& mappedInput,
|
|
|
|
|
const std::function<void()>& onComplete)
|
|
|
|
|
: ActivityWithSubactivity("CalibreConnect", renderer, mappedInput), onComplete(onComplete) {}
|
|
|
|
|
void onEnter() override;
|
|
|
|
|
void onExit() override;
|
|
|
|
|
void loop() override;
|
refactor: move render() to Activity super class, use freeRTOS notification (#774)
## Summary
Currently, each activity has to manage their own `displayTaskLoop` which
adds redundant boilerplate code. The loop is a wait loop which is also
not the best practice, as the `updateRequested` boolean is not protected
by a mutex.
In this PR:
- Move `displayTaskLoop` to the super `Activity` class
- Replace `updateRequested` with freeRTOS's [direct to task
notification](https://www.freertos.org/Documentation/02-Kernel/02-Kernel-features/03-Direct-to-task-notifications/01-Task-notifications)
- For `ActivityWithSubactivity`, whenever a sub-activity is present, the
parent's `render()` automatically goes inactive
With this change, activities now only need to expose `render()`
function, and anywhere in the code base can call `requestUpdate()` to
request a new rendering pass.
## Additional Context
In theory, this change may also make the battery life a bit better,
since one wait loop is removed. Although the equipment in my home lab
wasn't been able to verify it (the electric current is too noisy and
small). Would appreciate if anyone has any insights on this subject.
Update: I managed to hack [a small piece of
code](https://github.com/ngxson/crosspoint-reader/tree/xsn/measure_cpu_usage)
that allow tracking CPU idle time.
The CPU load does decrease a bit (1.47% down to 1.39%), which make
sense, because the display task is now sleeping most of the time unless
notified. This should translate to a slightly increase in battery life
in the long run.
```
PR:
[40012] [MEM] Free: 185856 bytes, Total: 231004 bytes, Min Free: 123316 bytes
[40012] [IDLE] Idle time: 98.61% (CPU load: 1.39%)
[50017] [MEM] Free: 185856 bytes, Total: 231004 bytes, Min Free: 123316 bytes
[50017] [IDLE] Idle time: 98.61% (CPU load: 1.39%)
[60022] [MEM] Free: 185856 bytes, Total: 231004 bytes, Min Free: 123316 bytes
[60022] [IDLE] Idle time: 98.61% (CPU load: 1.39%)
master:
[20012] [MEM] Free: 195016 bytes, Total: 231532 bytes, Min Free: 132460 bytes
[20012] [IDLE] Idle time: 98.53% (CPU load: 1.47%)
[30017] [MEM] Free: 195016 bytes, Total: 231532 bytes, Min Free: 132460 bytes
[30017] [IDLE] Idle time: 98.53% (CPU load: 1.47%)
[40022] [MEM] Free: 195016 bytes, Total: 231532 bytes, Min Free: 132460 bytes
[40022] [IDLE] Idle time: 98.53% (CPU load: 1.47%)
```
---
### AI Usage
While CrossPoint doesn't have restrictions on AI tools in contributing,
please be transparent about their usage as it
helps set the right context for reviewers.
Did you use AI tools to help write this code? **NO**
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Refactor**
* Streamlined rendering architecture by consolidating update mechanisms
across all activities, improving efficiency and consistency.
* Modernized synchronization patterns for display updates to ensure
reliable, conflict-free rendering.
* **Bug Fixes**
* Enhanced rendering stability through improved locking mechanisms and
explicit update requests.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
---------
Co-authored-by: znelson <znelson@users.noreply.github.com>
2026-02-16 11:11:15 +01:00
|
|
|
void render(Activity::RenderLock&&) override;
|
2026-01-27 06:02:38 -05:00
|
|
|
bool skipLoopDelay() override { return webServer && webServer->isRunning(); }
|
|
|
|
|
bool preventAutoSleep() override { return webServer && webServer->isRunning(); }
|
|
|
|
|
};
|