μITRON4.0仕様について

μITRON4.0仕様についてFAQ形式で詳しくお答えいたします。

周期ハンドラの説明の中に出てくる「起動位相以上」について

μITRON仕様書の「4.7.2 周期ハンドラ」で、p.241～p.242(Ver.4.03仕様書のページ数)に跨る以下の文章の「起動位相以上」の意味を教えてください。
「周期ハンドラの起動位相は、周期ハンドラを生成するサービスコールが呼び出された時刻からの相対時間であるため、周期ハンドラの初回の起動は、周期ハンドラを生成するサービスコールが呼び出されてから、指定された起動位相以上の時間が経過した後に行うことを保証しなければならない。」

解答

これは、「2.1.9 相対時間とシステム時刻」で説明している相対時間の扱いに関する共通規定を、起動位相について適用して表現したものです。
相対時間について、少し補足します。

μITRON4.0仕様では、実際にその時間イベントが発生するのは、指定した相対時間が経過した後でなければなりません。つまり、以下の関係を保証しなければなりません。
　(時間イベントが発生するまでの実時間)≧(指定した相対時間)
ほとんどのカーネルでは、固定周期のタイマ割込みを使用するので、以下その前提で例を使って説明します。

例１：
システム時刻の単位時間が１ミリ秒、タイマ割込み周期も1ミリ秒の場合で、システム時刻＝２の時にtslp_tsk(3)を呼び出したケースを考えます。単純に考えると、２＋３＝５でシステム時刻５でタイムアウトすれば良いように思ってしまうかもしれませんが、そうではありません。システム時刻が２というのは、システム時刻が２に更新されてからいくらか実際に時間αが経過しています。αは、(0＜α≦タイマ割込み周期時間＝1ミリ秒)の範囲を取り得ますが、当然ながらカーネルはαを認識できません。したがって、上式を確実に満たすには、次回のシステム時刻３への更新タイミングを起点に相対時間3を計測する必要があります。その結果、本例ではシステム時刻6への更新タイミングでタイムアウトする動作が正しいことになります。

例２：
システム時刻の単位時間が１ミリ秒、タイマ割込み周期が５ミリ秒の場合で、システム時刻＝１０の時にtslp_tsk(11)を呼び出したケースでは、下図のようにシステム時刻25への更新タイミングでタイムアウトする動作が正しいことになります。

ページトップへ戻る

周期起動ハンドラの起動タイミングが仕様書を見ても分かりづらいので、解説をお願いします。

解答

周期ハンドラを起動すべき時刻は、各回次毎に起点となる時刻からの相対時間で決定します。具体的には、以下のケースがあります。なお、相対時間の扱いについては、Queston1の回答を参照してください。

TA_PHS属性の指定がない場合
- TA_STA属性によって、生成時に動作開始した場合1
  生成時点を起点として、ｎ回目のハンドラ起動までの相対時間Tnを以下のように扱います。
  　　　Tn = (起動位相) + (起動周期)×(n-1)
- sta_cycによって動作開始した場合
  sta_cyc時点を起点として、ｎ回目のハンドラ起動までの相対時間Tnを以下のように扱います。
  　　　Tn = (起動周期)×n
TA_PHS属性の指定がない場合
生成時点を起点とし、n回目のハンドラを起動タイミングまでの相対時間Tnを(1)の(a)と同じ扱いとします。ただし、そのタイミングで周期ハンドラが起動されるかどうかは、その時の周期ハンドラの動作状態に依存します。
なお、起動周期がタイマ割込み周期より短い場合は、同じタイミングで2回以上周期ハンドラを起動しなければならないケースがあることにも注意してください。例えば、周期ハンドラの周期時間が２ミリ秒で、タイマ割込み周期時間が４ミリ秒の場合、タイマ割込みのたびに2回周期ハンドラを起動することになります。もし、タイマ割込みのタイミングで1回しか周期ハンドラを起動しない場合、上記仕様を満たしていないことになります。

ページトップへ戻る

ディスパッチ禁止状態では、タスク例外処理ルーチンは起動されるでしょうか？

解答

これは、仕様書「4.3　タスク例外処理機能」の【補足説明】にありますように、起動すべき条件が揃った場合に、タスク例外処理ルーチンは起動されます。タスク例外処理ルーチンの起動時と終了時でディスパッチ禁止状態は変化しないことは仕様で規定しています。ここで注意しなければならないのは、タスク例外処理ルーチン内でディスパッチ許可にする要求を行うと、タスク切替が発生する可能性があるということです。

したがって、タスク例外処理ルーチン内でディスパッチ許可状態にする要求を行う場合、そのタスク例外処理ルーチンを定義するタスクがディスパッチ禁止状態にする場合、ディスパッチ禁止状態にしている処理の間、タスク例外処理禁止状態にする必要があります。

ページトップへ戻る

CPUロック状態において、待ち状態になる可能性があるサービスコールを要求した場合はどうなるでしょうか？

解答

これは、仕様書「3.5.4　CPUロック状態」にありますように、CPUロック状態では呼び出せるサービスコールが限定されています。限定されているサービスコール以外のサービスコールを要求した場合は、E_CTXエラーになります。
ただし、E_CTXエラーは実装定義で省略されることがあります。省略された場合の動作は未定義です。

ページトップへ戻る

E_CTXエラーが返却されるのはどのようなときでしょうか？

解答

E_CTXエラーは、サービスコールを呼び出したコンテキストが、そのサービスコールを呼び出せる状態にないことを示すエラーです。
具体的な状況例を以下に示します。

タスク（タスクコンテキスト）から、iact_tskなどの非タスクコンテキスト専用のサービスコールを呼び出した(仕様書　3.6 非タスクコンテキストからのサービスコール呼び出し)
割込みハンドラなどの非タスクコンテキストで、chg_priなどのタスクコンテキスト専用のサービスコールを呼び出した。
なお、待ちになるサービスコールなど、暗黙的に自タスクを指定するサービスコールはすべてタスクコンテキスト専用になっています(仕様書　3.6 非タスクコンテキストからのサービスコール呼び出し)
CPUロック状態において、act_tskなどCPUロック状態では呼び出すことのできないサービスコールを呼び出した(仕様書　3.5.4 CPUロック状態)
ディスパッチ禁止状態において、slp_tskなどの待ち状態になるようなサービスコールを呼び出した(仕様書　3.5.5 ディスパッチ禁止状態)
（ただし、ディスパッチ禁止状態で待ち状態になる可能性があるサービスコールを呼び出した場合、無条件にエラーとするか、待ち状態になる条件が満たされるときにエラーを検出するかは実装に依存します。例えば、セマフォカウントが正のセマフォに対してwai_semを呼び出した場合、エラーとなるカーネルと、正常終了するカーネルがありえます。）

等々

ただし、E_CTXエラーは、呼出しコンテキストエラークラスに属し、その検出は実装定義で省略することができます（仕様書　2.3.2　ITRON仕様共通定数　（２）メインエラーコード）。つまり、E_CTXエラーが返るかどうかは、カーネル実装毎に異なります。

検出を実装定義で省略可能なエラークラスには、この他に内部エラークラス、未サポートエラークラス、パラメータエラークラスがあります。エラーの検出を省略したカーネルの場合、そのエラー条件が発生した場合の振る舞いは未定義です（仕様書　2.1.6　サービスコールの返値とエラーコード）。

ページトップへ戻る

スタンダードプロファイルにおいて、タスクや周期ハンドラ、アラームハンドラの起動時に動的なパラメータ(変数)を渡すには、どうすればよいのでしょうか？

解答

静的APIによるタスクの生成時に、拡張情報(exinf)へグローバル変数のポインタを指定し、exinfを介してグローバル変数を参照する方法があります。