確かにC++は高速で動作するMFCプログラムライブラリは確かに強力だ。1mS毎にインターバルジャンプしてくれる処理内容に処理時間がかかる冗長な記述はご法度だが、それでもちゃんと定期的に監視してくれていることが分かり、一安心。
ただ、全計測CHが同時に変化した、という、実際にはあまり生じにくいレアケースでのサンプリング速度性能調査では、残念ながら3mS程度、内部処理時間がインタラプトでかかっており、目標の応答速度には到達できなかった。
具体的には、1発目のキャッチ、これは設計どおり1mSでちゃんと応答する。ただし、その1発目から次の2発目の応答まで3mS程度の不感ゾーン、つまり割込み処理が行われている間に次の反応をキャッチすることができない。割込み内のいろんな処理コードの速度が3mS程度かかる、ということだ。
ネィティブコンパイラが吐き出す処理コードはそれなりに十分高速だが、コンパイラがWin32カーネルを最適化コールしても、どうしてもそれなりの処理時間を要する、という限界が見えてきた。
単体処理時間は短くても、全CH同時に、となると、やはりそれなりに時間がかかる…。
今回作成プログラムではC++で極力処理速度優先のマシン語的なデザインでコーティングをしてみたが、この冗長なときを含む1mSの壁を確約するための設計は、やはり専用ボード設計による方が遥かに見通しが良さそうである。
波形観測装置、オシロでいうところのスイープ時間軸がオーバースペックなソフトウェア処理速度でもたつかないようなデザイン…が計測屋にはやはり大事なポリシーだと…。
ただ、全計測CHが同時に変化した、という、実際にはあまり生じにくいレアケースでのサンプリング速度性能調査では、残念ながら3mS程度、内部処理時間がインタラプトでかかっており、目標の応答速度には到達できなかった。
具体的には、1発目のキャッチ、これは設計どおり1mSでちゃんと応答する。ただし、その1発目から次の2発目の応答まで3mS程度の不感ゾーン、つまり割込み処理が行われている間に次の反応をキャッチすることができない。割込み内のいろんな処理コードの速度が3mS程度かかる、ということだ。
ネィティブコンパイラが吐き出す処理コードはそれなりに十分高速だが、コンパイラがWin32カーネルを最適化コールしても、どうしてもそれなりの処理時間を要する、という限界が見えてきた。
単体処理時間は短くても、全CH同時に、となると、やはりそれなりに時間がかかる…。
今回作成プログラムではC++で極力処理速度優先のマシン語的なデザインでコーティングをしてみたが、この冗長なときを含む1mSの壁を確約するための設計は、やはり専用ボード設計による方が遥かに見通しが良さそうである。
波形観測装置、オシロでいうところのスイープ時間軸がオーバースペックなソフトウェア処理速度でもたつかないようなデザイン…が計測屋にはやはり大事なポリシーだと…。
PR