# Lightning Talk -- 軟韌體合作傳送門：Non OS 程式碼 mob programming 篇

###### tags: ``Lightning Talk``
___

## 前言

作者是非本科系出身的 SI 產業純軟工程師，為了可以和韌體更順利的合作 -- 包括偶爾幫忙開發、偶爾有效率的吵架的這種合作模式，因此開始研究 C 語言，和軟體、韌體一起 mob programming 的可能性。

至於為什麼要用 mob programming 而不是 pair programming？

這是因為韌體和硬體工程師，早在 XP programming 出現之前，其實早就在用 mob programming 了方式開發了。

## 我對韌體的簡單分類

* Non OS：泛指單晶片韌體開發，也是我在工作軟、韌體合作的起點
* OS based：通常也稱為系統工程師，需要寫系統程式、使用甚至修改 OS 核心 API
* Middlware：在硬體抽象層、platform “上面” 的開發工作。例如 React Native 的 Native Module，Android AIDL

## 軟韌體在 Non OS 平台 mob programming 的入口：FSM 有限狀態機與多工程式開發

### 問題背景

不論是軟體還是韌體程式，真正在執行的時候，都可以視為一個重複執行的 “大迴圈”。這個大迴圈當中，有很多 “做一件事情就讓出執行權限” 的運算式、函數，目的是讓大家都能夠輪流使用 CPU，實現多工程式，讓大迴圈的每一個函數，看起來都有在一起工作。

在 OS based 的軟體開發，如果要做到多工、同時執行的效果，有 OS 的排程器、好用的執行緒 API，可以幫助我們無痛寫出這樣的架構。但是在 Non OS、單晶片的環境，則需要自己設計這種輪流使用 CPU 的程式。而這種程式或是函數，通常會設計為 non-blocked 的架構。

你也可以使用第三方的多工 library，但是別忘了 “使用 libray 的程式”，也就是最外面的大迴圈，也需要用 non-blocked 的方式去使用 library。

### 討論範圍

#### 有限狀態機實作 (FSM)

從上面的討論中，我們知道要寫一個大迴圈，然後讓迴圈中的運算，盡量不要佔用太多時間。在實務上，我們會使用有限狀態機 -- 也稱為自動機，讓這個大迴圈可以真的像個機器一樣標準化、自動化，被重複使用。

一個理想的 FSM 架構，只要將狀態表、對應的函數填好，就可以工作了。而不是每次修改，都需要手動在大迴圈中，用一堆 if ... else 修修改改。

#### 如何驗證 non-blocked

這邊指的是靜態驗證。當你在開發韌體程式，使用某些平台 HAL API 時，如何確認這些 API 和你的程式，確實是 non-blocked 的行為模型。

可以想像我們除了要去看文件，搞懂自己用的 API，還需要一個可以 non-block 的單元測試框架。如果有預算的話，還可以用上一些硬體除錯工具。

#### 效能量測

會談到兩個部分。

第一是可維護的架構。良好的架構和效能，兩者並不是互斥的關係。事實上，良好的架構不但能更容易掌握、驗證程式的效能，還能帶來提升開發效率、容易維護的好處。

第二是如何分析、量測效能。這關係到後續的負載、壓力測試，如果我們沒有 overhead 的數據，就不能進行有意義的效能測試。

#### Lock-free 和 lock-less

由於在 Non OS 實作 lock-less 很簡單，學習成本也低，因此順便了解一下什麼是 lock-free。

### FSM 快速入門 (實作開始)

#### Function pointer

#### Co-routine and ``static`` variable

#### Interrupt

#### 定義一個~~很鳥的範例~~ state ``struct``

#### 來寫*大迴圈*

### 單元測試框架與 non-blocked 驗證

#### Unit test / Google ``Googletest``

### 如何量測 overhead

#### 為什麼會量到不準確的 overhead

#### Non-blocked logging

#### ICE tools ($$$)

### Lock-less

#### Context switch

#### DMA

#### Atomic, ``__LDREXB``, ``__STREXB``