Debugger)のお話です。gdbはその名の通りデバッガなのですが、サポートするCPUはそこそこ(かなり?)多いです。サポートする・・・といっても、通常のgdbはx86(PC)用なので、これがそのままSHやらARMやらのデバッグができるわけではありません。各CPUアーキテクチャ毎にコンフィギュレーション&ビルドして、そのCPU専用のgdbを作成するなり、出来あえのgdbをガメてくるなりする必要があります。タイトルに出てきているISSですが、命令セットシミュレータの略です。命令セットシミュレータというのは、そのCPU専用の命令を解釈して処理をしてくれるシミュレータで、本来であれば、該当のCPU上でなければ実行できない実行モジュールをPC上で仮想実行してしまうものです。前回までのVCやらx86-gcc上でシミュレートしていた方式は、ISSに対して、ネイティブシミュレータと呼びます。何にに大してネイティブかというとPC(x86-CPU)の命令に対してネイティブってことだと思います。ネイティブシミュレータの場合はソースコードレベルの動作までしかデバッグ/テストできないことに対し、ISSでは命令レベルのデバッグ/テストが可能となります。gdbとISSがどう関係するかと言うと・・・大概、gdbはISSを内包しています。大概・・・と言ったのはマニュアルを読むとすべてのgdbが内包してるわけではないという記述があったため、そのように表現しましたが、私が確認した限りだと全アーキテクチャに於いてISSは実装されているようです。※まぁgdb自体のデバッグなども考えるとISSがあった方が楽だし、私でも先にISSを作ろうと思うかな?というわけで、今回はこのISSを使用します。ターゲットCPUはとりあえずARMでいきます。gdbだけあったも仕方ないので、ARM用のツールチェインをそろえる必要があります。基本は以下を用意します。・binutilsバイナリユーティリティ。アセンブラやらリンカやらオブジェクトコンバータなどのツールセットです。コレがないと始まらない・gccコンパイラです。C/C++用にコンフィグしましたが、C言語しか使わない予定です。・libc、libstdc++C/C++標準ライブラリです。libcをリンクするとGPL汚染されてしまいます。よって、組み込み系に於いては大概Redhat社が公開している、ロイヤリティフリーのlibcであるnewlibというものを使用します。・gdb上で説明したデバッガです。いうわけで、コンパイラをコンパイルするというよくわからん作業をまずこなします。使用するプログラムは恒例の状態機と制御器です。別にgdbを使ってこれらをデバッグすることが目的ではありません。今回の目的は「最終成果物の状態でユニットテストをする」になります。「最終成果物」なので、ユニットテスト用コード及びフレームワークは除外されてる、または封印されていることがほとんどだと思います。gdbを使用するとユニットテストフレームワーク無しでユニットテストを実施することができます。gdbのコマンドの中にcallコマンドというものがあるのですが、これを使用します。ユニットテストフレームワークを使用した方が良いと判断する方もいるとは思いますが、それはそれでこれはこれってヤツです。組み込み系に於いてのコンパイラは割りと無茶な最適化をする、またはさせていることが多く、構成を変えた状態のものでテストしても問題なしという判定にならないことが多いです。(構成を変えることでコンパイラの不具合がでたり出なかったりが発生するため。暗黙inlineなどが発生した場合はauto変数の構成が大きく変わるため、命令構成がガラチェンします)というわけで最終成果物の形でテストして初めてOK判定が可能というパターンが多いです。いえ、gdb&ISSの起動直後にcallコマンドを発行してもまともには動きません。理由は、スタックポインタの初期化、静的変数の初期化が走っていない状態では、C言語として前提条件がそろっていないためです。この状態でcallコマンドを発行するとアドレス例外が発生して強制終了します。gdb上で動作してるプログラムが終了するだけでgdbは無事ですが。といわけで、スタックポインタの初期化、静的変数の初期化が終わるあたりにブレークポイントを設置してから、そこまでプログラムを走らせたあとにcallコマンド発行という流れになります。PLL、WDGの初期化などのHW絡みのコードまで走らせると今度はHW初期化待ち状態の無限ループに陥ることもあるので、そこらへんは構成を見て最適と思われる箇所を探す必要があります。HW初期化が先に設置されていたり、あまり無いとは思いますが、スタックポインタの初期化と静的変数の初期化の間にHW初期化が設置されている場合はうまくプログラムカウンタを書き換えて該当処理をかわすなどの対応をしてください。C言語的に動作可能な状態になったところでcallコマンドを発行です。関数名(引数)Enterを押せば、関数が実行されます。ライセンス文がごちゃごちゃ出てくる。プロンプトが(gdb)になる。main.c:37#※この段階でcallコマンドがまともに動作可能な状態になる。gdb上から操作する場合、$r13、または$spで直接操作ができる。環境に依存させたくない場合は$spで。ちなみにARMの場合r14がリンクレジスタでr15がプログラムカウンタ。それぞれ$lr、$pcがエイリアスになる。0x1fffb0#巨大な配列、構造体などの領域を確保する場合はmalloc関数をcallコマンドで呼んで、ヒープから取得した方が良いが、そもそもヒープがあるかどうかって問題がある。別にRTOSが持ってるメモリプールでも問題ないので、そこらへんは環境に合わせて。※戻り値があるタイプの関数だとcallコマンド実行後に戻り値が表示される。0今回は手打ちしてますが、gdb自体にスクリプトを読ませることができるので、自動実行/連続実行は可能です。通常のユニットテストフレームワークを使用するのと比べると使いづらいのは否めないですね。テスト対象が状態機、制御器なので1,2回関数呼んでもなんかよくわからん感じです。最初の方の数回は状態機側で指令値を加工してしまうので、第1引数なんかは何を入れても結果変わらないし・・・。その1gdbをISS(インタラクションセットシミュレータ)として利用した上で、scilabと連携する方法。その2SPILSネタの続きです。以下の構成の方が一般的です。一個別のgdbをgdbサーバーとして起動。scilab直下のgdbからリモートデバッグする体で接続しています。その2gdbをISS(インタラクションセットシミュレータ)として利用した上で、制御器の検証に応用する方法。ARM-gdbを使用。Scilabで作成した制御モデル、モータープラントモデルと連携。ELF/DWARFはソースコードファイル名や各ソースライン情報を保持している。コメントをキャンセルメールアドレスが公開されることはありません。※サイト次回のコメントで使用するためブラウザーに自分の名前、メールアドレス、サイトを保存する。上に表示された文字を入力してください。(14)KEI主に自動車開発関連の技術者っぽい人。領域はパワートレインがメインだが、それ以外もちょこちょことやってる感じ。カテゴリ的には凡そ以下。現場は疲れたので、シミュレーションで実物を扱わなくても仕事ができる環境を目指す。家に引きこもって外に出なくてもOKな世界。目指せ完全テレワーク。KEIをフォローするKEI2024.11.01はい。一般的な動画のfpsに近いものと思ってもらってOKです。※以下、たぶんDS検定では聞かれないと思いますが念のため...画像フレームレートという表現ですが、世間一般の表現ではありません。仮)(データサイエンティスト検定リテラシーレベル)KEI2024.11.01ありがとうございます。正解選択肢の内容が間違ってますね。逆というか、協調フィルタリング側が間違っている状態でした。仮)(データサイエンティスト検定リテラシーレベル)鋼鉄の戦士2024.11.01協調フィルタリングとコンテンツベースフィルタリングの説明逆な気がします。仮)(データサイエンティスト検定リテラシーレベル)あ2024.10.09先日お伝えした問題は無事解決しました。Usホーム検索トップサイドバータイトルとURLをコピーしました。