【XCP】最小構成のMBD事例 第2章 その168【XCP Basic㉒】

バックナンバーはこちら。
https://www.simulationroom999.com/blog/model-based-of-minimum-2-backnumber/

はじめに
登場人物
ALLOC_ODT_ENTRYの制限
ALLOC_ODT_ENTRYを投げて見る
ALLOC_ODT_ENTRYを複数回投げてみる
まとめ

はじめに

前回はALLOC_ODTの送信実験。
ALLOC_ODTでODTを生成するたびにXCP Basic側のリソースが消費されていくのが確認できた。
また、ODTが増えるということはODT用の送信バッファも増えるということで
それも加味したリソース管理をしないと設定前にリソース枯渇もあり得ることがわかった。

今回はODTの内部リソースであるODT_ENTRYの生成に関する話となる。

登場人物

博識フクロウのフクさん

イラスト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

ALLOC_ODT_ENTRYの制限

太郎くん

前回はALLOC_ODTだったから
続けてALLOC_ODT_ENTRYだね。

太郎くん

ODT_ENTRYって確かODTの中にどの位置にどのの変数を格納させるかを定義するものだっけ？

フクさん

そうだね。
ALLOC_ODT_ENTRYコマンドを発行する段階ではまだ具体的にどの変数ってとこまでは定義しないが、定義するための箱をいくつ用意するか指定するコマンドになる。

太郎くん

1ODTでCAN1フレーム分だから、
ODT_ENTRYで定義する変数も合計で8byteに収めないといけないってのもあるよね。

フクさん

実際には先頭にPIDが1byteあるんで、
7byteかな。
加えてDAQのmodeによってはタイムスタンプが乗ったりDAQ number、ODT numberが乗ることもあるんで、
さらに減ることはあり得る。
まぁCANの場合、1フレームが8byteということからPIDしか乗せないことの方が多いけどね。

太郎くん

まぁ何かしらで上限があるってことだね。

ALLOC_ODT_ENTRYを投げて見る

フクさん

ALLOC_ODT_ENTRYでDAQ list 0のODT 0に対してODT_ENTRYを1個生成る場合の電文はこれになる。
0xD3, 0x00, 0x00, 0x00, 0x00, 0x01
3～4byte目にDAQ＿LIST_NUMBER、
5byte目にODT_NUMBER、
6byte目にODT_ENTRIES_COUNT(生成するODT_ENTRY数)
になってる。

太郎くん

じゃー、送るよー。

xcp_sendrecv([0xD3, 0x00, 0x00, 0x00, 0x00, 0x01, ]);

Send msg : Timestamp:        0.000000   ID: 0001 S DLC: 6 d3 00 00 00 00 01
Recv msg : Timestamp: 1635592684.849435 ID: 0002 S DLC: 1 ff Channel: 1

XCP Basicのコンソール画面

-> ALLOC_ODT_ENTRY daq=0, odt=0, count=1
[XcpAllocMemory] 15/256 Bytes used
[XcpAllocMemory] Queuesize=26
<- 0xFF

太郎くん

うん。
OKそうだ。

ALLOC_ODT_ENTRYを複数回投げてみる

フクさん

じゃ、ALLOC_ODT_ENTRYも複数回投げてみよう。

-> ALLOC_ODT_ENTRY daq=0, odt=0, count=1
[XcpAllocMemory] 15/256 Bytes used
[XcpAllocMemory] Queuesize=26
<- 0xFF
-> ALLOC_ODT_ENTRY daq=0, odt=0, count=1
[XcpAllocMemory] 20/256 Bytes used
[XcpAllocMemory] Queuesize=26
<- 0xFF
-> ALLOC_ODT_ENTRY daq=0, odt=0, count=1
[XcpAllocMemory] 25/256 Bytes used
[XcpAllocMemory] Queuesize=25
<- 0xFF

# 省略

-> ALLOC_ODT_ENTRY daq=0, odt=0, count=1
[XcpAllocMemory] 245/256 Bytes used
[XcpAllocMemory] Queuesize=1
<- 0xFF
-> ALLOC_ODT_ENTRY daq=0, odt=0, count=1
<- 0xFE error=30h

太郎くん

これ何回くらい投げたの？

フクさん

73回くらいかな？

太郎くん

1ODTが8byteだから、こんなにODT_ENTRYを生成しても意味なくない？

フクさん

まぁ実際の運用に於いては意味の無い生成の仕方だな。
といっても、ALLOC_ODT_ENTRYコマンドの段階では変数のデータ長がわからないから、XCPスレーブ側としては指示された分を生成しようとしちゃうんだろうね。
最終的にはERR_MEMORY_OVERFLOWのエラーにはなってるが、これは単純にメモリが枯渇しただけだ。

太郎くん

まぁODT_ENTRY自体もリソースを消費するってのが分かったってところだね。
5byteずつ消費してるみたい。

フクさん

XCP Basicに於いては4byte長のアドレスと1byte長のデータ長の合わせて5byteを使ってるね。

まとめ

フクさん

まとめだよ。

ALLOC_ODT_ENTRYは物理層の都合やODTのフォーマットによる制限がある。
- CANの場合だとデータフィールド8byteが制限。
- タイムスタンプ等が入ることで計測データを格納する範囲が少なくなる。
ALLOC_ODT_ENTRYを複数回投げてみた。
- リソースが枯渇するまで生成は可能。

バックナンバーはこちら。