目次

設計コンセプト

 C言語だけで、RTOSを実現すると決めましたが、それだけでは設計
 できないので、いくつか制約条件を与えます。

 制約が多いほうが、考えることが少なくなるので、以下を規定します。



システムコールは、μITRONに準拠

 μITRONの解説書は、巷に流布されていますし、μITRONを  利用したシステムの構築内容を説明したサイトが多数あり  ます。  説明サイトが多数あれば、システムコールそのものを解説  する手間を省略できると考え、μITRONにあわせます。  μITRONであれば、ゆるい規格化をうたっているので、引数  や動作をシステムに合わせて変更することもできます。  これらの理由から、システムコールは、μITRONに準拠します。

システムコール数は、少なく

 スケジューリングとディスパッチは、簡単に実現したり、  ノンプリエンプティブ動作にすると、システムコール数を  少なくできます。  システムコールが多いと、RTOS本体部分が肥大化してしまい  タスク切替え時間が長くなったり、コード領域の圧迫が出て  しまいます。  コード領域、メモリ領域が小さいマイコンでも動作するように  したいので、システムコールは、次の6個にしました。

タスク数は、最大16個まで

 コード領域、メモリ領域が小さいマイコンでも動作するように  したいので、タスクを最大16個に限定します。  複雑なことを実現しなければ、16個あれば充分でしょう。  マルチタスクという言葉の意味を考えれば、最小は2個のタスク  で動作させればよいことになります。  USOを使うならば、タスク数は3個以上16個以下が妥当です。

タスク状態は、5個

 μITRONでは、タスクは最小で3状態、最大で7状態をもてます。  システムによりタスク状態を変更してよいと規定されているので  次の5状態にします。  RUNは、タスクがCPUを使っている状態です。  READYは、CPUの割当てを待っている状態です。  SUSPENDは、時間待ちではないタスクの動作保留状態です。  WAITは、時間待ちによる動作保留状態です。  DORMANTは、休止状態でUSOから認識できない状態です。

タスクの起動、停止、時間待ちを担当

 機能満載のRTOSがありますが、USOは、次の3点だけに限定します。  他のタスク起動は、システムコールrsm_tskで実現します。  他のタスク停止は、システムコールsus_tskで実現します。  自タスク停止は、システムコールslp_tskで実現します。  時間待ちは、システムコールwai_tskで実現します。

スケジューラ、ディスパッチは、簡単に実現

 RTOSは、タスクを切り替えるために、スケジューラとディスパッチャが  必要になります。  USOでは、スケジューラとディスパッチャは、ラウンドロビンで実現します。  タスクをID順に並べておき、READYであればRUNにします。  RUNになると、タスクはCPUを使い必要な作業をします。  USOは、そのタスクの作業終了まで待ちます。  CPUの返却はタスクに任せるので、内部で無限ループすると  他のタスクにCPUを割当てられなくなります。  ラウンドロビンで、スケジューラとディスパッチャを実現する  ので、ノンプリエンプティブの動作になります。

目次

inserted by FC2 system