ESP-IDF target
The hardware build stays reproducible in CI so firmware changes do not silently break the ESP32-S3 target while UI logic evolves.
BUILD
From parts to a real reader.
This page tracks the practical ENKU build path without pretending the physical prototype is already finished. Software and interface work can be reproduced today; enclosure dimensions, battery fit and final assembly details will be locked only after the reference board is physically validated.
AVAILABLE NOWSource + design
Firmware architecture, host-tested behavior, design references and project documentation are versioned in GitHub.
REFERENCE HARDWAREWaveshare 3.97″
The project targets the ESP32-S3 e-Paper 3.97″ board with an 800 × 480 monochrome panel.
PHYSICAL VALIDATIONPrototype pending
Battery choice, enclosure tolerances and final assembly instructions remain intentionally provisional until hands-on testing.
01 · BOM
Start with the smallest useful stack.
ENKU is being developed around ready-made modules first. The goal is a reproducible low-cost reader before any custom PCB work. Items below distinguish the reference platform from parts that still depend on the physical prototype.
COREWaveshare ESP32-S3 e-Paper 3.97″
ESP32-S3, 800 × 480 e-paper, wireless connectivity and the project’s reference I/O in one board.
REFERENCESTORAGEmicroSD card
Used for books and local content. Exact card capacity is not a firmware requirement.
SUPPORTEDPOWERLi-Po battery
Final capacity and physical dimensions will be chosen after real enclosure measurements and power testing.
PENDING FITCONTROLPhysical buttons / rotary input
Navigation is non-touch by design. The exact mechanical layout follows the reference control scheme and enclosure.
PROTOTYPEENCLOSURE3D-printed shell + M2 hardware
Designed to remain printable and serviceable. Final tolerances wait for board, battery and button measurements.
IN PROGRESS02 · PREPARATION
Validate before closing the case.
Bring up the electronics on the bench first. A working display, storage path, controls and power behavior are easier to diagnose before they are constrained by the enclosure.
Inspect the board
PHYSICAL CHECK
Confirm the delivered board revision, included accessories and connector placement against the reference documentation.
Prepare storage
SOFTWARE PATH DEFINED
Use a known-good microSD card and a small test library. Keep the first bring-up minimal so storage failures are obvious.
Flash a clean build
CI COVERED
Build from the current repository state rather than an old binary. Host tests and ESP-IDF builds are used to catch regressions before hardware testing.
Bench-test input
HARDWARE VALIDATION
Check directional navigation, confirm/back behavior and the first-start flow before committing to final button geometry.
03 · ENCLOSURE
Dimension from reality, not a render.
The enclosure is deliberately downstream of the electronics. CAD should reflect measured board outlines, connector clearances, battery thickness, button travel and practical print tolerances.
Measure the reference stack
AFTER DELIVERY
Record the real PCB, display, connector and control geometry. Vendor drawings are a starting point, not the final mechanical truth.
Lock service access
PROTOTYPE RULE
Keep charging, power switching and assembly screws accessible without forcing the display or battery out of the shell.
Print and revise
ITERATIVE
The first case is a fit test. Button feel, bezel spacing, panel support and back-cover retention are expected to change before release files are marked stable.
Release rule: enclosure files will only be presented as production-ready after a real print has been assembled, opened again and used long enough to expose fit and access problems.
04 · FIRMWARE
Build software independently of the shell.
ENKU firmware is developed as a real product surface, not a late hardware demo. Search, reader overlays, typography state, navigation rules and other behavior are exercised in host tests before they reach the device.
Host behavior
Logic that does not require the physical display is tested on the host, keeping navigation and reader behavior faster to iterate.
Library + reader
Core reading flows are implemented around local content, persistent state and a predictable physical-navigation model.
Refresh discipline
Hardware bring-up will validate partial/full refresh behavior, ghosting and timing against the interaction rules defined in Design.
05 · ASSEMBLY
Only freeze what has been tested.
The final assembly order will be published after the first complete device is built. Until then, the sequence below is the intended engineering path rather than a claim that every tolerance has already been verified.
Fit controls and switch
PROTOTYPE
Install physical controls first so travel and alignment can be checked before the board and battery restrict access.
Seat the display board
PROTOTYPE
Support the PCB without loading the e-paper glass. Confirm port and microSD access before fastening the shell.
Install the battery
CAPACITY TBD
Use the battery geometry validated for the enclosure; avoid compressing the cell or routing wiring across sharp printed edges.
Close, reopen, inspect
RELEASE GATE
A successful first closure is not enough. The design must survive service access and reassembly before instructions are finalized.
06 · FIRST BOOT
Verify the reader, not just the screen.
A useful first boot checks the complete path from power-up to reading. The exact hardware checklist will grow as measurements from the first assembled prototype arrive.
Power + display
Confirm stable startup, correct panel orientation and a clean initial refresh without unexpected resets.
Controls
Walk through first start, Library navigation, Back behavior and reader overlays using only the intended physical inputs.
Storage
Load a test title from microSD, reopen it and verify that the reading position and settings persist as expected.
Power behavior
Validate sleep, wake and hard power-off behavior before measuring realistic battery life.
FOLLOW THE BUILD
The instructions evolve with the prototype.
Build stays the stable entry point; the engineering log records what changed, what failed and what became verified as the physical reader comes together.