CAN通信させてみた(BeagleBoneBlack-RaspberryPi 間) - その1(1/3)
概要
BeagleBoneBlackとRaspberryPiの間でCANを利用した簡易通信実験ができるようになるまでに必要な情報をまとめた。
ほぼ先人の情報を参考にしてできたので、内容的には、その際に使用した参考にしたサイトを中心に紹介し、自分で実際にやってみて、間違えたところやうまくいかなかったところ、気づいた点などの情報を追記する形式とした。
初回は、CANのプロトコル仕様について。
背景
モータードライバをCANでコントロールする必要に迫られ、とりあえずCANってどういう仕様?というお勉強から、具体的に動かすために何が必要か(エレキ、ソフトウェア)の調査、実際に作ってみて・buildして実験まではできたので、それをまとめてみることにした。
環境
PC: Ubuntu14.04 64bit (RasPi kernelのクロスコンパイル用)
仮想系。母艦はMacBookProのVirtualBoxとWindows8.1のVMwarePlayer
ロジックアナライザ: LogicCube(LAP-C16032)
StrawberryLinuxや秋月などで10k-12kほどで買えます。マルツでも買えるけどプローブが2個しかついてないみたい。
(マルツの方が安いのでプローブ持ってる人/使わない人は、そちらでいいかも)
リンク
まずは、CANの仕様について以下のサイトでお勉強してみた。
序章含めて全7回分あり、以下の4回を中心に読み進めた。
- CANプロトコルを理解するための基礎知識 (1/2) - MONOist(モノイスト)
- CAN通信におけるデータ送信の仕組みとは? (1/3) - MONOist(モノイスト)
- CANを理解するうえで欠かせない“フレーム”の知識 (1/3) - MONOist(モノイスト)
- 実装や試験で役立つ物理層から見るCANの仕組み (1/3) - MONOist(モノイスト)
上記サイトから、CANの特徴を表し重要と感じたキーワードをピックアップすると以下。
使う分には、ざっくりと以下の意味と背景を知り、トラブルが発生した時にキーワードが思い出せれば最初の段階としてはいいのではなかろうか。(と勝手に思ってる)
- ライン型構造
- マルチマスター方式
- CSMA/CA
- IDを使用したメッセージ・アドレッシング
- 耐ノイズ性に優れた物理層
- エラー検出メカニズム
- データの一貫性
- ドミナントとリセッシブ
- 同期
- ビットスタッフィングルール
- データフレーム
- (リモートフレーム)
- エラーフレーム
- (オーバーロードフレーム)
- コントローラとトランシーバ
感想としては、基本的には、IDとデータがあれば通信できると理解。
それをうまく動かす工夫として、ドミナントの意味と背景、ビットスタッフィングルールとエラー処理あたりがよく考えられてるなぁと感じた。
2線式だが低速の時は、1本切れても通信できたりも。
次回は、RasPi側のCANエレキ、ソフトの準備などについて記載予定。徐々にまとめる予定。