The Embedded Project Cookbook A Step-by-Step Guide for Microcontroller Projects (John T. Taylor, Wayne T. Taylor)（Z-Library）

【One-Line Pitch】 A practical, process-first playbook for turning a microcontroller idea into a commercially releasable product, covering the non-code artifacts—requirements, design docs, CI, reviews—that most embedded books skip. Best for mid-level embedded developers and software leads who want to ship quality code without wading through theory. 【Book Arc】 - **Opening (~0%–10%)**: Frames the goal—building and releasing a commercially viable embedded system—and introduces the GM6000 running example, showing how requirements (MR/PR/SWR series) are captured and traced before any code is written. - **Early (~10%–30%)**: Moves through analysis, the Software Development Plan, and preparation, establishing hardware block diagrams, performance estimates, documentation responsibilities, and the build-script and repository foundations (libdirs.b, wiki structure) that later stages depend on. - **Early–Middle (~30%–45%)**: Covers continuous integration, revisiting requirements as design statements, and the start of construction—tasks, just-in-time detailed design, and the discipline of writing code alongside unit tests rather than in a big-bang pass. - **Middle (~45%–60%)**: Dives into drivers and the Hardware Abstraction Layer, explaining binding times (source, compile, link, run) and the LHeader/LConfig patterns used to defer hardware-specific decisions as late as possible. - **Late (~60%–85%)**: Applies the framework to real driver implementations—PWM, buttons, I2C—across Arduino, STM32, and simulator targets, showing how the same abstract interface maps to different concrete platforms. - **Ending (~85%–100%)**: Closes with release management, distinguishing early-access, candidate, and gold releases, and tying the whole process back to producing maintainable, reusable, extensible code. 【Key Takeaways】 - **Non-code artifacts carry the project** (Opening): Requirements, SDPs, trace matrices, and design reviews are treated as first-class deliverables, not end-of-project paperwork—this is the book's central thesis. - **Requirements traceability closes the loop** (Early): The GM6000 trace matrix exposes orphan subsystems (Bootloader, Software Update) that were expected but never formally required, showing how tracing catches gaps and prevents unrequested work. - **Build-and-test software before hardware exists** (Early–Middle): A functional simulator and decoupled UI let you develop substantial production-quality code ahead of hardware availability, compressing start-to-release time. - **Test early, test often** (Middle): The author explicitly warns against big-bang testing, recommending incremental code-test-iterate cycles and checking in multiple times per day on a branch. - **Late binding is the HAL's core principle** (Middle): Minimize source-time bindings; use compile-time, link-time, and run-time mechanisms (LHeader, LConfig) so hardware specifics stay swappable. - **One abstract interface, many concrete targets** (Late): Drivers like PWM and buttons are implemented separately for Arduino, STM32, and simulated platforms, proving the HAL's portability claim in practice. - **Pull requests and CI are developer workflow, not ceremony** (Middle): PRs gate merges to develop/main, while CI builds unit tests under multiple compilers (Visual Studio, MinGW, GCC-ARM) to surface compiler-masked errors. - **Release tiers match risk** (Ending): Early-access, candidate, and gold releases each carry different feature-completeness and change-control expectations, tied to specific SCM branches. 【Reading Tips】 - **Deep-read the requirements and analysis chapters (Opening–Early)**: The traceability and SDP material is the book's differentiator; skim if you already run a mature process, but don't skip the orphan-subsystem example. - **Treat the driver chapters (Middle–Late) as reference, not narrative**: Read one driver end-to-end (e.g., PWM) to absorb the HAL pattern, then consult others as needed for your target platform. - **Have the companion framework open**: The book repeatedly references concrete source paths (src/Driver/DIO/Arduino/Pwm.cpp, etc.); following along in the repo makes the LHeader/LConfig discussion far more concrete. - **Don't expect theory**: The book explicitly defers the "why" to *Patterns in the Machine*—if you want conceptual grounding, read that alongside or first. - **Adapt, don't copy**: The GM6000 is a heating controller; the processes generalize, but the specific tooling (GitHub, Jenkins, Doxygen) may need substitution in your environment. 【Coverage Limits】 The excerpts cover the full arc from requirements through release, but specific chapter-level detail is uneven—later driver and release chapters are represented by fewer, more fragmented chunks, so some implementation specifics may be thinner than the book itself.