beb4e82c9c2436fe0d11a618b283223fcc2f7806
11
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 Jeremy Klein
|
7acc31bc34 |
fix: silent-reboot on wifi activity exit to clear heap fragmentation (#1908)
WiFi/LWIP/netif teardown scatters long-lived allocations across the heap, leaving ~50KB of contiguous space unrecoverable without a reboot. Reboot the SoC on exit from any wifi-using activity to guarantee a clean heap. An RTC_NOINIT flag survives the reboot and tells setup() to skip the boot splash and route the user back where they came from: - File transfer / Calibre / OPDS / Font download -> home - KOReader sync -> currently-open EPUB Activities check WiFi.getMode() before rebooting, so backing out of the network mode menu without joining doesn't trigger a cycle. KOSync also esp_wifi_stop()s after the sync result so the radio is off while the user reads it; full teardown happens at the reboot. ## Additional Context The silent reboot skips the booting splash screen - it visibly looks like a screen refresh. This does cause a disconnection/reconnection blip for developers actively pulling logs over serial, but `pio device monitor` and the like successfully reconnect and feed in the early boot serial. as an example: ``` [256676] [DBG] [ACT] Exiting activity: KOReaderSync [256706] [DBG] [MAIN] Silent restart (target=reader) ESP-ROM:esp32c3-api1-20210207 Build:Feb 7 2021 rst:0xc (RTC_SW_CPU_RST),boot:0xf (SPI_FAST_FLASH_BOOT) Saved PC:0x403872bc SPIWP:0xee mode:DIO, clock div:1 load:0x3fcd72a0,len:0x990 load:0x403cbf10,len:0xac8 load:0x403ce710,len:0x4d28 entry 0x403cbf10 [22] [INF] [MAIN] Hardware detect: X4 [29] [SD] SD card detected [43] [DBG] [CPS] Settings loaded from file [58] [DBG] [KRS] Loaded KOReader credentials for user: jeremydk [69] [DBG] [OPS] Loaded 1 OPDS servers from file [69] [DBG] [UI] Using Lyra theme [70] [DBG] [MAIN] Starting CrossPoint version 1.2.0-dev-detached-bde75787 ... [203] [DBG] [ACT] Entering activity: Reader [211] [DBG] [EBP] Loading ePub: /Halting State - Charles Stross.epub [221] [DBG] [BMC] Loaded cache data: 51 spine, 41 TOC entries [246] [DBG] [CSS] Loaded 41 rules from cache [247] [DBG] [EBP] Loaded ePub: /Halting State - Charles Stross.epub ``` --- ### 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? _PARTIALLY_ |
||
|
Jeremy Klein
|
adcd7961c9 |
feat: self-heal from transient WiFi loss, add dBm indicator during WebServerActivity (#1780)
## Summary * **What is the goal of this PR?** I was seeing hangs during File Transfer. Troubleshooting via serial showed it had to do with the SHUTTING_DOWN state. Strengthened the WiFi State Machine a bit and added self-healing. Additionally, I found it obnoxious to need to keep referring to serial for my wifi strength, so a dBm meter is added opposing the SSID when on the File Transfer page. * **What changes are included?** The dBm meter was at risk of causing rapid screen updates (if, say, we hovered right around a threshold), so I've implemented a basic hysteresis around this. RISING/FALLING would be more canonical variable names, but are reserved in the framework. ## Additional Context My X4 has a terrible antenna, apparently, and I was running into this failure condition pretty regularly. Wifi "bars" were chosen as a relatively pan-cultural glyph rather than relying on localization. Tested on hardware at -83 dBm under sustained EPUB upload (60 books, ~30 MB). Transient losses up to ~14s now ride through; pre-fix the same losses required a power-cycle after as little as a 2s blip. --- ### 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? Nope. Commits are hand written. Claude was used to build a local test harness for validation only during iteration. |
||
|
Xuan-Son NguyenandZach Nelson
|
c4fc4effbd |
refactor: implement ActivityManager (#1016)
## Summary Ref comment: https://github.com/crosspoint-reader/crosspoint-reader/pull/1010#pullrequestreview-3828854640 This PR introduces `ActivityManager`, which mirrors the same concept of Activity in Android, where an activity represents a single screen of the UI. The manager is responsible for launching activities, and ensuring that only one activity is active at a time. Main differences from Android's ActivityManager: - No concept of Bundle or Intent extras - No onPause/onResume, since we don't have a concept of background activities - onActivityResult is implemented via a callback instead of a separate method, for simplicity ## Key changes - Single `renderTask` shared across all activities - No more sub-activity, we manage them using a stack; Results can be passed via `startActivityForResult` and `setResult` - Activity can call `finish()` to destroy themself, but the actual deletion will be handled by `ActivityManager` to avoid `delete this` pattern As a bonus: the manager will automatically call `requestUpdate()` when returning from another activity ## Example usage **BEFORE**: ```cpp // caller enterNewActivity(new WifiSelectionActivity(renderer, mappedInput, [this](const bool connected) { onWifiSelectionComplete(connected); })); // subactivity onComplete(true); // will eventually call exitActivity(), which deletes the caller instance (dangerous behavior) ``` **AFTER**: (mirrors the `startActivityForResult` and `setResult` from android) ```cpp // caller startActivityForResult(new NetworkModeSelectionActivity(renderer, mappedInput), [this](const ActivityResult& result) { onNetworkModeSelected(result.selectedNetworkMode); }); // subactivity ActivityResult result; result.isCancelled = false; result.selectedNetworkMode = mode; setResult(result); finish(); // signals to ActivityManager to go back to last activity AFTER this function returns ``` TODO: - [x] Reconsider if the `Intent` is really necessary or it should be removed (note: it's inspired by [Intent](https://developer.android.com/guide/components/intents-common) from Android API) ==> I decided to keep this pattern fr clarity - [x] Verify if behavior is still correct (i.e. back from sub-activity) - [x] Refactor the `ActivityWithSubactivity` to just simple `Activity` --> We are using a stack for keeping track of sub-activity now - [x] Use single task for rendering --> avoid allocating 8KB stack per activity - [x] Implement the idea of [Activity result](https://developer.android.com/training/basics/intents/result) --> Allow sub-activity like Wifi to report back the status (connected, failed, etc) --- ### 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? **PARTIALLY**, some repetitive migrations are done by Claude, but I'm the one how ultimately approve it --------- Co-authored-by: Zach Nelson <zach@zdnelson.com> |
||
|
Xuan-Son Nguyenandznelson
|
a616f42cb4 |
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> |
||
|
|
3a761b18af |
Refactors Calibre Wireless Device & Calibre Library (#404)
Our esp32 consistently dropped the last few packets of the TCP transfer in the old implementation. Only about 1/5 transfers would complete. I've refactored that entire system into an actual Calibre Device Plugin that basically uses the exact same system as the web server's file transfer protocol. I kept them separate so that we don't muddy up the existing file transfer stuff even if it's basically the same at the end of the day I didn't want to limit our ability to change it later. I've also added basic auth to OPDS and renamed that feature to OPDS Browser to just disassociate it from Calibre. --------- Co-authored-by: Arthur Tazhitdinov <lisnake@gmail.com> Co-authored-by: Dave Allie <dave@daveallie.com> |
||
|
Pavel Liashkov
|
a922e553ed |
Prevent device sleep during WiFi file transfer and OTA updates (#203)
## Summary * **What is the goal of this PR?** Fixes #199 - Device falls asleep during WiFi file transfer after 10 minutes of inactivity, disconnecting the web server. * **What changes are included?** - Add `preventAutoSleep()` virtual method to `Activity` base class - Modify main loop to reset inactivity timer when `preventAutoSleep()` returns true - Override `preventAutoSleep()` in `CrossPointWebServerActivity` (returns true when web server running) - Override `preventAutoSleep()` in `OtaUpdateActivity` (returns true during update check/download) ## Additional Context * The existing `skipLoopDelay()` method controls loop timing (yield vs delay) for HTTP responsiveness. The new `preventAutoSleep()` method is semantically separate - it explicitly signals that an activity should keep the device awake. * `CrossPointWebServerActivity` uses both methods: `skipLoopDelay()` for responsive HTTP handling, `preventAutoSleep()` for staying awake. * `OtaUpdateActivity` only needs `preventAutoSleep()` since the OTA library handles HTTP internally. |
||
|
dangson
|
140d8749a6 |
Support swapping the functionality of the front buttons (#133)
## Summary **What is the goal of this PR?** Adds a setting to swap the front buttons. The default functionality are: Back/Confirm/Left/Right. When this setting is enabled they become: Left/Right/Back/Confirm. This makes it more comfortable to use when holding in your right hand since your thumb can more easily rest on the next button. The original firmware has a similar setting. **What changes are included?** - Add the new setting. - Create a mapper to dynamically switch the buttons based on the setting. - Use mapper on the various activity screens. - Update the button hints to reflect the swapped buttons. ## Additional Context Full disclosure: I used Codex CLI to put this PR together, but did review it to make sure it makes sense. Also tested on my device: https://share.cleanshot.com/k76891NY |
||
|
Brendan O'Leary
|
9f4f71fabe |
Add AP mode option for file transfers (#98)
## Summary
* **What is the goal of this PR?** Adds WiFi Access Point (AP) mode
support for File Transfer, allowing the device to create its own WiFi
network that users can connect to directly - useful when no existing
WiFi network is available. And in my experience is faster when the
device is right next to your laptop (but maybe further from your wifi)
* **What changes are included?**
- New `NetworkModeSelectionActivity` - an interstitial screen asking
users to choose between:
- "Join a Network" - connects to an existing WiFi network (existing
behavior)
- "Create Hotspot" - creates a WiFi access point named
"CrossPoint-Reader"
- Modified `CrossPointWebServerActivity` to:
- Launch the network mode selection screen before proceeding
- Support starting an Access Point with mDNS (`crosspoint.local`) and
DNS server for captive portal behavior
- Display appropriate connection info for both modes
- Modified `CrossPointWebServer` to support starting when WiFi is in AP
mode (not just STA connected mode)
## Additional Context
* **AP Mode Details**: The device creates an open WiFi network named
"CrossPoint-Reader". Once connected, users can access the file transfer
page at `http://crosspoint.local/` or `http://192.168.4.1/`
* **DNS Captive Portal**: A DNS server redirects all domain requests to
the device's IP, enabling captive portal behavior on some devices
* **mDNS**: Hostname resolution via `crosspoint.local` is enabled for
both AP and STA modes
* **No breaking changes**: The "Join a Network" option preserves the
existing WiFi connection flow
* **Memory impact**: Minimal - the AP mode uses roughly the same
resources as STA mode
|
||
|
Dave Allie
|
b39ce22e54 | Cleanup of activities | ||
|
Dave Allie
|
77c655fcf5 |
Give activities names and log when entering and exiting them (#92)
## Summary * Give activities name and log when entering and exiting them * Clearer logs when attempting to debug, knowing where users are coming from/going to helps |
||
|
Brendan O'LearyandDave Allie
|
d41d539435 |
Add connect to Wifi and File Manager Webserver (#41)
## Summary
- **What is the goal of this PR?**
Implements wireless EPUB file management via a built-in web server,
enabling users to upload, browse, organize, and delete EPUB files from
any device on the same WiFi network without needing a computer cable
connection.
- **What changes are included?**
- **New Web Server**
([`CrossPointWebServer.cpp`](src/CrossPointWebServer.cpp),
[`CrossPointWebServer.h`](src/CrossPointWebServer.h)):
- HTTP server on port 80 with a responsive HTML/CSS interface
- Home page showing device status (version, IP, free memory)
- File Manager with folder navigation and breadcrumb support
- EPUB file upload with progress tracking
- Folder creation and file/folder deletion
- XSS protection via HTML escaping
- Hidden system folders (`.` prefixed, "System Volume Information",
"XTCache")
- **WiFi Screen** ([`WifiScreen.cpp`](src/screens/WifiScreen.cpp),
[`WifiScreen.h`](src/screens/WifiScreen.h)):
- Network scanning with signal strength indicators
- Visual indicators for encrypted (`*`) and saved (`+`) networks
- State machine managing: scanning, network selection, password entry,
connecting, save/forget prompts
- 15-second connection timeout handling
- Integration with web server (starts on connect, stops on exit)
- **WiFi Credential Storage**
([`WifiCredentialStore.cpp`](src/WifiCredentialStore.cpp),
[`WifiCredentialStore.h`](src/WifiCredentialStore.h)):
- Persistent storage in `/sd/.crosspoint/wifi.bin`
- XOR obfuscation for stored passwords (basic protection against casual
reading)
- Up to 8 saved networks with add/remove/update operations
- **On-Screen Keyboard**
([`OnScreenKeyboard.cpp`](src/screens/OnScreenKeyboard.cpp),
[`OnScreenKeyboard.h`](src/screens/OnScreenKeyboard.h)):
- Reusable QWERTY keyboard component with shift support
- Special keys: Shift, Space, Backspace, Done
- Support for password masking mode
- **Settings Screen Integration**
([`SettingsScreen.h`](src/screens/SettingsScreen.h)):
- Added WiFi action to navigate to the new WiFi screen
- **Documentation** ([`docs/webserver.md`](docs/webserver.md)):
- Comprehensive user guide covering WiFi setup, web interface usage,
file management, troubleshooting, and security notes
- See this for more screenshots!
- Working "displays the right way in GitHub" on my repo:
https://github.com/olearycrew/crosspoint-reader/blob/feature/connect-to-wifi/docs/webserver.md
**Video demo**
https://github.com/user-attachments/assets/283e32dc-2d9f-4ae2-848e-01f41166a731
## Additional Context
- **Security considerations**: The web server has no
authentication—anyone on the same WiFi network can access files. This is
documented as a limitation, recommending use only on trusted private
networks. Password obfuscation in the credential store is XOR-based, not
cryptographically secure.
- **Memory implications**: The web server and WiFi stack consume
significant memory. The implementation properly cleans up (stops server,
disconnects WiFi, sets `WIFI_OFF` mode) when exiting the WiFi screen to
free resources.
- **Async operations**: Network scanning and connection use async
patterns with FreeRTOS tasks to prevent blocking the UI. The display
task handles rendering on a dedicated thread with mutex protection.
- **Browser compatibility**: The web interface uses standard
HTML5/CSS3/JavaScript and is tested to work with all modern browsers on
desktop and mobile.
---------
Co-authored-by: Dave Allie <dave@daveallie.com>
|