用 MCP2515 和 NUC131 進行 CAN bus 通訊

CAN bus 是非常古董的通訊協議, 一開始就是設計給車用
這協議蠻特別的, 只要兩條線就可以通訊
i2c 雖然也是兩條, 但是它需要有共同的接地, 所以正確說應該是三條
而 CAN bus 全部就只有兩條, 而且所有在 bus 上的設備都並接在這兩條上
沒有共地沒關係, 蠻神奇的, 而且在這兩條線上還實現了優先權機制, 大家都可收和發
由 BOSCH 這家公司發起, 看到它我就想到電鑽和砂輪機, 因為我這兩樣都買他們家的XD
本篇將試驗透過 CAN bus 回應車用抬頭顯示器, 讓它顯示出假的行車資訊, 驗證車用網路通訊



我還在唸書時就知道有這東西, 但一直沒有去接觸它, 主要原因是沒有設備可以試
常見的玩法是兩顆都帶有 CAN 的 MCU 對接互傳, 但...這沒有 feel 啊！XD
這樣我也不知道它有什麼好處, 如果只是互傳用 UART/i2c 不就好了?
拍賣上雖然有賣汽車零件, 但賣家只會說這可以裝在哪些車上, 至於細節...一概不清楚
直到最近接了車用的專案, 看規格, 對資料, 才了解這東西的特色, 以及其應用
不過這類資料都是封閉的, 所有內容都要簽保密條款, 所以和別人家車子有關的細節我沒法給
但我可以拿一個比較有 feel 的東西出來做實驗, 這東西很多人有也容易買到
而且它用的資料都有公開, 只是因為它不屬於車內設備所以通常不會想到它：

這個是汽車狀態的抬頭顯示器, 屬於汽車百貨, 放在駕駛座前方
可以把資訊投射到玻璃上, 這樣駕駛就不用低頭也能知道狀況
裡面長這樣：

有兩顆 MCU, PIC18F25K80 和 STM8S005K6T6
PIC 應該是作為車用網路界面, CAN 收發器直接接給它, STM8 應該只是處理燈號, 雙核心耶！XD


LED 全部都上白色 LED, 燈號顏色由外面貼紙決定
這樣生產多種顏色的版型就只有一個料品有變動, 不用改貼片料, 聰明的選擇

這玩具雖然安裝在車內, 但我會說它不屬於車內設備原因是它正確說是診斷設備
車內設備會回報當前狀況, 可能是定期廣播或是等別人去問
可是抬頭顯示器則是不斷的廣播詢問, 然後把問到的訊息顯示出來, 如此而已
對於車用網路來說它其實是個囉唆的傢伙, 一直開口問XD
不過由於 CAN bus 本身就有優先權機制, 所以它應該不至於影響行車安全
診斷儀器的優先權很低的, 如果有更重要的訊息, 診斷訊息很容易被蓋過
不過由於它是接在車用網路上, 如果它沒有乖乖遵守協議, 還是有惹麻煩的風險
以我買的這台看來, 收發器是德州儀器的 SN65HVD230, MCU 是 Microchip 的 PIC18F25K80
製造商都是有做車裝的大廠, 而且這兩顆都是車用規格, 所以應該還是能安全使用
雖然不保證韌體會不會有切 GPIO 亂拉的現象...但至少硬體本身體質應該沒問題

要玩 CAN bus 首先要看協議, 這裡有中文+原文資料連結：成大資工 Wiki：CAN
英文 Wiki 也有相當詳盡的資料： CAN bus

硬體部份通常有兩個元件, 一個是 CAN 通訊硬體, 以及一個接在通訊硬體後的收發器
通訊硬體有幾種選擇, 部份 STM32 系列 MCU 有內建, NXP S32 系列 MCU
Microchip 有部份 PIC 系列內建 CAN 的 MCU, 以及獨立的 CAN 控制器：MCP2515
新唐的部份 MCU 也有內建, 最容易取得的是 NUC131 系列
收發器則有 NXP TJA1050, TJA1042 帶有 standby mode, 可以休眠
德州儀器 SN65HVD23x 系列等, 有些是 3V 系統用, 有些是 5V 用
對於 CAN bus 來說, 上面的網頁已經十分詳盡, 我就不重複了
這裡只簡單紀錄一些程式會用到的資料：

CAN bus 優先權由訊息 ID 決定, ID 數字越小的優先權越高
ID 只代表訊息代號, 和裝置位址沒有絕對關係, 沒有一定一個裝置就一個 ID
一個裝置可以發很多種 ID 的訊息, 把 ID 當成位址是更上層協議的行為
CAN bus 本身並不認位址, 任何裝置只要能發某種 ID 的訊息它就會被當成該類裝置
隨時可以加入網路或從網路移除, 什麼 ID 給什麼裝置使用完全由車廠主導
傳輸速度, 取樣點, 用標準 ID 還是延伸 ID 也是車廠主導, 沒有標準
傳輸內容主要有 ID, DLC 內容長度, 以及 8 bytes 資料
只要是傳資料, DLC 不管設多少都會傳 8 bytes, 是固定長度的協議
(更正：資料長度為可變的, 依 DLC 決定)

CAN bus 每次傳 8-byte, 如果只是車內設備回報狀態, 像是門鎖打開, 車燈打開等
對這樣的應用是綽綽有餘, 夠用的了, 不過如果要傳送字串這種比較長的
那就需要分多次傳, 以這 CAN 為基礎的多次傳輸有另一標準：ISO 15765-2
這文件有版權不能放, 請上網搜尋別人偷放的XD 或是去對岸網站買和諧版(?)
所有 ISO 文件幾乎都是如此, 要看是要花錢買的
一次傳輸稱作一個 frame, 中文可翻成 "框" 或 "幀", 框我認為比較是軟體 "框架" 在用
而幀則是影像用, 由於是一筆一筆資料, 可以看成一塊塊的, 我傾向這裡用 "幀"
一個幀可能是 8-byte 的資料, 或是沒資料的資料請求幀, 共有四種幀
若是傳資料的, ISO 15765-2 制定單幀以及多幀傳輸, 共有四種資料幀
當走 ISO 15765-2 時, DLC 一律填 8, 不管裡面有多少有效資料
有效資料數量寫在 8-byte 資料中, 所以會佔用 1~2 byte 來挪作 header 用
若是單幀傳輸, 最多 7 個 byte, 資料長度寫在第一個 byte, 後面放資料
若是多幀傳輸, 第一幀前兩 byte 挪作 header, 共 16-bit, 前 4-bit 填 0x1 表示第一幀
後面 12-bit 則是資料長度, 所以最多可傳 4095 bytes
第一幀傳完後對方回流控幀 (flow control frame), 告訴發送端它的狀況
可以是繼續發送, 或是要求等待, 或是接收端緩衝炸了停止傳輸等
若是繼續發送, 接著發送端就開始塞資料, 這時傳的是連續幀 (consecutive frame)
連續幀只佔用一個 byte header, 前 4-bit 填 0x3 表示連續幀, 後 4-bit 是傳輸序號
從 0x0-0xF 不斷循環, 若接收端發現數字沒有連續就是掉資料了
以上就是 ISO 15765-2 的概略說明, 還有一些細節像是定義把訊息 ID 當成位址的
以及各個傳輸階段的 timeout, 等不到資料時的處理請參考規格書

有了單幀多幀傳輸, 接著在往上, 是通用診斷服務 (Wiki: Unified Diagnostic Services)
以下簡稱 UDS, 一共有兩個標準： ISO 15765-3, ISO 14229-1
ISO 14229-1 是集合體, 包含各種不同的通訊協議, 把它 "Unify" 成單一格式
而 ISO 15765-3 則是這通用診斷服務中屬於 CAN bus 的部份
在 ISO 14229-1 中有個圖表表示下層引用的標準, 我把它簡化繪出：

用於底層的一共有五種協議, 以後可能還會增加
ISO 14229-2 定義到 UDS 的 Session layer services, 再往上疊兩層就是 ISO 14229-1
從 CAN 那欄位看 ISO 標準疊的方式, 應該可以猜到別的通訊方案架構
其中還有 IEEE 802.3 系列的, 表示有廠商拿網路線去用XD
在電腦網路中, 我們希望的是大家共用一種傳輸通道來實現各種不同的應用
來看網頁, 傳檔案, 串流語音影像, 甚至快速自動控制...等
但是 UDS 剛好相反, 它要各家各種亂七八糟的通訊方法中整合出一個通用的診斷服務
讓不同的網路來做同樣的事情：診斷, 設定, 以及更新資料或韌體
UDS 的協議不難, 架構單純, 但是細節很多, 玩法就是第一個 byte 是服務代碼
以我們 CAN bus 版本的 UDS, 我們在 ISO 15765-2 那裡前面第一個 byte 不算
那是屬於 ISO 15765-2 的封裝, 因此若是單幀的情況, 服務 ID 會放在 8-byte 中第二個
這裡我們忽略 ISO 15765-2, 只看封裝中的資料
第一個 byte 是服務 ID, 簡寫 SID, 告訴裝置你想要做什麼, 發出後裝置會返回回應
ISO 14229-1 中有定義什麼時候要回什麼, 可能不會回應, 也可能會有回應
回應有正向的 (Positive, 即是功能成功) 以及負向的 (Negative, 即是功能失敗)
正向的回應第一個 byte 放 SID + 0x40, 負向的則是放 0x7F, 其餘資料該放什麼都寫在標準中
ISO 14229-1 通用診斷是一般設備, 和引擎和排放有關的有另一個標準：ISO 15031-5
如果把 ISO 15031-5 放到上圖 ISO 14229-2 的位置, 那麼它底下會換成：
(ISO 11898 / ISO 15765-4), ISO 9141-2, SAE J1850, ISO 14230-2
意思就是...底下支援的連線又是另一種, 只有 CAN 和 K-Line 是有兩者都有支援
ISO 15031-5 資料內容和 ISO 14229-1 的格式相同, 區別是 SID

出自：Diagnosesysteme im Automobil Transport- & Diagnoseprotokolle 第 20 頁
這個應該是德文吧...應該XD 裡面參雜英文, 可以模糊的(?)推測內容
看起來 SID 0x0-0xF 是 ISO 15031-5 排放相關診斷
SID 0x10-0x3E 則是 UDS, 即是 ISO 14229

以上這堆是從基礎協議堆到診斷協議, 功能是 "診斷"
可是車內一堆 ECU 之間的通訊, 那又是另外一回事了, 有一些用於可靠性的
ECU 間監控, 互動的, 我們這裡就先跳過, 那個我沒有玩過, 而且資料更少, 沒有可測的裝置

如果只是要走標準協議撈出車上的狀態, 有個現成的東西可以買：ELM327

這是一個用 PIC 系列 MCU 做的診斷器, 插到車上的診斷接口, 下命令即可讀取回應
不過車子必須是提供 OBD (Wiki: On-board diagnostics) 接口的車種
這裡有些資料介紹 OBD 接口上有哪些傳輸協議, 以及一些使用該協議的車廠：
Getting Started with OBD-II 
裡面有三四種協議, 非常混亂的世界XD
如果插上去撈不到資料就認命吧, 這也是很正常的, 要確切知道通信方法得看車廠文件

ELM327 是診斷儀器, 抬頭顯示器也是診斷儀器, 它們對接互相診斷是不會有結果的XD
所以我做一個玩具, 給診斷儀器診斷用：


上面 WT-13 的電路圖精簡版：

上圖紅色接腳接給 MCP2515 模組, PB0 作為 CS, 5V 電源由 USB 接過去, 中斷沒接


抬頭顯示器那端我只接四條線, 接腳定義請參考前面 Wiki 的 OBD 頁面
我接 Pin 6,14 那組 CAN (ISO 15765-4 and SAE J2284), 以及 Pin 5,16 電源, 送 12V

控制軟體： usb-can.zip
USB 相關的技術請參考前篇：用 AVR atmega16u2 連接 USB
裡面有兩個東西, usb-spi 目錄放的是 AVR 的韌體原始碼, 燒錄到 atmega16u2 上
mcp2515.c 則是 ubuntu 上用的通訊程式, atmega16u2 燒錄後接上電腦會產生 ttyACM 節點
編譯 mcp2515.c 後執行： ./mcp2515 /dev/ttyACM0
執行結果： MAH04500.MP4

WT-13 作為 USB to SPI 使用, ubuntu 端的通訊程式直接存取 MCP2515 的暫存器
全部用 polling mode, 不斷的去讀 MCP2515 的狀態, 所以這玩具反應會有些延遲
不過我可以任意的改變所有參數而不需重燒韌體, 也不用複雜的協議
程式在完成 ttyACM 連線後用 mcp2515_init() 初始化 MCP2515
設定位元率, 設定接收所有訊息, 位元率我設 250 kbps, 這是試出來的
Wiki OBD 頁面有寫, 250 或 500 kbit/s, 兩個都試一下就有了
比較特別的是我這台設 500 kbps 會嗶嗶叫個幾聲才正常顯示, 似乎認為有錯?
設定位元率時需注意 MCP2515 模組上用的晶振速度, 我買到的是 8MHz
網路上有人說有多個版本, 要根據晶振速度計算, 這裡有個計算機：
CAN Bus Bit Timing Calculator
連這種東西都有XD 可能有很多用戶有這困擾, 不過最好還是自己算過一回
因為到了 MCU 上, 頻率就不再是固定那幾種, 得依照規格去修改

初始化完成後就進入死迴圈, 不斷的用 mcp2515_get_rx_status() 讀取狀態
一發現有資料進來就讀入資料, 然後送給 handle_uds() 回應假的行車資料
我先測試讀取這台抬頭顯示器會問的訊息, 可以發現都是 SID = 0x01 的請求
0x0-0xF 都是屬於 ISO 15031-5 排放相關診斷, 所以我們要拿該標準的文件來查
查詢結果它會詢問：引擎轉速, 引擎溫度, 車速, 進氣壓力, 進氣空氣溫度, 油門位置
我們就依照規格塞一些拉機給它XD 如果塞超出安全範圍的值它會嗶嗶叫警示
g_speed, g_rpm 這兩變數用來放速度和引擎轉速, 每發過一次就遞增, 到最大值後歸零
然後就可以看到抬頭顯示器數字一直跑


接著把功能做到 MCU 上, 這次我選一顆帶 CAN bus 的 MCU：NUC131

可支援 Arduino, 官方有提供 patch, 但根據本實驗室傳統這些都......刪除！XD
接著把板上內建燒錄器切除, 改用我的 ST-Link v2, 板上有 DC 輸入, 但後面掛了 7805
DC 2.1 也是本實驗室常用規格, 我有庫存一些這種接頭, 也有 5V 變壓器
7805 不是 LDO, 會需要 7V 以上才能穩壓成 5V, 我已經有 5V 穩壓了這東西就擋路
於是把穩壓拔掉, 直接短路 5V 直入, 變成這樣：

這樣就夠用了！
接著是開發環境, 和前篇 在 ubuntu 上開發 nuvoton m051 實驗板  完全一樣
把啟動程式和 ld 腳本改一下, 然後 openocd 要小改
NUC131 這顆 MCU 並不在 openocd 列表中, 燒 flash 時會有問題：

> flash write_image erase test.bin 0                 
auto erase enabled
Device ID: 0x10013110
NuMicro flash driver: Failed to detect a known part

auto_probe failed

無法燒錄, 認不到 flash, 改這個只要把標紅色的 ID 複製下來然後新增到列表中
修改：openocd-code/src/flash/nor/numicro.c

static const struct numicro_cpu_type NuMicroParts[] = {
    /*PART NO*/     /*PART ID*/ /*Banks*/
    /* NUC100 Version B */
    {"NUC100LD2BN", 0x10010004, NUMICRO_BANKS_NUC100(64*1024)},
...
    /* NUC131 */
    {"NUC131SD2AE" , 0x10013110, NUMICRO_BANKS_NUC100(64*1024)},

    {"UNKNOWN"     , 0x00000000, NUMICRO_BANKS_NUC100(128*1024)},
};

加一筆資料到 NuMicroParts 這陣列中, 加在 "UNKNOWN" 項目之前任意地方都可
然後重新編譯即可使用

這裡放出韌體源碼：nuc131-can-linux.zip
裡面有四個目錄：

keil-inc：Keil 抽出的 header, 新版和前篇有不少改變！
test：點 LED 的範例, 執行結果同上圖
can-bus：收到 CAN 訊息後會原封不動回傳
can-uds：把前面送假資料給診斷器的整套系統做到 NUC131 上


can-bus 範例：

NUC131 外接一個 CAN 的收發器
用前面做的 usb-can 不斷發資料給 NUC131, 然後收 NUC131 返回的回覆
ubuntu 端執行結果：

I(main):open uart...
I(main):setup uart...
D(mcp2515_reset):hw reset
 <-  ID(STD) :7df #8 00 01 02 03 04 05 06 01
  -> ID(STD) :7df #8 00 01 02 03 04 05 06 01
 <-  ID(STD) :7df #8 00 01 02 03 04 05 06 02
  -> ID(STD) :7df #8 00 01 02 03 04 05 06 02
 <-  ID(STD) :7df #8 00 01 02 03 04 05 06 03
  -> ID(STD) :7df #8 00 01 02 03 04 05 06 03
 <-  ID(STD) :7df #8 00 01 02 03 04 05 06 04
  -> ID(STD) :7df #8 00 01 02 03 04 05 06 04
 <-  ID(STD) :7df #8 00 01 02 03 04 05 06 05
  -> ID(STD) :7df #8 00 01 02 03 04 05 06 05
...

can-uds 範例：

NUC131 收下所有收到的幀, 然後看裡面的訊息 ID, 如果是 0x7DF 就丟給 handle_uds() 去回覆
7DF 是網路上找到的常用診斷 ID, 在 ISO 14229-1 裡有寫到, 但為什麼是這數字就不清楚了
只知道這個數字在 11-bit 的標準 ID 來說已經接近最大值, 意思就是優先權非常低

這玩具做完整理完後, 同事整理資產找到這個：

這東西是 ECU Simulator, 就和我做的東西一樣, 收診斷設備的訊息然後回應假資料
這個是商業品, 完成度較高, 可以透過旋鈕輸入改變回報的車速和引擎轉速等資料
而且附有 OBD 接頭, 這東西不好買, 把我買的抬頭顯示器插上去, 它就會動作



今年接的案子最勁爆的就是車載, 這是多人專案, 而我處理的項目是 MCU 中的一部分
以往 MCU 我只是當興趣在使, 現在突然轉主力項目, 長官本來沒要我做, 只先問有沒有興趣
我想這專案用的 MCU 我有玩過接近的, 而且挖的深度也夠, 還算有信心, 就接了
順便驗收技能等級, 自我驗收結果是應付一般問題都還行, 但缺乏 OS 相關的經驗
畢竟業餘玩具都是簡單的, 沒有 OS 需求, 不像這專案把 MCU 所有腳都用上了
接了一大堆設備, 還要處理複雜的協議, 非常變態, 因此一定要多工
多工不僅僅是平均切割各個工作耗的時間, 也同時切開專案內容, 讓多人可以開發各自的部份
但也因為多了多工, 有些思維必須改變, 面臨的問題也不相同

車載電子的生態非常封閉, 想買料對方都會要求告知專案車種, 文件都要簽保密
料件全部都要寬溫, 最少 -40 到 +85, 美國規範則是 +125
做出來的產品驗證不容易, 而且還有法規管束, 裡面的廠商不多
而車廠大多有固定的合作夥伴, 就算努力做出來了, 也很難打入這市場, 因為根本沒有訂單
由於可選的項目不多, 料件用途都有固定市場, 看你買的料就可以大概猜到你想幹麻XD
這大概是車上裝置沒看到太多人在玩的原因, 因為根本沒什麼可玩
最多讓用戶裝個電腦, 裝個行車記錄器, 或是多幾隻攝影機來個環景合成
想收車上設備發出來訊息或是控制它們? 沒門！
福特汽車有一個開放計畫 The OpenXC Platform
讓用戶可以從診斷接口獲取更多的訊息, 但參與的車廠就只有他自己XD
目前找到的資料大概就是診斷接口撈資料, 撈一些 UDS 訂的基本資料
如果想在車上做些花樣, 和車廠合作是必須的, 要加入他們的圈子, 要有門票才行
所以基本功反而是最重要的, 對 MCU 基本原理要很清楚, 當有一些奇怪的要求時才知道怎麼做
至於怎麼創新, 怎麼做整個方案, 等拿到門票再來想也不遲, 因為能搞的花樣其實沒很多
光是用料限制就足夠綁手綁腳, 在加上法規限制, 沒門啊
這個生態和 IoT 很像, 做不做的出來反而是其次, 有沒有單才是重點
所以我沒有花太多心力在 IoT 上面, 玩了一些方案, 然後就放著, 隨風而去XD