ＣＡＮ通信の基礎概要

〔マイコンのトップに戻る〕

・ＰＩＣ１８Ｆ２６Ｋ８０のＥＣＡＮレジスタ内容
・ＭＣＣ操作でＥＣＡＮ ２.０Ｂプログラムを生成する
・ＰＩＣとＰＩＣでＥＣＡＮ通信の実験
・ＭＣＰ２５１５モジュールでＣＡＮ通信の実験１(Arduino)
・ＭＣＰ２５１５モジュールでＣＡＮ通信の実験２(PIC)
CAN(Controller Area Network)は、ノイズの塊である自動車内で使用する為に開発されたのが始まりで、
今では様々な分野の電子機器で利用されていて、ISOで国際的に標準化されたシリアル通信プロトコルです

CAN通信は、ライン型(バス型)のマルチマスタ方式で接続され2本の通信線の電圧差(2 線式差動電圧方式)で送信されます。
尚、電圧差があった場合(1.8V：0.9V以上)がビット０で、無かった場合(0V：0.5V以下)がビット１となります。

《ＣＡＮ通信》

高速CAN通信バスの接続概念図

CAN通信バスの概念図

高速CAN(最大1Mbit/s)はリニアバスの両端で120 Ωの抵抗を使用するが、
低速CAN(最大125kbit/s)は各ノードで抵抗(100Ω以上)を使用します。
CANバス上に接続されたデバイスを”ノード”と呼びこの図では２個のノードが有ります。

MCP2561は、第2世代のハイスピードCANバストランシーバでCANのデジタルメッセージデータを
2線式CAN物理バスの差動信号レベルに変換する送受信のインターフェースとして機能します。
又、その他にMCP2551/MCP2562等が有ります。

MCP2515は、CAN通信2.0B規格でCANバスとメッセージデータを送受信する為の通信制御機能を
処理するコントローラで、MCP2515はスタンドアロンですがこの機能を内蔵した物がPIC18F26K80と
なります。
その他にPIC18F2680/PIC16F1778/PIC18F248等が有ります。
又、CANコントローラとCANバストランシーバを一緒にしたMCP25625も有る様です。

CAN通信の特徴としては、

マイコンからメッセージデータを受け取ってもバスが空いている時に送信を行ったり、
全ノードが正常にデータを受信するまでは繰り返し再送されるのでリアルタイム性としては乏しい。

CAN通信ではCANバス上のビットデータを全ノードがサンプリングしてデータ内容を監視しているので
全ノードの同期(CAN 同期：こちらも参照)を行う必要性が有ります。

CAN通信は非同期通信で行われ、送受信するデータはフレーム単位のデータフォーマットで行われます。
データはデジタル信号の"0"/"1"ですが、"0"を dominant(ドミナント) と言い、
"1"をrecessive(リセッシブ) と呼ぶらしい。

それとぉ、CAN通信のプロトコルは低レベルなのでセキュリティ機能がサポートされていません、
必要な人は御自分で何らかな対策を施しましょう。


《メッセージフレーム》

フレームと呼ばれる通信の単位には、 「 データフレーム」「リモートフレーム」「エラーフレーム」
「オーバーロードフレーム」と呼ばれる４つの通信情報を表すメッセー ジフレームが定義されています。

基本メッセージフレームの構 成
基本メッセージフレームの構成図

フィー ルド名
 ビッ ト長
 内 容
SOF
 1
 SOF(Strat of Frame)フ レーム送信の開始を示し、ドミナントで始まる。
※ ノード間での同期(ハード同期)にも利用されます。
ARBITRATION
 12
 アー ビトレーションフィールド
ID(優先度や送信側の識別)、標準 フォーマットなら11ビット長です
(拡張フォーマットなら11+18=29ビット長)
1 ビット長のフレームタイプを識別するRTR(Remote Transmission Request)。
(データフレームはド ミナント、リモートフレームならリセッシブ)
※ 優先順位を決める通信調停にも利用されます。
※ 上位7ビットが全てリセッシブ(1)になる事は禁止されています。
CONTROL
 6
 コ ントロールフィールド
1ビット長の"IDE(Identifier Extension)"と予約ビット"RB0"、
4ビット長の"データレングスコード(DLC)" から構成されます。
DATA
 0-64
 送信デー タ部分で、0〜8バイトの可変長フィールドです。
CRC
 16
 CRC(Cyclic Redundancy Check)巡 回冗長検査 フィールド
15ビット長のCRCシーケンスと1ビット長のCRCデリミタで構成されます。
ACK
 1
 ACKスロット：送信したCRCフィールドまでのデータが正 常に受信出来たかの判断に使用されます。
送信ノード側はリセッシブで送り、受信する全てのノード側が正常に受信したら、ドミナントで上書きされます。
1
 ACKデリミタ：ACKスロットの終了を表します。
1ビット長のリセッシブ固定です。
EOF
 7
 EOF(End of Frame)フレームの終了を 示し、全てリセッシブ固定です。
Interframe
Space
 3
 ITM(Intermission)で3 ビット長のリセッシブ固定です。
通常のメッセージフレームは"SOF"〜"EOF"までで、このITM後が
バスアイドル状態となり次のメッセージフレームが送信可能になります。
※ 拡張フォーマット時は"ARBITRATION"の内容が異なります。

同期（ビットタイミングの項）
各ノードの器機は電源がＯＮした時間等によりシステムクロックタイミングが他のノードとズレてしまい
ます、メッセージデータを送信しても読むタイミングがズレるのでこれを調整する仕組みが必要です。

通信調停
IDの値が小さい方を優先し、同じIDのデータフ レームとリモートフレームが同時に送信された場合は、
RTRで判別しデータフレームを優先します。
又、リセッシブとドミナントの出力がかち合った場合は、ドミナン トが優先します。
そして一つでもドミナントレベルを出力するノードがいると、バスはドミナントレベルになります。


データフレーム

実際のデータを送信する際のフォーマットを 「データフレーム」と呼びます。
データフレームには“標準フォーマット” と“拡張フォーマット” の2種類のフォーマットが存在します。
拡張フォーマットは、CAN 2.0B アクティブ仕様で利用出来、それ以前の仕様ではエラー或いは無視します。

標 準フォーマット

識別子IDが11ビット長(ID)のフォーマットフレーム

標準フォーマット
フィールド名 ビット長 内容
SOF
 1
 データフレームの開始、ドミナント(0)で固定。
ID
 11
 データ内 容や送信ノードの識別子、 メッセージ優先度も表す。
MSB                                      LSB
[10][9][8][7][6][5][4][3][2][1][0]
上位7 ビットがすべて'1'であるID設定は禁止されています。
RTR
 1
 データフレームなのでドミナント(0)をセット。
IDE
 1
 標準フォーマットなのでドミナント(0)をセット。
RB0
 1
 予約ビッ ト、ドミナント(0)で固定。
DLC
 4
 データの バイト数(0-8バイト)
DATA
 0-64
 送信する データ(DLCフィールドにてバイト単位で指定された長さ)
CRC シーケンス
 15
 "SOF" から"DATA"までの演算で行う
CRCデ リミタ
 1
 CRC シーケンスの終了を表す区切り記号、リセッシブ(1)固定。
ACKス ロット
 7
 送信側は 全てリセッシブ(1)でセット。
ACKデ リミタ 1
 ACKス ロットの終了を表す区切り記号、リセッシブ(1)固定。
EOF
 7
 データフレームの終了、全てリセッシブ(1)でセット。


拡張フォー マット

識別子IDが29ビット長(ベースID+拡 張ID)のフォーマットフレーム

拡張フォーマット
フィールド名 ビット長 内容
SOF
 1
 データフレームの開始、ドミナント(0)で固定。
ベース ID
 11
 データ内 容や送信ノードのベース識別子、 メッセージ優先度も表す。
MSB                      
[28][27][26][25][24][23]22][21][20][19][18]
上位7 ビットがすべて'1'であるID設定は禁止されています。
SRR
 1
 代替リ モート要求、リセッシブ(1)固定。
IDE
 1
 拡張フォーマットなのでリセッシブ(1)でセット。
拡 張ID
 18
 ベース ID(11) + 拡張ID(18)の29ビット長識別子
                                                                                    LSB
[17][16][15][14][13][12][11][10][9][8][7][6][5][4][3][2][1][0]
RTR
 1
 データフレームなのでドミナント(0)をセット。
RB1
 1
 予約ビッ ト、ドミナント(0)で固定。
RB0
 1
 予約ビッ ト、ドミナント(0)で固定。
DLC
 4
 データの バイト数(0-8バイト)
DATA
 0-64
 送信する データ(DLCフィールドにてバイト単位で指定された長さ)
CRC シーケンス
 15
 "SOF" から"DATA"までの演算で行う
CRCデ リミタ
 1
 CRC シーケンスの終了を表す区切り記号、リセッシブ(1)固定。
ACKス ロット
 7
 送信側は 全てリセッシブ(1)でセット。
ACKデ リミタ 1
 ACKス ロットの終了を表す区切り記号、リセッシブ(1)固定。
EOF
 7
 データフレームの終了、全てリセッシブ(1)でセット。
※ 赤文字の部分が拡張及び変更されている箇所です。


リモートフレーム

他のノードから必要なデータを受信したい場 合に、「リモートフレーム」を送信する事によって、
そのデータを所有するノードから所定のデー タを得る事が出来るフォーマットです。
リモートフレームのフォーマットは、データフレームフォーマット から"DATA"を除いたフォーマットと
なります。

標 準リモートフレームのフォーマット

標準リモートフレームのフォーマット

フィールド名 ビット長 内容
SOF
 1
 データフレームの開始、ドミナント(0)で固定。
ID
 11
 データ内 容や送信ノードの識別子、 メッセージ優先度も表す。
RTR
 1
 リモートフレームなのでリセッシブ(1)をセット。
IDE
 1
 標準フォーマットなのでドミナント(0)をセット。
RB0
 1
 予約ビッ ト、ドミナント(0)で固定。
DLC
 4
 データの バイト数だが、データは無いので０をセット。
CRC シーケンス
 15
 "SOF" から"DLC"までの演算で行う
CRCデ リミタ
 1
 CRC シーケンスの終了を表す区切り記号、リセッシブ(1)固定。
ACKス ロット
 7
 送信側は 全てリセッシブ(1)でセット。
ACKデ リミタ 1
 ACKス ロットの終了を表す区切り記号、リセッシブ(1)固定。
EOF
 7
 データフレームの終了、全てリセッシブ(1)でセット。


拡張リモートフレームのフォーマット

拡張リモートフレームのフォーマット

リモートフレームを使うと、欲しいデータを得るのに"リモートフレーム"と"データフレーム"が必要になり
バス占有率が上がってしまう可能性が有る為、リモートフレームは使わず定期的(垂れ流し)にデータフレームを送信するやり方が一般的らしい。


エラーフレーム

通信中にエラーが発生した際に送信されるの が「エラーフレーム」です。
送信中のデータ(リモート)フレームは、全ノードが受信しビットスタッフィングルールによってフレームを
監視しエラーを検出したノードがプライマリエラーフラグをバス上に送信します、
でぇ、他のノードはビットスタッフィングルールに違反している事 を検出しセカンダリエラーフラグを
送信します。(但し、CRCエラー時は少し異なる 様です)
又、エラー検出時は送信中のデータフレームは破壊され、ITM後に再送信が行われます。
尚、バス上のノードが一つでも受信に失敗した時は、そのデータフ レームは破壊され全ノードが成功するまで繰り返し行われます。

各ノードは、エラーフラグを送り出した後は1ビットのリセッシブを出力し続けます、
これはバス上がリセッシブレベルになるまで続きリセッシブレベルを検出したら7ビットのリセッシブを
出力(検出リセッシブ1ビット＋7ビットのリセッシブでエラーデリミタとなる)して終了です。

エラーフレーム

フィー ルド名 ビッ ト長
 内 容
エラーフラグ
(プライマリ)
 6
 6ビット長ドミナント(0)を送る(エラーアクティブ状態時)
送受信のエラーカウンタが"127"を超えたらエラーパッシブ状態に
移行するこの場合は、6ビット長リセッシブ(1)が送られます。
エラーフラグ
(セカンダリ)		 0-6
 6ビット長ドミナント(0)を送る
違反検出のタイミングによってはプライマリエラーフラグと被るのでビット長は変化する。
エラーデリミタ
 8
 8ビット長リセッシブ(1)を送る

送 信ノードでのエラー監視

・ビットエラー
　送信ノードが送信したデータとバス上に流れているデータ内容が異なった時に検出されます。
・ACKエラー
　ACKスロットに全ての受信ノードがドミナントを返さなかった場合に検出されます。

受 信ノードでのエラー監視

・CRCエラー
　送信データフレームにはCRC値が有り、受信ノードでCRCシーケンスを計算し値が異なった場合に
　検出されます。
・フォームエラー
　CRCデリミタ、ACKデリミタ、EOFのフィールドは通常リセッシブ固定ですが、何処かにドミナントが
　現れた場合に検出されます。
・スタッフエラー
　ビットスタッフィングルールが守られているかを監視し、連続した6ビットが同じビットレベルの場合に
　検出されます。

エラーカウンタ

送信エラーカウンタと受信エラーカウンタの２つが有り、其々にエラーを検出した時に増加します、
正常に通信が終了すれば減少します。
(送受信エラーカウンタの値増減の話はこちらも読んで置きましょう)
でぇ、カウンタの値によりエラーの状態が”エラーアクティブ状態”・”エラーパッシブ状態”・
”バスオフ状態”の ３つに推移します、以下が推移図です。

エラー状態の推移図
又、送受信エラーカウンタが95を超えると警告が発令されます。

”エラーアクティブ状態”は、通信に正常に参加できる状態 (≦127)です。

”エラーパッシブ状態”時(≧128)にデータを送信する場合は、他のノードが優先ですなのでITM 受信後に
更に8ビットのリセッシブ(サスペンドトランスミッション)後に送信されます。
”エラーパッシブ状態”時にデータを受信しエラーを検出した場合のエラーフラグは6ビット長リセッシブ(1)が送られますが、リセッシブであるエラーフラグは無視されるの で他のノードの通信を妨げません。

”バスオフ状態”は通信に参加できない状態(≧256)で す。


オーバーロードフレーム

受信したデータフレームの処理が間に合わな い場合(受信準備未完了)に、次のデータフレーム送信開始を
遅らせる場合に「オーバーロードフレーム」 を使います。
(昔のマイコンは処理速度が遅かったのでぇこんな仕掛けが今でも残っているのですね)
送信側が送信中のデータ(リモート)フレームのITM送信を終える前に、
処理の間に合わない受信側が オーバーロードフラグ(6ビットのドミナント)を送信します。
他のノードは、ITMの3ビットリセッシブ中にドミナントが現れ たのでオーバーロードフラグを出します。
なのでオーバーロードフラグが上書きされる形となりバス上には7ビットのオーバーロードフラグが出現します。

オーバーロードフレーム


インターフレームスペース

インターフレームスペースはデータ(リモー ト)フレーム間を分離させるフレームです。
ですのでこの間(3ビット長ITM)は次のフレームを送信出来ません、バスアイドル状態で送信します。
又、ITM期間中にドミナントが現れた場合はオーバーロードフラグを送信する必要が有ります。

通 常のインターフレームスペース

通常のインターフレームスペース
エラーパッシブ状態のインターフレームスペース

エラーパッシブ状態のインターフレームスペース

正常なノードは、ITM後に次のメッセージフレームを送信出来るが、
エラーパッシブ状態のノードが送信する場合は、サスペンドトランスミッション(送 信一時待機)後に
エラーパッシブノードは送信出来ます。
(要はバスアイドル状態が8ビット続いた後に送信可能と言う事かな)
これにより他のノードが優先的に送信出来ますね。


《その他》

実際は、上記の様なフレーム構成などはCANプロトコルコントローラが行ってくれるので、
マイコン側は、ID(標準／拡張)とデータ内容にリモート／データフレームのみ行うだけです。

CAN入門書
・VECTORサイトの「はじめてのCAN/CAN FD」がダウンロード出来ます。
・RENESASの「CAN入門」が解り易いと思われたのですがぁ．．．
　なぜだかぁ非公開状態になっています、"CAN 入門書 Renesas Rulz"等で検索をかければぁ．．．




【きむ茶工房ガ レージハウス】
 Copyright (C) 2006-2018 Shigehiro Kimura All Rights Reserved.