# Learn-Embedded-Systems: a checkable path from microcontroller to job > Learn Embedded Systems is a curriculum rather than a library, twenty modules across five phases that take you from what a microcontroller is to firmware you would be paid to write, with the same structure in every module, hands-on checkpoints on real boards, and a stated hardware budget of about sixty dollars. The repository is the source of a website with checkboxes that remember your progress, and the text is licensed CC BY-SA 4.0. **erinjense/Learn-Embedded-Systems** — Resources to learn embedded systems engineering. - Repository: https://github.com/erinjense/Learn-Embedded-Systems - Stars: 572 · Forks: 102 - Language: Python - License: CC-BY-SA-4.0 - Published: 2026-10-22 · Updated: 2026-10-22 · Language: en - Canonical page: https://hysenlabs.com/projects/erinjense-learn-embedded-systems ## A curriculum with checkboxes, not a list of links The project describes itself as resources to learn embedded systems engineering, and the README states its ambition in one line: a calm, checkable path from what is a microcontroller to job-ready embedded engineer. Free resources first, hands-on checkpoints in every module, and nothing you do not need. That last phrase is the differentiator. Most embedded learning material is either a book you must buy or a pile of links that assume you already know what you are looking for. This one is organised as a path with a stated order and a stated end point. The audience is explicit. High schoolers with a soldering iron, computer science students who have never touched a register, and working engineers switching into firmware. The README describes the shape as one path, three entry points, and a focus on getting into the industry rather than down a hobby rabbit hole, which is a good corrective to the way embedded hobbyism usually absorbs beginners. The first version was written by Erin Jense in 2020 as a personal reading list and, to the author's surprise, picked up a following. The 2026 edition keeps the checkbox spirit, drops what has gone stale, adds what the industry now expects, and reorganises everything so you always know where you are and what comes next. The changelog in the appendix records what changed and which links died, which is a rare and welcome thing to find in a learning repository. The primary language of the repository is Python, but only because the tooling that builds the site is Python. Nothing here is a program you import. ## The website is the product, the repository is the same content The README is emphatic that the website is the best way to use the guide. The site at erinjense.github.io/Learn-Embedded-Systems has clickable checkboxes that remember your progress, a progress overview, search, and dark mode. The repository holds the same content as plain Markdown, and the README says to read it there if you prefer, or to fork it and tick boxes in the files themselves. That fork instruction is the one to notice, because it is what makes the guide usable as a personal tracking system rather than a document you read once. The reason to build the site rather than ship a PDF is the same reason the project has a start-here page asking where do I start. A person arriving at a twenty module curriculum with no idea where to begin is the exact case the progress checkboxes address, and a static list of links does not solve it. The technical shape is MkDocs with the Material theme, and the requirements file lists exactly two dependencies: ```bash mkdocs>=1.6,<2 mkdocs-material>=9.6 ``` The mkdocs.yml file at the root configures the site, and the docs/ directory holds the content. The repository also has a hooks/ directory, which in MkDocs means the build can run Python at build time, and a tools/ directory, which holds the link checker described later. The result is a site that is generated from Markdown in a repository, with the same content in both places. That is a deliberate trade: the website is the better interface, and the repository is the better interface for anyone who wants to fork it, adapt it or track their own progress in it. ## The same five parts in every module The How it works section describes the module template, and it is the part that makes the guide a curriculum rather than a list of resources. Every module has the same five parts. Why this matters, which is a minute of framing. Learn, which is the two to five best resources, each with a type and a time estimate. Do, which is hands-on checkpoints on real hardware. Check yourself, which is a few questions. And go deeper, which is optional and collapsed. Two details carry weight. The learn section is capped at two to five resources, each with a type and a time estimate, so a reader can budget their time before committing, and a module cannot quietly grow into a reading list. And the do section is on real hardware rather than a simulator, which is the difference between a course that looks like engineering and one that is engineering. The check yourself questions are what make the path checkable. They are the point at which a reader finds out whether the module landed, and a guide that only points at resources has no way to tell. The project also has a stated position on AI, which is unusual to see written down. The stance is to learn each idea without it first, well enough to explain it to someone else, and then to use every tool you can find. Module 18, in the fifth phase, shows how professionals do that without losing the skill. It is a sensible position for a field where the vocabulary is the barrier, since a job interview will ask you to describe what your code does, and a tool that writes the code does not help with that. ## Five phases, twenty modules, four specializations The map in the README is the clearest description of the scope, and the phase structure is a curriculum design rather than a topic list. Phase 1, Foundations, is three modules: electronics, C for embedded, and a first board on the Pico 2, ending with the ability to read a schematic, write real C and blink an LED by writing a register. Phase 2, Core, is four modules covering how a microcontroller works under the hood, peripherals, communication, and the toolchain and build, ending at the point where you can drive every common peripheral and bus from the datasheet. Phase 3, Professional, moves to STM32 and covers firmware architecture and testing, using an RTOS on purpose, and debugging with real tools. Phase 4, Specializations, is six modules you pick from according to the job: low power, robustness against ESD, EMI and EFT, safety and security, embedded Linux, wireless, and signals, control and motors. Phase 5, Beyond, is three modules: using AI well, a capstone that proves you can ship, and career and community. The appendices hold books, the original MSP430 course, a glossary, the changelog and the contributing guide. The design decision worth noting is the split between phase 3 and phase 4. The professional phase is common ground, the architecture, the RTOS and the debugging, and the specialization phase is where the paths diverge. That is how a real job market is shaped, and it means a reader does not have to decide at the start what their job will be. They take the common modules and branch when their target job becomes clear. ## The hardware budget, and which board belongs to which phase The gear section is short and concrete, which matters for a course that claims you can start with a small budget. For phases 1 and 2 the list is a Raspberry Pi Pico 2, the Raspberry Pi Debug Probe, a breadboard, an assortment of LEDs and resistors, and a multimeter. For phase 3 it is an STM32 Nucleo-64. The README says that about sixty dollars covers phases 1 and 2, and there is a gear list document with details and prices. The split between the two boards is not arbitrary. The Pico 2 is where you learn what a register write does, and it is cheap enough that a failed experiment costs almost nothing. The Nucleo is where you meet the parts that matter when a board is a product rather than a learning toy, and the transition to it is module 8, the first of the professional phase. Including the Debug Probe in the phase 1 and 2 list is the detail that surprises people. Debugging hardware is usually treated as a phase 3 topic, where it appears alongside measurement and an oscilloscope. Listing it from the start means the reader meets debugging on the first board, which is arguably the right order and is not what most courses do. The limit of this budget is worth stating plainly. It buys a real board, a breadboard and a multimeter, which is enough to learn the fundamentals and to build the phase 2 checkpoints, and it is not enough to buy the instruments that phase 3 and phase 4 assume. ## Link checking, a one-line contribution rule, and a licence that covers the words The contributing section is where a learning repository reveals how seriously it takes rot, and the rule is memorable. The README asks for fixes to links, sharper sentences and better resources, says to read CONTRIBUTING.md first, and states the one rule: do not make it longer without making it better. That is a good constraint for a corpus that grows by addition, because the pressure in a link collection is always to add rather than to remove. The tooling backs it up. Every link is checked monthly by tools/check_links.py, and the changelog in the appendix records which links died. For a guide whose value is that its resources still exist, automated link checking is not a nicety, it is the feature that makes the guide usable, and the monthly cadence is a reasonable compromise for a project maintained alongside a full time job. The licence is CC BY-SA 4.0 for the text and structure, and the README says linked resources belong to their authors, which is the correct split. You can fork, adapt and redistribute the curriculum itself under the same terms, and you are expected to respect the rights of the books, courses and papers it points at. The default branch is master and the project publishes no GitHub releases, so the changelog in the appendices is the version history, which is a sensible choice for a document that is revised rather than released. ## Who this is for, and when a course is the wrong answer The alternative to a curriculum like this is a course: a university module with a syllabus and a lecturer, or the training that a hardware vendor sells for its own chip family. The difference in approach is worth being precise about, because it decides when each one is right. A course gives you a sequence with feedback and a credential, and it is scoped to one institution and one set of tools. This guide gives you a sequence with self-check questions, no credential, hardware you own, and a choice of specialization at the end, and it is scoped to no employer at all. For a high school student or a career changer, the self-paced format and the low hardware cost are the point, and a paid course is often out of reach. The cases where this is the wrong answer are clear. If you need an answer to a specific protocol question, a reference manual is better than a curriculum, and this guide will not have it. If your job uses a chip family with a proprietary toolchain, the vendor training will be more directly applicable. And if you cannot buy a board, the hands-on checkpoints do not work, and the project is honest about that by putting the hardware in the requirements rather than hiding it. What it offers that neither of the alternatives does is the shape. Knowing what an STM32 is does not make you a firmware engineer, and the sequence from a register write to a structured firmware architecture to a shipped capstone is the part that is hard to find and cheap to copy. The cost is the six hundred dollar question, and the answer is that phase 1 and 2 need about sixty. ## Conclusion Learn Embedded Systems suits a high school student with a soldering iron, a computer science student who has never touched a register, or an engineer moving into firmware, because it is one path with three entry points instead of a directory of links. It does not suit you if you want a reference to consult on a specific protocol, since it is a curriculum and every module is a sequence rather than a manual, and it does not suit you if you cannot buy the hardware, because the checkpoints are on a real board. Check three things before you start: that the target job family matches one of the four specialization modules, that you can obtain a Pico 2 and later an STM32 Nucleo, and that you are willing to work through the checkpoints rather than skim, since the check-yourself questions are the part that decides whether the module landed. The last push to the repository was on 2026-09-09 and the project publishes no GitHub releases. ## FAQ ### What is Learn Embedded Systems? It is a curriculum of twenty modules across five phases, from what a microcontroller is to job-ready firmware, with the same five-part structure in every module, hands-on checkpoints on real hardware, and free resources rather than paid books, on a Raspberry Pi Pico 2 and later an STM32 Nucleo. ### What hardware do I need to start? For phases 1 and 2, a Raspberry Pi Pico 2, the Raspberry Pi Debug Probe, a breadboard, LEDs and resistors, and a multimeter, which the README puts at about sixty dollars in total. Phase 3 moves to an STM32 Nucleo-64, and there is a gear list document with details and prices. ### How is each module structured? With five parts: why this matters, a short learn section of two to five resources each with a type and a time estimate, hands-on do checkpoints on real hardware, a check-yourself quiz, and an optional collapsed go-deeper section. ### How do I track my progress through the guide? The website at erinjense.github.io/Learn-Embedded-Systems has clickable checkboxes that remember your progress, a progress overview, search and dark mode, and the repository holds the same content as plain Markdown, which you can fork and tick off in the files themselves. ### Can I reuse and adapt this guide? Yes. The text and structure are licensed CC BY-SA 4.0, and linked resources belong to their authors, so the curriculum can be forked and redistributed under the same terms while the resources it points at keep their own rights. Every link is also checked monthly by a script in the repository. ## Sources - [erinjense/Learn-Embedded-Systems on GitHub](https://github.com/erinjense/Learn-Embedded-Systems) - [Issues](https://github.com/erinjense/Learn-Embedded-Systems/issues) - [License: CC-BY-SA-4.0](https://github.com/erinjense/Learn-Embedded-Systems/blob/master/LICENSE) - [README](https://github.com/erinjense/Learn-Embedded-Systems/blob/master/README.md) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/erinjense-learn-embedded-systems