Easyduino keeps KiCad versions of popular devboards in one repository

One folder per devboard, collected to fix a fragmented supply of design files

Easyduino exists because the design files for popular microcontroller boards are scattered across different tools, companies and years. The README makes this point with concrete examples: the Arduino Uno was developed in 2010 in Italy using Eagle, the ESP32 devboard was developed in 2016 in China using Altium, and the Raspberry Pi Pico 2040 followed around 2021 in the United Kingdom using KiCad and Altium. That mix of formats and conventions is the real problem being solved. A student or hobbyist who wants to understand why a pin is routed the way it is on a Pico would otherwise need tools for three different ecosystems, and the original files are rarely offered in a form that opens in current software.

The answer here is to rewrite each board in KiCad, which the README describes as free and open source software, and to follow the best practices used across the PCB and KiCad ecosystem. The repository is laid out as one directory per board, which means the top level lists the board families directly: an Atmega328p Arduino Nano folder, an Atmega328p Arduino Uno folder, ESP32, ESP32S3, Raspberry Pi Pico 2040 and STM32F103 Bluepill. Three further boards are linked from the README but are not present as top level entries, the Pi Pico 2, the Pi Pico 2 2354B and an nrf52840 dongle. The README marks all three with the same in progress miniature image, which is a fair signal that they are designs in flight rather than finished products.

So the audience is people who read schematics: students learning a board, educators who need a board they can rebuild, and engineers who want a permissive starting point for a derived design. This is not a software project and there is nothing to install beyond the CAD tool.

Four copper layers across every board on the JLC04161H-7628 stackup

Every project in the collection uses four layers of copper. The README gives the reason plainly, to simplify the wiring and improve overall signal integrity, since the additional layers provide better reference planes, lower return path impedance, reduced crosstalk and improved high frequency performance. The stackup named is JLC04161H-7628 from JLCPCB.

That decision matters more than it first appears, because it ties the design work to a specific fab house. The manufacturer constraints of JLCPCB are not left implicit; they are documented in a separate Assets/JLCPCB Constraints directory that the README links directly, including a section on the CPL component placement list. Choosing a stackup and a fab means the impedance targets, minimum trace widths and via rules in the KiCad files correspond to a real production process rather than to generic defaults. If you intend to build these boards somewhere other than JLCPCB, you would be carrying over constraints that were not designed for your chosen line.

The four layer approach also explains why the boards are not a single merged design. Each is a separate KiCad project with its own outputs, its own BOM and its own centroid file, all generated from a KiCad jobset and then copied into a ProductionFiles folder. Keeping them independent means a change to one board does not disturb another, but it also means there is no shared library across the whole repository and no single place where a footprint update propagates. The non standard footprints for a given board live inside that board's own xxx.pretty or xxxlibraries folder.

The substitutions the README admits to, especially on the UNO and the Pico

The README is unusually direct about where these boards differ from the products they imitate. It says the outline, pinout, layout and components have been tried to be replicated with respect to the originals, in all of the boards, and adds that this was done with various levels of success. Two specific compromises are called out.

The first concerns the Raspberry Pi Pico, which uses 01005 components that the README describes as too expensive for the manufacturer to integrate in the PCB assembly line. The second concerns the original Arduino UNO USB to serial converter, an Atmega16u2, which was hard to come by around January 2023, so more readily available options were chosen instead. That last detail is not a footnote. An Atmega16u2 handles USB communication and can serve as a second serial port, so swapping it changes the programming interface and can remove the native USB port behaviour that some sketches and bootloaders rely on.

The project's answer to this problem is documentation rather than silence. Each board folder contains a readme explaining the specifics of that project, and the README states that all the differences with the original boards are explained inside the folder of each project in a readme file. Anyone ordering boards on the assumption of drop in equivalence with a commercial part is therefore working from a false premise, and the per board readme is the document to read before committing to a design.

Getting the files and opening a .kicad_pro in KiCad

There is no installation script and no package manager entry. The path in is KiCad itself, followed by a download of the repository. The README gives the sequence in three steps, and they read like this in the original text:

1. Install the latest version of [KiCad](https://www.kicad.org/)
2. If you already have KiCad installed, click the upper right button in this github page `<>Code`, click `Download ZIP`, extract the files in your desired folder. If you know how to use git, clone the repository
3. Double click on the xxx.kicad_pro file inside any project and KiCad will start

Two details in that sequence matter for a first session. The file you double click is the project file, and each project directory contains the main KiCad files such as .kicad_pro and .kicad_sch, so opening the project rather than a loose schematic pulls in the board settings that go with it. Second, the README states that the project was developed using KiCad v8.0.0 but has been updated and tested with KiCad v10, including the creation of jobsets, which it credits with greatly simplifying the creation of gerbers and BOMs. If your installation is older than v10, the jobset outputs will not regenerate the way the author expects.

There is a second, lighter path for readers who do not want to open the CAD tool at all. The README points to the schematics and the gerbers inside the ProductionFiles folder of each project, under the PDFs and Gerber folders, so a stack up check or a manufacturing review can be done from the archive alone.

ProductionFiles already holds what a fab order needs

The structure of each project is consistent enough to describe from memory after one board, and it is worth internalising because it separates the editable source from the orderable output. The README lists the parts of a project this way:

- Main KiCad files (.kicad_pro, .kicad_sch...)
- A readme explaining the specifics of that project
- xxx.pretty or xxxlibraries folder which contains the non standard footprints or schematic parts used in the project (Some projects such as the Arduino UNO only use standard libraries, therefore these folders don't exist)

Alongside those sit an Outputs folder and a ProductionFiles folder. The Outputs folder holds everything produced by the KiCad jobset, including gerbers, STEP files, PDFs, ERC results, the BOM and the CPLs, and those are then copied and organised into the ProductionFiles folder. Inside ProductionFiles the README describes a BOM folder containing both the component list and the centroid file in JLCPCB readable format, a Datasheets folder with the datasheets of the main components, a Gerbers folder holding a zip of the manufacturing files such as copper, mask and silkscreen layers, a PDFs folder with the schematic and PCB as PDF and PNG, and a Photos folder with photographs of the manufactured boards and some renders.

One practical wrinkle is flagged: the CPL .csv file needs a small tweak at the beginning of the file in order to be readable, and the README links to the relevant section of the JLCPCB Constraints notes. Datasheets for resistors, capacitors and LEDs are deliberately omitted as easily replaceable parts.

KiCad v10 jobsets help, but the git utilities do not handle a collection of projects

The tooling story is mixed, and the README says so without hedging. On the generation side, KiCad v10 jobset support is a clear win, because a single jobset produces the gerbers, the BOM and the placement lists for a board, and the outputs of that jobset are what populate the ProductionFiles folders described above. On the version control side the same release introduces friction. The README states that since this is a collection of projects, the new KiCad v10 git utilities do not work properly with each project, forcing you to git add the whole project if you want to make a change.

That is a workflow constraint rather than a bug in the designs, but it changes how a contributor works. You cannot stage a single schematic symbol edit in isolation and rely on the project tooling to isolate it; you stage the project as a unit. For a fork that is fine, since the projects are already separated by folder. For a large team wanting to track a single board across many commits, it is friction that has to be planned around.

Contributions are handled in a simple way, per the README: if you spot mistakes inside any of the projects, open an issue and the author will try to correct it. There is no documented pull request template, review process or test policy, and no automated checks are described.

What the licence and the push history say about upkeep

The repository is published under CERN-OHL-P-2.0, with the licence text stored as a License.txt file at the top level of the repository. That is a hardware licence rather than a software licence, and it is the usual choice for open hardware, where it aims to keep derivative board designs open rather than closing them. This is a licensing fact, not advice, and anyone using these designs commercially should read the licence text and the per board documentation themselves.

On maintenance, the repository is not archived and the last push was on 2026-06-28. The repository has no GitHub releases, so there is no versioned release stream to upgrade through and no changelog to consult. There is also no indication in the documentation of a KiCad version support policy beyond the note that the files were developed with KiCad v8.0.0 and updated and tested with KiCad v10, which means the compatibility statement is a point in time fact rather than a promise.

The absence of releases has a practical consequence for anyone automating a build. You cannot pin to a tagged release of a specific board, so a fork or a local snapshot of the repository is the only stable reference, and any change in the default branch lands silently.

Where a stock devboard is the better answer

The honest comparison is with buying a mass produced board from a distributor, and on price, warranty and time to first working firmware the stock product wins by a wide margin. A retail Arduino Uno or Pico arrives assembled, tested and covered by seller support. Easyduino gives you source files for a board you would have to order, assemble and debug yourself, at the price of four layers of fabrication.

The comparison in the other direction is about control. If you need to change a connector, add a mounting hole, move a test point or reproduce a board that the original manufacturer no longer sells, the design files are the whole point. USB-C is a good example of what changes here, since the README presents adding the much needed USB-C support as a goal of the project rather than a footnote.

The alternative approach to writing a board from scratch is not a competitor product but a different habit: start from a design the original vendor already published in an open format, or design only the portion of the board you actually need to change on top of a purchased module. The cost of that habit is that you inherit the original board's exact quirks, including the Atmega16u2 arrangement on the UNO that Easyduino replaced for availability reasons. Neither path is universally right. What separates them is whether the constraint you care about is getting a working prototype quickly or owning a design you are free to modify and reproduce.

Editorial conclusion

Easyduino is worth adopting if you plan to spin these specific boards yourself and want a starting schematic rather than a blank file. It is the wrong tool if you need a board it does not cover, or if you expect the layouts to match a stock product exactly, since the README documents deliberate substitutions such as a different USB to serial converter on the UNO. Before ordering, open the .kicad_pro of the board you want, check the per project readme for the differences listed there, and confirm the CPL .csv header tweak described in the JLCPCB Constraints notes.

Frequently asked questions

Official sources

1. Hanqaqa/Easyduino on GitHub
2. Issues
3. License: CERN-OHL-P-2.0
4. README