韌體開發 x 踩坑心得 x 讓錢慢慢長大
在嵌入式開發裡，定義常數這件事做了幾萬次，但我敢說大多數人都沒有認真想過「這三種到底有什麼差別」。
反正 #define 能跑、const 也能用，切換狀態就 enum，好像各有各的場，不去想也沒事。
直到某次 code review，被人問了一句：「這裡為什麼用 #define 而不是 const？」
我愣了一下。說真的，我沒有理由，就只是習慣。
不想看完可以直接記這個：
| 情境 | 建議 |
|---|---|
| 硬體暫存器位址、bit mask | #define |
| 有型別的常數值 | const |
| 一組互斥的狀態 / 選項 | enum |
| 條件編譯、平台切換 | #define |
| 陣列長度（C99 以後） | enum 或 const 均可，但 #define 最保險 |
但只知道結論沒什麼用，知道背後的理由才不會在邊緣情況翻車。
有一次我在 review 同事的 code，看到一行：
if (len - sizeof(header) > 0) {我當下沒說什麼，因為看起來很正常。結果那週 QA 回報說某個封包長度剛好等於 header size 的時候，系統會亂跑。
追進去才發現：len 是 int，sizeof(header) 是 size_t，也就是 unsigned。當 len == sizeof(header) 的時候，相減結果是 0，但如果 len < sizeof(header)，你以為是負數，其實是一個很大的正整數。然後 > 0 就是 true。
然後就囧了。
有一次 code review，同事寫了這樣一行：
int result = MAX(sensor_read(), threshold);我看了一眼沒說什麼，但心裡其實有點毛。
MAX 是怎麼定義的？他說是標準的那種：
#define MAX(a, b) ((a) > (b) ? (a) : (b))那 sensor_read() 會被呼叫幾次？他楞了一下。答案是：不一定，可能是一次，也可能是兩次。
for 迴圈大概打過幾萬次了，但「從 0 開始還是從 1 開始」這件事，我到現在還是會停下來想一秒。
不是不會寫，是因為這個東西錯起來特別陰。編譯不會報錯、跑起來大部分時候也正常，偏偏就在某個 buffer 邊界、某個陣列尾巴，悄悄多讀一個 byte 或少寫一格，然後在三天後的某個壓力測試裡爆給你看。
這篇就聊聊我自己的判斷邏輯，以及那些讓我學乖的坑。
有一次接手一個前人留下來的 firmware 專案，開機卡在某個地方，重現條件很怪：只有在 UART 收到特定指令、又剛好在某個 timer 中斷觸發的時候才會掛。
追了兩天，最後發現是一個叫 g_status 的全域變數，被三個地方在改：主迴圈、UART ISR、還有一個 timer callback。三方搶著寫，沒有人管同步。
那一刻我就在想，當初寫這個的人，大概也只是想「方便」而已。
做了快二十年 firmware，我一直信「把技術做好，錢自然會來」。
某種程度上沒錯，薪水確實會漲。但前陣子看公司某部門的一些人事變動，我突然意識到一件事:我的技術值多少錢，從來不是我說了算。產業會變、技術棧會折舊、公司會做策略決定，這些我一個都管不到。
那一刻我才認真想：我把所有複利都壓在「技術」這一個資產上，這根本就是一個沒對沖的高風險部位。
這篇不聊選股、不聊賺快錢。我只是想跟還在埋頭寫 code 的同行說一句:花一點時間搞懂錢這件事，可能是你這輩子 CP 值最高的投資。
有一次在專案開發中，需要把收到的封包做 checksum 驗證。邏輯很單純，把 buffer 的每個 byte 加起來，對吧？
我寫了一個驗證函式，丟進去跑，結果 checksum 每次都不對。封包明明是對的，Wireshark 抓出來也沒問題，但我的函式就是算錯。
花了快一個小時在懷疑通訊協定、懷疑 byte order、懷疑硬體……最後發現問題出在 sizeof。一個我以為自己很熟的東西。
簡化後的程式碼大概是這樣：
⚠️ 本文為個人學習與投資記錄，不構成任何投資建議。投資有風險，請自行判斷。
在做指數長期投資的過程中，手上難免會有一些短期閒置資金——可能是等待進場時機、可能是預留的緊急備用金、可能是剛出清某個部位還沒決定下一步。
這些錢不能就這樣放著吃台幣定存的利息，但也不想暴露在太高的市場波動裡。需求說起來很矛盾：波動要小、要抗通膨、風險要低、隨時能變現，最好利率還能贏過台幣定存。
我花了一些時間研究這個問題，最後選了 SGOV 和 VGUS 作為我的現金停泊工具。這篇記錄一下選擇的邏輯。
記得曾經有一次，改了一段看起來超簡單的字串處理邏輯。改完，編譯過了，燒進去跑——直接掛。 不是 crash 那 … 閱讀全文
寫韌體寫久了，有些東西會變成肌肉記憶，手就是會自動打出來。指標宣告完順手 = NULL，這大概是每個 C 工程師的本能反應。
但前陣子在 debug 一個詭異的 crash，追了大半天才發現：問題出在我對 NULL、0、和「指標初始化」這幾件事的理解，其實一直有個模糊地帶。
在一個專案裡，有一段大概長這樣的 code：
struct sensor_ctx {
uint8_t *buf;
uint16_t len;
int (*callback)(uint8_t *data, uint16_t size);
};
void sensor_init(struct sensor_ctx *ctx)
{
memset(ctx, 0, sizeof(*ctx));
// 後面根據設定去 assign buf 和 callback
}看起來超正常對吧？memset 把整個 struct 清成 0，指標欄位自然就是 NULL，之後再根據需要 assign。
這段 code 在我們的 ARM Cortex-M4 平台跑了好幾個月都沒事。直到有一天，同事把類似的邏輯搬到另一個比較冷門的平台上——然後 callback 呼叫就莫名 crash 了。