C# と VB.NET の質問掲示板

ASP.NET、C++/CLI、Java 何でもどうぞ

C# と VB.NET の入門サイト

Re[18]: ＯＳの仕組み

(過去ログ 129 を表示中)

[トピック内 20 記事 (1 - 20 表示)]　 << 0 >>

■76660 / inTopicNo.1)

　ＯＳの仕組み

▼■

□投稿者/ ろーろるぷろぐらま (1回)-(2015/07/31(Fri) 08:35:50)

分類:[討論]　

ＲＳ２３２Ｃについてこっちにスレ立てさせていただきます。

○「デバドラは割り込みを直接ハンドルしない」

＜＜ハードウエアの割り込み処理なしにどのように「デバドラ」を書くのか
私には理解できません。＞＞

「直接ハンドル」してたのは昔懐かしいＭＳ－ＤＯＳや32bitＤＯＳエクステンダの
時代です。近代のＯＳではWindowsがそうであるようにハードウェアに依存している
ミニポートドライバと依存しないデバイスドライバの階層に分かれていてハードウェ
アの割り込み自体はＯＳがハンドリングします。
いや、この言葉を見たとき「懐かしさ」でいっぱいですよ、本当に。なにしろ割り
込みコントローラーの処理まで全部自前で書いていたのですから、そういう意味では
＜＜ハードウエアの割り込み処理なしにどのように「デバドラ」を書くのか
私には理解できません。＞＞
はおっしゃるとおり。
ちなみにＰＣ－ＡＴのＲＳ２３２Ｃと日本のパソコン（ＰＣ９８代表）とは信号線の
アサインの違いでＰＣ－ＡＴでは同期モデムが使えなかったのは、これまた懐かしい
話。
特にいわゆるチップセット（ＢＸチップセットとかね）がＰＣ－ＡＴ互換機で使われ
始めたころからＵＳＲＴは個別のＬＳＩとしてではなくチップセットに内包されて
たはず。今やグラフックも内包しててＰＣ－ＡＴ互換機アーキテクチャ自体がもは
や過去のもの？？

で、何度も書きますがＲＳ２３２ＣはWindowsにおいてはイベントを発生しないデバイ
スです。受信データ有りとか送信バッファエンプティの「割り込み」はＯＳとしての
Windowsを経由してデバドラに渡されますがデバドラはそれをＯＳ配下のアプリケー
ションに通知することはありません。これは１００％ガチです。

ですから
>>「モジュールに渡します」
＜＜どーやって？？？
となったのです。

引用返信 編集キー/

■76663 / inTopicNo.2)

　Re[1]: ＯＳの仕組み

▲▼■

□投稿者/ hata (3回)-(2015/07/31(Fri) 14:10:40)

たぶん私(hata)に宛てた発言であると理解し、回答します。

あなたは「シリアル通信でバッファオーバーランが発生する」
に発言された「通りすがり」さんでしょうか？
もしそうだとすると、あなたは次の２点でこの掲示板の
「利用方法/規約」に反していますよ。

１、「無責任な発言や、他人の悪口・個人情報などは書き込んではいけません。」
　>>質問の掲示板にオオウソを書くのはどうかと思いますがいかがでしょ？
　と言う発言に関して、「オオウソを書いた」と言うのは明らかに悪口です。
　ちなみに「発言の内容が間違っていませんか」と書くのは悪口では有りません。

２、「一貫して同じハンドルを使用し、場を混乱させないようにしましょう。」
　「とおりすがり」「ろーろるぷろぐらま」と言う２つのハンドルを使っている。
　私はあなたが「とおりすがり」さんか否かわからなくなっています。

さて、デバイスドライバーに関して掲示板に詳細に書くことは時間の無駄です。
前にも書きましたが、「ウィキペディア」で「デバイスドライバ」の説明を
閲覧するか、Googleで「ＭＳＤＮ　ハードウェア割り込みの処理」と検索して
下さい。
ここには、
『フレームワークベースのドライバーは、フレームワーク割り込みオブジェクトを
使用してハードウェア割り込みを管理します。』
と書かれています。
あなたのおっしゃる
○「デバドラは割り込みを直接ハンドルしない」
とはいったどのようなことを言っているのでしょうか。
「ＭＳＤＮ」の「ドライバーとは」という項目には、
「ドライバーがデバイスからデータを取得した後、
データはオペレーティングシステムに返され、
さらにアプリケーションへと返されます。」
と書かれています。

>>何度も書きますがＲＳ２３２ＣはWindowsにおいてはイベントを
発生しないデバイスです。

「RS232C」は通信規格の名前です。（正しくはRS-232Cですが）
RS232Cの何がイベントを発生しないのでしょうか。
.NETの「SerialPortクラス」のことでしょうか。
これのは「DataReceivedイベント」と言うイベントが有ります。
RS-232Cの受信側がデータを受信した時、イベントが起きます。

>>「Windowsを経由してデバドラに渡されますが」
逆じゃないですか？
ハードウエアがデータを受信する -> デバイスドライバ―がwindows
上にある.NETの「SerialPortクラス」のインスタンスのイベントを
起こす。（受信割込み　DataReceivedイベント）

引用返信 編集キー/

■76664 / inTopicNo.3)

　Re[2]: ＯＳの仕組み

▲▼■

□投稿者/ 774RR (289回)-(2015/07/31(Fri) 15:00:03)

喧嘩しない。

この辺は用語というか文言というか、どの層に注目しているかだけの問題だ。
用語「デバイスドライバ」 (Windows 業界) の解釈が違うだけのこと。

ハードウエア割り込みの処理
Windows ではハードウェア密着層（デバイスドライバの最下位層）は Windows Kernel が取り扱う仕様だ。
オイラたち「デバイス屋」でもハードウエア割り込みハンドラのエントリーポイントを記述しない。
Windows Kernel の最下位層ルーチンによって IRQ ディスパッチされた後に
「デバイス屋」の組んだデバイスドライバー部に処理がくる。

という意味で
>>「デバドラは割り込みを直接ハンドルしない」
>>「Windowsを経由してデバドラに渡されますが」
この表現はきわめて適切。

ハードウエアがデータを受信する -> Windows Kernel の最下位層が処理をし (ミニポートドライバ)
-> 各デバイスメーカが作るデバイスドライバが呼ばれ
-> デバイスドライバ―が windows kernel 中間層に通知する
-> Windows 上位層 (この場合 .NET SerialPort) が Application EXE に対して処理を発行する
ということで、用語「デバイスドライバ」を
・専門家として狭義に解釈するなら、デバイスドライバは割り込みを直接ハンドルしない
・一般ぴーぽーとして広義に解釈する（ミニポートドライバとデバイスドライバを一括して「ドライバ」とする）
　なら、ドライバは割り込み（やそれに関連して行わねばならない処理）をハンドルする
わけで、両方正しい。

イベントを発行する、しない、ってのもオイラ的には視点の問題、見ている層の違いだとしか思えない。
SerialPort クラスが EXE に DataReceived を通知する、というのは
EXE 作ってる側としてはイベントが通知されると考えて差し支えない。

Windows の下の層でデバイスドライバ的ミニポートドライバ的オイラ的には謎な用語「イベント」を
使っているかどうかを、一般 EXE プログラマは気にする必要は無いよ。

引用返信 編集キー/

■76665 / inTopicNo.4)

　Re[3]: ＯＳの仕組み

▲▼■

□投稿者/ hata (4回)-(2015/07/31(Fri) 16:19:07)

元の投稿は
ReceivedBytesThreshold = 1として読み込んでいるにも
かかわらず長時間稼働していると「Buffer Overrun」と言う
珍しエラーを吐くという質問なので、きっとこれは
DataReceivedの中で読んでいるつもりが、実は読んでいないのでは
と思い、それなら条件無に読むだけの読み捨てプログラムにして、
それでもエラーが出るか否かをチックすればいいのかなと思って
投稿したのですが、横からガブリと。
無視した方が良かったと反省。

よく読むと、「Buffer Overrun」の投稿主は別スレでUSBシリアル変換
使用と書いてありました。
これだとちょっと話が変わって、「どこの変換アダプターを使ってるの？」
と言うところから始めないといけない気もします。

引用返信 編集キー/

■76669 / inTopicNo.5)

　Re[4]: ＯＳの仕組み

▲▼■

□投稿者/ 通りすがり (20回)-(2015/08/01(Sat) 08:39:30)

774RRさん、丁寧にありがとうございます。要はWindowsはシリアル通信デバイスでは
イベントを発生させることはないってことを言いたかったのです。

hataさんの書き込みではどうみてもデバイスドライバあるいはOSとしてのWindowsが
イベント（いわゆるWM_???で定数定義されたイベント）が発生するように読めてし
まい、「オオウソ」だからです。
真実に合致する部分が全然ない場合は「間違い」ではなく「嘘」ではないですか？

<<逆じゃないですか？
ハードウエアがデータを受信する -> デバイスドライバ―がwindows
上にある.NETの「SerialPortクラス」のインスタンスのイベントを
起こす。（受信割込み　DataReceivedイベント）>>

ハードウェアの割り込みとC#のイベントを混同しています。これは「間違い」では
なく「嘘」です。「オオウソ」という表現はつつしんでお詫びします。ですが、
「嘘」は「嘘」。

掲示板マナーについてはコメントはしません。

引用返信 編集キー/

■76670 / inTopicNo.6)

　Re[5]: ＯＳの仕組み

▲▼■

□投稿者/ 魔界の仮面弁士 (428回)-(2015/08/01(Sat) 11:11:25)

2015/08/01(Sat) 12:25:36 編集(投稿者)

■No76669 (通りすがりさん) に返信
> イベント（いわゆるWM_???で定数定義されたイベント）が発生するように読めてし
それは「イベント」の定義次第では無いでしょうか。

メッセージベースの通信だけがイベントでは無いと思います。たとえば
シグナルによる割り込みをイベントとして扱う処理系だってありますよね。

その一方で、イベント・シグナル・メッセージなどを、それぞれ
別の用語として捉える処理系や考え方も確かにあります。ただ、
それは捉え方の違いによるものであり、そのどちらかが
嘘というわけでは無いはずです。

で、話を本題に戻すと…SerialPort クラスの場合、内部スレッドが
Win32 の WaitCommEvent API を待ち合わせる実装になっています。
https://msdn.microsoft.com/ja-jp/library/cc429842.aspx
https://msdn.microsoft.com/en-us/library/windows/desktop/aa363479.aspx

この API は、関数名の末尾に Event の名を冠しておりますし、
SDK における同関数の説明でも
》 The set of events that are monitored by this function is contained in the event mask associated with the device handle.
》この関数で監視するイベントは、デバイスのハンドルに関連付けられているイベントマスクによって示されます。
のような表記があることから、Windows の世界にとってみれば、これもまた
「イベント」の一種と呼ばれる仕組みであることは明確であるかと思います。
それが WM 系メッセージを用いていようといまいと。

引用返信 編集キー/

■76672 / inTopicNo.7)

　Re[6]: ＯＳの仕組み

▲▼■

□投稿者/ 通りすがり (21回)-(2015/08/01(Sat) 19:53:19)

(魔界の仮面弁士さん) に返信

いやいや、割り込みとイベントは全く違いますよ（と思います）。割り込みは待つものではなくて
「かかるもの」。日本語では処理に割り込みをかけるって言いますよね。

だからイベントと割り込み処理を混同すると色々問題が発生します、と思うわけで。

魔界の仮面弁士さんに対しては釈迦に説法かも知れませんが少なくとシステム処理さえもマスクして
ない場合は「割り込まれてしまう」のでイベントとは違います。
だってinterruptだしSDKでも確かそう書いてあったと思うです。

引用返信 編集キー/

■76673 / inTopicNo.8)

　Re[7]: ＯＳの仕組み

▲▼■

□投稿者/ hata (5回)-(2015/08/02(Sun) 11:21:56)

そう思うならそれでいいんじゃないかな、
誰にも迷惑はかからないし。
反論したくても書かれたことが意味不明で、
理解できません。

割り込みとイベントが同じだとは誰も書いてない。
「割り込みをイベントとして扱う処理系がある」
と書かれている。

https://msdn.microsoft.com/ja-jp/library/cc418107.aspx
MSDNには「割り込みを処理するための主な方法は、イベントを、
指定された ISR に関連付けることです。」
と書いてある。
これは割り込みがかかるとそれに関連したイベントが起きると
考えても差し支えないのでは。
すなわち、このイベントが起きた時に、「割り込みがかかった」と
言っても間違いではない。

http://www.technoveins.co.jp/dev/vb2005/serialport.htm
「シリアル通信LSIがデータを1バイト受信すると、ハードウェア割り込み
が発生します。
ハードウェア割り込みによりデバイスドライバは、シリアル通信LSIのFIFOから
データを受け取り、自分のドライバ内の受信バッファに保存するとともに
、Windowsにメッセージ通知します。」
と書いてある。
ここの記事が100%正しいか否かは不明なれど、大筋で間違っていないでしょう。

引用返信 編集キー/

■76674 / inTopicNo.9)

　Re[8]: ＯＳの仕組み

▲▼■

□投稿者/ 通りすがり (22回)-(2015/08/02(Sun) 13:50:43)

（と思います）と書いたのは言い切ってしまうとトゲトゲしいからです。じゃ言い切りましょう、

いやいや、割り込みとイベントは全く違います。
書いたように英語でも全然違う言葉で、意味も違います。同じだという認識はいい加減捨てましょう。

何度も書きます。シリアル通信においてWindowsではイベントを待つＡＰＩは存在しますがイベント
発生を原因とするコールバックは存在しません。
.netではスレッドを作成してイベントを待つＡＰＩを呼び出し結果が返ってきたらそれをトリガとし
てOnRecieveを呼び出しするって実装です。ＶＢ６．０ではサポートＯＳがWindows95のようなスレッ
ドをサポートしないＯＳだったためＣＯＭポートのハンドリングは本当に大変だったのです。

同様な勘違いはタイマーイベントにも良くあります。あたかも定期的に処理に「割り込んでくる」よ
うに見えるタイマーですが実際にはWindowsがWM_TIMERをPostMessageするだけで実際に呼び出すのは
プログラムのWindowsメッセージハンドラです。したがって「タイマー割り込み」っていうのはウソ
です。
なので他のメッセージ処理中にはタイマー処理は呼び出されません。VB6.0ではDoEventsだったかを
適当にはさんでタイマー処理を動かすことができますがDoEventsでは他のメッセージも処理しますの
で色々予想もしないことが起こったりします。

「受信割り込み」は本当にハードウェアが発生する割り込みなのでOS側マスクしない限りは必ず
処理の分岐が発生します。
https://msdn.microsoft.com/ja-jp/library/cc418107.aspx
あ、こっちのほうがより適切にかかれてますよね。Windows CEですけど。

引用返信 編集キー/

■76675 / inTopicNo.10)

　Re[9]: ＯＳの仕組み

▲▼■

□投稿者/ hata (6回)-(2015/08/02(Sun) 16:10:04)

割り込みとイベントに関しては堂々巡り。

Windows 95はマルチスレッド対応。
http://digital.ni.com/public.nsf/allkb/862567530005F0A1862568C00079EFC2
VB6が原則マルチスレッドに未対応だった。

「MSComm コントロールを使用してデータの送受信を行う方法」
https://support.microsoft.com/ja-jp/kb/411403
VB6MSCommのころより受信には「イベントドリブン方式」が
採用されていて、簡単にRS-232Cの通信が可能だった。

DoEventsは簡単に言うと、現在のイベントが終了するのを待たずに、
メッセージキューにたまっているメッセージを処理するコマンドで
VB6のタイマーコントロールとは無関係。

あなたの示したサイトは一つ前の投稿で私が示したMSDNのサイトと
同じですよ。

引用返信 編集キー/

■76676 / inTopicNo.11)

　Re[10]: ＯＳの仕組み

▲▼■

□投稿者/ ??????? (1回)-(2015/08/02(Sun) 18:02:26)

hataさん、Windows95はスレッド対応ですね。Win32sと混同してました。
でも当時主流であった16bitからは呼べないので使われてなかったってことですね。
これについてはウソでした。ごめんなさい。

堂々巡りではありません。明確に言葉も概念もイベントと割り込み（インタラプト）とは違います。
混同してはいけない概念です。一般にOSの管理下にあるプログラムは割り込みは検知しませんし、
できません。スレッドのタイトルが「OSの仕組み」ってなってるのはそういう理由です。

OSはハードウェアの割り込みを管理ハンドルし、必要があればそれを管理下のプログラムに通知しま
す。それがイベントです。「必要があれば」と書いたのはシリアル通信のようにそれが実装されない
場合があるからです。
シリアルポートの「受信割り込み」と「受信通知イベント」を混同してはいけません。「受信割り込み」
は必ずしも「受信通知イベント」を生成するとは限りません。hataさんの開発レベルは知らないのですが
同期モデムの場合は常に「受信割り込み」は発生しますが「受信通知イベント」は本当に接続があった
時にのみ発生します。同期モデムは常にシンクデータを送り続けるのでこれは当然です。
PC-AT互換機には同期モデムは専用のボードを増設しないと接続できないのでPC98のようなJa-JpなPCで
はシリアルポートのドライバ自体がPC-ATのそれとは異なると思います。

引用返信 編集キー/

■76677 / inTopicNo.12)

　Re[11]: ＯＳの仕組み

▲▼■

□投稿者/ 通りすがり (23回)-(2015/08/02(Sun) 18:03:32)

ハンドルネーム設定し忘れ

引用返信 編集キー/

■76678 / inTopicNo.13)

　Re[12]: ＯＳの仕組み

▲▼■

□投稿者/ 通りすがり (24回)-(2015/08/02(Sun) 18:05:58)

ちなみにURLはhataさんの書き込みからのコピペですよ。Windows CEですけど。って書いたのに。

引用返信 編集キー/

■76681 / inTopicNo.14)

　Re[13]: ＯＳの仕組み

▲▼■

□投稿者/ hata (7回)-(2015/08/03(Mon) 09:27:25)

何度も言いますが、割り込みとイベントが同じなどとだれも
言っていません。
・割り込みとは、実行中の処理を中断して、強制的に指定された処理を実行させること。
・イベントとは、システム内で偶発的あるいは非計画的に生じる操作や挙動・
　状態の変化およびそれらを非同期的に特定のモジュールに通知するための仕組みのこと。
この程度のことはプログラムをするものとして当然理解しています。

>>「要はWindowsはシリアル通信デバイスでは
>>　イベントを発生させることはないってことを言いたかったのです。」
とあなたは書いていますが、「シリアル通信デバイス」とはいったいなんでしょうか？
UART（Universal Asynchronous Receiver/Transmitter）のような物のことを言われて
いるんでしょうか？
もしそうだとしたらWindowsがUART上でイベントを発生させることなんか無いのは
当たり前ではないですか。

もしUARTが１バイトのデータを受信し、ハードウェア割り込み発生が発生され
何らかの通知が.NETのSerialPort クラスに通知されたとして、その中にイベント
と言う動作が無いとしたら、
https://msdn.microsoft.com/ja-jp/library/system.io.ports.serialport(v=vs.110).aspx
https://msdn.microsoft.com/ja-jp/library/system.io.ports.serialport.datareceived(v=vs.110).aspx
ここに定義されているイベントとはいったいなんですか？
この中のイベントがあなたの定義するインベントと異なっていたら、もんくは私にではなくマイクロソフトに
言ってください。

>>hataさんの開発レベルは知らないのですが
不特定の人が書き込む掲示板で、ハンドル名だけからその人のプログラムの技量を推察
することは不可能です。
書き込み人はそのことを踏まえて書き込むべきです。

私ですが、.netでSerialPortのプログラムを書こうとして、ＷＥＢで検索する人は殆ど
１回は私のサンプルを見ると思いますよ。
プログラム歴は、8080チップの評価ボードがインテルから発売された時からですから、
多分あなたより長いでしょう。
書いたことのあるソフトは、
8080系のマシーン語、8080系のマクロアッセンブラー、basic、N-88basic、okibasic
IBM RPG、VB2～VB6、Ｃ言語、C++、VisualC#、VisualBasi、Java、Pyson、
ＸＭＬ、ＨＴＭＬ、ASP.NET、Javascript、ANDROID、ＰＨＰ等です。
ハードに関しては、
音響関係のアンプ、Ｐｉｃマイコン、モーターのサーボアンプ等です。

引用返信 編集キー/

■76682 / inTopicNo.15)

　Re[13]: ＯＳの仕組み

▲▼■

□投稿者/ 774RR (290回)-(2015/08/03(Mon) 09:32:24)

Windows Kernel を離れて .NET Framework においては「イベント機構」ってのがある
VB.NET でも C# でも
・ event というキーワードを使って「何か起きたときのアクション」を定義し
・その event に delegate を登録して「 callback 形式で呼び出してもらう」
・呼び出し側と呼び出され側が、これによって簡単に分離できる
という機構。

referencesource を見てまで確認してないけど、元ネタ発言における
DataReceived/ErrorReceived はたぶんこの event/delegate 機構で呼び出されているとオイラは思う。
一般プログラマは当該 event がどういう経路をたどって呼び出されるかは気にしなくていい。
オイラ最初からそういう意味で「イベント」が発生していると書き込んでるんだが。

立場が違えば「その業界に限定される特別な用語」の限定的意味は違う。
相手にそれを押し付けたら行き違いが生じるだけだ。
枝葉末節だけに異常にこだわってもしょうがないよ。

引用返信 編集キー/

■76684 / inTopicNo.16)

　Re[14]: ＯＳの仕組み

▲▼■

□投稿者/ hata (9回)-(2015/08/03(Mon) 09:45:55)

追伸：
余計なことを書き込みましたが、私が唯一言いたかったことは、
.NETのSirialPortクラスは素晴らしく安定したクラスだということです。
通りすがりさんの投稿の中で、SirialPortクラスは不安定であるかのような
発言が有り、これを見た人がSirialPortクラス使用をた躊躇うように
なればそれはその人にとって不幸なことではないかと思って書き込んだ
までです。

４年ほど前に、SirialPortを６個、ＧＰＩＢ、I/Oポートを持ち、
合計８軸のロボットを動かしながら、半導体ベアチップの測定
をするプログラムを書きました。
その結果Windows Xp以降のWindows Os上で動作するこれらの
モジュールは素晴らしく安定したパフォーマンスを示し、３年間
全く不具合無に、良好なログを吐き続けました。
Socket クラスも含め安心して使ええるモジュールだと思います。

ただし、残念なことに、RS-232CーUSB変換ケーブル（器）は
何らかの事情でCom番号が変わってしまうというトラブルが有り、
私的にはプロ仕様にはそぐわないと考えています。（あくまでも私見）

引用返信 編集キー/

■76686 / inTopicNo.17)

　Re[15]: ＯＳの仕組み

▲▼■

□投稿者/ 774RR (291回)-(2015/08/03(Mon) 10:37:19)

以下雑談

.NET Framework 1.1 には System.IO.Ports.SerialPort なかったはずで
当時は COM なり InteropServices なりで Win32 API を自分でほげほげしてた。
この辺は manage/unmanage の両方を理解していないと簡単にバグを埋め込んぢゃう。
この頃から .NET でシリアルポート扱っている人は不安定な印象があるはず。

それに比べれば SerialPort を使う分には manage だけで済むんで安定してると思うぞ。
実際オイラんとこでもトラぶってないし。

RS232/USB 変換機は同一の変換機を異なる USB ポートに挿すと異なる COM 番号になる仕様。
別の変換機を同一 USB ポートに挿すと元の COM がまた変わりうる。
「かぶらない」という点では実にプロ仕様だとオイラ思うんだけど。

デバイスマネージャ→ポート→ポートの設定→詳細で COM 番号を変えることができるんで
COM 番号に関してはあまり困ったこと無いかな。
# 電話口で素人さんに手順を説明するとかなるとアレだけど

RS232/USB 変換機は USB 側の都合で 1byte-1byte なハンドシェイクを行うようなデバイスに使うと
超絶遅いのが難点だね。

引用返信 編集キー/

■76690 / inTopicNo.18)

　Re[16]: ＯＳの仕組み

▲▼■

□投稿者/ hata (10回)-(2015/08/03(Mon) 12:36:09)

そうでしたね、.NET Framework 1.1にはSerialPortが無くて、
ＶＢ６に逆戻りした人が多かった。
ＶＢ６の「MSComm」も使いやすいモジュールでずいぶんと
お世話になりました。(笑

プロ仕様と言う言い方はおかしかったですね、プロが作って
お客さん（素人）が使うという意味で。
ある日突然動かないというので、電話で対応するがわからない、
行ってみるとUSBのケーブルのさす場所が違っている。
機械を移動するときにさし替えたと言われる。
Comのコネクタ―だとさす場所が決まっているということは
素人でもわかるのだが、ＵＳＢの場合、きちんと番号を付けて
あっても違うところにさされるとことが何回かありました。
ＵＳＢはどこにさしても同じと言うイメージが有るのかな。

それとこれは完全にメーカー依存だと思うのだが、USB機器抜いたり
さしたりすると何かの拍子にＣｏｍ番号がダブってしまう。
この復旧方法を説明するのはかなりしんどい。
海外なんかに機械が行ってしまうと解決までに一汗かくことに。

「1byte-1byte なハンドシェイク」考えただけでも遅そうですね。
だいたいこのRS-232Cにしろ422にしろ昔から、おしゃべりな
機械同士の会話には向かない。
時々ボソリとのたまうような通信に向いている気がします。

引用返信 編集キー/

■76692 / inTopicNo.19)

　Re[17]: ＯＳの仕組み

▲▼■

□投稿者/ 通りすがり (25回)-(2015/08/03(Mon) 17:07:23)

枝葉末節ですか・・・・。

TK-80が発売されたころ全バイト代を突っ込んで組み立てて動かずに親になきついて
業者に直してもらった高校生でした。

[１回は私のサンプルを見ると思いますよ]

凄い自信だなぁ。だから「受信イベント」を「受信割り込み」って書いて同意だとして
るわけだ。たぶん自分も見てるでしょうね。去年だったかにRS232Cでデータを受ける
「まともに動く」サンプルって奴を作った記憶があるので、そのときに見てる可能性
大だた。
プログラミング雑誌のライターをやってたため「枝葉末節だけに異常にこだわって」し
まいますわ。言葉を並べて金銭をいただく以上、こだわるわけで。

>>いわゆる「Event Driven」のイベントと「serialPort1_DataReceived」のような
>>イベントは別物です。

ここはうんうん、同意。

>>RS-232Cはガチガチのハードで、ハードウェアーから上がる割り込みを
>>デバイスドライバーが受けて、モジュールに渡します。

はぁ？？ってなりますよね。これ。誤解を招く表現でたぶん編集から直してねってお
願いされると思います。

・イベントとは、システム内で偶発的あるいは非計画的に生じる操作や挙動・
　状態の変化およびそれらを非同期的に特定のモジュールに通知するための仕組みのこと。

hataさんは運命論者？？システム内で偶発的あるいは非計画的に生じるって・・・hataさん
ご指摘のurl

http://www.technoveins.co.jp/dev/vb2005/serialport.htm

には「イベントをスケジューリングします」と書いてあります。明らかに計画的。だってス
ケジュールですから。ハードウェアの受信割り込みも「偶発的あるいは非計画的」に起こる
ものだったんですね。勉強になりました。ありがとうございます。

引用返信 編集キー/

■76695 / inTopicNo.20)

　Re[18]: ＯＳの仕組み

▲　■

□投稿者/ hata (12回)-(2015/08/03(Mon) 19:52:29)

細部にこだわるのは自由だけど人に押し付けるのはどうかな。
「木を見て森を見ず」という言葉もあるし。

・イベントとは、システム内で偶発的あるいは非計画的に生じる操作や挙動・
　状態の変化およびそれらを非同期的に特定のモジュールに通知するための仕組みのこと。
これは「IT用語辞典」
http://www.sophia-it.com/content/%E3%82%A4%E3%83%99%E3%83%B3%E3%83%88
のコピペで「不適切な表現などを発見した際..」とあるので苦情はそちらへどうぞ。

もうこの辺で止めます、堂々巡りですから

引用返信 編集キー/

トピック内ページ移動 / << 0 >>

このトピックに書きこむ

過去ログには書き込み不可

- Child Tree -