ACPI ASL 教材 — 章節撰寫指南（內部文件）
本文件是《ACPI ASL 從零到實戰》各模組撰寫者的統一規範。 動筆前必讀三個檔案：: 本指南 acpibook.sty — 所有可用的巨集與環境定義 modules/module01.tex — 品質與風格標竿（exemplar），你的輸出必須與它同風格
阅读文章 →開發環境安裝指南
macOS 沒有 /sys/firmware/acpi，抓取實機 ACPI tables 的練習 （第 22 章、Project 5）請在 Linux 實體機或虛擬機上進行。
阅读文章 →參考資料
ACPI Specification 6.5, UEFI Forum. https://uefi.org/specifications 一切問題的最終答案。建議搭配本書：第 5 章（tables）、 第 6 章（device configuration）、第 19 章（ASL reference）。 ACPICA — ACPI Component Architecture, Intel. https://www.acpica.org/、
阅读文章 →前言
打開任何一台 x86 筆電或伺服器，作業系統之所以知道「這台機器有哪些電池、 哪顆 GPIO 控制器、感測器接在哪條 I2C 匯流排、按下電源鍵該做什麼」， 靠的不是魔法，而是韌體交給作業系統的一份「機器說明書」—— ACPI Tables。而撰寫這份說明書的語言，就是 ASL （ACPI Source Language）。
阅读文章 →ACPI Introduction
在寫下第一行 ASL 之前，你必須先知道這門語言存在的理由。本章從歷史與架構 切入，建立「韌體描述硬體、作業系統解讀並決策」這個 ACPI 的核心世界觀。
阅读文章 →ASL vs AML
第 1 章的結尾出現過一條生產線：硬體規格經過 ASL、AML，最後抵達 OS 的 ACPI Interpreter。本章把鏡頭拉近到前兩站，回答一個看似簡單、 卻是每個 BIOS 新人都踩過的問題：ASL 和 AML 到底是不是同一個東西？ 答案是否定的——它們的關係就像原始碼與機器碼，中間隔著一個編譯器。
阅读文章 →Data Types
第 3 章告訴你 Namespace 是一棵掛滿物件的樹；本章回答下一個問題：這些物件到底 「是什麼」？ASL 沒有 int、char 這類型別宣告關鍵字——你宣告的是 物件，型別由初始值決定，而且執行期還會換。這種動態型別的世界觀，讓你在 C 語言養成的直覺一半有用、一半會害你。
阅读文章 →Device Object
第 1 章說過，ACPI 存在的一大理由是替「不可列舉」的硬體向 OS 自我介紹，而自我介紹的載體，就是本章的主角——Device 物件：一個 Device 節點搭配一組名稱固定的標準子物件，就構成 OS 眼中「一個完整的裝置」。本章依 OS 列舉的順序講解它們：身分 （_HID、_CID、_ADR、_UID）、 狀態（_STA）、資源（_CRS、_PRS、 _SRS）、屬性與初始化（_DSD、_INI）。
阅读文章 →OperationRegion
第 8 章的 _CRS 只是「申報」：告訴 OS 我的暫存器在哪、佔多大， 請 OS 別把資源分給別人。但 AML 自己也常要動手碰硬體——_STA 要讀狀態暫存器、_INI 要寫預設值、EC 的電池電量要一個 byte 一個 byte 讀出來。ACPI 給 AML 的存取機制分成兩層：本章的 OperationRegion 負責「在某個位址空間開一扇窗」， 第 10 章的 Field 再把窗內切成一顆顆具名暫存器。
阅读文章 →Method
Module 5 的 OperationRegion 與 Field 讓你能描述硬體暫存器，但 Name 與 Field 物件終究是「靜態資料」——它們安靜地躺在 Namespace 裡等人來讀。 真正讓 DSDT「動起來」的是 Control Method：一段包在名字裡的 AML 程式，OS 在正確的時機呼叫它，它替 OS 敲硬體、算結果、回報狀態。 從本章起，ASL 對你而言不再只是描述語言，而是一門真正的程式語言。
阅读文章 →Power States
第 1 章說過，電源管理是 ACPI 存在的理由；前幾章的 Method 與 Notify 也一直繞著電源事件打轉。本章正式把地圖攤開：G、S、D、C、P 五個字母家族各管什麼、彼此如何嵌套；一台筆電從闔上蓋子到再次喚醒， OS 與韌體之間完整的握手順序是什麼。這張地圖是 Module 7 後兩章、乃至日後所有電源除錯工作的座標系。
阅读文章 →DSDT
第 2、3 章說過：OS 開機時解譯 AML、建立 ACPI Namespace。那 AML 究竟住在 哪裡？答案的主體就是 DSDT（Differentiated System Description Table）——每台機器都有、也只有一份的「硬體描述主檔」。你在前七個模組寫的 每一個 Device、OperationRegion、Method，在真實產品中幾乎都躺在 DSDT （或它的延伸 SSDT）裡。
阅读文章 →iASL Compiler / Disassembler
第 20 章的流水線裡，iasl、acpidump、acpixtract 已經輪番上陣，但當時它們只是配角。本章把工具升格為主角： 這些程式從哪裡來、彼此什麼關係、每個常用旗標解決什麼問題。 你會發現它們全部出自同一個專案——ACPICA——而且與 Linux kernel 裡的 ACPI 直譯器系出同門。
阅读文章 →Linux ACPI
寫了九個模組的 ASL，你可能還沒有真正「摸」過一台機器裡活著的 ACPI。 Linux 是觀察 ACPI 最友善的平台：核心把 ACPI 的一舉一動攤在 /sys 與 kernel log 裡，工具鏈又與第 21 章的 iASL 系出同門。本章建立一條 你之後會反覆走的分析路線：從 sysfs 找到裝置、反組譯 DSDT、讀懂 Method、對應到硬體——第 23、24 章的 Debug 與錯誤排除都蓋在這條 路線上。
阅读文章 →ACPI 與 Linux Kernel 整合
前面 24 章，你一直站在「韌體端」寫 ASL、除錯 ASL。本章換到桌子的 另一側：OS 工程師拿到你的 DSDT，是怎麼把 Device 變成 struct device、把 _CRS 變成 ioremap 的參數、 把 Method 變成一個 C 函式呼叫的？這是全書最長的一章，也是把你從 「會寫 ASL 的人」升級成「能做系統整合的韌體工程師」的一章—— 第 26 章 Project 1 的 DEMO0001 裝置正是本章的主角
阅读文章 →Project 1：Virtual ACPI Device
這是你第一次不跟著課文抄範例，而是以工程師的身分交付一個「產品」： 一個從零開始的虛擬 ACPI 裝置。它只有一個 _HID、一個 _STA 和一個會回傳 1234 的 Method，小得不能再小， 但五臟俱全——你會走完 ASL 生產線的每一站：撰寫、編譯、 在 acpiexec 裡執行、最後塞進 QEMU 或真機的 Namespace， 在 /sys/bus/acpi/devices 底下親眼看到它。
阅读文章 →STM32 × FreeRTOS × 智慧語音控制
智慧居家語音控制器完整實作課程：LaTeX 教材、高品質 PDF，以及可放入 STM32CubeIDE 的分週韌體。
阅读文章 →智慧居家語音控制器 — 實驗韌體
對應教材《STM32 × FreeRTOS × 智慧語音控制》。應用層只放在本目錄； STM32Cube 產生的啟動檔、HAL、FreeRTOS 核心請用 CubeMX／CubeIDE 產生。
阅读文章 →lab08 路徑 B — Edge AI 接線
官方延伸：X-CUBE-AI、FP-AI-NANOEDG1、STM32H747I-DISCO 音訊 AI 示範。
阅读文章 →MQTT 選做接線（第 11 章）
下行必須進入 g_cmd_q，遵守安全策略，禁止直接呼叫 dev_*。 現成的 ESP32 MQTT–UART 橋在 ../lab12_assistant_gateway/esp32/mqtt_uart_bridge/。
阅读文章 →lab12 — 智慧助理閘道（Siri / Alexa / OK Google）
對應教材第 13 章。三家助理的喚醒與辨識在生態系側完成，STM32 只多一個 Gateway 任務，所有指令仍進同一條 g_cmd_q。
阅读文章 →Matter 路線（第 13 章導讀）
Matter 是 CSA 的智慧家庭標準；Apple Home、Alexa、Google Home 都是控制器， 配對一次即可被三家 App 控制（multi-admin）。DIY 裝置可用測試憑證在自家 配對，出貨才需要 CSA 認證與正式 DAC。
阅读文章 →總成專案
加入編譯：: ../common/src/*.c（hooks 可選） ../lab08_asr_module/asr_map.c app_main.c
阅读文章 →課程導論與專案全貌
嵌入式課程最常見的失敗模式，是學員會閃燈、會讀 ADC，卻無法把多個週邊組成 一個「產品」。本課程反過來設計：先給你產品規格，再把規格拆成硬體、驅動、 RTOS、AI 與可靠度五層。每一層都有可執行的實驗，最後疊成同一套韌體。
阅读文章 →