イベント駆動型プログラム、の特徴は、イベントハンドラ、という個々の割込み関数にプログラムを分けて記述する方式。
WindowsOSが採用しているのもイベント駆動(ドリブン)型で、いろんな要素をOSが管理りましょう…というワケで、時間が来たから
「最優先に処理して…」とか、
「この割込みを先に処理してよ~」
というユーザーが割込みのレベル管理をすることができないんです。
「時間軸制御」で動かさなければいけない用途の場合、WindowsCE、RTLinuxやINTimeといったリアルタイムOSを導入するのがどうやら本筋のようです。
PC内部のタイマー(…といってもCPUクロックを読み取る関数がその根本)をソフトウェア的に「せこく」利用してタイマーを作るより、専用IC位は外付けで用意して、結果のみOSに知らせてね…って感じな仕様なんでしょう…(笑)
確かにそうですね。時間にシビアな測定なら専用ストップウォッチボードをハードで作成して、データをエクセルに転送する設計が「標準」的な発想でしょうから…。
いかに「せこく」(←安価に?)いくか…ソフトウェアエンジニア達のアイディアがこのフィールドに集うのも、そんなワケなんです。
マルチメディアタイマーのヘッダファイルを覗くと…1mS測定はどうやらCPUタイムを数えているようですね。
考え方としてカーネル部分…にパッチを当てればユーザープログラムが動く訳ですが、流石にそれは…マズイなぁ。。OSのアップデートの度ごとに動かなくなったり…。←本末転倒ですね。ユーザープログラムはOSを触ってはアカンのです。。
WindowsOSが採用しているのもイベント駆動(ドリブン)型で、いろんな要素をOSが管理りましょう…というワケで、時間が来たから
「最優先に処理して…」とか、
「この割込みを先に処理してよ~」
というユーザーが割込みのレベル管理をすることができないんです。
「時間軸制御」で動かさなければいけない用途の場合、WindowsCE、RTLinuxやINTimeといったリアルタイムOSを導入するのがどうやら本筋のようです。
PC内部のタイマー(…といってもCPUクロックを読み取る関数がその根本)をソフトウェア的に「せこく」利用してタイマーを作るより、専用IC位は外付けで用意して、結果のみOSに知らせてね…って感じな仕様なんでしょう…(笑)
確かにそうですね。時間にシビアな測定なら専用ストップウォッチボードをハードで作成して、データをエクセルに転送する設計が「標準」的な発想でしょうから…。
いかに「せこく」(←安価に?)いくか…ソフトウェアエンジニア達のアイディアがこのフィールドに集うのも、そんなワケなんです。
マルチメディアタイマーのヘッダファイルを覗くと…1mS測定はどうやらCPUタイムを数えているようですね。
考え方としてカーネル部分…にパッチを当てればユーザープログラムが動く訳ですが、流石にそれは…マズイなぁ。。OSのアップデートの度ごとに動かなくなったり…。←本末転倒ですね。ユーザープログラムはOSを触ってはアカンのです。。
PR