齋藤電気の電気実験室

　システムプログラム設計のちょっとした考慮点を取り上げてみたいと思います。

　ターゲットとなるシステム、それは24時間365日という「止まることのない」システム。業務用途、いってみればサーバと同じ耐久性が必要なんですね。

　その中で停電、という厄介な問題も当然対処に含まれています。
普通のＰＣは動作中に停電したら…それまでの記録やらが消滅するだけでなく、再起動…がままならない、ってこともあるわけです。

　無停電装置ＵＰＳをつければ、まぁＰＣにおいては安心ですが、ＵＰＳが無くてもちゃんと「自動起動の設定」…これもＢＩＯＳ設定やスタートアップの登録など、いろいろ細かな配慮で格段に計測の信頼性が向上します。
　ＵＰＳとていずれ内部電池の寿命もあったり、停電自動復帰やらモロモロのインストールは案外機種の細かい設定があったりします。
　
　以前、停電復帰実験でＵＰＳの電池が無くなる…というシャットダウン設定を組み込んだのですが、再び通電が開始されると、本来の予定では自動計測メニューが起動する筈だったのです。
　しかし実際はファイルエラー。…これはＵＰＳ関係制御ファイルの何かが「電池切れ」後の再通電は「人間の手」によって復帰させる、というポリシーなんでしょうね。

　やっぱりこうした制御は複雑です。ＵＰＳ制御ソフトに頼らずとも自動再起動…これが自動計測の王道です。



　

コンパイルが終わり、目的のプログラムが一応できた…次にするのはプログラム配布の準備です。
インストーラーの作成はセットアッププロジェクトというウィザードで必要ファイルを設定します。

ファイルシステム、レジストリ、インターフェース、起動条件…など。

　今回作成したファイルは実行ファイルが１つなのですが、実はそれだけではプログラムは動作しません。
レジストリファイル…これがないとプログラムの起動ができませんでした。…つまりレジストリパラメータにも依存した実行プログラムだったのです。割込み関連の開始終了にはやっぱりＯＳの深い機能を使わなければいけないのです。
それから、コンパイルしてEXEファイルが動作するためのランタイムライブラリ、これも必要となります。
いわゆるマイクロソフトのDLLというもので、開発環境のＰＣではプログラム実行で必要なライブラリは既にインストールされていますから実行できますが、配布用のプログラムにはこのライブラリ、がない場合もあり、コンパイルでリンクしたのと同様のライブラリをユーザＰＣにインストールして動作させます。
この一連のインストール手続きを配布ウィザード、で行うわけなのですが、昔のＭＳ-ＤＯＳ時代でいうところのバッチファイル、というのに相当するのですね。

AUTOEXEC.BATやCONFIG.SYSといったファイルをご自身でタイプされた方ならきっと理解ができると思いますが、CONFIG.SYS…これがレジストリみたいなもので、デバイスドライバを自動的にインストールさせるAUTO.INF…これがAUTOEXEC.bat…なるほど。。Visual形式で膨大な必要ファイルを自動インストールさせるのにも、いろいろなステップが必要…みたいです。

　確かにＣ++は高速で動作するMFCプログラムライブラリは確かに強力だ。1mS毎にインターバルジャンプしてくれる処理内容に処理時間がかかる冗長な記述はご法度だが、それでもちゃんと定期的に監視してくれていることが分かり、一安心。

ただ、全計測ＣＨが同時に変化した、という、実際にはあまり生じにくいレアケースでのサンプリング速度性能調査では、残念ながら3mS程度、内部処理時間がインタラプトでかかっており、目標の応答速度には到達できなかった。

具体的には、1発目のキャッチ、これは設計どおり1mSでちゃんと応答する。ただし、その1発目から次の2発目の応答まで3mS程度の不感ゾーン、つまり割込み処理が行われている間に次の反応をキャッチすることができない。割込み内のいろんな処理コードの速度が3mS程度かかる、ということだ。

ネィティブコンパイラが吐き出す処理コードはそれなりに十分高速だが、コンパイラがWin32カーネルを最適化コールしても、どうしてもそれなりの処理時間を要する、という限界が見えてきた。

単体処理時間は短くても、全ＣＨ同時に、となると、やはりそれなりに時間がかかる…。
今回作成プログラムではＣ++で極力処理速度優先のマシン語的なデザインでコーティングをしてみたが、この冗長なときを含む1mSの壁を確約するための設計は、やはり専用ボード設計による方が遥かに見通しが良さそうである。

波形観測装置、オシロでいうところのスイープ時間軸がオーバースペックなソフトウェア処理速度でもたつかないようなデザイン…が計測屋にはやはり大事なポリシーだと…。

　ユーザープログラムで1mSより短いサンプリング周期、例えば専用ハードウェアがインストールされるデバイスドライバなど、どんな感じで開発していくのか…。

　どうやらWindowsDDK開発キット、にいろんなツールが含まれているようです。
Visualシリーズで扱ってきた開発言語の殆どはユーザーモード、といって直接ハードウェアアクセスを認めていません。じゃぁ、ベンダーメーカーが接続するハードウェアのプログラムの開発する環境？…それがハードウェアを操作することのできるカーネルモードを扱うＤＤＫとよばれる開発ライブラリに入っているんだそうです。（主にＣ++で記述する…というか、言語以前に仕様とか数多くの定義を理解することが先決…）
標準MFCが提供しているライブラリを越えて直接カーネルコードを扱うことはできません、とのガイドラインが何やら英語で書かれていましたが、考えてみればそうですね。
ユーザープログラムがＯＳコードを自由に操作できてパッチを当ててしまったら、セキュリティに穴を開けてしまうようなもんですから…。
デバイスドライバを作成するためのカーネルモードでプログラムコードを作成するのは、どうやらやはりかなりハードルが高い領域のようです。

さて、実際の1mS取り込みルーチンはこんな感じ…

void CALLBACK timerProc(UINT uTimerID, UINT uMsg,
DWORD dwUser, DWORD dummy1, DWORD dummy2){
//データ読込
nRet = DioInputDword(hDeviceHandle,
　FBIDIO_IN1_32,&nBufw64[0]);//CH1-32を取り込む
nRet = DioInputDword(hDeviceHandle,
　FBIDIO_IN33_64,&nBufw64[1]);//CH33-64を取り込む
…他の処理…
return;
}

このプログラムを入れる場所はMainView.cpp内の定義後すぐの位置、つまりグローバル変数エリアで登録します。
そして起動は

// タイマー割込の開始！！
MMRESULT timerID = timeSetEvent(1, // 間隔[ms]
0, // 分解能 0なら1ｍＳ
timerProc, // 割り込み関数
(DWORD)&count, // ユーザーパラメータ
TIME_PERIODIC | TIME_CALLBACK_FUNCTION // 動作フラグ
);//タイマスタートＯｎ！

で開始されます。
この開始コマンド記載場所もグローバルMainView.cpp内の最初の方です。

コンパイル時にちょっと厄介なのは、デバイスドライバの認識です。
割込みルーチンの記述にはI/Oボードのアクセスがあります。
標準的なエクスプローラで作成されるスタンダードな関数内に括ってしまうとデバイスがオープン（初期化）されていないというエラーを出します。
プログラムコーティングシーケンスの順序についてもこのような考慮ポイントが存在しています。