發表文章
我之前已經在一些文章有稍微帶到關於 CAN Bus 的一些概念：
USB DIY--自學計畫_CAN Bus Application (一) --- 前言
不過，可能大家只要看到標題： USB DIY ，就可能認為這個東西應該還是屬於
USB 的系統應用範疇，或是認為這些平台離我真的太遠了，我可能真的用不到了。
CAN Controller：MCP2515 ，其實我後來也有整合做了一塊PCB ：
但這一種做法，真的不太親民了。為什麼？來看看我跟我在大陸朋友的微信：
我也知道我在系統應用上，早晚還是會碰到 32 bits 的MCU 的。--- 尤其是 STM32 。
就在前天，我終於向現實低頭了：開始架設 STM32 。並不是我要排斥 32 bits MCU，
而是真的要在系統應用上，真的需要才有必要啊。否則幹嘛給自己添麻煩呢？
我不是也沒有用過其他的 32 bits MCU 啊。做車用的 32 bits MCU 還有一款：
一樣是 ST 產品，只不過，人家真的是真正車用的 32 bits MCU ： SPC560 系列。
所以我其實已經在這兩種不同平台上去實現 CAN Bus 的系統應用開發。
只不過，要在 STM32 上再搞一次而已。對我們來說：上手一顆MCU 需要很久時間嗎？
有時真的不是我們不想碰，而是真的要看到真正的應用才有用啊，要不然搞這麼多MCU
要玩死自己嗎？好吧，既然人家都勸我說了，真的現在一顆 STM32F103 便宜到、
或是說或多到滿街都是了。那幹嘛還要那麼堅持呢？那就開幹了囉：
就去新竹光復路的電子材料行直接去買一片帶有CAN Bus 的 STM32 平台的板子吧。
也不用再洗PCB ，就可以直接架起來開始寫程式了吧：
套一句上述微信中朋友所說的：現在搞 MCU 平台最簡單了啊：只要在網路上搜尋一下
Open Source 範例，抓下來稍微改寫編譯一下就可以搞定了。
這也沒啥大學問的，主要還是在於系統的Debug 與驗證吧。這時候可能還是需要周邊
的一些輔助環境，其實 CAN Bus 在車用系統的標準接頭是就是傳統RS232 用的DB9 接頭：
幸好這個接頭在這個領域裡還有一些系統應用，否則早在PC 周邊市場裡，已經不知道
早就被USB淘汰多久了啊。
基本上，CAN Bus ,只需要 CANH 及 CANL 即可，不太需要有GND，但我們有時為了
量測訊號檢測時，還是會需要GND 的，所以我們一般還是會接上GND 的。
接下來就是系統程式驗證了：
---
-----
其實這個程式很簡單，就是固定的送 8 組資料數據，然後最後一筆加入滾動效果，
以便我們觀察數據的動態傳輸。就這樣子，兩天就可以搞定一個新的MCU 系統
開發平台，並把我們所需要的介面打通。
其實，後續才是我們在系統應用上的挑戰，因為這些屬於 MCU 基礎應用對我們
這一種老鳥工程師，真的沒甚麼困難的。而是你要在系統上如何去發揮這個
CAN Bus 在車用系統上的功能，包括了其實在車用系統上，也是可以透過CAN Bus
來進行所謂的 IAP (In Application Programming) 的。這一點大家可是比較陌生的。
這在ISO(SAE 規範中是有定義的：)
這個我在另一篇文章中有稍微提過：他在規範中的命令組也是有定義的：
都只是很基礎功力而已，主要還是要如何在真正車用系統中如何發揮而已：
最後我就用一小段利用CAN Bus 在實際機車控制系統中開發的影片作為結尾：
-----
---
結語：在不同的MCU 平台上去開發系統，寫韌體程式，這些都不難，只要時間就可以了，
有經驗的，進入時間短，沒經驗就需要多一點時間磨練。
車用系統需要一些特殊經驗的累積，也不是光靠自己想像就可以，這些東西在全球車用
系統中，都有其規範可以依循，這也都需要時間去研讀與實現。
搞車用系統沒有捷徑，道理就是那麼簡單而已。
========================
PS ： 關於CAN Bus 的技術內容，因為他的規範標準已經出來超過二十幾年了，
(都比USB 早很久)，市面上或網路中，也有很多文章內容可以參考，有沒有特別
需要留意的地方？我個人認為應該沒有。
在MCU 的技術應用領域中，常用的連結介面有：I2C、SPI、UART、USB 及CAN 。
I2C 及 SPI 是屬於比較是小範圍，IC 與IC 或小模組之間的連結， 它們有主從觀念，
而且一開始就得要定義明確，傳輸內容沒有任何資料檢查機制。
UART (延伸常用的有RS232、RS485 及DMX512 等)，也沒有很強的資料檢查機制，
對於內容格式也沒有一定的規範，沒有主從觀念，他只能算一種很基礎的連結介面。
至於USB 及CAN 都是屬於差動訊號的連結，對於惡劣環境來說都有一定的抵抗
能力，所以在使用上就一定得要用 Transceiver，而一般來說，USB 的Transceiver都是
內建在芯片中；但CAN 不是，他的Transceiver 是要額外外掛的。
USB 及CAN 的通訊都沒有帶有時脈(clock) 同步機制，它們完全是靠定義的Baudrate
來決定的，USB 一般是固定的Baudrate ，無法調整，但CAN 可以視使用條件調整。
這兩者在資料傳輸封包中都已經含有資料檢查機制，都是屬於CRC 方式。
USB 有主從觀念，也是一開始就得要定義清楚，是固定的沒辦法改的。他的通訊內容
與封包應該是這些介面裡最嚴謹的，所以它的系統完善工夫也最大，維護也不容易，
所以一般人真的不容易維護，但她卻是對於與PC 之間的連結最成熟也成為最大宗
應用市場。所以在應用上跟PC 端的應用軟體有很大的關聯性。
CAN 有主從觀念，但不是一開始就定義的，主從觀念是視應用條件而改變，增加了
在系統之間使用彈性，CAN 只有定義封包格式，對資料內容沒有強制的要求與規範，
從這一點可以說是介於 USB 及 UART之間，所以他在韌體系統尚不需要有額外的
維護能力，但這個介面也不太可能能像UART 用韌體程式來模擬的。所以CAN 的介面
就得要倚賴MCU 芯片商來提供了，但我我認為市面上在不同的IC (芯片)中 的CAN
的定義都是一樣的。因為CAN Bus 這個東西的IP 智權是屬於 BOSCH 的，
您會發現市面上所有帶有CAN 的 MCU 之暫存器(Register) 的定義幾乎一樣的。
所以只要你懂了某一個IC 的CAN Bus 實現功能，對於其他平台的CAN Bus 介面
應該都是大同小異的。關於CAN 使用環境從小到兩個MCU之間，大可以到整個工廠
自動化，如果你沒機會體會CAN 在系統使用上的優點的話，真的就比較難接觸到
此一介面，但在車用應用系統中，他真的有其獨特的使用條件，他所延伸的周邊系統
，包括著軟硬體與許多設備，已經儼然是一個完整又成熟的產業標準了。
所以人家之所以會把CAN 納入新一代 32 bits MCU ，尤其是STM32 這樣大宗MCU
市場中，還是提供了CAN 介面，或許也是一個道理吧。
關於車用電子應用系統，有一塊很重要的系統驗證領域工作，測試是非常倚賴系統
中MCU 與外界之連結工作，這一部分CAN 就扮演著非常重要的角色，也幾乎說：
沒有了CAN ，還真的不知道怎麼搞車用電子系統？
在這一部分只要你有機會接觸到這方面的系統時，你大概就會體會得到。
從以前、目前與未來來說：人家CAN 能在這一塊領域站穩這一個領先地位不是沒有
道理的，主要還是在於你要怎麼用CAN Bus 吧。
這是我的經驗，分享給各位。
謝謝
(待續)
沒有留言:
張貼留言