하드웨어와 임베디드 시스템
Arduino, RISC-V, MSP430, PLC, Linux 드라이버, 임베디드 시스템 엔지니어링.
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 與可靠度五層。每一層都有可執行的實驗，最後疊成同一套韌體。
글 읽기 →STM32 嵌入式系統架構
還沒寫應用程式之前，先建立一張「晶片內部地圖」。之後 FreeRTOS 的 Tick、 I2S 的 DMA、Watchdog 的獨立時鐘，都會回到這張地圖。
글 읽기 →開發環境、CubeMX 與 HAL
工具鏈是嵌入式的第一道牆。本章目標只有一個：到下課時，板上的使用者 LED 以 1 Hz 閃爍，且 UART 印出 hello voice-home。
글 읽기 →GPIO 與周邊設備控制
應用層出現 |HAL_GPIO_WritePin(GPIOB, GPIO_PIN_0, ...)| 是壞味道。 腳位會因改板而變；語音任務不該重新編譯只因為 LED 換腳。本課程的 dev_* API 定義在 firmware/common/：
글 읽기 →PWM、定時器與馬達／風扇
GPIO 只能全開全關。燈光調光、風扇轉速、舵機角度都需要脈衝寬度 調變（PWM）：固定週期、改變高電平時間。STM32 的通用／進階計時器就是 做這件事的硬體。
글 읽기 →FreeRTOS 核心：任務、優先權與排程
從本章起，超級迴圈退役。系統變成一群「看起來同時在跑」的函式——任務 （Task）。語音控制器至少需要音訊、辨識、設備、感測、通訊、監控六類任務， 先用三個 LED 任務把肌肉練好。
글 읽기 →Queue、Semaphore 與 Mutex
多任務一旦開始「順便改同一個 |g_light_on|」，bug 就會變成時序競賽。 正確做法：誰擁有資料，誰才改它；其他人傳訊息。
글 읽기 →Event Group、軟體定時器與系統同步
Queue 適合「這筆資料給那一個消費者」。有些事情卻是很多任務都要知道 ：已經喚醒、匯流排故障、準備升級。Event Group 用一組位元表達這些事實。
글 읽기 →音訊擷取：麥克風、I2S 與 DMA
語音系統的物理起點是空氣壓力變化。STM32 不會「聽懂」，它只會把電壓或 數位串流變成記憶體裡的整數陣列。本章把這條管線做穩——穩了，後面的 AI 才有乾淨的輸入。
글 읽기 →