VisulaBasicでもかなり細かいプログラム表現が可能だ。でもどうしても越えられない、というか、使いたい機能が提供されていない…。
InterFace社のActivX他ライブラリ関数には1mS単位の記載があった。が、この関数自体、どうやら1つのCHしか監視がされていないことがテストプログラムの測定でわかり、やはり独自に作るしかない、という道しかないようだ。
仕様は次のとおり。
・1mSのサンプリング周期で全ＣＨデータ入力（デジタル信号）を捕らえたい…。
この1mSというキーワードでタイマーについていろいろと調べていくと、CPUパフォーマンスカウンタ、メディアタイマ、といった関連の情報が出てきた。
CPUパフォーマンスカウンタは経過時間を調べる用途には都合はよいが、1mS経過したらジャンプ、といった割込み仕様にはなっていない。（イベント的な…いわゆるジャンプでの利用はできない）
マルチメディアタイマというWinmm.Lib関数内にあるTimerProc()で使われる関数のみが、WindowsOS本体でどうやら最小1mSを提供している関数のようだ。
この関数TimerProc()は、Visualシリーズのイベントタイマーの内部でコールされる最小単位の関数であり、この関数を用いてプログラムを作成する場合、残念ながらVisualアイコンのタイマーイベントは競合の関係から一切利用できない制約がある。
そして、このTimerProc()関数を記述するためのVisual言語にはVisual C++でなければならないことが判明した。
逐次コンパイルのインタプリタ方式では動作速度が遅く、極限までに動作速度の効率を高めた、いわゆるネィティブプログラム方式、ＭＦＣ（マイクロソフトファンデーションクラス）でしか提供されていないことがわかった。
やはり専門家用ツールソフト（Ｃ++）にはアセンブラ（ハードウェアアクセス）に近い機能が備わっていることをあらためて再認識した。
InterFace社のActivX他ライブラリ関数には1mS単位の記載があった。が、この関数自体、どうやら1つのCHしか監視がされていないことがテストプログラムの測定でわかり、やはり独自に作るしかない、という道しかないようだ。
仕様は次のとおり。
・1mSのサンプリング周期で全ＣＨデータ入力（デジタル信号）を捕らえたい…。
この1mSというキーワードでタイマーについていろいろと調べていくと、CPUパフォーマンスカウンタ、メディアタイマ、といった関連の情報が出てきた。
CPUパフォーマンスカウンタは経過時間を調べる用途には都合はよいが、1mS経過したらジャンプ、といった割込み仕様にはなっていない。（イベント的な…いわゆるジャンプでの利用はできない）
マルチメディアタイマというWinmm.Lib関数内にあるTimerProc()で使われる関数のみが、WindowsOS本体でどうやら最小1mSを提供している関数のようだ。
この関数TimerProc()は、Visualシリーズのイベントタイマーの内部でコールされる最小単位の関数であり、この関数を用いてプログラムを作成する場合、残念ながらVisualアイコンのタイマーイベントは競合の関係から一切利用できない制約がある。
そして、このTimerProc()関数を記述するためのVisual言語にはVisual C++でなければならないことが判明した。
逐次コンパイルのインタプリタ方式では動作速度が遅く、極限までに動作速度の効率を高めた、いわゆるネィティブプログラム方式、ＭＦＣ（マイクロソフトファンデーションクラス）でしか提供されていないことがわかった。
やはり専門家用ツールソフト（Ｃ++）にはアセンブラ（ハードウェアアクセス）に近い機能が備わっていることをあらためて再認識した。
PR
Visualシリーズの開発言語で旧来から馴染みがありそうなVisualBasicについて触れてみたいと思う。
PC98時代のMS-DOS版BASICとの違いといえば、それはやはりマルチタスクをサポートする複雑な階層構造を有している、の一言に尽きる。
プログラム作成環境を設定するプロジェクトの種類としてWindowsアプリケーションを選択。
Visualシリーズ共通のハローワールドでは、画面を表示するためのデザイン設定からが基本です。
今までテキストベースでタイプしていたコントロールとよばれる内容がマウス操作で実現できるのもユーザーフレンドリーな設計の特徴です。
さて、計測アプリを構築するときに使うタイマーイベント機能はVisualBasicではどうなっているのかを調べて見ました。
Timerの性能は、1ミリ秒単位で設定できるようにはなっているが、最短、毎秒18回程度間隔でしか動作しない。また、ソフトウェアの動作状況によっては間隔も遅れる、とある。
PC98より遥かに高速で動作している筈のWindowsOSの提供される標準タイマー機能がこれほど貧弱なものとは、ある意味ショックな事実でもある。
WindowsOSで１ミリ秒単位で設定可能な内部の方法はないものなのか…。
PC98時代のMS-DOS版BASICとの違いといえば、それはやはりマルチタスクをサポートする複雑な階層構造を有している、の一言に尽きる。
プログラム作成環境を設定するプロジェクトの種類としてWindowsアプリケーションを選択。
Visualシリーズ共通のハローワールドでは、画面を表示するためのデザイン設定からが基本です。
今までテキストベースでタイプしていたコントロールとよばれる内容がマウス操作で実現できるのもユーザーフレンドリーな設計の特徴です。
さて、計測アプリを構築するときに使うタイマーイベント機能はVisualBasicではどうなっているのかを調べて見ました。
Timerの性能は、1ミリ秒単位で設定できるようにはなっているが、最短、毎秒18回程度間隔でしか動作しない。また、ソフトウェアの動作状況によっては間隔も遅れる、とある。
PC98より遥かに高速で動作している筈のWindowsOSの提供される標準タイマー機能がこれほど貧弱なものとは、ある意味ショックな事実でもある。
WindowsOSで１ミリ秒単位で設定可能な内部の方法はないものなのか…。
VisualStudioシリーズで提供されている言語にBASIC,C#,C++,WebDeveloper…。
そしてソフトウェア作成のための各種サポートツール群。
実は、コード作成そのものは体験版であるExpress版で殆どの機能が装備されています。
ただ、有償の製品版との違いは…。
ソースコード修正デバッグ作業の際に重宝する機能、リソース、構成マネージャー、デバッグ、詳細書式設定、マクロ、ＭＦＣ…といったいわゆる開発環境で便利、美味しい処といわれる機能が提供されていません。
Express版はやはりあくまで体験という位置づけであって、実際にプログラムをコーティング仕様とする場合には物足りなくなるよう、実に巧妙なリリースをしています。Office機能有無やセットアップでStandardエディションとProfessonalで違いがあり、プログラム作成規模に則した導入の見極めが大切です。
VisualStudioシリーズが提供している言語機能は.NETとよばれる共通ライブラリ機能に依存した設計スタイルによって各種コード等が実現されており、マイクロソフトが過去ソフト継承の互換性を保ちつつも新しい機能の拡張に置き換えていくプロセスもこうした選択肢を提供しています。
そしてソフトウェア作成のための各種サポートツール群。
実は、コード作成そのものは体験版であるExpress版で殆どの機能が装備されています。
ただ、有償の製品版との違いは…。
ソースコード修正デバッグ作業の際に重宝する機能、リソース、構成マネージャー、デバッグ、詳細書式設定、マクロ、ＭＦＣ…といったいわゆる開発環境で便利、美味しい処といわれる機能が提供されていません。
Express版はやはりあくまで体験という位置づけであって、実際にプログラムをコーティング仕様とする場合には物足りなくなるよう、実に巧妙なリリースをしています。Office機能有無やセットアップでStandardエディションとProfessonalで違いがあり、プログラム作成規模に則した導入の見極めが大切です。
VisualStudioシリーズが提供している言語機能は.NETとよばれる共通ライブラリ機能に依存した設計スタイルによって各種コード等が実現されており、マイクロソフトが過去ソフト継承の互換性を保ちつつも新しい機能の拡張に置き換えていくプロセスもこうした選択肢を提供しています。
Windows上で動かすアプリケーションソフトはマイコロソフト社が提供しているVisualStudioシリーズの開発環境を利用するのがどうやら王道のようです。
これら詳細はマイクロソフトのソフトウェア開発ページであるmsdnのVisualStudioページに記載網羅されています。
ここで昔のBASIC言語でプログラムを組んだ経験のある方なら、Windows流の各種方言、例えばクラス、プロパティ、プロシージャ、メソッド、インスタンス…聴きなれない専門用語の羅列に戸惑うばかりです。
オブジェクト志向というパラダイム（＝考え方）１つをとっても、真意を理解するには深い洞察力が必要です。
早い話、マシン語で直接I/Oを触るような記述をWindowsプログラムでは認めていません。
でも、ハードウェアを増設拡張していろんなアプリケーションを動かすためには何らかのアクセス方法が必要です。
その統一手段、WindowsＯＳ上でアクセスする方法がマイクロソフトが提供するVisualシリーズ環境、というわけです。
これら詳細はマイクロソフトのソフトウェア開発ページであるmsdnのVisualStudioページに記載網羅されています。
ここで昔のBASIC言語でプログラムを組んだ経験のある方なら、Windows流の各種方言、例えばクラス、プロパティ、プロシージャ、メソッド、インスタンス…聴きなれない専門用語の羅列に戸惑うばかりです。
オブジェクト志向というパラダイム（＝考え方）１つをとっても、真意を理解するには深い洞察力が必要です。
早い話、マシン語で直接I/Oを触るような記述をWindowsプログラムでは認めていません。
でも、ハードウェアを増設拡張していろんなアプリケーションを動かすためには何らかのアクセス方法が必要です。
その統一手段、WindowsＯＳ上でアクセスする方法がマイクロソフトが提供するVisualシリーズ環境、というわけです。
PC98がBIOS標準で提供しているインタラプトタイマーの最小精度…は10mS。
Beepなど、エラー処理で音源周波数が設定されている8253タイマの分周設定もこの時設定単位で割込みコントローラ8259のタイマインタラプト信号で動いています。
テクニカルマニュアルによれば、I/O処理の後にNOP命令、いわゆる待ち時間を8253の場合、リカバリタイムが1000nS、とあります。本体メモリーアクセスはCPUクロック精度でいけるのですが、I/Oポートとのやりとりにはアクセス速度の制限（応答周波数）が存在します。
つまり、連続性してタイマ設定の変更が1mS以上の間隔を空けないとできない…という訳です。
PC内蔵タイマを単ショットカウントなど、セットリセットを繰り返すシーケンスに使うは、こうした「規格」の仕様をよく知った上でプログラムコーティングしないと、追従速度の限界を越えてセットした場合の不明な動作に悩まされることになります。
（実際、能力以上のパラメータを設定すると、案の定、フリーズしてしまいました。タイマが応答しきれない時間に再度割込み信号が…永遠ループから抜け出せない…）
インターフェイス拡張ボードとPCタイマを使って高速サンプリングのシステムを設計する際のいろいろな「勘違い」発見には、原因の深い洞察力が必要となりました。
Beepなど、エラー処理で音源周波数が設定されている8253タイマの分周設定もこの時設定単位で割込みコントローラ8259のタイマインタラプト信号で動いています。
テクニカルマニュアルによれば、I/O処理の後にNOP命令、いわゆる待ち時間を8253の場合、リカバリタイムが1000nS、とあります。本体メモリーアクセスはCPUクロック精度でいけるのですが、I/Oポートとのやりとりにはアクセス速度の制限（応答周波数）が存在します。
つまり、連続性してタイマ設定の変更が1mS以上の間隔を空けないとできない…という訳です。
PC内蔵タイマを単ショットカウントなど、セットリセットを繰り返すシーケンスに使うは、こうした「規格」の仕様をよく知った上でプログラムコーティングしないと、追従速度の限界を越えてセットした場合の不明な動作に悩まされることになります。
（実際、能力以上のパラメータを設定すると、案の定、フリーズしてしまいました。タイマが応答しきれない時間に再度割込み信号が…永遠ループから抜け出せない…）
インターフェイス拡張ボードとPCタイマを使って高速サンプリングのシステムを設計する際のいろいろな「勘違い」発見には、原因の深い洞察力が必要となりました。