|
|
≪割り込みイベント≫ |
| 「ボタン及びキー処理」の様なイベントは、割り込みイベントであるのが理想である。割り込みイベントと言っても割り込み入力を使う訳ではなく、割り込み(キーの場合はタイマ割り込み)の中でイベントキューに追加される。
図割イ-1
イベントキューへの書き込みは、全割り込みで共有されるため、割り込みは多重割り込みを禁止しなければならない。(割り込み中は割り込みがかからない) 割り込み中のイベントは全てイベントキューに追加されるので、適切にキューから引き上げる事ができれば、イベントのハンドリングは簡単になる。 通常はフォアグラウンドでイベントキューから取り出し、適切なアクションを行う事になる。
注意しなければならない事が1つ。割り込みイベントに対するアクションの中でタイムクリティカルなものは、割り込みの中で処理しなければならない事。 この場合、「処理しましたイベント」をイベントキューに追加して、フォアグラウンドで認識する事になる。 |
|
≪非割り込みイベント≫ |
| イベントを処理する事に連動して、新たなイベントが発生する事がある。たとえば、キーのイベントに連動して、内部シーケンスを進めて行く様な場合、シーケンス変更イベントが発生する。 この場合は、非割り込みにおいてイベントが発生するため、先のイベントキューと同一のキューに追加する事ができない。 このため、イベントキューを2つ持ち、「割り込みイベント」を「イベント」、「非割り込みイベント」を「メッセージ」として区別する。
図非イ-1
メッセージを処理する側はフォアグラウンド、追加する側もフォアグラウンドなので、読み書きの区別が保たれる。 イベントキューは書き込み側が割り込み、読み出し側がフォアグラウンドとなる。 |
|
≪イベントハンドリング≫ |
| 割込み、非割込みなどの様々なイベントを処理する部分がないとソフトとしては機能しない。 オーソドックスなのはシーケンス制御の様なループ構造のメインループ。
図メ−1
正しくはオーソドックスかどうか不明。筆者はよっぽど非力なCPUでないと、この方法は使わない。 OSを使わない場合、ほとんどの皆さんはコレではないだろうか。
実は制御ソフトというのはその処理のほとんどにおいて、イベントハンドリングばっかりしている。 イベントは前の状態と今の状態の差で発動させる。 具体的には、前の状態を保持する変数があって、今の状態と違っていれば、サブルーチンを呼ぶとかする事になる。 変数への保存や比較する部分をメインループやサブルーチン部分に記述する事になる。 これでも小規模なモノは十分うまく動く。 ただ、この部分は本来したい動作ではない。 本来したかった事は『何か外部の制御』であって、『イベントハンドリングなどの制御構造』ではない。 ソフトの規模を大きくするためには、制御構造を単純化させる必要がある。 具体的には制御構造が必然的に機能を表す様な構造を採用する必要がある。
OSレスでイベントハンドリングを行うには、メッセージモデルが最適だと、筆者は思う。 |
|
≪メッセージ≫ |
| 筆者がメッセージモデルと出会ったのは、Windows3.0からである。 組込の話をしているのに、Windowsは関係無いと思われるかもしれないが、「イベントドリブン」という考え方は、それ以前の組込モデルには見られなかった。(筆者が知らかっただけだとも思われるが) 前述した様に、非割り込みのイベントを処理するのがメッセージという事になる。 メッセージというのは今の生活に例えると、メールに似ている。そして割り込みは電話に似ている。 メールは送ってさえ置けば、相手がいつ見るかは大した問題ではない。反対に電話はかけた時に相手が出る事が前提となる。
|
|
≪キュー
≫ |
| |
|
≪テキスト表示≫ |
| |
|
≪静的記憶
≫ |
| |