こんにちは。皆さんに質問があります。
皆さんの中に、開発しているプログラムの実行速度やメモリ使用量など、パフォーマンス/ベンチマークを計測している方はいらっしゃいますか？
その場合、どのようにして計測していらっしゃるか教えていただけないでしょうか？
system daemon さん
既知情報でしょうが、CS+のヘルプにて「実行時間」を検索すると、
実行時間等を計測するためのヘルプが出てきますが、これで実行できませんでしょうか？
因みに、小職は現在不要なため、チャレンジしていませんが、折を見てチャレンジしようかなと思っております。
実行時間の測定では、測定開始時点と終了時点にブレークポイントを設定して
開始時点でSTOP→実行→終了時点でSTOPと動作させて、その時のCS+右下の時間を見ています。
また、未使用ポートを出力に設定して、測定開始部分でHIGH、終了部分でLOWを出力して
オシロスコープで測定しています。
Mきちさん、情報ありがとうございます。
なるほど、オシロで時間を計測する話は聞いたことがあります。エミュレータのタイマー機能に比べ計測で何点も計測できて楽なような気がします（ポートを叩く時間は誤差範囲ですね）。
ソースのどこにボトルネックがあるか、オシロとCS+とで突き合わせるのがちょっと大変な気がするのですが、何か秘訣とかありましたら(問題ない範囲で)ヒントをいただけると助かります。
こんにちは、シェルティです。
私は以下3レベルくらいの時間測定を使い分けています。
①関数単体の実行時間を知りたい→デバッガの時間計測機能（Jinさん方式）②数点のポイントの処理順序/処理時間の関係を知りたい→空きポートL/Hしてオシロ計測（Mきちさん方式）③複数タスク/複数割り込み、タスク遷移を確認したい→リアルタイムOSタスクアナライザ機能
③については小さいマイコンを扱っているとあまり触る機会がないかもしれませんので少し紹介します。RI600V4というリアルタイムOSのツール連携機能で、タスクの遷移や処理時間を視覚化してくれます。
http://documentation.renesas.com/doc/products/tool/doc/r20ut3089jj0101_ri600v4rn.pdf→このpage30図7-7にイメージ図が載っています。
グラフにカーソルを持っていくと処理時間が表示される、という感じでソフトウェアのボトルネック（無駄にアイドルタスクでシステムが待ち状態になっている箇所など）を見つけるのに非常に役に立ちます。
RI600V4は評価版が無償ダウンロード可能なので、CS+にインストールして何かソフトを適当に組んでみて、タスクアナライザ機能を確認してみると良いと思います。
以上です
あるお客様から実コンピュータを用いた実行時間とカバレッジ計測する事が要求された事があります。ポートの立ち上がり立下りをオシロスコープで計測する手法は誤差が大きいとの理由でNGでした。結局は8ビットの汎用ポートを要所でたたいて高速レコーダーで記録してカバレッジと実行時間を求めました。最終コードでテストする必要があるのでそのまま納入です。
通常はポートに余裕がないので私はファンクションの入り口と出口でフリーランカウンターを読み込んで実行時間を求める手法を最も多く使います。
メモリチェックも含めて、多重割り込みや動的変数や関数のポインター呼び出しは使わないようにしてます。先出のお客様は、CallWalkerを信用できないと言うのでコンパイルリストからサイズを拾って計算表を1週間かけて作成しました。
kijoさん、興味深い情報ありがとうございます。
オシロでも計測できないほど精度と確かさが要求される場合があり、しかも実マイコンで計測が必要、となるとなかなか厳しいですね…
さらにマイコン自体のタイマ/カウンタ資源を使うという発想は目から鱗でした。空いているSFRなら使わなきゃ損ですよね。
あと、計測コード入りのままで納入、はよく聞きますよね。そうしないと評価結果だけでなく動作も変わってきてしまいますし(動作に違いがないことが証明できれば一番いいのですが、まず無理)
メモリ系バグは一番出やすく、皆さんどうデバッグされているのか非常に興味がありますが、なるほど、そもそも多重割り込みやポインタ系を使わないルールでバグを防ぐ、という方法も効果がありそうです。でもCallWalkerを信用されていないクライアントさんですか...しかも自力で計算は自分にはちょっと無理です...
少し紛らわしい書き込みをしてしまいました。オシロスコープを用いるMきちさん方式もさほど問題になるような誤差は発生しないと私は思ってます。ソフトウエア検証に電気的な要素が入ることを不安に思ったお客様に十分に電気的誤差は無視できることを即答できなかったことで却下されたと思ってます。CallWalkerも評価レポートをすぐに示せればOKになったと思います。レベルは低いにしてもマイコンとコンパイラーの評価レポートがあったので命拾いしました。
RTOSを用いた参考情報として。実時間スケジューリング理論の利用率束縛定理を虎の子のように意識してます。それぞれのタスクの実行時間の和が69%以下なら独立したタスクがいつも時間制約を満たす事が出来ると言うものです。インターネットやいろいろな教科書等での聞きかじりなので私に大きな勘違いがあるかもしれません。興味があれば、systemdaemonさん自身で確認してください。これからはRTOSの時代だと思ってます。従って、シェルティさんの情報はとても興味を引きます。私も試してみたいのですが、Windows7のPCはスタンドアローンなので.NET Framework と Visual C++ のランタイム・ライブラリインストールがネックです。Hi。
kijoさん、お心遣い感謝いたします。クライアントと色々調整が必要だったというわけですね。良く分かります。
あと、「実時間スケジューリング理論の利用率束縛定理」は初耳でした(不勉強で申し訳ないです)。調査してみます。
===
.NETとVCのランタイムはインストーラに同梱されていたと思いますが、スタンドアロンPCだと何かほかに問題があるのでしょうか？
「利用率束縛定理」は不確かです。先に確認すべきでした。申し訳ありません。「スケジューリング理論」とか「レートモノトニック」で検索するといろいろと情報が得られます。私はコンピュータサイエンスを専攻していなかったので基礎知識がなく以前に書店で書籍を探してみましたが良いモノが得られませんでした。
ダウンロードした評価版だからと思います。インストーラを起動するとネットワーク経由で.NET Frameworkもインストールするようです。職場のPCはWindows7でネットワークにつながっているので問題なく.NET FrameworkもCS+もインストールできます。インストーラお任せにせず.NET Frameworkをローカルに持ってきて事前にインストールすればＯＫのはずですが、、。ネットワークにつなげているPCはWindows10でCS+未確認とルネサスのHPにあるのでインストールをひかえてます。職場の内職でやってみようと思ってます。
kijoさん、googleで検索してみました。いろいろ情報が見つかったので（”69%”で相手に納得していただけるよう）勉強してみます。
==
ランタイムはローカルにダウンロードしてインストールもできますね(CS+が使用しているランタイムのバージョンを間違えないよう注意です)。
Win10は昨年の7月29日リリースですから、CS+のリリース時期を考えると対応確認は酷かも？