關于阻塞函數和非阻塞函數

在CAN和LIN相關的開發庫里，不可避免的會出現“收”和“發”的函數。如何快速有效的處理數據，是開發中重要的事項。但實際上單路CAN由于波特率的限制，數據量并不會很大：以常用的500k為例，如果按照總線負載率為30%左右，那么需要在1ms處理1~2次數據即可。相比之下常用的以太網一般都要在100M的速率以上了。

因為系統的底層，例如WINDOWS，在處理文件、串口等使用的是同樣的函數，所以CAN、LIN處理起來可以運用這些相關的經驗。回歸到正題，讀寫函數可以分為阻塞函數和非阻塞函數兩種，它們處理起來的方式是不一樣的。

阻塞函數(blocking)：在執行時會阻塞當前線程，通常會有一個超時時間。

非阻塞函數(non-blocking)：不會阻塞當前線程，直接返回結果，通常會有一個對應的緩存。

讓我們舉兩個例子說明：

在UDS的API中獲取ECU返回的數據采用阻塞函數。例如，我們在用27服務獲取seed，如果我們沒有成功獲取seed，那么接下來的步驟也無法進行下去。所以阻塞函數會迫使我們去等待結果；如果執行失敗，需要做錯誤處理，例如重新嘗試進行獲取。

如果阻塞函數的超時時間設置為0，就會和非阻塞函數類似（有些阻塞函數超時時間為0，可能意味著永遠也讀不到數據了，因為它們總是想要讀取來自“未來”的內容）。

在底層的basic API中，CAN的接收采用了非阻塞函數，設備將把讀到的數據放到緩存里，而函數將從緩存里讀取數據。如果緩存里沒有數據，函數會立刻返回無數據，而不會等待“不確定的”下一個數據。也就是說無論何種情況，函數都會立刻返回結果。

在我們處理CAN數據時，可以周期性（例如20ms）讀取數據，讀到無數據之后，做其它的事情，例如通過dbc獲取信號值并顯示。函數不會等待20ms直到新的CAN幀出現在總線上，也防止了丟幀的情況。因為普通的CAN通信，我們無法在程序層面判斷何時會接收到新的數據。

另外，有時我們也會想要保證數據是“新的”，而不是躺在緩存里不知道多久之前的內容，那么在讀取數據前先清空緩存會是一個不錯的選擇。

END

虹科車輛網絡

虹科車輛網絡事業部在汽車總線行業經驗超過10年，與世界知名的CAN、LIN總線供應商PEAK-System、Lipowsky、IHR等合作10年之久，提供領域內頂尖水平的CAN/LIN分析儀和測試方案，同時也提供汽車以太網，時間敏感網絡（TSN）的仿真測試工具和方案。虹科自主研發的EOL測試軟硬件系統已經在業內完成多次安裝和測試，事業部所有成員都受過國內外專業培訓，并獲得專業資格認證，工程師平均5年+技術經驗和水平，一致贏得客戶極好口碑。虹科車輛網絡事業部致力于為您提供最專業的服務。