※ 2015年2月に執筆したものを転載
引き続きgdbネタです。
前回、gdb内包ISSを用いたテストを実施しました。
正直、テストデータをモデルから引っこ抜くという作業も少々煩わしいです。
というわけで、そのままscilabからgdbを制御してISS上でソフトウェアの動作、結果取得ができなか検討します。
ちなみにこういう手法、タイトルでも書いていますが
SPILSと呼びます。
SPILSはSimulatorBased Processor In the Loop Simulationの略。
近い用語に
SILS(Software In the Loop Simulation)
PILS(Processor In the Loop Simulation)
FILS(Function In the Loop Simulation)
なんてものあります。
※ちなみにPILSとFILSは現在においては同一のもののようです。
SILSはネイティブシミュレータを使用したものに対し、PILSは実機互換のプロセッサ上で直接動作、SPILSはISS上で動作するという感じで、ちょうどSILS、PILSの中間の性質のものとなります。
さて、SPILSを実現するためにはgdbとうまくやり取りをする必要があります。
ざっとマニュアルと確認しましたが、gdb-sever以外で対話インターフェースに該当する機能は見当たりません。
しかし、Insight、DDD、Eclipse-CDTなどのフロントエンドツールがあるところから何かしらの通信手段はあると見ています。
というわけで各ツールの中をちょっと潜って見ます。
結果↓
Insight → 標準入出力経由プロセス間対話
DDD → 標準入出力経由プロセス間対話
Eclipse-CDT → 標準入出力経由プロセス間対話。ただし、CLIではなくMI
なんとなく予想はしていたけども、標準入出力で直接叩いてるみたいです。
標準入出力はその名の通り標準的なインターフェースなわけなので、これはこれで良しと思うべきでしょう。
想定する構成は以下になります。
やり取りの手順ですが、
まずはgdbの出力を確認しておきます。
# gdb起動↓ $ arm-none-eabi-gdb pid_test GNU gdb (GDB) 7.8.1 Copyright (C) 2014 Free Software Foundation, Inc. # ライセンス文がごちゃごちゃ出てくる。 # プロンプトが(gdb)になる。 (gdb)
起動プロセスはarm-none-eabi-gdb、パラメータはpid_testで良いでしょう。
出力は必ず「(gdb) 」の6文字(最後にスペースが入っている)なので、
この6文字をターミネータとして認識すればよさそうです。
こちらからの指示は改行ターミネートになっているので、
かならず最後に\nを送ればOKです。
プロセス起動初回のみ、標準出力を受け付け
あとは
標準入力→標準出力
の繰り返しとなります。
というわけでざっくり手順は以下になると思います
※送りつける標準入力は前回の手順がベースになります。
・プロセス起動
・taget sim\n 送信
・load\n 送信
・b main\n 送信
・c\n 送信
・set $command = $sp – sizeof(long)\n 送信
・set $sp = $command\n 送信
・set $dutycut = $sp – sizeof(int)\n 送信
・set $sp = $dutycut\n 送信
ここまでが初期化処理相当。
シミュレーション開始時に1回やればOKのところです。
あとは只管controllerをcallコマンドで呼べばOKです。
・call controller([パラメータ1],[パラメータ1],(long)$command,(int)$dutycut)\n 送信
・print (long)$command\n 送信
・数値文字列取得
・print (int)$dutycut\n 送信
・数値文字列取得
シミュレーション終了時は以下を投げればOK。
・quit\n 送信
・y\n 送信
・標準入出力Close
・プロセスClose
動作結果↓
おなじみにの波形です。
SPILSを実施する前に前回のテーマで一度gdbのISS単体で動作させているので失敗する要素はほとんど無いのですけどね。
ちょっと気にしていたのが速度だったのですが、特に遅い感じはしません。
さすがにSILSと比べるとごちゃごちゃと通信している分、モッサリ感がでますが、実時間よりかはまだ早い状態です。
もうちょい踏み込んだネタがあるので次回に続く。
コメント