比「追逐下一片開發版」更好的投資 — 搞懂通訊協定

比「搞懂板子」更保值的「搞懂通訊協定」

每一塊開發版上除了MCU可能不同之外，周邊、layout也可能不同，因此關連到硬體的程式往往要重寫；就算與硬體無關的程式碼，即便同樣是C語言，也可能因為各家complier不同而需要修改（筆者過去移植離散PID就遇過）。許多開發版前仆後繼地推出、有如「一代拳王」或「一片歌手」般的快速亮相又默默消失，導致過去累積的程式資產無法有效轉移下來。

但通訊協定不同。通訊協定只有演算法、並無實體，且廣泛使用的通訊協定都經過長時間考驗。

除了像是繼電器、LED等少數簡單的周邊裝置可以用單純的Hi與Lo驅動之外，大部分周邊裝置都要透過一連串複雜格式的訊號與MCU溝通，這些「一連串複雜格式」就叫做「通訊協定」，也有另外一種說法叫「介面」。

以下舉例幾種MCU常用通訊協定：

• UART：Arduino IDE的程式碼下載到MCU就是透過UART；MCU與PC通訊也常用；許多藍芽模組也是，只要訊號pin腳命名為Rx與Tx的多數都是。
• SPI：常用來與SENSOR、ADC、DAC溝通用，透過CS pin(Chip Select)可以一對多通訊。
• IIC(I²C)：常用來與SENSOR、ADC、DAC溝通用。特色是一對多通訊時不會增加匯流排占用。
• 1-Wire：常用來與低速SENSOR通訊，特色是input與output都在同一支pin腳上。
• CAN(Car Area Network)：車用的。
• USB：一般Maker不太會碰到，頂多是轉成USB的UART介面。

由於通訊協定具有「西瓜偎大邊」的大者恆大特性，新的不容易制定、舊的也不容易淘汰，因此投資心力在弄懂通訊協定非常保值！

你說搞懂訊號很保值，值在哪裡？能吃嗎？

「都是擴充板（Shield）搞得鬼？」這篇文章曾提到：

為什麼有些人覺得面對電路特別困難？因為純軟問題往往可以靠論壇上的大神高手幫忙隔空抓藥，而且通常還蠻有效的；但替電路debug，若只是把電路照片po到論壇上，通常很難看到問題全貌。得要拿起來左看看、右看看，三用電表這裡量、那裡量，逐個節點收斂問題範圍，這些都是難以隔空協助的過程。

若有心紮根在MCU系統設計，你需要熟悉三用電表、熟悉所用元件每支pin腳的時序圖。這個過程雖然艱辛，但卻是能常保不鬼打牆的護身符。

這個「護身符」除了熟悉電子電路之，另一個就是熟悉各種通訊協定的時序。

如何熟悉通訊協定？

有人說：「如果你想搞懂夜店的妹在想什麼，那就要親自到Gay bar走一趟！體驗各種蒼蠅、蜜蜂從四面八方黏上來的感覺」

同理，如果你想徹底弄懂一個通訊協定，那就要把自己放在CPU的角度，用程式寫，親自拉出每一個周期的Bus clock、親自寫出對每一個Input pin讀取每一個bit、親自對每一個Output pin拉出每一個Hi-Lo level或Falling-Rising edge。

透過這種hard-core的實踐過程，可以建構出你心中的「匯流排小劇場」，往後面對電路問題時，能幫助你更快收斂除錯範圍。

光是call function或交給硬體完成通訊過程的話，你和細節之間永遠都會隔層紗。（就像朋友幫你把的妹，心會在你朋友身上，而不是你。）

以ADXL345為例，CS、SCLK、SDI、SDO四支pin腳都可以用GPIO實作，這4條時序（如下圖）之間必須互相配合才能正確通訊。至於如何達到？端看開發者流程控制的功力，以及對指令周期的熟悉度。

由於這個過程相當辛苦，筆者也不是每種通訊協定都以軟體自幹過，目前只寫過1-Wire和SPI。UART雖然最常用，但軟體實做的價值較低，原因如下：

• 大多數MCU都有內建硬體UART。
• 因UART通訊中沒有明顯的主從關係，bus clock（Baudrate）需要收送雙方事先配合，無法如SPI般由Master端主控；而軟體產生的bus clock並不穩定，故software UART較容易發生資料錯誤。