ECCH8：程式編寫在現實生活的應用

「程式編寫在現實生活的應用」強調程式不是只在螢幕內運算，而是接收真實世界的輸入（例如光度、動作、聲音），再作出輸出（例如開燈、發出提示音、在畫面顯示狀態），令系統能在現實情境中運作。

在課題中，常見的輸入來自傳感器，輸出可以是執行器（例如燈、馬達）或資訊輸出（畫面/文字）。

1. 釐清目標：系統想解決甚麼問題？（例如節能、提示、保安）
2. 列出輸入：需要哪些數據？（光、動作、語音文字）
3. 設計處理規則：界定值、條件、狀態、計時（例如延時關燈）
4. 決定輸出：控制甚麼裝置？顯示甚麼訊息？
5. 考慮事件：哪些情況會觸發處理？（按鍵、超過界定值、計時到期）

規則：「偏暗而且有人」就開燈；否則關燈。

程式化時可變成：

• 輸入：light（光傳感器讀數）、motion（有人/無人）
• 處理：if light < threshold and motion == 1
• 輸出：開燈/關燈

關鍵是把「一句話」拆成可檢查的變量與條件。

互動程式（本章主線）重點在於：輸入會隨時間改變、要處理雜訊與時延、要設計事件觸發與狀態管理。

純計算程式重點在於：算法（algorithm）正確性、數據結構、效率等（也重要，但不是本章核心）。

• 把讀數當作永遠準確：忽略雜訊，令輸出不停閃爍。
• 沒有定義輸出行為：同一條件下，應該「保持狀態」還是「重設」？
• 忘記狀態：例如有手動模式時，仍讓自動規則覆蓋手動輸出。

實際系統通常以「分層」方式工作：

• 上層：你的程式（邏輯規則、介面）
• 中層：擴充模組／函式庫（提供應用程式界面（API））
• 下層：驅動程式、韌體、硬件（負責真正讀取/控制）

使用函式庫的好處是：你可以專注在解難與邏輯，而不必一開始就處理通訊協定、時序、匯流排等底層細節。

輸入－處理－輸出循環（IPO）是一種快速整理方法：把系統拆成「輸入」「處理」「輸出」，避免一開始就跳入寫程式。

數據流程圖（DFD）用圖像表示「數據如何流動」：從數據來源（例如傳感器）流到處理程序，再流到數據接收器（data sink，例如顯示器/裝置）。

1. 找出外部實體：使用者、傳感器、外部系統。
2. 找出處理程序：比較界定值、計算平均、判斷動作。
3. 找出數據流：讀數、事件、狀態訊息。
4. 找出輸出：開燈訊號、警報訊息、畫面顯示。

提示：DFD 著重「數據」；如果你寫到「如果…就…」很多，可能你其實在寫流程圖。

• DFD（數據流程圖）：看數據流向與資料交換。
• 流程圖（flowchart）：看步驟次序與分支/迴圈。
• 方塊圖（block diagram）：看系統由哪些大模組組成（較高層）。

同一個系統可以有多種圖，但要先想清楚「你要表達甚麼」。

• 輸入不限於鍵盤：傳感器讀數、按鍵事件都屬輸入。
• 輸出不限於螢幕：控制燈、馬達、蜂鳴器亦是輸出。
• DFD 不是畫得越多箭嘴越好：應該每一條箭嘴都代表一種有意義的數據。

一個大型系統的 DFD 可用「分層」方式表示：

• Level 0（Context Diagram）：把整個系統當成一個大處理程序，只畫外部實體與主要數據流。
• Level 1：把大處理程序拆成多個子處理程序（例如：讀取、濾波、決策、輸出）。

分層的好處是：高層清楚、低層可深入細節，但不會一開始就畫到混亂。

• 讀數：傳感器量度到的數值（例如 0–1023）。
• 界定值（threshold）：用來把讀數分成兩類（例如偏暗/偏亮）。
• 雜訊：不希望出現的波動，令讀數在短時間內上下跳動。
• 取樣：以固定時間間隔讀取一次讀數（例如每 0.5 秒讀一次）。

真實世界多數是連續變化（模擬），但程式往往要做離散決策（開/關、是/否）。常見方法是：

1. 讀取數值（可能經模擬數碼轉換器（Analog Digital Converter (ADC)））
2. 必要時先做轉換（例如 0–1023 → 0–100%）
3. 用界定值把數值分類
4. 加入「抗雜訊」策略，避免一跳動就改變輸出

若只用單界定值：

如果 light < threshold：
    開燈
否則：
    關燈

當 light 在界定值附近抖動時，燈就會不停閃爍。改善之一是「多次確認」：

如果連續 3 次 light < threshold：
    開燈

做法簡單，但能有效減少誤觸發。

• 調整界定值：環境基線改變時最直接，但未必解決抖動。
• 平滑／濾波：適合處理高頻雜訊，但可能引入時延。
• 延遲判定／多次確認：對付尖峰很有效，但反應會慢少少。

實際系統常會混合使用。

• 忽略「讀數跳動」：導致輸出不停改變。
• 界定值設定不合理：例如太貼近常態值，令系統長期在邊界震盪。
• 只追求「反應快」：取樣太密，反而更易受雜訊影響。

不少傳感器輸出是模擬電壓，電腦/微控制器需要透過模擬數碼轉換器（Analog Digital Converter (ADC)）把電壓轉成整數讀數。

解像度（resolution）可理解為「分得幾細」：例如 10-bit ADC 會把量程分成 2¹⁰=1024 個等級（0–1023）。

解像度越高，理論上可分得越細；但雜訊、電源穩定性、感測器本身誤差，都會影響實際效果。

平滑／濾波通常要「看多一點點數據」才可以算平均或趨勢，所以會引入時延（latency）：

• 例如移動平均要等到收集 3 次讀數，才算到一個平均值。
• 時延太大會令系統反應慢；時延太小又可能仍然抖動。

設計時要在「穩定」與「反應」之間取平衡。

擴充模組／函式庫是一組已寫好的程式碼，讓你不用由零開始處理硬件細節。

它通常會提供一個或多個應用程式界面（application program interface (API)），例如：

• sensor.read()：讀取傳感器讀數
• light.on() / light.off()：控制輸出裝置

1. 初始化：設定通訊埠、位址、模式、取樣率等。
2. 讀取/控制：在主迴圈或事件處理器中呼叫 API。
3. 處理例外：讀不到數據、超時、格式錯誤等。
4. 釋放資源：需要時停止裝置、關閉連線。

提示：即使你看不到底層，仍要明白「何時初始化」「何時讀取」及「出錯點算」這些設計決定。

• 用函式庫：上手快，集中處理邏輯；但遇到特別硬件或要改低層行為時較受限制。
• 自己寫底層：可完全控制，但要處理更多硬件與通訊細節，開發成本高。

在學習階段，多數情況先用函式庫建立系統思維與程式架構。

• 忘記初始化就直接讀取。
• 通訊埠或位址設定錯，仍以為是程式邏輯錯。
• 忽略回傳值範圍（例如 0–1023 或 0–1.0），導致界定值比較失準。

一個典型互動系統可分成幾層：

1. 應用層（你的程式）：寫規則、處理事件。
2. 函式庫層：提供 API，處理常見格式轉換與錯誤處理。
3. 驅動程式（driver）：與硬件溝通，控制通訊埠、寄存器等。
4. 韌體（firmware）：在嵌入式系統（embedded system）內控制硬件行為。
5. 硬件層：傳感器本體、模擬數碼轉換器（ADC）、匯流排等。

你呼叫一個 read()，下層可能做了「發送讀取命令 → 等待回應 → 進行校驗 → 轉成數值」等多步。

• 匯流排（bus）：多個裝置共享通道（例如 I²C），需要位址（address）分辨裝置。
• 緩衝區（buffer）：暫存收發數據；緩衝區滿/空都可能造成讀取異常。
• 時延（latency）：裝置回應需要時間；若程式等得太短就當作失敗。

因此排查時，不應只看程式邏輯；接線、供電、通訊埠設定、甚至訊號交換（handshaking）也可能是關鍵。

• 事件：一個「值得反應」的狀態改變（例如按下按鈕）。
• 事件處理器（Event handler）：事件發生時執行的程式片段（通常是一個函式）。
• 事件驅動程式（Event-driven Program）：以事件作為主要觸發機制的程式架構。
• 輪詢（polling）：程式以固定時間間隔主動檢查狀態是否改變。

輪詢像「每隔一陣就問一次」：

每 0.5 秒：
    讀取傳感器
    如有變化就處理

事件驅動像「有事先叫你」：

當按鈕被按下：
    執行事件處理器

當讀數連續 3 次超標：
    觸發警報

兩者都可達到效果，但在時延、資源消耗與程式結構上各有取捨。

不少系統會採用混合方式：

• 按鍵（事件）→ 立即切換 AUTO/MANUAL
• 定時（輪詢）→ 每秒更新一次畫面顯示

混合方式能兼顧即時性與穩定更新。

• 事件驅動：按鍵、超標觸發、需要即時反應的情況。
• 輪詢：固定間隔記錄、定時更新畫面、週期性工作。
• 混合：同時有「即時事件」與「週期性工作」時。

• 按鍵彈跳（bounce）造成一次按下變多次事件。
• 讀數抖動造成界定值附近不停觸發。
• 事件處理器做太多工作，導致整個系統卡住。

解法通常是：去抖、多次確認、把重工作放到背景循環處理。

在部分硬件平台，事件可以由中斷請求（Interrupt Request (IRQ)）觸發，系統會暫停手上工作，先執行中斷處理程式（interrupt handler）去回應事件。

這可帶來更低時延，但亦需要更小心：中斷處理程式通常要很短、很快，避免影響系統其他部份。

即使是事件驅動，事件也可能先排入「事件佇列」，再由主迴圈逐個處理。若事件太多或處理太慢，就會造成：

• 時延（latency）上升：反應越來越慢。
• 緩衝區（buffer）積壓：甚至溢出或丟失事件。

因此，設計事件處理器時要避免做過多計算，並適當限制觸發頻率。

智能照明的目標通常包括：

• 需要時自動開燈（方便、保安）。
• 無需要時自動關燈（節能）。
• 避免閃爍與誤判（用得舒服）。

• light：光傳感器讀數（用界定值判斷偏暗/偏亮）。
• motion：動作/有人（可視為事件或狀態）。
• mode：AUTO 或 MANUAL（決定是否執行自動規則）。

當 mode=AUTO 時，系統用規則決定燈；當 mode=MANUAL 時，燈狀態由使用者控制，系統不應強行改動。

# 變量
mode ← AUTO
lamp ← OFF
lastMotionTime ← -infinity

當偵測到動作：
    lastMotionTime ← 現在時間

重覆（每 0.5 秒）：
    light ← 讀取光傳感器
    isDark ← (light < threshold)

    如果 mode = AUTO：
        如果 isDark 且 (現在時間 - lastMotionTime ≤ delay)：
            lamp ← ON
        否則：
            lamp ← OFF

這段偽代碼把「延時」寫成時間差判斷，概念清晰。

單界定值：light < threshold 就開燈，否則關燈，容易在邊界抖動。

兩個界定值：例如 light < low 才開燈，light > high 才關燈，可減少來回切換。

• MANUAL 模式下仍然執行 AUTO 規則，令使用者覺得「我明明關咗燈又自己開返」。
• 延時設計錯：每次循環都把 lastMotionTime 更新，導致永遠不關燈。
• 沒有處理抖動：讀數在界定值附近就不停閃爍。

常見光敏元件（例如 LDR）會隨光度改變電阻，配合電阻形成分壓電路，輸出一個隨光度變化的電壓。

系統再用模擬數碼轉換器（Analog Digital Converter (ADC)）把電壓轉成 0–1023 之類的數值。

因此「讀數變大代表更光/更暗」要視乎接法；設計界定值前要先做簡單量度與校準。

加速度計用來量度物件在不同方向上的加速度變化。常見為三軸（x、y、z），反映不同方向的變動。

在應用上，我們常用它來偵測：搖晃、跌落、轉向、步行節奏等。

把三軸合成一個量：

mag2 ← ax^2 + ay^2 + az^2

然後用界定值比較：

如果 mag2 > threshold2：
    記為一次「超標」

使用平方的好處是：不需要開根號，計算更簡單，也適合界定值比較。

count ← 0
重覆讀取 n 次：
    計算 mag2
    如果 mag2 > threshold2：
        count ← count + 1

如果 count ≥ 3：
    輸出「搖晃」
否則：
    輸出「正常」

這樣可減少單一尖峰造成的誤報。

• 單一軸：容易受方向/角度影響，可能誤判。
• 總加速度：綜合三軸資訊，通常更穩定，但可能失去方向資訊。

• 取樣太疏：漏掉短暫動作（例如快速搖一下）。
• 界定值太低：輕微動作也被當成搖晃。
• 沒有平滑：雜訊造成超標次數被放大。

不少加速度計屬 MEMS（微機電系統）。可用簡化模型理解：內部有微小「質量」與「彈簧」，加速度改變時質量相對位移，電容/電阻改變，再被電路轉成數值。

這個模型提醒我們：讀數本身有誤差與噪聲，所以需要平滑、多次確認等策略。

在本章的角度，語音識別可以理解成一個「輸入模組」：

• 輸入：聲音（語音）
• 輸出：文字（例如「開始」「停止」「開燈」）

程式再把文字視為事件或指令，進行處理。

典型做法：

1. 取得語音文字 text
2. 判斷包含關鍵詞：例如「開始/停止」
3. 映射成控制指令：START/STOP/UNKNOWN
4. 與自動規則協調：例如「語音 OFF」應覆蓋自動「偏暗＋有人」

輸入 voice（ON/OFF/NONE）
輸入 motion（0/1）
輸入 isDark（0/1）

如果 voice = ON：
    開燈
否則如果 voice = OFF：
    關燈
否則：
    如果 motion=1 且 isDark=1：
        開燈
    否則：
        關燈

這種「優先次序」寫清楚後，系統行為會更可預測。

• 語音：自然、方便，但可能受環境噪音影響，需要處理誤識別。
• 按鍵：可靠、明確，但需要使用者接觸或靠近。

在設計上，兩者都可以成為事件；差別在於誤差來源不同。

• 太鬆：見到一個「開」字就當作開燈，容易誤判。
• 太緊：一定要完全一致才接受，使用者體驗差。
• 沒有 UNKNOWN：遇到不明指令時沒有合理回應。

不少語音識別系統背後會用到人工智能（Artificial Intelligence (AI)）模型，把聲音特徵映射成文字。對本章而言，你不一定要掌握模型訓練細節，但可以理解：

• 語音識別有機會出錯（誤識別/漏識別）。
• 系統設計需要容錯：例如提供重複確認、顯示識別結果給使用者確認。
• 若使用雲端服務，亦要留意私隱與資料傳送。