Learning Objectives
- 把一個想法寫成需求與規格，切成可以逐步完成的里程碑
- 用狀態機整理作品的行為，把邏輯與硬體分開並寫簡單的測試
- 列出讓別人能重做作品所需的文件：README、材料清單、電路圖、原始檔與版本紀錄
- 說明開源硬體的定義，替硬體、文件與程式選擇合適的授權
原型會動了，然後呢？
麵包板上的電路會動，是很重要的第一步，但離「作品」還有一段距離：
- 別人能用嗎？ 不用你在旁邊解說，看得懂怎麼開、怎麼調。
- 能撐多久？ 接線不會鬆、電池夠用、放進外殼不會過熱（第 15～17 課）。
- 別人能重做嗎？ 半年後的你，或另一位同學，照著資料能做出一樣的東西，甚至改得更好。
這一課以一盞「書桌燈」為例，走過規劃、整合、文件與授權。這是自造者入門的最後一課，前面每一課學到的東西都會用上。
從想法到規格
「我想做一盞智慧書桌燈」是想法，還不能開始做。先把它寫成需求（為誰、解決什麼問題），再寫成規格（可以檢查的條件）：
| 需求（為什麼） | 規格（怎麼算做到） | 怎麼測試 |
|---|---|---|
| 晚上讀書時不想找開關 | 按一下按鈕切換開關，0.2 秒內有反應 | 按 10 次，每次都正確切換 |
| 不同時間想要不同亮度 | 旋鈕可以連續調整亮度，從很暗到全亮 | 轉到兩端，亮度明顯不同 |
| 想帶到宿舍以外的地方 | 用電池至少撐 2 個晚上（每晚 4 小時） | 第 15 課的電源預算，再實測一次 |
| 放在書桌上不礙事 | 底座不超過 10 × 8 cm | 量外殼的尺寸 |
接著把工作切成里程碑，每一個都能展示、能測試：
- 最小可行原型：麵包板上，按鈕開關一顆 LED。
- 加入旋鈕調亮度，改用 PWM。
- 換成電池供電，量實際用電，加上低電量提醒。
- 焊到洞洞板、做外殼。
- 請兩、三位同學實際使用，記下他們卡住的地方，再修改。
先做出最小可行原型很重要：越早讓東西動起來，越早發現想法哪裡有問題。 規格裡寫不出「怎麼測試」的項目，通常代表還不夠具體。
逐步看：用狀態機寫出模式切換
規格說「按一下切換模式：關閉 → 恆亮 → 閃爍 → 關閉…」。這種「現在處於哪個狀態、遇到什麼事件就換到哪個狀態」的行為，
可以寫成狀態機：用一個變數 mode 記住目前的狀態，按鈕被按下（事件）時換到下一個。
模擬的按鈕在 0.5 秒與 1.6 秒各按一次，看 mode 怎麼變、燈怎麼跟著變。
把邏輯和硬體分開
作品越來越複雜時，每改一次就要接上電路、按按鈕、轉旋鈕來確認，很花時間，也容易漏測。 一個好習慣是把「決定要做什麼」的邏輯寫成一般的函式，和「讀感測器、控制腳位」分開：
def brightness(light, on): # 純邏輯：給輸入，回傳輸出
...
# 硬體的部分只負責讀與寫
lamp.duty_u16(brightness(ldr.read_u16(), on))
純邏輯的函式可以在電腦上直接測試，不用接任何硬體。把規格裡的情況寫成測試案例（輸入與預期的輸出）， 每次修改後全部跑一次。特別要放進邊界情況：最暗、最亮、關閉、讀值異常。
逐步看：替亮度邏輯寫測試
brightness() 依環境光決定燈的亮度：環境越暗、燈越亮。下面用 4 個測試案例檢查它，
最後一個故意給一個超出範圍的讀值，確認結果不會變成負數。這個範例不用接任何硬體。
文件化：讓別人（和未來的你）能重做
一個作品的資料夾，常見的內容：
| 檔案 | 內容 |
|---|---|
README.md |
這是什麼、為誰做的、照片、怎麼使用、怎麼組裝、已知的問題 |
BOM.csv（材料清單） |
每個零件的名稱、規格、數量、在電路圖上的代號、哪裡可以買到 |
hardware/ |
電路圖、電路板設計檔（用原始格式，不是只有截圖） |
code/ |
程式碼，以及燒錄的方法 |
enclosure/ |
外殼的 CAD 原始檔（例如 STEP）與給機器的檔案（STL、SVG） |
docs/ |
組裝步驟照片、測試紀錄、使用者回饋 |
CHANGELOG.md |
每一版改了什麼 |
LICENSE |
授權條款 |
寫文件的時機是邊做邊寫：拍下每個里程碑的照片、記下踩過的雷（「GP29 不能接感測器」「卡槽要扣掉切口寬度」）， 最後整理就好。等全部做完才回想，很多細節已經忘了。
用版本控制（例如 Git）管理這個資料夾，每完成一個里程碑就存一個版本，改壞了可以回到上一版， 也看得出每一次改了什麼（Git 軌有完整的介紹）。
把作品整理成一個專案資料夾
用終端機示範建立專案資料夾、放入文件與授權、存成第一個版本。實際的輸出（版本代碼、檔案數）會依你的內容不同。
-
1
建立資料夾並開始版本控制
一個作品一個資料夾，用 Git 記錄每一次的變更。
-
2
放進文件與原始檔
依上一段的表格建立資料夾，放入 README、材料清單、電路圖、程式碼與外殼的原始檔。
-
3
選好授權，寫進 LICENSE 與 README
硬體、文件與程式可以用不同的授權（下一段說明）。在 README 寫清楚每一部分用哪一種， 例如「硬體設計：CERN-OHL-S-2.0；文件與照片：CC BY 4.0；程式：MIT」。
-
4
存成第一個版本
每完成一個里程碑就提交一次，並標上版本號，之後在 CHANGELOG 記下這一版改了什麼。
開源硬體與授權
開源硬體協會（OSHWA）的定義大意是：設計公開，讓任何人都可以研究、修改、製作、散布與販售這個設計，以及依這個設計做出的硬體。 它要求公開的資料包含方便修改的原始格式的設計檔（例如電路圖的原始檔，而不只是一張圖片），而且不能限制別人販售或用在商業上。
硬體作品通常包含三種東西，各自有適合的授權：
| 部分 | 常見的授權 | 說明 |
|---|---|---|
| 硬體設計（電路、外殼） | CERN 開放硬體授權第 2 版（CERN-OHL） | 2020 年發布，有三種：P（寬鬆，改了不必公開）、W（弱互惠：修改到的設計部分要公開，和它搭配的其他元件不受影響）、S（強互惠：以它為基礎的整個設計都要用相同條件公開） |
| 文件、照片、教學 | Creative Commons（例如 CC BY、CC BY-SA） | 目前是 4.0 版。BY＝要署名，SA＝改作要用相同授權。Creative Commons 自己建議不要把 CC 用在軟體與硬體上 |
| 程式碼 | 軟體授權，例如 MIT（寬鬆）、GPL（互惠） | 不要用 CC 授權程式碼 |
選擇的思考方式：
- 希望任何人（包括公司）都能自由使用、不必回饋，選寬鬆的（CERN-OHL-P、MIT）。
- 希望別人改進之後也要公開，選互惠的（CERN-OHL-S、GPL、CC BY-SA）。
- 加上「非商業使用」（NC）限制的授權，不符合開源硬體的定義。
兩件常被忽略的事：
- 授權不包含商標。開源的設計可以被重做，但原作者的名稱、標誌不能直接拿來用；衍生作品通常要換一個名字。
- 使用別人的開源設計時，要遵守它的授權：保留原作者的署名，互惠授權的部分要用相同條件公開。
授權有法律效果，正式發表或商品化前，請詳讀條款原文，必要時詢問學校的技術移轉或法務單位。
小測驗：規劃與測試
下列哪一個最像「可以檢查的規格」？
狀態機裡 mode = (mode + 1) % 3，從 mode = 0 開始按 4 次按鈕。下面的程式會印出什麼？
mode = 0
for i in range(4):
mode = (mode + 1) % 3
print(mode)
brightness(light, on) 回傳 max(0, min(65535, 65535 - light))（開啟時）。下面的程式會印出什麼？
light = 70000
print(max(0, min(65535, 65535 - light)))
小測驗：文件與授權
你希望別人改進你的電路設計後，也必須用相同的條件公開整個設計。比較適合哪一種授權？
下列哪一個做法不符合開源硬體的定義？
專題的程式碼、文件照片、電路設計，最合適的授權組合是？
重點整理
- 把想法寫成需求與可以測試的規格，切成里程碑，先做出最小可行原型。
- 用狀態機整理作品的行為；把邏輯寫成純函式，用測試案例（含邊界情況）檢查。
- 文件邊做邊寫：README、材料清單、電路圖與 CAD 的原始檔、程式、變更紀錄，用版本控制管理。
- 開源硬體：公開可修改的原始設計檔，不限制別人製作與販售。
- 授權分開選：硬體用 CERN-OHL（P／W／S），文件用 Creative Commons，程式用軟體授權；授權不包含商標。
自造者入門走完了
從電壓電流、麵包板、三用電錶，到感測器、通訊、各種開發板，再到電源、焊接、外殼與文件，你已經有完成一件作品所需的基本功。 接下來可以到 ESP32 軌做連網的物聯網作品，或到樹莓派軌做需要攝影機、網頁伺服器與資料分析的專題。 做出作品之後，記得把它寫成文件分享出去。