Command Space Packet の Secondary Header を見直し，TLC や BC の実行方法を拡張する

[meltingrabbit]

概要

Command Space Packet の Secondary Header を見直し，TLC や BC の実行方法を拡張する

詳細

• TLC や BCT のための exec type や TI を header が持ってるのをやめたい？ #528 のつづき
• 現状の CSP https://github.com/ut-issl/c2a-core/blob/8075472c7f63b564dc1edaeb8903c5c4cb381b58/Docs/Core/communication.md
  • exec type, dest type を header が持つのをやめたい
  • TI を header が持つのをやめたい
  • MOBC BCT に AOBC TLC をいれる，といったことがいまできない

close条件

実装されたら

[meltingrabbit]

現状

案１ APID にルーティングなどを持たせる

懸念

• APID 枯渇
• pack cmd の形（型）が微妙

案２ high order cmd （こっちが有力？）

懸念

• GS 側の実装が大変

[meltingrabbit]

C2A core 側の実装の問題

BCT

• REGSTER_BCT コマンドを受領後，pack されている cmd を抽出し，それを BCT に格納
• TI 情報は失われてしまうので，BCT の拡張（CCP と TI の両方の配列を保存する必要がある）
• BCT 的には，header が短くなるので，メモリ状はとても有利になる！

TLC

• だいぶ悩み
• BCTのように pack cmd を抽出してもいいが，TIを保存する場所がない
  • PL をつかっているので，linked list (queue) としてのデータ構造では，CCPしか格納できない
• ccp + TI のstruct を定義して，それの linked list をつくってもいいが，ちょっとだるい
• また，PL は BCT とちがって，1 cmd につき（＝ queue entry につき） CCP_MAX_LEN だけメモリを確保してる
  • TI を別途持つと，めちゃくちゃRAM使用量が増える（32 bit x queue サイズ）
  • 一方で， CCP_MAX_LEN だけ確保してるので， pack cmd を抽出する前の， REGISTER_TLC Cmd のままでも queue に格納可能（こちらのほうがメモリ効率が良い）
• とは言え 「REGISTER_TLC Cmd のままで queue にいれて，デキューじに pack cmd を抽出するのもそうではなくない？ とういう気持ちに
  • 一旦これで実装して fixme？