車用電子漫談(二A)--- 在STM32 上實現車用常用的匯流排CAN Bus(補述篇)

上一篇很基本的在STM32 上實現CAN Bus 的系統功能驗證，但說坦白的，

這一種文章在網路上比比皆是，尤其是在大陸網站哩，到處都是抄來抄去，

轉貼來，轉貼去的。反正也看不出來到底誰是原作者，而且也好像是貼了交差而已。

也不管後續應用如何。尤其我最近有空也看了 STM32 的 USB 介面說明。

也都沒有更進一步說明，所以我想再補充一點說明，下回有機會我就會整理

說明關於 STM32 中關於 USB 系統介面功能，這一部分如果你之前都完全沒有USB

概念或是相關系統經驗的話，可能也很難上手的。可能就跟這篇 CAN Bus 的情形

一樣的。所以我就會用實際系統應用的觀點來補充說明一下吧。

所謂的 CAN Bus (Controller Area Network) ，其實就是用來連結許多控制器之間的一種

通訊介面，這樣子的文字描述，大家都會講，也都看得懂，但實際他的重點是甚麼？

他跟一般所謂的 SPI/I2C/UART 或 RS232/RS485 等有甚麼不一樣之處呢？

其實重點就是在於他這一種通訊界面是有所謂的"仲裁機制" (Arbitration)的。

這一點大家有時真的很難體會，這一篇文章我會用實例證明給大家看的：

為什麼要有仲裁機制？因為既然要成為控制器之間連結的匯流排，就得要能很輕易

的處理訊號衝突(打架)的問題。因為你真的不知道在這些匯流排上還會有誰會

突然插進來搶頻寬的。而且其他的控制器到底是怎麼完善它的系統應用內容的呢？

這個如果要你用一般的 UART 來寫的話，可能大家就得要先坐下來，開一大堆

協調會議，訂出嚴謹的通訊協定(Protocol)，那還得了，萬一又是不同產品性質，

或不同國家、不同團隊等，那怎麼辦？這一點你就得不得不欽佩一下 BOSCH 在

車用電子系統的遠見了，因為在車用電子系統裡，一定會碰這一種系統應用問題，

引擎控制器需要車速訊號，但可能ABS 控制器也需要同樣的資訊，而彼此之間也

需要連結通訊的交換系統資訊。但不可能大家都在那邊為了通訊介面在那邊每天

開會討論吧。而且在車輛上的所使用的控制系統也不可能只有你一家獨家啊。

那萬一也要接別人的東西時，要怎麼辦？接下來我就用實例演示給大家看一下。

不過首先要先交代一下在 STM32 中CAN Bus 操作模式說明：

這應該也不光只是 STM32 控制器裡有而已，而在一般有CAN Bus 的MCU中，應該

都是一樣的，我說過了：CAN Bus 的矽智財(IP) 是屬於BOSCH 的，所以大家所使用

的設計方式應該都是一樣的。他們為了大家在MCU 上驗證CAN Bus 功能，他有提供了

幾個使用模式：Silent Mode, Loopback Mode 等模式，就是大家在網路上看到的：

因為CAN Bus 是一種有主從架構的互動型通訊介面，它的存在就是為了控制器之間的

通訊連結，如果沒有其他控制器存在的話，這個東西就沒啥系統應用價值了。

但搞MCU 控制器的，為了大家學習驗證方便，他就提供了這幾種算是測試驗證模式

給大家玩玩，不用第二顆MCU 的 CAN Bus 來交代這件事。結果有很多MCU 的入門書，

或網站說明也都只交代到這裡而已。就沒有下文了，為什麼？因為他們可能只是

賣MCU 而已，至於系統應用的問題，就不歸他們了。

當然有些系統應用他們也可能不懂吧。

所以所提供的範例程式如下：

但萬一我想實際用 Normal mode 時會碰到甚麼問題呢？

-----

從影片中，大家可以看到：如果我的程式改寫成 Normal Mode 之後，在CAN Bus 的資料

匯流排上看到的東西，因為發出去的封包，沒有收到其他CAN Bus ACK 訊號，CAN

Bus 就會一直不斷的發出封包。只要有其他一顆CAN Bus 的控制器存在就正常了。
----
所以從這個例子大家就有了CAN Bus 系統基本應用有點感覺了吧。

接下來我們就來看在實際上CAN Bus 在整合許多Controller Area Network 的情形：

上圖中，就代表著有三組不同的 CAN Bus 系統連結在一起工作之情形，有些是我自己的

控制系統，有的卻是別人的系統，當然我們也不清楚別人的系統東西。但因為 CAN Bus

是大家都要掛在一起工作的，

以上這兩張圖是CAN Bus 的系統拓樸圖。當然這種圖在網路上也是一堆參考圖。

大家也都會查得到，也看得懂的。但實際是甚麼？也不一定可以體會得到。

這樣的東西會有甚麼問題？那就是有些控制系統可能會隨時掛上此一匯流排，

加入整個系統之中，我指的是：火線上線。這是有可能的。因為在車用系統中，

每一套系統不一定會同時上線，因為每個系統初始化過程的長度與時間不一。

所以系統就得要容忍這種事情發生，那怎麼辦？那就有所謂的仲裁機制了：

所謂仲裁 (Arbitration)簡單來說：

在匯流排上，ID 小的是有比較高的仲裁取得Bus 使用權的。當然啊，我們自己在開發

相關系統應用時，也不會笨到把自己的ID 宣告成比較低(比較高的仲裁權)的控制器。

因為比較高的仲裁權的控制器的系統能力與責任是比較大的。不要搞死自己吧。

尤其是搞一般設備的。

這是一個簡單的技術說明，接下來就實際演示一下CAN Bus 在複雜控制器系統中

如何簡單的建立 Controller Area Network ：

在影片中：我們一共有三套CAN Bus 系統，有兩套是我自己的，有一套是別人的，

這一套是搞車用一家英國很有名的公司，RaceLogic 公司，有很多車輛測試都是採用

這家公司的儀器設備，他們的測試數據是世界車界所公認的。當然啊~我們的 CAN Bus

一旦要跟這一種國際知名公司的系統掛在一起時，會不會出現問題啊？這個就是

CAN Bus 厲害的地方了，你不用懂人家的系統內部，也不用知會他們，你就可以隨時

整合他們的東西到你所需要的車用系統中了。影片中：ID 0x401/0x421/0x441。

是RaceLogic 他們的系統，我的有一個是 0x7F1 。然後我另一個 0x7F0 是後來上電

加進來的。所以大家可以看到：幾乎無縫接軌的將我的系統與國外系統在CAN Bus

連接中整合在一起了。

這一種觀念有沒有像我們現在所謂的 Open Source 共享的觀念？這樣的東西，是早在

1992 年，三十年前就形成的。你在想想：如果要你用UART 或其他連接介面。如何

簡單又快速地做到呢？

這樣的東西你大概就應該有點概念了吧。透過CAN Bus ，在許多車用應用系統中

我們就不用甚麼東西就得要自己搞得要死，別人有現成的東西你就可以很容易的

整合進來用了。所以我們才可以看到真正整體車用電子應用系統如何蓬勃的

建立發展起來，這個 CAN Bus 在系統應用上，真的扮演著一個重要的角色。

當然啊，如果你有經驗，也懂得如何使用的話。

以上就是一個很簡單的補充說明與演示。

謝謝各位的觀看，下回見。