バックナンバーはこちら。
https://www.simulationroom999.com/blog/model-based-of-minimum-2-backnumber/
はじめに
前回はXCPonCAN-FDに対応すべく現状の仮想ECU、仮想HILS構成を再確認。
結論としては
- CANのところをCAN-FD化
- XCP経由で変数のやり取りをしている部分を32bit化
当然動作確認もする必要があるが、python-can、PyXCPを駆使してなんとかする方針。
今回は、AUTOSAR-XCPのCAN-FD対応について。
登場人物
博識フクロウのフクさん
イラストACにて公開の「kino_k」さんのイラストを使用しています。
https://www.ac-illust.com/main/profile.php?id=iKciwKA9&area=1
エンジニア歴8年の太郎くん
イラストACにて公開の「しのみ」さんのイラストを使用しています。
https://www.ac-illust.com/main/profile.php?id=uCKphAW2&area=1
AUTOSAR-XCPのCAN-FD対応に向けての方針
まずはAUTOSAR-XCPのCAN-FD対応をやるわけだけど、
どこをどうすればいいんだ？
うーん、そうだねー。
まずはCanIfに相当する部分。
次にXCPのMAX_CTO、MAX_DTOの変更。
ってあたりかな。
CanIfに相当する部分の修正が必要なのか・・・。
結構面倒そうだなぁ・・・。
いや、たぶんそうでもないよ。
実は最初からCAN-FDを想定した作りにはしてある。
何しろCAN-FDの実験をしたときのCanTpで使用したものを持ってきてるからね。
そういう意味では部分レベルではCAN-FDの実績はあるものを使っているとは言える。
そっか、CanTpの時にもCAN-FDはやってたもんね。
確かここらへん。
CanIfのCAN-FD対応の勘所
といっても、どこらへんがCAN-FD対応なのかは示しておこう。
確かに、知らんうちにCAN-FD対応されてた。
では、なんかあった時に困るもんね。
ポイントは受信割り込み時のところになるな。
int rx_interrupt(void *param, vcanMessage* msg)
{
_WaitForSigleObject(hMutex, -1);
// for CAN-FD
static const uint8 cantp_canfd_dlc_snd_table[] = {
0U, 1U, 2U, 3U, 4U, 5U, 6U, 7U,
8U, 12U, 16U, 20U, 24U, 32U, 48U, 64U,
};
XcpInfo.SduDataPtr = msg->Data;
XcpInfo.SduLength = cantp_canfd_dlc_snd_table[msg->Dlc];
if (msg->Id == 1) {
Xcp_CanIfRxIndication(1, &XcpInfo);
}
_ReleaseMutex(hMutex);
return 0;
}
そういえば、cantp_canfd_dlc_snd_tableってのいて、ちょっと気になってはいたんだよな。
これでDLCを実際のデータ長に変えてる感じ？
そうだね。
CAN-FDの場合、8以下の場合はDLCとデータフィールドのサイズは一致するんだけど、8を超えるとちょっと数え方が変わる。
配列の中身を見てもらえればわかるんだけど、以下の関係になってる。
| DLC | データフィールドサイズ |
|---|---|
| 9 | 12 |
| 10 | 16 |
| 11 | 20 |
| 12 | 24 |
| 13 | 32 |
| 14 | 48 |
| 15 | 64 |
ここら辺はいつも分からなくなるんだよねー。
まぁ、「こういう仕様だ。」以上のことは言えないしね。
まとめ
まとめだよ。
- AUTOSAR-XCPのCAN-FD対応に向けての方針を決める。
- CanIf相当の部分とXCPのパケット長のところを修正する必要あり。
- といってもCanIf相当の部分は実はすでにCAN-FD対応済み
- CAN-FD対応の際はDLCの仕様の特殊さに注意する必要がある。
- 8以下の時と8を超えた時で雰囲気が変わる。
バックナンバーはこちら。
コメント