トップページに戻る(マイコン徹底入門:STM32で始めるARM/Cortex-M3組み込み開発)
「マイコン徹底入門」とは？ | 「マイコン徹底入門」を読む | ダウンロード | 掲示板 | 筆者の自己紹介
Previous: 1.1.1. OSを使わない場合 |
Up: 1.1. OSを使用する理由 |
Next: 1.1.3. リアルタイムOS |
このような単純なルーチンでも各周辺回路を同時に制御できます。しかしこのルーチンにはいくつかの問題があります。
まず、関数の実行頻度の問題があります。今回の例で言えば、PSDセンサの検出距離は1m近くありますから、マウスマシンの速度がよっぽど速くない限りは、1秒間に10回程度測定できれば、壁との衝突を避けることができるでしょう。そのためGetPSDDistance関数の実行周波数は10Hzもあればよいということになります。一方は、縁を検出するためのフォトインタラプタは、実際にマウスマシンが縁に到達して初めて、縁の存在を検出できます。縁を検出するのが遅れると、マウスマシンを停止させるのが遅れるので、マウスマシンが落下してしまいます。そこでGetEdge関数は、1秒間に100回程度は実行したいところです。しかし単純なループ処理であれば、各関数の実行頻度は同じになります。CPUが十分に高速ならばよいのですが、実行頻度が少なくてもよい処理まで高頻度で実行してしまうと、実行頻度が高くないといけない処理の処理周期が長くなってしまいます。各関数が実行される頻度を調整しようと思うと、関数内に一工夫が必要です。たとえば関数が呼び出される度にカウンタを加算していき、カウンタが一定数値に達した時点で初めて所期の処理を実行するという形にします。
次に各関数は必ず一定期間内に終了するように構成されていなければいけません。単純なループであれば、どれか一つの関数が、外部からの情報を無期限に待つような処理をしてしまうと、他の関数が実行されるのが待たされてしまいます。結果、ループ処理全体のタイミングが崩れてしまいます。どうしても長い時間待ちをしたいのであれば、最長の待ち時間を定めておいて、それが経過すると一旦関数の実行を終了させるといった処理が必要になります。
さらに、先の問題と関連する問題ですが、ループ全体の処理周波数は、各関数全体の処理時間の合計によって定まります。「1秒毎に」といった、現実世界の時間を基準にできるわけではありません。合計処理時間によって周波数が定まる以上、各関数が実行されるタイミングは、他の関数の実行時間に影響されます。例えば新しい機能を追加するために、ループ中に新たな関数を追加したとしましょう。そうすると、他のすべての関数の処理頻度が遅くなります。一方、ある機能を削減するために、対応する関数を削除すると、残りのすべての関数の処理頻度が速くなります。これを避けようと思うと、ループの開始部分や、各関数の冒頭部分で、タイマを利用して、「時間が1秒の倍数になったこと」などを検出して移行の関数に進むといった処理が必要になります。
いずれの問題点も、各関数に一定のしかけを盛り込むことで対応は可能です。ただ関数が増えてくると、「それぞれ関数の処理がシステム全体にどういう影響を与えているのか」を考えながら各関数を作成したり、また「ある関数を修正する度に他の関数が影響を受けない」よう他の関数も修正したりする作業はとても面倒です。ミスも起きやすいと言えるでしょう。そのため、こういった問題は、各関数の内部で対応するよりも、システム全体としてこれに対応できるような仕組みになっていることが望ましいと言えます
そこでマルチタスクOSの登場です。マルチタスクOSでは、OS上で並行して実行されるそれぞれの処理のことをタスクと呼んでいます。マルチタスク処理が実装されているOSを利用すると、各タスク(先ほどの例の各関数に対応します)に実行頻度を指定するだけで、各タスクがそれぞれ固有の実行周期で実行されます。OSはあるタスクの実行時間が一定時間を超えると、そのタスクの処理を一旦中断させて、他のタスクを実行させます。他のタスクの処理が一巡した時点で、中断していたタスクは中断したときの状態のまま再開されることになります。つまりマルチタスクOSを利用すると、タスクを実装する際には、あたかも他のタスクやOSが存在しないのと同じように、そのタスクの本来の目的のためだけにコードを作成すればよいのです。あとはOSが各タスク間での処理の切り替えや、実行頻度の調整を行ってくれることになります。
Previous: 1.1.1. OSを使わない場合 |
Up: 1.1. OSを使用する理由 |
Next: 1.1.3. リアルタイムOS |