Keep firmware artifacts tied to the hardware profile and record the checks performed when reviewing a release.
Update from the display
- Open Settings > Wi-Fi and connect to a network. The keyboard supports hidden SSIDs and password entry.
- Open Settings > Firmware updates and check for a release.
- Review the available version, confirm installation and keep the display powered.
- Restart when the verified image is ready.
The public release feed is techfoundrynz/wheelie_fun_display. A release needs the matching environment-named image and GitHub SHA256 digest. Missing releases or incompatible images are reported without replacing the installed firmware.
Installation pauses vehicle communications. A phone owning the proxy conversation blocks maintenance until it disconnects. Certificate-verified HTTPS and image validation protect the download; this is not a separate signed-firmware/secure-boot scheme.
Release artifacts
Build the supported environments before packaging:
pio run
python scripts/check_sdkconfig.py --all
python scripts/package_release.py
Packaging writes .pio/releases/<environment>.bin and manifest.json. The supported list comes from default_envs; removed board images are not carried forward. The release workflow injects the tag version using BIKE_FIRMWARE_VERSION and builds that same supported list.
Review the version, board identity, sizes and hashes before publishing. App slots are 7 MiB each. A newly booted image is accepted only after initialization and ten seconds of a functioning UI loop; an early failure leaves rollback available.
Diagnose before resetting
About > Diagnostics provides version/build identity, uptime, memory, display work timings and connection information. Save the serial log and describe the action that caused an issue. Panel work timings are not the same as measured delivered FPS.
NVS contains preferences, saved associations, bonds, Wi-Fi details and PIN state. Do not erase it as routine troubleshooting; that changes the user's setup and makes a problem harder to reproduce.
Hardware acceptance
A successful build and simulator check do not establish radio or wired interoperability. For a release, record the exact board, controller firmware and phone/app used, then exercise:
- Cold boot, both orientations, corner-safe layout and touch alignment.
- Settings scrolling, PIN entry, locked timeout and wake-contact consumption.
- Disconnect/reconnect, upstream encrypted pairing and changed/removed local PINs.
- CAN/UART operation with the actual transceiver/wiring and controller discovery.
- Phone proxy behavior, CAN forwarding, MTU differences, sustained traffic and lease release.
- Wi-Fi/OTA success, failure, cancellation and first-boot acceptance.
Track remaining hardware work in TODO. Record repeatable performance measurements in performance notes; a startup sample does not establish a sustained frame rate.
Documentation and Pages
CI builds the browser simulator, renders documentation pictures from that current shared Slint UI, then assembles and tests the site. Screenshots are generated artifacts under .cache/pages/docs-images; do not check them in or regenerate them before committing.
To reproduce the complete Pages build locally:
python -m pip install -r requirements-docs.txt -r simulator/requirements-browser-test.txt
python -m playwright install chromium
python scripts/build_web_simulator.py --output .cache/pages/site/simulator
python scripts/generate_docs_screenshots.py --site .cache/pages/site
python scripts/build_docs.py --output .cache/pages/site
python tests/simulator_browser_test.py --site .cache/pages/site
python scripts/package_browser_results.py --site .cache/pages/site
python tests/docs_browser_test.py --site .cache/pages/site
The interactive simulator is the clean end-user preview. The separate CI browser evidence gallery contains touchscreen checks and their captured images. Browser checks cover root and project-subpath hosting, navigation, search, touch, rotation, PIN entry, telemetry and responsive layout. Screenshots support visual review; they are not pixel-baseline comparisons or real-device acceptance.
Preview the generated site through a local HTTP server. Both the downloadable site artifact and GitHub Pages include the simulator and separate CI gallery. Generated HTML and screenshots are build outputs, not a second hand-edited copy of the source.