# Lightning Talk -- 軟韌體合作傳送門：通訊協定設計概念篇 (逐字稿 / 講稿版)

###### tags `Lightning Talk`

---

## 前言

身為純軟工程師，我在系統整合、SI 產業，累積了 “n 個 1 年” 的工作經驗。

技術上雖然沒有成長很多，但是在軟體、韌體的合作上，自己挖坑、踩坑的經驗倒是不少。

所以呢，我想要把踩坑的案例收集起來，整理成一系列的 “避坑” 指南。

## 軟韌體合作有什麼特別的

SI 產業，尤其在設備商、供應商這一塊，有個特別的地方，就是軟體、韌體工程師會一起合作。

而且這種合作，還是程式碼等級的合作，意思是軟體會幫忙寫韌體，韌體也會幫忙寫軟體，或是開發一些小工具。

## 技術選型方式造成的代溝

但是因為軟體、韌體，不論是在系統性質、開發工具的差異，或是生態圈調性的不同，可能從寫程式這件事情上，就會有代溝了。

不過在設計、選型階段，就發現有代溝，我覺得是好事。總比在系統整合的時候，雙方才跑出來 “蛤，這三小” 的疑問，會有更多的挽救機會，更和平的處理方式。

## 從技術選型開始發現代溝

首先，既然是軟韌體系統整合，就表示會有低階和高階的系統，和對應的通訊要整合。

這個時候，兩邊一起參與的技術選型會議，就很重要了。

因為呢，如果只靠 “規格書” 溝通，即使我們有一份很棒的實例化規格，但是背景不同的工程師，其實都不一定能看得懂。

更何況我們也知道，現實中即使是 “傳統”、“正規” 的技術文件，也有很大的機會，不是寫的 2266，就是自己讀的 2266。

所以不如一開始就好好的開會，做技術選型、同步背景知識。在這個階段，也可以好好的吵架、找到問題。

## 背景差異案例 -- 對通訊 “行為” 認知不同

舉例來說，在設備商做軟韌體整合，對軟體工程師來說，經常會用到 “底層” 的通訊協定。

當然了，這個底層，是和軟體、App 工程師，比較熟悉的 “上層” HTTP 通訊，和JSON 格式做比較。

因此軟體工程師，拿到廣義上的規格書後，可能會用上層通訊行為的經驗，來串接底層系統。然後就發生了，人和機器都溝通不良的問題。

譬如軟體會覺得，每次向設備要資料，都會拿到乾淨的資料，而且可以一次拿完。

用 UART、I2C 這類通訊來舉例，你其實得要自己一個字元、一個字元的 “要資料”，還要自己判斷 "payload" 收完沒、前後是不是有不乾淨的資料要丟掉。

因此，在技術選型溝通不良的情況下，軟體用了 “上層” 通訊的觀念，來寫通訊程式，就會覺得韌體有問題、和規格書不符。韌體則是覺得軟體亂寫，是不是在對我的系統做壓力測試。

## 通訊協定設計：基本 “調性” 與技術選型議題

### 確認技術架構與需求

首先，在設計通訊協定的時候，請先確認你們在討論 “哪一層” 的通訊協定，是基於什麼架構。並且趁著在這個階段，趕快吵架、對齊大家的語言。譬如說：

> 韌體工程師聚焦在 CRC, checksum 的議題，忽略了目前用的是 TCP / XML。

> 軟體工程師很開心的做好 gRPC ``proto`` 文件，也想要好好要說服大家使用 gRPC -- 但是始終沒有理解，“這次韌體會用 8051 開發” 是什麼意思。

### 技術選型與設計議題

以下列出在通訊協定設計上，基本的技術選型議題。

通常我們會從技術、資源限制開始 -- 例如只能用 UART 通訊，來規劃通訊協定要長什麼樣子，會有什麼特性。

#### 考慮 Paylaod, Packet

* 誰來處理：人讀、機讀
* 要放什麼：Data, Command, "RPC request"
* 怎麼放：Text, Binary
* 怎麼處理：Flexible, Fixed

#### 考慮系統行為、架構

* Stateless, Stateful
* Push, Pull
* Sync, Async, Event trigger
* Blocked, Non-blocked
* Client - server, P2P, Bus

#### 其他

* Authentication, Authorization
* Encryption, Security
* Binary-safe