みなさん、こんにちは。ソフトウェア設計課の林です。
前回のブログでは、前の職務とは畑違いの車載関連のFAE業務に携わることになり、勉強中のマイコンの概要についてお話ししました。
今回は、もう少し具体的な話をしたいと思います。
Infenion社のAURIXマイコンを使ったCAN FD通信を、評価ボード(TriBoard)を使用して実際に行ってみました。
CAN FD(CAN with Flexible Data Rate)とは、CAN(Classic CAN: Controller Area Network)のプロトコル仕様を拡張し、従来のCANよりも通信速度の高速化と送受信データの大容量化に対応した通信プロトコルです。
CAN FDの通信プロトコルの内、 CAN IDなどがあるアービトレーションフェーズでは従来のCAN通信と同じ通信速度で送受信し、データフェーズではビットレートスイッチを行って高速で送受信します。
つまり、1フレームの通信中に通信速度が変わります。もちろん、変えなくても通信できます。
CAN通信では、通信するビットの構成を下図のように定めています。
通信する各ビット内の、論理レベルを判定するタイミング(位置)のことをサンプルポイントと呼び、そのポイントを以下のように決める必要があります。
図1 ビット時間
まず、CANノードの動作1クロック分の時間を1TQとして、通信ボーレートとクロック周波数から1ビットが何TQになるかを求めます。
例えば、ボーレートが100Kbpsなら1ビットは10μsec、動作クロック周波数が20MHzならクロック1周期は50nsecですから、1ビットは200TQとなります。
そのトータル200TQの時間を図1に示すようにTSEG1、TSEG2に配分し、TSEG1とTSEG2の間にあるサンプルポイントの位置(時間)を決定します。サンプルポイントは、ビット長の80%の位置を目安にすると良いようです。この例の場合は、TSEG1=159TQ、TSEG2=40TQとすれば、サンプルポイントが80%の位置になります。
AURIXマイコンでは、TSEG1、TSEG2の値を該当するコンフィグレーションレジスタに設定すればOKです。
CAN FD通信では、自ノードが送信したデータを自ノードで受信して、正常に送信できているかをチェックします。送信してから受信するまでの経路にかかる時間をループ遅延と言います。CAN FD通信のデータフェーズでは通信速度が最大1Mbps以上も可能になりますので、送信したデータを受信するときに発生するループ遅延が問題になります。
受信データは、このループ遅延が1+TSEG1より大きい場合、送信したビットを受信したときには送信側は既に次のビットを送信している可能性があります。このとき、送信ビットの値と受信ビットの値が異なる場合はエラーとなってしまいます。
データフェイズにおいてトランシーバのループ遅延より短いビット時間を可能にするため、トランスミッタ遅延補償(TDC)が実装されています。CAN FDメッセージのデータフェイズ中は、TSEG1 の直後のサンプルポイントでビット値を判定するのではなく、計算したセカンダリサンプルポイント(SSP)でサンプリングします。
セカンダリサンプルポイントは、あらかじめこれぐらいの遅延があるはずだ、と言う値を計算しておき、受信データを判定するタイミング(サンプルポイント)をその分遅らせた位置とするわけです。
AURIXマイコンでは、CAN FD通信の遅延補償コンフィグレーションレジスタにその値を設定してやれば良く、通信速度を上げると送信がエラーになる場合は、この設定値を見直す必要があります。
図2 ループ遅延
これまでの説明以外にも送受信のバッファや割り込みの設定など、各コンフィグレーションレジスタに値を設定する必要があります。しかし、最小限必要な設定を行えば、案外簡単に通信することができます。
TriBoardにはCANのトランシーバーICが2個実装されていますので、1枚のボードでCAN通信の送受信の確認ができます。CANトランシーバーICのCAN-H、CAN-LがTriBoard上のソケットに接続されていますので、ブレットボード用のジャンパ線などでソケット内のCAN-H同士、CAN-L同士を接続すれば、CANノード0とCANノード1で相互に通信できます。
この方法でクラシックCAN、CAN FD(ビットレートスイッチあり、なし)、データ長1バイト~64バイトまで、色々な設定で通信できることを確認しました。
WTIでは、お客様からのご要求に対して、メリット、デメリットをしっかりご説明した上で対応させていただいております。CAN通信を含め、IoT組込み機器の開発で何かお悩みのお客様は、是非一度ご相談ください。
最後までお読みいただき、ありがとうございました。
【関連リンク】
【関連ブログ】
- IoT機器のOTA化が意外と進まない理由とは part3 ~エンベデッドセキュリティはHSM(ハードウェアセキュリティモジュール)がRoT(信頼の基点Root of Trust )に~
- IoT機器のOTA化が意外と進まない理由とは part2 ~エッジコンピューティングへのニーズの高まりとハッキングの危険性~
- Arduinoでイルミネーション制御をやってみた part1
- IoT機器のOTA導入が意外と進まない理由とは
- IoT時代の開発者が知っておくべき組込みセキュリティ対策とは? PartⅡ
- IoT時代の開発者が知っておくべき組込みセキュリティ対策とは?
- 組込みソフトウェア作成時のポイントを紹介します
- Q-Learningでチーズパズルを解いてみました
- ESP32マイコンでOTA! Wi-Fiでプログラムを書き込む
- M5stackで簡易Wi-Fiチェッカーを作ってみました
- 無線モジュール搭載IoT機器の開発には幅広い知見と技術が必要です
- IoT化のお手伝い-ワンストップでアイデアを形にします
- WTIブログ(IoT関連)
- 無線通信モジュールのコストを抑える方法とは
- ソフトウェア開発時のデバッグのお話 ~ ロジアナを使ってI2C通信を解析 ~
- IoTのプロフェッショナルを顧客社内に育成する「テクノシェルパ」登場
【関連動画】
WTIメールマガジンの配信(無料)
WTIエンジニアが携わる技術内容や日々の業務に関わる情報などを毎週お届けしているブログ記事は、メールマガジンでも購読できます。ブログのサンプル記事はこちら
WTIメールマガジンの登録・メールアドレス変更・配信停止はこちら
WTIの技術、設備、設計/開発会社の使い方、採用関連など、幅広い内容を動画で解説しています。