Evereader: An Open-Source Dual-Screen E-Book Reader Built by a High School Graduate

A High School Graduate's Open-Source Hardware Dream

In the world of hardware development, the first PCB from scratch is always fraught with uncertainty. Recently, a developer named Ezekiel, fresh out of high school, posted on Reddit seeking community help to review the schematic and PCB design of his e-book project — Evereader.

The project has an ambitious goal: to build a dual-screen, fully open-source, portable, and customizable e-book reader. For someone whose prior electronics experience was limited to "lighting up an LED" and who was using KiCad for the first time, this is undeniably a bold starting point.

KiCad is a free and open-source electronic design automation (EDA) software suite, created by Jean-Pierre Charras of CERN (the European Organization for Nuclear Research) in France in 1992, and has received significant funding and promotion from CERN since 2013. It includes a complete toolchain with a schematic editor, PCB layout editor, 3D viewer, and Gerber file generator. Unlike commercial EDA software (such as Altium Designer, which costs around $10,000/year), KiCad is completely free with no board size or layer count limitations, making it the tool of choice for independent developers, students, and open-source hardware projects. KiCad 7.0, released in 2023, brought significant improvements in interactive routing and design rule checking, but the learning curve remains relatively steep for beginners, particularly in component library management and footprint creation.

The more pressing challenge is cost — the author candidly admits that as a recent graduate without a job, he can't afford multiple prototyping runs, and hopes to get experienced eyes on the design before ordering fabrication. This "get it right the first time" pressure is a challenge shared by many independent hardware developers.

Evereader Technical Breakdown

Core Architecture: ESP32-S3 MCU

Based on the information disclosed by the author, Evereader uses the ESP32-S3 as its main controller. This is a quite reasonable choice — the ESP32-S3 offers dual-core processing capability, rich peripheral interfaces, and native USB support, along with an active open-source community ecosystem, making it well-suited for this kind of DIY e-book project.

The ESP32-S3 is a high-performance MCU-WiFi-Bluetooth integrated chip released by Espressif Systems in late 2020. Compared to the previous-generation ESP32, the S3 version's biggest upgrades are the addition of vector instruction extensions (for AI inference acceleration) and native USB OTG support, meaning developers can communicate with PCs and flash firmware without additional USB-to-serial chips (such as CP2102 or CH340). Its dual-core Xtensa LX7 processor runs at up to 240MHz, and with up to 512KB SRAM plus external PSRAM support, it's more than capable of handling image decoding and rendering tasks for e-ink displays. In the open-source community, the ESP32-S3 has been widely used in e-paper projects (such as the LilyGo T5 series), portable game consoles, and IoT gateways, with two mature development frameworks available: ESP-IDF and Arduino.

Dual E-Ink Display Solution

The display section uses two WeAct 4.2-inch e-ink screens sourced from AliExpress. WeAct Studio also provides open-source e-paper module documentation, which serves as a reference foundation for the project's dual-screen design. Dual-screen designs are uncommon in the e-book space, but if implemented well, they can deliver a reading experience similar to turning pages in a real book.

E-ink displays (E-Paper/E-Ink) are based on electrophoretic display technology. The core principle involves encapsulating positively and negatively charged black and white particles in microcapsules, and controlling particle migration through applied electric fields to display images. Unlike LCDs, e-ink displays only consume power during refresh and draw virtually zero power for static display, making them ideal for e-book readers. WeAct Studio's 4.2-inch modules typically communicate via SPI interface, with a resolution of 400×300 pixels and refresh times of approximately 2-4 seconds (full refresh) or hundreds of milliseconds (partial refresh). The main technical challenges of a dual-screen design include: when two screens share an SPI bus, independent chip select (CS) signals are needed for time-division control; simultaneous refresh can result in instantaneous currents of 40-80mA×2, placing higher demands on power design; additionally, the BUSY signals from both screens need to be monitored separately to ensure refresh timing doesn't conflict.

Power and Charging Management Circuit

The project put considerable thought into power design, implementing charging and flashing through a single USB-C port. The specific power chain includes:

• TP4065: Lithium battery charge management IC
• FS8205A + DW01A: A classic battery protection combination responsible for overcharge, over-discharge, and overcurrent protection
• AP2122K-3.3: LDO voltage regulator, converting voltage to a unified 3.3V

This combination of TP4056-type charging + DW01A/FS8205A protection + LDO step-down is a common solution for lithium battery-powered portable devices, indicating that the author has done his homework on power architecture and the approach is sound.

Regarding the technical details of the battery protection scheme: DW01A is a single-cell lithium battery protection IC that monitors battery voltage and charge/discharge current in real-time. When it detects overcharge (typically >4.3V), over-discharge (typically <2.4V), overcurrent, or short circuit conditions, it cuts off the charge or discharge path by controlling external MOSFETs. The FS8205A comes in a TSSOP-8 package containing two N-channel MOSFETs that separately control the charge and discharge paths, with an on-resistance of only about 25mΩ for minimal power loss. This combination costs less than 1 CNY yet effectively prevents lithium batteries from swelling or catching fire due to abuse. In PCB layout, the DW01A and FS8205A should be placed as close to the battery connector as possible, and trace widths for high-current paths should be sufficient (recommended ≥0.5mm), otherwise line impedance could cause protection threshold drift.

Notable PCB Design Details

Distinguishing Logical Connections from Physical Routing

The author specifically pointed out a design detail that could be easily misunderstood: the connections between J6 and J6, and between J5 and J8, are only logical "shared nets" — on the actual PCB they should remain disconnected and be physically connected via JST ribbon cables.

This is an important concept in hardware design. Sharing the same net between two connectors in a schematic conveniently expresses signal relationships, but in actual PCB layout, such cross-board connections need to be completed through external cables rather than on-board traces. Being aware of this shows that the author has a certain understanding of the mapping relationship between schematics and PCB.

In EDA tools like KiCad, if two connectors are assigned to the same net, DRC (Design Rule Check) will by default require them to be connected through copper traces on the PCB, otherwise it will report an "unconnected" error. Common approaches for handling cross-board connections include: defining each pair of connectors on different nets and using text annotations in the schematic to explain their physical connection relationship; or using KiCad's "no-check" flags to suppress related DRC warnings.

Firmware Serves Only as Pin Reference

The author explicitly states that the firmware in the repository is "far from started" and currently serves only as a pinout reference. This is a pragmatic approach — during the hardware design phase, firmware completeness isn't important; what matters is ensuring pin assignments match hardware connections to avoid software-hardware mismatches later on.

Common Risks and Checklist for First-Time PCB Designers

While the author's overall approach is clear, for first-time PCB designers, the following categories of issues are common causes of "first prototype failure" and warrant careful review before ordering:

Power Integrity Issues

Are the input/output capacitors for the LDO (AP2122K) properly selected? E-ink screens draw significant transient current during refresh — is the 3.3V supply load capacity sufficient? Peak power consumption during simultaneous dual-screen refresh needs careful calculation, otherwise system resets during screen refresh may occur.

The AP2122K-3.3 is a low-dropout linear regulator (LDO) with a maximum output current of 600mA and a typical dropout voltage of about 200mV. For lithium battery (3.7V nominal, approximately 3.3V at end of discharge) powered scenarios, when battery voltage drops close to 3.5V, the LDO's headroom becomes very small. If simultaneous dual-screen refresh causes instantaneous current to exceed the LDO's load capacity at this point, the output voltage will sag and potentially trigger the ESP32-S3's brownout detection (BOD) reset. One possible improvement is to use a DC-DC switching buck converter instead of an LDO for higher efficiency and wider input voltage range, though this would increase design complexity and PCB area.

E-Ink Display Driving Voltage Requirements

E-ink screens typically require multiple voltage rails (such as +15V/-15V), and some modules have built-in boost circuits while others require external supply. The author needs to confirm whether the WeAct modules include complete driving power, otherwise 3.3V alone cannot properly drive e-ink display output. This is the most easily overlooked pitfall in dual-screen designs.

The driving principle of e-ink displays dictates that relatively high voltages are needed to move charged particles within microcapsules. Typical E-Ink drivers (such as SSD1619, UC8176, etc.) require VGH/VGL (Gate high/low voltage, typically ±15V to ±22V) and VSH/VSL (Source high/low voltage) among other voltage rails. Fortunately, most finished e-paper modules (including WeAct's products) integrate boost converters and charge pumps on the FPC interface board, so users only need to provide 3.3V logic power and VCC supply. However, developers should still verify this by reviewing the module schematic, and note that the boost circuit's operation will introduce switching noise on the 3.3V supply line, potentially affecting the ESP32-S3's analog peripherals (such as ADC used for battery voltage detection).

USB-C and ESP32-S3 Flash Circuit

Implementing both charging and flashing through a single port requires proper handling of USB data line connections to the ESP32-S3, CC resistor configuration, and isolation between the charging current path and data communication. If this part of the design is incorrect, it could result in inability to flash firmware or charging anomalies.

The USB Type-C interface specification requires specific resistance values on CC (Configuration Channel) pins to identify device roles and power delivery capabilities. For Evereader's design as a device end (UFP/Sink), each CC pin needs a 5.1kΩ pull-down resistor to ground, which tells the host "this is a device that needs to be powered." Since the ESP32-S3 has a built-in USB controller, D+/D- data lines can be directly connected to the chip's GPIO19 (D-) and GPIO20 (D+) pins without external USB-to-serial chips. However, note that USB 2.0 signals have trace impedance requirements (differential impedance 90Ω±10%), and D+/D- traces should maintain equal length and avoid vias or discontinuities. Additionally, when USB is connected to a PC, the charging IC (TP4065) programming resistor should limit charging current to under 500mA (standard USB 2.0 port rating), otherwise it may trigger the host's overcurrent protection and disconnect the USB connection.

Footprint and Silkscreen Verification

For beginners, mismatches between component footprints and actually purchased components are the most common cause of "failure." It's recommended to verify each component's footprint, pin order, and polarity markings one by one.

Specific verification methods include: comparing 3D models in KiCad against package dimension drawings in supplier datasheets; paying special attention to IC pin 1 marker orientation, polarity component (capacitor, diode, LED) positive/negative markings, and connector insertion direction. A practical tip is to print the PCB at 1:1 scale on paper, then place actual components on the paper to compare pad positions. For fine-pitch packages like QFP and QFN, even a 0.1mm deviation can cause solder bridges or cold joints.

The Collaborative Value of the Open-Source Hardware Community

Ezekiel's help post reflects the core spirit of open-source hardware culture — reducing trial-and-error costs through community collaboration. For a young developer with limited budget and limited experience, making the design public and seeking peer review is far wiser than working in isolation and spending money on failed prototypes.

The open-source hardware movement can be traced back to the birth of the Arduino project in 2005, followed by OSHWA (Open Source Hardware Association) publishing the Open Source Hardware Definition in 2010. Under this philosophy, design files (schematics, PCB layouts, BOM lists) are released under open licenses, allowing anyone to learn from, modify, and manufacture them. GitHub has become the primary hosting platform for open-source hardware projects, and combined with low-cost PCB manufacturing services like JLCPCB and PCBWay (5 double-layer boards starting at just $2), the barrier to hardware innovation for independent developers has been dramatically lowered. Reddit subreddits like r/PrintedCircuitBoard and r/AskElectronics have also formed active design review communities where experienced engineers voluntarily provide free reviews for beginner projects.

The project is open-sourced on GitHub (Ezekiel0108/Evereader), and any experienced engineer can step in to review. This open attitude not only improves the project's chances of success but also makes the entire design process itself a valuable learning resource.

For readers who are also at the hardware beginner stage, this case offers several insights:

• Start with proven reference designs (such as ESP32-S3, TP4056-type charging solutions) as a foundation
• Make full use of community review resources before ordering prototypes
• Honestly label the project's completion status so reviewers can precisely locate issues

Conclusion

Evereader may still be just an unverified PCB, but it carries a young developer's passion and practical courage for open-source, portable e-books. Going from lighting up an LED to designing a complete board integrating charging, protection, and dual-screen driving is itself a significant growth leap.

Regardless of whether this board ultimately "lights up on the first try," the process of open design, seeking reviews, and iterative improvement is the essential path for hardware engineers' growth.