CAN FD に挑戦

Analog3 プロジェクトでは、ハードウェアは FDCAN 対応が進んできました。が、設定の方がまだでせっかくの FD 機能が使えてなく宝の持ち腐れでした。が、現在、モジュールのフレームワークを Embassy に引っ越しているのでファームウェアも書き直し、今が CAN FD を導入してしまう絶好の機会です。CAN FD 規格については知らないことや、かねてから疑問だったことが結構あるので、最低限の設定を試してみて、感触をつかむことにしました。

CAN FD とは何?なんで使いたいの?

CAN FD とは Controller Area Network Flexible Data-Rate が略さない名前で、CAN 2.0、いわゆる Classic CAN の規格を拡張したものです。どんな拡張がされているのかというと、主に二点

  • フレーム送信中ビットレートを切り替えて、データ部を高いビットレートで送ることができる
  • データ長を最大 64 byte まで伸ばせる

Analog3 で注目しているのは前者です。何故かというと、Classic CAN の通信速度は意外と遅いからです。バスのビットレートは最大 1 Mbps、レガシー MIDI の通信速度は 31.25 baud ですがこれは実のところ 250 kbps です。つまり CAN はレガシー MIDI より 4 倍速いバスを使っていますが、IDや CRC などデータ以外に送るフレーム部分のオーバヘッドが大きいのです。Analog3 のリアルタイムメッセージでよくある 2 byte のデータ長で送信した場合、1 メッセージを送るのに約 62 μSかかってしまいます。レガシー MIDI はバスは遅いものの 1 メッセージを送るのは通常 2 byte で済みます。1 メッセージを送るのに必要な時間を計算すると 64 μS です。ほぼ Classic CAN と変わらない。Analog3 では MIDI よりも忙しくバスを使う予定なので、輻輳するのではないかという懸念があります。そういうわけでデータを高いビットレートで送れる CAN FD を試してみたいわけなのです。

nominal bitrate = 1Mbps, brs = 0, dlc = 2, elapsed = 61.9 μS

ビットレートを上げるには

詳細は別記事を書くかもしれませんが、CAN FD ではフレームのヘッダの FDF (FD Format) ビットを recessive にすると (CAN 2.0 では reserved bit の位置で、dominant にするように決められている)、FD フォーマットでの伝送が始まります。ビットレートを切り替えるにはこれだけでは不十分で、続く BRS (Bit Rate Switch) ビットをセットする必要もあります。こうすると、BRS も含めて高いビットレートに切り替わります。これでノード同士の同期をとるのだからすごい離れ業です。

実際にやってみた

まずは 2 Mbps から。ロジックアナライザのキャプチャをよく見るとデータ部と CRC 部分のビットレートが高くなっています。メッセージ送信の所有時間は 51.86 μS、全然十分じゃない感じがしますが短くなることは確認できました。

arbitration = 1 Mbps, data = 2 Mbps, dlc = 2, elapsed = 51.86 μS

4 Mbps ならどうだろう?39.5 μS に短縮、いいぞー、

arbitration = 1 Mbps, data = 4 Mbps, dlc = 2, elapsed = 39.5 μS

これぐらいのビットレートになってくると、ビットレートの切り替えがはっきり見えるようになります。

下はビットレート切り替え前後を拡大してみたところです。BRS からビット長が短くなってます。

データ部に続いて CRC も高いビットレートで送りますが、ACK のところで通常の 1 Mbps に戻ります。

さてそれでは気をよくして 6 Mbps を試してみましょう。

arbitration = 1 Mbps, data = 6 Mbps, dlc =2, no propagation delay compensation

エラーになってしまいました。何が悪いかというと、ビットレートが高まると伝送の遅延が無視できなくなるのです。下図でも rx と tx がかなり大きくずれています。CAN コントローラは送信データを自分自身の rx でも確認して、送信内容と一致しなければエラーになります。

エラーは続けて dominant または recessive (CAN のエラーについては勉強中です) を padding bit の間隔より長く維持するものです。

CANFD コントローラにはたいてい Transceiver Delay Compensation (TDC、伝送遅延補償) という仕組みがついていてその機能を使ったところ、今度はうまく通信できました。35.3 μS、もともとの約半分の伝送時間になりました。

aritration = 1 Mbps, data = 6 Mbps, with propagation delay compensation, dlc=2, 35.3 μS

TDC は tx と rx の間の遅延を測定してサンプル点をずらすというただでさえ離れ業の FD の中のさらなる離れ業を行います。別ページに詳しい解説を書きました

ここからさらに 8 Mbps にも挑戦したいですが今のところうまく行っていません。マイクロコントローラのクロックに RC オシレータを使っているのがいけない模様。検討の続きに必要な部品を取り寄せ中なので高ビットレートチャレンジは今回はここまで。

互換性のないノードが混じるとどうなる?

互換性のないノードの可能性は二種類

  • Classic CAN のみ対応で FD に対応できない
  • ビットレートが違う

これらがネットワークの中に混じってしまったらどうなる?というかねてからの疑問があったので試してみました。下は、一番左の列のノードから一行目に書かれている種類のノードにフレームを送ったらどうなるかを示した表です。

sender / receiverCAN v2CAN FD 2 MbpsCAN FD 4 Mbps
CAN v2okokok
CAN FD 2 Mbpsignoredokerror
CAN FD 4 Mbpsignorederrorok
  • Classic CAN から同じ Classic CAN や FD ノードへは問題なく送信できる。FD ノードから Classic のフレームを送る場合も同様
  • FD ノードから Classic ノードにメッセージを送ると Classic ノードはエラーとなるが Passive Error ならバス全体がエラー状態になることはないので通信は継続できる。ただしバス上に FD フレームを認識できるノードがないと Ack がなく送信エラーになってしまう(エラーの扱いは勉強中)
  • ノード同士ビットレートが異なるとバスエラーになり回復不能な状態に陥ってしまう。厳禁

対応ビットレートが違うと通信できないのは容易に想像つきますしやる理由がありませんね。Classic ノードが混じった場合、バスが破綻することはなさそうですがエラーハンドリングの設定次第かもしれません。要さらなる勉強

Comments

No comments yet. Why don’t you start the discussion?

コメントを残す

メールアドレスが公開されることはありません。 が付いている欄は必須項目です

このサイトはスパムを低減するために Akismet を使っています。コメントデータの処理方法の詳細はこちらをご覧ください