|
|
|
|
| 不明点の抽出と調査 |
 |
10月3日・・・知識不足と調査 |
| 以前にデバイスドライバの作成方法を聞いたことから「デバイスID/ベンダーIDを使用してボードを検出する関数があるはずだ!!」とあたりをつけました。 ・・・が ADボードのマニュアルに2つの情報が書かれていないこと、ボードに用意されているデバイスソフトウェアがあるという情報からINtime®のAPIではなくボードに付属のライブラリを使用するのかなぁと思ってしまいました・・・。 ということでボードのベンダーのHPを調査しボードに対するアクセス用ライブラリを懸命に探していました。 ---INtime®では、Windowsで使用するライブラリを使用することは一切ありません--- もちろんベンダーの提供するライブラリはINtime®用ではありません・・・。 私の知識不足から時間をかけて調査をしましたが、分かったことは、通常ベンダーはボードのマニュアルにベンダーID・デバイスIDなどの内部情報は掲載しないということです。 後にベンダーに問い合わせたところ、ベンダーID・デバイスIDを教えていただきました。早とちりから大きく道がそれてしまいましたが、今までINtime®とWindowsの違いはシステムコールが多少違うだけで、開発環境が同じと考えていた私にとって新たにその違いが明確になりました。 ---INtime®では、Windowsで使用するライブラリを使用することは一切ありません--- 「・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・。」 だとしたら・・・通常Windowsで使う標準ライブラリはどうだろう・・・？ printf()など標準のライブラリをINtime®でも使用しているではないか!? (回答) 標準ライブラリコールとまったく同じ形式であるだけで、中身がリアルタイム用に改良されたものです。もちろんリアルタイム用の標準入出力ライブラリがあります。 ≪Windowsとはまったく違うじゃないか!!≫ (当然) なるほど・・・しかしこれで納得できる・・・ INtime®アプリケーションの開発環境はWindowsの開発環境とまったく同じようで、追加ライブラリ、インクルードファイルはまったく違うものが入っていたわけだ!!これはVisual StudioでINtime®ウィザード使用時のコンパイル・リンク設定と、通常Windows Consoleアプリケーション作成時のコンパイル・リンク設定がまったく違っていたことでわかりました。 私の失敗をこじつけるならば、INtime®アプリケーションがWindowsアプリケーションのように作成できてしまうために(まったくINtime®を意識せずに)、見た目には違いを認識する部分が少ない！ そのため、INtime®とWindowsという境目がみえなかったのだ・・・！(苦)。 |
 |
本日の感想 |
|
INtime®とWindowsの違いをまざまざと感じる私でした・・・。
|
|
|