# EmbeddedSystem is a Chinese notebook knowledge base whose index has fallen behind its own tree > SummerGift/EmbeddedSystem collects notes on computer architecture, embedded fundamentals and mainstream languages, written in Chinese and stored mostly as notebooks. The interesting part is the gap: the directory index in the README points at names that are not in the repository, and nine real directories are never mentioned. **SummerGift/EmbeddedSystem** — Summary of computer architecture, embedded systems fundamentals, and mainstream programming languages - Repository: https://github.com/SummerGift/EmbeddedSystem - Stars: 713 · Forks: 154 - Language: Jupyter Notebook - License: MIT - Published: 2026-09-10 · Updated: 2026-09-10 · Language: en - Canonical page: https://hysenlabs.com/projects/summergift-embeddedsystem ## Nine of the seventeen directory names in the index are not in the tree The README opens with a link index, and it is the one part of this repository that can be checked against the file list. It links seventeen directories. The repository's top level contains seventeen directories too. They are not the same seventeen. Eight links land on a directory that exists: Articles, Network, RTOS, Linux, Tools, Math, DataStructure and Compiler. Nine do not: Arm, MachineLearning, C, C++, Python, Java, JavaScript, Go and Gist. There is no Arm directory at the top level, and the machine learning notes live under ML rather than MachineLearning. The six language sections are not six directories at all; the tree has a single Language directory where the index implies six separate ones. The Gist entry has no counterpart in the top level either. The mismatch runs the other way as well. Nine directories that do exist are never linked: AUTOSAR, Algo, Arch, Books, DesignPattern, Language, Middleware, ML and SoC. So an index reader looking for automotive software, middleware or system on chip material will not find it, even where it sits at the top level. ## The dominant language is Jupyter Notebook and there is nothing to build GitHub classifies this repository's dominant language as Jupyter Notebook. That single statistic is the most reliable description of its shape: the material is executable or at least notebook-formatted, not a set of prose documents with a toolchain around them. There is no build script, no install command, no package manifest and no published release in the tree. The MIT license file sits next to the README, which is the only governance signal present. Two issues are open against 712 stars and 154 forks. On content, the README is explicit about provenance. It presents the contents as three things mixed together: the author's own study notes and reflections, tricks used in day to day work, and embedded knowledge gathered from various places. Nothing marks which is which, and no individual note carries a date or a source line. For a repository whose pitch is that it will keep being updated over the long term, that missing provenance is the practical gap, since a reader cannot tell an original explanation from a transcription. ## The opening argument is that an iPhone already counts as embedded The framing paragraph sets the scope, and it is an argument rather than a syllabus. Someone quoted as saying something much better is treated as the lead: an iPhone is an embedded ARM running an OS, and CUDA can be understood as a kind of heterogeneous embedded computing. From there the README draws a conclusion about definitions. If computer science and embedded are treated as separate, and only microcontrollers, ARM and FPGA count as embedded, then nobody becomes a good embedded engineer by studying that narrow band. The word used for the field is a branch of computer science, not a specialty beside it. This is worth reading as a positioning statement rather than a technical claim, because it explains the repository's shape. A collection spanning network, RTOS, Linux, compilers, data structures, machine learning and five mainstream languages is a coherent answer to that argument, and it is also why the ARM material is listed as one line among many. ## A hand-built 16-bit CPU is the author's argument for depth over CPU familiarity The section on technical depth carries the repository's most personal claim. The author writes that after several years of engineering work, having touched many kinds of processors, and having designed and implemented a simple 16-bit CPU of his own, the conclusion was that knowing how to use a few particular CPUs is not the most important knowledge. What matters more, as written, is computer organization and computer architecture, with x86, ARM and RISC-V given as the named examples. The stated payoff is transfer: a solid grasp of the fundamentals makes new hardware learnable by analogy, and makes heterogeneous computing such as GPU, TPU and NPU less intimidating when it turns up. The same paragraph applies the argument to programming languages. Yes, keep learning new ones. The part that actually carries the weight is the design thinking behind a language and the situations it fits, and further back, compiler principles, described as the knowledge base from which a language is built. Learning those makes a new language easy to pick up. ## The recommended route runs against the one most electronics graduates take The section asking what an embedded engineer is describes a common entry path and then objects to it. Electronics graduates typically start at the machine level with microcontrollers and the principles of microcomputers, move up to the language level with C and Python, and finish with data structures and algorithms. As written, the route looks reasonable and suits beginners, but it has a serious flaw: you can end up knowing that something works without knowing why. The objection is about composite problems. Work problems in this field tend to combine layers, and approaching them only from the language or algorithm level tends not to solve them, because sometimes the answer is at the machine level. The way out, as given, is to know where the layers of a computer system sit and where you are on them, which needs a real grasp of computer organization. Two pointers follow. One is a third edition book by Randal E. Bryant and David R. O'Hallaron, linked through their home pages at cs.cmu.edu. The other is a MOOC course called 计算机系统基础, taught by 袁春风, whose course page is at icourse163.org/course/NJU-1001625001. Both are recommended for the same purpose: building a picture of the abstraction layers of a whole computer system. ## Debugging is presented as a question-asking discipline, not a tool chain One section treats debugging as a subject with its own literature. The starting point is a colleague, described as genuinely skilled, being asked how they debug and answering that they mostly rely on thinking. The README concedes that this is too terse, then agrees with it anyway: debugging does depend on thinking, and the real question is how to think. The reading that supplies a method is a book called 《How to solve it》, and the argument is that this is a way-of-thinking problem, because solving a bug proceeds much like solving a mathematics problem. The practice that follows is a fixed set of questions an engineer should ask. When a solution looks feasible and seems correct, ask how one would come up with it. When an experiment looks feasible and seems to be a fact, ask how that fact was discovered, and how you would have arrived at it yourself. The final instruction is the demanding one: understand not only the solution to each bug but its motivation and steps, and be able to explain those motivations and steps to somebody else. Nothing in this section is tooling, which is consistent with a repository that has no build. ## The unlisted directories hold the industry-shaped material Reading the file list rather than the index changes what the repository appears to contain. The nine unlinked directories are not padding. AUTOSAR and SoC are automotive and system on chip subjects that an embedded engineer meets in industry rather than in a textbook chapter. Middleware is the layer that sits between an RTOS and an application, and the index has an RTOS entry but no middleware one. DesignPattern, Algo and Books extend the reach into software architecture, algorithms and reading notes, and Arch and Language look like the current homes for the ARM material and for the five language sections the index still lists separately. That reading is inference from directory names, and the repository offers no description of any single directory. It is also the reason to distrust the index. The list of links a reader gets is a snapshot of an earlier layout, while the tree reflects a later consolidation into fewer, broader directories. The README is written in Chinese throughout, and no English version is offered. The book and course titles above are given as they appear in the source text. ## Conclusion Use this repository the way the author uses it, as a reading list and a place to keep personal notes, not as a reference with an authoritative table of contents. The subjects it argues for are worth taking seriously: computer organization and architecture over familiarity with any single processor, and a deliberate method for thinking about bugs. Before you point a student or a new hire at it, check what is actually in each directory, since nine of the seventeen names the index links do not exist at the top level and nine real directories, including AUTOSAR, SoC and Middleware, are absent from the index. There is no build, no install step and no published release to reason about, and the last push on record is 5 May 2026. Copy the ideas, not the links. ## FAQ ### What does SummerGift/EmbeddedSystem actually contain? A Chinese-language summary of computer architecture, embedded system fundamentals and mainstream programming languages. The top level holds MIT-licensed notes under Articles, Network, RTOS, Linux, Tools, Math, DataStructure and Compiler, plus nine further directories the index never links, including AUTOSAR, SoC, Middleware and ML. ### Is EmbeddedSystem a software project I can build or install? There is nothing to build. GitHub classifies its dominant language as Jupyter Notebook, and the repository contains no build script, no install command and no published release. The README presents the contents as the author's study notes, day to day work tips and embedded knowledge collected from elsewhere, without marking which is which. ### Which book and course does the EmbeddedSystem README recommend? A third edition book by Randal E. Bryant and David R. O'Hallaron, linked through their CMU home pages at cs.cmu.edu, and a MOOC course called 计算机系统基础 taught by 袁春风, whose course page is at icourse163.org/course/NJU-1001625001. Both are recommended for understanding the abstraction layers of a whole computer system. ### How does the EmbeddedSystem README define embedded engineering? As a branch of computer science rather than a narrow hardware field. The framing example quoted is that an iPhone is an embedded ARM running an OS, and that CUDA can be understood as a kind of heterogeneous embedded computing, which is the argument for not treating microcontrollers, ARM and FPGA as the whole subject. ### Is EmbeddedSystem still being updated? The README says the repository will be updated on an ongoing basis, and the last push on record is 5 May 2026. It is not archived and one issue is open. No GitHub releases are published and no changelog appears at the top level, so there is no published record of what changed when. ## Sources - [Issues](https://github.com/SummerGift/EmbeddedSystem/issues) - [License: MIT](https://github.com/SummerGift/EmbeddedSystem/blob/master/LICENSE) - [README](https://github.com/SummerGift/EmbeddedSystem/blob/master/README.md) - [SummerGift/EmbeddedSystem on GitHub](https://github.com/SummerGift/EmbeddedSystem) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/summergift-embeddedsystem