The ZEReader Project - Adopting Agile and Software-First Methods in Open Hardware

The ZEReader project is an open-source E-Reader that originated as an electrical engineering thesis. As a hobbyist project, it faces the typical rigidity of hardware iteration. To manage this, I applied an agile, software-first methodology, leveraging my background as an embedded systems developer. Instead of writing drivers for fixed hardware, I utilized the Zephyr driver ecosystem to let software requirements define component choices. This inverted approach enabled rapid proof-of-concept testing before committing to physical designs.

To support iteration, the hardware design tries to maximize modularization, which limits errors to specific components and simplifies board bring-up and debugging. Furthermore, the project improves traceability using Git-based version control and CI concepts to match generated documentation to specific physical PCB revisions. The goal is to share practical learnings on how software methods can support lower-risk iteration and where technical friction remains for individual contributors.

Hardware development for individual enthusiasts is fundamentally constrained by the high cost and logistical friction associated with physical iteration. This talk presents the ZEReader project—an open-source E-Reader—as a practical case study for how a single developer can mitigate these issues by applying principles borrowed directly from modern, agile software development.

The ZEReader originated as an electrical engineering bachelor’s thesis. As an embedded systems developer, my goal was not just to build an E-Reader, but to design a workflow that successfully manages the development process. The core innovation was inverting the traditional hardware-first approach. Instead of committing to fixed hardware and then spending limited time developing low-level drivers, I prioritized the software stack. I leveraged the Zephyr Real-Time Operating System (RTOS), specifically its comprehensive and hardware-agnostic driver ecosystem. This allowed the software requirements to define the minimal viable hardware needed for prototyping, dramatically reducing the time spent on low-level abstraction and enabling a rapid proof-of-concept phase.

Strategies for Agile Hardware

To support this rapid, software-driven iteration, two core structural and procedural strategies were implemented:

Modularization for Risk Management and Debugging: The ZEReader hardware was designed using a modular approach as much as possible, treating functional blocks (such as the display controller, power management unit, and microcontroller) as semi-independent boards or breakout sections. It simplifies the complex task of board bring-up, allowing subsystems to be tested and verified in isolation. Ideally, it would also apply to the PCB designing process: in the event of a design flaw, the failure would be contained to a small, isolated module, which minimizes the scope of required redesign. This effectively translates the software principle of decoupling into a physical hardware architecture. Nevertheless, this approach is right now limited applicable for a hobbyist project due to round-trip times and cost.

Traceability and CI Concepts for Documentation: A major limitation in Open Hardware is the difficulty in matching physical objects (PCBs) and generated files (Gerbers, BOMs) to their corresponding design stage. The ZEReader project attempts to implement robust traceability by using Git-based version control to explicitly tag and link design documentation (schematics, layout exports) to specific, verified physical PCB revisions. I will demonstrate how light-weight Continuous Integration (CI) concepts—typically used for compiling code—were adapted to automate the generation and version stamping of documentation, ensuring that the project’s documentation remains synchronized with its physical state.

Practical Limitations and Technical Friction

While these software-centric methods provided significant advantages, the talk will conclude with an honest appraisal of the remaining friction points. Specifically, I will discuss the practical limitations encountered within applications like KiCad. While powerful for design, it still lacks robust, integrated features necessary for true version merging, comprehensive automation of design rule checks in a CI pipeline, and built-in support for modularization best practices. While some of these issues will be addressed in the upcoming KiCad version, sharing these current limitations is crucial for identifying areas where the Open Hardware community can focus future development efforts.

The session will share these practical learnings and offer concrete methods for individual developers looking to manage risk and increase their iteration speed in their own hardware projects.

Hardware development for individual enthusiasts is fundamentally constrained by the inherent rigidity and logistical friction associated with physical iteration. This talk presents the ZEReader project—an open-source E-Reader—as a practical case study demonstrating how a single developer can mitigate these issues by applying principles borrowed directly from modern, agile software development.

The ZEReader originated as an electrical engineering bachelor’s thesis. As an embedded systems developer, my primary goal was to design a manageable workflow, not merely complete the hardware. The core innovation was inverting the traditional hardware-first approach. Instead of committing to fixed hardware and spending limited time developing low-level drivers, I prioritized the software stack. I leveraged the Zephyr Real-Time Operating System (RTOS), specifically its comprehensive and hardware-agnostic driver ecosystem. This strategy allowed the software requirements to define the minimal viable hardware needed for prototyping, dramatically reducing the time spent on low-level abstraction and enabling a rapid proof-of-concept phase before committing to complex PCB designs.

Strategies for Agile Hardware and their Limitations

To sustain this software-driven, rapid iteration, two core structural and procedural strategies were implemented and will be detailed in the talk:

• Modularization for Error Isolation and Debugging: The ZEReader hardware was designed to maximize modularity, treating functional blocks (such as the display controller, power management unit, and microcontroller) as semi-independent sections. This strategy simplifies the complex task of board bring-up, allowing subsystems to be tested and verified in isolation. Critically, this design intends to isolate errors: in the event of a design flaw, the failure is contained to a small module, minimizing the scope of required redesign. However, this ideal is limited in hobbyist projects due to the round-trip times and costs associated with manufacturing multiple smaller boards compared to a single monolithic one. This illustrates a key challenge in translating the software principle of decoupling into physical hardware architecture.

• Traceability and CI Concepts for Documentation: A major limitation in Open Hardware is the difficulty in matching physical objects (PCBs) and generated files (Gerbers, BOMs) to their corresponding design stage. The ZEReader project attempts to implement robust traceability by using Git-based version control to explicitly tag and link design documentation (schematics, layout exports) to specific, verified physical PCB revisions. I will demonstrate how light-weight Continuous Integration (CI) concepts—typically used for compiling code—were adapted to automate the generation and version stamping of documentation, ensuring the project’s documentation remains synchronized with its physical state.

Practial Limitations and Technical Friction

While these software-centric methods provided significant advantages, the talk will conclude with an honest appraisal of the remaining friction points. Specifically, I will discuss the practical limitations encountered within applications like KiCad. While powerful for design, it still lacks robust, integrated features necessary for true version merging, comprehensive automation of design rule checks in a CI pipeline, and built-in support for modularization best practices across different file types. While some of these issues may be addressed in upcoming software versions, sharing these current tool limitations is crucial for identifying areas where the Open Hardware community and developers can focus future efforts.

The session will share these practical learnings and offer concrete methods for individual developers looking to manage risk and increase their iteration speed in their own hardware projects.

Presented at

• Open Hardware Summit, Berlin

Download slides