µITRON4.0 仕様
Ver. 4.01.00(社) トロン協会 ITRON 部会
坂村 健 監修／高田 広章 編

Copyright (C) 1999, 2001 by ITRON Committee, TRON ASSOCIATION, JAPANµITRON4.0 仕様（Ver. 4.01.00）
本仕様書の著作権は，( 社 )トロン協会 ITRON 部会に属しています．
( 社 ) トロン協会 ITRON 部会は，本仕様書の全文または一部分を改変することなく複写し，無料または実費程度の費用で再配布することを許諾します．ただし，本仕様書の一部分を再配布する場合には，µITRON4.0 仕様書からの抜粋である旨，抜粋した箇所，および本仕様書の全文を入手する方法を明示することを条件とします．その他，本仕様ならびに本仕様書の利用条件の詳細について
は，6.1 節を参照してください．
本仕様ならびに本仕様書に関する問い合わせ先は，下記の通りです．
( 社 )トロン協会 ITRON 部会〒 108-0073 東京都港区三田 1 丁目 3 番 39号 勝田ビル 5 階
TEL: 03-3454-3191 FAX: 03-3454-3224§ TRON は “The Real-time Operating system Nucleus”の略称です。
§ ITRONは “Industrial TRON”の略称です。
§ µITRON は “Micro Industrial TRON”の略称です。
§ BTRONは “Business TRON” の略称です。
§ CTRONは “Central and Communication TRON” の略称です。
§ TRON，ITRON，µITRON，BTRON，および CTRON は，特定の商品ないしは商品群を指す
名称ではありません。

µITRON4.0 仕様

Ver. 4.01.00

監修の言葉
ITRONは，機器組込み制御用リアルタイム・オペーレーティングシステムの仕様として TRONプロジェクトの開始とともに歩みはじめ，15 年が経過した．この間マイクロプロセッサの技術革新とともに，ITRONの適用範囲も大幅に広がり，工場のロボットや生産設備の制御といった産業分野での応用から OA 機器
や家電製品などコンシューマ用途，新しい情報通信機器，情報家電などに広く応用されるようになってきた．ITRON の技術的特長であるリアルタイム性，リソースを浪費しないコンパクトさ，柔軟な仕様適合性が適用範囲の拡大を着実に進めたとともに，TRONプロジェクトのオープンアーキテクチャポリシーが高い利用実績を押し進めたことは間違いない．
µITRON4.0はµITRON3.0をベースに概念や用語を整理し互換性や厳密性の向上をはかり，ソフトウェア開発の生産性向上や応用ソフトウェアの再利用性，移植性を高めることを目的として仕様を整理したものである．
その背景として，近年のネットワーク応用やインターネット，イントラネット
関連機器を中心として通信や GUI，デバッグ関連のミドルウェアが ITRON上で利用される機会が増加し，これらのミドルウェアの移植性向上に対する要求を満足するために仕様の互換性や厳密性を高める必要性が出てきた．ITRONはリ
ソースが少なく CPU 性能の低いプロセッサにも適用できるように弱い標準化とレベルという考え方で仕様が作られているがソフトウェアの移植性の観点からは強い標準化が要求され，この相反する要求を満たす仕様が µITRON4.0 である．互換性については全体としては弱い標準を維持しながら，レベルの考え方を発展させ，スタンダードプロファイルという属性を設け，この中ではソフトウェア移植性を実現する強い標準化がされている．また，スタンダードプロ
ファイル以外に応用向けごとに互換性を高めるためのプロファイル設定を可能とした．
また，仕様に出てくる用語や概念についても整理や定義や詳細説明を行い，実装依存の部分を極力減らし，仕様書の完成度を高めた．
µITRON4.0 は，これまでに培われた ITRONの豊富な経験と現場の声を反映し新しい応用に対する要求に広範に応えるものである．新しく生まれる新しい分野
を含め多くの分野で µITRON4.0 が導入され，有効に活用されことを期待している．
1999年 6月
坂村 健
トロンプロジェクト
プロジェクトリーダーiµITRON4.0 仕様

Ver. 4.01.00

まえがき1984 年に ITRON プロジェクトが開始されてから，今年で 15 年になる．その間の関係者の尽力により，組込みシステム用のリアルタイムカーµITRON 仕様は，
ネルのデファクト標準仕様と呼べるまでに発展してきた．この実績を背景として，ITRON プロジェクトでは， 1996 年頃より，標準化の範囲をリアルタイム
カーネル仕様からソフトウェア部品などの周辺仕様に広げた第 2フェーズの標準化活動に取り組んでいる．
µITRON4.0 仕様は，ハードリアルタイムサポート研究会 カーネル仕様 WG（1997 年 4 月〜 1998 年 3 月）とそれを引き継いだ µITRON4.0 仕様研究会 カーネ
ル仕様検討 WG（1998年 4 月〜 1999年 6 月）における 2年余りの検討の成果である．両 WG における仕様の検討は，月に 1回程度のミーティングを中心として，
電子メールによって議論を補う形で進めた．最終的に，仕様検討のためにやりとりされた電子メールは，1000 通をはるかに越えることとなった．さらに，
ITRON プロジェクトの他の標準化活動，とりわけ RTOS自動車応用技術委員会と µITRON4.0 仕様研究会 デバイスドライバ設計ガイドライン WG における検討結果も，µITRON4.0 仕様の重要な一部分を構成している．
ITRON プロジェクトでは，第 2フェーズの標準化活動における新しい試みとして，µITRON4.0 仕様の検討の場を，参加資格を限定せずに誰でも自由に参加できるオープンな研究会とした．それが大きな要因となって，それまで ITRON仕様の標準化活動に関与していなかった多くの技術者に，新たに標準化活動に参加していただくことができた．特に，リアルタイムカーネル開発サイドの技術者に加えて，アプリケーション開発サイドの技術者の参加を得られたことは，仕様策定上での意義が極めて大きかったと考えている．
µITRON4.0 仕様におけるもう一つの新しい試みとして，ソフトウェアの移植性を確保するためのスタンダードプロファイルを規定したことが挙げられる．これまでの弱い標準化の方針下では，検討メンバの意見が割れた場合に，両者の意見を仕様に取り込み，実装でどちらを採るかは実装依存とするという妥協策が可能であった．ところが，スタンダードプロファイル規定を定める際には，µITRON 仕様のそれぞれの機能を一通りに標準化することが必要であり，検討
メンバの意見が対立する場面もあった．しかしながら，µITRON4.0 仕様の検討過程で出会った意見の対立のほとんどは，各々の技術者が主に取り組んでいる
アプリケーション分野における要求事項の違いからくるもので，会社間の利害対立が原因となっているものはほとんどなかった．それどころか，検討メンバ
は，より良い仕様を作ろうという気持ちを共有していたものと思う．
以上のような検討過程を経て完成した µITRON4.0 仕様は，色々な視点からの多様な意見が反映された，極めて完成度の高い仕様になっているものと自負している．言い換えると，µITRON4.0 仕様の完成度は，1 人ないしは 1 社による検討では決して成しえなかったものと確信している．
µITRON4.0 仕様書に関して読者に注意を促したい点として，厳密性を重視して
ii

µITRON4.0 仕様

Ver. 4.01.00

仕様書を記述しているために，わかり易さが犠牲になっている面があることを挙げたい．これまでの µITRON 仕様書では，リアルタイム OSに詳しくない技術者が読んでも理解できるように，仕様書の中にチュートリアル的な内容を含めていた．それに対して µITRON4.0 仕様書は，ソフトウェアの移植性を確保する
ために，わかりやすさよりも厳密性を追求して記述している．そのため，これまでの仕様書と比べてわかりにくいという批判は免れないものと考えており，
今後，標準的な参考書（標準ガイドブック）など，仕様書を補足するドキュメ
ントを整備していきたいと考えている．とは言え，不必要にわかりにくい記述があるとすれば，それはひとえに編者の責任である．
ITRON仕様に関する今後の展開として，µITRON4.0 仕様研究会では，デバッギ
ングインタフェースの標準化，デバイスドライバ設計ガイドラインの作成を進めている．また，µITRON4.0 仕様のスタンダードプロファイルに準拠した製品の検定制度創設に向けての検討も，近々開始の予定である．これらの活動により，µITRON 仕様のデファクト標準仕様としての地位をより確かなものとすることを目指している．
最後に，µITRON4.0 仕様の標準化に多大な貢献をいただいた µITRON4.0 仕様研究会 カーネル仕様検討 WGのメンバ各位を始めとして，µITRON4.0 仕様の検討
活動に直接的・間接的にご支援くださった ITRONプロジェクト関係者各位に感謝の意を表する．また，ITRONプロジェクトの標準化活動に対して，引き続きご支援いただくようお願いする次第である．
1999年 6月
高田 広章
µITRON4.0 仕様研究会 幹事／
豊橋技術科学大学 情報工学系

iii

µITRON4.0 仕様

Ver. 4.01.00

仕様書の構成本仕様書は，µITRON4.0仕様（ないしは，µITRON4.0リアルタイムカーネル仕様）の C言語 APIを規定するものである．仕様のバージョン番号は，仕様書の表紙ならびに各ページの右上に表示されている．
本仕様書の構成は次の通りである．
第 1 章では，TRONならびに ITRON プロジェクトの概要と ITRON仕様の設計方
針について紹介した後，µITRON4.0 仕様の位置付けについて解説する．この章の内容は，µITRON4.0 仕様策定の背景について説明するもので，µITRON4.0仕様の本体ではない．
第 2 章は，µITRON4.0 仕様ならびにそれと整合するように標準化されるソフト
ウェア部品仕様に共通する規定を定めるものである．第 3 章では，µITRON4.0
仕様における各種の概念と，複数の機能単位に共通する定義を示す．第 4章では，µITRON4.0 仕様の各機能を，機能単位毎に説明する．第 5 章では，付属的な規定について述べる．
第 6章には，仕様の保守体制や参考文献など，仕様に関連する参考情報を掲載
する．第 7章には，仕様を読む上で参考となる一覧表などを掲載する．ここに掲載する一覧表は，第 2 章〜第 5章の内容を別の観点から整理したものである．
第 6 章および第 7章の内容は，µITRON4.0 仕様の本体ではない．

iv

µITRON4.0 仕様

Ver. 4.01.00

仕様書の記述形式
本仕様書では，次の記述形式を採用している．
【スタンダードプロファイル】
この項では，µITRON4.0 仕様のスタンダードプロファイルにおける規定を示す．具体的には，µITRON4.0 仕様に規定される機能の中でスタンダードプロ
ファイルがサポートすべき機能の範囲，スタンダードプロファイルがサポートすべきサービスコールおよび静的 APIの機能説明中でスタンダードプロファイ
ルには適用されない規定，µITRON4.0仕様では規定されていないがスタンダー
ドプロファイルには適用される規定などについて述べる．
【補足説明】
この項は，µITRON4.0仕様の本体だけではわかりにくい点や誤解するおそれのある点について説明を補足するもので，µITRON4.0仕様の本体ではない．
【µITRON3.0仕様との相違】
この項では，µITRON3.0 仕様との主な相違と，変更の理由について説明する．
µITRON3.0仕様と異なる規定がされている点を中心に説明し，µITRON4.0仕様
で追加された点や規定が明確になった点については網羅していない．この項の内容は，µITRON4.0仕様の本体ではない．
【仕様決定の理由】
この項では，仕様の決定理由として特に説明を必要とする点について説明する．この項の内容は，µITRON4.0仕様の本体ではない．
また，第 4 章のサービスコールと静的 API の機能説明では，上記に加えて次の記述形式を用いる．
各サービスコールまたは静的 APIの機能説明は，次の形式のヘッダで開始する．

の名称
APIの

API の説明

プロファイル「APIの名称」には，サービスコールまたは静的 API の名称を記述する．
「APIの説明」では，サービスコールまたは静的 API の機能を簡潔に記述する．
「プロファイル」欄に【S】と記されたサービスコールおよび静的 API は，スタンダー
ドプロファイルでサポートしなければならないものである．
【静的 API】
この項では，静的 APIのシステムコンフィギュレーションファイル中での記述
形式を示す．
【C 言語 API】
この項では，サービスコールの C言語からの呼出し形式を示す．
v

µITRON4.0 仕様

Ver. 4.01.00【パラメータ】
この項では，サービスコールおよび静的 APIに渡すパラメータをリストアップ
し，それぞれのパラメータのデータ型と名称，簡単な説明を示す．
【リターンパラメータ】
この項では，サービスコールが返すリターンパラメータをリストアップし，それぞれのリターンパラメータのデータ型と名称，簡単な説明を示す．
【エラーコード】
この項では，サービスコールが返すメインエラーコードをリストアップし，それぞれのメインエラーコードを返す理由を簡単に説明する．ただし，多くのサービスコールが共通の理由で返すメインエラーコードについては，サービス
コール毎には記述しない（2.1.6 節参照）．
【機能】
この項では，サービスコールおよび静的 APIの機能について説明する．
サービスコールや定数などの名称で，イタリック体で記述した文字は，他の文字に置き換えられるものであることを示す．例えば，cre_yyy（ yyyがイタリッ
ク体）は，cre_tsk，cre_sem，cre_flgなどをあらわす．
オブジェクト属性やサービスコールの動作モードなどのパラメータで，いくつかの値を選択して設定する場合には，次のような記述方法を用いる．
［x］
x｜ y
x‖ y

xを指定しても指定しなくてもよいことを示す．
xと yをビット毎に論理和をとって指定することを示す．
xまたは y のいずれか片方を指定できることを示す．

例えば，（（TA_HLNG ‖ TA_ASM）｜［TA_ACT］）は，以下の 4種類のいずれかの指定ができることを示す．
TA_HLNG
TA_ASM（TA_HLNG ｜ TA_ACT）（TA_ASM ｜ TA_ACT）vi

µITRON4.0 仕様

Ver. 4.01.00

目次
監修の言葉 .................................................................................................................... i
まえがき ....................................................................................................................... ii
仕様書の構成 ...............................................................................................................iv
仕様書の記述形式 ........................................................................................................v
目次 ............................................................................................................................. vii
サービスコール索引 .................................................................................................. xi
静的 API索引 ............................................................................................................. xvi

第 1章 µITRON4.0 仕様策定の背景

1

1.1 トロンプロジェクト ......................................................................................1
1.1.1 トロンプロジェクトとは？ ................................................................1
1.1.2 基礎プロジェクト ................................................................................3
1.1.3 応用プロジェクト ................................................................................5
1.2 ITRON 仕様の歴史と現状..............................................................................7
1.2.1 組込みシステムの現状と特徴 ............................................................7
1.2.2 組込みシステム用の RTOS に対する要求 .........................................7
1.2.3 ITRON 仕様の現状 ...............................................................................9
1.3 ITRON 仕様の設計方針................................................................................11
1.4 µITRON4.0 仕様の位置付け ........................................................................13
1.4.1 ITRON プロジェクトの第 2フェーズの標準化活動.......................13
1.4.2 µITRON4.0 仕様の策定の必要性 ......................................................14
1.4.3 スタンダードプロファイルの導入 ..................................................15
1.4.4 より広いスケーラビリティの実現 ..................................................17
1.4.5 µITRON4.0 仕様における新機能 ......................................................18

第 2章 ITRON仕様共通規定

23

2.1 ITRON 仕様共通概念....................................................................................23
2.1.1 用語の意味 ..........................................................................................23
2.1.2 API の構成要素 ...................................................................................24
2.1.3 オブジェクトの ID番号とオブジェクト番号 .................................26
2.1.4 優先度 ..................................................................................................27
2.1.5 機能コード ..........................................................................................28
2.1.6 サービスコールの返値とエラーコード ..........................................28
2.1.7 オブジェクト属性と拡張情報 ..........................................................30
2.1.8 タイムアウトとノンブロッキング ..................................................30
2.1.9 相対時間とシステム時刻 ..................................................................32
2.1.10 システムコンフィギュレーションファイル ..................................32
2.1.11 静的 APIの文法とパラメータ...........................................................36
2.2 API の名称に関する原則 .............................................................................38
2.2.1 ソフトウェア部品識別名 ..................................................................38vii

µITRON4.0 仕様

Ver. 4.01.00

2.2.2 サービスコール..................................................................................39
2.2.3 コールバック......................................................................................39
2.2.4 静的 API...............................................................................................39
2.2.5 パラメータとリターンパラメータ..................................................39
2.2.6 データ型..............................................................................................412.2.7 定数......................................................................................................41
2.2.8 マクロ..................................................................................................422.2.9 ヘッダファイル..................................................................................422.2.10 カーネルとソフトウェア部品の内部識別子..................................43
2.3 ITRON仕様共通定義 ...................................................................................432.3.1 ITRON 仕様共通データ型 .................................................................432.3.2 ITRON 仕様共通定数 .........................................................................45
2.3.3 ITRON 仕様共通マクロ .....................................................................49
2.3.4 ITRON 仕様共通静的 API ..................................................................50

第 3章 µITRON4.0 仕様の概念と共通定義

51

3.1 基本的な用語の意味 ....................................................................................51
3.2 タスク状態とスケジューリング規則 ........................................................52
3.2.1 タスク状態..........................................................................................52
3.2.2 タスクのスケジューリング規則......................................................55
3.3 割込み処理モデル ........................................................................................57
3.3.1 割込みハンドラと割込みサービスルーチン..................................57
3.3.2 割込みの指定方法と割込みサービスルーチンの起動..................59
3.4 例外処理モデル ............................................................................................60
3.4.1 例外処理の枠組み..............................................................................60
3.4.2 CPU 例外ハンドラで行える操作 .....................................................61
3.5 コンテキストとシステム状態 ....................................................................61
3.5.1 処理単位とコンテキスト..................................................................61
3.5.2 タスクコンテキストと非タスクコンテキスト..............................62
3.5.3 処理の優先順位とサービスコールの不可分性..............................63
3.5.4 CPU ロック状態 .................................................................................64
3.5.5 ディスパッチ禁止状態......................................................................66
3.5.6 ディスパッチ保留状態の間のタスク状態......................................68
3.6 非タスクコンテキストからのサービスコール呼出し ............................69
3.6.1 非タスクコンテキストから呼び出せるサービスコール..............69
3.6.2 サービスコールの遅延実行..............................................................71
3.6.3 呼び出せるサービスコールの追加..................................................72
3.7 システム初期化手順 ....................................................................................73
3.8 オブジェクトの登録とその解除 ................................................................74
3.9 処理単位の記述形式 ....................................................................................75
3.10 カーネル構成定数／マクロ ........................................................................76
3.11 カーネル共通定義 ........................................................................................77viii

µITRON4.0 仕様

Ver. 4.01.00

3.11.1 カーネル共通定数 ..............................................................................77
3.11.2 カーネル共通構成定数 ......................................................................78

第 4章 µITRON4.0 仕様の機能

81

タスク管理機能 ............................................................................................81
タスク付属同期機能 ..................................................................................104
タスク例外処理機能 ..................................................................................117
同期・通信機能 ..........................................................................................130
4.4.1 セマフォ ............................................................................................130
4.4.2 イベントフラグ ................................................................................139
4.4.3 データキュー ....................................................................................151
4.4.4 メールボックス ................................................................................163
4.5 拡張同期・通信機能 ..................................................................................174
4.5.1 ミューテックス ................................................................................174
4.5.2 メッセージバッファ ........................................................................185
4.5.3 ランデブ ............................................................................................198
4.6 メモリプール管理機能 ..............................................................................219
4.6.1 固定長メモリプール ........................................................................219
4.6.2 可変長メモリプール ........................................................................229
4.7 時間管理機能 ..............................................................................................240
4.7.1 システム時刻管理 ............................................................................240
4.7.2 周期ハンドラ ....................................................................................245
4.7.3 アラームハンドラ ............................................................................255
4.7.4 オーバランハンドラ ........................................................................263
4.8 システム状態管理機能 ..............................................................................271
4.9 割込み管理機能 ..........................................................................................283
4.10 サービスコール管理機能 ..........................................................................296
4.11 システム構成管理機能 ..............................................................................301
4.1
4.2
4.3
4.4

第 5章 付属規定309

5.1 µITRON4.0 仕様準拠の条件 ......................................................................309
5.1.1 基本的な考え方 ................................................................................309
5.1.2 µITRON4.0 仕様準拠の最低機能 ....................................................310
5.1.3 µITRON4.0 仕様に対する拡張 ........................................................311
5.2 自動車制御用プロファイル ......................................................................312
5.2.1 制約タスク ........................................................................................312
5.2.2 自動車制御用プロファイルに含まれる機能 ................................313
5.3 仕様のバージョン番号 ..............................................................................315
5.4 メーカコード ..............................................................................................316

第 6章 付録

319

6.1 仕様と仕様書の利用条件 ..........................................................................319
6.2 仕様の保守体制と参考情報 ......................................................................320ix

µITRON4.0 仕様

Ver. 4.01.00

6.3 仕様策定の経緯と関係者リスト ..............................................................321
6.4 バージョン履歴 ..........................................................................................324

第 7章 リファレンス

327

7.1 サービスコール一覧 ..................................................................................327
7.2 静的 API 一覧...............................................................................................332
7.3 スタンダードプロファイルの静的 API とサービスコール...................333
7.4 データ型 ......................................................................................................335
7.5 パケット形式 ..............................................................................................338
7.6 定数とマクロ ..............................................................................................345
7.7 構成定数とマクロ ......................................................................................348
7.8 エラーコード一覧 ......................................................................................349
7.9 機能コード一覧 ..........................................................................................350
索引 ............................................................................................................................353x

µITRON4.0 仕様

Ver. 4.01.00

サービスコール索引
この索引は，µITRON4.0 仕様のサービスコールのアルファベット順の索引である．
acp_poracre_alm
acre_cyc
acre_dtq
acre_flg
acre_isr
acre_mbf
acre_mbx
acre_mpf
acre_mpl
acre_mtx
acre_poracre_sem
acre_tsk
act_tsk
cal_por
cal_svc
can_act
can_wup
chg_ixxchg_pri
clr_flg
cre_alm
cre_cyccre_dtq
cre_flg
cre_isr
cre_mbf
cre_mbx
cre_mpf
cre_mplcre_mtx
cre_porcre_sem
cre_tsk
def_exc

ランデブの受付 ..............................................................................208
アラームハンドラの生成（ID 番号自動割付け）.......................257
周期ハンドラの生成（ID 番号自動割付け）...............................248
データキューの生成（ID 番号自動割付け）...............................154
イベントフラグの生成（ID 番号自動割付け）...........................141
割込みサービスルーチンの生成（ID 番号自動割付け）...........288
メッセージバッファの生成（ID 番号自動割付け）...................188
メールボックスの生成（ID 番号自動割付け）...........................166
固定長メモリプールの生成（ID 番号自動割付け）...................221
可変長メモリプールの生成（ID 番号自動割付け）...................231
ミューテックスの生成（ID 番号自動割付け）...........................178
ランデブポートの生成（ID 番号自動割付け）...........................202
セマフォの生成（ID 番号自動割付け）.......................................132
タスクの生成（ID 番号自動割付け）.............................................85
タスクの起動 ....................................................................................89
ランデブの呼出し ..........................................................................205
サービスコールの呼出し ..............................................................300
タスク起動要求のキャンセル ........................................................91
タスク起床要求のキャンセル ......................................................109
割込みマスクの変更 ......................................................................294
タスク優先度の変更 ........................................................................97
イベントフラグのクリア ..............................................................146
アラームハンドラの生成 ..............................................................257
周期ハンドラの生成 ......................................................................248
データキューの生成 ......................................................................154
イベントフラグの生成 ..................................................................141
割込みサービスルーチンの生成 ..................................................288
メッセージバッファの生成 ..........................................................188
メールボックスの生成 ..................................................................166
固定長メモリプールの生成 ..........................................................221
可変長メモリプールの生成 ..........................................................231
ミューテックスの生成 ..................................................................178
ランデブポートの生成 ..................................................................202
セマフォの生成 ..............................................................................132
タスクの生成 ....................................................................................85
CPU 例外ハンドラの定義..............................................................303
xi

µITRON4.0 仕様
def_inh
def_ovr
def_svc
def_texdel_alm
del_cycdel_dtq
del_flg
del_isrdel_mbf
del_mbx
del_mpf
del_mpldel_mtx
del_pordel_sem
del_tsk
dis_dspdis_int
dis_texdly_tsk
ena_dspena_int
ena_texexd_tsk
ext_tsk
frsm_tsk
fsnd_dtq
fwd_por
get_ixx
get_mpf
get_mplget_pri
get_tid
get_timiact_tsk
ifsnd_dtq
iget_tid
iloc_cpu
ipsnd_dtq

Ver. 4.01.00

割込みハンドラの定義..................................................................286
オーバランハンドラの定義..........................................................265
拡張サービスコールの定義..........................................................298
タスク例外処理ルーチンの定義..................................................122
アラームハンドラの削除..............................................................259
周期ハンドラの削除......................................................................251
データキューの削除......................................................................156
イベントフラグの削除..................................................................143
割込みサービスルーチンの削除..................................................290
メッセージバッファの削除..........................................................191
メールボックスの削除..................................................................169
固定長メモリプールの削除..........................................................223
可変長メモリプールの削除..........................................................233
ミューテックスの削除..................................................................180
ランデブポートの削除..................................................................204
セマフォの削除..............................................................................134
タスクの削除....................................................................................88
ディスパッチの禁止......................................................................276
割込みの禁止..................................................................................292
タスク例外処理の禁止..................................................................126
自タスクの遅延..............................................................................116
ディスパッチの許可......................................................................277
割込みの許可..................................................................................293
タスク例外処理の許可..................................................................127
自タスクの終了と削除....................................................................94
自タスクの終了................................................................................93
強制待ち状態からの強制再開......................................................114
データキューへの強制送信..........................................................159
ランデブの回送..............................................................................211
割込みマスクの参照......................................................................295
固定長メモリブロックの獲得......................................................224
可変長メモリブロックの獲得......................................................234
タスク優先度の参照........................................................................99
実行状態のタスク ID の参照 .........................................................273
システム時刻の参照......................................................................243
タスクの起動....................................................................................89
データキューへの強制送信..........................................................159
実行状態のタスク ID の参照 .........................................................273
CPUロック状態への移行 .............................................................274
データキューへの送信（ポーリング）........................................157
xii

µITRON4.0 仕様
iras_tex
irel_wai
irot_rdq
iset_flg
isig_semisig_tim
iunl_cpu
iwup_tsk
loc_cpu
loc_mtx
pacp_porpget_mpf
pget_mpl
ploc_mtx
pol_flg
pol_sem
prcv_dtq
prcv_mbf
prcv_mbx
psnd_dtq
psnd_mbf
ras_texrcv_dtq
rcv_mbf
rcv_mbx
ref_alm
ref_cfg
ref_cyc
ref_dtq
ref_flg
ref_isr
ref_mbf
ref_mbx
ref_mpf
ref_mplref_ovr
ref_porref_rdv
ref_sem
ref_sysVer. 4.01.00

タスク例外処理の要求 ..................................................................124
待ち状態の強制解除 ......................................................................110
タスクの優先順位の回転 ..............................................................272
イベントフラグのセット ..............................................................144
セマフォ資源の返却 ......................................................................135
タイムティックの供給 ..................................................................244
CPU ロック状態の解除..................................................................275
タスクの起床 ..................................................................................107
CPU ロック状態への移行..............................................................274
ミューテックスのロック ..............................................................181
ランデブの受付（ポーリング）....................................................208
固定長メモリブロックの獲得（ポーリング）............................224
可変長メモリブロックの獲得（ポーリング）............................234
ミューテックスのロック（ポーリング）....................................181
イベントフラグ待ち（ポーリング）............................................147
セマフォ資源の獲得（ポーリング）............................................136
データキューからの受信（ポーリング）....................................160
メッセージバッファからの受信（ポーリング）........................194
メールボックスからの受信（ポーリング）................................171
データキューへの送信（ポーリング）........................................157
メッセージバッファへの送信（ポーリング）............................192
タスク例外処理の要求 ..................................................................124
データキューからの受信 ..............................................................160
メッセージバッファからの受信 ..................................................194
メールボックスからの受信 ..........................................................171
アラームハンドラの状態参照 ......................................................262
コンフィギュレーション情報の参照 ..........................................305
周期ハンドラの状態参照 ..............................................................254
データキューの状態参照 ..............................................................162
イベントフラグの状態参照 ..........................................................150
割込みサービスルーチンの状態参照 ..........................................291
メッセージバッファの状態参照 ..................................................196
メールボックスの状態参照 ..........................................................173
固定長メモリプールの状態参照 ..................................................227
可変長メモリプールの状態参照 ..................................................238
オーバランハンドラの状態参照 ..................................................269
ランデブポートの状態参照 ..........................................................217
ランデブの状態参照 ......................................................................218
セマフォの状態参照 ......................................................................138
システムの状態参照 ......................................................................282xiii

µITRON4.0 仕様
ref_tex
ref_tsk
ref_tstref_ver
rel_mpf
rel_mplrel_wai
rot_rdq
rpl_rdv
rsm_tsk
set_flg
set_timsig_sem
slp_tsk
snd_dtq
snd_mbf
snd_mbx
sns_ctx
sns_dpnsns_dspsns_loc
sns_texsta_alm
sta_cyc
sta_ovr
sta_tsk
stp_alm
stp_cyc
stp_ovr
sus_tsktacp_portcal_por
ter_tsktget_mpf
tget_mpl
tloc_mtx
trcv_dtq
trcv_mbf
trcv_mbx
tslp_tsk

Ver. 4.01.00

タスク例外処理の状態参照..........................................................129
タスクの状態参照..........................................................................100
タスクの状態参照（簡易版）........................................................103
バージョン情報の参照..................................................................306
固定長メモリブロックの返却......................................................226
可変長メモリブロックの返却......................................................236
待ち状態の強制解除......................................................................110
タスクの優先順位の回転..............................................................272
ランデブの終了..............................................................................215
強制待ち状態からの再開..............................................................114
イベントフラグのセット..............................................................144
システム時刻の設定......................................................................242
セマフォ資源の返却......................................................................135
起床待ち..........................................................................................106
データキューへの送信..................................................................157
メッセージバッファへの送信......................................................192
メールボックスへの送信..............................................................170
コンテキストの参照......................................................................278
ディスパッチ保留状態の参照......................................................281
ディスパッチ禁止状態の参照......................................................280
CPUロック状態の参照 .................................................................279
タスク例外処理禁止状態の参照..................................................128
アラームハンドラの動作開始......................................................260
周期ハンドラの動作開始..............................................................252
オーバランハンドラの動作開始..................................................267
タスクの起動（起動コード指定）..................................................92
アラームハンドラの動作停止......................................................261
周期ハンドラの動作停止..............................................................253
オーバランハンドラの動作停止..................................................268
強制待ち状態への移行..................................................................112
ランデブの受付（タイムアウトあり）........................................208
ランデブの呼出し（タイムアウトあり）....................................205
タスクの強制終了............................................................................95
固定長メモリブロックの獲得（タイムアウトあり）................224
可変長メモリブロックの獲得（タイムアウトあり）................234
ミューテックスのロック（タイムアウトあり）........................181
データキューからの受信（タイムアウトあり）........................160
メッセージバッファからの受信（タイムアウトあり）............194
メールボックスからの受信（タイムアウトあり）....................171
起床待ち（タイムアウトあり）....................................................106xiv

µITRON4.0 仕様
tsnd_dtq
tsnd_mbf
twai_flg
twai_sem
unl_cpu
unl_mtx
wai_flg
wai_sem
wup_tskVer. 4.01.00

データキューへの送信（タイムアウトあり）............................157
メッセージバッファへの送信（タイムアウトあり）................192
イベントフラグ待ち（タイムアウトあり）................................147
セマフォ資源の獲得（タイムアウトあり）................................136
CPU ロック状態の解除..................................................................275
ミューテックスのロック解除 ......................................................183
イベントフラグ待ち ......................................................................147
セマフォ資源の獲得 ......................................................................136
タスクの起床 ..................................................................................107xv

µITRON4.0 仕様

Ver. 4.01.00

静的 API索引
この索引は，µITRON4.0 仕様の静的 API のアルファベット順の索引である．
ATT_INI
ATT_ISR
CRE_ALM
CRE_CYC
CRE_DTQ
CRE_FLG
CRE_MBF
CRE_MBX
CRE_MPF
CRE_MPL
CRE_MTX
CRE_POR
CRE_SEM
CRE_TSKDEF_EXCDEF_INH
DEF_OVR
DEF_SVC
DEF_TEXINCLUDE

初期化ルーチンの追加..................................................................308
割込みサービスルーチンの追加..................................................288
アラームハンドラの生成..............................................................257
周期ハンドラの生成......................................................................248
データキューの生成......................................................................154
イベントフラグの生成..................................................................141
メッセージバッファの生成..........................................................188
メールボックスの生成..................................................................166
固定長メモリプールの生成..........................................................221
可変長メモリプールの生成..........................................................231
ミューテックスの生成..................................................................178
ランデブポートの生成..................................................................202
セマフォの生成..............................................................................132
タスクの生成....................................................................................85
CPU例外ハンドラの定義 .............................................................303
割込みハンドラの定義..................................................................286
オーバランハンドラの定義..........................................................265
拡張サービスコールの定義..........................................................298
タスク例外処理ルーチンの定義..................................................122
ファイルのインクルード................................................................50xvi

µITRON4.0 仕様

Ver. 4.01.00

第 1 章 µITRON4.0 仕様策定の背景
1.1 トロンプロジェクト
1.1.1 トロンプロジェクトとは？
トロン（TRON: The Real-time Operating system Nucleus）は，理想的なコンピュー
タアーキテクチャの構築を目的として，1984年に東京大学の坂村健博士によって開始されたプロジェクトである．産業界と大学の協力のもとで，まったく新しいコンピュータの体系の実現を目指している．
トロンプロジェクトでは，コンピュータ体系の再構築にあたって，近い将来に高度にコンピュータ化された社会―電脳社会―が来ることを想定している．電脳社会においては，我々の日常生活を取り巻くあらゆる機器，設備，道具にマイクロコンピュータが内蔵される．さらに，それらがコンピュータネットワー
クにより相互に接続されて協調動作することにより，人間の活動を多様な側面から支援する．コンピュータが内蔵されネットワークに接続された機器をインテリジェントオブジェクト，それらが接続され協調動作するシステム全体を超機能分散システム（HFDS；Highly Functionally Distributed System）と呼ぶ．HFDSの実現は，トロンプロジェクトの最も重要なゴールである．
現在，トロンプロジェクトは，基礎サブプロジェクトと，応用サブプロジェク
トに分かれて進行している．基礎サブプロジェクトでは，HFDS の構成要素となるコンピュータシステムについて研究を行っている．具体的には，ITRON（組込みシステム用のリアルタイム OS仕様とその関連仕様），BTRON（パソコンやワークステーション用の OS 仕様とその関連仕様），CTRON（通信制御や情報処理を目的とした OSインタフェース仕様），トロン電子機器 HMI（各種の電子機器のヒューマンマシンインタフェースの標準ガイドライン）の各サブプ
ロジェクトが進行している．
応用サブプロジェクトでは，HFDS 内での現実の応用システム実現のための問
題点を取り上げ，細かく分析し解決してゆく．未来のコンピュータ化された社
会をミニモデル的にシミュレートし，基礎サブプロジェクトで開発されたアーキテクチャの成果を評価する．応用プロジェクトは問題解決に基礎プロジェク
トの成果を利用し，基礎プロジェクトは応用からの貴重なフィードバックを研究に役立てるという構造になっている．
21世紀に向けて
トロンプロジェクトは，21世紀の技術レベルに基づいた理想的なコンピュータ
アーキテクチャを目指している．この理想の実現にあたり，高度な VLSI 技術
を前提として，リアルタイム処理やコストパフォーマンスを重視し，究極のフォン・ノイマン型アーキテクチャの実現を目指している．家電や産業用ロ

1

µITRON4.0 仕様

Ver. 4.01.00

ボット，パソコン，ワークステーション，大型コンピュータ，電話交換装置などといった広い分野にわたるアプリケーションに統一的な最新の設計思想が適用されることになる．
オープンアーキテクチャ
基本的な方針として，トロンプロジェクトの成果は，公開された仕様という形
で一般に入手できるようになっている．この仕様をもとに誰でも自由に製品を開発し市場に参入できる．この方針は HFDSの実現を目指すという立場からして当然であり重要なことである．トロン協会はトロン仕様に関して仕様作成や仕様適合性の検証を行う中核となる機関として設立された．トロンプロジェク
トの趣旨に賛同し，協会の規則に従うならば，誰でもトロン協会の会員になることができる．
弱い標準化
トロン仕様はコンピュータインタフェースを規定するが，基盤となるハード
ウェアやソフトウェアに関してはまったく規定せず，OS 自身ではなく OSイン
タフェースを規定している．プログラムやデータの互換性を実現することで，開発コストを軽減し，ユーザやアプリケーションプログラマの教育的効果を向上させることを狙っている．そういった意味で設計のコンセプトのみを規定するという弱い標準化が方針として採用されており，標準化された設計コンセプ
トに従い実装者が実際のシステムを自由に実現することができる．弱い標準化は，発展し続ける最新の技術を採り入れることと，それと相反する HFDS内の構成要素間の互換性を達成することとの折衷案としての意味合いも持つものである．
インタフェースは，マイクロプロセッサの命令セット，OS 核（カーネル），OS
外核，データ規約，オブジェクト間通信インタフェース，プログラマブルイン
タフェース，ヒューマンマシンインタフェース（HMI；Human Machine Interface）という形で階層的に定義されている．仕様が階層的なので，多くの会社がそれぞれの階層を互いに独立して開発・実装することができる．1 つのシステムでも，異なる階層を別々の会社で開発できることはもちろん，同じ階層も各社の自由競争の下で実現することができる．
将来の互換性
トロンプロジェクトでは，将来の上位互換性を実現するために，過去の互換性にひきずられることのないようにしている．既存の多くのコンピュータシステ
ムは，初期のアーキテクチャを拡張することで実現されてきた．いわば何度も改築が繰り返されて大きくなった家のようなものである．一方トロンは未来の
VLSI 技術を基盤とするまったく新しいアーキテクチャである．トロンでは各種アプリケーション間でのデータ互換性を実現するため，トロンアプリケー
ションデータバス（TAD；TRON Application Databus）という標準データフォー

2

µITRON4.0 仕様

Ver. 4.01.00

マットが規定されている．TAD フォーマットにより，既存の OS がトロンと共存する道も提供されている．
操作の標準性
トロンプロジェクトのもう 1つの目的は，ちょうど現在の自動車が基本的にはメーカやモデルによらず運転できるように，誰でも使えるコンピュータを実現することである．ハードウェアやアプリケーションが改良や変更されても使い方を学ぶために余分な労力をかけることのないよう，特にパソコンには車と似たような HMIの標準化が大切なのである．

1.1.2 基礎プロジェクト
ITRON（Industrial TRON）と JTRON
ITRON は機器組込み制御システム用のリアルタイム OS（RTOS；Real-TimeOperating System）のアーキテクチャである．ITRON 仕様の詳細については，次節以降で述べる．
JTRON 仕様は，すでに 10 年以上の実績をもつ ITRON 仕様の RTOS と，移植性やネットワーク透過性に優れた Java の実行環境とを融合した仕様である．
JTRON 仕様を使った応用システムでは，
ITRON仕様と Javaの両方の長所を活かした開発が容易に行える．具体的には，時間的制約の厳しいリアルタイム制御
プログラムは ITRON仕様の機能を使って記述し，GUIやネットワーク関連機能
は Java で記述する．これにより，ITRON仕様と Javaを融合させたネットワーク
対応のリアルタイムシステムが構築できるほか，性能面でのチューニングが必
要な部分を ITRON仕様の RTOS側でネイティブコードを使って記述し，移植性を重視する部分を Java 言語で記述してパーソナルコンピュータやワークス
テーションを利用した開発・デバッグを行うこともできる．
JTRON 仕様には， 1997 年に仕様が公開され，すでに商品化まで行われている
JTRON1.0 仕様と，ITRON仕様の RTOSと Java実行環境の間の連携機能を強化した JTRON2.0 仕様がある．
BTRON（ Business TRON）
BTRON は人間と計算機がスムーズに情報伝達できるようなパソコンやワーク
ステーションのアーキテクチャである．統一的なヒューマンマシンインタ
フェース（HMI），そしてデータ移植性を目的とするトロンアプリケーション
データバス（TAD）を用いてデータ互換性が保証されることが重要視されている．
BTRON HMI の主たる特徴は，キーボードと電子ペンを入力デバイスとするグ
ラフィカルユーザインタフェース（GUI）である．タッチパネルを電子ペンの代わりに入力デバイスとすることができ，ペンだけを使用する HMIガイドラインも現在作成中である．
3

µITRON4.0 仕様

Ver. 4.01.00

TAD はトロンアーキテクチャに従って設計されたコンピュータ間でのデータの互換性を実現する．従来の文書や絵のデータはもちろん，音声や画像などのリアルタイムデータやいろいろな環境情報なども扱える汎用的データ互換
フォーマットである．
これまで述べてきた目的を満たす仕様として BTRON1，BTRON2，BTRON3，µBTRON の仕様が公開されている．BTRON1は限定されたハードウェアリソー
スの上での実装を想定して設計されている．一方 BTRON2，BTRON3は強力なコンピュータシステムのハードウェアリソースをフルに活用できるように設計されている．µBTRON 仕様は，携帯情報機器（PDA）のための BTRON 仕様
であり，パワーマネジメント機能の実装などを考慮している．
ノートブック型のパソコン上で動作する BTRON1仕様 OS は 1991年に発売された．トロン仕様キーボードも BTRON 仕様コンピュータ用に開発されている．
これまでのものより簡単に使えて，疲れも少ないように設計されている．電子
デジタイズペンがポインティンデバイスとして使われているが，マウスなどより，手書き文字入力や図形の描画に適している．トロン仕様キーボードは 1991
年に発売された．
現在は，BTRON のための新しいウィンドウシステムアーキテクチャ，BTRON
でのグラフィカルアプリケーション群のバッチ処理を実現する TACL（TRON
Application Control flow Language），マルチメディア TAD仕様，多国語や多漢字に対応した文字コード体系であるTRONコードの整備などを中心に研究している．
CTRON（Communication and Central TRON）
CTRON は情報通信ネットワークの交換処理，通信処理，情報処理の各ノードに共通に適用できるオペレーティングシステムインタフェースである．情報化
社会の幕開けといわれた 80 年代から，CTRON は情報通信ネットワークの核となるべく，CTRON インタフェース仕様の検討，ソフトウェアポータビリティ
評価実験，リアルタイム性の評価実験などが行われてきた．
CTRON インタフェース仕様は 1988 年に第 1 版が公開され，その後仕様変更の集積，仕様のスリム化などにより全面改訂を行い，1993年に「新版原典 CTRON大系」として出版された．1989 年には CTRON仕様の OS 検定が開始され，現在までに 20 を超える製品が合格している．
1990 年から 1992年にかけて，CTRONインタフェース仕様に準拠した製品の流通性を実験によって定量的に把握するために，ソフトウェアポータビリティ評
価実験が行われた．この実験によりソフトウェア流通性の高いことが検証され，さらにソフトウェア流通にかかわる課題を抽出し，CTRON 仕様書へ反映された．
このように CTRONは 90年代の高度情報通信ネットワークでの基本的なソフト
ウェアプラットホームとしてほぼ確立された．今後は 21世紀に向けて，マルチ
メディア時代の通信ネットワークの核となるべく検討されつつある．
4µITRON4.0 仕様

Ver. 4.01.00

トロン電子機器 HMI
HFDS は人間の生活を支えるために多くのインテリジェントオブジェクトが協調動作することで達成される．すべての HFDS 環境にわたり一貫性のとれた
HMIがトロンプロジェクトで必要となってくる．このサブプロジェクトは，パ
ソコン，電子機器，自動車などを含めたあらゆるインテリジェントオブジェク
トのための HMIガイドラインの作成を目的としている．
TRON HMI ガイドラインはさまざまなユーザやアプリケーションに応用可能なボタン，スイッチ，ハンドルなどのいくつかの物理的なインタラクション
パーツについて規定している．多様なユーザに適応する例として，イネーブル
ウェア仕様と多国語仕様がある．前者は，いろいろなハンディキャップを持つ障害者のための HMI，後者はあらゆる人に自分の母国語でコンピュータを操作することを可能にするためのものである．このガイドラインに沿って作成された HMIの下では，ユーザは互換性の違いなどにより戸惑うことはなくシステム間の移行をスムーズに行うことができる．
プロジェクトの成果は，トロン電脳生活ヒューマンインタフェース仕様として公開されている．1992年と 1993 年の 2回，この仕様に従った HMIデザインコン
ペティションが開催され，仕様の有効性の評価が行われた．

1.1.3 応用プロジェクト
応用プロジェクトとしては，これまでに，トロン電脳住宅，トロン電脳ビル，
トロン電脳自動車網など多くのプロジェクトで仕様検討，実験などが行われ，基礎プロジェクトへのフィードバックが行われてきた．以下では最も新しい 4つの応用プロジェクトを紹介する．
電脳強化環境あらゆる機器や設備にコンピュータを埋め込み，それらをネットワーク接続することで現実環境を機能強化しようという試みは電脳強化環境（ Computer
Augmented Environments，Ubiquitous Computing と呼ばれる場合もある）と呼ばれ，世界的にも近年盛んに研究が行われているが，これはトロンプロジェクトがすでに開発当初から HFDSと呼んでその構築を最終的な目標としてきたものである．そのための基盤ソフトウェアは，トロンプロジェクトにおいて過去約
10 年間にわたって研究・開発してきた技術の延長線上にある．
電脳強化環境実現のために，パソコンやサーバからの指示によって組込機器を制御するための言語処理系である電脳強化環境制御スクリプトを開発している．
マルチメディアネットワークサービスプラットフォーム（MNP）
インターネットやイントラネットの急速な普及に伴い，ネットワーク型のマル
チメディアサービスが本格的に展開されようとしている．
5

µITRON4.0 仕様

Ver. 4.01.00

マルチメディアネットワークサービスに対応するために，CTRON が狙いとしてきた基幹ネットワーク設備およびその周辺（ゲートウェイ機能ノードやルータ，サービスサーバ，マルチメディア端末など）での柔軟なネットワーク資源の利用とリアルタイム制御機能の実現を狙いとして，CTRON に追加すべき新たな OS インタフェース規定，上記の狙いに対応した制御機能に対する技術的な課題，さらにそれらの実現性に関する検討を，1994 年から進めている．
デジタルミュージアム
デジタルミュージアムとは，その活動のあらゆる面でデジタル技術をフルに活用した将来のミュージアムをいい，収蔵物の格納や展示，演出などをデジタル技術が強力にサポートする．つまり，デジタルミュージアムとは，単にイン
ターネット上の World Wide Web（WWW）システムを使った，仮想的な展覧会
だけではない．WWW上の仮想的な展覧会はデジタルミュージアムの一部に過ぎない．デジタルミュージアムのコンセプトでは，ミュージアムのリアルス
ペースを，コンピュータやインターネットに代表されるサイバースペースによって拡張・強化することによって，リアルミュージアムの様々な限界を解消
し，更にリアルミュージアムの魅力を増大させようとしている．
デジタルミュージアムは，トロンプロジェクトが目標として掲げてきた HFDSの一つの応用例と考えることができる．ミュージアムのありとあらゆるところにコンピュータを埋め込み，展示物を演出し展示空間を強化する．また，デジタルミュージアムを構築していく上で現れたコンピュータへの要素技術への要求の多くが，実は BTRON が目指していた技術と共通することもわかった．
これは，BTRON の技術の汎用性を示していると同時に，BTRONサブプロジェ
クトが行ってきたハイパーメディアの技術開発の方向性が正しかったことを間接的に示しているものと考えている．
情報家電のための分散ソフトウェアプラットフォーム
最近では，家電のデジタル化と，それに伴うネットワーク化・高機能化が急速に進んでおり，情報家電の制御ソフトウェアも複雑化の一途をたどっている．
この一方で，機器の開発期間の短縮が求められており，ソフトウェア開発を効率化するソフトウェアプラットフォームに対する要求は極めて高い．
こうした要求に対して，すでに組込みシステム用の RTOS 仕様として業界標準となっている µITRON 仕様の RTOS 上で，情報家電をネットワーク接続するためのミドルウェア群を実際に構築している．これにより，組込み機器の操作性や組込み機器相互間の接続性の確保と，ソフトウェア開発の効率化を目指すた
めの土台を提供する．

6

µITRON4.0 仕様

Ver. 4.01.00

1.2 ITRON仕様の歴史と現状
1.2.1 組込みシステムの現状と特徴
マイクロプロセッサ技術の発展により，機器組込み制御システム（組込みシステム）の応用分野は拡大の一途をたどっている．当初は，工場の生産ラインの制御など産業用途が中心であったものが，通信機器やオフィス機器などの業務機器分野，さらに近年は，自動車やオーディオ／ビデオ機器，テレビ，携帯電話，電子楽器やゲームマシン，洗濯機，エアコン，照明器具などの民生機器分野に急激に拡大し，今では身の回りのほとんどの電気／電子機器に組込みシステムが応用されるようになっている．
それと並行して，制御対象となる機器の高機能化や複合化に伴って，組込みシ
ステムの大規模化・複雑化も著しい．それに加えて，最近顕著になってきた機
器のデジタル化の流れも，マイクロプロセッサの高性能化によりソフトウェア
で実現可能な処理が増えていることとあいまって，組込みシステムの重要性を増す結果となっている．
一般に，民生機器に代表される小規模な組込みシステムには，産業機器に代表される規模の大きい組込みシステムと比較して，機器の製造個数が極めて多く，単価が安いという特徴がある．そのため，大規模な組込みシステムでは開発コストを下げることが重視されるのに対して，小規模な組込みシステムでは最終製品の製造コストを下げることが重視される傾向にある．また，特に民生機器分野では，厳しい機器開発競争からシステム開発期間の短縮に対する要求が著しく，また一度販売した機器のソフトウェアを改修することはほとんどないことから，システム開発のライフサイクルが極めて短いことも特徴の 1つとなっている．
小規模な組込みシステムの分野では，プロセッサコアに加えて，ROM，RAM，
汎用 I/O デバイス，用途に応じたデバイスなどを 1 チップ化した MCU（MicroController Unit；1 チップマイコンと呼ばれる場合もある）が広く使われている．
MCU 上のソフトウェアを開発する際には，最終製品のコストダウンの要請から，ハードウェア資源の制約，とりわけメモリ容量の制約が問題になる．また，高いコストパフォーマンスが求められる MCU は，しばしばアプリケーションに最適化して設計されるため，プロセッサコアの種類が極めて多いことも特筆すべき点である．
このような小規模な組込みシステムの分野においても，ソフトウェアの大規模化・複雑化や開発期間短縮に対する要求から，ソフトウェアの生産性の向上は重要な課題となっており，C 言語などの高級言語を使うケースや，µITRON 仕様などの RTOS を用いるケースが一般的になりつつある．

1.2.2 組込みシステム用の RTOSに対する要求
マイクロプロセッサの高性能化が進む一方で，民生機器など大量生産される機7

µITRON4.0 仕様

Ver. 4.01.00

器への応用が広がっていることから，組込みシステムのコストパフォーマンス
向上に対する要請は以前と同様極めて強いものがある．また，組込みシステムの応用分野の拡大に伴って，RTOS を扱うべきソフトウェア技術者も増加して
おり，システム設計者やプログラマの教育の重要性も高い．
このことを裏付けるデータとして，
トロン協会が 1996年より毎年実施している
アンケート調査においても，組込みシステム用の RTOS の問題点として，「使いこなせる技術者が不足またはいない」「OSにより仕様の違いが大きく切替えの負担が大きい」という教育上や標準化の問題を挙げた回答者が最も多く，「OSのサイズや使用リソースが大きすぎる」「性能・機能が要求条件に適合しない」という適合性に関する問題を挙げた回答者がそれに次いで多くを占めるという結果が例年得られている．
このような背景から ITRONプロジェクトでは，概念や用語の統一といった教育面を特に重視して，広い範囲の組込みシステムに共通に適用できる RTOS 仕様の標準化が必要であると考え，プロジェクトに取り組んできた．
組込みシステム用の RTOS 仕様の標準化にあたって最も困難な問題として，
ハードウェアの持つ性能を最大限に発揮させるという要求と，ソフトウェアの生産性を向上させるという要求のトレードオフの解決が挙げられる．ハード
ウェア資源の制約が厳しい MCU ベースのシステムにおいては，与えられた
ハードウェアの性能を最大限に発揮できることが，RTOS を採用する前提条件となる．一方で，ソフトウェア生産性の向上は RTOS を用いる最大の動機であるが，ソフトウェアの生産性を向上させるために OS が提供するサービスの抽象度を上げたり，用いるハードウェアによらずにソースコードレベルの完全な移植性を確保しようとすると，OS が提供するサービスとハードウェアアーキ
テクチャとのギャップが実行時のオーバヘッドにつながり，ハードウェアの持つ性能を最大限に発揮させることが難しくなる．
この 2 つの要求の最適なトレードオフは，組込み機器の性質に大きく依存する．
具体的には，小規模なシステムにおいては，最終製品のコストダウンの要求から，実行時性能を低下させてまでソフトウェアの移植性を向上させる意義は少ない．それに対して，既存のソフトウェア部品を用いる場合や，ソフトウェアの再利用が不可欠な規模の大きいシステムにおいては，ソフトウェアの移植性は極めて重要な要求となる．さらに，2 つの要求の最適なトレードオフは，マイクロプロセッサ技術の発展によって常に変化している．
また，小規模なシステムと大規模なシステムでは，RTOS に求める機能にも大きな違いがある．小規模な組込みシステムに，必要性の低い高度な機能を持った OS を用いると，プログラムサイズが大きくなり，実行時性能も低下する結果となる．逆に大規模なシステムでは，高度な機能を持った OS を用いてソフ
トウェアの生産性向上を図るべきである．
以上より，組込みシステムの規模や性質に応じて，RTOS に対する要求は大きく異なることがわかる．システムの規模や性質毎に別々の RTOS 仕様を定義することも可能ではあるが，ソフトウェア技術者の教育面やソフトウェア部品の8

µITRON4.0 仕様

Ver. 4.01.00

流通性，開発支援ツールのサポート面を考えると，多種多様な組込みシステムに共通に適用できるスケーラビリティを持った RTOS仕様を定義することが望ましい．
組込みシステム用の RTOS仕様に対する以上の要求を簡単に整理すると，次のようになる．
• ハードウェアの持つ性能を最大限に発揮できること• ソフトウェアの生産性向上に役立つこと• 各規模のシステムに適用できるスケーラビリティを持つこと
以上で述べた技術的な要求事項に加えて，仕様が真の意味でオープンであることも重要な要件となる．組込みシステムが身の回りのあらゆる電気／電子機器に適用されることを考えると，仕様書が誰にでも入手可能な形で一般に公開されるだけでなく，それに基づいた製品を誰もが自由にロイヤリティなしで実装・販売できることも満たさなくてはならない要件である．

1.2.3 ITRON仕様の現状
ITRONプロジェクトは，
1984年に開始して以来，組込みシステム用の標準 RTOS
仕様について検討を行い，その結果として，一連の ITRONリアルタイムカーネ
ル仕様を策定・公開してきた．カーネル仕様に重点を置いて標準化を行ってきたのは，小規模な組込みシステムでは，カーネルの機能のみが利用されるケースが多いためである．
最初の ITRON仕様は，1987 年に ITRON1仕様という形でまとめられた．ITRON1仕様に従っていくつかのリアルタイムカーネルが開発・応用され，仕様の適用性の検証に重要な役割を果たした．その後，小規模な 8 〜 16 ビットの MCU に適用するために機能を絞り込んだ µITRON 仕様（Ver. 2.0），逆に大規模な 32ビットのプロセッサに適用するための ITRON2仕様の検討を進め，共に 1989年に仕様を公開した．この内 µITRON 仕様は，極めて限られた計算能力とメモリ容量しか持たない MCU 上でも実用的な性能を発揮することができたために，多くの種類の MCU 用に実装され，極めて多くの組込みシステムに応用された．実際，組込みシステム向けの主要な MCU のほとんどすべてに，µITRON 仕様のカーネルが開発されているといっても過言ではない．
このように，µITRON 仕様が広範な分野に応用されるにしたがって，それぞれの機能の必要性や性能に対する要求がより正確にわかってきた．また，MCUの適用分野が広がるに従って，µITRON 仕様カーネルを 32 ビット MCU 用に実装するという仕様設計時に想定していなかった適用例も出てきた．そこで，そ8 ビットから 32ビットまでの各規模の MCU
れまでの ITRON 仕様を再度見直し，に適用できるスケーラビリティを持った仕様を策定する作業を行った結果，1993 年に µITRON3.0 仕様を公開した．µITRON3.0 仕様には，1つの組込みシス
テムをネットワークで接続された複数のプロセッサで実現する場合に適用するための，接 続機能も含 まれている．µ I T RO N 3 . 0 の 仕様書の英 語版は，

9

µITRON4.0 仕様

Ver. 4.01.00“µITRON3.0: An Open and Portable Real-Time Operating System for Embedded
Systems”という書名で，IEEE CS Pressから出版されている．
ITRON 仕様に準拠したリアルタイムカーネル製品としては，現在トロン協会に登録されているものだけでも，約 35 種類のプロセッサ用に約 50 種類の製品がある．最近では，米国のソフトウェアベンダが ITRON仕様カーネルを開発する例も出てきている．また，µITRON 仕様カーネルは，規模が小さく比較的容易に実装することができるために，ユーザが自社内専用に開発しているケースも多く，製品化されているもの以外にも多くの実装例がある．また，フリーソフ
トウェアとして配付されている µITRON 仕様カーネルも，複数種類ある．
言うまでもなく，このように多くの ITRON仕様カーネルが実装されるのは，広い応用分野と極めて多くの応用事例があるためである．ITRON仕様カーネルが使用されている機器の例を表 1-1 に挙げる．また，先に紹介したトロン協会によるアンケート調査でも，ITRON仕様が特に民生機器の分野において広く使われており，事実上の業界標準仕様となっていることがわかる．また，ITRON仕様カーネルを使っているケースの中で，自社製の ITRON仕様カーネルを使用しているケースが多くあり，ITRON仕様が真にオープンな標準仕様となっている
ことがわかる．
表 1-1. ITRON 仕様カーネルの主な適用分野
AV 機器，家電
テレビ，ビデオ，デジタルカメラ，セットトップボックス，
オーディオ機器，電子レンジ，炊飯器，エアコン，洗濯機
個人用情報機器，娯楽／教育機器
PDA，電子手帳，カーナビ，ゲーム機，電子楽器
パソコン周辺機器，OA 機器
プリンタ，スキャナ，ディスクドライブ，CD-ROM ドライ
ブ，コピー，FAX，ワープロ
通信機器
留守番電話機，ISDN電話機，携帯電話，PHS，ATMスイッチ，放送機器／設備，無線設備，人工衛星
運輸機器，工業制御／ FA機器，その他
自動車，プラント制御，工業用ロボット，エレベータ，自動販売機，医療用機器，業務用データ端末
リアルタイムカーネル仕様以外では，BTRON 仕様のファイルシステムと互換性のあるファイル管理機能を持つ ITRON/FILE 仕様を公開している．
このように，ITRON リアルタイムカーネル仕様は，多くのメーカが規模の異なる様々なプロセッサ用に実装を行い，その多くが製品化され，また広く応用されている．特に µITRON 仕様カーネルは，今までメモリ容量や実行速度の制約
10µITRON4.0 仕様

Ver. 4.01.00

によって RTOS が使用できなかったシングルチップの MCU への適用が進んでおり，µITRON 仕様がこの分野における世界最初の標準リアルタイムカーネル
仕様の地位を築きつつあるということができる．
ITRON プロジェクトでは，このような実績をベースとして，標準化の対象をカーネル仕様からソフトウェア部品や開発環境などの周辺仕様へと広げると同時に，応用分野毎の調査研究・標準化活動を進めている（1.4.1 節参照）
．さらに将来的な方向性としては，トロンプロジェクトのゴールである HFDSの実現へ向けての検討を進めていく計画である．

1.3 ITRON仕様の設計方針
1.2.2 節で述べた要求事項を満たすために，ITRON仕様を設計するにあたって，以下の設計方針を設定している．
• ハードウェアの過度の仮想化を避け，ハードウェアに対する適応化を考慮する．
ハードウェアの持つ性能を最大限に発揮させ，高いリアルタイム性能を得るためには，仕様作成にあたって，ハードウェアを過度に仮想化することは避けなければならない．ハードウェアに対する適応化とは，ハードウェアの持
つ性能や性質に応じて RTOS の仕様や内部の実装方法を変え，システム全体
としての性能向上をはかることをいう．
具体的には，ITRON仕様において，ハードウェアによらず標準化すべき事項と，ハードウェアの持つ性能や性質に応じて最適になるように決定してよい事項を明確に分離した．標準化した項目には，タスクのスケジューリング規則，システムコールの名称と機能，パラメータの名前・順序・意味，エラー
コードの名前と意味などが含まれる．一方，標準化すると実行時性能の低下につながるような部分については無理に標準化せず，標準化・仮想化による性能の低下を避けるように配慮した．具体的には，パラメータのビット数や割込みハンドラの起動方法については，実装毎に決める方針としている．
• アプリケーションに対する適応化を考慮する．
アプリケーションに対する適応化とは，アプリケーションに必要となるカーネルの機能や要求される性能に応じて，カーネルの仕様や内部の実装方法を変更し，システム全体として性能向上をはかるアプローチをいう．組込みシ
ステムの場合，OS のオブジェクトコードはアプリケーション毎に生成するため，アプリケーションに対する適応化が特に有効に働く．
具体的には，カーネルが提供する各種の機能をできる限り独立させ，アプリ
ケーション毎に必要な機能だけを用いることができるように考慮して，仕様の設計を行っている．また，システムコールの単機能化により，必要な機能のみを組み込むことを容易にしている．実際，多くの µITRON 仕様カーネル
は，カーネル自身がライブラリの形で提供されており，アプリケーションプ

11

µITRON4.0 仕様

Ver. 4.01.00

ログラムとリンクするだけでカーネルの必要なモジュールだけが組み込まれる仕組みになっている．
• ソフトウェア技術者の教育を重視する．
小規模な組込みシステムにおいては，あるシステム用に開発されたソフト
ウェアがそのまま次に開発するシステムに使えることはまれであり，ソフト
ウェアの互換性や移植性は，それほど重視されない傾向にある．それよりも，カーネル仕様の標準化によって，ソフトウェア技術者の教育が容易になったり，用語や概念の統一を通じて技術者間の意志疎通がスムーズになることが重要と考えられる．
ITRON 仕様では，ソフトウェア技術者の教育を重視し，標準化を通じて一度覚えた事が広く活用できるよう配慮している．具体的には，仕様における用語の使い方や，システムコールなどの名称の決め方などは，できる限り一貫性を持つよう配慮した．また，教育用のテキストの作成にも力を入れている．
• 仕様のシリーズ化やレベル分けを行う．
多種多様なハードウェアへの適用を可能にするため，仕様のシリーズ化やレベル分けを行う．これまでに作成したリアルタイムカーネル仕様の内，µITRON 仕様（Ver. 2.0）は主に 8〜 16 ビット MCUを用いた小規模なシステム向けに作成したもので，ITRON2 仕様は 32ビットプロセッサ向けの仕様である．またこれらの仕様の中でも，機能毎の必要度に応じたレベル分けを行い，カーネルを実装する際には必要度の高い機能のみを実装すればよいものとしている．µITRON3.0 仕様では，システムコールのレベル分けにより，1つの仕様で小規模なプロセッサから大規模なプロセッサまでをカバーしている．
また，ネットワークで接続された分散システムのための仕様や，マルチプロ
セッサシステムのための仕様も，一連の ITRON 仕様シリーズの中で標準化を検討している．
• 豊富な機能を提供する．
カーネルが提供するプリミティブを少数に限定するのではなく，性質の異なる豊富なプリミティブを提供するというアプローチを取る．アプリケーショ
ンやハードウェアの性質に適合したプリミティブを利用することで，実行時性能やプログラムの書きやすさの向上が期待できる．
これらの設計方針のいくつかに共通するコンセプトとして，「弱い標準化」がある．弱い標準化とは，共通化すると実行時性能の低下につながるような部分については無理に標準化を行わず，ハードウェアやアプリケーションに依存して決めるべき部分として残すアプローチのことをいう．弱い標準化の考え方により，多種多様なハードウェアの上で，その性能を最大限に発揮させることが可能になる（図 1-1）．

12µITRON4.0 仕様

Ver. 4.01.00µITRON仕様で定める機能
タスク管理 セマフォ イベント データ メール その他 . . .
フラグ キュー ボックスプロセッサのアーキテクチャへの適応化
応用分野への適応化

AAAA

AAAA

プロセッサXに適応化したµITRON仕様カーネル
タスク管理 セマフォ

データ メール
その他
キュー ボックス

実装独自機能アプリケーションの要求に応じた適応化

AAAAAAA AAAAAA

アプリケーションAに適応化したµITRON仕様カーネル
タスク
管理

セマフォ

データ
キュー

実装独自
機能

図 1-1. µITRON仕様における適応化

1.4 µITRON4.0 仕様の位置付け
1.4.1 ITRONプロジェクトの第 2 フェーズの標準化活動
先に述べたように，ITRON プロジェクトでは，これまでリアルタイムカーネル
仕様を中心に標準化活動を行ってきたが，組込みシステムの大規模化・複雑化が進行するに伴い，リアルタイムカーネルを取り巻く環境を意識した標準化活動の必要性が高まっている．そこで， 1996 年頃から開始した ITRON プロジェ
クトの第 2フェーズにおいては，標準化の範囲をカーネル仕様の標準化から周辺仕様を含めた標準化，とりわけ組込みシステム向けのソフトウェア部品のための標準化へと広げて活動を進めている．
ソフトウェア部品のための標準化として，具体的には，ソフトウェア部品の開発・流通を促す条件を整えることに加えて，分野毎のソフトウェア部品インタ
フェースの標準化を進めている．
一つめのソフトウェア部品の開発・流通を促す条件を整えるための検討として，さらに次の 2つの課題について検討を行っている．最初の課題は，現在実装されている ITRON仕様カーネルは実装毎の仕様の違いが大きいために，
ソフ
トウェア部品の流通性が十分に確保できないという問題を解決することである．そのためには，弱い標準化の利点を残しつつ，カーネル仕様の標準化レベ
ルを上げることが必要になる．2 つめの課題は，リアルタイム性を持ったソフ
トウェア部品をサポートすることである．ソフトウェア部品の中にはリアルタ
イム性を求められるものが多くあり，ソフトウェア部品のリアルタイム制約を満たしつつアプリケーションと共存させたり，複数のソフトウェア部品の併用

13

µITRON4.0 仕様

Ver. 4.01.00を可能にする枠組みが求められる．
これらの 2 つの課題に関する検討結果は， µITRON4.0 仕様に反映されている．
また，リアルタイムカーネルを用いた組込みシステム設計の標準的な手法を提示するとともに，ハードリアルタイム性を持ったソフトウェア部品をサポートするためのアプリケーション設計ガイドラインの作成を行っている．
分野毎のソフトウェア部品インタフェースの標準化としては，TCP/IPプロトコ
ルスタックの API（Application Program Interface）と，Java実行環境とのインタ
フェースの標準化に取り組んでいる．
最近，組込みシステムの分野においても，TCP/IPプロトコルスタックの重要性が増している．現在 TCP/IP の API として広く使われているソケットインタ
フェースは，組込みシステム（特に小規模なもの）に用いるには，オーバヘッ
ドが大きい，プロトコルスタック内で動的メモリ管理が必要になるといった問題が指摘されている．組込みシステムのための標準的な TCP/IP API である
ITRON TCP/IP API仕様は，ソケットインタフェースの持つこれらの問題を解決
し，コンパクトで効率の良い TCP/IPプロトコルスタックを実現することを可能にするために設計された．ITRON TCP/IP API仕様は，1998 年 5月に公開されている．
Java もまた，最近注目を集めている技術の 1 つである．Java の技術を組込みシステムに適用する現実的な方法として，Java 実行環境を ITRON仕様カーネル上に実現し，アプリケーションシステムの Javaに適した部分は Javaプログラムの形で，ITRON 仕様カーネルの利点を活かせる部分は ITRON のタスクとして実装する方法がある．ここで，Java プログラムと ITRONタスクの間の通信インタ
フェースの標準化が重要な課題となる．JTRON2.0 仕様は，この標準インタ
フェースを定めることを目的に設計されたもので，1998 年 10 月に公開されている．
ソフトウェア部品関連以外では，応用分野を絞り込んでの調査研究・標準化活動として，自動車制御分野における ITRON仕様カーネルに対する要求事項を整理し，標準仕様に対する提案をまとめる活動を行った．そこでの検討結果も，µITRON4.0 仕様に反映されている．
これらの他にも，現在，ITRON 仕様カーネルとデバッグ環境との間のインタ
フェースの標準化や，デバイスドライバ設計ガイドラインの作成などの活動を進めている．さらに，ITRON仕様カーネルの C++言語バインディングの標準化などへの取組みを予定している．

1.4.2 µITRON4.0 仕様の策定の必要性
前節で紹介した第 2フェーズの活動の中で，リアルタイムカーネル仕様を今一度見直す必要性が指摘され，ITRON リアルタイムカーネル仕様としては第 4世
代に位置付けられる µITRON4.0 仕様の策定を行うこととなった．µITRON4.0 仕様の策定が必要な理由は，次の 4 点に集約できる．

14

µITRON4.0 仕様

Ver. 4.01.00(a) ソフトウェアの移植性の向上
近年の組込みソフトウェアの大規模化・複雑化により，アプリケーション
ソフトウェアを異なる ITRON 仕様カーネルへ容易に移植できることが，従来よりも強く求めらるようになってきた．また，ソフトウェア部品の流通を促すためにも，ITRON 仕様カーネル上に構築されるソフトウェアの移植性の向上は，極めて重要な課題となっている．
(b) ソフトウェア部品向けの機能の追加
従来の ITRON 仕様では，外販することを前提にソフトウェア部品を構築す
るには，機能的に不足している部分があった．例えば，ソフトウェア部品のあるサービスルーチンが，どのようなコンテキストから呼び出されたか調べる方法は，拡張レベルでしか用意されていなかった．
(c) 新しい要求・検討成果の反映
ITRONプロジェクトでは，ハードリアルタイムサポート研究会（1996年 11
月〜 1998 年 3 月）においてハードリアルタイムシステムの構築を容易にするためにリアルタイムカーネルが持つべき機能の検討を，RTOS自動車応用技術委員会（ 1997 年 6 月〜 1998年 3 月）において自動車制御応用におけるリ
アルタイムカーネルに対する要求事項の整理を行ってきた．これらの新しい要求や検討成果を，リアルタイムカーネル仕様に反映する必要がある．
(d) 半導体技術の進歩への対応µITRON3.0 仕様を策定してから約 6年が経過しており，その間に半導体技術は大きく進歩し，組込みシステムに用いられるプロセッサの性能向上やメ
モリ容量の増加も著しい．そのため，有用な機能ではあるが，µITRON3.0
仕様の策定時点ではオーバヘッドが大きいために標準化を見送ったが，現在の技術では許容できるオーバヘッドで実現できると考えられるものもある．

1.4.3 スタンダードプロファイルの導入
ソフトウェアの移植性を向上させるためには，実装が備えるべき機能セット
や，それぞれのサービスコールの機能仕様を，厳格に定めることが必要である．言い換えると，仕様の標準化の度合いを強くする必要がある．
一方，µITRON 仕様はこれまで，ソフトウェアの移植性よりも，ハードウェア
やプロセッサへの適応化を可能にし，実行時のオーバヘッドや使用メモリの削減を重視する「弱い標準化」の方針に基づいて標準化を行ってきた．
「弱い標準化」の方針により µITRON 仕様は，8ビットから 64ビットまでの広い範囲のプロセッサに適用可能なスケーラビリティを実現しており，µITRON 仕様が広く受け入れられている重要な理由の一つとなっている．ところが，ソフトウェ
ア移植性の向上とスケーラビリティの実現は本質的に矛盾する面が多く，一つの仕様で両者を同時に実現することは困難である．
そこで µITRON4.0 仕様では，仕様全体としては「弱い標準化」の方針を維持し
15

µITRON4.0 仕様

Ver. 4.01.00

つつ，ソフトウェアの移植性を向上させるために，標準的な機能セットとその仕様を厳格に定めるというアプローチを採用している．この標準的な機能セッ
トを「スタンダードプロファイル」と呼ぶ．標準的な機能セットを定めるにあたっては，µITRON 仕様カーネルの応用分野としては大きめのシステムを想定する．これは一般に，システムの規模が大きいほど，ソフトウェアの移植性が重視されるためである．
スタンダードプロファイルを定義することにより，ソフトウェア部品などの移植性を重視するソフトウェアはスタンダードプロファイルの機能のみを用いて構築することを推奨し，逆にソフトウェアの移植性を重視する分野向けのカーネルはスタンダードプロファイルに準拠して実装することを推奨することになる．
さらに，スタンダードプロファイル内でも，考えられる限り，ソフトウェアの移植性を向上させるとともに，スケーラビリティも実現できるような仕様としている．具体的には，小さいオーバヘッドで実現できる範囲で，割込みハンド
ラの移植性が向上するような仕組みを導入している．例えば従来の µITRON 仕様では，割込みハンドラの中でより優先度の高い割込みハンドラが多重起動されるのを禁止するための，移植性を確保できる方法が用意されていなかったが，µITRON4.0 仕様ではこれを可能にしている．
スケーラビリティの実現に関しては，
従来の µITRON 仕様と同様，
サービスコー
ルの単機能化などの方針により，豊富な機能を用意した上でライブラリリンクの機構で必要のない機能がリンクされないような工夫を行っている．さらに，ライブラリリンクの機構だけでは必要な機能だけをリンクすることが難しい場面では，カーネルではより複雑な機能を実現するのに必要なプリミティブのみを提供するという方針を採っている．これにより，カーネルに改造を加えず複雑な機能を実現することを可能にする一方，複雑な機能を必要としないアプ
リケーションでのオーバヘッドを最小限にすることができる．
スタンダードプロファイルが想定するシステムイメージは，具体的には次のよ
うなものである．
• ハイエンドの 16 ビットないしは 32ビットプロセッサを使用．
• カーネルのプログラムサイズが 10 〜 20KB 程度（すべての機能を使った場
合）．
• システム全体が一つのモジュールにリンクされる．
• カーネルオブジェクトは静的に生成される．
システム全体が一つのモジュールにリンクされることから，サービスコールはサブルーチンコールで呼び出すことになる．また，プロテクションの機構は持たない．
スタンダードプロファイルでサポートすべき機能には，µITRON3.0 仕様のレベル S のすべての機能（一部の機能は仕様を変更または拡張した），一部のレベ
ル Eの機能（タイムアウト付きのサービスコール，固定長メモリプール，周期ハンドラなど；周期ハンドラは仕様を整理した），新たに導入したいくつかの
16

µITRON4.0 仕様

Ver. 4.01.00

機能（タスク例外処理機能，データキュー，システム状態参照機能など）が含まれている．また，後述するオブジェクトの生成情報を記述するための静的
APIもサポートされる．

1.4.4 より広いスケーラビリティの実現
前節で述べた通り，µITRON4.0 仕様全体としては「弱い標準化」の方針を維持し，従来の仕様以上に広範なスケーラビリティの実現を狙っている．
まず，最小の機能セットを，従来の µITRON 仕様よりもさらにコンパクトに実現可能なものとし，従来にも増して小規模なシステムへ適用できるものとしている．具体的には，従来の仕様では必須としていた待ち状態のサポートを必須とせず，それに代えて休止状態のサポートを必須としている．待ち状態を持たないカーネルでは，すべてのタスクを同一のスタック空間を用いて動作させることが可能で，スタックのためのメモリ領域の削減や，タスク切替えオーバ
ヘッドの削減を図ることができる．
逆にスタンダードプロファイルを越える要求に対応するために，豊富な拡張機能を定義しており，µITRON4.0 仕様のフルセットは従来の µITRON 仕様のフルセットよりも豊富な機能を持っている．具体的には，µITRON3.0 仕様の機能の内，接続機能を除くほとんどすべての機能を持つことに加えて，µITRON4.0 仕様に新たに導入した機能として，スタンダードプロファイルに含まれる新機能（タスク例外処理機能，データキュー，システム状態参照機能など），ID番号の自動割付けを行うオブジェクト生成機能，移植性を確保して割込み処理を記述するための割込みサービスルーチンの機能，優先度継承／上限プロトコルをサポートするミューテックス，タスクが与えられたプロセッサ時間を使い切ったことを検出するオーバランハンドラなどが含まれている．µITRON4.0 仕様のフルセットは，ITRON2 仕様のフルセットとの対比においても，それほど遜色のない機能を持っているということができる．
また，スタンダードプロファイルに加えて，自動車制御用プロファイルを定義している．自動車制御用プロファイルは，文字どおり自動車制御応用への適用を狙ったものであるが，スタンダードプロファイルが対象としているよりも小規模なシステムに対して，ソフトウェアの移植性を向上させるための機能セットという位置付けを持っている．具体的には，スタンダードプロファイルと比較して，タイムアウト付きのサービスコール，強制待ち状態，タスク例外処理
機能，メールボックス，固定長メモリプールなどがサポートの必要のない機能となっている．逆に，自動車制御用プロファイル独自の機能として，待ち状態に入ることができないタスク（これを制約タスクと呼ぶ）がある．待ち状態に入らないことから，同じ優先度を持つ制約タスクでスタック領域を共有することが可能となり，メモリ使用量を削減することができる．待ち状態に入るサービスコールを呼んだ時にエラーとなることに依存しない限りは，制約タスクを
通常のタスクに置き換えてもシステムの振舞いは変化せず，その意味では，制約タスクという独自の機能を持つにもかかわらず，自動車制御用プロファイル
17

µITRON4.0 仕様

Ver. 4.01.00

はスタンダードプロファイルに対する下位互換性を有している．
図 1-2 は，µITRON4.0 仕様の機能レベルを，µITRON3.0 仕様との関係で図示したものである．µITRON4.0 仕様は，従来の µITRON 仕様に比べて，より小規模のシステムへも，より大規模なシステムへも適用できるような仕様となっているということができる．

フルセット
レベルE
スタンダードプロファイル
レベルS
自動車制御用プロファイル
レベルRµITRON3.0仕様

最小セットµITRON4.0仕様

図 1-2. µITRON3.0 仕様と µITRON4.0 仕様の機能レベル

1.4.5 µITRON4.0 仕様における新機能
前述したように，µITRON4.0 仕様には従来の µITRON 仕様が持っていなかった
新機能が数多く導入されている．以下では，µITRON4.0 仕様における新機能を簡単に紹介する．
例外処理のための機能µITRON4.0 仕様では，従来の µITRON 仕様では実装依存として定義していなかった例外処理の枠組みを定義している．
プロセッサが何らかの例外条件を検出すると，プロセッサは CPU例外ハンドラを起動する．CPU例外ハンドラは，例外の種類毎にアプリケーションで定義することができる．CPU 例外ハンドラはシステム全体で共通であるため，CPU例
外ハンドラ内で例外が発生したコンテキストや状況を調べ，必要であれば例外が発生したタスクに処理を任せることができる．タスクに処理を任せるために用意したのが，タスク例外処理機能である．
タスク例外処理機能は， UNIX のシグナル機能を簡略化したような機能で，
ITRON2 仕様の強制例外に類似の機能である．タスク例外処理機能の典型的な用途として，次のようなものが挙げられる．
• ゼロ除算などの CPU例外をタスクに伝える．
• 他のタスクに終了要求を出す．
• タスクにデッドラインが来たことを通知する．
18

µITRON4.0 仕様

Ver. 4.01.00µITRON4.0 仕様が例外処理のために定義している機能は，より複雑な例外処理機能を実現する場合にそのプリミティブとして使うことができるよう配慮して設計されている．
データキュー
データキューは，1 ワードのデータをメッセージとして通信するための機構である．µITRON3.0 仕様では，メールボックスを実装するために，リンクリストを使う方法とリングバッファを使う方法のいずれを用いてもよいものとしていた．それに対して µITRON4.0 仕様では，ソフトウェアの移植性を向上させる
ために，メールボックスの実装を線形リストを使う方法に限定すると同時に，
リングバッファを使って実装したメールボックスと同等のデータキューを，別のオブジェクトとして規定することとした．
データキューは，自動車制御応用において強い要求があったことから，当初自動車制御用プロファイル独自の機能として導入する方向で検討したが，データキューが他の応用分野においても有用であること，データキューを使わないア
プリケーションにおいてはそのためのプログラムがリンクされないように実装できることから，スタンダードプロファイルに含めることとなった．
システム状態参照機能
他で開発されるアプリケーションから呼び出されることを前提としてソフト
ウェア部品を構築する場合には，ソフトウェア部品の各サービスルーチンが，どのようなコンテキストから呼ばれても対応できることが求められる．ところが µITRON3.0 仕様では，現在のシステム状態を調べるには，レベル Eの機能である ref_sys を使うしか方法がなかった．ref_sysをサポートしていないカーネ
ル製品も多く，サポートしている場合でも，他の情報も一緒に参照できるためにオーバヘッドが大きくなるという問題があった．
そこで µITRON4.0 仕様には，現在のシステム状態を小さいオーバヘッドで参照する機能として，5つのサービスコール（sns_yyy）を導入した．これらのサービスコールはいかなるコンテキストからも呼び出すことができ，いずれもブール値を返す（エラーを返すことはない）．これらのサービスコールを用いると，
例えば，待ち状態に入るサービスコールを呼べる状態にあるかどうかを，小さいオーバヘッドで調べることができる．
また，これらのサービスコールを用いると，排他制御が必要な処理を行うために，一時的に CPUロック状態（またはディスパッチ禁止状態）にし，処理が終わった後で元の状態に戻すことが容易にできる．これに関連して，µITRON3.0
仕様では，ディスパッチ禁止状態で loc_cpu を呼び出して CPUロック状態にす
ると元の状態に戻す方法がなかったが，µITRON4.0 仕様ではディスパッチ禁止
状態と CPUロック状態を独立な状態とすることで，この問題も解決している．

19

µITRON4.0 仕様

Ver. 4.01.00

ID 番号の自動割付けを行うオブジェクト生成機能µITRON3.0 仕様では，オブジェクトを動的に生成する場合には，生成するオブジェクトの ID 番号をアプリケーションで指定しなければならなかったが，大規模なシステムにおいては，使っていない ID 番号を管理するのが面倒になるという問題があった．そこで µITRON4.0 仕様では，生成するオブジェクトの ID
番号をアプリケーションで指定するのではなく，カーネルが割り付けた ID 番号を用いてオブジェクトを生成するサービスコールを新たに導入した．割り付けられた ID 番号は，サービスコールの返値として，アプリケーションに返される．
割込みサービスルーチン
割込み処理のアーキテクチャは，プロセッサやシステムにより違いが大きく，標準化の難しい部分である．従来の µITRON 仕様では，割込みハンドラの記述
方法はプロセッサやシステムに最適に定めるべき事項と考えて標準化していなかったが，デバイスドライバの移植性を向上させるためには，移植性の高い
割込み処理の記述方法が求められている．
そこで µITRON4.0 仕様では，従来の仕様と同様の割込みハンドラに加えて，移植性を確保して割込み処理を記述するための割込みサービスルーチンの機能を新たに導入した．割込みサービスルーチンは，割込みの発生源となるデバイ
スのみに依存して記述できることを目指して，仕様が設計されている．
ミューテックス
厳しい時間制約を持つリアルタイムシステムを構築する場合には，優先度逆転現象を防ぐための仕組みとして，優先度継承プロトコルや優先度上限プロトコルが必要になる．ミューテックスは，優先度継承プロトコルと優先度上限プロ
トコルをサポートする排他制御のための機構として，µITRON4.0 仕様で新たに導入した機能である．ミューテックスの導入にあたっては，POSIXのリアルタイム拡張におけるミューテックスの機能を参考にした．
オーバランハンドラ
厳しい時間制約を持つリアルタイムシステムを構築する場合に必要となるもう一つの機能として，µITRON4.0 仕様では，タスクが与えられたプロセッサ時
間を使い切ったことを検出するためのオーバランハンドラの機能を導入した．
システムが時間制約を満たしていないことを検出する最も単純な方法は，処理がデッドラインまでに終了しないことを検出する方法である（処理がデッドラインまでに終了しないことの検出は，アラームハンドラなどを使うことで実現できる）．ところがこの方法には，優先度の高いタスクがデッドラインまで実行を続けた場合，優先度の低いタスクは連鎖的にデッドラインを守れなくなるという問題がある．この問題を解決するには，タスクが与えられたプロセッサ
時間を使い切ったことを検出するための機構が必要になる．
20

µITRON4.0 仕様

Ver. 4.01.00

コンフィギュレーション方法の標準化
スタンダードプロファイルでは，タスクやセマフォなどのカーネルオブジェク
トは静的に生成されることを想定している．そのため，スタンダードプロファ
イルに準拠したカーネル上に実現されたアプリケーションソフトウェアを，他のスタンダードプロファイル準拠のカーネル上に移植するためには，アプリ
ケーションプログラムそのものを移植することに加えて，カーネルオブジェク
トの生成情報を新しいカーネルに移行することも必要になる．
従来の µITRON 仕様では，カーネルオブジェクトの生成情報を記述する方法は標準化していなかったため，生成情報の記述方法はカーネル製品毎にかなり異なったものとなっていた．例えば，オブジェクトの生成情報を直接 C言語の構
造体の初期化データの形で記述させる製品もあれば，GUI を持ったコンフィ
ギュレータを備えている製品もある．このような状況では，大規模なアプリ
ケーションを他のカーネルに移植する際に，生成情報の移植工数が無視できな
くなる．ここで，書き直し作業そのものの工数はそれほど大きくなくても，製品毎に異なる記述方法を学習するのにかかる時間も工数に含めて考えるべきであることに注意して欲しい．
そこで µITRON4.0 仕様では，オブジェクトの生成情報の記述方法と，それを基にカーネルやソフトウェア部品をコンフィギュレーションする方法を標準化している．システムコンフィギュレーションファイル中での，オブジェクトの生成情報の記述方法を，静的 API と呼ぶ．静的 APIの名称は，同じ機能を持つ
サービスコールの名称を大文字で記述したものとしており，静的 APIとサービ
スコールでパラメータを一致させている（ただし，パケットへのポインタの代わりに，パケットの各要素の値を “{” と “}”の中に列挙する）．これは，片方を覚えればもう片方も自然に覚えられるという教育的効果を狙ったものである．
また，静的 APIを処理するコンフィギュレータは，ID番号が与えられないオブジェクトに ID 番号を自動的に割り付ける機能を持たなければならない．これにより，別々に開発されたモジュールを組み上げてアプリケーションを構築する場合にも，オブジェクトの ID 番号割付けの管理を省略することができ，大規模なアプリケーション開発においては特に有効な機能である．
µITRON4.0 仕様のコンフィギュレーション方法のもう一つの特徴は，一つのシステムコンフィギュレーションファイル中に，カーネルの静的 API に加えて，
ソフトウェア部品のための静的 APIを混在して記述することを可能にしている点である．システムコンフィギュレーションファイルを，ソフトウェア部品とカーネルのコンフィギュレータに順に処理されることによって，ソフトウェア
部品のコンフィギュレーションによりソフトウェア部品が必要とするカーネ
ルオブジェクトが変わるような複雑な状況にも対応することができる．
以上で紹介した新機能に加えて，µITRON4.0 仕様では，ソフトウェアの移植性を向上させるために，個々のサービスコールの機能の中で µITRON3.0 仕様では実装依存としていた事項や曖昧になっていた事項について，新たに規定するな

21

µITRON4.0 仕様

Ver. 4.01.00

どの方法で実装依存性を削減している．さらに，用語や概念の再整理，パラ
メータのデータ型の再整理，エラーコードの再整理，サービスコールの機能
コードの再割付け，カーネルの構成を取り出すための定数やマクロの標準化，システムの初期化手順の標準化など，µITRON3.0 仕様に対して数々の改善を加
えている．

22

µITRON4.0 仕様

Ver. 4.01.00

第 2 章 ITRON 仕様共通規定
ITRON仕様共通規定は，µITRON4.0 仕様ならびにそれと整合するように標準化されるソフトウェア部品仕様（この規定の中では，これらを ITRON仕様と総称する）に共通する規定を定めるものである．この規定の中で，「カーネル仕様」とは µITRON4.0 仕様を，「スタンダードプロファイル」とは µITRON4.0 仕様のスタンダードプロファイルを指す．
【補足説明】
この章は，ソフトウェア部品仕様にも共通に適用できるように記述している
が，µITRON4.0 仕様の理解を容易にするために，必要に応じて µITRON4.0 仕様とそのスタンダードプロファイルに固有の事項にも言及する．

2.1 ITRON仕様共通概念
2.1.1 用語の意味
ITRON仕様において用いる用語の意味を次の通りに定める．
•「実装定義」とは，ITRON仕様で定める機能仕様の中で，ITRON仕様では標準化せず，実装毎に規定すべき事項であることを示す．実装について説明する製品マニュアルなどで，実装における規定を示さなければならない．アプ
リケーションプログラムの中で，実装定義の事項に依存している部分は，移植性が確保されない．
•「実装依存」とは， ITRON 仕様で定める機能仕様の中で，実装ないしはシス
テムの動作条件によって振舞いが変わる事項であることを示す．アプリケー
ションが実装依存の事項に依存している場合の振舞いは，ITRON仕様上は保証されない．
•「未定義」とは，そのような状況における振舞いに関して何も保証されないことを示す（すなわち，システムダウンを引き起こすかもしれない）．仕様に定めのない事項は，一般的には未定義である．アプリケーションが未定義の状況を作り出した場合の振舞いは， ITRON 仕様上は保証されない．
•「実装独自」とは， ITRON 仕様で定める範囲外の機能仕様を，実装において規定したものであることを示す．
【補足説明】
実装における規定は，規定の内容が実装毎に一通りに固定されている必要はな
く，カーネルやソフトウェア部品の構成により規定の内容が変わってもよい．
構成により規定の内容が変わる場合には，実装について説明する製品マニュア
ルなどで，カーネルやソフトウェア部品の構成方法と，それぞれの構成における規定の内容を示さなければならない．
23

µITRON4.0 仕様

Ver. 4.01.00

2.1.2 APIの構成要素
API（Application Program Interface）とは，アプリケーションプログラムがカー
ネルやソフトウェア部品を使う場合のインタフェースのことをいう．APIは次の要素で構成される．
(A) サービスコール
アプリケーションプログラムからカーネルまたはソフトウェア部品を呼び出すインタフェースをサービスコールと呼ぶ．ITRON 仕様では，サービスコールの名称，機能，パラメータとリターンパラメータの種類・順序・名称・データ型を標準化する．
C 言語 API では，サービスコールは関数呼出しの形で定義されるが，同じ機能を持つならプリプロセッサマクロなどの形で実現してもよい．
【µITRON3.0 仕様との相違】µITRON3.0 仕様ではシステムコールと呼んでいたが，ソフトウェア部品への対応を考慮して，サービスコールと呼ぶことにした．カーネルのサービスコール
をシステムコールと呼んでも良い．
(B) コールバック
ソフトウェア部品からアプリケーションプログラムが登録したルーチンを呼び出すインタフェースをコールバック，呼び出されるルーチンをコールバック
ルーチンと呼ぶ．ITRON 仕様では，コールバックルーチンの名称，機能，パラ
メータとリターンパラメータの種類・順序・名称・データ型を標準化する．
コールバックルーチンが実行されるコンテキストは，それぞれのソフトウェア
部品仕様で規定する．
【補足説明】
カーネル仕様ではコールバックを用いていない．
(C) 静的 API
システムコンフィギュレーションファイル中に記述し，カーネルやソフトウェ
ア部品の構成を決定したり，オブジェクトの初期状態を定義するためのインタ
フェースを，静的 APIと呼ぶ．ITRON 仕様では，静的 APIの名称，機能，パラメータの種類・順序・名称・データ型を標準化する．
オブジェクトを登録するサービスコールなどに対して，それに対応する静的
APIを規定する．サービスコールに対応する静的 APIは，システムコンフィギュ
レーションファイル中に記述された順序で，それぞれに対応するサービスコー
ルをシステム初期化時に実行するのと等価の機能を持つ．また，サービスコー
ルに対応しない静的 API，カーネルやソフトウェア部品で共通に利用する
ITRON 仕様共通静的 API もある．

24

µITRON4.0 仕様

Ver. 4.01.00(D) パラメータとリターンパラメータ
サービスコール・コールバックルーチン・静的 APIに渡すデータをパラメータ，
サービスコールやコールバックルーチンが返すデータをリターンパラメータと呼ぶ．ITRON 仕様では，パラメータとリターンパラメータの名称とデータ型を標準化する．
C 言語 API では，関数の返値以外のリターンパラメータは，リターンパラメー
タを入れる領域へのポインタを C 言語の関数の引数（以下，単に引数と呼ぶ）として渡すか，複数のパラメータまたはリターンパラメータを含む構造体（これをパケットと呼ぶ）に入れて返すことで実現される．この場合，リターンパ
ラメータを入れる領域へのポインタはパラメータとは考えないこととし，パラメータとしてはリストアップしない．それに対して，パケットへのポインタ
は，パラメータとしてリストアップする．
C 言語 API で，リターンパラメータの名称の前に “p_”を付加した名称（ただし，リターンパラメータの名称の先頭が “pk_” の場合は，それを “ppk_”に置き換えた名称）の引数があれば，その引数はリターンパラメータを入れる領域へのポインタをあらわす．また，パラメータのサイズが大きいなどの理由で，パラメータを入れた領域へのポインタを引数として渡す場合も同様である．
サービスコールに対してリターンパラメータ（またはパラメータ）を入れる領域やパケットへのポインタを渡した場合，そのサービスコールの処理が完了した後は，アプリケーションはそれらの領域を別の目的に使うことができるのが原則である．また，コールバックに対してリターンパラメータ（またはパラメータ）を入れる領域やパケットへのポインタを渡した場合，そのコールバッ
クの処理が完了した後は，ソフトウェア部品はそれらの領域を別の目的に使うことができるのが原則である．これらの原則の例外となるケースについては，
サービスコールやコールバックの機能説明でその旨を明示する．
【仕様決定の理由】
関数の引数と返値の名称は，カーネルやソフトウェア部品の APIを直接的に定めるものではないが，仕様書や製品マニュアルなどの中で頻繁に使われることから，ITRON仕様で標準を定める．
(E) データ型
ITRON仕様では，パラメータやリターンパラメータなどのデータ型の名称と意
味を標準化する．データ型によっては，その型定義を ITRON仕様で標準化する場合もある．
ITRON仕様でビット数が規定されていないデータ型に対して，実装で定義されるデータ型のビット数よりも少ない有効ビット数ないしはデータ型で表現できる範囲よりも狭い有効範囲を，実装定義に定めることができる．
(F) 定数ITRON仕様では，パラメータやリターンパラメータなどに用いる定数，サービ
25

µITRON4.0 仕様

Ver. 4.01.00

スコールの機能コードとして用いる定数の名称・意味・値を標準化する．C言語 APIでは，定数はプリプロセッサマクロとして定義する．
(G) マクロカーネルやソフトウェア部品を呼び出さず，システムの状態に依存せずに値の変換などを行うためのインタフェースをマクロと呼ぶ．ITRON 仕様では，マクロの名称と意味を標準化する．C 言語 API では，マクロはプリプロセッサマク
ロとして定義する．
(H) ヘッダファイル
カーネルやソフトウェア部品毎に，サービスコールの宣言と，データ型・定数・マクロの定義などを含むヘッダファイルを一つまたは複数用意する．
ITRON 仕様では，ヘッダファイルの名称を標準化する．また，複数のヘッダ
ファイルを用意する場合には，どのヘッダファイルにどの宣言および定義が含まれるかを標準化する．
また，ITRON仕様共通定義で規定されるデータ型，定数，マクロの定義などを含むヘッダファイルを用意し，カーネルならびにソフトウェア部品毎に用意するヘッダファイルからインクルードする．
オブジェクトの ID 番号などの自動割付けを行うコンフィギュレータは，自動割付けを行った結果を，自動割付け結果ヘッダファイルに生成する．ITRON仕様では，自動割付け結果ヘッダファイルの名称を標準化する．
ITRON 仕様で標準化されたヘッダファイルを，複数のファイルに分割して実装してもよい．また，同じヘッダファイルを複数回インクルードしてもエラーとならないようにしなければならない．
【補足説明】
同じヘッダファイルを複数回インクルードしてもエラーとならないようにするためには，ヘッダファイルの先頭で特定の識別子（ここでは “_KERNEL_H_”とする）をプリプロセッサマクロとして定義（“#define _KERNEL_H_”）し，ヘッダファイル全体を “#ifndef _KERNEL_H_” と “#endif”で囲めばよい．

2.1.3 オブジェクトの ID番号とオブジェクト番号
カーネルやソフトウェア部品が操作対象とする資源を，オブジェクトと総称する．オブジェクトは，その種類毎に，番号によって識別する．オブジェクトを識別する番号がカーネルやソフトウェア部品の APIに閉じており，アプリケー
ションが自由に番号を割り付けることができる場合に，その識別のための番号を ID 番号と呼ぶ．それに対して，カーネルやソフトウェア部品の内部や外部からの条件によってオブジェクトを識別する番号が定まる場合に，それをオブ
ジェクト番号と呼ぶ．
ID番号で識別されるオブジェクトは，アプリケーションによって生成すること
で，カーネルやソフトウェア部品に登録される．それに対して，オブジェクト
26

µITRON4.0 仕様

Ver. 4.01.00

番号で識別されるオブジェクトは，カーネルやソフトウェア部品の内部や外部からの条件で意味が与えられるため，生成の対象とはならない．オブジェクト
番号で識別されるオブジェクトをカーネルやソフトウェア部品に登録することを，オブジェクトの定義と呼ぶ．
オブジェクトを種類分けしない場合には，オブジェクトの ID番号には 1から連続した正の値を用いる．保護機構を入れるなどの目的で，オブジェクトをユー
ザオブジェクトとシステムオブジェクトに分類する場合には，ユーザオブジェ
クトには 1から連続した正の ID番号，システムオブジェクトには (–5)から小さい方へ連続した負の ID 番号を用いる．この場合，ID 番号の自動割付けの対象となるのは，正の ID 番号を持ったユーザオブジェクトのみである．(–4)〜 0は，
特別な意味に用いるために予約されている．
【スタンダードプロファイル】
スタンダードプロファイルでは，オブジェクトを種類分けする必要はなく，負の値の ID 番号をサポートする必要はない．少なくとも 1 〜 255の範囲の正の値の ID 番号をサポートしなければならない．
【補足説明】
オブジェクト番号で識別されるオブジェクトの例として，割込みハンドラやランデブがある．割込みハンドラ番号はハードウェア条件から，ランデブ番号はカーネル内部の条件から番号が定まり，アプリケーションが自由に番号を割り付けることはできない．

2.1.4 優先度
優先度は，タスクやメッセージなどの処理順序を制御するために，アプリケー
ションによって与えられるパラメータである．優先度には，1 から連続した正の値を用い，値が小さいほど優先して処理される（優先度が高い）．
【スタンダードプロファイル】
スタンダードプロファイルでは，少なくとも 1 〜 16の 16段階のタスク優先度をサポートしなければならない．また，少なくともタスク優先度以上の段階数のメッセージ優先度をサポートしなければならない．
【µITRON3.0 仕様との相違】µITRON3.0 仕様では，システムのための優先度として負の値が使えることになっていたが，使い途が少ないため正の値に限定した．実装独自に負の値の優先度を使えるようにすることは許される．また，少なくとも 1 〜 8の 8段階以上のタスク優先度をサポートしなければならないものとしていたが，µITRON4.0
仕様全体では最低限の段階数を規定せず，スタンダードプロファイルにおいて
1 〜 16の 16 段階以上とした．

27

µITRON4.0 仕様

Ver. 4.01.00

2.1.5 機能コード
機能コードは，サービスコールを識別するために，各サービスコールに割り付けられる番号である．機能コードは，サービスコールをソフトウェア割込みで呼び出す場合などに利用するもので，サービスコールをサブルーチンコールで呼び出す場合には用いる必要はない．
ITRON 仕様のカーネルおよびソフトウェア部品のサービスコールには，それぞれ異なる負の値の機能コードを割り付ける．ただし，(–4) 〜 0 は，特別な意味に用いるために予約されている．正の値の機能コードは，拡張サービスコールをあらわす．

2.1.6 サービスコールの返値とエラーコード
サービスコールの返値は原則として符号付きの整数で，エラーが発生した場合には負の値のエラーコード，処理を正常に終了した場合は E_OK（＝ 0）また
は正の値とする．正常終了した場合の返値の意味はサービスコール毎に規定する．この原則の例外として，真偽値（BOOL 型）を返すサービスコールと，呼び出されるとリターンすることのないサービスコールがある．リターンすることのないサービスコールは，（すなわち void
C言語 API では返値を持たないもの
型の関数）として宣言する．
エラーコードは，
下位 8ビットのメインエラーコードと，
それを除いた上位ビットのサブエラーコードで構成される．メインエラーコード，サブエラーコード
共に負の値とする（サブエラーコードの値とは，エラーコードの値を符号付きで 8 ビット右シフトしたものである）．したがって，それらを組み合わせたエラーコードも負の値となる．メインエラーコードの名称，意味，値は，カーネルおよびソフトウェア部品で共通とし，ITRON 仕様共通定義で規定する．メイ
ンエラーコードは，検出の必要性や発生状況などにより，エラークラスに分類
される．
ITRON 仕様の各サービスコールの機能説明においては，サービスコールが返す
メインエラーコードのみを記述するのを原則とし，サブエラーコードは実装定義とする．ただし，ソフトウェア部品仕様において，サブエラーコードについても規定する場合もある．サービスコールの機能説明などに「E_XXXXX エ
ラーを返す」ないしは「E_XXXXX エラーとなる」という記述があった場合，
メインエラーコードを E_XXXXX とするエラーコードを返すことを意味する．
警告クラスのメインエラーコードである場合を除いては，サービスコールがエ
ラーコードを返した場合には，サービスコールを呼び出したことによる副作用はない（言い換えると，サービスコールを呼び出したことで，システムの状態は変化していない）のが原則である．ただし，サービスコールの機能上，サービスコールを呼び出したことによる副作用を防げない場合は例外とし，サービ
スコールの機能説明でその旨を明示する．
ITRON 仕様を実装する場合には，オーバヘッドを削減するために，一部のエ28

µITRON4.0 仕様

Ver. 4.01.00

ラーの検出を省略することができる．検出を省略することができるエラーは，
メインエラーコードが属するエラークラスによって定めるのを原則とし，エラークラス毎に検出を省略することができる旨を明示する．この原則の例外となるケースについては，サービスコールの機能説明でその旨を明示する．エ
ラーの検出を省略したことにより，本来検出すべきエラーを検出できなかった
場合の振舞いは未定義である．
次のメインエラーコードは，多く（または，ほとんどすべて）のサービスコー
ルで発生する可能性があるため，サービスコールが返すメインエラーコードとしてサービスコール毎には記述しないのを原則とする．
E_SYS
E_NOSPT
E_RSFN
E_CTX
E_MACV
E_OACVE_NOMEM

システムエラー
未サポート機能
予約機能コード
コンテキストエラー
メモリアクセス違反
オブジェクトアクセス違反
メモリ不足

ただし，これらのエラーが発生する理由がサービスコール独特のものである場
合などには，この原則にかかわらず，サービスコール毎に記述する．
サービスコールが複数のエラーを検出すべき状況で，どのエラーを示すエラー
コードを返すかは，実装依存とする．
【補足説明】
E_OK（＝ 0）は正常終了を示す返値であり，エラーコードではない．ただし，便宜上，サービスコールが返すエラーコードとして記述する場合がある．
サービスコールでエラーが発生したかを，返値の下位 8ビットが負の値であるかで判断する方法は正しくない．これは，サービスコールの処理が正常に終了
し，返値が正の値であった場合でも，返値の下位 8ビットが負の値である可能性があるためである．
【µITRON3.0 仕様との相違】
エラーコードをメインエラーコードとサブエラーコードから構成されるものとし，カーネルとソフトウェア部品でメインエラーコードを共通化することとした．サブエラーコードは，エラーが発生した原因をより細かく報告することを目的としており，主にデバッグ時に使うことを想定している．例えば，メイ
ンエラーコードが E_PAR（パラメータエラー）の場合に，どのパラメータの値が不正であったかを示すためにサブエラーコードを使うことができる．また，E_OK はエラーコードではないと規定した．
一部のエラーの検出を省略することができることを明示し，どのエラーの検出を省略できるかをエラークラス毎に規定することとした．また，サービスコー
ル毎に記述しないメインエラーコードを見直した．
µITRON3.0 仕様では，サービスコールの返値に関する原則として，正の値を返29

µITRON4.0 仕様

Ver. 4.01.00

す場合を規定していたが，実際に正の値を返すカーネルのサービスコールはな
かった．µITRON4.0 仕様では，カーネルのサービスコールに，正の値を返すものがある．また，真偽値を返すサービスコールを新たに導入した．

2.1.7 オブジェクト属性と拡張情報
ID番号で識別されるオブジェクトは，原則としてオブジェクト属性を持つ．オ
ブジェクト番号で識別されるオブジェクトが，オブジェクト属性を持つ場合もある．オブジェクト属性は，オブジェクト登録時に指定し，オブジェクトの細かな動作の違いやオブジェクトの初期状態を定める．オブジェクト属性に
TA_XXXXXが指定されている場合，そのオブジェクトを「 TA_XXXXX属性のオブジェクト」と呼ぶ．オブジェクト登録後にオブジェクト属性を読み出すイ
ンタフェースは，一般には用意されない．
各オブジェクトのオブジェクト属性に指定できる値とその意味は，オブジェク
トを登録するサービスコールまたは静的 APIの機能説明で規定する．特に指定すべきオブジェクト属性がない場合には，TA_NULL（＝ 0）を指定する．
実行主体となるオブジェクトは，拡張情報を持つ場合がある．拡張情報はオブジェクト登録時に指定し，オブジェクトが実行を始める時にパラメータとして渡される情報で，カーネルやソフトウェア部品自身の動作には影響を与えない．オブジェクトを指定して拡張情報を読み出すインタフェースは，一般には用意されない．
【補足説明】
実行主体となるオブジェクトで拡張情報を持つものの例として，タスク，周期
ハンドラなどのタイムイベントハンドラ，割込みサービスルーチンがある．
【µITRON3.0 仕様との相違】µITRON3.0 仕様では，ID番号で識別されるオブジェクトは原則として拡張情報を持っていたが，必要なものだけに限定することとした．関連して，拡張情報
はオブジェクトが実行を始める時にパラメータとして渡されるものとし，オブジェクトの状態参照サービスコールでは読み出せないことを原則とした．

2.1.8 タイムアウトとノンブロッキング
待ち状態に入る可能性のあるサービスコールには，必要に応じて，タイムアウ
トとノンブロッキングの機能を持たせる．
タイムアウトは，指定された時間が経過しても処理が完了しない場合に，処理をキャンセルしてサービスコールからリターンするものである（この時，サービスコールは E_TMOUTエラーを返す）．そのため，「サービスコールがエラー
コードを返した場合には，サービスコールを呼び出したことによる副作用はない」という原則より，タイムアウトした場合には，サービスコールを呼び出したことで，システムの状態は変化していないのが原則である．ただし，サービ

30

µITRON4.0 仕様

Ver. 4.01.00

スコールの機能上，処理のキャンセル時に元の状態に戻せない場合は例外とし，サービスコールの機能説明でその旨を明示する．
タイムアウト時間を 0に設定すると，サービスコールの中で待ち状態に入るべき状況になっても，待ち状態には入らない．そのため，タイムアウト時間を 0としたサービスコール呼出しでは，待ち状態に入る可能性がない．タイムアウ
ト時間を 0としたサービスコール呼出しを，ポーリングと呼ぶ．すなわち，ポー
リングを行うサービスコールでは，待ち状態に入る可能性がない．次に説明するノンブロッキングとは，処理がキャンセルされるか継続されるかの違いがある．
ノンブロッキングは，サービスコールの中で待ち状態に入るべき状況になった
場合に，処理を継続したままサービスコールからリターンするものである（この時，サービスコールは E_WBLKエラーを返す）．そのため，サービスコール
からリターンしても処理は継続しており，処理が完了した時点（または，処理がキャンセルされた時点）で，何らかの方法でアプリケーションプログラムに処理完了が通知される．サービスコールからリターンした後も処理が継続しているため，リターンパラメータ（またはパラメータ）を入れる領域やパケット
は，サービスコールからリターンした後も，処理が完了するまでの間は別の目的に使ってはならないことを原則とする．
サービスコールの中で待ち状態になっている場合，またはノンブロッキング指定による処理が継続している場合，サービスコールによる処理がペンディングされているという．
ITRON仕様の各サービスコールの機能説明では，タイムアウトがない（言い換えると，永久待ちの）場合の振舞いを説明するのを原則とする．サービスコー
ルの機能説明などで「待ち状態に入る」ないしは「待ち状態に移行させる」と記述されている場合でも，タイムアウト時間を指定をした場合には，指定時間経過後に待ち状態が解除され，メインエラーコードを E_TMOUTとしてサービ
スコールからリターンする．また，ポーリングの場合には，待ち状態に入らずにメインエラーコードを E_TMOUTとしてサービスコールからリターンする．
ノンブロッキング指定をした場合には，待ち状態に入らずにメインエラーコー
ドを E_WBLKとしてサービスコールからリターンする．
タイムアウト指定（TMO 型）は，正の値でタイムアウト時間，TMO_POL（＝0）でポーリング，TMO_FEVR（＝ –1）で永久待ちを指定する．また，サービ
スコールによっては，TMO_NBLK（＝ –2）でノンブロッキングを指定することができる．タイムアウト時間が指定された場合，タイムアウトの処理は，サービスコールが呼び出されてから，指定された以上の時間が経過した後に行うことを保証しなければならない．
【補足説明】
カーネルのサービスコールは，ノンブロッキングの機能を持っていない．ポーリングを行うサービスコールでは待ち状態に入らないため，それを呼び出した
タスクの優先順位は変化しない．
31

µITRON4.0 仕様

Ver. 4.01.00

一般的な実装においては，
タイムアウト時間に 1が指定されると，サービスコー
ルが呼び出されてから 2回めのタイムティックでタイムアウト処理を行う．タ
イムアウト時間に 0 を指定することはできないため（0 は TMO_POL に割り付けられている），このような実装では，サービスコールが呼び出された後の最初のタイムティックでタイムアウトすることはない．

2.1.9 相対時間とシステム時刻
イベントの発生する時刻を，サービスコールを呼び出した時刻などからの相対値で指定する場合には，相対時間（RELTIM型）を用いる．相対時間を用いてイベントの発生時刻が指定された場合，イベントの処理は，基準となる時刻か
ら指定された以上の時間が経過した後に行うことを保証しなければならない．
イベントの発生間隔など，イベントの発生する時刻以外を指定する場合にも，相対時間（RELTIM型）を用いる．その場合，指定された相対時間の解釈方法
は，それぞれの場合毎に定める．
時刻を絶対値で指定する場合には，システム時刻（SYSTIM 型）を用いる．カー
ネル仕様には現在のシステム時刻を設定する機能が用意されているが，この機能を用いてシステム時刻を変更した場合にも，相対時間を用いて指定されたイ
ベントが発生する実世界の時刻（これを実時刻と呼ぶ）は変化しない．言い換
えると，相対時間を用いて指定されたイベントが発生するシステム時刻は変化することになる．
【補足説明】
一般的な実装においては，相対時間に 1が指定されると，サービスコールが呼び出されてから 2回めのタイムティックでイベント処理を行う．また，相対時間に 0 が指定されると，サービスコールが呼び出された後の最初のタイム
ティックでイベント処理を行う．

2.1.10 システムコンフィギュレーションファイル
カーネルやソフトウェア部品の構成やオブジェクトの初期状態を定義するためのファイルを，システムコンフィギュレーションファイルと呼ぶ．システム
コンフィギュレーションファイルには，カーネルやソフトウェア部品の静的APIと ITRON 仕様共通静的 API（以下，単に共通静的 API と呼ぶ）に加えて，C
言語処理系のプリプロセッサディレクティブを記述することができる．システ
ムコンフィギュレーションファイル中の静的 APIを解釈して，カーネルやソフ
トウェア部品を構成するためのツールを，コンフィギュレータと呼ぶ．
システムコンフィギュレーションファイルの処理手順は次の通りである（図2-1）．システムコンフィギュレーションファイルは，まず，C 言語のプリプロ
セッサに通される．次にソフトウェア部品のコンフィギュレータによって順に処理され，最後にカーネルのコンフィギュレータによって処理される．
ソフトウェア部品のコンフィギュレータは，渡されたファイル中に含まれる自32

µITRON4.0 仕様

Ver. 4.01.00

system.cfg

システムコンフィギュ
レーションファイル

www_cfg.c

C言語プリプロセッサ

ソフトウェア部品
構成・初期化ファイル
ソフトウェア部品のコンフィギュレータ

www_id.h

ID自動割付け結果
ヘッダファイルAAA

kernel_cfg.c

カーネル
構成・初期化ファイル

カーネルのコンフィギュレータ

kernel_id.h

ID自動割付け結果
ヘッダファイル※ 図中のファイル名は例である．
図 2-1. システムコンフィギュレーションファイルの処理手順
分自身に対する静的 API と共通静的 APIを解釈し，自分自身の構成や初期化に必要なファイルを C 言語のソースファイルの形で，ID 自動割付け結果ヘッダ
ファイルを C言語のヘッダファイルの形で生成する．また，渡されたファイル
から自分自身に対する静的 APIを取り除き，以降のコンフィギュレータに対す
る静的 APIを追加し（必要な場合のみ），次のコンフィギュレータに渡す．
カーネルのコンフィギュレータは，渡されたファイル中のすべての静的 APIを解釈し，自分自身の構成や初期化に必要なファイルを C言語のソースファイルの形で，ID自動割付け結果ヘッダファイルを C言語のヘッダファイルの形で生成する．自分自身に対する静的 API または共通静的 APIとして解釈できない記述が含まれている場合には，エラーを報告する．
カーネルおよびソフトウェア部品のコンフィギュレータは，“#” で始まる行を無視する．ソフトウェア部品のコンフィギュレータは，“#” で始まる行を，そのまま次のコンフィギュレータに渡す．
【補足説明】
ソフトウェア部品のコンフィギュレータが，以降のコンフィギュレータに対す
33

µITRON4.0 仕様

Ver. 4.01.00

る静的 API を追加する場合には，追加する静的 API のパラメータ中に，システ
ムコンフィギュレーションファイルまたはそこからプリプロセッサディレク
ティブ（“#include”）を用いてインクルードされるファイル中で定義されたプ
リプロセッサマクロを用いてはならない．これは，それらのプリプロセッサマ
クロは，最初にC言語プリプロセッサに通された時点で展開されるためである．
システムコンフィギュレーションファイルの処理手順を，図 2-2 の例を用いて説明する．なお，ID 番号の自動割付けについては2.1.11節を，共通静的 APIについては2.3.4節を，それぞれ参照すること．

system.cfg#include "rep_id.h"
INCLUDE("<itron.h>");TCP_CRE_REP(REP_HTTP, { ....
CRE_TSK(TSK_A, { TA_HLNG, ..
CRE_SEM(SEM_A, { TA_TPRI, ..

rep_id.h#define REP_HTTP 1

C言語プリプロセッサ

INCLUDE("<itron.h>");TCP_CRE_REP(1, { ...........
CRE_TSK(TSK_A, { TA_HLNG, ..
CRE_SEM(SEM_A, { TA_TPRI, ..
tcpip_cfg.c#include <itron.h>

TCP/IPプロトコルスタックのコンフィギュレータ

TCP受付口の初期化情報

INCLUDE("<itron.h>");CRE_TSK(TSK_TCPIP, { .......
CRE_MBX(MBX_REP_HTTP, ......
CRE_TSK(TSK_A, { TA_HLNG, ..
CRE_SEM(SEM_A, { TA_TPRI, ..

kernel_cfg.c#include <itron.h>
タスク，セマフォ，メール
ボックスの初期化情報
kernel_id.h

カーネルのコンフィギュレータ

#define TSK_TCPIP 1#define MBX_REP_HTTP 1#define TSK_A 2#define SEM_A 1

図 2-2. システムコンフィギュレーションファイルの処理例

34

µITRON4.0 仕様

Ver. 4.01.00

最初に，システムコンフィギュレーションファイルがC言語のプリプロセッサに通されると，プリプロセッサディレクティブ（“#include”）によるインクー
ルード処理が行われ，プリプロセッサマクロ（この例では，REP_HTTP）が展開される．
次に，ソフトウェア部品の一つである TCP/IP プロトコルスタックのコンフィ
ギュレータは，渡されたファイル中に含まれる自分自身に対する静的API（この例では，TCP_CRE_REP）と共通静的 API（ INCLUDE）を解釈し，TCP/IP
プロトコルスタックの構成や初期化に必要なファイルtcpip_cfg.cを生成する．
ここで，tcpip_cfg.c の中の #include は，共通静的APIの INCLUDEから生成したものである．この例では，解釈された静的APIに ID番号自動割付けの対象となる識別子が含まれていないため，ID番号自動割付け結果ファイルは生成しな
い（空のID 番号自動割付け結果ファイルを生成してもよい）．また，TCP/IPプ
ロトコルスタックのコンフィギュレータは，自分自身の構成に必要なカーネルの静的API（この例では，TSK_TCPIPに対する CRE_TSKと MBX_REP_HTTP
に対する CRE_MBX）を追加し，カーネルのコンフィギュレータに渡す．
最後にカーネルのコンフィギュレータは，渡されたファイル中に含まれるすべての静的 A P I を解釈し，カ ーネルの構 成や初期化 に必要なフ ァイル
kernel_cfg.cを生成する．ここで，kernel_cfg.cの中の #includeは，共通静的
APIの INCLUDEから生成したものである．また，静的 APIに含まれる ID番号
自動割付けの対象となる識別子（この例では，TSK_TCPIP，MBX_REP_HTTP，
TSK_A，SEM_A）に整数値を割り付け，その結果を ID番号自動割付け結果ファイル kernel_id.h として生成する．
【仕様決定の理由】
システムコンフィギュレーションファイルの処理手順を標準化したのは，カー
ネルとソフトウェア部品が独立に開発された場合に対応するためである．
システムコンフィギュレーションファイルを最初にC言語プリプロセッサに通すのは，次のようなことが可能になるためである．
• プリプロセッサのインクルードディレクティブを用いて，システムコンフィ
ギュレーションファイルを複数のファイルに分割することができる．例えば，ソフトウェア部品を組み込む場合に，それに必要な静的 APIを独立したファイルに記述しておき，そのファイルをシステムコンフィギュレーション
ファイルからインクルードするといった使い方が考えられる．
• オブジェクトの ID 番号やオブジェクト番号を，直接整数値で記述する代わりに，整数値に展開されるプリプロセッサマクロを用いて記述することができる．
• システムコンフィギュレーションファイル中にプリプロセッサの条件ディレクティブ（ “#ifdef” など）を記述して，カーネルやソフトウェア部品の構成やオブジェクトの初期状態を条件によって変えることができる．
コンフィギュレータに “#” で始まる行を無視させるのは，プリプロセッサが
ソースファイルなどに関する情報（そのような情報は，“#” で始まる行として
35

µITRON4.0 仕様

Ver. 4.01.00生成されるのが一般的である）を生成する場合に対応するためである．“#” で始まる行を読み込み，エラーメッセージなどの生成に利用することは許される．

2.1.11 静的 API の文法とパラメータ
静的 APIの文法は，C言語の関数呼出し式の文法に準ずる．また，サービスコー
ルに対応する静的 API のパラメータは，対応するサービスコールの C 言語 APIに準ずる．ただし，パラメータにパケットへのポインタがある場合には，パケット中の各要素を “,”で区切り， “{” と “}” で囲んだ形で記述する．
静的 APIのパラメータは，記述に使える式によって次の 4 種類に分類される．
(a) 自動割付け対応整数値パラメータ整数値（負の数を含む），単一の識別子，またはそれらに展開されるプリプ
ロセッサマクロ（後に述べる制限あり）のみを記述できるパラメータ．ID
番号自動割付けの対象となるオブジェクトの ID 番号などがこれに該当す
る．
自動割付け対応整数値パラメータに単一の識別子が記述された場合，その静的 APIを処理するコンフィギュレータが，識別子に整数値を割り付ける．
これを，コンフィギュレータによる ID 番号の自動割付けと呼ぶ．コンフィ
ギュレータは，各識別子を割り付けた整数値にマクロ定義するプリプロ
セッサディレクティブ（“#define”）を含むファイルを，自動割付け結果
ヘッダファイルとして生成する．整数値を割り付けられた識別子は，そのコンフィギュレータおよびそれ以降のコンフィギュレータが処理する静的
APIのパラメータ中で，割り付けられた整数値に展開されるプリプロセッサ
マクロと同等なものとして用いることができる．
(b) 自動割付け非対応整数値パラメータ整数値（負の数を含む）またはそれに展開されるプリプロセッサマクロ（後に述べる制限あり）のみを記述できるパラメータ．ID 番号自動割付けの対象とならないオブジェクトの ID 番号やオブジェクト番号などがこれに該当
する．
(c) プリプロセッサ定数式パラメータ
プリプロセッサによって解釈できる定数式のみを記述できるパラメータ．
定数およびマクロと，プリプロセッサが解釈できる演算子のみを用いることができる．オブジェクト属性などがこれに該当する．
(d) 一般定数式パラメータ
C 言語の任意の定数式を記述できるパラメータ．
多くのパラメータはこれに該当する．
静的 API の各パラメータがどれに分類されるかは，静的 API 毎に定める．自動割付け対応整数値パラメータ，自動割付け非対応整数値パラメータ，プリプロ
セッサ定数式パラメータに該当するものは，静的 APIの機能説明においてその36

µITRON4.0 仕様

Ver. 4.01.00

旨を明示し，明示のないものは一般定数式パラメータである．
ITRON仕様共通静的 API として，ファイルをインクルードする機能を規定している．そのため，システムコンフィギュレーションファイル中でファイルをイ
ンクルードするために，プリプロセッサディレクティブ（“#include”）を用いる方法と，共通静的 API を用いる方法がある．この 2 つの方法には次の違いがある．
• 自動割付け対応整数値パラメータと自動割付け非対応整数値パラメータ（以下，これらをあわせて整数値パラメータと呼ぶ）の記述にプリプロセッサマ
クロを用いる場合には，システムコンフィギュレーションファイルまたはそこからプリプロセッサディレクティブを用いてインクルードされるファイル中で定義されたプリプロセッサマクロのみを用いることができる．
• プリプロセッサディレクティブを用いてインクルードされるファイルには，
静的 APIとプリプロセッサディレクティブのみを記述することができる．それに対して，静的 API を用いてインクルードされるファイルには，C言語の宣言や定義とプリプロセッサディレクティブのみを記述することができる．
メモリ領域をカーネルに確保させるための指定などに用いる NULL は，静的
API のパラメータ中では識別子として認識される．計算結果が 0 になる定数式
は NULL と解釈されるとは限らず，そのような定数式を記述した場合の振舞いは実装依存とする．また，コンフィギュレータが処理する前に，NULLがプリプロセッサによってマクロ展開されてはならない．すなわち，システムコン
フィギュレーションファイルおよびそこからプリプロセッサディレクティブを用いてインクルードされるファイル中で，NULLをプリプロセッサマクロとして定義してはならない．
静的 APIに文法エラーやパラメータ数の過不足があった場合には，それを検出したコンフィギュレータがエラーを報告する．また，コンフィギュレータは，
静的 API で生成されたオブジェクトの ID 番号が連続にならない場合にも，エラーを報告することができる．静的 API の処理において検出すべきエラーと，エラーを検出した場合の扱いについては，実装定義とする．
【スタンダードプロファイル】
ほとんどの静的 APIで，実装独自にパラメータを追加することが許されているが，そのような実装をスタンダードプロファイルに準拠させるためには，追加したパラメータが記述されていない場合でも，デフォルト値を補うなどの方法
で正しく処理できることが必要である．
【補足説明】
静的 APIは，システムコンフィギュレーションファイル中でフリーフォーマッ
トで記述できる．すなわち，ワードの間に空白文字や改行，コメントが含まれていてもよい．また，静的 APIの最後には “;”が必要である．
C 言語の列挙型の定数，sizeof はプリプロセッサで解釈できないため，プリプ
ロセッサ定数式パラメータに用いることはできない．
37

µITRON4.0 仕様

Ver. 4.01.00

ファイル構成上，システムコンフィギュレーションファイルからプリプロセッ
サディレクティブを用いてインクルードされるファイル中から，NULLのプリプロセッサマクロ定義を取り除くことが難しい場合には，次の方法で対応することができる．まず，システムコンフィギュレーションファイルの先頭で特定の識別子（ここでは “CONFIGURATOR” とする）をプリプロセッサマクロとして定義（“#define CONFIGURATOR”）し，問題となる NULL のプリプロ
セッサマクロ定義を “#ifndef CONFIGURATOR”と “#endif”で囲む．
【仕様決定の理由】
静的 API のパラメータを 4 種類に分類したのは，コンフィギュレータの実装を単純にするためである．
オブジェクトの ID番号やオブジェクト番号はコンフィ
ギュレータで解釈することが必須であるため，自動割付けが可能なものを除いては，プリプロセッサを通すと整数値になるものに限定した（整数値パラメータ）．また，オブジェクト属性など，その値によって登録するオブジェクトの構造が変わる可能性のあるパラメータについては，コンフィギュレータが生成する C 言語のソースコード中に，そのパラメータに関する条件ディレクティブが記述できるように，プリプロセッサが解釈できる定数式に限定した（プリプロセッサ定数式パラメータ）．その他のパラメータについては，C 言語の任意の定数式を記述できることとした（一般定数式パラメータ）．ただし，この方法でコンフィギュレータを実現した場合，コンフィギュレータがすべてのパラ
メータの定数値を知ることができず，コンフィギュレータによるパラメータエ
ラーのチェックには限界がある．すべてのパラメータの定数値を知りたい場合には，コンフィギュレータからコンパイラを呼び出し，定数式を定数値に変換する方法が考えられるが，この方法ではコンパイラ毎にコンフィギュレータの修正が必要になる可能性があるため，標準とはしないこととした．

2.2 APIの名称に関する原則
2.2.1 ソフトウェア部品識別名
標準化されるソフトウェア部品の API の名称に用いるために，その種類を 2 〜
4 文字程度であらわすソフトウェア部品識別名を定める．複数の機能単位から構成されるソフトウェア部品の場合には，機能単位毎にソフトウェア部品識別名を与える場合もある．ソフトウェア部品識別名は，ソフトウェア部品仕様で定める．
独自に APIを定義したソフトウェア部品については，この規定の適用範囲外ではあるが，標準化されたソフトウェア部品との名称の衝突を避けるために，ソフトウェア部品識別名を 5文字以上とするか，ソフトウェア部品識別名の前に“v” の文字を付加することを推奨する．
以下，ソフトウェア部品識別名を小文字で表記したものを www，大文字で表記したものを WWW と記述する．
38

µITRON4.0 仕様

Ver. 4.01.00

2.2.2 サービスコール
カーネルのサービスコールの名称は，xxx で操作の方法，yyy で操作の対象をあらわし，xxx_yyyの形を基本とする．xxx_yyyから派生したサービスコール
は，派生したことをあらわす文字 z を付加し，zxxx_yyy の形とする．二重に派生したサービスコールの場合には，派生をあらわす文字を 2 つ付加し，zzxxx_yyyの形となる．
ソフトウ ェア部品の サービスコ ールの名称 は，www_xxx_yyy ないし は
www_zxxx_yyy の形とする．
実装独自に用意するサービスコール名称は，xxx または zxxx の前に “v”の文字を付加し，vxxx_yyy，vzxxx_yyy，www_vxxx_yyy，www_vzxxx_yyyの形とするのを原則とする．ただし，カーネル仕様において，割込みハンドラから呼び出せるサービスコールに付加する “i”の文字が “v” と重なる場合には，“i”を前にして ivxxx_yyyの形とする．
【補足説明】µITRON4.0 仕様において，xxx，yyy，zに用いている省略名とその元になった
英語を表 2-1に示す．

2.2.3 コールバック
コールバックの名称は，パラメータの形でのみ仕様にあらわれるため，パラメータの名称の原則に従う．

2.2.4 静的 API
静的 APIの名称は，原則として，対応するサービスコールの名称を大文字で表記したものとする．サービスコールに対応しない静的 API の名称は，サービス
コールの名称に関する原則に準拠して定めた名称を大文字で表記したものとする．
カーネルやソフトウェア部品で共通に利用すべきITRON仕様共通静的APIの名
称と意味は，ITRON仕様共通定義で規定する．

2.2.5 パラメータとリターンパラメータ
パラメータとリターンパラメータの名称は，すべて小文字で 4 〜 7 文字程度とする．パラメータとリターンパラメータの名称に関して，以下の原則を設ける．
〜 id
〜 no
〜 atr
〜 stat〜 mode〜 ID（オブジェクトの ID 番号，ID 型）〜番号（オブジェクト番号）〜属性（オブジェクト属性，ATR型）〜状態（オブジェクト状態，STAT 型）〜モード（サービスコールの動作モード，MODE 型）

39µITRON4.0 仕様

Ver. 4.01.00

表 2-1. µITRON4.0 仕様における省略名と元になった英語
xxx
acp
act*
att
cal
can
chg
clr
cre
def
del
dis
dly
ena
exd
ext
fwd
get
loc*
pol
ras
rcv
ref
rel
rot
rpl
rsm
set
sig
slp
snd
sns
sta
stp
sus
ter
unl
wai*
wup*

元になった英語
acceptactivate
attachcall
cancelchangeclear
createdefinedeletedisabledelay
enableexit and delete
exit
forward
get
lock
poll
raise
receivereferencereleaserotatereply
resumeset
signal
sleep
send
sense
start
stop
suspendterminateunlockwait
wake up

yyy
alm
cfg
cpu
ctx
cyc
dpn
dsp
dtq
exc
flg
inh
ini
int
isr
mbf
mbx
mpf
mpl
mtx
ovr
por
pri
rdq
rdv
sem
sys
svc
tex
tid
tim
tsk
tst
ver

元になった英語
alarm handler
configuration
CPU
context
cyclic handler
dispatch pending
dispatchdata queue
exception
eventflaginterrupt handler
initilizationinterrupt
interrupt service routine
message buffer
mailboxfixed-sized memory pool
memory poolmutex
overrun handler
port
priority
ready queue
randezvous
semaphoresystemservice calltask exceptiontask IDtimetask
task status
version

z
a
f
i
p
t

元になった英語
automatic ID assignment
force
interrupt
poll
timeout※ * を付した省略名は yyy としても用いている．
40

µITRON4.0 仕様

Ver. 4.01.00

〜 pri
〜 sz
〜 cnt
〜 ptn
〜 tim
〜 cd

〜優先度（優先度，PRI型）〜サイズ（単位はバイト数，SIZE型または UINT型）〜の個数（単位は個数，UINT 型）〜パターン〜時刻，〜時間
〜コード

i〜
max 〜
min 〜
left〜

〜の初期値
〜の最大値
〜の最小値
残り〜

p_〜

リターンパラメータ（またはパラメータ）を入れる領域
へのポインタpk_ 〜
パケットへのポインタ
pk_cyyy
cre_yyyに渡すパケットへのポインタ
pk_dyyy
def_yyyに渡すパケットへのポインタ
pk_ryyy
ref_yyyに渡すパケットへのポインタ
pk_www_cyyy
www_cre_yyyに渡すパケットへのポインタ
pk_www_dyyy www_def_yyy に渡すパケットへのポインタ
pk_www_ryyy
www_ref_yyy に渡すパケットへのポインタ
ppk_〜
パケットへのポインタを入れる領域へのポインタ

パラメータやリターンパラメータの名称が同じであれば，原則として同じデータ型である．

2.2.6 データ型
データ型の名称は，すべて大文字で 2〜 10文字程度とする．データ型の名称に関して，以下の原則を設ける．
〜P
ポインタのデータ型
T_〜
パケットのデータ型（構造体）
T_CYYY
cre_yyyに渡すパケットのデータ型
T_RYYY
ref_yyyに渡すパケットのデータ型
T_WWW_ 〜
ソフトウェア部品で用いる構造体
T_WWW_CYYY
www_cre_yyyに渡すパケットのデータ型
T_WWW_RYYY
www_ref_yyy に渡すパケットのデータ型
カーネルやソフトウェア部品で共通に利用すべき ITRON 仕様共通データ型の名称と意味は，ITRON仕様共通定義で規定する．

2.2.7 定数
定数の名称はすべて大文字で記述し，以下の原則に従って定める．

41

µITRON4.0 仕様

Ver. 4.01.00(A) ITRON 仕様共通定数
カーネルやソフトウェア部品で共通に利用すべき ITRON 仕様共通定数の名称については特に原則を定めず，その意味および値と共に，ITRON仕様共通定義で規定する．
(B) エラーコード
ITRON 仕様で定めるメインエラーコードの名称は E_XXXXX の形（XXXXXは，
2〜 5文字程度），実装独自に定義するメインエラーコードの名称は EV_XXXXXの形とする．
サブエラーコードの名称に関しては，特に原則を定めない．
エラークラスの名称は，EC_XXXXX の形（XXXXXは，2 〜 5 文字程度）とする．
(C) その他の定数
その他の定数の名称は，TUU_XXXXX または TUU_WWW_XXXXXの形とする（UUは 1〜 3 文字程度，XXXXX は 2〜 7 文字程度）．同じパラメータに用いられる定数の名称については，UU の部分を共通にする．リターンパラメータについても同様とする．また，ソフトウェア部品の API で，多くのサービスコール
やコールバックに共通に用いる定数については，WWW_XXXXXの形とする場
合もある．
上記に加えて，その他の定数の名称に関して，以下の原則を設ける．
TA_〜
オブジェクトの属性値
TFN_ 〜
サービスコールの機能コード
TFN_XXX_YYY
xxx_yyy の機能コード
TFN_WWW_XXX_YYY www_xxx_yyyの機能コード
TSZ_ 〜〜のサイズ
TBIT_ 〜〜のビット数
TMAX_〜〜の最大値
TMIN_〜〜の最小値

2.2.8 マクロ
マクロの名称はすべて大文字で記述し，定数と同様の原則に従って定める．特に，カーネルやソフトウェア部品で共通に利用すべき ITRON仕様共通マクロの名称と意味は，ITRON 仕様共通定義で規定する．

2.2.9 ヘッダファイル
ITRON 仕様共通定義で規定されるデータ型，定数，マクロの定義などを含む
ヘッダファイルの名称を “itron.h”，カーネル仕様で定められるサービスコー
ルの宣言と，データ型，定数，マクロの定義などを含むヘッダファイルの名称
を “kernel.h”，カーネルのコンフィギュレータが生成する自動割付け結果ヘッ
42

µITRON4.0 仕様

Ver. 4.01.00

ダファイルの名称を “kernel_id.h” とする．
ソフトウェア部品仕様で定められるサービスコールの宣言などを含むヘッダ
ファイルの名称と，ソフトウェア部品のコンフィギュレータが生成する自動割
付け結果ヘッダファイルの名称は，ソフトウェア部品識別名で始まる名称とす
ることを原則として，ソフトウェア部品毎に定める．

2.2.10 カーネルとソフトウェア部品の内部識別子
アプリケーションプログラムとリンクして用いるカーネルおよびソフトウェ
ア部品においては，アプリケーションプログラムとの名称の衝突を避けるために，カーネルやソフトウェア部品の内部に閉じて使われるルーチンやメモリ領域などの識別子の内，オブジェクトファイルのシンボル表に登録され外部から参照できるもの（これを内部識別子と呼ぶ）の名称に関する原則を次のように定める．
カーネルの内部識別子は，C 言語レベルで，_kernel_ または _KERNEL_ で始まる名称とすることを原則とする．ソフトウェア部品の内部識別子は，C言語レベルで，_www_ または _WWW_ で始まる名称とすることを原則とする．

2.3 ITRON仕様共通定義
2.3.1 ITRON仕様共通データ型
ヘッダファイル itron.hは，64ビット整数をあらわすデータ型（D，UD，VD）
を除いて，以下の ITRON仕様共通データ型の定義を含まなければならない．
B
H
W
D

符号付き 8ビット整数
符号付き 16ビット整数
符号付き 32ビット整数
符号付き 64ビット整数

UB
UH
UW
UD

符号無し 8ビット整数
符号無し 16ビット整数
符号無し 32ビット整数
符号無し 64ビット整数

VB
VH
VW
VD

データタイプが定まらない 8ビットの値
データタイプが定まらない 16ビットの値
データタイプが定まらない 32ビットの値
データタイプが定まらない 64ビットの値

VP
FP

データタイプが定まらないものへのポインタ
プログラムの起動番地（ポインタ）

INT

プロセッサに自然なサイズの符号付き整数

43

µITRON4.0 仕様

Ver. 4.01.00

UINT

プロセッサに自然なサイズの符号無し整数

BOOL

真偽値（TRUE または FALSE）

FN
ER
ID
ATR
STAT
MODE
PRI
SIZE

機能コード（符号付き整数）
エラーコード（符号付き整数）
オブジェクトの ID 番号（符号付き整数）
オブジェクト属性（符号無し整数）
オブジェクトの状態（符号無し整数）
サービスコールの動作モード（符号無し整数）
優先度（符号付き整数）
メモリ領域のサイズ（符号無し整数）TMO
RELTIM
SYSTIM

タイムアウト指定（符号付き整数，時間単位は実装定義）
相対時間（符号無し整数，時間単位は実装定義）
システム時刻（符号無し整数，時間単位は実装定義）

VP_INT

データタイプが定まらないものへのポインタまたはプロセッサに自然なサイズの符号付き整数

ER_BOOL
ER_ID

エラーコードまたは真偽値（符号付き整数）
エラーコードまたは ID 番号（符号付き整数，負の ID 番
号は表現できない）
エラーコードまたは符号無し整数（符号付き整数，符号無し整数を表現する場合の有効ビット数は UINT より 1
ビット短い）ER_UINT

これらのデータ型の中で，VB，VH，VW，VD，VP_INTをどのような型に定義するかは実装依存である．これらのデータ型の変数に値を代入する場合や，変数の値を参照する場合には，明示的に型変換（キャスト）しなければならな
い．
また SYSTIMは，システム時刻の表現に必要なビット数が整数型として扱えるビット数よりも多い場合には，構造体として定義してもよい．構造体として定義する場合の構造体の内容については，実装定義とする．
【スタンダードプロファイル】
スタンダードプロファイルでは，ITRON仕様共通データ型の有効ビット数と時間単位を次の通りに定める．
INT
UINT

16 ビット以上
16 ビット以上

FN
ER
ID
ATR
STAT

16 ビット以上
8 ビット以上
16 ビット以上
8 ビット以上
16 ビット以上
44

µITRON4.0 仕様

Ver. 4.01.00

MODE
PRI
SIZE

8 ビット以上
16 ビット以上
ポインタと同じビット数

TMO
RELTIM
SYSTIM

16 ビット以上，時間単位は 1ミリ秒
16 ビット以上，時間単位は 1ミリ秒
16 ビット以上，時間単位は 1ミリ秒

【補足説明】
SIZEは，タスクのスタックサイズや可変長メモリプールの全体のサイズなど，
大きいメモリ領域のサイズを指定する場合に用いる．メッセージの長さなど，
小さいメモリ領域のサイズには UINT を用いる．
SYSTIMを構造体として定義した場合，通常の演算子（例えば，“+” や “–”）を使って SYSTIM型の値に対する演算を行うことができなくなる．このような場合にもアプリケーションプログラムの移植性を保つためには，SYSTIM型の値に対する演算は関数呼出しの形で記述し，各実装における SYSTIMの定義に合致した演算モジュールを用意するといった方法を採る必要がある．
ER_BOOL は負のエラーコードまたは真偽値（TRUE または FALSE），ER_ID
は負のエラーコードまたは正の ID 番号，ER_UINTは負のエラーコードまたは非負の整数値（有効ビット数は UINT より 1 ビット短い）を表すことのできるデータ型であり，いずれも符号付き整数に定義しなければならない．
【µITRON3.0 仕様との相違】
CYCTIME，ALMTIME，DLYTIME を RELTIMに統合し，SYSTIMEを SYSTIMに改名した．また，STAT，MODE，SIZE を新設した．複合データ型としては，BOOL_ID を廃止し，VP_INT， ER_BOOL，ER_ID，ER_UINTを新設した．メモリ領域のサイズは，符号無し整数で扱うことを原則とした．

2.3.2 ITRON仕様共通定数
ヘッダファイル itron.hは，以下のすべての ITRON仕様共通定数の定義を含まなければならない．
(1) 一般NULL

0

無効ポインタ

TRUE
FALSE

1
0

真
偽

E_OK

0

正常終了

【µITRON3.0 仕様との相違】
無効ポインタを，C 言語との整合性を重視して，NADR（＝ –1）から NULL（＝0）に変更した．

45

µITRON4.0 仕様

Ver. 4.01.00(2) メインエラーコード(A) 内部エラークラス（EC_SYS，–5〜 –8）
カーネルやソフトウェア部品の内部エラーのクラス．このエラークラスに属す
るエラーの検出は，実装依存で省略することができる．
E_SYS

–5

システムエラーカーネルやソフトウェア部品の内部で発生した原因不明のエラー．
(B) 未サポートエラークラス（EC_NOSPT， –9 〜 –16）
ITRON 仕様で規定されていないか，実装でサポートされていない機能であることを示すエラーのクラス．このエラークラスに属するエラーの検出は，実装定義で省略することができる．
E_NOSPT–9

未サポート機能ITRON 仕様では規定されているが，実装ではサポートされていない機能であることを示すエラー．サービスコールの一部ないしは全部の機能をサポートしていない場合に，このエラーを返す．E_RSFN，E_RSATRに該当する場合を除く．
E_RSFN–10

予約機能コード

ITRON 仕様で規定されていないか，実装でサポートしていない機能コードが指定されたことを示すエラー．ソフトウェア割込みによりサービス
コールを呼び出す場合に発生する．
E_RSATR–11

予約属性

ITRON 仕様で規定されていないか，実装でサポートしていない属性値であることを示すエラー．
(C) パラメータエラークラス（EC_PAR，–17〜 –24）
パラメータの値の不正を示すエラーで，ほぼ静的に検出できるもののクラス．
このエラークラスに属するエラーの検出は，実装定義で省略することができ
る．
E_PAR

–17

パラメータエラー

パラメータの値の不正を示すエラーで，ほぼ静的に検出できるもの．
E_IDに該当する場合を除く．
E_ID

–18

不正 ID番号

オブジェクトの ID 番号が使用できる範囲外であることを示すエラー．ID
番号で識別されるオブジェクトに対してのみ発生する．
(D) 呼出しコンテキストエラークラス（EC_CTX，–25 〜 –32）
サービスコールを呼び出したコンテキストに依存して発生するエラーのクラス．このエラークラスに属するエラーの検出は，実装定義で省略することがで
46

µITRON4.0 仕様

Ver. 4.01.00

きる．
E_CTX

–25

コンテキストエラー

サービスコールを呼び出したコンテキストが，そのサービスコールを呼び出せる状態にないことを示すエラー．E_MACV，E_OACV，E_ILUSEに該当する場合を除く．
E_MACV–26

メモリアクセス違反

サービスコール内でアクセスするメモリ領域として，サービスコールを呼び出したコンテキストからはアクセスできない領域が指定されたことを示すエラー．メモリのない領域が指定された場合にも，このエラーを返す．
E_OACV–27

オブジェクトアクセス違反

サービスコールでアクセスするオブジェクトとして，サービスコールを呼び出したコンテキストからはアクセスできないオブジェクトが指定されたことを示すエラー．オブジェクトをユーザオブジェクトとシステ
ムオブジェクトに分類している場合に，システムオブジェクトにアクセスできないコンテキストからシステムオブジェクトをアクセスしようとした時，このエラーを返す．
E_ILUSE–28

サービスコール不正使用

サービスコールの使用方法が正しくないことを示すエラーで，サービス
コールを呼び出したコンテキストや操作対象のオブジェクトの状態に依存して発生するもの．
(E) 資源不足エラークラス（EC_NOMEM，–33 〜 –40）
サービスコールの実行に必要な資源が不足していることを示すエラーのクラス．このエラークラスに属するエラーの検出は，省略することができない．
E_NOMEM

–33

メモリ不足

内部で動的にメモリ領域の確保を行うサービスコールで，必要なメモリ領域を確保できなかったことを示すエラー．
E_NOID–34

ID番号不足ID 番号の自動割付けを行うオブジェクト生成のサービスコールで，割付け可能な ID 番号がないことを示すエラー．
(F) オブジェクト状態エラークラス（ EC_OBJ，–41 〜 –48）
操作対象のオブジェクトの状態に依存して，サービスコールを実行できないことを示すエラーのクラス．操作対象のオブジェクトの状態によっては，同じ
サービスコール呼び出しでもエラーとなるとは限らないため，動的にチェックすることが必要である．このエラークラスに属するエラーの検出は，省略することができない．

47

µITRON4.0 仕様
E_OBJ

Ver. 4.01.00–41

オブジェクト状態エラー

操作対象のオブジェクトの状態に依存するエラーで，E_NOEXSE_QOVR に該当しないもの．
E_NOEXS–42とオブジェクト未生成

操作対象のオブジェクトが生成されていないために，アクセスできない
ことを示すエラー．このエラーが返るのは，オブジェクトの ID番号が使用できる範囲内である場合に限られるため，このエラーが返った ID番号を指定して，オブジェクトの生成を行うことができる．
E_QOVR–43

キューイングオーバフロー

キューイングまたはネスト可能なサービスコールで，その上限回数を超えたことを示すエラー．
(G) 待ち解除エラークラス（EC_RLWAI，–49 〜 –56）
サービスコールの中で一旦待ち状態に入った後，待ち状態が解除されたことを示すエラーのクラス．このエラークラスに属するエラーの検出は，省略することができない．
E_RLWAI–49

待ち状態の強制解除

待ち状態が強制解除された，または待ち状態にある処理がキャンセルされたことを示すエラー．
E_TMOUT–50

ポーリング失敗またはタイムアウト

タイムアウトが発生した，またはポーリングに失敗したことを示すエ
ラー．
E_DLT

–51

待ちオブジェクトの削除待つ対象となっているオブジェクトが削除されたことを示すエラー．
E_CLS

–52

待ちオブジェクトの状態変化

待つ対象となっているオブジェクトの状態変化により，そのサービス
コールを実行できない状態となったことを示すエラー．同様のオブジェ
クトの状態変化がサービスコール呼出し前に起こっていた場合，サービ
スコール中で待ち状態に入らずに，このエラーを返すことがある．
【補足説明】
E_CLSは，通信回線からのデータ受信を行うサービスコールで，受信待ちの間に回線が異常切断されたことを知らせる場合などに用いる．サービスコールを呼び出す前に回線が異常切断されていた場合にも，同じメインエラーコードを用いることができる．
(H) 警告クラス（EC_WARN，–57〜 –64）
処理を実行したが，注意すべき状況（警告を発すべき状況）が発生したことを示すエラーのクラス．このエラークラスに属するエラーは，「サービスコール
48

µITRON4.0 仕様

Ver. 4.01.00

でエラーが発生した場合には，サービスコールを呼び出したことによる副作用はない」という原則の例外となっている．このエラークラスに属するエラーの検出は，省略することができない．
E_WBLK–57

ノンブロッキング受付け

ノンブロッキング指定で呼び出したサービスコールの処理が継続していることを示すメインエラーコード．
E_BOVR–58

バッファオーバフロー

データをバッファに受け取ったが，バッファ領域に入らない部分を捨てたことを示すメインエラーコード．
(I) 予約エラーコード（–5 〜 –96で上に定義のないもの）
ITRON仕様の将来の拡張のために予約されているメインエラーコード．
(J) 実装独自エラーコード（ –97 〜 –128）
実装独自に定義するためのメインエラーコード．メインエラーコードの名称を
EV_XXXXX の形としなければならない．
【µITRON3.0 仕様との相違】
カーネル仕様の新機能のためのメインエラーコード（E_ILUSE，E_NOID）とソフトウェア部品仕様のためのメインエラーコード（E_CLS，E_WBLK，
E_BOVR）を追加し，接続機能用のエラーコード（EN_XXXXX）と ITRON/
FILE仕様専用のエラーコード（E_INOSPT）を削除した．メインエラーコードのエラークラスへの分類を一部見直し，値を割り付けなおした．この際に，メインエラーコードを下位 8 ビットとしたことから，8 ビットの符号付き整数として見た場合も負の値となるようにしている．また，エラー番号（errno）は廃止した．
(3) オブジェクト属性
TA_NULL

0

オブジェクト属性を指定しない

0
–1
–2

ポーリング
永久待ち
ノンブロッキング(4) タイムアウト指定
TMO_POL
TMO_FEVRTMO_NBLK

2.3.3 ITRON仕様共通マクロ
ヘッダファイル itron.hは，以下のすべての ITRON仕様共通マクロの定義を含まなければならない．

49

µITRON4.0 仕様

Ver. 4.01.00(1) エラーコード生成・分解マクロ
ER ercd = ERCD ( ER mercd, ER sercd )メインエラーコードとサブエラーコードからエラーコードを生成する．
ER mercd = MERCD ( ER ercd )エラーコードからメインエラーコードを取り出す．
ER sercd = SERCD ( ER ercd )エラーコードからサブエラーコードを取り出す．

2.3.4 ITRON仕様共通静的 API(1) ファイルのインクルード
INCLUDE ( 文字列 ) ;システムコンフィギュレーションファイルから，プリプロセッサ定数式パラメータおよび一般定数式パラメータの解釈に必要な C 言語の宣言・定義とプリ
プロセッサマクロの定義などを含んだファイルをインクルードするための指定．パラメータの文字列を，プリプロセッサの “#include”の後ろにそのまま置いて解釈できるように記述する．
【補足説明】ITRON 仕様共通静的 API の記述例を示す．
INCLUDE ( "<itron.h>" ) ;INCLUDE ( "\"memory.h\"" ) ;【仕様決定の理由】
パラメータを文字列としたのは，システムコンフィギュレーションファイルを最初にプリプロセッサを通す時に展開されないようにするためである．

50

µITRON4.0 仕様

Ver. 4.01.00

第 3 章 µITRON4.0 仕様の概念と共通
定義
3.1 基本的な用語の意味(1) タスクと自タスクプログラムの並行実行の単位を「タスク」と呼ぶ．すなわち，一つのタスク中のプログラムは逐次的に実行されるのに対して，異なるタスクのプログラムは並行して実行が行われる．ただし，並行して実行が行われるというのは，アプ
リケーションから見た概念的な動作であり，実装上はカーネルの制御のもとで，それぞれのタスクが時分割で実行される．
また，サービスコールを呼び出したタスクを「自タスク」と呼ぶ．
(2) ディスパッチとディスパッチャ
プロセッサが実行するタスクを切り替えることを「ディスパッチ」（または「タスクディスパッチ」）と呼ぶ．また，ディスパッチを実現するカーネル内の機構を「ディスパッチャ」（または「タスクディスパッチャ」）と呼ぶ．
(3) スケジューリングとスケジューラ
次に実行すべきタスクを決定する処理を「スケジューリング」（または「タス
クスケジューリング」）と呼ぶ．また，スケジューリングを実現するカーネル
内の機構を「スケジューラ」（または「タスクスケジューラ」）と呼ぶ．スケ
ジューラは，一般的な実装では，サービスコール処理の中やディスパッチャの中で実現される．
(4) コンテキスト
一般に，プログラムの実行される環境を「コンテキスト」と呼ぶ．コンテキス
トが同じというためには，少なくとも，プロセッサの動作モードが同一で，用いているスタック空間が同一（スタック領域が一連）でなければならない．ただし，コンテキストはアプリケーションから見た概念であり，独立したコンテ
キストで実行すべき処理であっても，実装上は同一のプロセッサ動作モードで同一のスタック空間で実行されることもある．
(5) 優先順位
処理が実行される順序を決める順序関係を「優先順位」と呼ぶ．優先順位の低い処理を実行中に，優先順位の高い処理が実行できる状態になった場合，優先順位の高い処理を先に実行するのが原則である．

51

µITRON4.0 仕様

Ver. 4.01.00【補足説明】
優先度は，タスクやメッセージの処理順序を制御するために，アプリケーショ
ンによって与えられるパラメータである．それに対して優先順位は，仕様中で処理の実行順序を明確にするために用いる概念である．タスク間の優先順位
は，タスクの優先度に基づいて定められる．

3.2 タスク状態とスケジューリング規則
3.2.1 タスク状態
タスク状態は，大きく次の 5つに分類される．この内，広義の待ち状態は，さらに 3つの状態に分類される．また，実行状態と実行可能状態を総称して，実行できる状態と呼ぶ．
(a) 実行状態（RUNNING）
現在そのタスクを実行中であるという状態．ただし，非タスクコンテキス
トを実行している間は，別に規定されている場合を除いて，非タスクコン
テキストの実行を開始する前に実行していたタスクが実行状態であるものとする．
(b) 実行可能状態（READY）
そのタスクを実行する準備は整っているが，そのタスクよりも優先順位の高いタスクが実行中であるために，そのタスクを実行できない状態．言い換えると，実行できる状態のタスクの中で最高の優先順位になればいつでも実行できる状態．
(c) 広義の待ち状態
そのタスクを実行できる条件が整わないために，実行ができない状態．言い換えると，何らかの条件が満たされるのを待っている状態．タスクが広義の待ち状態にある間，プログラムカウンタやレジスタなどのプログラムの実行状態を表現する情報は保存されている．タスクを広義の待ち状態から実行再開する時には，プログラムカウンタやレジスタなどを広義の待ち状態になる直前の値に戻す．広義の待ち状態は，さらに次の 3つの状態に分類される．
(c.1) 待ち状態（WAITING）
何らかの条件が整うまで自タスクの実行を中断するサービスコールを呼び出したことにより，実行が中断された状態．
(c.2) 強制待ち状態（SUSPENDED）
他の タス ク によ って，強 制的 に 実行 を中 断 させ られ た状 態．た だしµITRON4.0 仕様では，自タスクを強制待ち状態にすることもできる．
(c.3) 二重待ち状態（WAITING-SUSPENDED）
待ち状態と強制待ち状態が重なった状態．待ち状態にあるタスクに対して，
52

µITRON4.0 仕様

Ver. 4.01.00

強制待ち状態への移行が要求されると，二重待ち状態に移行させる．
(d) 休止状態（DORMANT）
タスクがまだ起動されていないか，実行を終了した後の状態．タスクが休止状態にある間は，実行状態を表現する情報は保存されていない．タスク
を休止状態から起動する時には，タスクの起動番地から実行を開始する．また，別に規定されている場合を除いて，レジスタの内容は保証されない．
(e) 未登録状態（NON-EXISTENT）
タスクがまだ生成されていないか，削除された後の，システムに登録されていない仮想的な状態．
実装によっては，以上のいずれにも分類されない過渡的な状態が存在する場合がある（3.5.6 節参照）．
実行可能状態に移行したタスクが，現在実行中のタスクよりも高い優先順位を持つ場合には，実行可能状態への移行と同時にディスパッチが起こり，即座に実行状態へ移行する場合がある．この場合，それまで実行状態であったタスク
は，新たに実行状態へ移行したタスクにプリエンプトされたという．また，
サービスコールの機能説明などで，「実行可能状態に移行させる」と記述されている場合でも，タスクの優先順位によっては，即座に実行状態に移行させる
場合もある．
タスクの起動とは，休止状態のタスクを実行可能状態に移行させることをいう．このことから，休止状態と未登録状態以外の状態を総称して，起動された状態と呼ぶことがある．タスクの終了とは，起動された状態のタスクを休止状態に移行させることをいう．
タスクの待ち解除とは，タスクが待ち状態の時は実行可能状態に，二重待ち状
態の時は強制待ち状態に移行させることをいう．また，タスクの強制待ちからの再開とは，タスクが強制待ち状態の時は実行可能状態に，二重待ち状態の時は待ち状態に移行させることをいう．
一般的な実装におけるタスクの状態遷移を図 3-1 に示す．実装によっては，この図にない状態遷移を行う場合がある．
【補足説明】
待ち状態と強制待ち状態は直交関係にあり，強制待ち状態への移行の要求は，タスクの待ち解除条件には影響を与えない．言い換えると，タスクが待ち状態にあるか二重待ち状態にあるかで，タスクの待ち解除条件は変化しない．そのため，資源獲得のための待ち状態（セマフォ資源の獲得待ち状態やメモリブ
ロックの獲得待ち状態など）にあるタスクに強制待ち状態への移行が要求され，二重待ち状態になった場合にも，強制待ち状態への移行が要求されなかった場合と同じ条件で資源の割付け（セマフォ資源やメモリブロックの割付けなど）が行われる．
【µITRON3.0 仕様との相違】
タスク状態の英語名を，形容詞形に統一した．具体的には，実行状態を RUNか53

µITRON4.0 仕様

Ver. 4.01.00

ディスパッチ

実行可能状態
READY

プリエンプト
待ち
解除

待ち

待ち状態
WAITING
強制待ち

再開

二重待ち状態WAITINGSUSPENDED
待ち解除
強制待ち
再開

起動
強制終了

AAAA
AAAA
AAAA
AAAA
AAAA
AAAA
AAAA
AAAA
AAAA
AAAA

実行状態
RUNNING

強制待ち状態SUSPENDED

休止状態
DORMANT

強制待ち

強制終了
終了

AAAAA
AAAAA
AAAAA
削除

生成

未登録状態
NON-EXISTENT

終了と削除

図 3-1. タスクの状態遷移
ら RUNNING に，待ち状態を WAIT から WAITINGに，強制待ち状態を SUSPENDから S U S P E N D E Dに，二 重待ち状態 を WA I T- S U S P E N Dから
WAITING-SUSPENDEDに変更した．
自タスクを強制待ち状態にすることができることとした．これは，自タスクによる待ちと他のタスクによる待ちを区別しない API（ POSIX スレッドや Java スレッドなどの API）のインタフェーサを，µITRON4.0 仕様のカーネル上に実装するのを容易にするためである．
【仕様決定の理由】
ITRON 仕様において待ち状態（自タスクによる待ち）と強制待ち状態（他のタスクによる待ち）を区別しているのは，それらが重なる場合があるためである．それらが重なった状態を二重待ち状態として区別することで，タスクの状
態遷移が明確になり，サービスコールの理解が容易になる．それに対して，待ち状態のタスクはサービスコールを呼び出せないため，複数の種類の待ち状態
54

µITRON4.0 仕様

Ver. 4.01.00（例えば，起床待ち状態とセマフォ資源の獲得待ち状態）が重なることはない．
ITRON仕様では，他のタスクによる待ちには一つの種類（強制待ち状態）しかないため，強制待ち状態が重なった状況を強制待ち要求のネストと扱うこと
で，タスクの状態遷移を明確にしている．

3.2.2 タスクのスケジューリング規則
ITRON仕様においては，タスクに与えられた優先度に基づくプリエンプティブ
な優先度ベーススケジューリング方式を採用している．同じ優先度を持つタス
ク間では，FCFS（First Come First Served）方式によりスケジューリングを行う．
具体的には，タスクのスケジューリング規則はタスク間の優先順位を用いて，タスク間の優先順位はタスクの優先度によって，それぞれ次のように規定される．
実行できるタスクが複数ある場合には，その中で最も優先順位の高いタスクが実行状態となり，他は実行可能状態となる．タスク間の優先順位は，異なる優先度を持つタスク間では，高い優先度を持つタスクの方が高い優先順位を持
つ．同じ優先度を持つタスク間では，先に実行できる状態（実行状態または実行可能状態）になったタスクの方が高い優先順位を持つ．ただし，サービス
コールの呼出しにより，同じ優先度を持つタスク間の優先順位が変更される場
合がある．
最も高い優先順位を持つタスクが替わった場合には，ただちにディスパッチが起こり，実行状態のタスクが切り替わる．ただし，ディスパッチが起こらない状態になっている場合には，実行状態のタスクの切替えは，ディスパッチが起こる状態となるまで保留される．
【補足説明】ITRON仕様のスケジューリング規則では，優先順位の高いタスクが実行できる状態にある限り，それより優先順位の低いタスクは全く実行されない．すなわ
ち，最も高い優先順位を持つタスクが待ち状態に入るなどの理由で実行できな
い状態とならない限り，他のタスクは全く実行されない．この点で，複数のタ
スクを公平に実行しようという TSS（Time Sharing System）のスケジューリン
グ方式とは根本的に異なっている．ただし，同じ優先度を持つタスク間の優先順位は，サービスコールを用いて変更することが可能である．アプリケーショ
ンがそのようなサービスコールを用いて，TSSにおける代表的なスケジューリ
ング方式であるラウンドロビン方式を実現することができる．
同じ優先度を持つタスク間では，先に実行できる状態（実行状態または実行可能状態）になったタスクの方が高い優先順位を持つことを，図 3-2 の例を用いて説明する．図 3-2 (a)は，優先度 1 のタスク A，優先度 3 のタスク E，優先度 2のタスク B，タスク C，タスク D がこの順序で起動された後のタスク間の優先順位を示す．この状態では，最も優先順位の高いタスク Aが実行状態となっている．

55

µITRON4.0 仕様

Ver. 4.01.00

優先順位
優先度1

タスクA

優先度2

タスクB

優先度3

タスクE

タスクC

タスクD

(a) 最初の状態の優先順位
優先順位
優先度2

タスクB

優先度3

タスクE

タスクC

タスクD

(b) タスクBが実行状態になった後の優先順位
優先順位
優先度2

タスクC

優先度3

タスクE

タスクD

(c) タスクBが待ち状態になった後の優先順位
優先順位
優先度2

タスクC

優先度3

タスクE

タスクD

タスクB

(d) タスクBが待ち解除された後の優先順位
図 3-2. タスク間の優先順位
ここでタスク A が終了すると，次に優先順位の高いタスク Bを実行状態に遷移させる（図 3-2 (b)）．その後タスク A が再び起動されると，タスク Bはプリエンプトされて実行可能状態に戻るが，この時タスク Bは，タスク C とタスク Dのいずれよりも先に実行できる状態になっていたことから，同じ優先度を持つタ
スクの中で最高の優先順位を持つことになる．すなわち，タスク間の優先順位
は図 3-2 (a)の状態に戻る．
次に，図 3-2 (b)の状態でタスク B が待ち状態になった場合を考える．タスクの56

µITRON4.0 仕様

Ver. 4.01.00

優先順位は実行できるタスクの間で定義されるため，タスク間の優先順位は図3-2 (c) の状態となる．その後タスク B が待ち解除されると，タスク Bはタスク
C とタスク Dのいずれよりも後に実行できる状態になったことから，同じ優先度を持つタスクの中で最低の優先順位となる（図 3-2 (d)）．
以上を整理すると，実行可能状態のタスクが実行状態になった後に実行可能状態に戻った直後には，同じ優先度を持つタスクの中で最高の優先順位を持っているのに対して，実行状態のタスクが待ち状態になった後に待ち解除されて実行できる状態になった直後には，同じ優先度を持つタスクの中で最低の優先順
位となる．
【µITRON3.0 仕様との相違】
レディキューは実装上の概念であるため，仕様の説明には，レディキューに代
えて優先順位という用語を用いることにした．
タスクが強制待ち状態から実行可能状態に移行した時に，同じ優先度内で最低の優先順位になるものとした．これは，実装依存性を削減するためである．

3.3 割込み処理モデル
3.3.1 割込みハンドラと割込みサービスルーチンµITRON4.0 仕様では，外部割込み（以下，単に割込みと呼ぶ）によって起動される処理として，割込みハンドラと割込みサービスルーチンがある．
割込みハンドラは，プロセッサの機能のみに依存して起動することを基本とする．したがって，割込みコントローラ（IRC；Interrupt Request Controller）の操
作は，カーネルではなく，割込みハンドラで行う．割込みハンドラの記述方法
は，一般にはプロセッサの割込みアーキテクチャや用いる IRCなどに依存するため，実装定義とする．割込みハンドラをそのままの形で異なるシステムに移植することはできない．
それに対して割込みサービスルーチンは，割込みハンドラから起動するルーチ
ンで，プロセッサの割込みアーキテクチャや用いる IRCなどに依存せずに記述することができる．すなわち，IRCの操作は割込みサービスルーチンを起動す
る割込みハンドラで行われ，割込みサービスルーチンでは IRCを操作する必要はない．
µITRON4.0 仕様では，アプリケーションが用意した割込みハンドラを登録するための API（DEF_INH など）と，割込みサービスルーチンを登録するためのAPI（ATT_ISR など）の両方を規定しており，実装ではそのいずれかの APIを提供すればよい．割込みハンドラを登録するための API を提供する場合，割込
みハンドラの起動の前後に行うべき処理を含むルーチン（これを，割込みハン
ドラの出入口処理と呼ぶ）をカーネルで用意し，割込みハンドラ属性によっては，用意した出入口処理を経由して割込みハンドラを起動することができる．
割込みサービスルーチンを登録するための APIのみを提供する場合には，割込
57

µITRON4.0 仕様

Ver. 4.01.00

みサービスルーチンを起動する割込みハンドラは，カーネルが用意する．また，両方の API を提供することも可能であるが，その場合，両方の API を併用した場合の振舞いは実装定義とする．
カーネルは，ある優先度よりも高い優先度を持つ割込み（禁止できない割込みを含む）を，管理しないものとすることができる．このような割込みを，カーネルの管理外の割込みと呼ぶ．どの優先度より高い優先度を持つものをカーネルの管理外の割込みとするかは，実装定義である．カーネルの管理外の割込みによって起動される割込みハンドラからは，カーネルのサービスコールを呼び出すことができない．この仕様書で，割込み（ないしは，割込みハンドラ）という場合には，カーネルの管理外の割込み（ないしは，それによって起動される割込みハンドラ）は含まないものとする．
図 3-3 に µITRON4.0 仕様における割込み処理の概念モデルを示す．ただし，この図はあくまでも概念モデルを示すものであり，実際の実現方法は実装やアプ
リケーション毎に自由に決定することができる．

割込みハンドラの
出入口処理
外部割込み

割込み
ハンドラ
IRC の操作

割込みサービス
ルーチン
A

B

リターン
タスクディスパッチ

図 3-3. 割込み処理モデル【補足説明】
割込みハンドラの出入口処理で必要な処理として，割込みハンドラ内で使用するレジスタの保存と復帰，スタックの切替え，タスクディスパッチ処理，プロ
セッサレベルでの割込みハンドラからの復帰が挙げられる．この中で実際にどの処理が必要かは，場合によって異なる．また，これらの処理の中で，どれをカーネルが用意する出入口処理で行い，どれをアプリケーションが登録する割込みハンドラで行わなければならないとするかは，実装定義である（割込みハ58

µITRON4.0 仕様

Ver. 4.01.00

ンドラ属性によっても異なる）．
割込みサービスルーチンを起動する際に，割込みハンドラで行わなければならない IRC の操作として，IRCからの割込み要因の取り出し，取り出した割込み
要因による分岐，IRC のエッジトリガのクリア，IRC の割込みサービス中フラグのクリアが挙げられる．また，割込みサービスルーチンを起動する前に，CPU
ロック解除状態にすることが必要である．
割込みサービスルーチンを起動する際のオーバヘッドを削減するために，割込
みハンドラの出入口処理と割込みハンドラを一体で用意する方法や，割込みハ
ンドラ内に割込みサービスルーチンをインライン展開する方法を採ることができる．
【スタンダードプロファイル】
スタンダードプロファイルでは，割込みハンドラを登録するための APIと割込
みサービスルーチンを登録するための APIのいずれかをサポートしなければな
らない．
【仕様決定の理由】
アプリケーションの割込み処理部分の移植性を向上させるために，割込みハン
ドラよりも高い移植性を持つ割込みサービスルーチンを導入した．一方，移植性の低い割込みハンドラを残したのは，用いる IRCに依存しない形でカーネルを提供できるようにするためである．

3.3.2 割込みの指定方法と割込みサービスルーチンの起動µITRON4.0 仕様では，割込みを指定するための方法として，割込み番号と割込
みハンドラ番号の 2つがある．また，割込みサービスルーチンは，ID番号で識別される．
割込みハンドラ番号（INHNO 型）は，割込みハンドラを登録する際に，割込
みハンドラを登録する対象となる割込みを指定するために用いる番号である．
指定された割込みは，IRCを操作しない範囲で判別できるのが基本であること
から，一般的な実装では，プロセッサの割込みベクトル番号に対応する．割込
みベクトルを持たないプロセッサにおいては，指定することができる割込みハ
ンドラ番号は一つのみとなる場合もある．
割込み番号（INTNO 型）は，割込みサービスルーチンを登録する際に，割込
みサービスルーチンを登録する対象となる割込みを指定するために用いる番号である．また，割込み番号は，割込みを個別に禁止／許可するためのサービ
スコール（dis_int，ena_int）で，禁止／許可の対象となる割込みを指定するためにも用いられる．割込みサービスルーチンの起動や，割込みの個別の禁止／許可は，IRC を操作して実現することを想定していることから，一般的な実装では，割込み番号は IRCへの割込み要求入力ラインに対応する．
割込みサービスルーチンは，デバイスからの割込み要求ラインに対応して用意するのを基本とする．IRC への一つの割込み要求入力ラインには，複数のデバ
59

µITRON4.0 仕様

Ver. 4.01.00

イスからの割込み要求が接続される場合があるため，一つの割込み番号に対して複数の割込みサービスルーチンを登録することができる．割込み番号で指定された割込みが発生した場合には，その割込み番号に対して登録されたすべての割込みサービスルーチンを順に起動する．割込みサービスルーチンを起動する順序は実装依存である．一つの割込み番号に対して登録された複数の割込みサービスルーチンを区別するために，割込みサービスルーチンは ID 番号を用いて識別する．
【補足説明】
IRCの一つの割込み要求入力ラインに複数のデバイスからの割込み要求が接続されていても，割込みを要求したデバイスがプロセッサに割込みベクトル番号を供給する場合には，プロセッサレベルで割込み要因を判別することができる．このような場合，異なる割込みベクトル番号を供給する割込みは，異なる
割込み番号を持つものと解釈することができる．

3.4 例外処理モデル
3.4.1 例外処理の枠組みµITRON4.0 仕様では，例外処理のための機能として，CPU例外ハンドラとタス
ク例外処理の機能を規定する．
CPU 例外ハンドラは，プロセッサが検出する CPU 例外によって起動される．
CPU例外ハンドラは，CPU例外の種類毎に，アプリケーションで登録することができる．CPU例外ハンドラの起動の前後に行うべき処理を含むルーチン（これを，CPU 例外ハンドラの出入口処理と呼ぶ）をカーネルで用意し，CPU例外
ハンドラ属性によっては，用意した出入口処理を経由して CPU例外ハンドラを起動することができる．
同一の CPU例外に対する CPU例外ハンドラはシステム全体で共通であるため，必要でCPU例外ハンドラ内で CPU 例外が発生したコンテキストや状態を調べ，あればタスク例外処理機能を用いて CPU 例外が発生したタスクに例外処理を任せることができる．
タスク例外処理機能は，タスクを指定してタスク例外処理を要求するサービス
コールを呼び出すことで，指定したタスクに実行中の処理を中断させ，タスク
例外処理ルーチンを実行させるための機能である．タスク例外処理ルーチンの実行は，タスクと同じコンテキストで行われる．タスク例外処理ルーチンから
リターンすると，中断された処理の実行が継続される．タスク毎に一つのタス
ク例外処理ルーチンを，アプリケーションで登録することができる．タスク例
外処理機能については，4.3 節で述べる．
【スタンダードプロファイル】
スタンダードプロファイルでは，CPU例外ハンドラとタスク例外処理ルーチン

60

µITRON4.0 仕様

Ver. 4.01.00をサポートしなければならない．

3.4.2 CPU 例外ハンドラで行える操作
CPU 例外ハンドラの記述方法は，一般にはプロセッサの CPU 例外アーキテク
チャやカーネルの実装などに依存するため，実装定義とする．CPU例外ハンド
ラをそのままの形で異なるシステムに移植することはできない．
CPU 例外ハンドラ内で呼出し可能なサービスコールは実装定義である．ただし，CPU例外ハンドラ内で次の操作を行う方法を用意しなければならない．これらの操作を行う方法も，実装定義である．
(a) CPU 例外が発生したコンテキストや状態の読出し．具体的には，CPU 例外が発生した処理で sns_yyy を呼び出した場合の結果を，CPU例外ハンドラ
内で取り出せること．
(b) CPU例外が発生したタスクの ID番号の読出し（例外を発生させたのがタスクである場合のみ）．
(c) タスク例外処理の要求．具体的には，CPU 例外ハンドラ内で，ras_texと同等の操作ができること．
ここで，CPUロック状態で CPU 例外が発生した場合には，(b) および (c)の操作ができることは要求されない．

3.5 コンテキストとシステム状態
3.5.1 処理単位とコンテキストµITRON4.0 仕様のカーネルは，次の処理単位の実行制御を行う．
(a) 割込みハンドラ(a.1) 割込みサービスルーチン(b) タイムイベントハンドラ(c) CPU 例外ハンドラ(d) 拡張サービスコールルーチン(e) タスク(e.1) タスク例外処理ルーチン
割込みハンドラおよび割込みサービスルーチンは，それぞれ独立したコンテキ
ストで実行される．以下この節では，割込みサービスルーチンに関する記述が別にない限りは，割込みハンドラに関する記述は割込みサービスルーチンにも適用される．
タイムイベントハンドラは，時間をきっかけとして起動される処理で，周期ハンドラ，アラームハンドラ，オーバランハンドラの 3つの種類がある．タイム
イベントハンドラは，それぞれ独立したコンテキストで実行される．周期ハンドラについては 4.7.2 節，アラームハンドラについては 4.7.3 節，オーバランハ
61

µITRON4.0 仕様

Ver. 4.01.00

ンドラについては 4.7.4 節で述べる．
CPU 例外ハンドラは，ハンドラ毎および CPU 例外が発生したコンテキスト毎に，それぞれ独立したコンテキストで実行される．
拡張サービスコールルーチンは，拡張サービスコールの呼出しにより起動される処理で，アプリケーションによって登録される．拡張サービスコールルーチ
ンは，ルーチン毎および拡張サービスコールが呼び出されたコンテキスト毎に，それぞれ独立したコンテキストで実行される．拡張サービスコールルーチ
ンについては，4.10 節で述べる．
タスクは，それぞれ独立したコンテキストで実行される．タスク例外処理ルー
チンは，そのタスクのコンテキスト内で実行される．以下この節では，タスク
例外処理ルーチンに関する記述が別にない限りは，タスクに関する記述はタス
ク例外処理ルーチンにも適用される．
以上の処理単位に分類されない処理として，カーネル自身の処理がある．カー
ネルの処理は，サービスコール処理，ディスパッチャ，割込みハンドラ（または割込みサービスルーチン）と CPU例外ハンドラの出入口処理などから構成される．カーネルが実行されるコンテキストは，アプリケーションの振舞いには影響しないため，特に規定しない．
【µITRON3.0 仕様との相違】
タイマハンドラに代えて，タイムイベントハンドラという用語を用いることにした．また，拡張 SVC ハンドラに代えて，拡張サービスコールルーチンという用語を用いることにした．

3.5.2 タスクコンテキストと非タスクコンテキスト
タスクの処理の一部とみなすことのできるコンテキストを総称してタスクコ
ンテキスト，そうでないコンテキストを総称して非タスクコンテキストと呼ぶ．
タスクの実行されるコンテキストは，タスクコンテキストに分類される．割込
みハンドラおよびタイムイベントハンドラが実行されるコンテキストは，非タ
スクコンテキストに分類される．CPU例外ハンドラおよび拡張サービスコール
ルーチンが実行されるコンテキストがいずれに分類されるかは，それぞれ，CPU 例外が発生したコンテキストおよび拡張サービスコールが呼び出されたコンテキストに依存して，次のように定められる．
タスクコンテキストを実行中に CPU例外が発生した場合には，CPU例外ハンド
ラが実行されるコンテキストがタスクコンテキストと非タスクコンテキストのいずれに分類されるかは実装定義とする．非タスクコンテキストを実行中にCPU例外が発生した場合には，CPU例外ハンドラが実行されるコンテキストは
非タスクコンテキストに分類される．
タスクコンテキストから拡張サービスコールを呼び出した場合には，拡張サービスコールルーチンが実行されるコンテキストはタスクコンテキストに分類
62

µITRON4.0 仕様

Ver. 4.01.00

される．非タスクコンテキストから拡張サービスコールを呼び出した場合には，拡張サービスコールルーチンが実行されるコンテキストは非タスクコンテ
キストに分類される．
µITRON4.0 仕様では，タスクコンテキストから呼び出すサービスコールと，非タスクコンテキストから呼び出すサービスコールを区別して扱う．非タスクコ
ンテキストからのサービスコール呼出しについては，3.6 節で述べる．
非タスクコンテキストから，暗黙で自タスクを指定するサービスコールや，自タスクを広義の待ち状態にする可能性のあるサービスコールが呼び出された
場合には，E_CTX エラーを返す．また，サービスコールに渡すパラメータとして，自タスクを指定する TSK_SELF（＝ 0）を用いることもできない．渡された場合には，E_IDエラーとなる．
【補足説明】
3.5.3 節で述べるように，CPU例外ハンドラの優先順位はディスパッチャよりも高いため，CPU 例外ハンドラ実行中はディスパッチが起こらない．そのため，
CPU例外ハンドラがタスクコンテキストで実行される実装で，CPU例外ハンド
ラ内で自タスクを広義の待ち状態にする可能性のあるサービスコールを呼出し可能とした場合であっても，その振舞いはこの仕様上は未定義である．エ
ラーを報告する場合には，E_CTX エラーを返す．
【µITRON3.0 仕様との相違】
タスク部とタスク独立部に代えて，それぞれタスクコンテキストと非タスクコ
ンテキストという用語を用いることとした．カーネルが実行されるコンテキス
トは規定していないため，過渡的な状態という用語は用いていない．また，µITRON4.0 仕様ではプロセッサの動作モードについて規定していないため，準タスク部の概念は定義せず，タスクコンテキストに含まれるものとした．

3.5.3 処理の優先順位とサービスコールの不可分性µITRON4.0 仕様のカーネルが，各処理単位とディスパッチャを実行する優先順
位は次のように規定される．
各処理単位とディスパッチャの間では，次の順序で優先順位が高い．
(1) 割込みハンドラ，タイムイベントハンドラ，CPU例外ハンドラ(2) ディスパッチャ（カーネルの処理の一部）(3) タスク
割込みハンドラの優先順位は，ディスパッチャの優先順位よりも高い．割込み
ハンドラおよび割込みサービスルーチン相互間の優先順位は，それらを起動する外部割込みの優先度に対応して定めることを基本に，実装定義で定める．
タイムイベントハンドラの優先順位は，isig_timを呼び出した割込みハンドラの優先順位以下で，ディスパッチャの優先順位よりも高いという範囲内で，実装定義で定める．

63

µITRON4.0 仕様

Ver. 4.01.00

CPU例外ハンドラの優先順位は，CPU例外が発生した処理の優先順位と，ディ
スパッチャの優先順位のいずれよりも高い．割込みハンドラやタイムイベント
ハンドラとの間の優先順位は，実装定義である．
拡張サービスコールルーチンの優先順位は，拡張サービスコールを呼び出した処理の優先順位よりも高く，拡張サービスコールを呼び出した処理よりも高い
優先順位を持つ他のいずれの処理の優先順位よりも低い．
タスクの優先順位は，ディスパッチャの優先順位よりも低い．タスク相互間の優先順位は，タスクのスケジューリング規則によって定められる．
カーネルのサービスコール処理は不可分に実行され，サービスコール処理の途中の状態がアプリケーションから見えないのが基本であるが，システムの応答性を向上させるために，サービスコール処理の途中でアプリケーションプログ
ラムが実行される実装も認める．この場合にも，別に規定されている場合を除いて，アプリケーションがサービスコールを用いて観測できる範囲で，サービスコールが不可分に実行された場合と同様に振る舞わなければならない．このように振る舞わせることを，サービスコールの不可分性を保証するという．ただし，実装独自の機能を追加する場合には，実装方式によっては高い応答性を保ちつつサービスコールの不可分性を保証することが難しい場合が考えられる．そのような場合には，サービスコールの不可分性の原則を緩めることを認める．
カーネルのサービスコール処理が不可分に実行される場合には，サービスコー
ル処理は最も高い優先順位を持つことになるが，上述の理由から，サービス
コール処理の優先順位は，サービスコールを呼び出した処理の優先順位よりも高いという条件を満たす範囲で，実装依存とする．
サービスコール処理以外のカーネルの処理（ディスパッチャ，割込みハンドラと CPU例外ハンドラの出入口処理など）も，サービスコール処理と同様とする．
【スタンダードプロファイル】
スタンダードプロファイルに準拠する実装では，スタンダードプロファイル機能の範囲内で，サービスコールの不可分性を保証しなければならない．
【補足説明】
ディスパッチャの優先順位は割込みハンドラの優先順位よりも低いため，すべての割込みハンドラの処理を終えるまで，ディスパッチは起こらない．これを，従来の仕様では遅延ディスパッチの原則と呼んでいた．タイムイベントハ
ンドラ，CPU例外ハンドラについても同様である．

3.5.4 CPUロック状態
システムは，CPU ロック状態か CPU ロック解除状態かのいずれかの状態をとる．CPU ロック状態では，割込みハンドラ（カーネルの管理外の割込みによって起動されるものを除く）やタイムイベントハンドラは起動されず，ディスパッチも起こらない．CPU ロック状態は，実行中の処理の優先順位が，他のい64

µITRON4.0 仕様

Ver. 4.01.00

ずれの処理よりも高くなった状態とみなすこともできる．実装によっては，
CPU ロック状態と CPU ロック解除状態のどちらにも該当しない過渡的な状態が存在する場合がある．
CPU ロック状態に移行することを「CPU ロックする」，CPUロック解除状態に移行することを「CPUロックを解除する」ともいう．
CPUロック状態では，以下のサービスコールを呼び出すことができる．
loc_cpu／ iloc_cpu
unl_cpu／ iunl_cpu
sns_ctx
sns_loc
sns_dspsns_dpnsns_tex

CPUロック状態への移行
CPUロック状態の解除
コンテキストの参照
CPUロック状態の参照
ディスパッチ禁止状態の参照
ディスパッチ保留状態の参照
タスク例外処理禁止状態の参照

ここで，loc_cpu／ iloc_cpuは，タスクコンテキストからは loc_cpu，非タス
クコンテキストからはiloc_cpuを呼び出せることを示す（unl_cpu／iunl_cpuについても同様）．CPU ロック状態で，これら以外のサービスコールが呼び出された場合には，E_CTX エラーを返す．
割込みハンドラの実行開始直後に，CPU ロック状態・CPU ロック解除状態・どちらにも該当しない過渡的な状態のいずれになっているかは実装依存である．
ただし，割込みハンドラ内で CPU ロック解除状態にするための方法を，実装定義で用意することが必要である．また，CPU ロック解除状態にした後に，割込
みハンドラから正しくリターンするための方法も実装定義とする．実装で規定されている方法に従わずにリターンした場合の振舞いは未定義である．割込み
ハンドラからのリターン直後は，CPUロック解除状態になる．
割込みサービスルーチンとタイムイベントハンドラの実行開始直後は，CPU
ロック解除状態になっている．アプリケーションは，これらのルーチン／ハン
ドラからリターンする前に，CPU ロック解除状態にしなければならない．CPU
ロック状態でこれらのルーチン／ハンドラからリターンした場合の振舞いは未定義である．これらのルーチン／ハンドラからのリターン直後は，CPUロッ
ク解除状態になる．
CPU例外ハンドラの起動とそこからのリターンによって，CPUロック／ロック
解除状態は変化しない．アプリケーションは，CPU 例外ハンドラ内で CPUロック／ロック解除状態を変化させた場合，CPU例外ハンドラからリターンする前に元の状態に戻さなければならない．元の状態に戻さずに CPU例外ハンドラからリターンした場合の振舞いは未定義である．
拡張サービスコールルーチンの起動とそこからのリターンによって，CPUロック／ロック解除状態は変化しない．
タスクの実行開始直後は，CPUロック解除状態になっている．アプリケーショ
ンは，自タスクを終了させる前に，CPU ロック解除状態にしなければならな
い．CPUロック状態で自タスクを終了させた場合の振舞いは未定義である．
65

µITRON4.0 仕様

Ver. 4.01.00

タスク例外処理ルーチンの起動とそこからのリターンによって，CPUロック／
ロック解除状態は変化しない．ただし，CPUロック状態でタスク例外処理ルーチンが起動されるかどうかは，この仕様上は規定されない．アプリケーション
は，タスク例外処理ルーチン内で CPUロック／ロック解除状態を変化させた場
合，タスク例外処理ルーチンからリターンする前に元の状態に戻さなければならない．元の状態に戻さずにタスク例外処理ルーチンからリターンした場合の振舞いは未定義である．
【補足説明】
CPUロック解除状態であっても，割込みが許可されているとは限らない．
「CPU 例外ハンドラの起動とそこからのリターンによって，CPU ロック／ロッ
ク解除状態は変化しない」とは，次のことを意味する．すなわち，CPU例外ハンドラの実行開始直後は，CPU例外が CPU ロック状態で発生した場合には CPU
ロック状態，CPU ロック解除状態で発生した場合には CPU ロック解除状態になっている．また，CPU例外ハンドラからのリターン直後は，CPU例外ハンド
ラから CPU ロック状態でリターンした場合には CPU ロック状態，CPU ロック解除状態でリターンした場合には CPU ロック解除状態になる．拡張サービス
コールルーチンとタスク例外処理ルーチンについても，これと同様である．
【µITRON3.0 仕様との相違】
CPUロック／ロック解除状態の意味を変更した．具体的には，CPUロック状態
を，割込みとタスクディスパッチが禁止された状態と考えていたのを，それらとは概念的には独立した状態と扱うことにした．また，CPU ロック状態では，一部の例外を除いてサービスコールを呼び出せないのを基本とした．

3.5.5 ディスパッチ禁止状態
システムは，ディスパッチ禁止状態かディスパッチ許可状態かのいずれかの状態をとる．ディスパッチ禁止状態では，ディスパッチは起こらない．ディス
パッチ禁止状態は，実行中の処理の優先順位が，ディスパッチャよりも高くなった状態とみなすこともできる．実装によっては，ディスパッチ禁止状態とディスパッチ許可状態のどちらにも該当しない過渡的な状態が存在する場合がある．
ディスパッチ禁止状態に移行することを「ディスパッチを禁止する」，ディス
パッチ許可状態に移行することを「ディスパッチを許可する」ともいう．
ディスパッチ禁止状態では，タスクコンテキストから呼び出せるサービスコー
ルに次の制限がある．すなわち，別に規定されている場合を除いて，ディスパッチ禁止状態で自タスクを広義の待ち状態にする可能性のあるサービス
コールが呼び出された場合には，E_CTX エラーを返す．それに対して，非タ
スクコンテキストから呼び出せるサービスコールは，ディスパッチ禁止状態でも制限を受けない．
割込みハンドラ，割込みサービスルーチン，タイムイベントハンドラ，CPU例
66

µITRON4.0 仕様

Ver. 4.01.00

外ハンドラの起動と，それらからのリターンによって，ディスパッチ禁止／許可状態は変化しない．アプリケーションは，これらのハンドラ／ルーチン内でディスパッチ禁止／許可状態を変化させた場合，ハンドラ／ルーチンからリターンする前に元の状態に戻さなければならない．元の状態に戻さずにハンドラ／ルーチンからリターンした場合の振舞いは未定義である．
拡張サービスコールルーチンの起動とそこからのリターンによって，ディスパッチ禁止／許可状態は変化しない．
タスクの実行開始直後は，ディスパッチ許可状態になっている．アプリケー
ションは，自タスクを終了させる前に，ディスパッチ許可状態にしなければならない．ディスパッチ禁止状態で自タスクを終了させた場合の振舞いは未定義
である．
タスク例外処理ルーチンの起動と，そこからのリターンによって，ディスパッ
チ禁止／許可状態は変化しない．
ディスパッチ禁止／許可状態は，CPUロック／ロック解除状態とは独立に管理される．
【補足説明】
ディスパッチ禁止状態から自タスクを広義の待ち状態にする可能性のあるサービスコールが呼び出された場合の振舞いを未定義とする制限は，別に規定されている場合を除いて，サービスコール単位に適用される．具体的には，
ポーリングを行うサービスコール（例えば pol_sem）は，自タスクを待ち状態にする可能性がないため，ディスパッチ禁止状態でも呼び出すことができる．
それ に 対 して，待 ち 状態 に 入 る可 能 性 のあ る サー ビ ス コー ル（例 えば
twai_sem）は，タイムアウト時間に TMO_POL（ポーリング）を指定して呼び出した場合でも，その振舞いは未定義である．
「割込みハンドラの起動とそこからのリターンによって，ディスパッチ禁止／
許可状態は変化しない」とは，次のことを意味する．すなわち，割込みハンド
ラの実行開始直後は，割込みがディスパッチ禁止状態で発生した場合にはディスパッチ禁止状態，ディスパッチ許可状態で発生した場合にはディスパッチ許可状態になっている．また，割込みハンドラからのリターン直後は，割込みハンドラからディスパッチ禁止状態でリターンした場合にはディスパッチ禁止
状態，ディスパッチ許可状態でリターンした場合にはディスパッチ許可状態になる．割込みサービスルーチン，タイムイベントハンドラ，CPU 例外ハンドラ，拡張サービスコールルーチン，タスク例外処理ルーチンについても，これと同様である．
非タスクコンテキストからディスパッチ禁止／許可状態を変更するためのサービスコールは，µITRON4.0 仕様では用意されていない．そのため，実装独自の拡張を行わない限りは，割込みハンドラやタイムイベントハンドラ内でディスパッチ禁止／許可状態を変化させることはできない．CPU例外ハンドラ
が非タスクコンテキストで実行される場合には，CPU例外ハンドラについても同様である．
67

µITRON4.0 仕様

Ver. 4.01.00

ディスパッチ禁止／許可状態は CPUロック状態と独立に管理されるため，例えば，ディスパッチ禁止状態で CPU ロック状態に移行し，その後 CPU ロックを解除しても，ディスパッチ禁止状態は保持されている．また，CPUロック状態
でも，ディスパッチ禁止状態かディスパッチ許可状態かを参照することができる．
【µITRON3.0 仕様との相違】
ディスパッチ禁止状態の意味を変更した．具体的には，ディスパッチ禁止状態
を，CPUロック状態とは独立に管理される状態とした．

3.5.6 ディスパッチ保留状態の間のタスク状態
ディスパッチャよりも優先順位の高い処理が実行されている間，CPUロック状
態の間，およびディスパッチ禁止状態の間は，ディスパッチが起こらない．この状態をディスパッチ保留状態と呼び，その間のタスク状態については次のよ
うに定める．
ディスパッチ保留状態では，実行中のタスクがプリエンプトされるべき状況となっても，新たに実行すべき状態となったタスクにはディスパッチされない．
実行すべきタスクへのディスパッチは，ディスパッチが起こる状態となるまで保留される．ディスパッチが保留されている間は，それまで実行中であったタスクが実行状態であり，ディスパッチが起こる状態となった後に実行すべきタ
スクは実行可能状態である．
また，実装独自に，非タスクコンテキストから実行中のタスクを強制待ち状態
や休止状態に移行させるサービスコールを追加した場合や，ディスパッチ禁止
状態で自タスクを強制待ち状態に移行させるサービスコールを呼出し可能とした場合には，ディスパッチ保留状態の間のタスク状態について次のように定める．
ディスパッチ保留状態で，実行中のタスクを強制待ち状態や休止状態へ移行させようとした場合，タスクの状態遷移はディスパッチが起こる状態となるまで保留される．状態遷移が保留されている間は，それまで実行中であったタスク
は過渡的な状態にあると考え，その具体的な扱いは実装依存とする．一方，ディスパッチが起こる状態となった後に実行すべきタスクは，実行可能状態である．
【補足説明】
ディスパッチ保留状態の間のタスク状態を，図 3-4 の例を用いて説明する．タ
スク A の実行中に発生した割込みによって起動された割込みハンドラから，タスク A よりも高い優先度を持つタスク Bが起動された場合を考える．割込みハ
ンドラの優先順位はディスパッチャの優先順位より高いため，割込みハンドラが実行されている間はディスパッチ保留状態であり，ディスパッチは起こらな
い．割込みハンドラの実行が終了すると，ディスパッチャを実行し，実行するタスクをタスク A からタスク Bに切り替える．
68

µITRON4.0 仕様

Ver. 4.01.00

実行可能状態

ディスパ
ッチャ

割込み
ハンドラ

iact_tsk(タスクB)

実行状態

実行可能状態

実行状態

タスクB
タスクA
（優先度低） （優先度高）

図 3-4. ディスパッチ保留状態とタスク状態
割込みハンドラ内でタスク Bが起動された後も，ディスパッチャが実行されるまでの間はタスク A が実行状態であり，タスク B は実行可能状態である．ディ
スパッチャの実行後は，タスク B が実行状態，タスク Aが実行可能状態となる．
なお，ディスパッチャの実行は不可分に行われるのが原則であり，その間のタスク状態は，この仕様上は規定されない．

3.6 非タスクコンテキストからのサービスコール呼出し
3.6.1 非タスクコンテキストから呼び出せるサービスコール
どのコンテキストからでも呼び出せる一部のサービスコールを除いては，非タ
スクコンテキストから呼び出せるサービスコールはサービスコール名に “i” の文字を付加することとし，タスクコンテキストから呼び出せるサービスコールと区別する．言い換えると，サービスコールは次の 3つに分類することができる．
(a) 非タスクコンテキスト専用のサービスコール
サービスコール名が “i” で始まるサービスコールを，非タスクコンテキスト専用のサービスコールと呼び，名前の通り，非タスクコンテキストから呼び出すことができる．
非タスクコンテキスト専用のサービスコールがタスクコンテキストから呼び出された場合には，E_CTX エラーを返す．

69

µITRON4.0 仕様

Ver. 4.01.00【補足説明】
具体的には，次のサービスコールがこれに該当する．
iact_tsk
iwup_tsk
irel_waiiras_tex
isig_sem
iset_flg
ipsnd_dtq
ifsnd_dtq
isig_tim
irot_rdq
iget_tid
iloc_cpu
iunl_cpu

タスクの起動タスクの起床待ち状態の強制解除
タスク例外処理の要求
セマフォ資源の返却
イベントフラグのセット
データキューへの送信（ポーリング）
データキューへの強制送信
タイムティックの供給
タスクの実行順位の回転
実行状態のタスク ID の参照
CPUロック状態への移行
CPUロック状態の解除(b) どのコンテキストからでも呼び出せるサービスコール
どのコンテキストから
サービスコール名が sns_yyy の形のサービスコールは，
でも呼び出すことができる．すなわち，タスクコンテキスト，非タスクコンテ
キストのいずれからも呼び出すことができる．
【補足説明】
具体的には，次のサービスコールがこれに該当する．
sns_ctx
sns_loc
sns_dspsns_dpnsns_tex

コンテキストの参照
CPUロック状態の参照
ディスパッチ禁止状態の参照
ディスパッチ保留状態の参照
タスク例外処理禁止状態の参照(c) タスクコンテキスト専用のサービスコール
その他のサービスコールを，タスクコンテキスト専用のサービスコールと呼び，名前の通り，タスクコンテキストから呼び出すことができる．
タスクコンテキスト専用のサービスコールが非タスクコンテキストから呼び出された場合には，E_CTXエラーを返す．
【補足説明】
実装独自の拡張として，（同等の機能を持つ非タスクコンテキスト専用のサービスコールが用意されていないサービスコールに対して）非タスクコンテキス
ト専用のサービスコールを追加すること，非タスクコンテキスト専用のサービ
スコールをタスクコンテキストからも呼び出せるようにすること，タスクコン
テキスト専用のサービスコールを非タスクコンテキストからも呼び出せるよ
うにすることは，いずれも許される．詳しくは，3.6.3 節を参照すること．

70

µITRON4.0 仕様

Ver. 4.01.00【µITRON3.0 仕様との相違】
非タスクコンテキスト専用のサービスコールを，“i”で始まる名称にすることを規定した．また，どのサービスコールに対してそれと同等の機能を持つ非タス
クコンテキスト専用のサービスコールを用意するかを明確に規定し，機能コードは規定したサービスコールに対してのみ割り付けた．そのため，µITRON3.0
仕様で機能コードを割り付けた非タスクコンテキスト専用のサービスコールのいくつかに対して，µITRON4.0 仕様では機能コードを割り付けていない．

3.6.2 サービスコールの遅延実行
長い割込み禁止区間を設けずにサービスコールの不可分性を保証することを可能にするために，非タスクコンテキストから呼び出されたサービスコールの実行を，最大限，ディスパッチャよりも高い優先順位を持つ処理の実行が終わるまで遅延することができる．これを，サービスコールの遅延実行と呼ぶ．
ただし，次のサービスコールを遅延実行することは許されない．
iget_tid
iloc_cpu
iunl_cpu
sns_ctx
sns_loc
sns_dspsns_dpnsns_tex

実行状態のタスク ID の参照
CPUロック状態への移行
CPUロック状態の解除
コンテキストの参照
CPUロック状態の参照
ディスパッチ禁止状態の参照
ディスパッチ保留状態の参照
タスク例外処理禁止状態の参照

サービスコールを遅延実行する場合にも，遅延実行することを許されないもの
を除いて，サービスコールの実行順序がサービスコールの呼び出された順序に一致しなければならない．
遅延実行を認めた結果，非タスクコンテキストから呼び出したサービスコール
に対して，操作対象のオブジェクトの状態に依存して発生するエラーをサービ
スコール呼出し時に検出できなくなり，遅延実行しない場合と同じエラーコー
ドを返せなくなる場合がある．このような場合には，遅延実行しない場合に返るエラーコードに代えて，E_OK を返すことができる．実際にどのようなエ
ラー時にエラーコードを返すことを省略できるかは，サービスコール毎に定める．
サービスコールを遅延実行するために，遅延実行すべきサービスコールを記憶しておく必要がある．そのためのメモリ領域が不足した場合には，サービス
コールは E_NOMEM エラーを返さなければならない．
【補足説明】
サービスコールの実行を実際にどの時点まで遅延させるかは，仕様において規定された振舞いと同じ振舞いをする限りは自由である．具体的には，ディスパッチ保留状態で呼び出されたサービスコールの実行を，ディスパッチが起こ
71

µITRON4.0 仕様

Ver. 4.01.00

る状態となるまで遅延できる場合がある．ただし iras_tex については，ディス
パッチ禁止状態でも実行しなければならない場合があるので，注意が必要である（詳しくは，iras_texの機能説明を参照）．
遅延実行されるサービスコールが E_OK を返した場合，後でそのサービスコー
ルの処理を呼び出すことを保証しなければならない．
【µITRON3.0 仕様との相違】
サービスコールの遅延実行に関して明確に規定することとした．

3.6.3 呼び出せるサービスコールの追加µITRON4.0 仕様に xxx_yyy（または zxxx_yyy）という名称のタスクコンテキ
スト専用のサービスコールが用意されている場合で，非タスクコンテキストから呼び出せるそれと同等の機能のサービスコールを実装独自に追加する場合には，実装独自に追加するサービスコール名称の原則（サービスコール名称の前に “v” を付加する）にかかわらず，ixxx_yyy（または izxxx_yyy）の名称とする．非タスクコンテキストから呼び出したサービスコールの遅延実行により，一部のエラーコードを返すことを省略する場合にも，同等の機能であるとみなす．
また，実装独自の拡張として，タスクコンテキスト専用のサービスコールをそのままの名称で非タスクコンテキストからも呼び出せるようにした場合，呼び出せるようにしたサービスコール名の前に “i” の文字を付加した名称のサービ
スコールを，非タスクコンテキストから呼び出せるようにしなければならな
い．逆に，非タスクコンテキスト専用のサービスコールをそのままの名称でタ
スクコンテキストからも呼び出せるようにした場合，呼び出せるようにした
サービスコール名の先頭の “i” を外した名称のサービスコールを，タスクコン
テキストから呼び出せるようにしなければならない．
これらの規則は，実装独自のサービスコールにも同様に適用される．vxxx_yyyという名称のサービスコールを実装独自に用意した場合で，非タスクコンテキ
ストからもそれと同等の機能を持つサービスコールを呼び出せるようにする
場合には，少なくとも ivxxx_yyyという名称で呼び出せるようにしなければならない．
【補足説明】
3.6.1 節で，タスクコンテキスト専用のサービスコールが非タスクコンテキスト
から呼び出された場合には，E_CTXエラーを返すと規定している．それにもかかわらず，実装独自の拡張として，タスクコンテキスト専用のサービスコール
を非タスクコンテキストからも呼び出せるようにすることが許されるのは，次の理由による．
E_CTX エラーの検出は，実装定義で省略することができる（2.3.2 節）．一方，エラーの検出を省略したことにより，本来検出すべきエラーを検出できなかった場合の振舞いは，仕様上は未定義である（2.1.6 節）．仕様上は未定義の事項
72

µITRON4.0 仕様

Ver. 4.01.00

を実装独自に規定することは許されるため，タスクコンテキスト専用のサービ
スコールが非タスクコンテキストから呼び出された場合の振舞いを，実装独自に定めることは許される．そのため，実装独自の拡張として，タスクコンテキ
スト専用のサービスコールを非タスクコンテキストから呼び出せるようにすることは許される．
非タスクコンテキスト専用のサービスコールをタスクコンテキストから呼び出せるようにすることが許されるのも，同じ理由による．

3.7 システム初期化手順
システム初期化手順は，次のようにモデル化される（図 3-5）．

リセット

ハードウェア依存の初期化処理

カーネル自身の初期化処理

静的 API の処理
・オブジェクトの登録
・初期化ルーチンの実行

カーネルの動作開始
・システム時刻を初期化
・割込みを許可・タスクの実行を開始

図 3-5. システム初期化手順
システムがリセットされると，最初に，ハードウェア依存の初期化処理を行う．ハードウェア依存の初期化処理はカーネルの管理外であり，アプリケー
ションで用意する．ハードウェア依存の初期化処理の最後で，カーネルの初期化処理を呼び出す．カーネルの初期化処理を呼び出す方法は，実装定義である．
カーネルの初期化処理が呼び出されると，まずカーネル自身の初期化処理（カーネル内のデータ構造の初期化など）を行い，次に静的 API の処理（オブジェクトの登録など）を行う．ATT_INI 以外の静的 API の処理は，システムコ
ンフィギュレーションファイル中に記述された順序で行う．静的 APIの処理中

73

µITRON4.0 仕様

Ver. 4.01.00にエラーを検出した場合の扱いについては，実装定義とする．
静的 APIの処理には，初期化ルーチンの実行も含まれる．初期化ルーチンはア
プリケーションで用意され，ATT_INI を使ってカーネルに登録される．初期化
ルーチンは，カーネルの管理外の割込みを除くすべての割込みを禁止した状態で実行する．カーネルの管理外の割込みを禁止するかどうかは，実装定義である．また，初期化ルーチン内でサービスコールを呼び出せるか否か，呼び出せる場合にはどのようなサービスコールが呼び出せるかも，実装定義である．初期化ルーチンは，システムコンフィギュレーションファイル中に ATT_INIの記
述のある順序で実行する．初期化ルーチンの実行と，他の静的 APIの処理との順序関係は，実装依存である．
静的 APIの処理が終了すると，カーネルの動作を開始する．すなわち，タスクの実行を開始する．また，この時点で初めて割込みを許可する．システム時刻
は，この時点を時刻 0 とする．
以上はあくまでも概念モデルを示すものであり，実際のシステム初期化手順
は，この概念モデルと同じ振舞いをする限りは，実装依存に最適化することができる．

3.8 オブジェクトの登録とその解除
ID 番号で識 別されるオブ ジェクトは，オ ブジェクトを 生成する静 的 API（CRE_YYY）またはサービスコール（cre_yyy）によってカーネルに登録され，オブジェクトを削除するサービスコール（ del_yyy）によってその登録が解除される．オブジェクトが削除された後は，同じ ID 番号で新しくオブジェクトを生成することができる．オブジェクト生成時には，生成するオブジェクトのID番号と生成に必要な情報を指定する．オブジェクト削除時には，削除するオ
ブジェクトの ID 番号を指定する．
カーネルに登録できるオブジェクトの最大数や ID 番号の範囲は，実装定義である．また，サービスコールを用いて生成できるオブジェクトの最大数や ID番
号の範囲の指定方法も，実装定義である．
オブジェクトを追加する静的 API（ATT_YYY）は，オブジェクトの ID 番号を指定せずにオブジェクトを生成し，カーネルに追加登録する．生成したオブ
ジェクトは ID 番号を持たないため，この方法で登録したオブジェクトを ID 番号を指定して操作することはできない．そのため，この方法で生成したオブ
ジェクトは削除することができない．
ID 番号の自動割付けを行うオブジェクト生成のサービスコール（acre_yyy）
は，生成するオブジェクトの ID 番号を，オブジェクトが登録されていない ID
番号の中から割り付ける．生成したオブジェクトに割り付けた ID番号は，サービスコールの返値としてアプリケーションに返される．サービスコールの返値が負の値の場合はエラーの発生を意味するため，この方法で割り付ける ID 番
号は正の値に限定される．割り付けることができる ID 番号がない場合には，
74

µITRON4.0 仕様

Ver. 4.01.00

サービスコールは E_NOID エラーを返す．
自動割付けされる ID 番号の範囲の指定方法は，実装定義である．また，オブジェクトが登録されていない ID 番号の中から，生成するオブジェクトに ID 番
号を割り付ける方法は，実装依存とする．
同期・通信オブジェクトの削除は，そのオブジェクトにおいて条件成立を待っているタスクがある場合にも行うことができる．この場合，削除されるオブジェクトにおいて条件成立を待っているタスクは待ち解除する．また，待ち解除されたタスクに対しては，待ち状態に入ったサービスコールの返値として
E_DLT エラーを返す．条件成立を待っているタスクが複数ある場合には，同期・通信オブジェクトの待ち行列につながれていた順序で待ち解除する．そのため，実行可能状態に移行したタスクで同じ優先度を持つものの間では，待ち行列の中で前につながれていたタスクの方が高い優先順位を持つことになる．
同期・通信オブジェクトが複数の待ち行列を持つ場合には，異なる待ち行列で条件成立を待っていたタスクの間では，待ち解除する順序は実装依存である．
【スタンダードプロファイル】
スタンダードプロファイルでは，少なくとも 1〜 255 の範囲の ID番号をサポー
トしなけければならない．また，スタンダードプロファイルでサポートしなけ
ればならない ID 番号で識別されるオブジェクトについては，少なくとも 255個のオブジェクトを登録できることが必要である．

3.9 処理単位の記述形式µITRON4.0 仕様では，割込みサービスルーチン，タイムイベントハンドラ（周期ハンドラ，アラームハンドラ，オーバランハンドラ），拡張サービスコール
ルーチン，タスク，タスク例外処理ルーチンの各処理単位を C言語で記述する
場合の形式を規定する．処理単位をカーネルに登録する際のオブジェクト属性に TA_HLNG（高級言語用のインタフェースで処理単位を起動）が指定された場合には，規定された形式で記述されているものと仮定して処理単位を起動する．
それに対して，これらの処理単位をアセンブリ言語で記述する方法について
は，実装定義とする．処理単位をカーネルに登録する際のオブジェクト属性に
TA_ASM（アセンブリ言語用のインタフェースで処理単位を起動）が指定された場合には，実装毎に規定された形式で記述されているものと仮定して処理単位を起動する．
割込みハンドラおよび CPU例外ハンドラを記述する方法と，これらをカーネルに登録する場合のオブジェクト属性の指定方法については実装定義とし，µITRON4.0 仕様では規定しない．
【補足説明】µITRON4.0 仕様では，割込みハンドラからリターンするためのサービスコール
75

µITRON4.0 仕様

Ver. 4.01.00（従来の仕様では，ret_int）について規定していない．これは，割込みハンド
ラの記述方法を実装定義としたためで，従来の仕様で ret_int が行っていた処理が不要になったわけではない．実装によっては，割込みハンドラを記述する
ために，ret_int に相当するサービスコールが用意される場合もある． CPU 例
外ハンドラからのリターンについても，これと同様である．
また µITRON4.0 仕様では，タイムイベントハンドラからリターンするためのサービスコール（従来の仕様では，ret_tmr）についても規定していない．これは，C 言語でタイムイベントハンドラを記述する場合には，関数からの単なるリターンによりタイムイベントハンドラからリターンできるものと定めた
ためで，従来の仕様でret_tmrが行っていた処理が不要になったわけではない．
実装によっては，アセンブリ言語でタイムイベントハンドラを記述するために，ret_tmrに相当するサービスコールが用意される場合もある．割込みサー
ビスルーチン，拡張サービスコールルーチン，タスク例外処理ルーチンからのリターンについても，これと同様である．
【µITRON3.0 仕様との相違】µITRON4.0 仕様では，各処理単位を C 言語で記述する場合の形式を規定し，処理単位からリターンするためのサービスコール（ret_yyy）については，処理単位をアセンブリ言語で記述する場合にのみ必要なものであることから，規定しないこととした．

3.10 カーネル構成定数／マクロ
カーネル構成定数／マクロは，アプリケーションプログラムの移植性を向上させることを目的に，アプリケーションプログラムからカーネルの構成を参照す
るために用いるものである．カーネル構成定数／マクロは，アプリケーション
プログラムから参照できるようになっていれば，どのように定義するかは実装依存である．
カーネル構成定数／マクロは，それに関連する機能をサポートしていない場合には定義しない．
【補足説明】
カーネル構成定数／マクロを定義する方法として，カーネルのヘッダファイル
中で固定的に定義する方法や，コンフィギュレータによって定義を生成する方法が考えられる．また，アプリケーションが用意するヘッダファイルでカーネ
ル構成定数／マクロを定義し，その情報を使ってカーネルを生成する方法もある．
【µITRON3.0 仕様との相違】
カーネル構成定数／マクロは，µITRON4.0 仕様において新たに導入した機能である．

76

µITRON4.0 仕様

Ver. 4.01.00

3.11 カーネル共通定義
3.11.1 カーネル共通定数(1) オブジェクト属性
TA_HLNG
TA_ASM

0x00
0x01

高級言語用のインタフェースで処理単位を起動
アセンブリ言語用のインタフェースで処理単位
を起動

TA_TFIFO
TA_TPRI

0x00
0x01

タスクの待ち行列を FIFO 順に
タスクの待ち行列をタスクの優先度順に

TA_MFIFO
TA_MPRI

0x00
0x02

メッセージのキューを FIFO 順に
メッセージのキューをメッセージの優先度順に【µITRON3.0 仕様との相違】
TA_HLNG と TA_ASM の値を逆にした．
(2) カーネルで用いるメインエラーコード
カーネルでは，2.3.2節に規定されているメインエラーコードの中で，E_CLS，
E_WBLK，E_BOVR の 3つを除いたメインエラーコードを用いる．
【スタンダードプロファイル】
スタンダードプロファイルで発生し，検出しなければならないメインエラー
コードは次の通りである．
E_OBJ
E_QOVR
E_RLWAIE_TMOUT

オブジェクト状態エラー
キューイングオーバフロー
待ち状態の強制解除
ポーリング失敗またはタイムアウト

スタンダードプロファイルに準拠したカーネル上でポータビリティを確保したいアプリケーションは，上に挙げた以外のメインエラーコードが検出されることに依存してはならない．
【補足説明】
スタンダードプロファイルで発生しないか，検出を省略することができるメイ
ンエラーコードは，次の通りである．
(a) カーネルでは使用しないもの
E_CLS， E_WBLK，E_BOVR(b) スタンダードプロファイルの機能では発生しないもの
E_OACV， E_NOID，E_NOEXS，E_DLT(c) 発生するかどうかは実装に依存するもの
E_SYS，E_RSFN，E_NOMEM
77

µITRON4.0 仕様

Ver. 4.01.00(d) 検出を省略することができるもの
E_NOSPT，E_RSATR，E_PAR，E_ID，E_CTX，E_MACV，E_ILUSE(3) サービスコールの機能コード
カーネルのサービスコールには，(–0xe0) 〜 (–0x05) の範囲の機能コードを割り付ける．ただし，cal_svc には機能コードを割り付けない．機能コードの具体的な割付けは，第 4 章において機能単位毎に規定する．
(–0xe0) 〜 (–0x05) の範囲の機能コードで，この仕様で割り付けられていないものは，将来のカーネルの機能拡張のために予約されている．(–0x100) 〜 (–0xe1)の範囲の機能コードは，実装独自のサービスコールに用いることができる．(–
0x200) 〜 (–0x101)の範囲の機能コードは，将来のカーネルの機能拡張のために予約されているが，必要であれば実装独自のサービスコールに用いてもよいものとする．
【µITRON3.0 仕様との相違】
機能コードの値を割り付けなおした．
【仕様決定の理由】
スタンダードプロファイルに含まれるサービスコールの機能コードを (–0x80)〜 (–0x05) の範囲としているが，これは，8ビットで表現できるようにするためである．
(4) その他のカーネル共通定数
TSK_SELF
TSK_NONE00

自タスク指定該当するタスクが無い【µITRON3.0 仕様との相違】
TSK_NONE を新たに導入した．µITRON3.0 仕様では．該当するタスクが無い
場合には FALSE（＝ 0）を用いている．

3.11.2 カーネル共通構成定数(1) 優先度の範囲
TMIN_TPRI
TMAX_TPRI

タスク優先度の最小値（＝ 1）
タスク優先度の最大値

TMIN_MPRI
TMAX_MPRI

メッセージ優先度の最小値（＝ 1）
メッセージ優先度の最大値【スタンダードプロファイル】
スタンダードプロファイルでは，これらのカーネル構成定数を定義しなければならない．また，TMAX_TPRIは 16 以上，TMAX_MPRI は TMAX_TPRI以上でなければならない．
78

µITRON4.0 仕様

Ver. 4.01.00【補足説明】
TMIN_TPRI と TMIN_MPRIは，この仕様上は 1 に固定されているが，実装独自の拡張として，1以外の値でカーネルを構成できるようにすることは許される．
(2) バージョン情報
TKERNEL_MAKER
TKERNEL_PRID
TKERNEL_SPVER
TKERNEL_PRVER

カーネルのメーカコード
カーネルの識別番号
ITRON仕様のバージョン番号
カーネルのバージョン番号【スタンダードプロファイル】
スタンダードプロファイルでは，これらのカーネル構成定数を定義しなければならない．
【補足説明】
バージョン情報をあらわす定数値の意味については，ref_ver の機能説明を参照すること．

79

µITRON4.0 仕様

Ver. 4.01.00

80µITRON4.0 仕様

Ver. 4.01.00

第 4 章 µITRON4.0 仕様の機能
4.1 タスク管理機能
タスク管理機能は，タスクの状態を直接的に操作／参照するための機能である．タスクを生成／削除する機能，タスクを起動／終了する機能，タスクに対する起動要求をキャンセルする機能，タスクの優先度を変更する機能，タスクの状態を参照する機能が含まれる．タスクは ID 番号で識別されるオブジェク
トである．タスクの ID 番号をタスク ID と呼ぶ．タスク状態とスケジューリン
グ規則については，3.2 節を参照すること．
タスクは，実行順序を制御するために，ベース優先度と現在優先度を持つ．単にタスクの優先度といった場合には，タスクの現在優先度を指す．タスクのベース優先度は，タスクの起動時にタスクの起動時優先度に初期化する．
ミューテックス機能を使わない場合には，タスクの現在優先度は常にベース優
先度に一致している．そのため，タスク起動直後の現在優先度は，タスクの起動時優先度になっている．ミューテックス機能を使う場合に現在優先度がどのように設定されるかについては，4.5.1 節で述べる．
タスクに対する起動要求は，キューイングされる．すなわち，すでに起動されているタスクを再度起動しようとすると，そのタスクを起動しようとしたという記録が残り，後でそのタスクが終了した時に，タスクを自動的に再起動する．ただし，起動コードを指定してタスクを起動するサービスコール（ sta_tsk）
では，起動要求はキューイングされない．タスクに対する起動要求のキューイングを実現するために，タスクは起動要求キューイング数を持つ．タスクの起動要求キューイング数は，タスクの生成時に 0にクリアする．
タスクを起動する際には，そのタスクの拡張情報（exinf）をパラメータとして渡す．ただし，起動コードを指定してタスクを起動するサービスコール（sta_tsk）によってタスクが起動された場合には，拡張情報に代えて，指定された起動コードを渡す．
カーネルは，タスクの終了時に，ミューテックスのロック解除を除いては，タスクが獲得した資源（セマフォ資源，メモリブロックなど）を解放する処理を行わない．タスク終了時に資源を解放するのは，アプリケーションの責任である．
タスクの生成時，起動時，終了時，削除時には，それぞれ次のような処理を行う必要がある．タスクの生成時に行うべき処理には，タスクの起動要求キュー
イング数のクリア，タスク例外処理ルーチンの定義されていない状態への初期化（4.3節参照），上限プロセッサ時間の設定されていない状態への初期化（ 4.7.4
節参照）が含まれる．タスクの起動時に行うべき処理には，タスクのベース優
先度（および現在優先度）の初期化，起床要求キューイング数のクリア（ 4.2
節参照），強制待ち要求ネスト数のクリア（ 4.2 節参照），保留例外要因のクリ
81

µITRON4.0 仕様

Ver. 4.01.00

ア（4.3 節参照）
，タスク例外処理禁止状態への設定（4.3節参照）が含まれる．
タスクの終了時に行うべき処理には，タスクがロックしているミューテックスのロック解除（4.5.1節参照），タスクの上限プロセッサ時間の設定の解除（4.7.4
節参照）が含まれる．タスクの削除時に行うべき処理には，タスクのスタック
領域の解放（スタック領域をカーネルで確保した場合のみ）が含まれる．
タスクの C 言語による記述形式は次の通りとする．
void task ( VP_INT exinf ){タスク本体
ext_tsk ( ) ;}タスクのメインルーチンからリターンした場合には，ext_tsk を呼び出した場
合と同じ振舞いをする（すなわちタスクを終了する）．また，exd_tsk を呼び出して，タスクの終了と同時にタスクを削除することもできる．
タスク管理機能に関連して，次のカーネル構成定数を定義する．
TMAX_ACTCNT

タスクの起動要求キューイング数の最大値

タスク生成情報およびタスク状態のパケット形式として，次のデータ型を定義
する．
typedef struct t_ctsk {ATRtskatr ;VP_INT
exinf ;
FP
task ;
PRI
itskpri ;SIZEstksz ;/* タスク属性 *//* タスクの拡張情報 *//* タスクの起動番地 *//* タスクの起動時優先度 *//* タスクのスタックサイズ（バイト
数）*/
VP
stk ;
/* タスクのスタック領域の先頭番地 *//* 実装独自に他のフィールドを追加してもよい */} T_CTSK ;typedef struct t_rtsk {STAT
tskstat ;/* タスク状態 */PRI
tskpri ;/* タスクの現在優先度 */PRI
tskbpri ;/* タスクのベース優先度 */STAT
tskwait ; /* 待ち要因 */ID
wobjid ;/* 待ち対象のオブジェクトの ID番号 */TMO
lefttmo ;/* タイムアウトするまでの時間 */UINT
actcnt ;/* 起動要求キューイング数 */UINTwupcnt ; /* 起床要求キューイング数 */UINTsuscnt ;/* 強制待ち要求ネスト数 *//* 実装独自に他のフィールドを追加してもよい */} T_RTSK ;typedef struct t_rtst {STAT
tskstat ;/* タスク状態 */STAT
tskwait ; /* 待ち要因 *//* 実装独自に他のフィールドを追加してもよい */} T_RTST ;82

µITRON4.0 仕様

Ver. 4.01.00

タスク管理機能の各サービスコールの機能コードは次の通りである．
TFN_CRE_TSK
TFN_ACRE_TSK
TFN_DEL_TSK
TFN_ACT_TSK
TFN_IACT_TSK
TFN_CAN_ACT
TFN_STA_TSK
TFN_EXT_TSK
TFN_EXD_TSK
TFN_TER_TSK
TFN_CHG_PRI
TFN_GET_PRI
TFN_REF_TSK
TFN_REF_TST

–0x05
–0xc1
–0x06
–0x07
–0x71
–0x08
–0x09
–0x0a
–0x0b
–0x0c
–0x0d
–0x0e
–0x0f
–0x10

cre_tskの機能コード
acre_tskの機能コード
del_tsk の機能コード
act_tskの機能コード
iact_tsk の機能コード
can_actの機能コード
sta_tskの機能コード
ext_tskの機能コード
exd_tskの機能コード
ter_tsk の機能コード
chg_priの機能コード
get_pri の機能コード
ref_tskの機能コード
ref_tstの機能コード【スタンダードプロファイル】
スタ ン ダー ドプ ロ ファ イル では，タ ス クを 動的 に 生成 ／削 除 する 機能（cre_tsk，acre_tsk，del_tsk），起動コードを指定してタスクを起動する機能（sta_tsk），タスクを終了と同時に削除する機能（exd_tsk），タスクの状態を参照する機能（ref_tsk， ref_tst）を除いて，タスク管理機能をサポートしなければならない．
スタンダードプロファイルでは，少なくとも 1回のタスクの起動要求キューイ
ングをサポートしなければならない．したがって，TMAX_ACTCNT は 1 以上でなければならない．
【補足説明】
タスクを実行するコンテキストと状態については，次のように整理できる．
• タスクは，それぞれ独立したコンテキストで実行する（ 3.5.1 節参照）
．タス
クを実行するコンテキストは，タスクコンテキストに分類される（3.5.2節参照）．
• タスクの優先順位は，ディスパッチャの優先順位よりも低い（3.5.3節参照）．
• タスクの実行開始直後は，CPUロック解除状態かつディスパッチ許可状態になっている．自タスクを終了する際には，CPU ロック解除状態かつディス
パッチ許可状態にしなければならない（ 3.5.4 節と 3.5.5節を参照）．
タスクの起動要求キューイングをサポートしない場合には， TMAX_ACTCNT
は 0とする．
【µITRON3.0 仕様との相違】
タスクに対して直接操作を行う機能で，広義の待ち状態とは関係しないもののみをタスク管理機能に分類することにした．具体的には，タスクの優先順位を回転する機能（rot_rdq），実行状態のタスク IDを参照する機能（ get_tid），タ
83

µITRON4.0 仕様

Ver. 4.01.00

スクディスパッチを禁止／許可する機能（dis_dsp，ena_dsp）をシステム状
態管理機能に分類した．また，タスクの待ち状態を強制解除する機能（rel_wai）
をタスク付属同期機能に分類した．
タスクに対する起動要求をキューイングする機能を追加し，それをサポートするためのサービスコール（act_tsk，can_tsk）を新設した．起動コードを指定してタスクを起動するサービスコール（sta_tsk）は，µITRON3.0 仕様との互換性のために残した（スタンダードプロファイル外）．
ミューテックスの導入に伴って，タスクのベース優先度の概念を新たに導入した．ただし，ミューテックス機能を使わない場合には，タスクの現在優先度は
常にベース優先度に一致しており，実質的な変化はない．
タスクのメインルーチンからのリターンによっても，タスクを終了させることができることとした．

84

µITRON4.0 仕様

CRE_TSK
cre_tsk
acre_tsk

Ver. 4.01.00

タスクの生成（静的 API）

【 S】

タスクの生成タスクの生成（ ID番号自動割付け）【静的 API】
CRE_TSK ( ID tskid, { ATR tskatr, VP_INT exinf, FP task,
PRI itskpri, SIZE stksz, VP stk } ) ;【C 言語 API】
ER ercd = cre_tsk ( ID tskid, T_CTSK *pk_ctsk ) ;ER_ID tskid = acre_tsk ( T_CTSK *pk_ctsk ) ;【パラメータ】
ID
T_CTSK *tskid
pk_ctsk

生成対象のタスクの ID番号（acre_tsk以外）
タスク生成情報を入れたパケットへのポイン
タ（CRE_TSKではパケットの内容を直接記述する）

pk_ctskの内容（T_CTSK 型）
ATR
tskatr
タスク属性
VP_INT
exinf
タスクの拡張情報FP
task
タスクの起動番地
PRI
itskpri
タスクの起動時優先度
SIZE
stksz
タスクのスタック領域のサイズ（バイト数）
VP
stk
タスクのスタック領域の先頭番地（実装独自に他の情報を追加してもよい）【リターンパラメータ】
cre_tsk の場合
ER
ercd
acre_tsk の場合
ER_ID
tskid
【エラーコード】
E_ID
E_NOID
E_NOMEM
E_RSATR
E_PAR

正常終了（E_OK）またはエラーコード
生成したタスクの ID 番号（正の値）またはエ
ラーコード

不正 ID 番号（tskid が不正あるいは使用できない；
cre_tskのみ）
ID 番号不足（割付け可能なタスク ID がない； acre_tsk
のみ）
メモリ不足（スタック領域などが確保できない）
予約属性（tskatrが不正あるいは使用できない）
パラメータエラー（pk_ctsk，task，itskpri，stksz，stkが不正）
85

µITRON4.0 仕様
E_OBJ

Ver. 4.01.00
オブジ ェクト状 態エラ ー（対象タス クが登 録済み；
cre_tsk のみ）【機能】
tskidで指定される ID 番号を持つタスクを，pk_ctskで指定されるタスク生成
情報に基づいて生成する．具体的には，対象タスクを未登録状態から休止状態
または実行可能状態に移行させ，それに伴って必要な処理を行う．tskatrはタ
スクの属性，exinf はタスクを起動する際にパラメータとして渡す拡張情報，
task はタスクの起動番地，itskpri はタスク起動時のベース優先度の初期値を指定する起動時優先度，stksz はタスクのスタック領域のサイズ（バイト数），
stkはタスクのスタック領域の先頭番地である．
CRE_TSK においては，tskid は自動割付け対応整数値パラメータ，tskatrはプ
リプロセッサ定数式パラメータである．
生成するタスクのID番号をタスクが登録されていない ID番号の中
acre_tskは，から割り付け，割り付けた ID 番号を返値として返す．
（（ TA_HLNG ‖ TA_ASM）｜［TA_ACT］）の指定ができる．
tskatr には，
TA_HLNG（＝ 0x00）が指定された場合には高級言語用のインタフェースで，TA_ASM（＝ 0x01）が指定された場合にはアセンブリ言語用のインタフェース
でタスクを起動する．TA_ACT（＝ 0x02）が指定されない場合には，対象タス
クを休止状態に移行させ，タスクの生成時に行うべき処理を行う．TA_ACTが指定された場合には，対象タスクを実行可能状態に移行させ，タスクの生成時に行うべき処理に加えて，タスクの起動時に行うべき処理を行う．タスクを起動する際のパラメータとしては，タスクの拡張情報を渡す．
タスクを実行するため
stkで指定された番地からstkszバイトのメモリ領域を，のスタック領域として使用する．stk に NULL（＝ 0）が指定された場合には，
stkszで指定されたサイズのメモリ領域を，カーネルが確保する．
stksz に実装定義の最大値よりも大きい値が指定された場合には，E_PAR エ
ラーを返す．
【スタンダードプロファイル】
スタンダードプロファイルでは， tskatr に TA_ASM が指定された場合の機能はサポートする必要がない．また，stk に NULL 以外の値が指定された場合の機能もサポートする必要がない．
【補足説明】
タスクから呼び出されたサービスコールやタスクの実行中に起動された割込
みハンドラ（ないしは，それらの出入口処理）がタスクと一連のスタック領域を使う場合，それらの使うスタック領域もタスクのスタック領域に含まれる．
タスクのスタック領域のサイズを求める方法は，実装について説明する製品マ
ニュアルなどで説明すべきである．
タスクのスタック領域の先頭番地には，スタックとして使用するメモリ領域の中での最小番地を指定する．そのため，タスクの実行開始直後のスタックポイ
86

µITRON4.0 仕様

Ver. 4.01.00

ンタの値とは，一般には一致しない．
cre_tsk の対象タスクに自タスクを指定することはできない．自タスクが指定された場合には，未登録状態でないために E_OBJエラーを返す．
stk に NULL が指定された場合にカーネルが確保するスタック領域のサイズ
は，stkszに指定されたサイズ以上であれば，それよりも大きくてもよい．
【µITRON3.0 仕様との相違】
タスク生成情報に，タスクのスタック領域の先頭番地（stk）を追加した．
µITRON3.0 仕様との互換性を保つためには，stkに NULL を指定すればよい．
タスク生成情報を入れたパケット中での tskatrと exinfの順序を交換した．また，exinfのデータ型を VP から VP_INTに， stksz のデータ型を INT から SIZEにそれぞれ変更した．
タスク属性（TA_ACT）により，タスク生成後にタスクを実行可能状態とする機能を追加した．これは，タスクを静的に生成する場合を考慮したためである．タスクがコプロセッサを使用することを示すタスク属性は規定しないことにした（必要なら実装独自に対応できる）．
acre_tsk は新設のサービスコールである．

87

µITRON4.0 仕様

del_tskVer. 4.01.00

タスクの削除【C 言語 API】
ER ercd = del_tsk ( ID tskid ) ;【パラメータ】
IDtskid【リターンパラメータ】
ER
ercd【エラーコード】
E_ID
E_NOEXS
E_OBJ

削除対象のタスクの ID 番号
正常終了（E_OK）またはエラーコード

不正 ID 番号（tskidが不正あるいは使用できない）
オブジェクト未生成（対象タスクが未登録）
オブジェクト状態エラー（対象タスクが休止状態でない）【機能】
tskid で指定されるタスクを削除する．具体的には，対象タスクを休止状態から未登録状態に移行させ，タスクの削除時に行うべき処理を行う．
対象タスクが休止状態でない場合には，E_OBJ エラーを返す（ただし，対象
タスクが未登録状態の時は E_NOEXSエラーとなる）．
【補足説明】
対象タスクに自タスクを指定することはできない．自タスクが指定された場合には，休止状態でないために E_OBJ エラーを返す．自タスクを削除する場合には，exd_tskを用いる．

88

µITRON4.0 仕様

act_tskiact_tsk

Ver. 4.01.00【 S】

タスクの起動【 S】【C 言語 API】
ER ercd = act_tsk ( ID tskid ) ;ER ercd = iact_tsk ( ID tskid ) ;【パラメータ】
IDtskid【リターンパラメータ】
ER
ercd【エラーコード】
E_ID
E_NOEXSE_QOVR

起動対象のタスクの ID番号
正常終了（E_OK）またはエラーコード

不正 ID 番号（tskidが不正あるいは使用できない）
オブジェクト未生成（対象タスクが未登録）
キューイングオーバフロー（起動要求キューイング数のオーバフロー）【機能】
tskid で指定されるタスクを起動する．具体的には，対象タスクを休止状態から実行可能状態に移行させ，タスクの起動時に行うべき処理を行う．タスクを起動する際のパラメータとして，タスクの拡張情報を渡す．
対象タスクが休止状態でない場合には，タスクに対する起動要求をキューイン
グする（ただし，対象タスクが未登録状態の時は E_NOEXS エラーとなる）．
具体的には，タスクの起動要求キューイング数に 1を加える．タスクの起動要
求キューイング数に 1を加えると起動要求キューイング数の最大値を越える場
合には，E_QOVRエラーを返す．
非タスクコンテキストから呼び出された場合で，サービスコールを遅延実行する場合には，E_QOVR エラーを返すことを，実装定義で省略することができる．
tskidに TSK_SELF（＝ 0）が指定されると，自タスクを対象タスクとする．ただし，非タスクコンテキストからの呼出しでこの指定が行われた場合には，
E_IDエラーを返す．
【補足説明】
スタンダードプロファイルでは，タスクの起動要求キューイング数の最大値
は，1以上であればいくつであってもよい．したがって，スタンダードプロファ
イルに準拠したカーネルで，起動要求がキューイングされているタスクを指定してこのサービスコールを呼び出しても，E_QOVR エラーが返るとは限らな
い．

89

µITRON4.0 仕様

Ver. 4.01.00【µITRON3.0 仕様との相違】
新設のサービスコールである．

90

µITRON4.0 仕様

can_act

Ver. 4.01.00

タスク起動要求のキャンセル【 S】【C 言語 API】
ER_UINT actcnt = can_act ( ID tskid ) ;【パラメータ】
IDtskid【リターンパラメータ】
ER_UINT actcnt【エラーコード】
E_ID
E_NOEXS

起動要求のキャンセル対象のタスクの ID番号
キューイングされていた起動要求の回数（正の値または 0）またはエラーコード

不正 ID 番号（tskidが不正あるいは使用できない）
オブジェクト未生成（対象タスクが未登録）【機能】
tskid で指定されるタスクに対してキューイングされている起動要求をキャン
セルし，キューイングされていた起動要求の回数を返す．具体的には，タスクの起動要求キューイング数を 0にクリアし，クリアする前の起動要求キューイ
ング数を返す．
tskidに TSK_SELF（＝ 0）が指定されると，自タスクを対象タスクとする．
【補足説明】
休止状態のタスクを対象タスクとして呼び出すこともできる．この場合，休止状態のタスクには起動要求がキューイングされていないために，サービスコー
ルの返値は 0となる．
このサービスコールは，タスクを周期的に起動して処理を行う場合に，周期内に処理が終わっているかどうかを判定するために用いることができる．具体的には，前の起動要求に対する処理が終了した時点で can_act を呼び出し，その返値が 1以上の値であった場合，前の起動要求に対する処理が周期内に終了せず，次の起動要求が行われたことがわかる．したがって，処理の遅れに対する処置をとることができる．
【µITRON3.0 仕様との相違】
新設のサービスコールである．

91

µITRON4.0 仕様

sta_tskVer. 4.01.00

タスクの起動（起動コード指定）【C 言語 API】
ER ercd = sta_tsk ( ID tskid, VP_INT stacd ) ;【パラメータ】
ID
VP_INT

tskid
stacd

【リターンパラメータ】
ER
ercd【エラーコード】
E_ID
E_NOEXS
E_OBJ

起動対象のタスクの ID 番号
タスクの起動コード
正常終了（E_OK）またはエラーコード

不正 ID 番号（tskidが不正あるいは使用できない）
オブジェクト未生成（対象タスクが未登録）
オブジェクト状態エラー（対象タスクが休止状態でない）【機能】
tskid で指定されるタスクを起動する．具体的には，対象タスクを休止状態から実行可能状態に移行させ，タスクの起動時に行うべき処理を行う．タスクを起動する際のパラメータとして，stacdの値を渡す．
対象タスクが休止状態でない場合には，タスクに対する起動要求をキューイン
グせず，E_OBJ エラーを返す（ただ し，対象タスクが未登 録状態の時は．
E_NOEXSエラーとなる）【補足説明】
対象タスクに自タスクを指定することはできない．自タスクが指定された場合には，休止状態でないために E_OBJエラーを返す．
【µITRON3.0 仕様との相違】
stacdのデータ型を INTから VP_INT に変更した．

92

µITRON4.0 仕様

ext_tskVer. 4.01.00【 S】

自タスクの終了【C 言語 API】
void ext_tsk ( ) ;【パラメータ】
なし【リターンパラメータ】
このサービスコールからはリターンしない【機能】
自タスクを終了させる．具体的には，自タスクを実行状態から休止状態に移行させ，タスクの終了時に行うべき処理を行う．
自タスクに対する起動要求がキューイングされている場合，具体的には，自タ
スクの起動要求キューイング数が 1以上の場合には，起動要求キューイング数
から 1を減じ，自タスクを実行可能状態に移行させる．この時，タスク起動時に行うべき処理を行う．タスクを起動する際のパラメータとしては，タスクの拡張情報を渡す．
このサービスコールは，リターンすることがないサービスコールである．したがって，サービスコール内で何らかのエラーを検出した場合でも，エラーコー
ドを返すことはできない．サービスコール内でエラーを検出した場合の振舞い
は実装定義とする．
【補足説明】
このサービスコールは，自タスクに対する起動要求がキューイングされている
場合，自タスクをいったん終了させた後に再起動する．そのため，自タスクがロックしているミューテックスをロック解除し，上限プロセッサ時間の設定を解除する．また，タスクのベース優先度（および現在優先度），起床要求キュー
イング数，強制待ち要求ネスト数，保留例外要因，タスク例外処理禁止／許可
状態を，タスクの起動直後の状態に初期化する．再起動されたタスクの優先順
位は，同じ優先度を持つタスクの中で最低の優先順位となる．
サービスコール内でエラーを検出した場合，検出したエラーに関する情報を，
エラーログに残すなどの方法が考えられる．
タスクのメインルーチンからリターンした場合も，ext_tsk を呼び出した場合と同じ振舞いをする．
【µITRON3.0 仕様との相違】
起動要求をキューイングする機能を追加したため，このサービスコールは，自タスクを終了させた後に再起動する場合がある．

93

µITRON4.0 仕様

exd_tskVer. 4.01.00

自タスクの終了と削除【C 言語 API】
void exd_tsk ( ) ;【パラメータ】
なし【リターンパラメータ】
このサービスコールからはリターンしない【機能】
自タスクを終了させ，さらに自タスクを削除する．具体的には，自タスクを実行状態から未登録状態に移行させ，タスクの終了時に行うべき処理と削除時に行うべき処理を行う．
このサービスコールは，リターンすることがないサービスコールである．したがって，サービスコール内で何らかのエラーを検出した場合でも，エラーコー
ドを返すことはできない．サービスコール内でエラーを検出した場合の振舞い
は実装定義とする．
【補足説明】
このサービスコールが呼び出されると，起動要求がキューイングされているかどうかにかかわらず，自タスクを終了させ，削除する（未登録状態では，起動要求キューイング数は意味を持たない）．
サービスコール内でエラーを検出した場合，検出したエラーに関する情報を，
エラーログに残すなどの方法が考えられる．

94

µITRON4.0 仕様

ter_tskVer. 4.01.00【 S】

タスクの強制終了【C 言語 API】
ER ercd = ter_tsk ( ID tskid ) ;【パラメータ】
IDtskid【リターンパラメータ】
ER
ercd【エラーコード】
E_ID
E_NOEXS
E_ILUSE
E_OBJ

強制終了対象のタスクの ID番号
正常終了（E_OK）またはエラーコード

不正 ID 番号（tskidが不正あるいは使用できない）
オブジェクト未生成（対象タスクが未登録）
サービスコール不正使用（対象タスクが自タスク）
オブジェクト状態エラー（対象タスクが休止状態）【機能】
tskid で指定されるタスクを強制的に終了させる．具体的には，対象タスクを休止状態に移行させ，タスクの終了時に行うべき処理を行う．
対象タスクに対する起動要求がキューイングされている場合，具体的には，対象タスクの起動要求キューイング数が 1以上の場合には，起動要求キューイン
グ数から 1を減じ，対象タスクを実行可能状態に移行させる．この時，タスクの起動時に行うべき処理を行う．タスクを起動する際のパラメータとしては，タスクの拡張情報を渡す
対象タスクが休止状態の時は E_OBJ エラーを返す．また，このサービスコー
ルで自タスクを終了させることはできない．対象タスクが自タスクの場合には，E_ILUSE エラーを返す．
【補足説明】
このサービスコールは，対象タスクが広義の待ち状態にある場合にも，対象タ
スクを強制的に終了させる．対象タスクが何らかの待ち行列につながれていた
場合には，対象タスクを待ち行列から外す．その際に，その待ち行列で待っている他のタスクの待ち解除が必要になる場合がある（snd_mbf の機能説明と．
get_mpl の機能説明を参照）
このサービスコールは，対象タスクに対する起動要求がキューイングされている場合，対象タスクをいったん終了させた後に再起動する．そのため，対象タ
スクがロックしているミューテックスをロック解除し，上限プロセッサ時間の設定を解除する．また，タスクのベース優先度（および現在優先度），起床要
求キューイング数，強制待ち要求ネスト数，保留例外要因，タスク例外処理禁止／許可状態を，タスクの起動直後の状態に初期化する．再起動されたタスクの優先順位は，同じ優先度を持つタスクの中で最低の優先順位となる．
95

µITRON4.0 仕様

Ver. 4.01.00【µITRON3.0 仕様との相違】
対象タスクに自タスクが指定された場合のエラーを，E_OBJから E_ILUSEに変更した．
起動要求をキューイングする機能を追加したため，このサービスコールは，対象タスクを終了させた後に再起動する場合がある．

96

µITRON4.0 仕様

chg_priVer. 4.01.00【 S】

タスク優先度の変更【C 言語 API】
ER ercd = chg_pri ( ID tskid, PRI tskpri ) ;【パラメータ】
ID
PRI

tskid
tskpri【リターンパラメータ】
ER
ercd【エラーコード】
E_ID
E_NOEXS
E_PAR
E_ILUSE
E_OBJ

変更対象のタスクの ID番号
変更後のベース優先度
正常終了（E_OK）またはエラーコード

不正 ID 番号（tskidが不正あるいは使用できない）
オブジェクト未生成（対象タスクが未登録）
パラメータエラー（tskpri が不正）サービスコール不正使用（上限優先度の違反）
オブジェクト状態エラー（対象タスクが休止状態）【機能】
tskid で指定されるタスクのベース優先度を， tskpri で指定される値に変更す
る．それに伴って，タスクの現在優先度も変更する．
tskidに TSK_SELF（＝ 0）が指定されると，自タスクを対象タスクとする．また，tskpriに TPRI_INI（＝ 0）が指定されると，対象タスクのベース優先度を，タスクの起動時優先度に変更する．
このサービスコールを実行した結果，対象タスクの現在優先度がベース優先度に一致している場合（ミューテックス機能を使わない場合には，この条件は常に成り立つ）には，次の処理を行う．対象タスクが実行できる状態である場
合，タスクの優先順位を，変更後の優先度にしたがって変化させる．変更後の優先度と同じ優先度を持つタスクの間では，対象タスクの優先順位を最低とす
る．対象タスクが何らかのタスク優先度順の待ち行列につながれている場合にも，その待ち行列の中での順序を，変更後の優先度にしたがって変化させる．
変更後の優先度と同じ優先度を持つタスクの間では，対象タスクを最後につなぐ．
対象タスクが TA_CEILING 属性のミューテックスをロックしているか，ロッ
クを待っている場合で，tskpri で指定されたベース優先度が，それらのミュー
テックスのいずれかの上限優先度よりも高い場合には，E_ILUSE エラーを返す．
【補足説明】
このサービスコールを呼び出した結果，対象タスクのタスク優先度順の待ち行
列の中での順序が変化した場合，対象タスクないしはその待ち行列で待ってい97

µITRON4.0 仕様

Ver. 4.01.00

る他のタスクの待ち解除が必要になる場合がある（snd_mbf の機能説明と．
get_mplの機能説明を参照）
対象タスクが，TA_INHERIT属性のミューテックスのロック待ち状態である場
合，このサービスコールでベース優先度を変更したことにより，推移的な優先度継承の処理が必要になる場合がある．
ミューテックス機能を使わない場合には，対象タスクに自タスク，変更後の優
先度に自タスクのベース優先度を指定してこのサービスコールが呼び出されると，自タスクの実行順位は同じ優先度を持つタスクの中で最低となる．そのため，このサービスコールを用いて，実行権の放棄を行うことができる．
【µITRON3.0 仕様との相違】
ミューテックスの導入に伴って，chg_pri はタスクのベース優先度を変更するものとした．tskpriに TPRI_INIを指定できる機能を，標準的な機能とした．

98

µITRON4.0 仕様

get_priVer. 4.01.00【 S】

タスク優先度の参照【C 言語 API】
ER ercd = get_pri ( ID tskid, PRI *p_tskpri ) ;【パラメータ】
IDtskid【リターンパラメータ】
ER
ercd
PRI
tskpri【エラーコード】
E_ID
E_NOEXS
E_PAR
E_OBJ

参照対象のタスクの ID番号
正常終了（E_OK）またはエラーコード
対象タスクの現在優先度

不正 ID 番号（tskidが不正あるいは使用できない）
オブジェクト未生成（対象タスクが未登録）
パラメータエラー（p_tskpri が不正）オブジェクト状態エラー（対象タスクが休止状態）【機能】
tskidで指定されるタスクの現在優先度を参照し，tskpri に返す．
tskidに TSK_SELF（＝ 0）が指定されると，自タスクを対象タスクとする．
【補足説明】
chg_pri がタスクのベース優先度を変更するのに対して，get_priはタスクの現在優先度を参照する．
【µITRON3.0 仕様との相違】
新設のサービスコールである．このサービスコールを新設したのは，送信するメッセージの優先度に自タスクの優先度を設定する場合などに，自タスクの優先度を小さいオーバヘッドで取り出す方法が必要となるためである．
【仕様決定の理由】
tskpriをサービスコールの返値としなかったのは，他の類似のサービスコール（get_yyy）との整合性と，実装独自に優先度に負の値を使う場合を考慮したためである．

99

µITRON4.0 仕様

ref_tskVer. 4.01.00

タスクの状態参照【C 言語 API】
ER ercd = ref_tsk ( ID tskid, T_RTSK *pk_rtsk ) ;【パラメータ】
ID
T_RTSK *tskid
pk_rtsk【リターンパラメータ】
ER
ercd

参照対象のタスクの ID 番号
タスク状態を返すパケットへのポインタ
正常終了（E_OK）またはエラーコード

pk_rtskの内容（T_RTSK型）
タスク状態
STAT
tskstat
タスクの現在優先度
PRI
tskpri
タスクのベース優先度
PRI
tskbpri
待ち要因
STAT
tskwait
待ち対象のオブジェクトの ID 番号ID
wobjid
タイムアウトするまでの時間
TMO
lefttmo
起動要求キューイング数
UINT
actcnt
起床要求キューイング数
UINT
wupcnt
強制待ち要求ネスト数
UINTsuscnt（実装独自に他の情報を追加してもよい）【エラーコード】
E_ID
E_NOEXS
E_PAR

不正 ID 番号（tskidが不正あるいは使用できない）
オブジェクト未生成（対象タスクが未登録）
パラメータエラー（pk_rtskが不正）【機能】
tskidで指定されるタスクに関する状態を参照し，pk_rtskで指定されるパケッ
トに返す．対象タスクが未登録状態の場合には，E_NOEXSエラーを返す．
tskstatには，対象タスクの状態によって，次のいずれかの値を返す．
TTS_RUNTTS_RDY
TTS_WAITTS_SUSTTS_WASTTS_DMT

0x01
0x02
0x04
0x08
0x0c
0x10

実行状態
実行可能状態
待ち状態
強制待ち状態
二重待ち状態
休止状態

対象タスクが休止状態でない場合に，tskpri には対象タスクの現在優先度，
tskbpri にはベース優先度を返す．対象タスクが休止状態の場合にこれらに返す値は実装依存である．

100

µITRON4.0 仕様

Ver. 4.01.00

対象タスクが待ち状態（二重待ち状態を含む）の場合に，tskwait には，対象タスクが待ち状態になっている要因によって，次のいずれかの値を返す．対象
タスクが待ち状態でない場合に tskwait に返す値は実装依存である．
TTW_SLPTTW_DLY
TTW_SEM
TTW_FLG
TTW_SDTQ
TTW_RDTQ
TTW_MBX
TTW_MTX
TTW_SMBF
TTW_RMBF
TTW_CAL
TTW_ACP
TTW_RDVTTW_MPF
TTW_MPL

0x00010x00020x00040x00080x00100x00200x00400x00800x01000x02000x04000x08000x10000x20000x4000

起床待ち状態
時間経過待ち状態
セマフォ資源の獲得待ち状態
イベントフラグ待ち状態
データキューへの送信待ち状態
データキューからの受信待ち状態
メールボックスからの受信待ち状態
ミューテックスのロック待ち状態
メッセージバッファへの送信待ち状態
メッセージバッファからの受信待ち状態
ランデブの呼出し待ち状態
ランデブの受付待ち状態
ランデブの終了待ち状態
固定長メモリブロックの獲得待ち状態
可変長メモリブロックの獲得待ち状態

対象タスクが待ち状態（二重待ち状態を含む）で，起床待ち状態，時間経過待ち状態，ランデブの終了待ち状態のいずれでもない場合に，wobjid には，待ち対象のオブジェクトの ID番号を返す．それ以外の場合に wobjidに返す値は実装依存である．
対象タスクが待ち状態（二重待ち状態を含む）で，時間経過待ち状態でない場
合に，lefttmo には，対象タスクがタイムアウトするまでの時間を返す．具体的には，タイムアウトとなる時刻から現在時刻を減じた値を返す．ただし，lefttmo に返す値は，タイムアウトするまでの時間以下でなければならない．そのため，次のタイムティックでタイムアウトする場合には，lefttmo に 0 を返す．対象タスクが永久待ち（タイムアウトなし）で待ち状態になっている場合には，lefttmo に TMO_FEVR を返す．対象タスクが待ち状態（二重待ち状態を含む）でないか，時間経過待ち状態である場合には，lefttmo に返す値は実装依存である．
actcntには，対象タスクの起動要求キューイング数を返す．
対象タスクが休止状態でない場合に，wupcnt には対象タスクの起床要求
キューイング数， suscnt には強制待ち要求ネスト数を返す．対象タスクが休止状態の場合にこれらに返す値は実装依存である．
tskidに TSK_SELF（＝ 0）が指定されると，自タスクを対象タスクとする．
【µITRON3.0 仕様との相違】
実装依存で参照できるとしていた情報の多くを，標準的に参照できるものとした．その際に，リターンパラメータの名称を wid から wobjid に変更した．また，参照できる情報に，タスクのベース優先度（tskbpri），タイムアウトする
101

µITRON4.0 仕様

Ver. 4.01.00

までの時間（lefttmo），起動要求キューイング数（actcnt）を追加し，拡張情報を削除した．
タスク状態を返すパケット中での tskstat と tskpriの順序を交換した．tskstatのデータ型を UINT から STAT に変更した．また，パラメータとリターンパラ
メータの順序を変更した．
特定のタスク状態の場合にのみ意味を持つリターンパラメータに，その他のタスク状態の場合に返す値を実装依存とした．例えば，タスクが休止状態の場合に tskpri に返す値は実装依存である．
tskwaitに返す値を割り付けなおした．
【仕様決定の理由】
対象タスクが時間経過待ち状態の場合に lefttmo に返す値を実装依存としたのは，dly_tsk による遅延時間が RELTIM型（符号無し整数）で指定されるために，TMO 型（符号付き整数）の lefttmoに返せるとは限らないためである．

102

µITRON4.0 仕様

ref_tstVer. 4.01.00

タスクの状態参照（簡易版）【C 言語 API】
ER ercd = ref_tst ( ID tskid, T_RTST *pk_rtst ) ;【パラメータ】
ID
T_RTST *tskid
pk_rtst【リターンパラメータ】
ER
ercd

参照対象のタスクの ID番号
タスク状態を返すパケットへのポインタ
正常終了（E_OK）またはエラーコード

pk_rtstの内容（T_RTST型）
タスク状態
STAT
tskstat
待ち要因
STAT
tskwait（実装独自に他の情報を追加してもよい）【エラーコード】
E_ID
E_NOEXS
E_PAR

不正 ID 番号（tskidが不正あるいは使用できない）
オブジェクト未生成（対象タスクが未登録）
パラメータエラー（pk_rtst が不正）【機能】
tskidで指定されるタスクに関する最低限の状態を参照し，pk_rtstで指定されるパケットに返す．
このサービスコールは， ref_tsk の簡易版である．tskstat と tskwait には，
ref_tsk で返すのと同じ値を返す．
tskidに TSK_SELF（＝ 0）が指定されると，自タスクを対象タスクとする．
【仕様決定の理由】
ref_tsk を用いると，タスクに関する各種の状態を参照できるが，タスク情報など最低限の状態のみを参照したい場合にはオーバヘッドが大きい．小さい
オーバヘッドでタスクに関する最低限の状態を参照するためのサービスコー
ルとして，ref_tst を新設した．
【µITRON3.0 仕様との相違】
新設のサービスコールである．

103

µITRON4.0 仕様

Ver. 4.01.00

4.2 タスク付属同期機能
タスク付属同期機能は，タスクの状態を直接的に操作することによって同期を行うための機能である．タスクを起床待ちにする機能とそこから起床する機能，タスクの起床要求をキャンセルする機能，タスクの待ち状態を強制解除する機能，タスクを強制待ち状態へ移行する機能とそこから再開する機能，自タスクの実行を遅延する機能が含まれる．
タスクに対する起床要求は，キューイングされる．すなわち，起床待ち状態でないタスクを起床しようとすると，そのタスクを起床しようとしたという記録が残り，後でそのタスクが起床待ちに移行しようとした時に，タスクを起床待ち状態にしない．タスクに対する起床要求のキューイングを実現するために，
タスクは起床要求キューイング数を持つ．タスクの起床要求キューイング数
は，タスクの起動時に 0 にクリアする．
タスクに対する強制待ち要求は，ネストされる．すなわち，すでに強制待ち状態（二重待ち状態を含む）になっているタスクを再度強制待ち状態に移行させようとすると，そのタスクを強制待ち状態に移行させようとしたという記録が残り，後でそのタスクを強制待ち状態（二重待ち状態を含む）から再開させようとした時に，強制待ちからの再開を行わない．タスクに対する強制待ち要求のネストを実現するために，タスクは強制待ち要求ネスト数を持つ．タスクの強制待ち要求ネスト数は，タスクの起動時に 0 にクリアする．
タスク付属同期機能に関連して，次のカーネル構成定数を定義する．
TMAX_WUPCNTTMAX_SUSCNT

タスクの起床要求キューイング数の最大値
タスクの強制待ち要求ネスト数の最大値

タスク付属同期機能の各サービスコールの機能コードは次の通りである．
TFN_SLP_TSK
TFN_TSLP_TSK
TFN_WUP_TSK
TFN_IWUP_TSK
TFN_CAN_WUP
TFN_REL_WAI
TFN_IREL_WAI
TFN_SUS_TSK
TFN_RSM_TSK
TFN_FRSM_TSK
TFN_DLY_TSK

–0x11
–0x12
–0x13
–0x72
–0x14
–0x15
–0x73
–0x16
–0x17
–0x18
–0x19

slp_tsk の機能コード
tslp_tskの機能コード
wup_tskの機能コード
iwup_tsk の機能コード
can_wupの機能コード
rel_waiの機能コード
irel_wai の機能コード
sus_tskの機能コード
rsm_tskの機能コード
frsm_tskの機能コード
dly_tsk の機能コード【スタンダードプロファイル】
スタンダードプロファイルでは，タスク付属同期機能をサポートしなければならない．
スタンダードプロファイルでは，少なくとも 1回のタスクの起床要求キューイ

104

µITRON4.0 仕様

Ver. 4.01.00

ングをサポートしなければならない．また，タスクの強制待ち状態をサポートしなければならない．したがって，TMAX_WUPCNT と TMAX_SUSCNT は，ともに 1以上でなければならない．
【補足説明】
TMAX_WUPCNT は，タスクの起床待ちをサポートしない場合には未定義，タスクの起床要求キューイングをサポートしない場合には 0とする．また，タスクの強制待ち状態をサポートしない場合には，TMAX_SUSCNTは未定義とする．したがって，TMAX_SUSCNT が 0に定義されることはない．
【µITRON3.0 仕様との相違】
タスクの待ち状態を強制解除する機能（rel_wai），自タスクの実行を遅延する機能（dly_tsk）をタスク付属同期機能に分類することにした．

105

µITRON4.0 仕様

slp_tsktslp_tsk

Ver. 4.01.00

起床待ち

【S】

起床待ち（タイムアウトあり）【S】【C 言語 API】
ER ercd = slp_tsk ( ) ;ER ercd = tslp_tsk ( TMO tmout ) ;【パラメータ】
TMO

tmout【リターンパラメータ】
ER
ercd【エラーコード】
E_PAR
E_RLWAIE_TMOUT

タイムアウト指定（tslp_tskのみ）
正常終了（E_OK）またはエラーコード

パラメータエラー（tmoutが不正；tslp_tskのみ）待ち状態の強制解除（待ち状態の間に rel_waiを受付）
ポーリング失敗またはタイムアウト（tslp_tsk のみ）【機能】
自タスクを起床待ち状態に移行させる．ただし，自タスクに対する起床要求がキューイングされている場合，具体的には，自タスクの起床要求キューイング
数が 1 以上の場合には，起床要求キューイング数から 1 を減じ，自タスクを待ち状態に移行させず，そのまま実行を継続する．
tslp_tsk は，slp_tsk にタイムアウトの機能を付け加えたサービスコールである．tmout には，正の値のタイムアウト時間に加えて，TMO_POL（＝ 0）とTMO_FEVR（＝ –1）を指定することができる．
【補足説明】
このサービスコールは，自タスクに対する起床要求がキューイングされている場合に，自タスクをいったん待ち状態とはしない．そのため，自タスクの優先順位は変化しない．
slp_tsk の処理をポーリングで行う専用のサービスコールは用意されてない．
必要があれば，can_wup により類似の機能を実現することができる．

106

µITRON4.0 仕様

wup_tskiwup_tsk

Ver. 4.01.00【 S】

タスクの起床【 S】【C 言語 API】
ER ercd = wup_tsk ( ID tskid ) ;ER ercd = iwup_tsk ( ID tskid ) ;【パラメータ】
IDtskid【リターンパラメータ】
ER
ercd【エラーコード】
E_ID
E_NOEXS
E_OBJ
E_QOVR

起床対象のタスクの ID番号
正常終了（E_OK）またはエラーコード

不正 ID 番号（tskidが不正あるいは使用できない）
オブジェクト未生成（対象タスクが未登録）
オブジェクト状態エラー（対象タスクが休止状態）
キューイングオーバフロー（起床要求キューイング数のオーバフロー）【機能】
tskid で指定されるタスクを，起床待ち状態から待ち解除する．待ち解除されたタスクに対しては，待ち状態に入ったサービスコールの返値として E_OKを返す．
対象タスクが起床待ち状態でない場合には，タスクに対する起床要求をキューイングする（ただし，対象タスクが未登録状態の時は E_NOEXS エラー，休止状態の時は E_OBJエラーとなる）．具体的には，タスクの起床要求キューイン
グ数に 1 を加える．タスクの起床要求キューイング数に 1 を加えると起床要求
キューイング数の最大値を越える場合には，E_QOVRエラーを返す．
非タスクコンテキストから呼び出された場合で，サービスコールを遅延実行する場合には，E_OBJエラーと E_QOVR エラーを返すことを，実装定義で省略することができる．
tskidに TSK_SELF（＝ 0）が指定されると，自タスクを対象タスクとする．ただし，非タスクコンテキストからの呼出しでこの指定が行われた場合には，
E_IDエラーを返す．
【補足説明】
スタンダードプロファイルでは，タスクの起床要求キューイング数の最大値
は，1以上であればいくつであってもよい．したがって，スタンダードプロファ
イルに準拠したカーネルで，起床要求がキューイングされているタスクを指定してこのサービスコールを呼び出しても，E_QOVR エラーが返るとは限らな
い．
107

µITRON4.0 仕様

Ver. 4.01.00【µITRON3.0 仕様との相違】
対象タスクに自タスクを指定できることとした．これは，act_tsk との整合性を考慮したためである．

108

µITRON4.0 仕様

can_wupVer. 4.01.00

タスク起床要求のキャンセル【 S】【C 言語 API】
ER_UINT wupcnt = can_wup ( ID tskid ) ;【パラメータ】
IDtskid【リターンパラメータ】
ER_UINT wupcnt【エラーコード】
E_ID
E_NOEXS
E_OBJ

起床要求のキャンセル対象のタスクの ID番号
キューイングされていた起床要求の回数（正の値または 0）またはエラーコード

不正 ID 番号（tskidが不正あるいは使用できない）
オブジェクト未生成（対象タスクが未登録）
オブジェクト状態エラー（対象タスクが休止状態）【機能】
tskid で指定されるタスクに対してキューイングされている起床要求をキャン
セルし，キューイングされていた起床要求の回数を返す．具体的には，タスクの起床要求キューイング数を 0にクリアし，クリアする前の起床要求キューイ
ング数を返す．
tskidに TSK_SELF（＝ 0）が指定されると，自タスクを対象タスクとする．
【補足説明】
このサービスコールは，タスクを周期的に起床して処理を行う場合に，周期内に処理が終わっているかどうかを判定するために用いることができる．具体的には，前の起床要求に対する処理が終了した時点で can_wup を呼び出し，その返値が 1以上の値であった場合，前の起床要求に対する処理が周期内に終了せず，次の起床要求が行われたことがわかる．したがって，処理の遅れに対する処置をとることができる．
【µITRON3.0 仕様との相違】
キューイングされていた起床要求の回数（ wupcnt）を，サービスコールの返値として返すこととした．

109

µITRON4.0 仕様

rel_wai
irel_waiVer. 4.01.00【S】

待ち状態の強制解除【S】【C 言語 API】
ER ercd = rel_wai ( ID tskid ) ;ER ercd = irel_wai ( ID tskid ) ;【パラメータ】
IDtskid【リターンパラメータ】
ER
ercd【エラーコード】
E_ID
E_NOEXS
E_OBJ

待ち状態の強制解除対象のタスクの ID 番号
正常終了（E_OK）またはエラーコード

不正 ID 番号（tskidが不正あるいは使用できない）
オブジェクト未生成（対象タスクが未登録）
オブジェクト状態エラー（対象タスクが待ち状態でない）【機能】
tskidで指定されるタスクが待ち状態にある場合に，強制的に待ち解除を行う．
すなわち，対象タスクが待ち状態の時は実行可能状態に，二重待ち状態の時は強制待ち状態に移行させる．このサービスコールにより待ち解除されたタスクに対しては，待ち状態に入ったサービスコールの返値として E_RLWAI エラーを返す．
対象タスクが待ち状態（二重待ち状態を含む）でない場合には，E_OBJエラー
を返す（ただし，対象タスクが未登録状態の時は E_NOEXS エラーとなる）．
非タスクコンテキストから呼び出された場合で，サービスコールを遅延実行する場合には，E_OBJ エラーを返すことを，実装定義で省略することができる．
【補足説明】
対象タスクに自タスクを指定することはできない．自タスクが指定された場合には，待ち状態でないために E_OBJエラーを返す．
このサービスコールでは，強制待ちからの再開は行わない．強制待ちからの再開を行う必要がある場合には，frsm_tsk（または rsm_tsk）を用いる．
対象タスクが何らかの待ち行列につながれていた場合には，対象タスクを待ち
行列から外す．その際に，その待ち行列で待っている他のタスクの待ち解除が必要になる場合がある（snd_mbf の機能説明と get_mpl の機能説明を参照）．
rel_wai と wup_tskには次のような違いがある．
• wup_tsk は起床待ち状態からのみ待ち解除するが，rel_waiは任意の要因による待ち状態から待ち解除する．
• 起床待ち状態になっていたタスクから見ると，wup_tsk による待ち解除は
110

µITRON4.0 仕様

Ver. 4.01.00

正常終了（E_OK）であるのに対して，rel_wai による強制的な待ち解除はエラー（ E_RLWAI）である．
• wup_tskの場合は，対象タスクが起床待ち状態でない場合には，要求がキューイングされる．それに対して rel_waiの場合は，対象タスクが待ち状
態でない場合には E_OBJエラーとなる．

111

µITRON4.0 仕様

sus_tskVer. 4.01.00

強制待ち状態への移行【S】【C 言語 API】
ER ercd = sus_tsk ( ID tskid ) ;【パラメータ】
IDtskid【リターンパラメータ】
ER
ercd【エラーコード】
E_ID
E_CTX
E_NOEXS
E_OBJ
E_QOVR

移行対象のタスクの ID 番号
正常終了（E_OK）またはエラーコード

不正 ID 番号（tskidが不正あるいは使用できない）
コンテキストエラー（ディスパッチ禁止状態で対象タス
クに自タスクを指定，その他のコンテキストエラー）
オブジェクト未生成（対象タスクが未登録）
オブジェクト状態エラー（対象タスクが休止状態）
キューイングオーバフロー（強制待ち要求ネスト数のオーバフロー）【機能】
tskidで指定されるタスクを強制待ち状態にして，タスクの実行を中断させる．
具体的には，対象タスクが実行できる状態の時は強制待ち状態に，待ち状態の時は二重待ち状態に移行させる．また，対象タスクの強制待ち要求ネスト数に1 を加える．タスクの強制待ち要求ネスト数に 1 を加えると強制待ち要求ネス
ト数の最大値を越える場合には，E_QOVR エラーを返す．
このサービスコールは，ディスパッチ禁止状態でも呼び出すことができるが，ディスパッチ禁止状態で自タスクを対象タスクとして呼び出された場合には，
E_CTXエラーを返す．
tskidに TSK_SELF（＝ 0）が指定されると，自タスクを対象タスクとする．
【補足説明】
このサービスコールは，パラメータによっては自タスクを強制待ち状態にする可能性があるにもかかわらず，ディスパッチ禁止状態でも呼び出すことができる．したがって，「ディスパッチ禁止状態から自タスクを広義の待ち状態にする可能性のあるサービスコールが呼び出された場合の振舞いは未定義とする
制限は，サービスコール単位に適用される」という原則の例外となっている．
スタンダードプロファイルでは，タスクの強制待ち要求ネスト数の最大値は，1 以上であればいくつであってもよい．したがって，スタンダードプロファイ
ルに準拠したカーネルで，強制待ち状態のタスクを指定してこのサービスコー
ルを呼び出しても，E_QOVR エラーが返るとは限らない．

112

µITRON4.0 仕様

Ver. 4.01.00【µITRON3.0 仕様との相違】
対象タスクに自タスクを指定できることとした．

113

µITRON4.0 仕様

rsm_tsk
frsm_tsk

Ver. 4.01.00

強制待ち状態からの再開【S】

強制待ち状態からの強制再開【S】【C 言語 API】
ER ercd = rsm_tsk ( ID tskid ) ;ER ercd = frsm_tsk ( ID tskid ) ;【パラメータ】
IDtskid【リターンパラメータ】
ER
ercd【エラーコード】
E_ID
E_NOEXS
E_OBJ

再開対象のタスクの ID 番号
正常終了（E_OK）またはエラーコード

不正 ID 番号（tskidが不正あるいは使用できない）
オブジェクト未生成（対象タスクが未登録）
オブジェクト状態エラー（対象タスクが強制待ち状態で
ない）

【機能】
tskidで指定されるタスクの強制待ちを解除し，タスクの実行を再開させる．具
体的な処理内容は次の通りである．
rsm_tsk は，対象タスクの強制待ち要求ネスト数から 1を減じ，減じた後の強制待ち要求ネスト数が 0の場合には，対象タスクが強制待ち状態の時は実行可能状態に，二重待ち状態の時は待ち状態に移行させる．減じた後の強制待ち要
求ネスト数が 1 以上の場合には，対象タスクの状態を変化させない．
frsm_tsk は，対象タスクの強制待ち要求ネスト数を 0とし，対象タスクが強制待ち状態の時は実行可能状態に，二重待ち状態の時は待ち状態に移行させる．
対象タスクが強制待ち状態（二重待ち状態を含む）でない場合には，E_OBJ
エラーを返す（ただし，対象タスクが未登録状態の時は E_NOEXSエラーとなる）．
【補足説明】
対象タスクに自タスクを指定することはできない．自タスクが指定された場合には，強制待ち状態でないために E_OBJ エラーを返す．実装独自に，非タス
クコンテキストから実行中のタスクを強制待ち状態に移行させるサービス
コールを追加した場合や，ディスパッチ禁止状態で自タスクを強制待ち状態に移行させるサービスコールを呼出し可能とした場合には，自タスクの強制待ち
要求ネスト数が 1 以上になっている場合がある．このような場合の振舞いは，
実装定義とする．
【µITRON3.0 仕様との相違】
タスクを強制待ち状態から実行可能状態に移行させる時に，同じ優先度内で最114

µITRON4.0 仕様

Ver. 4.01.00

低の優先順位とするものとした．詳しくは，3.2.1 節を参照すること．

115

µITRON4.0 仕様

dly_tskVer. 4.01.00【S】

自タスクの遅延【C 言語 API】
ER ercd = dly_tsk ( RELTIM dlytim ) ;【パラメータ】
RELTIM

dlytim【リターンパラメータ】
ER
ercd【エラーコード】
E_PAR
E_RLWAI

自タスクの遅延時間（相対時間）
正常終了（E_OK）またはエラーコード

パラメータエラー（dlytim が不正）待ち状態の強制解除（待ち状態の間に rel_waiを受付）【機能】
自タスクを時間経過待ち状態に移行させ，dlytim で指定される時間の間，実行を一時的に停止する．具体的には，サービスコールが呼び出された時刻から自タスクを時間
dlytim で指定された相対時間後に待ち解除されるよう設定し，経過待ち状態に移行させる．指定された相対時間後に待ち解除された場合，このサービスコールは正常終了し，E_OK を返す．
dlytim は，サービスコールが呼び出された時刻を基準に，時間経過待ち状態から待ち解除される時刻を指定する相対時間と解釈する．
【補足説明】
時間経過待ち状態からの解除は，システム時刻に依存して行われる処理である．そのため，時間経過待ち状態からの解除は，待ち解除すべき時刻以降の最初のタイムティックで行う．また，時間経過待ち状態からの解除は，このサービスコールが呼び出されてから，dlytimで指定された以上の時間が経過した後に行うことを保証しなければならない（2.1.9 節参照）
．このサービスコールは，
dlytim に 0が指定された場合にも，自タスクを待ち状態に移行させる．
時間経過待ち状態は待ち状態の一種であり，rel_wai により強制的に待ち解除することができる．タスクの遅延時間には，タスクが二重待ち状態になっている時間も含まれる．
このサービスコールは，tslp_tskと異なり，dlytimで指定された時間が経過して待ち解除された場合に正常終了となる．時間経過待ち状態にあるタスクを指定して wup_tskが呼び出されても，時間経過待ち状態からの解除は行わない．
dlytim で指定された時間が経過する前に dly_tsk が終了するのは，ter_tsk か
rel_wai が呼び出された場合に限られる．
【µITRON3.0 仕様との相違】
dlytim のデータ型を DLYTIME から RELTIM に変更した．

116

µITRON4.0 仕様

Ver. 4.01.00

4.3 タスク例外処理機能
タスク例外処理機能は，タスクに発生した例外事象の処理を，タスクのコンテ
キストで行うための機能である．タスク例外処理ルーチンを定義する機能，タ
スク例外処理を要求する機能，タスク例外処理を禁止／許可する機能，タスク
例外処理に関する状態を参照する機能が含まれる．
タスク例外処理を要求するサービスコールが呼び出され，タスクに対してタス
ク例外処理が要求されると，タスクが実行中の処理を中断し，タスク例外処理
ルーチンを起動する．タスク例外処理ルーチンは，タスクと同じコンテキストで実行する．タスク例外処理ルーチンからリターンすると，中断した処理の実行を継続する．アプリケーションは，タスク毎に一つのタスク例外処理ルーチ
ンを登録することができる．タスクの生成直後は，タスク例外処理ルーチンは登録されていない．
タスクに対してタスク例外処理を要求する場合には，要求する例外処理の種類をあらわすタスク例外要因を指定する．カーネルは，タスク毎に，要求されたがまだ処理されていないタスク例外要因を管理する．これを，保留例外要因と呼ぶ．保留例外要因は，処理されていない例外処理要求がない時には 0となっている．処理されていない例外処理要求があるタスクに対して，再度タスク例
外処理が要求された場合には，タスクの保留例外要因を，新たに要求された例
外処理のタスク例外要因とのビット毎の論理和に更新する．保留例外要因は，タスクの起動時に 0にクリアする．
タスクは，タスク例外処理禁止状態かタスク例外処理許可状態かのいずれかの状態をとる．タスク例外処理禁止状態に移行することを「タスク例外処理を禁止する」，タスク例外処理許可状態に移行することを「タスク例外処理を許可する」ともいう．タスクの実行開始直後は，タスク例外処理禁止状態とする．
実装定義で，拡張サービスコールルーチンの起動によりタスク例外処理を禁止
し，そこからのリターンにより起動前の状態に戻すことができる．このような実装では，拡張サービスコールルーチン内でタスク例外処理を許可してはならないため，拡張サービスコールルーチンから ena_texが呼び出された場合には
E_CTX エラーを返す．
タスク例外処理許可状態であり，保留例外要因が 0でなく，タスクが実行状態であり，非タスクコンテキストまたは CPU例外ハンドラが実行されていないという 4つの条件が揃うと，タスク例外処理ルーチンを起動する．起動するタス
ク例外処理ルーチンには，起動時の保留例外要因（texptn）とタスクの拡張情報（exinf）をパラメータとして渡す．またこの時，タスクをタスク例外処理
禁止状態に移行させ，保留例外要因を 0にクリアする．
タスク例外処理ルーチンからリターンすると，タスク例外処理ルーチンを起動する前に実行していた処理の実行を継続する．この時，タスクをタスク例外処
理許可状態に移行させる．ここで，保留例外要因が 0でない場合には，再びタ
スク例外処理ルーチンを起動する．
117

µITRON4.0 仕様

Ver. 4.01.00

タスク例外処理機能では，次のデータ型を用いる．
TEXPTN

タスク例外要因のビットパターン（符号無し整数）

タスク例外処理ルーチンの C 言語による記述形式は次の通りとする．
void texrtn ( TEXPTN texptn, VP_INT exinf ){タスク例外処理ルーチン本体}
タスク例外処理機能に関連して，次のカーネル構成定数を定義する．
TBIT_TEXPTN

タスク例外要因のビット数（TEXPTNの有効ビッ
ト数）

タスク例外処理ルーチン定義情報およびタスク例外処理状態のパケット形式
として，次のデータ型を定義する．
typedef struct t_dtex {ATR
texatr ;FP
texrtn ;/* タスク例外処理ルーチン属性 *//* タスク例外処理ルーチンの起動番
地 */実装独自に他のフィールドを追加してもよい/**/} T_DTEX ;typedef struct t_rtex {STAT
texstat ;/* タスク例外処理の状態 */TEXPTN
pndptn ; /* 保留例外要因 *//* 実装独自に他のフィールドを追加してもよい */} T_RTEX ;タスク例外処理機能の各サービスコールの機能コードは次の通りである．
TFN_DEF_TEX
TFN_RAS_TEX
TFN_IRAS_TEX
TFN_DIS_TEX
TFN_ENA_TEX
TFN_SNS_TEX
TFN_REF_TEX

–0x1b
–0x1c
–0x74
–0x1d
–0x1e
–0x1f
–0x20

def_texの機能コード
ras_texの機能コード
iras_tex の機能コード
dis_tex の機能コード
ena_tex の機能コード
sns_texの機能コード
ref_texの機能コード【スタンダードプロファイル】
スタンダードプロファイルでは，タスク例外処理ルーチンを動的に定義する機能（def_tex），タスク例外処理の状態を参照する機能（ ref_tex）を除いて，タスク例外処理機能をサポートしなければならない．
スタンダードプロファイルでは，タスク例外処理機能で用いるデータ型の有効ビット数を次の通りに定める．
TEXPTN

16 ビット以上したがって，TBIT_TEXPTNは 16 以上でなければならない．

118

µITRON4.0 仕様

Ver. 4.01.00【補足説明】
この仕様の範囲内では，CPUロック状態でタスク例外処理ルーチンを起動すべ
き条件が揃うことはない．それに対して，ディスパッチ禁止状態でタスク例外
処理ルーチンを起動すべき条件が揃うことはあり，その場合には，タスク例外
処理ルーチンを起動しなければならない．
タスク例外処理ルーチンを実行するコンテキストと状態については，次のように整理できる．
• タスク例外処理ルーチンは，タスクと同じコンテキストで実行する（3.5.1節参照）．タスク例外処理ルーチンを実行するコンテキストは，タスクコンテ
キストに分類される．
• タスク例外処理ルーチンの起動と，そこからのリターンによって，CPUロック／ロック解除状態とディスパッチ禁止／許可状態は変化しない（3.5.4節と3.5.5 節を参照）．ただし，CPUロック状態でタスク例外処理ルーチンを起動するかどうかは規定されない．
タスク例外処理禁止／許可状態が変化する状況は，次のように整理できる．
• タスク起動時には，タスク例外処理禁止状態とする．
• タスク例外処理ルーチンの起動時に，タスク例外処理禁止状態とし，タスク
例外処理ルーチンからのリターン時に，タスク例外処理許可状態に戻す．
• dis_tex が呼び出されると，タスク例外処理禁止状態とし，ena_tex が呼び出されると，タスク例外処理許可状態とする．
• def_tex によりタスク例外処理ルーチンの定義が解除されると，タスク例外
処理禁止状態とする．
タスク例外処理ルーチンはタスクと同じコンテキストで実行するため，C言語の標準ライブラリ関数の longjmpを用いて，タスク例外処理ルーチンから大域脱出することができる．この場合カーネルは，タスク例外処理ルーチンが終了したことを検知できないため，タスク例外処理許可状態には戻さない．タスク
例外処理許可状態に戻したい場合には，アプリケーションで ena_texを呼び出して，タスク例外処理を許可する必要がある．また，タスク例外処理ルーチンからの大域脱出を用いる場合，グローバルなデータ構造の一貫性が失われる間は，タスク例外処理を禁止する必要がある（仕様決定の理由を参照）．
タスク例外処理ルーチンからリターンした直後に再びタスク例外処理ルーチ
ンを起動する場合，タスク例外処理ルーチンの実行開始直後のスタックポイン
タの値が，最初に起動した時の値と同じでなければならない．つまり，タスク
例外処理ルーチンの再起動により，スタック上に無駄な領域が残ってはならな
い．さもないと，タスク例外処理ルーチンの連続起動によって使用されるス
タック領域の上限サイズを押さえることができなくなる．
µITRON4.0 仕様では，タスク例外要因毎に例外をマスクする機能は用意していないが，仕様に規定された機能を用いて，アプリケーションで同等の機能を実現することができる．具体的には，タスク毎のタスク例外処理マスクをアプリ
119

µITRON4.0 仕様

Ver. 4.01.00

ケーションで管理し，タスク例外処理ルーチンの先頭で，渡された例外要因がマスクされているかどうかを調べる．マスクされていた場合には，その例外要因でタスク例外処理ルーチンが起動された旨を記録して，すぐにリターンする（実際には，マスクされた例外要因とマスクされていない例外要因が重なった場合に対応する必要がある）．後でタスク例外処理マスクを解除する時点で，マスクを解除する例外要因でタスク例外処理ルーチンが起動された記録があるか調べ，記録がある場合にはその時点でタスク例外処理ルーチンを呼び出す．
タスク例外処理ルーチンを起動する時にタスク例外処理を禁止するため，そのままでは，タスク例外処理ルーチンは多重起動されない．タスク例外処理ルー
チンが複雑になる場合（特に，内部で待ち状態になる場合）には，タスク例外
処理ルーチンの実行中に発生した例外により，タスク例外処理ルーチンを多重に起動したいケースが考えられる．このような場合には，タスク例外処理ルー
チン内で ena_tex を呼び出してタスク例外処理を許可することで，タスク例外
処理ルーチンの多重起動を実現することができる．この時，タスク例外処理
ルーチンが無際限に多重起動することを防ぐための仕組みが必要である．例えば，上述のタスク例外要因毎にマスクする方法を併用し，処理中の例外要因をマスクする方法などが考えられる．
また，タスク例外処理ルーチンを起動する時にタスク例外処理を禁止するため，タスク例外処理ルーチン中で CPU 例外が発生した場合，CPU例外ハンドラ
からタスク例外処理を要求しても，CPU例外ハンドラからリターンすると元の処理が継続してしまう．この時，CPU 例外ハンドラ内で CPU例外を発生させた要因が取り除かれないと，リターン直後に再度 CPU 例外が発生し，CPU例外の発生を無際限に繰り返すおそれがある．同様のことは，タスク例外処理禁止状
態で発生した CPU例外すべてにあてはまる．
そこで，基本的には，CPU例外ハンドラからタスク例外処理を要求する場合には，タスク例外処理を禁止している間は CPU例外が発生しないようにすることが必要である．ただし，ソフトウェアのバグやハードウェアの誤動作で CPU例
外の発生が避けられない場合もあり，このような場合にも CPU例外が無際限に発生するのを避けるには，CPU 例外ハンドラ中で CPU例外を発生させたタスクのタスク例外処理禁止状態を参照し，禁止状態であった場合には特別な処理を行う必要がある．また，必要なら上記の方法でタスク例外処理ルーチンの多重起動を可能にするなどして，タスク例外処理を禁止する区間を短く押さえることも必要であろう．
アプリケーションとカーネルでスタックを切り替える実装では，タスク例外処
理ルーチンの多重起動を可能にするために，カーネルスタックまたはタスク制
御ブロック（ TCB；Task Control Block）に保存した情報をアプリケーションス
タックに移動させる必要が生ずる場合が多い．例えば，タスクがプリエンプトされている状態でタスク例外処理が要求され，次にそのタスクが実行状態となった時点でタスク例外処理ルーチンを起動する場合には，プリエンプト直前の状態（一般的には，カーネルスタックか TCB に保存されている）をアプリ
120

µITRON4.0 仕様

Ver. 4.01.00

ケーションスタックに積み直し，タスク例外処理ルーチンからのリターン時に，アプリケーションスタックに積まれた情報を元にプリエンプト直前の状態に戻す必要がある．
【µITRON3.0 仕様との相違】
タスク例外処理機能は，µITRON4.0 仕様において新たに導入した機能である．
【仕様決定の理由】µITRON4.0 仕様では，カーネルでは単純なタスク例外処理機能のみを提供し，より高度な機能が必要な場合にはアプリケーションでそれを実現できるように工夫した．これにより，カーネルをコンパクトに保ったまま，アプリケー
ションの高度な要求にも対応できるようにすることを狙っている．
仕様の本体では，タスク例外処理ルーチンはタスクと同じコンテキストで実行されるという記述にとどめ，longjmpによる大域脱出への言及を補足説明としたのは，以下 で述べる理 由により，タス ク例外処 理ルーチン から安易に
longjmp を使うのは危険なためである．また，スタンダードプロファイルの適用範囲を考えると，タスク例外処理ルーチンから強制脱出する方法は，タスクの終了（ext_tsk）のみで十分であると考えたためである．
タスク例外処理ルーチンから安易に longjmpを使うと，例えば，グローバルな
データ構造を操作する関数の実行途中にタスク例外処理ルーチンが起動され，起動されたタスク例外処理ルーチン中から longjmpで大域脱出すると，操作中のデータ構造の一貫性が保たれなくなる可能性がある．このようなケースを考えると，タスク例外処理ルーチン中から longjmp で大域脱出する方法は，かなりの注意を払わない限り危険であるということができる．具体的には，データ構造の一貫性が失われる間は，タスク例外処理を禁止しなければならない．

121

µITRON4.0 仕様

DEF_TEX
def_texVer. 4.01.00

タスク例外処理ルーチンの定義（静的 API）

【S】

タスク例外処理ルーチンの定義【静的 API】
DEF_TEX ( ID tskid, { ATR texatr, FP texrtn } ) ;【C 言語 API】
ER ercd = def_tex ( ID tskid, T_DTEX *pk_dtex ) ;【パラメータ】
ID
T_DTEX *tskid
pk_dtex

定義対象のタスクの ID 番号
タスク例外処理ルーチン定義情報を入れたパケットへのポインタ（ DEF_TEXではパケットの内容を直接記述する）

pk_dtexの内容（ T_DTEX型）
ATR
texatr
タスク例外処理ルーチン属性FP
texrtn
タスク例外処理ルーチンの起動番地（実装独自に他の情報を追加してもよい）【リターンパラメータ】
ER
ercd【エラーコード】
E_ID
E_NOEXSE_RSATR
E_PAR

正常終了（E_OK）またはエラーコード

不正 ID 番号（tskidが不正あるいは使用できない）
オブジェクト未生成（対象タスクが未登録）
予約属性（texatrが不正あるいは使用できない）
パラメータエラー（pk_dtex， texrtn が不正）【機能】
tskid で指定されるタスクに，pk_dtex で指定されるタスク例外処理ルーチン
定義情報に基づいて，タスク例外処理ルーチンを定義する．texatrはタスク例
外処理ルーチンの属性，texrtnはタスク例外処理ルーチンの起動番地である．
DEF_TEXにおいては，tskidは自動割付け非対応整数値パラメータ，texatrはプリプロセッサ定数式パラメータである．
pk_dtex に NULL（＝ 0）が指定されると，すでに定義されているタスク例外処
理ルーチンの定義を解除し，タスク例外処理ルーチンが定義されていない状態にする．この時，タスクの保留例外要因を 0にクリアし，タスクをタスク例外
処理禁止状態に移行させる．また，すでにタスク例外処理ルーチンが定義されているタスクに対して，再度タスク例外処理ルーチンが定義された場合には，以前の定義を解除し，新しい定義に置き換える．この時には，保留例外要因のクリアとタスク例外処理の禁止は行わない．
def_tex は，tskid に TSK_SELF（＝ 0）が指定されると，自タスクを対象タス
122

µITRON4.0 仕様

Ver. 4.01.00

クとする．
texatrには，（TA_HLNG‖ TA_ASM）の指定ができる．TA_HLNG（＝ 0x00）が指定された場合には高級言語用のインタフェースで，TA_ASM（＝ 0x01）が指定された場合にはアセンブリ言語用のインタフェースでタスク例外処理
ルーチンを起動する．
【スタンダードプロファイル】
texatrに TA_ASMが指定された場合の機能はスタンダードプロファイルでは，サポートする必要がない．
【補足説明】
一度定義されたタスク例外処理ルーチンは，pk_dtex に NULL が指定されて
def_tex が呼び出されるか，タスクが削除されるまで有効である．
DEF_TEX によりタスク例外処理ルーチンを定義する対象タスクは，システム
コンフィギュレーションファイル中で，それより前に記述された CRE_TSKで生成されたものでなければならない．
【仕様決定の理由】
タスク例外処理ルーチンの定義を解除する時に，保留例外要因のクリアとタス
ク例外処理の禁止を行うのは，タスク例外処理ルーチンが定義されていない時には，保留例外要因が 0でタスク例外処理が禁止された状態を保つためである（タスク例外処理ルーチンが定義されていない時には，保留例外要因がセットされることはなく，タスク例外処理を許可することもできないため，この状態が保たれる）．

123

µITRON4.0 仕様

ras_texiras_texVer. 4.01.00

タスク例外処理の要求

【S】
【S】

【C 言語 API】
ER ercd = ras_tex ( ID tskid, TEXPTN rasptn ) ;ER ercd = iras_tex ( ID tskid, TEXPTN rasptn ) ;【パラメータ】
ID
TEXPTN

tskid
rasptn【リターンパラメータ】
ER
ercd【エラーコード】
E_ID
E_NOEXS
E_PAR
E_OBJ

要求対象のタスクの ID 番号
要求するタスク例外処理のタスク例外要因
正常終了（E_OK）またはエラーコード

不正 ID 番号（tskidが不正あるいは使用できない）
オブジェクト未生成（対象タスクが未登録）
パラメータエラー（rasptnが不正）オブジェクト状態エラー（対象タスクが休止状態，対象
タスクにタスク例外処理ルーチンが定義されていない）【機能】
tskid で指定されるタスクに対して，rasptn で指定されるタスク例外要因によって，タスク例外処理を要求する．すなわち，対象タスクの保留例外要因
を，サービスコール呼出し前の保留例外要因と rasptn の値のビット毎の論理和に更新する．
tskidに TSK_SELF（＝ 0）が指定されると，自タスクを対象タスクとする．ただし，非タスクコンテキストからの呼出しでこの指定が行われた場合には，
E_IDエラーを返す．
対象タスクが休止状態の時は E_OBJ エラーを返す．また，対象タスクにタス
ク例外処理ルーチンが定義されていない場合にも，E_OBJ エラーを返す．非タスクコンテキストから呼び出された場合で，サービスコールを遅延実行する
場合には，E_OBJエラーを返すことを，実装定義で省略することができる．
rasptnに 0 が指定された場合には，E_PAR エラーを返す．
【補足説明】
このサービスコールにより，タスク例外処理ルーチンを起動する条件が揃った
場合には，タスク例外処理ルーチンを起動する処理を行う．
このサービスコールでは，対象タスクが広義の待ち状態である場合に，保留例
外要因の更新のみを行い，待ち解除や強制待ちからの再開は行わない．待ち解除や強制待ちからの再開を行う必要がある場合には，それぞれ rel_wai や
frsm_tsk（または rsm_tsk）を用いる．
124

µITRON4.0 仕様

Ver. 4.01.00

非タスクコンテキストから呼び出されたサービスコールを遅延実行する場合に，ディスパッチが起こる状態となるまで実行を遅延できるサービスコールが多いが，このサービスコールはディスパッチ禁止状態でも実行しなければならない．具体的な例として，ディスパッチ禁止状態で起動された割込みハンドラ
で，実行状態のタスクを対象タスクとしてタスク例外処理が要求された場合には，割込みハンドラからのリターン直後にタスク例外処理ルーチンを起動しなければならない．これを使うと，ディスパッチ禁止状態で暴走するタスクに対して，割込みハンドラからタスク例外処理を要求することによって，暴走を止めることができる．ただし，CPU ロック状態で暴走するタスクや，ディスパッ
チに加えてタスク例外処理も禁止した状態で暴走するタスクは，この方法で止めることはできない．

125

µITRON4.0 仕様

dis_texVer. 4.01.00

タスク例外処理の禁止【S】【C 言語 API】
ER ercd = dis_tex ( ) ;【パラメータ】
なし【リターンパラメータ】
ER
ercd【エラーコード】
E_OBJ

正常終了（E_OK）またはエラーコード

オブジェクト状態エラー（自タスクにタスク例外処理
ルーチンが定義されていない）【機能】
自タスクを，タスク例外処理禁止状態に移行させる．自タスクにタスク例外処
理ルーチンが定義されていない場合には，E_OBJエラーを返す．

126

µITRON4.0 仕様

ena_texVer. 4.01.00

タスク例外処理の許可【 S】【C 言語 API】
ER ercd = ena_tex ( ) ;【パラメータ】
なし【リターンパラメータ】
ER
ercd【エラーコード】
E_OBJ
E_CTX

正常終了（E_OK）またはエラーコード

オブジェクト状態エラー（自タスクにタスク例外処理
ルーチンが定義されていない）
コンテキストエラー（タスク例外処理を許可してはならないコンテキストからの呼出し，その他のコンテキスト
エラー）

【機能】
自タスクを，タスク例外処理許可状態に移行させる．自タスクにタスク例外処
理ルーチンが定義されていない場合には，E_OBJエラーを返す．
拡張サービスコールルーチン内でタスク例外処理を許可してはならない実装
で，このサービスコールが拡張サービスコールルーチンから呼び出された場合には，E_CTX エラーを返す．
【補足説明】
このサービスコールにより，タスク例外処理ルーチンを起動する条件が揃った
場合には，タスク例外処理ルーチンを起動する処理を行う．

127

µITRON4.0 仕様

sns_texVer. 4.01.00

タスク例外処理禁止状態の参照【S】【C 言語 API】
BOOL state = sns_tex ( ) ;【パラメータ】
なし【リターンパラメータ】
BOOL
state

タスク例外処理禁止状態【機能】
実行状態のタスク（タスクコンテキストから呼び出された場合は，自タスクに一致する）が，タスク例外処理禁止状態の場合に TRUE，タスク例外処理許可
状態の場合に FALSEを返す．非タスクコンテキストから呼び出された場合で，実行状態のタスクがない時には，TRUE を返す．
【補足説明】
タスク例外処理ルーチンが定義されていないタスクは，タスク例外処理禁止状
態に保たれているため，実行状態のタスクにタスク例外処理ルーチンが定義されていない場合には，このサービスコールは TRUEを返す．

128

µITRON4.0 仕様

ref_texVer. 4.01.00

タスク例外処理の状態参照【C 言語 API】
ER ercd = ref_tex ( ID tskid, T_RTEX *pk_rtex ) ;【パラメータ】
ID
T_RTEX *tskid
pk_rtex【リターンパラメータ】
ER
ercd

状態参照対象のタスクの ID番号
タスク例外処理状態を返すパケットへのポイ
ンタ
正常終了（E_OK）またはエラーコード

pk_rtexの内容（ T_RTEX型）
タスク例外処理の状態
STAT
texstat
保留例外要因TEXPTN
pndptn（実装独自に他の情報を追加してもよい）【エラーコード】
E_ID
E_NOEXS
E_PAR
E_OBJ

不正 ID 番号（tskidが不正あるいは使用できない）
オブジェクト未生成（対象タスクが未登録）
パラメータエラー（pk_rtex が不正）オブジェクト状態エラー（対象タスクが休止状態，対象
タスクにタスク例外処理ルーチンが定義されていない）【機能】
tskidで指定されるタスクの，タスク例外処理に関する状態を参照し，pk_rtex
で指定されるパケットに返す．
texstat には，対象タスクがタスク例外処理許可状態かタスク例外処理禁止状
態かによって，次のいずれかの値を返す．
TTEX_ENATTEX_DIS

0x00
0x01

タスク例外処理許可状態
タスク例外処理禁止状態

pndptn には，対象タスクの保留例外要因を返す．処理されていない例外処理要求がないときには，pndptn には 0を返す．
tskidに TSK_SELF（＝ 0）が指定されると，自タスクを対象タスクとする．
対象タスクが休止状態の時は，E_OBJ エラーを返す．また，対象タスクにタ
スク例外処理ルーチンが定義されていない場合にも，E_OBJエラーを返す．

129

µITRON4.0 仕様

Ver. 4.01.00

4.4 同期・通信機能
同期・通信機能は，タスクとは独立したオブジェクトにより，タスク間の同期・通信を行うための機能である．セマフォ，イベントフラグ，データキュー，
メールボックスの各機能が含まれる．
【µITRON3.0 仕様との相違】
メールボックスの実現方法をリンクリストを使う方法に限定し，リングバッファで実現したメールボックスと同等のデータキューの機能を新たに導入した．

4.4.1 セマフォ
セマフォは，使用されていない資源の有無や数量を数値で表現することにより，その資源を使用する際の排他制御や同期を行うためのオブジェクトである．セマフォ機能には，セマフォを生成／削除する機能，セマフォの資源を獲得／返却する機能，セマフォの状態を参照する機能が含まれる．セマフォは ID
番号で識別されるオブジェクトである．セマフォの ID 番号をセマフォ IDと呼ぶ．
セマフォは，対応する資源の有無や数量を表現する資源数と，資源の獲得を待つタスクの待ち行列を持つ．資源を返却する側（イベントを知らせる側）では，セマフォの資源数を 1つ増やす．一方，資源を獲得する側（イベントを待つ側）では，セマフォの資源数を 1つ減らす．セマフォの資源数が足りなくなった場合（具体的には，資源数を減らすと資源数が負になる場合），資源を獲得しようとしたタスクは，次に資源が返却されるまでセマフォ資源の獲得待ち状態となる．セマフォ資源の獲得待ち状態になったタスクは，そのセマフォの待ち行列につながれる．
また，セマフォに対して資源が返却され過ぎるのを防ぐために，セマフォ毎に最大資源数を設定することができる．最大資源数を越える資源がセマフォに返却されようとした場合（具体的には，セマフォの資源数を増やすと最大資源数を越える場合）には，エラーを報告する．
セマフォ機能に関連して，次のカーネル構成定数を定義する．
TMAX_MAXSEM

セマフォの最大資源数の最大値

セマフォ生成情報およびセマフォ状態のパケット形式として，次のデータ型を定義する．
typedef struct t_csem {ATR
sematr ;/* セマフォ属性 */UINT
isemcnt ; /* セマフォの資源数の初期値 */UINTmaxsem ; /* セマフォの最大資源数 *//* 実装独自に他のフィールドを追加してもよい */} T_CSEM ;typedef struct t_rsem {130

µITRON4.0 仕様
ID

Ver. 4.01.00
wtskid ;/* セマフォの待ち行列の先頭のタスクの ID番号 */UINTsemcnt ; /* セマフォの現在の資源数 *//* 実装独自に他のフィールドを追加してもよい */} T_RSEM ;セマフォ機能の各サービスコールの機能コードは次の通りである．
TFN_CRE_SEM
TFN_ACRE_SEM
TFN_DEL_SEM
TFN_SIG_SEM
TFN_ISIG_SEM
TFN_WAI_SEM
TFN_POL_SEM
TFN_TWAI_SEM
TFN_REF_SEM

–0x21
–0xc2
–0x22
–0x23
–0x75
–0x25
–0x26
–0x27
–0x28

cre_sem の機能コード
acre_sem の機能コード
del_semの機能コード
sig_semの機能コード
isig_semの機能コード
wai_semの機能コード
pol_sem の機能コード
twai_sem の機能コード
ref_sem の機能コード【スタンダードプロファイル】
スタンダード プロファイルでは，セ マフォを動的に生 成／削除する機能（cre_sem，acre_sem，del_sem），セマフォの状態を参照する機能（ref_sem）
を除いて，セマフォ機能をサポートしなければならない．
スタンダードプロファイルでは，セマフォの最大資源数として，少なくとも65535 以上の値が指定できなければならない．スタンダードプロファイルでは
TMAX_MAXSEM を定義する必要はないが，定義する場合には 65535以上の値となる．
【仕様決定の理由】
スタンダードプロファイルで TMAX_MAXSEM を定義する必要がないとしたのは，TMAX_MAXSEMを参照する必要があるのはセマフォを生成する時であるのに対して，スタンダードプロファイルではセマフォを動的に生成する機能をサポートする必要がないためである．

131

µITRON4.0 仕様

CRE_SEM
cre_sem
acre_semVer. 4.01.00

セマフォの生成（静的 API）

【S】

セマフォの生成セマフォの生成（ID番号自動割付け）【静的 API】
CRE_SEM ( ID semid, { ATR sematr, UINT isemcnt,
UINT maxsem } ) ;【C 言語 API】
ER ercd = cre_sem ( ID semid, T_CSEM *pk_csem ) ;ER_ID semid = acre_sem ( T_CSEM *pk_csem ) ;【パラメータ】
生成対象のセマフォの ID番号
（acre_sem以外）
ID
semid
T_CSEM * pk_csem セマフォ生成情報を入れたパケットへのポイ
ンタ（CRE_SEMではパケットの内容を直接記述する）
pk_csemの内容（ T_CSEM 型）
セマフォ属性ATR
sematrUINT
isemcnt セマフォの資源数の初期値
UINT
maxsem セマフォの最大資源数（実装独自に他の情報を追加してもよい）【リターンパラメータ】
cre_semの場合
ER
ercd
acre_semの場合
ER_ID
semid
【エラーコード】
E_ID
E_NOID
E_RSATR
E_PAR
E_OBJ

正常終了（E_OK）またはエラーコード
生成したセマフォの ID 番号（正の値）またはエ
ラーコード

不正 ID 番号（semid が不正あるいは使用できない；
cre_semのみ）（割付け可能なセマフォIDがない；acre_sem
ID番号不足のみ）
予約属性（sematrが不正あるいは使用できない）
パラメータエラー（pk_csem，isemcnt，maxsemが不正）
オブジェクト状態エラー（対象セマフォが登録済み；
cre_semのみ）

132

µITRON4.0 仕様

Ver. 4.01.00【機能】
semidで指定されるID番号を持つセマフォを，pk_csemで指定されるセマフォ
生成情報に基づいて生成する．sematrはセマフォの属性，isemcntはセマフォ
生成後の資源数の初期値，maxsem はセマフォの最大資源数である．
CRE_SEM においては，semid は自動割付け対応整数値パラメータ，sematr
はプリプロセッサ定数式パラメータである．
acre_sem は，生成するセマフォの ID番号をセマフォが登録されていない ID番
号の中から割り付け，割り付けた ID 番号を返値として返す．
sematrには，（TA_TFIFO‖ TA_TPRI）の指定ができる．セマフォの待ち行列
は，TA_TFIFO（＝ 0x00）が指定された場合には FIFO順，TA_TPRI（＝ 0x01）が指定された場合にはタスクの優先度順となる．
isemcntに maxsemよりも大きい値が指定された場合には，E_PARエラーを返す．また，maxsem に 0 が指定された場合や，セマフォの最大資源数の最大値（TMAX_MAXSEM）よりも大きい値が指定された場合にも，E_PARエラーを返す．
【µITRON3.0 仕様との相違】
セマフォ生成情報から拡張情報を削除した．また，isemcntと maxsemのデー
タ型を INTから UINTに変更した．
acre_sem は新設のサービスコールである．

133

µITRON4.0 仕様

del_semVer. 4.01.00

セマフォの削除【C 言語 API】
ER ercd = del_sem ( ID semid ) ;【パラメータ】
ID

semid【リターンパラメータ】
ER
ercd【エラーコード】
E_ID
E_NOEXS

削除対象のセマフォの ID 番号
正常終了（E_OK）またはエラーコード

不正 ID 番号（semid が不正あるいは使用できない）
オブジェクト未生成（対象セマフォが未登録）【機能】
semid で指定されるセマフォを削除する．
【補足説明】
対象セマフォに対して資源の獲得を待っているタスクがある場合の扱いについては，3.8 節を参照すること．

134

µITRON4.0 仕様

sig_semisig_semVer. 4.01.00【 S】

セマフォ資源の返却【 S】【C 言語 API】
ER ercd = sig_sem ( ID semid ) ;ER ercd = isig_sem ( ID semid ) ;【パラメータ】
ID

semid【リターンパラメータ】
ER
ercd【エラーコード】
E_ID
E_NOEXSE_QOVR

資源返却対象のセマフォの ID番号
正常終了（E_OK）またはエラーコード

不正 ID 番号（semid が不正あるいは使用できない）
オブジェクト未生成（対象セマフォが未登録）
キューイングオーバフロー（最大資源数を越える返却）【機能】
semid で指定されるセマフォに対して，資源を 1つ返却する．具体的には，対象セマフォに対して資源の獲得を待っているタスクがある場合には，待ち行列の先頭のタスクを待ち解除する．この時，対象セマフォの資源数は変化しな
い．また，待ち解除されたタスクに対しては，待ち状態に入ったサービスコー
ルの返値として E_OK を返す．資源の獲得を待っているタスクがない場合には，対象セマフォの資源数に 1を加える．
セマフォの資源数に 1 を加えるとセマフォの最大資源数を越える場合には，
E_QOVRエラーを返す．非タスクコンテキストから呼び出された場合で，サービスコールを遅延実行する場合には，E_QOVR エラーを返すことを，実装定
義で省略することができる．

135

µITRON4.0 仕様

wai_sem
pol_sem
twai_semVer. 4.01.00

セマフォ資源の獲得【S】

セマフォ資源の獲得（ポーリング）
セマフォ資源の獲得（タイムアウトあり）

【S】
【S】

【C 言語 API】
ER ercd = wai_sem ( ID semid ) ;ER ercd = pol_sem ( ID semid ) ;ER ercd = twai_sem ( ID semid, TMO tmout ) ;【パラメータ】
ID
TMO

semid
tmout

【リターンパラメータ】
ER
ercd【エラーコード】
E_ID
E_NOEXS
E_PAR
E_RLWAIE_TMOUT
E_DLT

資源獲得対象のセマフォの ID 番号
タイムアウト指定（twai_semのみ）
正常終了（E_OK）またはエラーコード

不正 ID 番号（semid が不正あるいは使用できない）
オブジェクト未生成（対象セマフォが未登録）
パラメータエラー（tmoutが不正；twai_sem のみ）
待ち状態の強制解除（待ち状態の間に rel_wai を受付；
pol_sem以外）
ポーリング失敗またはタイムアウト（wai_sem以外）
待ちオブジェクトの削除（待ち状態の間に対象セマフォが削除；pol_sem以外）【機能】
semid で指定されるセマフォから，資源を 1つ獲得する．具体的には，対象セ
マフォの資源数が 1 以上の場合には，セマフォの資源数から 1 を減じ，自タス
クを待ち状態とせずにサービスコールの処理を終了する．対象セマフォの資源数が 0の場合には，自タスクを待ち行列につなぎ，セマフォ資源の獲得待ち状態に移行させる．この時，対象セマフォの資源数は 0 のまま変化しない．
他のタスクがすでに待ち行列につながっている場合，自タスクを待ち行列につなぐ処理は次のように行う．セマフォ属性に TA_TFIFO（＝ 0x00）が指定されている場合には，自タスクを待ち行列の末尾につなぐ．TA_TPRI（＝ 0x01）が指定されている場合には，自タスクを優先度順で待ち行列につなぐ．同じ優先度のタスクの中では，自タスクを最後につなぐ．
pol_semは，wai_sem の処理をポーリングで行うサービスコール，twai_sem
は，wai_sem にタイムアウトの機能を付け加えたサービスコールである．
tmout には，正の 値のタイム アウト時間 に加えて，TMO_POL（＝ 0）とTMO_FEVR（＝ –1）を指定することができる．

136

µITRON4.0 仕様

Ver. 4.01.00【補足説明】
twai_semは，tmoutに TMO_POL が指定された場合，E_CTXエラーにならな
い限りは pol_sem と全く同じ動作をする．また，tmout に TMO_FEVRが指定された場合は，wai_sem と全く同じ動作をする．
【µITRON3.0 仕様との相違】
サービスコールの名称を，preq_sem から pol_sem に変更した．

137

µITRON4.0 仕様

ref_semVer. 4.01.00

セマフォの状態参照【C 言語 API】
ER ercd = ref_sem ( ID semid, T_RSEM *pk_rsem ) ;【パラメータ】
ID
semid
T_RSEM * pk_rsem

状態参照対象のセマフォの ID 番号
セマフォ状態を返すパケットへのポインタ【リターンパラメータ】
ER
ercd

正常終了（E_OK）またはエラーコード

pk_rsem の内容（T_RSEM型）
セマフォの待ち行列の先頭のタスクの ID 番号ID
wtskidセマフォの現在の資源数
UINT
semcnt（実装独自に他の情報を追加してもよい）【エラーコード】
E_ID
E_NOEXS
E_PAR

不正 ID 番号（semid が不正あるいは使用できない）
オブジェクト未生成（対象セマフォが未登録）
パラメータエラー（pk_rsem が不正）【機能】
semidで指定されるセマフォに関する状態を参照し，pk_rsemで指定されるパケットに返す．
wtskid には，対象セマフォの待ち行列の先頭のタスクの ID 番号を返す．資源の獲得を待っているタスクがない場合には，TSK_NONE（＝ 0）を返す．
semcntには，対象セマフォの現在の資源数を返す．
【補足説明】
wtskid≠ TSK_NONE と semcnt ≠ 0が同時に成立することはない．
【µITRON3.0 仕様との相違】参照できる情報から拡張情報を削除した．待ちタスクの有無ではなく，待ち行
列の先頭のタスクの ID 番号を返すこととした．これに伴って，リターンパラ
メータの名称とデータ型を変更した．
semcntのデータ型を INTから UINTに変更した．また，パラメータとリターン
パラメータの順序を変更した．

138

µITRON4.0 仕様

Ver. 4.01.00

4.4.2 イベントフラグ
イベントフラグは，イベントの有無をビット毎のフラグで表現することにより，同期を行うためのオブジェクトである．イベントフラグ機能には，イベン
トフラグを生成／削除する機能，イベントフラグをセット／クリアする機能，
イベントフラグで待つ機能，イベントフラグの状態を参照する機能が含まれる．イベントフラグは ID 番号で識別されるオブジェクトである．イベントフ
ラグの ID 番号をイベントフラグ ID と呼ぶ．
イベントフラグは，対応するイベントの有無をビット毎に表現するビットパ
ターンと，そのイベントフラグで待つタスクの待ち行列を持つ．イベントフラ
グのビットパターンを，単にイベントフラグと呼ぶ場合もある．イベントを知らせる側では，イベントフラグのビットパターンの指定したビットをセットな
いしはクリアすることが可能である．一方，イベントを待つ側では，イベント
フラグのビットパターンの指定したビットのすべてまたはいずれかがセットされるまで，タスクをイベントフラグ待ち状態にすることができる．イベント
フラグ待ち状態になったタスクは，そのイベントフラグの待ち行列につながれる．
イベントフラグ機能では，次のデータ型を用いる．
FLGPTN

イベントフラグのビットパターン（符号無し整数）

イベントフラグ機能に関連して，次のカーネル構成定数を定義する．
TBIT_FLGPTN

イベントフラグのビット数（FLGPTNの有効ビッ
ト数）

イベントフラグ生成情報およびイベントフラグ状態のパケット形式として，次のデータ型を定義する．
typedef struct t_cflg {ATR
flgatr ;FLGPTN
iflgptn ;/* イベントフラグ属性 *//* イベントフラグのビットパターンの初期値 *//* 実装独自に他のフィールドを追加してもよい */} T_CFLG ;typedef struct t_rflg {IDwtskid ;/* イベントフラグの待ち行列の先頭のタスクの ID番号 */FLGPTN
flgptn ;/* イベントフラグの現在のビットパ
ターン *//* 実装独自に他のフィールドを追加してもよい */} T_RFLG ;イベントフラグ機能の各サービスコールの機能コードは次の通りである．
TFN_CRE_FLG
TFN_ACRE_FLG
TFN_DEL_FLG
TFN_SET_FLG

–0x29
–0xc3
–0x2a
–0x2b

cre_flgの機能コード
acre_flgの機能コード
del_flg の機能コード
set_flgの機能コード
139

µITRON4.0 仕様

Ver. 4.01.00

TFN_ISET_FLG
TFN_CLR_FLG
TFN_WAI_FLG
TFN_POL_FLG
TFN_TWAI_FLG
TFN_REF_FLG

–0x76
–0x2c
–0x2d
–0x2e
–0x2f
–0x30

iset_flg の機能コード
clr_flgの機能コード
wai_flgの機能コード
pol_flg の機能コード
twai_flg の機能コード
ref_flg の機能コード【スタンダードプロファイル】
スタンダードプロファイルでは，イベントフラグを動的に生成／削除する機能（cre_flg，acre_flg，del_flg），イベントフラグの状態を参照する機能（ref_flg）
を除いて，イベントフラグ機能をサポートしなければならない．
スタンダードプロファイルでは，イベントフラグで複数のタスクが待ち状態になる機能（イベントフラグ属性の TA_WMUL指定）をサポートする必要はない．
スタンダードプロファイルでは，
イベントフラグのビット数は 16ビット以上でなければならない．したがって，TBIT_FLGPTN は 16 以上でなければならない．また，イベントフラグ機能で用いるデータ型の有効ビット数は次の通りとなる．
FLGPTN

16 ビット以上【補足説明】
スタンダードプロファイル以外では，イベントフラグのビット数に対する制限はない．したがって，1 ビットのイベントフラグ機能を提供することも許される．C 言語では任意ビット数の整数型を扱うことができないため，このような場合には，FLGPTN の有効ビット数（＝ TBIT_FLGPTN）は実装で定義されるデータ型のビット数と一致しなくなる．
【µITRON3.0 仕様との相違】
イベントフラグのビットパターンを入れるパラメータおよびリターンパラ
メータのデータ型を，UINT から専用のデータ型として新設した FLGPTNに変
更した．

140

µITRON4.0 仕様

CRE_FLG
cre_flg
acre_flg

Ver. 4.01.00

イベントフラグの生成（静的 API）

【 S】

イベントフラグの生成
イベントフラグの生成（ ID番号自動割付け）【静的 API】
CRE_FLG ( ID flgid, { ATR flgatr, FLGPTN iflgptn } ) ;【C 言語 API】
ER ercd = cre_flg ( ID flgid, T_CFLG *pk_cflg ) ;ER_ID flgid = acre_flg ( T_CFLG *pk_cflg ) ;【パラメータ】
ID
T_CFLG *flgid
pk_cflg

生成対象のイベントフラグの ID 番号（acre_flg
以外）
イベントフラグ生成情報を入れたパケットへのポインタ（CRE_FLGではパケットの内容を直接記述する）

pk_cflg の内容（T_CFLG 型）
ATR
flgatr
イベントフラグ属性
FLGPTN
iflgptn
イベントフラグのビットパターンの初期値（実装独自に他の情報を追加してもよい）【リターンパラメータ】
cre_flg の場合
ER
ercd
acre_flg の場合
ER_ID
flgid
【エラーコード】
E_ID
E_NOID
E_RSATR
E_PAR
E_OBJ

正常終了（E_OK）またはエラーコード
生成したイベントフラグの ID番号（正の値）またはエラーコード

不正 ID 番号（flgidが不正あるいは使用できない；cre_flg
のみ）
ID 番号不足（割付け可能なイベントフラグ ID がない；
acre_flg のみ）
予約属性（flgatr が不正あるいは使用できない）
パラメータエラー（pk_cflg，iflgptnが不正）オブジェクト状態エラー（対象イベントフラグが登録済
み；cre_flg のみ）【機能】
flgid で指定される ID 番号を持つイベントフラグを，pk_cflgで指定されるイベ
ントフラグ生成情報に基づいて生成する． flgatr はイベントフラグの属性，
141

µITRON4.0 仕様

Ver. 4.01.00

iflgptnはイベントフラグ生成後のビットパターンの初期値である．
CRE_FLG においては，flgid は自動割付け対応整数値パラメータ，flgatrはプ
リプロセッサ定数式パラメータである．
acre_flgは，生成するイベントフラグの ID番号をイベントフラグが登録されていない ID 番号の中から割り付け，割り付けた ID 番号を返値として返す．
（（TA_TFIFO ‖ TA_TPRI）｜（TA_WSGL ‖ TA_WMUL）｜
flgatr には，［TA_CLR］）の指定ができる．イベントフラグの待ち行列は，TA_TFIFO（＝0x00）が指定された場合には FIFO 順，TA_TPRI（＝ 0x01）が指定された場合にはタスクの優先度順となる．TA_WSGL（＝ 0x00）が指定された場合には，一つのイベントフラグで同時に複数のタスクが待ち状態となることを許さな
い．TA_WMUL（＝ 0x02）が指定された場合には，同時に複数のタスクが待ち状態になることを許す．TA_CLR（＝ 0x04）が指定された場合には，タスクをイベントフラグ待ち状態から待ち解除する時に，イベントフラグのビットパ
ターンのすべてのビットをクリアする．
【スタンダードプロファイル】
スタンダードプロファイルでは，flgatrに TA_WMULが指定された場合の機能はサポートする必要がない．
【補足説明】
イベントフラグ待ち状態のタスクは，待ち解除条件を満たせば待ち行列の先頭ではなくても待ち解除されるため，待ち行列につながれた順序で待ち解除されるとは限らない．例えば，TA_TFIFO属性のイベントフラグの場合でも，待ち状態のタスクが FIFO 順で待ち解除されるわけではない．
flgatrに TA_WSGL が指定された場合には，TA_TFIFO と TA_TPRIのどちらを指定しても，イベントフラグの振舞いは同じである．
TA_CLR属性のイベントフラグの場合，タスクを一つ待ち解除した時点でイベントフラグのすべてのビットをクリアするため，複数のタスクを同時に待ち解除することはない．
【µITRON3.0 仕様との相違】
イベントフラグのクリア指定を，wai_flgの待ちモードで指定する方法から，イベントフラグ属性で指定する方法に変更した．これは，一つのイベントフラグ
で，クリア指定付きの待ちとクリア指定無しの待ちが混在することはほとんどないと考えたためである．
イベントフラグ属性（TA_TPRI）により，イベントフラグの待ち行列をタスクの優先度順とする機能を追加した．
イベントフラグ生成情報から拡張情報を削除した．iflgptnのデータ型を UINTから FLGPTNに変更した．また，TA_WMULの値を変更した．
acre_flgは新設のサービスコールである．

142

µITRON4.0 仕様

del_flg

Ver. 4.01.00

イベントフラグの削除【C 言語 API】
ER ercd = del_flg ( ID flgid ) ;【パラメータ】
ID

flgid【リターンパラメータ】
ER
ercd【エラーコード】
E_ID
E_NOEXS

削除対象のイベントフラグの ID番号
正常終了（E_OK）またはエラーコード

不正 ID 番号（flgidが不正あるいは使用できない）
オブジェクト未生成（対象イベントフラグが未登録）【機能】
flgid で指定されるイベントフラグを削除する．
【補足説明】
対象イベントフラグで待っているタスクがある場合の扱いについては，3.8 節を参照すること．

143

µITRON4.0 仕様

set_flg
iset_flg

Ver. 4.01.00

イベントフラグのセット

【S】
【S】

【C 言語 API】
ER ercd = set_flg ( ID flgid, FLGPTN setptn ) ;ER ercd = iset_flg ( ID flgid, FLGPTN setptn ) ;【パラメータ】
ID
FLGPTN

flgid
setptn【リターンパラメータ】
ER
ercd【エラーコード】
E_ID
E_NOEXS
E_PAR

セット対象のイベントフラグの ID 番号
セットするビットパターン
正常終了（E_OK）またはエラーコード

不正 ID 番号（flgid が不正あるいは使用できない）
オブジェクト未生成（対象イベントフラグが未登録）
パラメータエラー（setptn が不正）【機能】
flgidで指定されるイベントフラグに対して，
setptnで指定されるビットをセットする．具体的には，対象イベントフラグのビットパターンを，サービスコー
ル呼出し前のビットパターンと setptn の値のビット毎の論理和に更新する．
対象イベントフラグのビットパターンが更新された結果，そのイベントフラグ
で待っているタスクの待ち解除条件を満たした場合には，該当するタスクを待ち解除する．具体的には，イベントフラグの待ち行列の先頭のタスクから順に待ち解除条件を満たしているかを調べ，待ち解除条件を満たしているタスクが見つかれば，そのタスクを待ち解除する．また，待ち解除されたタスクに対しては，待ち状態に入ったサービスコールの返値として E_OK を返し，待ち解除時のビットパターンとして，この時の（待ち解除条件を満たした）ビットパ
ターンを返す．またこの時，対象イベントフラグ属性に TA_CLR（＝ 0x04）が指定されている場合には，イベントフラグのビットパターンのすべてのビットをクリアし，サービスコールの処理を終了する．TA_CLRが指定されていない
場合には，待ち行列のさらに後ろのタスクについても待ち解除の条件を満たしているかを調べ，待ち行列の最後のタスクまで調べた時点で終了する．待ち解
除条件については，wai_flg の機能説明を参照すること．
イベントフラグ属性に TA_WMUL（＝ 0x02）が指定されており，TA_CLRが指定されていない場合，set_flgの一回の呼出しで複数のタスクが待ち解除される可能性がある．この場合，待ち解除されるタスクが複数ある場合には，イベン
トフラグの待ち行列につながれていた順序で待ち解除される．そのため，実行可能状態に移行したタスクで同じ優先度を持つものの間では，待ち行列の中で前につながれていたタスクの方が高い優先順位を持つことになる．
144

µITRON4.0 仕様

Ver. 4.01.00【補足説明】
setptn の全ビットが 0の場合には，何もしない．
【µITRON3.0 仕様との相違】
setptn のデータ型を UINTから FLGPTN に変更した．

145

µITRON4.0 仕様

clr_flg

Ver. 4.01.00

イベントフラグのクリア【S】【C 言語 API】
ER ercd = clr_flg ( ID flgid, FLGPTN clrptn ) ;【パラメータ】
ID
FLGPTN

flgid
clrptn【リターンパラメータ】
ER
ercd【エラーコード】
E_ID
E_NOEXS
E_PAR

セット対象のイベントフラグの ID 番号
クリアするビットパターン（ビット毎の反転値）
正常終了（E_OK）またはエラーコード

不正 ID 番号（flgid が不正あるいは使用できない）
オブジェクト未生成（対象イベントフラグが未登録）
パラメータエラー（clrptn が不正）【機能】
flgid で指定されるイベントフラグに対して，clrptn の対応するビットが 0 になっているビットをクリアする．具体的には，対象イベントフラグのビットパ
ターンを，サービスコール呼出し前のビットパターンと clrptnの値のビット毎の論理積に更新する．
【補足説明】
clrptn の全ビットが 1の場合には，何もしない．
【µITRON3.0 仕様との相違】
clrptn のデータ型を UINT から FLGPTN に変更した．

146

µITRON4.0 仕様

wai_flg
pol_flg
twai_flg

Ver. 4.01.00

イベントフラグ待ち【 S】

イベントフラグ待ち（ポーリング）
イベントフラグ待ち（タイムアウトあり）

【 S】
【 S】

【C 言語 API】
ER ercd = wai_flg ( ID flgid, FLGPTN waiptn, MODE wfmode,
FLGPTN *p_flgptn ) ;ER ercd = pol_flg ( ID flgid, FLGPTN waiptn, MODE wfmode,
FLGPTN *p_flgptn ) ;ER ercd = twai_flg ( ID flgid, FLGPTN waiptn, MODE wfmode,
FLGPTN *p_flgptn, TMO tmout ) ;【パラメータ】
ID
FLGPTN
MODE
TMO

flgid
waiptnwfmodetmout【リターンパラメータ】
ER
ercd
FLGPTN
flgptn【エラーコード】
E_ID
E_NOEXS
E_PAR
E_ILUSE
E_RLWAIE_TMOUT
E_DLT

待ち対象のイベントフラグの ID番号
待ちビットパターン
待ちモード
タイムアウト指定（twai_flg のみ）
正常終了（E_OK）またはエラーコード
待ち解除時のビットパターン

不正 ID 番号（flgidが不正あるいは使用できない）
オブジェクト未生成（対象イベントフラグが未登録）
パラメータエラー（ waiptn，wfmode，p_flgptn，tmout
が不正）サービスコール不正使用（ TA_WSGL属性が指定されたイベントフラグで待ちタスクあり）
待ち状態の強制解除（待ち状態の間に rel_wai を受付；
pol_flg 以外）
ポーリング失敗またはタイムアウト（wai_flg 以外）
待ちオブジェクトの削除（待ち状態の間に対象イベント
フラグが削除；pol_flg 以外）【機能】
flgidで指定されるイベントフラグのビットパターンが，waiptnとwfmodeで指定される待ち解除条件を満たすのを待つ．flgptn には，待ち解除される時のイ
ベントフラグのビットパターンを返す．具体的な処理内容は次の通りである．
対象イベントフラグのビットパターンが waiptn と wfmode で指定される待ち解除条件を満たしている場合には，自タスクを待ち状態とせずにサービスコー
ルの処理を終了する．flgptnには，この時の（待ち解除条件を満たした）ビッ
147

µITRON4.0 仕様

Ver. 4.01.00

トパターンを返す．またこの時，対象イベントフラグ属性に TA_CLR（＝ 0x04）が指定されている場合には，イベントフラグのビットパターンのすべてのビットをクリアする．
対象イベントフラグのビットパターンが waiptn と wfmode で指定される待ち解除条件を満たしていない場合には，自タスクを待ち行列につなぎ，イベント
フラグ待ち状態に移行させる．
対象イベントフラグ属性に TA_WSGL（＝ 0x00）が指定されており，イベント
フラグの待ち行列に他のタスクがつながれている場合には，待ち解除条件を満たしているかどうかにかかわらず，E_ILUSE エラーとなる．
（TWF_ANDW ‖ TWF_ORW）の指定 ができる．waiptn と
wfmode には，
wfmode で指定される待ち解除条件とは，wfmodeに TWF_ANDW（＝ 0x00）が指定された場合には，対象イベントフラグのビットパターンの waiptn で指定されるビットのすべてがセットされるという条件である．
（＝0x01）
TWF_ORWが指定された場合には，対象イベントフラグのビットパターンの waiptn で指定されるビットのいずれかがセットされるという条件である．
他のタスクがすでに待ち行列につながっている場合，自タスクを待ち行列につなぐ処理は次のように行う．イベントフラグ属性に TA_TFIFO（＝ 0x00）が指定されている場合には，自タスクを待ち行列の末尾につなぐ．TA_TPRI（＝0x01）が指定されている場合には，自タスクを優先度順で待ち行列につなぐ．
同じ優先度のタスクの中では，自タスクを最後につなぐ．
pol_flg は，wai_flg の処理をポーリングで行うサービスコール，twai_flg は，
wai_flg にタイムアウトの機能を付け加えたサービスコールである．tmout には，正の値のタイムアウト時間に加えて，TMO_POL（＝ 0）と TMO_FEVR（＝ –1）を指定することができる．
waiptn に 0が指定された場合には，E_PAR エラーを返す．
【補足説明】
twai_flgは，tmoutに TMO_POL が指定された場合，E_CTXエラーにならない
限りは pol_flg と全く同じ動作をする．また，tmoutに TMO_FEVRが指定された場合は，wai_flg と全く同じ動作をする．
【µITRON3.0 仕様との相違】
パラメータとリターンパラメータの順序を変更した．また，waitpn と flgptnのデータ型を UINT から FLGPTN に，wfmode のデータ型を UINT から MODEにそれぞれ変更した．
待ちモードのクリア指定（TWF_CLR）を廃止した．同等の機能として，
TA_CLR
属性のイベントフラグを用意している．また，TWF_ORWの値を変更した．
【仕様決定の理由】
この指定をした場合
waiptnに0が指定された場合をE_PARエラーとしたのは，に，イベントフラグのビットパターンがどのような値になっても待ち解除状態

148

µITRON4.0 仕様

Ver. 4.01.00を満たさないため，イベントフラグ待ち状態から抜けることができなくなるた
めである．

149

µITRON4.0 仕様

ref_flg

Ver. 4.01.00

イベントフラグの状態参照【C 言語 API】
ER ercd = ref_flg ( ID flgid, T_RFLG *pk_rflg ) ;【パラメータ】
ID
T_RFLG *flgid
pk_rflg【リターンパラメータ】
ER
ercd

状態参照対象のイベントフラグの ID 番号
イベントフラグ状態を返すパケットへのポイ
ンタ
正常終了（E_OK）またはエラーコード

pk_rflgの内容（T_RFLG 型）
イベントフラグの待ち行列の先頭のタスクのID
wtskid
ID 番号
イベントフラグの現在のビットパターン
FLGPTN
flgptn（実装独自に他の情報を追加してもよい）【エラーコード】
E_ID
E_NOEXS
E_PAR

不正 ID 番号（flgid が不正あるいは使用できない）
オブジェクト未生成（対象イベントフラグが未登録）
パラメータエラー（pk_rflgが不正）【機能】
flgid で指定されるイベントフラグに関する状態を参照し，pk_rflg で指定されるパケットに返す．
wtskidには，対象イベントフラグの待ち行列の先頭のタスクの ID番号を返す．
イベントを待っているタスクがない場合には，TSK_NONE（＝ 0）を返す．
flgptn には，対象イベントフラグの現在のビットパターンを返す．
【µITRON3.0 仕様との相違】参照できる情報から拡張情報を削除した．待ちタスクの有無ではなく，待ち行
列の先頭のタスクの ID 番号を返すこととした．これに伴って，リターンパラ
メータの名称とデータ型を変更した．
flgptn のデータ型を UINT から FLGPTNに変更した．また，パラメータとリター
ンパラメータの順序を変更した．

150

µITRON4.0 仕様

Ver. 4.01.00

4.4.3 データキュー
データキューは，1 ワードのメッセージ（これをデータと呼ぶ）を受渡しすることにより，同期と通信を行うためのオブジェクトである．データキュー機能には，データキューを生成／削除する機能，データキューに対してデータを送
信／強制送信／受信する機能，データキューの状態を参照する機能が含まれる．データキューは ID 番号で識別されるオブジェクトである．データキューの ID 番号をデータキュー ID と呼ぶ．
データキューは，データの送信を待つタスクの待ち行列（送信待ち行列）とデータの受信を待つタスクの待ち行列（受信待ち行列）を持つ．また，送信されたデータを格納するためのデータキュー領域を持つ．データを送信する側（イベントを知らせる側）では，送信したいデータをデータキューに入れる．
データキュー領域に空きがない場合は，データキュー領域に空きができるまで
データキューへの送信待ち状態になる．データキューへの送信待ち状態になったタスクは，そのデータキューの送信待ち行列につながれる．一方，データを受信する側（イベントを待つ側）では，データキューに入っているデータを一つ取り出す．データキューにデータが入っていない場合は，次にデータが送られてくるまでデータキューからの受信待ち状態になる．データキューからの受信待ち状態になったタスクは，そのデータキューの受信待ち行列につながれる．
データキュー領域に格納できるデータの数を 0にすることで，同期メッセージ機能を実現することができる．すなわち，送信側のタスクと受信側のタスクが，それぞれ相手のタスクがサービスコールを呼び出すのを待ち合わせ，両者がサービスコールを呼び出した時点で，データの受渡しが行われる．
データキューで送受信されるデータ（1ワードのメッセージ）は，整数値であっても，送信側と受信側で共有しているメモリ上に置かれたメッセージの先頭番地であってもよい．送受信されるデータは，送信側から受信側にコピーされる．
データキュー機能に関連して，次のカーネル構成マクロを定義する．
SIZE dtqsz = TSZ_DTQ ( UINT dtqcnt )dtqcnt 個のデータを格納するのに必要なデータキュー領域のサイズ（バ
イト数）
データキュー生成情報およびデータキュー状態のパケット形式として，次のデータ型を定義する．
typedef struct t_cdtq {ATR
dtqatr ;UINT
dtqcnt ;/* データキュー属性 *//* データキュー領域の容量（データの
個数）*/
VP
dtq ;
/* データキュー領域の先頭番地 *//* 実装独自に他のフィールドを追加してもよい */} T_CDTQ ;typedef struct t_rdtq {151

µITRON4.0 仕様
ID

Ver. 4.01.00
stskid ;/* データキューの送信待ち行列の先頭のタスクの ID番号 */データキューの受信待ち行列の先頭ID
rtskid ;/*のタスクの ID番号 */データキューに入っているデータのUINT
sdtqcnt ; /*数 *//* 実装独自に他のフィールドを追加してもよい */} T_RDTQ ;データキュー機能の各サービスコールの機能コードは次の通りである．
TFN_CRE_DTQ
TFN_ACRE_DTQ
TFN_DEL_DTQ
TFN_SND_DTQ
TFN_PSND_DTQ
TFN_IPSND_DTQ
TFN_TSND_DTQ
TFN_FSND_DTQ
TFN_IFSND_DTQ
TFN_RCV_DTQ
TFN_PRCV_DTQ
TFN_TRCV_DTQ
TFN_REF_DTQ

–0x31
–0xc4
–0x32
–0x35
–0x36
–0x77
–0x37
–0x38
–0x78
–0x39
–0x3a
–0x3b
–0x3c

cre_dtq の機能コード
acre_dtq の機能コード
del_dtqの機能コード
snd_dtq の機能コード
psnd_dtqの機能コード
ipsnd_dtq の機能コード
tsnd_dtqの機能コード
fsnd_dtq の機能コード
ifsnd_dtqの機能コード
rcv_dtq の機能コード
prcv_dtqの機能コード
trcv_dtq の機能コード
ref_dtq の機能コード【スタンダードプロファイル】
スタンダードプロファイルでは，データキューを動的に生成／削除する機能（cre_dtq，acre_dtq，del_dtq），データキューの状態を参照する機能（ref_dtq）
を除いて，データキュー機能をサポートしなければならない．
スタンダードプロファイルでは，データキュー領域の容量（格納できるデータの個数）として，少なくとも 255 以上の値が指定できなければならない．
スタンダードプロファイルでは，TSZ_DTQ を定義する必要はない．
【補足説明】
データキュー領域に格納できるデータの数を 0にした場合のデータキューの動作を，図 4-1 の例を用いて説明する．この図で，タスク A とタスク B は非同期に実行しているものとする．
• もしタスク Aが先に snd_dtq を呼び出した場合には，タスク B が rcv_dtqを呼び出すまでタスク Aは待ち状態となる．この時タスク Aは，データキュー
への送信待ち状態になっている（図 4-1 (a)）．
• 逆にタスク B が先に rcv_dtqを呼び出した場合には，タスク Aが snd_dtqを呼び出すまでタスク B は待ち状態となる．この時タスク B は，データキュー
からの受信待ち状態になっている（図 4-1 (b)）．
• タスク A が snd_dtq を呼び出し，タスク B が rcv_dtq を呼び出した時点で，152

µITRON4.0 仕様

タスクA

Ver. 4.01.00

タスクB

rcv_dtq ( dtqid )snd_dtq ( dtqid )
送信待ち
状態

タスクB

タスクA

rcv_dtq ( dtqid )snd_dtq ( dtqid )(a) snd_dtq が先の場合

受信待ち
状態

(b) rcv_dtq が先の場合

図 4-1. データキューによる同期通信
タスク A からタスク B へデータの受渡しが行われる．その後は，両タスクとも実行できる状態となる．
データキューは，リングバッファで実装することを想定している．
【µITRON3.0 仕様との相違】
データキュー機能は，µITRON3.0 仕様のリングバッファで実現したメールボッ
クスと同等の機能であり，µITRON4.0 仕様において新たに導入した機能である．

153

µITRON4.0 仕様

CRE_DTQ
cre_dtq
acre_dtq

Ver. 4.01.00

データキューの生成（静的 API）

【S】

データキューの生成
データキューの生成（ID番号自動割付け）【静的 API】
CRE_DTQ ( ID dtqid, { ATR dtqatr, UINT dtqcnt, VP dtq } ) ;【C 言語 API】
ER ercd = cre_dtq ( ID dtqid, T_CDTQ *pk_cdtq ) ;ER_ID dtqid = acre_dtq ( T_CDTQ *pk_cdtq ) ;【パラメータ】
ID

dtqid

T_CDTQ * pk_cdtq

生成対象のデータキューの ID 番号（ acre_dtq
以外）
データキュー生成情報を入れたパケットへのポインタ（CRE_DTQではパケットの内容を直接記述する）

pk_cdtq の内容（T_CDTQ型）
データキュー属性
ATR
dtqatr
データキュー領域の容量（データの個数）
UINT
dtqcnt
データキュー領域の先頭番地
VP
dtq（実装独自に他の情報を追加してもよい）【リターンパラメータ】
cre_dtqの場合
ER
ercd
acre_dtqの場合
ER_ID
dtqid
【エラーコード】
E_ID
E_NOID
E_NOMEM
E_RSATR
E_PAR
E_OBJ

正常終了（E_OK）またはエラーコード
生成したデータキューの ID 番号（正の値）またはエラーコード

不正 ID 番号（dtqid が不正あるいは使用できない；
cre_dtq のみ）
ID 番号不足（割付け可能なデータキュー ID がない；
acre_dtq のみ）
メモリ不足（データキュー領域などが確保できない）
予約属性（dtqatr が不正あるいは使用できない）
パラメータエラー（pk_cdtq，dtqcnt， dtq が不正）オブジェクト状態エラー（対象データキューが登録済
み；cre_dtq のみ）

154

µITRON4.0 仕様

Ver. 4.01.00【機能】
dtqid で指定される ID 番号を持つデータキューを，pk_cdtqで指定されるデー
タキュー生成情報に基づいて生成する．dtqatr はデータキューの属性，dtqcnt
はデータキュー領域に格納できるデータの個数，dtq はデータキュー領域の先頭番地である．
CRE_DTQ においては，dtqidは自動割付け対応整数値パラメータ，dtqatrはプリプロセッサ定数式パラメータである．
acre_dtqは，生成するデータキューのID番号をデータキューが登録されていな
い ID 番号の中から割り付け，割り付けた ID 番号を返値として返す．
dtqatr には，（TA_TFIFO ‖ TA_TPRI）の指定ができる．データキューの送信待ち行列は，TA_TFIFO（＝ 0x00）が指定された場合には FIFO 順，TA_TPRI（＝ 0x01）が指定された場合にはタスクの優先度順となる．
dtq で指定された番地から，dtqcnt個のデータを格納するのに必要なサイズのメモリ領域を，データキュー領域として使用する．TSZ_DTQ を用いると，ア
プリケーションプログラムから，dtqcnt 個のデータを格納するのに必要なサイズを知ることができる．dtq に NULL（＝ 0）が指定された場合には，必要なサイズのメモリ領域をカーネルが確保する．
dtqcnt に実装定義の最大値よりも大きい値が指定された場合には，E_PAR エ
ラーを返す．dtqcnt に 0を指定することは可能である．
【スタンダードプロファイル】
スタンダードプロファイルでは，dtq に NULL 以外の値が指定された場合の機能はサポートする必要がない．
【補足説明】
データキューの受信待ち行列は，常に FIFO 順となる．また，データキューに送信されるデータは優先度を持たず，データキュー中のデータの順序も FIFO
順のみをサポートしている．言い換えると，先に送信されたデータから順に受信されるのが原則である．ただし，snd_dtq と fsnd_dtqを併用した場合には，
snd_dtq で送信待ちしているタスクがあっても fsnd_dtq でデータを送信する
fsnd_dtqで送信されたデータがsnd_dtqで送信されたデー
ことはできるため，
タを追い越すことがある．

155

µITRON4.0 仕様

del_dtq

Ver. 4.01.00

データキューの削除【C 言語 API】
ER ercd = del_dtq ( ID dtqid ) ;【パラメータ】
ID

dtqid【リターンパラメータ】
ER
ercd

削除対象のデータキューの ID 番号
正常終了（E_OK）またはエラーコード【エラーコード】
E_ID
E_NOEXS

不正 ID 番号（dtqid が不正あるいは使用できない）
オブジェクト未生成（対象データキューが未登録）【機能】
dtqid で指定されるデータキューを削除する．データキュー領域をカーネルで確保した場合には，その領域を解放する．
【補足説明】
対象データキューに入っていたデータは破棄される．対象データキューで送信
または受信を待っているタスクがある場合の扱いについては，3.8 節を参照す
ること．

156

µITRON4.0 仕様

snd_dtq
psnd_dtq
ipsnd_dtq
tsnd_dtq

Ver. 4.01.00

データキューへの送信【 S】

データキューへの送信（ポーリング）

【 S】
【 S】
【 S】

データキューへの送信（タイムアウトあり）【C 言語 API】
ER ercd = snd_dtq ( ID dtqid, VP_INT data ) ;ER ercd = psnd_dtq ( ID dtqid, VP_INT data ) ;ER ercd = ipsnd_dtq ( ID dtqid, VP_INT data ) ;ER ercd = tsnd_dtq ( ID dtqid, VP_INT data, TMO tmout ) ;【パラメータ】
ID
VP_INT
TMO

dtqid
data
tmout

【リターンパラメータ】
ER
ercd【エラーコード】
E_ID
E_NOEXS
E_PAR
E_RLWAIE_TMOUT
E_DLT

送信対象のデータキューの ID番号
データキューへ送信するデータ
タイムアウト指定（tsnd_dtqのみ）
正常終了（E_OK）またはエラーコード

不正 ID 番号（dtqidが不正あるいは使用できない）
オブジェクト未生成（対象データキューが未登録）
パラメータエラー（tmoutが不正；tsnd_dtq のみ）
待ち状態の強制解除（待ち状態の間に rel_wai を受付；
snd_dtq， tsnd_dtq のみ）
ポーリング失敗またはタイムアウト（snd_dtq 以外）
待ちオブジェクトの削除（待ち状態の間に対象データ
キューが削除；snd_dtq， tsnd_dtq のみ）【機能】
dtqid で指定されるデータキューに，dataで指定されるデータを送信する．具体的な処理内容は次の通りである．
対象データキューで受信を待っているタスクがある場合には，受信待ち行列の先頭のタスクに送信するデータを渡し，そのタスクを待ち解除する．この時，待ち解除されたタスクに対しては，待ち状態に入ったサービスコールの返値として E_OKを返し，データキューから受信したデータとして dataの値を返す．
受信を待っているタスクがない場合は，送信するデータをデータキューの末尾に入れる．データキュー領域に空きがない場合には，自タスクを送信待ち行列につなぎ，データキューへの送信待ち状態に移行させる．
他のタスクがすでに送信待ち行列につながっている場合，自タスクを送信待ち
行列につなぐ処理は次のように行う．データキュー属性に TA_TFIFO（＝ 0x00）

157

µITRON4.0 仕様

Ver. 4.01.00

が指定 されて いる 場合に は，自タ スクを 送信待 ち行 列の末 尾につ なぐ．
TA_TPRI（＝ 0x01）が指定されている場合には，自タスクを優先度順で送信待
ち行列につなぐ．同じ優先度のタスクの中では，自タスクを最後につなぐ．
psnd_dtq と ipsnd_dtq は，snd_dtq の処理をポーリングで行うサービスコー
ル，tsnd_dtq は，snd_dtq にタイムアウトの機能を付け加えたサービスコー
ルである．tmout には，正の値のタイムアウト時間に加えて，TMO_POL（＝0）と TMO_FEVR（＝ –1）を指定することができる．
psnd_dtq と ipsnd_dtq は，対象データキューで受信を待っているタスクがな
く，データキュー領域に空きがない場合には，E_TMOUT エラーを返す．非タスクコンテキストから呼び出された場合で，サービスコールを遅延実行する場
合には，E_TMOUTエラーを返すことを，実装定義で省略することができる．
【補足説明】
tsnd_dtq は，tmout に TMO_POLが指定された場合，E_CTXエラーにならな
い限りは psnd_dtq と全く同じ動作をする．また，tmout に TMO_FEVR が指定された場合は，snd_dtqと全く同じ動作をする．

158

µITRON4.0 仕様

fsnd_dtq
ifsnd_dtq

Ver. 4.01.00

データキューへの強制送信

【 S】
【 S】

【C 言語 API】
ER ercd = fsnd_dtq ( ID dtqid, VP_INT data ) ;ER ercd = ifsnd_dtq ( ID dtqid, VP_INT data ) ;【パラメータ】
ID
VP_INT

dtqid
data【リターンパラメータ】
ER
ercd【エラーコード】
E_ID
E_NOEXS
E_ILUSE

送信対象のデータキューの ID番号
データキューへ送信するデータ正常終了（E_OK）またはエラーコード

不正 ID 番号（dtqidが不正あるいは使用できない）
オブジェクト未生成（対象データキューが未登録）
サービスコール不正使用（対象データキューのデータ
キュー領域の容量が 0）【機能】dtqidで指定されるデータキューに，dataで指定されるデータを強制送信する．
具体的な処理内容は次の通りである．
対象データキューで受信を待っているタスクがある場合には，受信待ち行列の先頭のタスクに送信するデータを渡し，そのタスクを待ち解除する．この時，待ち解除されたタスクに対しては，待ち状態に入ったサービスコールの返値として E_OK を返し，データキューから受信したデータとして dataの値を返す．
受信を待っているタスクがない場合は，送信するデータをデータキューの末尾に入れる．ここで，データキュー領域に空きがない場合には，データキューの先頭のデータを抹消し，データキュー領域に必要な領域を確保する．この場合
でも，送信するデータはデータキューの末尾に入れる．
これらのサービスコールで，データキュー領域の容量が 0のデータキューに対してデータを強制送信することはできない．対象データキューのデータキュー
領域の容量が 0の場合には，E_ILUSEエラーを返す．
【補足説明】
これらのサービスコールは，対象データキューで送信を待っているタスクがある場合でも，データを強制送信する．
対象データキューのデータキュー領域の容量が 0の場合には，データキューで受信を待っているタスクがある場合でも，E_ILUSE エラーを返す．

159

µITRON4.0 仕様

rcv_dtq
prcv_dtq
trcv_dtq

Ver. 4.01.00

データキューからの受信【S】

データキューからの受信（ポーリング）
データキューからの受信（タイムアウトあり）

【S】
【S】

【C 言語 API】
ER ercd = rcv_dtq ( ID dtqid, VP_INT *p_data ) ;ER ercd = prcv_dtq ( ID dtqid, VP_INT *p_data ) ;ER ercd = trcv_dtq ( ID dtqid, VP_INT *p_data, TMO tmout ) ;【パラメータ】
ID
TMO

dtqid
tmout

【リターンパラメータ】
ER
ercd
VP_INTdata【エラーコード】
E_ID
E_NOEXS
E_PAR
E_RLWAIE_TMOUT
E_DLT

受信対象のデータキューの ID 番号
タイムアウト指定（trcv_dtqのみ）
正常終了（E_OK）またはエラーコード
データキューから受信したデータ

不正 ID 番号（dtqid が不正あるいは使用できない）
オブジェクト未生成（対象データキューが未登録）
パラメータエラー（p_data，tmoutが不正）待ち状態の強制解除（待ち状態の間に rel_wai を受付；
prcv_dtq以外）
ポーリング失敗またはタイムアウト（rcv_dtq 以外）
待ちオブジェクトの削除（待ち状態の間に対象データ
キューが削除；prcv_dtq以外）【機能】
dtqid で指定されるデータキューからデータを受信し，dataに返す．具体的な処理内容は次の通りである．
対象データキューにデータが入っている場合には，その先頭のデータを取り出し，data に返す．データキューで送信を待っているタスクがある場合には，送信待ち行列の先頭のタスクが送信しようとしているデータをデータキューの末尾に入れ，そのタスクを待ち解除する．この時，待ち解除されたタスクに対しては，待ち状態に入ったサービスコールの返値として E_OK を返す．
データが入っていない場合で，対象データキューで送信を待っているタスクがある場合には（このような状況が起こるのは，データキュー領域の容量が 0の場合のみである），送信待ち行列の先頭のタスクから，そのタスクが送信しようとしているデータを受け取り，そのタスクを待ち解除する．この時，待ち解除されたタスクに対しては，待ち状態に入ったサービスコールの返値としてE_OK を返す．data には，受け取ったデータを返す．
データが入っていない場合で，送信を待っているタスクもない場合には，自タ160

µITRON4.0 仕様

Ver. 4.01.00

スクを受信待ち行列につなぎ，データキューからの受信待ち状態に移行させる．他のタスクがすでに受信待ち行列につながっている場合には，自タスクを受信待ち行列の末尾につなぐ．
prcv_dtqは，rcv_dtq の処理をポーリングで行うサービスコール，trcv_dtqは，
rcv_dtq にタイムアウトの機能を付け加えたサービスコールである．tmoutには，正の値のタイムアウト時間に加えて，TMO_POL（＝ 0）と TMO_FEVR（＝ –1）を指定することができる．
【補足説明】
trcv_dtqは，tmout に TMO_POL が指定された場合，E_CTXエラーにならない
限りは prcv_dtq と全く同じ動作をする．また，tmout に TMO_FEVR が指定された場合は，rcv_dtq と全く同じ動作をする．

161

µITRON4.0 仕様

ref_dtq

Ver. 4.01.00

データキューの状態参照【C 言語 API】
ER ercd = ref_dtq ( ID dtqid, T_RDTQ *pk_rdtq ) ;【パラメータ】
ID
T_RDTQ *dtqid
pk_rdtq【リターンパラメータ】
ER
ercd

状態参照対象のデータキューの ID 番号
データキュー状態を返すパケットへのポイン
タ
正常終了（E_OK）またはエラーコード

pk_rdtq の内容（T_RDTQ 型）
データキューの送信待ち行列の先頭のタスク
IDstskidの ID 番号
データキューの受信待ち行列の先頭のタスク
ID
rtskidの ID 番号
データキューに入っているデータの数
UINT
sdtqcnt（実装独自に他の情報を追加してもよい）【エラーコード】
E_ID
E_NOEXS
E_PAR

不正 ID 番号（dtqid が不正あるいは使用できない）
オブジェクト未生成（対象データキューが未登録）
パラメータエラー（pk_rdtqが不正）【機能】
dtqid で指定されるデータキューに関する状態を参照し，pk_rdtq で指定されるパケットに返す．
stskid には，対象データキューの送信待ち行列の先頭のタスクの ID 番号を返す．送信を待っているタスクがない場合には，TSK_NONE（＝ 0）を返す．
rtskid には，対象データキューの受信待ち行列の先頭のタスクの ID 番号を返す．受信を待っているタスクがない場合には，TSK_NONE（＝ 0）を返す．
sdtqcnt には，対象データキューに現在入っているデータの個数を返す．
【補足説明】
また，
rtskid≠TSK_NONEと sdtqcnt≠0が同時に成立することはない．
stskid≠ TSK_NONE の時には，sdtqcntはデータキュー領域の容量に一致する．

162

µITRON4.0 仕様

Ver. 4.01.00

4.4.4 メールボックス
メールボックスは，共有メモリ上に置かれたメッセージを受渡しすることにより，同期と通信を行うためのオブジェクトである．メールボックス機能には，
メールボックスを生成／削除する機能，メールボックスに対してメッセージを送信／受信する機能，メールボックスの状態を参照する機能が含まれる．メー
ルボックスは ID 番号で識別されるオブジェクトである．メールボックスの ID
番号をメールボックス ID と呼ぶ．
メールボックスは，送信されたメッセージを入れるためのメッセージキューと，メッセージの受信を待つタスクの待ち行列を持つ．メッセージを送信する側（イベントを知らせる側）では，送信したいメッセージをメッセージキューに入れる．一方，メッセージを受信する側（イベントを待つ側）では，メッ
セージキューに入っているメッセージを一つ取り出す．メッセージキューにメッセージが入っていない場合は，次にメッセージが送られてくるまでメール
ボックスからの受信待ち状態になる．メールボックスからの受信待ち状態になったタスクは，そのメールボックスの待ち行列につながれる．
メールボックスによって実際に送受信されるのは，送信側と受信側で共有しているメモリ上に置かれたメッセージの先頭番地のみである．すなわち，送受信されるメッセージの内容のコピーは行わない．
カーネルは，メッセージキューに入っているメッセージを，リンクリストにより管理する．アプリケーションプログラムは，送信するメッセージの先頭に，カーネルがリンクリストに用いるための領域を確保しなければならない．この領域をメッセージヘッダと呼ぶ．また，メッセージヘッダと，それに続くアプ
リケーションがメッセージを入れるための領域をあわせて，メッセージパケッ
トと呼ぶ．メールボックスへメッセージを送信するサービスコールは，メッ
セージパケットの先頭番地をパラメータとする．また，メールボックスからメッセージを受信するサービスコールは，メッセージパケットの先頭番地をリ
ターンパラメータとして返す．メッセージキューをメッセージの優先度順にする場合には，メッセージの優先度を入れるための領域も，メッセージヘッダ中に持つ必要がある．
カーネルは，メッセージキューに入っている（ないしは，入れようとしている）メッセージのメッセージヘッダ（メッセージ優先度のための領域を除く）の内容を書き換える．一方，アプリケーションは，メッセージキューに入っているメッセージのメッセージヘッダ（メッセージ優先度のための領域を含む）の内容を書き換えてはならない．アプリケーションによってメッセージヘッダの内容が書き換えられた場合の振舞いは未定義である．この規定は，アプリ
ケーションプログラムがメッセージヘッダの内容を直接書き換えた場合に加えて，メッセージヘッダの番地をカーネルに渡し，カーネルにメッセージヘッ
ダの内容を書き換えさせた場合にも適用される．したがって，すでにメッセー
ジキューに入っているメッセージを再度メールボックスに送信した場合の振舞いは未定義となる．
163

µITRON4.0 仕様

Ver. 4.01.00

メッセージヘッダのデータ型として，次のデータ型を定義する．
T_MSG
T_MSG_PRI

メールボックスのメッセージヘッダ
メールボックスの優先度付きメッセージヘッダ

T_MSG 型の定義やサイズは，実装定義である．それに対して T_MSG_PRI 型
は，T_MSG 型を用いて次のように定義する．
typedef struct t_msg_pri {T_MSG
msgque ;PRI
msgpri ;} T_MSG_PRI ;/* メッセージヘッダ *//* メッセージ優先度 */メールボックス機能に関連して，次のカーネル構成マクロを定義する．
SIZE mprihdsz = TSZ_MPRIHD ( PRI maxmpri )送信されるメッセージの優先度の最大値が maxmpri のメールボックスに必要な優先度別メッセージキューヘッダ領域のサイズ（バイト数）
メールボックス生成情報およびメールボックス状態のパケット形式として，次のデータ型を定義する．
typedef struct t_cmbx {ATR
mbxatr ;/* メールボックス属性 */PRI
maxmpri ; /* 送信されるメッセージの優先度の最大値 */VP
mprihd ; /* 優先度別のメッセージキューヘッダ
領域の先頭番地 *//* 実装独自に他のフィールドを追加してもよい */} T_CMBX ;typedef struct t_rmbx {ID
wtskid ;/* メールボックスの待ち行列の先頭のタスクの ID番号 */T_MSG * pk_msg ; /* メッセージキューの先頭のメッセー
ジパケットの先頭番地 *//* 実装独自に他のフィールドを追加してもよい */} T_RMBX ;メールボックス機能の各サービスコールの機能コードは次の通りである．
TFN_CRE_MBX
TFN_ACRE_MBX
TFN_DEL_MBX
TFN_SND_MBX
TFN_RCV_MBX
TFN_PRCV_MBX
TFN_TRCV_MBX
TFN_REF_MBX

–0x3d
–0xc5
–0x3e
–0x3f
–0x41
–0x42
–0x43
–0x44

cre_mbxの機能コード
acre_mbxの機能コード
del_mbx の機能コード
snd_mbxの機能コード
rcv_mbxの機能コード
prcv_mbx の機能コード
trcv_mbxの機能コード
ref_mbxの機能コード【スタンダードプロファイル】
スタンダードプロファイルでは，メールボックスを動的に生成／削除する機能
164

µITRON4.0 仕様

Ver. 4.01.00（cre_mbx，acre_mbx，del_mbx），メールボックスの状態を参照する機能（ref_mbx）を除いて，メールボックス機能をサポートしなければならない．
スタンダードプロファイルでは，TSZ_MPRIHDを定義する必要はない．
【補足説明】
メールボックス機能では，メッセージヘッダの領域をアプリケーションプログ
ラムで確保することとしているため，メッセージキューに入れることができる
メッセージの数には上限がない．また，メッセージを送信するサービスコール
で待ち状態になることもない．
アプリケーションプログラムをメッセージヘッダの定義やサイズが異なる
カーネルへも移植可能とするためには，アプリケーションで用いるメッセージ
パケットを C 言語の構造体として定義し，その先頭に T_MSG 型ないしはT_MSG_PRI型のフィールドを確保すればよい．また，メッセージに優先度を設定する場合には，メッセージパケットの先頭に確保した T_MSG_PRI 型のフィールド中の msgpri フィールドに代入する．メッセージヘッダのサイズを知る必要がある場合には，sizeof ( T_MSG )ないしは sizeof ( T_MSG_PRI )を用いることができる．
メッセージパケットとしては，固定長メモリプールまたは可変長メモリプール
から動的に確保したメモリブロックを用いることも，静的に確保した領域を用いることも可能である．一般的な使い方としては，送信側のタスクがメモリプールからメモリブロックを確保し，それをメッセージパケットとして送信し，受信側のタスクはメッセージの内容を取り出した後にそのメモリブロックを直接メモリプールに返却するという手順をとることが多い．
【µITRON3.0 仕様との相違】
メールボックスの実現方法を，リンクリストを使う方法に限定した．

165

µITRON4.0 仕様

CRE_MBX
cre_mbx
acre_mbx

Ver. 4.01.00

メールボックスの生成（静的 API）

【S】

メールボックスの生成
メールボックスの生成（ID番号自動割付け）【静的 API】
CRE_MBX ( ID mbxid, { ATR mbxatr, PRI maxmpri,
VP mprihd } ) ;【C 言語 API】
ER ercd = cre_mbx ( ID mbxid, T_CMBX *pk_cmbx ) ;ER_ID mbxid = acre_mbx ( T_CMBX *pk_cmbx ) ;【パラメータ】
IDmbxid

生成対象のメールボックスの番号ID（acre_mbx以外）
T_CMBX * pk_cmbx メールボックス生成情報を入れたパケットへのポインタ（CRE_MBXではパケットの内容を直接記述する）pk_cmbxの内容（T_CMBX型）
メールボックス属性
ATR
mbxatr
PRI
maxmpri 送信されるメッセージの優先度の最大値
優先度別のメッセージキューヘッダ領域の先VP
mprihd頭番地（実装独自に他の情報を追加してもよい）【リターンパラメータ】
cre_mbx の場合
ER
ercd
acre_mbx の場合
ER_ID
mbxid
【エラーコード】
E_ID
E_NOID
E_NOMEM
E_RSATR
E_PAR

正常終了（E_OK）またはエラーコード
生成したメールボックスの ID 番号（正の値）またはエラーコード

不正 ID 番号（mbxid が不正あるいは使用できない；
cre_mbxのみ）
ID 番号不足（割付け可能なメールボックス ID がない；
acre_mbxのみ）
メモリ不足（優先度別のメッセージキューヘッダ領域などが確保できない）
予約属性（mbxatrが不正あるいは使用できない）
パラメータエラー（pk_cmbx，maxmpri，mprihd が不正）
166

µITRON4.0 仕様
E_OBJ

Ver. 4.01.00
オブジェクト状態エラー（対象メールボックスが登録済
み；cre_mbxのみ）【機能】
mbxidで指定される ID番号を持つメールボックスを，pk_cmbxで指定される
メールボックス生成情報に基づいて生成する．mbxatr はメールボックスの属性，maxmpri はメールボックスに送信されるメッセージの優先度の最大値，
mprihd はメールボックスの優先度別のメッセージキューヘッダ領域の先頭番地である．maxmpri と mprihd は，mbxatr に TA_MPRI（＝ 0x02）が指定された場合にのみ有効である．
CRE_MBX においては，mbxid は自動割付け対応整数値パラメータ，mbxatrと maxmpri はプリプロセッサ定数式パラメータである．
acre_mbxは，生成するメールボックスの ID番号をメールボックスが登録されていない ID 番号の中から割り付け，割り付けた ID 番号を返値として返す．
mbxatrには，（（TA_TFIFO ‖ TA_TPRI）｜（ TA_MFIFO‖ TA_MPRI））の指定ができる．メールボックスの待ち行列は，TA_TFIFO（＝ 0x00）が指定された場合には FIFO 順， TA_TPRI（＝ 0x01）が指定された場合にはタスクの優先度順となる．また，メールボックスのメッセージキューは，TA_MFIFO（＝0x00）が指定された場合には FIFO 順，TA_MPRI（＝ 0x02）が指定された場合にはメッセージの優先度順となる．
mbxatrに TA_MPRIが指定された場合，mprihdで指定された番地から，送信されるメッセージの優先度の最大値が maxmpri の場合に必要なサイズのメモ
リ 領域 を，優 先 度 別 の メ ッ セー ジ キ ュ ー ヘ ッ ダ領 域 と し て 使 用 する．
TSZ_MPRIHDを用いると，
アプリケーションプログラムから，送信されるメッセージの優先度の最大値が maxmpri の場合に必要なサイズを知ることができ
る．mprihd に NULL（＝ 0）が指定された場合には，必要なサイズのメモリ領域をカーネルが確保する．
maxmpriに 0 が指定された場合や，メッセージ優先度の最大値（TMAX_MPRI）
よりも大きい値が指定された場合には，E_PAR エラーを返す．
【スタンダードプロファイル】
スタンダードプロファイルでは，mprihd に NULL 以外の値が指定された場合の機能はサポートする必要がない．
【補足説明】
メールボックスの優先度別のメッセージキューヘッダ領域を活用し，メッセー
ジのキューを優先度毎に用意する場合には，次のような配慮が必要である．
メッセージのキューを優先度毎に用意する方法は，メッセージ優先度の段階数が少ない場合には有効な方法であるが，メッセージ優先度の段階数が多い場合には，メモリ使用量が大きくなるために現実的ではない．そこで，メッセージ
優先度の段階数が多い場合にも対応するために，メッセージ優先度の段階数によってキューの構造を変えるといった工夫が必要になる．例えば，送信される
167

µITRON4.0 仕様

Ver. 4.01.00

メッセージの優先度の最大値が一定の値以下である場合にはメッセージのキューを優先度毎に用意し，そうでない場合にはすべてのメッセージを一つのキューで管理するといった方法が考えられる．この場合，TSZ_MPRIHD は，
maxmpri が一定の値よりも大きい場合には一定値を返すように定義する．また，CRE_MBXにおいて maxmpriをプリプロセッサ定数式パラメータとしているのは，カーネルのコンフィギュレータが生成する C言語のソースコード中に maxmpri に関する条件ディレクティブを記述し，maxmpriが一定の値よりも大きい場合にカーネル内部のデータ構造を変化させることを可能にするためである．
一方，すべてのメッセージを一つのキューで管理し，優先度別のメッセージ
キュー ヘッダ 領域 を使わ ない 実装も 可能で ある．こ のよう な実装 では，
TSZ_MPRIHDは maxmpriの値にかかわらず一定値を返すように定義する．
【µITRON3.0 仕様との相違】
メー ルボ ッ クス 生成 情 報に，送 信さ れ るメ ッセ ージ の 優先 度の 最 大値
（maxmpri）と優先度別のメッセージキューヘッダ領域の先頭番地（mprihd）
を追加し，拡張情報とリングバッファの大きさ（実装依存の情報）を削除した．
acre_mbxは新設のサービスコールである．

168

µITRON4.0 仕様

del_mbx

Ver. 4.01.00

メールボックスの削除【C 言語 API】
ER ercd = del_mbx ( ID mbxid ) ;【パラメータ】
ID

mbxid【リターンパラメータ】
ER
ercd【エラーコード】
E_ID
E_NOEXS

削除対象のメールボックスの ID番号
正常終了（E_OK）またはエラーコード

不正 ID 番号（mbxid が不正あるいは使用できない）
オブジェクト未生成（対象メールボックスが未登録）【機能】
mbxidで指定されるメールボックスを削除する．優先度別のメッセージキュー
ヘッダ領域をカーネルで確保した場合には，その領域を解放する．
【補足説明】
対象メールボックスのメッセージキューに入っていたメッセージは破棄される．対象メールボックスで受信を待っているタスクがある場合の扱いについては，3.8 節を参照すること．

169

µITRON4.0 仕様

snd_mbx

Ver. 4.01.00

メールボックスへの送信【S】【C 言語 API】
ER ercd = snd_mbx ( ID mbxid, T_MSG *pk_msg ) ;【パラメータ】
ID
T_MSG *

mbxid
pk_msg【リターンパラメータ】
ER
ercd【エラーコード】
E_ID
E_NOEXS
E_PAR

送信対象のメールボックスの ID 番号
メールボックスへ送信するメッセージパケッ
トの先頭番地正常終了（E_OK）またはエラーコード

不正 ID 番号（mbxidが不正あるいは使用できない）
オブジェクト未生成（対象メールボックスが未登録）
パラメータエラー（ pk_msgが不正，メッセージパケッ
ト中のメッセージ優先度（msgpri）が不正）【機能】
mbxidで指定されるメールボックスに，pk_msgを先頭番地とするメッセージを送信する．具体的な処理内容は次の通りである．
対象メールボックスで受信を待っているタスクがある場合には，待ち行列の先頭のタスクに pk_msg で指定されたメッセージパケットの先頭番地を渡し，そのタスクを待ち解除する．この時，待ち解除されたタスクに対しては，待ち状態に入ったサービスコールの返値として E_OK を返し，メールボックスから受信したメッセージパケットの先頭番地として pk_msg の値を返す．
受信を待っているタスクがない場合は，pk_msgを先頭番地とするメッセージ
パケットを メッセージ キューに 入れる．ここで，メ ールボック ス属性に
TA_MFIFO（＝ 0x00）が指定されている場合には，pk_msgを先頭番地とする
メッセージパケットをメッセージキューの末尾に入れる．TA_MPRI（＝ 0x02）が指定されている場合には，メッセージパケットを優先度順でメッセージ
キューに入れる．同じ優先度のメッセージパケットの中では，新たに送信されたメッセージパケットを最後に入れる．
メールボックス属性に TA_MPRI（＝ 0x02）が指定されている場合， pk_msg
を先頭番地とするメッセージパケットの先頭に，T_MSG_PRI型のメッセージ
ヘッダがあるものと仮定し，メッセージの優先度をその中の msgpri フィール
ドから取り出す．
【µITRON3.0 仕様との相違】
サービスコールの名称を，snd_msgから snd_mbx に変更した．

170

µITRON4.0 仕様

rcv_mbx
prcv_mbx
trcv_mbx

Ver. 4.01.00

メールボックスからの受信【 S】

メールボックスからの受信（ポーリング）
メールボックスからの受信（タイムアウトあり）

【 S】
【 S】

【C 言語 API】
ER ercd = rcv_mbx ( ID mbxid, T_MSG **ppk_msg ) ;ER ercd = prcv_mbx ( ID mbxid, T_MSG **ppk_msg ) ;ER ercd = trcv_mbx ( ID mbxid, T_MSG **ppk_msg,
TMO tmout ) ;【パラメータ】
ID
TMO

mbxid
tmout

【リターンパラメータ】
ER
ercd
T_MSG *
pk_msg【エラーコード】
E_ID
E_NOEXS
E_PAR
E_RLWAIE_TMOUT
E_DLT

受信対象のメールボックスの ID番号
タイムアウト指定（trcv_mbxのみ）
正常終了（E_OK）またはエラーコード
メール ボックスか ら受信したメ ッセージパ
ケットの先頭番地

不正 ID 番号（mbxid が不正あるいは使用できない）
オブジェクト未生成（対象メールボックスが未登録）
パラメータエラー（ppk_msg，tmout が不正）待ち状態の強制解除（待ち状態の間に rel_wai を受付；
prcv_mbx 以外）
ポーリング失敗またはタイムアウト（rcv_mbx以外）
待ちオブジェクトの削除（待ち状態の間に対象メール
ボックスが削除；prcv_mbx 以外）【機能】
mbxidで指定されるメールボックスからメッセージを受信し，その先頭番地を
pk_msg に返す．具体的な処理内容は次の通りである．
対象メールボックスのメッセージキューにメッセージが入っている場合には，その先頭のメッセージパケットを取り出し，その先頭番地を pk_msgに返す．
メッセージが入っていない場合は，自タスクを待ち行列につなぎ，メールボッ
クスからの受信待ち状態に移行させる．
他のタスクがすでに待ち行列につながっている場合，自タスクを待ち行列につなぐ処理は次のように行う．メールボックス属性に TA_TFIFO（＝ 0x00）が指定されている場合には，自タスクを待ち行列の末尾につなぐ．TA_TPRI（＝0x01）が指定されている場合には，自タスクを優先度順で待ち行列につなぐ．
同じ優先度のタスクの中では，自タスクを最後につなぐ．

171

µITRON4.0 仕様

Ver. 4.01.00

prcv_mbxは，rcv_mbxの処理をポーリングで行うサービスコール，trcv_mbx
は，rcv_mbx にタイムアウトの機能を付け加えたサービスコールである．
tmout には，正の 値のタイム アウト時間 に加えて，TMO_POL（＝ 0）とTMO_FEVR（＝ –1）を指定することができる．
【補足説明】
trcv_mbx は，tmout に TMO_POL が指定された場合，E_CTXエラーにならな
い限りは prcv_mbx と全く同じ動作をする．また，tmoutに TMO_FEVRが指定された場合は，rcv_mbxと全く同じ動作をする．
【µITRON3.0 仕様との相違】
サービスコールの名称を，rcv_msg，prcv_msg，trcv_msg から，それぞれ
rcv_mbx，prcv_mbx，trcv_mbx に変更した．また，パラメータとリターン
パラメータの順序を変更した．

172

µITRON4.0 仕様

ref_mbx

Ver. 4.01.00

メールボックスの状態参照【C 言語 API】
ER ercd = ref_mbx ( ID mbxid, T_RMBX *pk_rmbx ) ;【パラメータ】
状態参照対象のメールボックスの ID番号ID
mbxid
T_RMBX * pk_rmbx メールボックス状態を返すパケットへのポイ
ンタ【リターンパラメータ】
ER
ercd

正常終了（E_OK）またはエラーコード

pk_rmbx の内容（T_RMBX 型）
メールボックスの待ち行列の先頭のタスクのID
wtskidID 番号
T_MSG *
pk_msg メッセージキューの先頭のメッセージパケッ
トの先頭番地（実装独自に他の情報を追加してもよい）【エラーコード】
E_ID
E_NOEXS
E_PAR

不正 ID 番号（mbxid が不正あるいは使用できない）
オブジェクト未生成（対象メールボックスが未登録）
パラメータエラー（pk_rmbx が不正）【機能】
mbxid で指定されるメールボックスに関する状態を参照し，pk_rmbx で指定されるパケットに返す．
wtskid には，対象メールボックスの待ち行列の先頭のタスクの ID番号を返す．
送信を待っているタスクがない場合には，TSK_NONE（＝ 0）を返す．
pk_msg には，対象メールボックスのメッセージキューの先頭のメッセージパ
ケットの先頭番地を返す．メッセージキューにメッセージが入っていない場合には，NULL（＝ 0）を返す．
【補足説明】．
wtskid ≠ TSK_NONE と pk_msg≠ NULLが同時に成立することはない．
【µITRON3.0 仕様との相違】参照できる情報から拡張情報を削除した．待ちタスクの有無ではなく，待ち行
列の先頭のタスクの ID 番号を返すこととした．これに伴って，リターンパラ
メータの名称とデータ型を変更した．
パラメータとリターンパラメータの順序を変更した．

173

µITRON4.0 仕様

Ver. 4.01.00

4.5 拡張同期・通信機能
拡張同期・通信機能は，タスクとは独立したオブジェクトにより，タスク間の高度な同期・通信を行うための機能である．ミューテックス，メッセージバッ
ファ，ランデブの各機能が含まれる．
【スタンダードプロファイル】
スタンダードプロファイルでは，拡張同期・通信機能はサポートする必要がな
い．
【µITRON3.0 仕様との相違】
ミューテックスは新たに導入した機能である．

4.5.1 ミューテックス
ミューテックスは，共有資源を使用する際にタスク間で排他制御を行うためのオブジェクトである．ミューテックスは，排他制御に伴う上限のない優先度逆転を防ぐための機構として，優先度継承プロトコル（priority inheritance protocol）と優先度上限プロトコル（priority ceiling protocol）をサポートする．ミューテッ
クス機能には，ミューテックスを生成／削除する機能，ミューテックスをロッ
ク／ロック解除する機能，ミューテックスの状態を参照する機能が含まれる．
ミューテックスは ID 番号で識別されるオブジェクトである．ミューテックスの ID 番号をミューテックス ID と呼ぶ．
ミューテックスは，ロックされているかどうかの状態と，ロックを待つタスクの待ち行列を持つ．また，カーネルは，各ミューテックスに対してそれをロックしているタスクを，各タスクに対してそれがロックしているミューテックスの集合を管理する．タスクは，資源を使用する前に，ミューテックスをロックする．ミューテックスが他のタスクにロックされていた場合には，ミューテッ
クスがロック解除されるまで，ミューテックスのロック待ち状態となる．
ミューテックスのロック待ち状態になったタスクは，そのミューテックスの待
ち行列につながれる．タスクは，資源の使用を終えると，ミューテックスのロックを解除する．
ミューテックスは，ミューテックス属性に TA_INHERIT（＝ 0x02）を指定す
ることにより優先度継承プロトコルを，TA_CEILING（＝ 0x03）を指定することにより優先度上限プロトコルをサポートする．TA_CEILING 属性のミュー
テックスに対しては，そのミューテックスをロックする可能性のあるタスクの中で最も高いベース優先度を持つタスクのベース優先度を，ミューテックス生
成時に上限優先度として設定する．TA_CEILING 属性のミューテックスを，その上限優先度よりも高いベース優先度を持つタスクがロックしようとした場
合，E_ILUSEエラーとなる．また，TA_CEILING属性のミューテックスをロックしているかロックを待っているタスクのベース優先度を，chg_pri によってそのミューテックスの上限優先度よりも高く設定しようとした場合，chg_pri
174

µITRON4.0 仕様

Ver. 4.01.00

が E_ILUSE エラーを返す．
これらのプロトコルを用いた場合，上限のない優先度逆転を防ぐために，
ミューテックスの操作に伴ってタスクの現在優先度を変更する．優先度継承プ
ロトコルと優先度上限プロトコルに厳密に従うなら，タスクの現在優先度を，次に挙げる優先度の最高値に常に一致するように変更する必要がある．これを，厳密な優先度制御規則と呼ぶ．
• タスクのベース優先度• タスクが TA_INHERIT属性のミューテックスをロックしている場合，それらのミューテックスのロックを待っているタスクの中で，最も高い現在優先度を持つタスクの現在優先度• タスクが TA_CEILING属性のミューテックスをロックしている場合，それらのミューテックス中で，最も高い上限優先度を持つミューテッ
クスの上限優先度
ここで，TA_INHERIT属性のミューテックスを待っているタスクの現在優先度
が，ミューテックス操作か chg_priによるベース優先度の変更に伴って変更された場合，そのミューテックスをロックしているタスクの現在優先度の変更が必要になる場合がある．これを推移的な優先度継承と呼ぶ．さらにそのタスクが，別の TA_INHERIT 属性のミューテックスを待っていた場合には，そのミューテックスをロックしているタスクに対して推移的な優先度継承の処理が必要になる場合がある．
µITRON4.0 仕様では，上述の厳密な優先度制御規則に加えて，現在優先度を変更する状況を限定した優先度制御規則（これを簡略化した優先度制御規則と呼ぶ）を規定し，どちらを採用するかは実装定義とする．具体的には，簡略化した優先度制御規則においては，タスクの現在優先度を高くする方向の変更はすべて行うのに対して，現在優先度を低くする方向の変更は，タスクがロックしているミューテックスがなくなった時にのみ行う（この場合には，タスクの現在優先度をベース優先度に戻すことになる）．より具体的には，次の状況でのみ現在優先度を変更する処理を行えばよい．
• タスクがロックしている TA_INHERIT 属性のミューテックスを，
そのタスクよりも高い現在優先度を持つタスクが待ち始めた時• タスクがロックしている TA_INHERIT 属性のミューテックスを待っているタスクが，前者のタスクよりも高い現在優先度に変更された時• タスクが，そのタスクの現在優先度よりも高い上限優先度を持つ
TA_CEILING 属性のミューテックスをロックした時• タスクがロックしているミューテックスがなくなった時
ミューテックスの操作に伴ってタスクの現在優先度を変更した場合には，次の処理を行う．優先度を変更されたタスクが実行できる状態である場合，タスクの優先順位を，変更後の優先度にしたがって変化させる．変更後の優先度と同じ優先度を持つタスクの間での優先順位は，実装依存である．優先度が変更されたタスクが何らかのタスク優先度順の待ち行列につながれている場合にも，

175

µITRON4.0 仕様

Ver. 4.01.00

その待ち行列の中での順序を，変更後の優先度にしたがって変化させる．変更
後の優先度と同じ優先度を持つタスクの間での順序は，実装依存である．
タスクが終了する時に，そのタスクがロックしているミューテックスが残っている場合には，それらのミューテックスをすべてロック解除する．ロックしているミューテックスが複数ある場合には，それらをロック解除する順序は実装依存である．ロック解除の具体的な処理内容については，unl_mtxの機能説明を参照すること．
ミューテックス生成情報およびミューテックス状態のパケット形式として，次のデータ型を定義する．
typedef struct t_cmtx {ATR
mtxatr ;/* ミューテックス属性 */PRI
ceilpri ;/* ミューテックスの上限優先度 *//* 実装独自に他のフィールドを追加してもよい */} T_CMTX ;typedef struct t_rmtx {IDhtskid ;/* ミューテックスをロックしているタ
スクの ID番号 */ID
wtskid ;/* ミューテックスの待ち行列の先頭のタスクの ID番号 *//* 実装独自に他のフィールドを追加してもよい */} T_RMTX ;ミューテックス機能の各サービスコールの機能コードは次の通りである．
TFN_CRE_MTX
TFN_ACRE_MTX
TFN_DEL_MTX
TFN_LOC_MTX
TFN_PLOC_MTX
TFN_TLOC_MTX
TFN_UNL_MTX
TFN_REF_MTX

–0x81
–0xc6
–0x82
–0x85
–0x86
–0x87
–0x83
–0x88

cre_mtx の機能コード
acre_mtx の機能コード
del_mtxの機能コード
loc_mtxの機能コード
ploc_mtx の機能コード
tloc_mtx の機能コード
unl_mtxの機能コード
ref_mtxの機能コード【補足説明】
TA_TFIFO 属性または TA_TPRI属性のミューテックスは，最大資源数が 1のセマフォ（バイナリセマフォ）と同等の機能を持つ．ただし，ミューテックス
は，ロックしたタスク以外はロック解除できない，タスク終了時に自動的にロック解除されるなどの違いがある．
ここでいう優先度上限プロトコルは，広い意味での優先度上限プロトコルで，最初に優先度上限プロトコルとして提案されたアルゴリズムではない．厳密には，highest locker protocolなどと呼ばれているアルゴリズムである．
ミューテックスの操作に伴ってタスクの現在優先度を変更した結果，優先度を変更されたタスクのタスク優先度順の待ち行列の中での順序が変化した場合，優先度を変更されたタスクないしはその待ち行列で待っている他のタスクの176

µITRON4.0 仕様

Ver. 4.01.00

待ち解除が必要になる場合がある（snd_mbf の機能説明と get_mpl の機能説
明を参照）．
【µITRON3.0 仕様との相違】
ミューテックス機能は， µITRON4.0 仕様において新たに導入した機能である．
ミューテックスをセマフォとは別のオブジェクトとして導入したのは，計数型
セマフォで優先度継承プロトコルをサポートするのが難しいためである．
【仕様決定の理由】
ミューテックスの操作に伴ってタスクの現在優先度を変更した場合に，変更後の優先度と同じ優先度を持つタスクの間での優先順位を実装依存としたのは，次の理由による．アプリケーションによっては，ミューテックス機能による現在優先度の変更が頻繁に発生する可能性があり，それに伴ってタスク切替えが多発するのは望ましくない（同じ優先度を持つタスクの間での優先順位を最低とすると，不必要なタスク切替えが起こる）．理想的には，タスクの優先度ではなく優先順位を継承するのが望ましいが，このような仕様にすると実装上のオーバヘッドが大きくなるため，実装依存とすることにした．

177

µITRON4.0 仕様

CRE_MTX
cre_mtxacre_mtx

Ver. 4.01.00

ミューテックスの生成（静的 API）
ミューテックスの生成
ミューテックスの生成（ID番号自動割付け）【静的 API】
CRE_MTX ( ID mtxid, { ATR mtxatr, PRI ceilpri } ) ;【C 言語 API】
ER ercd = cre_mtx ( ID mtxid, T_CMTX *pk_cmtx ) ;ER_ID mtxid = acre_mtx ( T_CMTX *pk_cmtx ) ;【パラメータ】
ID

mtxid

生成対象のミューテックスの番号ID（acre_mtx以外）
T_CMTX * pk_cmtx ミューテックス生成情報を入れたパケットへのポインタ（CRE_MTXではパケットの内容を直接記述する）pk_cmtxの内容（T_CMTX 型）
ミューテックス属性
ATR
mtxatr
ミューテックスの上限優先度
PRI
ceilpri（実装独自に他の情報を追加してもよい）【リターンパラメータ】
cre_mtxの場合
ER
ercd
acre_mtx の場合
ER_ID
mtxid
【エラーコード】
E_ID
E_NOID
E_RSATR
E_PAR
E_OBJ

正常終了（E_OK）またはエラーコード
生成したミューテックスの ID 番号（正の値）またはエラーコード

不正 ID 番号（mtxid が不正あるいは使用できない；
cre_mtxのみ）
ID 番号不足（割付け可能なミューテックス ID がない；
acre_mtxのみ）
予約属性（mtxatrが不正あるいは使用できない）
パラメータエラー（pk_cmtx，ceilpriが不正）オブジェクト状態エラー（対象ミューテックスが登録済
み；cre_mtxのみ）【機能】
mtxid で指定される ID 番号を持つミューテックスを， pk_cmtx で指定される
ミューテックス生成情報に基づいて生成する． mtxatr はミューテックスの属178

µITRON4.0 仕様

Ver. 4.01.00

性，ceilpri はミ ューテックス の上限優先度 である．ceilpri は，mtxatr に
TA_CEILING（＝ 0x03）が指定された場合にのみ有効である．
CRE_MTXにおいては，mtxidは自動割付け対応整数値パラメータ，mtxatrはプリプロセッサ定数式パラメータである．
acre_mtxは，生成するミューテックスの ID番号をミューテックスが登録されていない ID 番号の中から割り付け，割り付けた ID 番号を返値として返す．
mtxatrには，（TA_TFIFO‖ TA_TPRI‖ TA_INHERIT‖ TA_CEILING）の指定ができる．ミューテックスの待ち行列は，TA_TFIFO（＝ 0x00）が指定された場合には FIFO 順，その他が指定された場合にはタスクの優先度順となる．また，TA_INHERIT（＝ 0x02）が指定された場合には優先度継承プロトコル，
TA_CEILING（＝ 0x03）が指定された場合には優先度上限プロトコルにしたがって，タスクの現在優先度を制御する．

179

µITRON4.0 仕様

del_mtx

Ver. 4.01.00

ミューテックスの削除【C 言語 API】
ER ercd = del_mtx ( ID mtxid ) ;【パラメータ】
ID

mtxid【リターンパラメータ】
ER
ercd【エラーコード】
E_ID
E_NOEXS

削除対象のミューテックスの ID 番号
正常終了（E_OK）またはエラーコード

不正 ID 番号（mtxidが不正あるいは使用できない）
オブジェクト未生成（対象ミューテックスが未登録）【機能】
mtxidで指定されるミューテックスを削除する．
【補足説明】
対象ミューテックスがロックされていた場合，それをロックしていたタスクにとっては，ロックしているミューテックスが減ることになる．そのため，対象
ミューテックスが TA_INHERIT 属性か TA_CEILING 属性の場合には，それをロックしていたタスクの現在優先度の変更が必要になる場合がある．簡略化した優先度制御規則を採用している場合には，ミューテックスを削除した結果，タスクがロックしているミューテックスがなくなった場合にのみ，タスクの現在優先度を変更する．
削除されたミューテックスをロックしているタスクには，ミューテックスが削除されたことはすぐには通知されず，後でミューテックスをロック解除しようとした時点でエラーが報告される．タスクがミューテックスをロックしている
間にミューテックスが削除されるのが不都合な場合には，ミューテックスを削除するタスクが，ミューテックスをロックした状態で削除すればよい．
対象ミューテックスのロックを待っているタスクがある場合の扱いについては，3.8 節を参照すること．

180

µITRON4.0 仕様

loc_mtx
ploc_mtx
tloc_mtx

Ver. 4.01.00

ミューテックスのロック
ミューテックスのロック（ポーリング）
ミューテックスのロック（タイムアウトあり）【C 言語 API】
ER ercd = loc_mtx ( ID mtxid ) ;ER ercd = ploc_mtx ( ID mtxid ) ;ER ercd = tloc_mtx ( ID mtxid, TMO tmout ) ;【パラメータ】
ID
TMO

mtxid
tmout

【リターンパラメータ】
ER
ercd【エラーコード】
E_ID
E_NOEXS
E_PAR
E_ILUSE
E_RLWAIE_TMOUT
E_DLT

ロック対象のミューテックスの ID番号
タイムアウト指定（tloc_mtx のみ）
正常終了（E_OK）またはエラーコード

不正 ID 番号（mtxid が不正あるいは使用できない）
オブジェクト未生成（対象ミューテックスが未登録）
パラメータエラー（tmoutが不正；tloc_mtxのみ）
サービスコール不正使用（ミューテックスの多重ロック，上限優先度の違反）待ち状態の強制解除（待ち状態の間に rel_wai を受付；
ploc_mtx 以外）
ポーリング失敗またはタイムアウト（loc_mtx以外）
待ちオブジェクトの削除（待ち状態の間に対象ミュー
テックスが削除；ploc_mtx 以外）【機能】
mtxid で指定されるミューテックスをロックする．具体的には，対象ミュー
テックスがロックされていない場合には，自タスクがミューテックスをロックした状態にし，自タスクを待ち状態とせずにサービスコールの処理を終了す
る．対象ミューテックスがロックされている場合には，自タスクを待ち行列につなぎ，ミューテックスのロック待ち状態に移行させる．
他のタスクがすでに待ち行列につながっている場合，自タスクを待ち行列につなぐ処理は次のように行う．ミューテックス属性に TA_TFIFO（＝ 0x00）が指定されている場合には，自タスクを待ち行列の末尾につなぐ．その他の属性が指定されている場合には，自タスクを優先度順で待ち行列につなぐ．同じ優先度のタスクの中では，自タスクを最後につなぐ．
自タスクがすでに対象ミューテックスをロックしている場合には，E_ILUSE
エラーを返す．また，対象ミューテックスが TA_CEILING 属性の場合で，自タスクのベース優先度が対象ミューテックスの上限優先度よりも高い場合に181

µITRON4.0 仕様

Ver. 4.01.00

も，E_ILUSE エラーを返す．
ploc_mtx は，loc_mtx の処理をポーリングで行うサービスコール，tloc_mtx
は，
loc_mtxにタイムアウトの機能を付け加えたサービスコールである．
tmoutには，正の値のタイムアウト時間に加えて，TMO_POL（＝ 0）と TMO_FEVR（＝ –1）を指定することができる．
【補足説明】
自TA_INHERIT 属性のミューテックスを対象にサービスコールが呼び出され，タスクをミューテックスのロック待ち状態に移行させた場合で，自タスクの現在優先度が対象ミューテックスをロックしているタスクの現在優先度よりも高い場合には，後者のタスクの現在優先度を，前者のタスクの現在優先度に変更する．
また，TA_INHERIT 属性のミューテックスのロックを待っているタスクを，タ
イムアウトまたは rel_wai を受け付けたことにより待ち解除する場合には，そのミューテックスをロックしているタスクの現在優先度の変更が必要になる場合がある．簡略化した優先度制御規則を採用している場合には，この変更は行わない．
自TA_CEILING 属性のミューテックスを対象にサービスコールが呼び出され，タスクがミューテックスをロックした場合で，対象ミューテックスの上限優先
度が自タスクの現在優先度よりも高い場合には，自タスクの現在優先度を，ミューテックスの上限優先度に変更する．
tloc_mtxは，tmout に TMO_POL が指定された場合，E_CTXエラーにならない
限りは ploc_mtx と全く同じ動作をする．また，tmout に TMO_FEVR が指定された場合は，loc_mtx と全く同じ動作をする．

182

µITRON4.0 仕様

unl_mtx

Ver. 4.01.00

ミューテックスのロック解除【C 言語 API】
ER ercd = unl_mtx ( ID mtxid ) ;【パラメータ】
ID

mtxid【リターンパラメータ】
ER
ercd【エラーコード】
E_ID
E_NOEXS
E_ILUSE

ロック解除対象のミューテックスの ID番号
正常終了（E_OK）またはエラーコード

不正 ID 番号（mtxid が不正あるいは使用できない）
オブジェクト未生成（対象ミューテックスが未登録）
サービスコール不正使用（対象ミューテックスをロックしていない）【機能】
mtxid で指定されるミューテックスをロック解除する．具体的には，対象
ミューテックスに対してロックを待っているタスクがある場合には，待ち行列の先頭のタスクを待ち解除し，待ち解除されたタスクが対象ミューテックスをロックした状態にする．この時，待ち解除されたタスクに対しては，待ち状態に入ったサービスコールの返値として E_OKを返す．ロックを待っているタス
クがない場合には，対象ミューテックスをロックされていない状態にする．
対象ミューテックスを自タスクがロックしていない場合には，E_ILUSE エ
ラーを返す．
【補足説明】
対象ミューテックスが TA_INHERIT 属性か TA_CEILING 属性の場合には，このサービスコールを呼び出したことにより，自タスクの現在優先度の変更が必要になる場合がある．簡略化した優先度制御規則を採用している場合には，
ミューテックスをロック解除した結果，自タスクがロックしているミューテッ
クスがなくなった場合にのみ，自タスクの現在優先度を変更する．

183

µITRON4.0 仕様

ref_mtx

Ver. 4.01.00

ミューテックスの状態参照【C 言語 API】
ER ercd = ref_mtx ( ID mtxid, T_RMTX *pk_rmtx ) ;【パラメータ】
ID
mtxid
T_RMTX * pk_rmtx【リターンパラメータ】
ER
ercd

状態参照対象のミューテックスの ID 番号
ミューテックス状態を返すパケットへのポイ
ンタ
正常終了（E_OK）またはエラーコード

pk_rmtx の内容（T_RMTX型）
ミューテックスをロックしているタスクの ID
IDhtskid
番号
ミューテックスの待ち行列の先頭のタスクのID
wtskidID 番号（実装独自に他の情報を追加してもよい）【エラーコード】
E_ID
E_NOEXS
E_PAR

不正 ID 番号（mtxidが不正あるいは使用できない）
オブジェクト未生成（対象ミューテックスが未登録）
パラメータエラー（pk_rmtx が不正）【機能】
mtxidで指定されるミューテックスに関する状態を参照し，pk_rmtxで指定されるパケットに返す．
htskid には，対象ミューテックスをロックしているタスクの ID 番号を返す．対
象ミューテックスがロックされていない場合には，TSK_NONE（＝ 0）を返す．
wtskidには，対象ミューテックスの待ち行列の先頭のタスクの ID番号を返す．
ロックを待っているタスクがない場合には，TSK_NONE（＝ 0）を返す．
【補足説明】
htskid ＝ TSK_NONEと wtskid≠ TSK_NONE が同時に成立することはない．

184

µITRON4.0 仕様

Ver. 4.01.00

4.5.2 メッセージバッファ
メッセージバッファは，可変長のメッセージを受渡しすることにより，同期と通信を行うためのオブジェクトである．メッセージバッファ機能には，メッ
セージバッファを生成／削除する機能，メッセージバッファに対してメッセー
ジを送信／受信する機能，メッセージバッファの状態を参照する機能が含まれる．メッセージバッファは ID 番号で識別されるオブジェクトである．メッセー
ジバッファの ID 番号をメッセージバッファ ID と呼ぶ．
メッセージバッファは，メッセージの送信を待つタスクの待ち行列（送信待ち行列）とメッセージの受信を待つタスクの待ち行列（受信待ち行列）を持つ．
また，送信されたメッセージを格納するためのメッセージバッファ領域を持
つ．メッセージを送信する側（イベントを知らせる側）では，送信したいメッ
セージをメッセージバッファにコピーする．メッセージバッファ領域の空き領
域が足りなくなった場合，メッセージバッファ領域に十分な空きができるまでメッセージバッファへの送信待ち状態になる．メッセージバッファへの送信待ち状態になったタスクは，そのメッセージバッファの送信待ち行列につながれる．一方，メッセージを受信する側（イベントを待つ側）では，メッセージ
バッファに入っているメッセージを一つ取り出す．メッセージバッファにメッセージが入っていない場合は，次にメッセージが送られてくるまでメッセージ
バッファからの受信待ち状態になる．メッセージバッファからの受信待ち状態になったタスクは，そのメッセージバッファの受信待ち行列につながれる．
メッセージバッファ領域のサイズを 0にすることで，同期メッセージ機能を実現することができる．すなわち，送信側のタスクと受信側のタスクが，それぞれ相手のタスクがサービスコールを呼び出すのを待ち合わせ，両者がサービスコールを呼び出した時点で，メッセージの受渡しが行われる．
メッセージバッファ機能に関連して，次のカーネル構成マクロを定義する．
SIZE mbfsz = TSZ_MBF ( UINT msgcnt, UINT msgsz )サイズが msgsz バイトのメッセージを msgcnt 個格納するのに必要なメッセージバッファ領域のサイズ（目安のバイト数）
このマクロは，あくまでもメッセージバッファ領域のサイズを決める際の目安として使うためのものである．このマクロを使って，異なるサイズのメッセージを格納するのに必要なサイズを決定することはできない．
メッセージバッファ生成情報およびメッセージバッファ状態のパケット形式
として，次のデータ型を定義する．
typedef struct t_cmbf {ATR
mbfatr ;UINT
maxmsz ;SIZEmbfsz ;/* メッセージバッファ属性 *//* メッセージの最大サイズ（バイト数）*//* メッセージバッファ領域のサイズ（バイト数）*/

185

µITRON4.0 仕様
VP

Ver. 4.01.00
mbf ;/* メッセージバッファ領域の先頭番
地 */実装独自に他のフィールドを追加してもよい/**/} T_CMBF ;typedef struct t_rmbf {IDstskid ;/* メッセージバッファの送信待ち行列の先頭のタスクの ID番号 */ID
rtskid ;/* メッセージバッファの受信待ち行列の先頭のタスクの ID番号 */UINT
smsgcnt ; /* メッセージバッファに入っているメッセージの数 */SIZE
fmbfsz ;/* メッセージバッファ領域の空き領域のサイズ（バイト数，最低限の管理領域を除く）*//* 実装独自に他のフィールドを追加してもよい */} T_RMBF ;メッセージバッファ機能の各サービスコールの機能コードは次の通りである．
TFN_CRE_MBF
TFN_ACRE_MBF
TFN_DEL_MBF
TFN_SND_MBF
TFN_PSND_MBF
TFN_TSND_MBF
TFN_RCV_MBF
TFN_PRCV_MBF
TFN_TRCV_MBF
TFN_REF_MBF

–0x89
–0xc7
–0x8a
–0x8d
–0x8e
–0x8f
–0x91
–0x92
–0x93
–0x94

cre_mbf の機能コード
acre_mbf の機能コード
del_mbfの機能コード
snd_mbfの機能コード
psnd_mbf の機能コード
tsnd_mbf の機能コード
rcv_mbf の機能コード
prcv_mbfの機能コード
trcv_mbfの機能コード
ref_mbfの機能コード【補足説明】
メッセージバッファ領域のサイズを 0にした場合の，メッセージバッファの動作を図 4-2 の例を用いて説明する．この図で，タスク A とタスク B は非同期に実行しているものとする．
• もしタスク A が先に snd_mbf を呼び出した場合には，タスク B が rcv_mbf
を呼び出すまでタスク Aは待ち状態となる．この時タスク Aは，メッセージ
バッファへの送信待ち状態になっている（図 4-2 (a)）．
• 逆にタスク B が先に rcv_mbf を呼び出した場合には，タスク A が snd_mbf
を呼び出すまでタスク B は待ち状態となる．この時タスク B は，メッセージ
バッファからの受信待ち状態になっている（図 4-2 (b)）．
• タスク Aが snd_mbf を呼び出し，タスク Bが rcv_mbfを呼び出した時点で，タスク Aからタスク B へメッセージの受渡しが行われる．その後は，両タス
クとも実行できる状態となる．
メッセージバッファへの送信を待っているタスクは，待ち行列につながれている順序でメッセージを送信する．例えば，あるメッセージバッファに対して 40
186

µITRON4.0 仕様

Ver. 4.01.00

タスクA

タスクB

rcv_mbf ( mbfid )snd_mbf ( mbfid )
送信待ち
状態

タスクB

タスクA

rcv_mbf ( mbfid )snd_mbf ( mbfid )(a) snd_mbf が先の場合

受信待ち
状態

(b) rcv_mbf が先の場合

図 4-2. メッセージバッファによる同期通信
バイトのメッセージを送信しようとしているタスク A と，10バイトのメッセー
ジを送信しようとしているタスク Bが，この順で待ち行列につながれている時に，別のタスクによるメッセージの受信により 20バイトの空き領域ができたとする．このような場合でも，タスク A がメッセージを送信するまで，タスク B
はメッセージを送信できない．ただし，このような場合にタスク Bに先にメッセージを送信させる指定を，実装独自にメッセージバッファ属性に追加することは許される．
メッセージバッファは，可変長のメッセージをコピーして受渡しする．データ
キューとの違いは，メッセージの長さが可変であることである．一方，メール
ボックスとの違いは，メッセージをコピーすることである．
メッセージバッファは，リングバッファで実装することを想定している．
カーネルのエラーログ用（サービスコールを呼び出した処理に通知できないエラーの記録用）にメッセージバッファを用いる場合，ID 番号が（–4）のメッ
セージバッファを用いることができる．さらに，デバッグサポート機能との通信用などに，カーネル内部でメッセージバッファを用いる場合には，ID番号が（–3）〜（–2）のメッセージバッファを用いることができる．また，アプリケー
ションプログラムからこれらのメッセージバッファにアクセスする方法を限定することができる．
【µITRON3.0 仕様との相違】
メッセージバッファでメッセージの送信を待っているタスクが，待ち行列につながれている順序でメッセージを送信するか，メッセージを送信できるものか
ら先に送信するかが実装依存となっていたのを，前者に標準化した．

187

µITRON4.0 仕様

CRE_MBF
cre_mbf
acre_mbf

Ver. 4.01.00

メッセージバッファの生成（静的 API）
メッセージバッファの生成
メッセージバッファの生成（ID番号自動割付け）【静的 API】
CRE_MBF ( ID mbfid, { ATR mbfatr, UINT maxmsz, SIZE mbfsz,
VP mbf } ) ;【C 言語 API】
ER ercd = cre_mbf ( ID mbfid, T_CMBF *pk_cmbf ) ;ER_ID mbfid = acre_mbf ( T_CMBF *pk_cmbf ) ;【パラメータ】
ID

mbfid

生成対象のメッセージバッファの ID 番号（acre_mbf以外）
T_CMBF * pk_cmbf メッセージバッファ生成情報を入れたパケッ
トへのポインタ（CRE_MBFではパケットの内容を直接記述する）

pk_cmbfの内容（T_CMBF型）
メッセージバッファ属性
ATR
mbfatrUINT
maxmsz メッセージの最大サイズ（バイト数）
メッセージバッファ領域のサイズ（バイト数）
SIZE
mbfsz
メッセージバッファ領域の先頭番地
VP
mbf（実装独自に他の情報を追加してもよい）【リターンパラメータ】
cre_mbfの場合
ER
ercd
acre_mbf の場合
ER_ID
mbfid
【エラーコード】
E_ID
E_NOID
E_NOMEM
E_RSATR
E_PAR

正常終了（E_OK）またはエラーコード
生成したメッセージバッファの ID 番号（正の値）またはエラーコード

不正 ID 番号（mbfid が不正あるいは使用できない；
cre_mbfのみ）
ID 番号不足（割付け可能なメッセージバッファ ID がな
い；acre_mbfのみ）
メモリ不足（メッセージバッファ領域などが確保できない）
予約属性（mbfatrが不正あるいは使用できない）
パラメータエラー（pk_cmbf，maxmsz，mbfsz，mbf
が不正）
188

µITRON4.0 仕様
E_OBJ

Ver. 4.01.00
オブジェクト状態エラー（対象メッセージバッファが登録済み；cre_mbfのみ）【機能】
mbfidで指定される ID番号を持つメッセージバッファを，pk_cmbfで指定されるメッセージバッファ生成情報に基づいて生成する． mbfatr はメッセージ
バッファの属性，maxmszはメッセージバッファに送信できるメッセージの最大サイズ（バイト数），mbfszはメッセージバッファ領域のサイズ（バイト数），
mbfはメッセージバッファ領域の先頭番地である．
CRE_MBF においては，mbfid は自動割付け対応整数値パラメータ，mbfatrはプリプロセッサ定数式パラメータである．
acre_mbfは，生成するメッセージバッファの ID番号をメッセージバッファが登録されていない ID 番号の中から割り付け，割り付けた ID 番号を返値として返す．
mbfatrには，（TA_TFIFO‖ TA_TPRI）の指定ができる．メッセージバッファの送信待ち行 列は，TA_TFIFO（＝ 0x00）が指 定された場合には FIFO 順，
TA_TPRI（＝ 0x01）が指定された場合にはタスクの優先度順となる．
mbfで指定された番地から mbfszバイトのメモリ領域を，メッセージバッファ
領域として使用する．メッセージバッファ領域内には，メッセージを管理する
ための情報も置くため，メッセージバッファ領域のすべてをメッセージを格納するために使えるわけではない．TSZ_MBFを用いると，アプリケーションプ
ログラムから，mbfszに指定すべきサイズの目安を知ることができる．mbfにNULL（＝ 0）が指定された場合には，mbfszで指定されたサイズのメモリ領域
を，カーネルが確保する．mbfszに 0 を指定することも可能である．
maxmszに 0 が指定された場合や，実装定義の最大値よりも大きい値が指定された場合には，E_PAR エラーを返す．また，mbfsz に実装定義の最大値よりも大きい値が指定された場合にも，E_PAR エラーを返す．
【補足説明】
メッセージバッファの受信待ち行列は，常に FIFO 順となる．また，メッセー
ジバッファにメッセージを入れる順序も，FIFO 順のみをサポートしている．
mbfにNULLが指定された場合にカーネルが確保するメッセージバッファ領域のサイズは，mbfsz に指定されたサイズ以上であれば，それよりも大きくてもよい．
【µITRON3.0 仕様との相違】
メッセージバッファ属性の TA_TPRI は，µITRON3.0 仕様では受信待ち行列をタスクの優先度順とする指定であったが，送信待ち行列をタスクの優先度順とする指定に変更した．これは，送信待ち行列をタスクの優先度順とする機能の方が有用性が高いためである．
メッセージバッファ生成情報に，メッセージバッファ領域の先頭番地（mbf）

189

µITRON4.0 仕様

Ver. 4.01.00

を追加し，拡張情報を削除した．パラメータの名称を bufszから mbfszに変更
し，メッセージバッファ生成情報を入れたパケット中での maxmsz と mbfszの順序を交換した．また，maxmszのデータ型を INT から UINTに， mbfszのデータ型を INTから SIZEにそれぞれ変更した．
acre_mbfは新設のサービスコールである．

190

µITRON4.0 仕様

del_mbf

Ver. 4.01.00

メッセージバッファの削除【C 言語 API】
ER ercd = del_mbf ( ID mbfid ) ;【パラメータ】
IDmbfid

削除対象のメッセージバッファの ID番号

【リターンパラメータ】
ER
ercd

正常終了（E_OK）またはエラーコード【エラーコード】
E_ID
E_NOEXS

不正 ID 番号（mbfid が不正あるいは使用できない）
オブジェクト未生成（対象メッセージバッファが未登録）【機能】
mbfid で指定されるメッセージバッファを削除する．メッセージバッファ領域
をカーネルで確保した場合には，その領域を解放する．
【補足説明】
対象メッセージバッファに入っていたメッセージは破棄される．対象メッセー
ジバッファで送信または受信を待っているタスクがある場合の扱いについては，3.8 節を参照すること．

191

µITRON4.0 仕様

snd_mbf
psnd_mbf
tsnd_mbf

Ver. 4.01.00

メッセージバッファへの送信
メッセージバッファへの送信（ポーリング）
メッセージバッファへの送信（タイムアウトあり）【C 言語 API】
ER ercd = snd_mbf ( ID mbfid, VP msg, UINT msgsz ) ;ER ercd = psnd_mbf ( ID mbfid, VP msg, UINT msgsz ) ;ER ercd = tsnd_mbf ( ID mbfid, VP msg, UINT msgsz,
TMO tmout ) ;【パラメータ】
ID
VP
UINT
TMO

mbfid
msg
msgsz
tmout

【リターンパラメータ】
ER
ercd【エラーコード】
E_ID
E_NOEXS
E_PAR
E_RLWAIE_TMOUT
E_DLT

送信対象のメッセージバッファの ID 番号
送信メッセージの先頭番地
送信メッセージのサイズ（バイト数）
タイムアウト指定（tsnd_mbf のみ）
正常終了（E_OK）またはエラーコード

不正 ID 番号（mbfidが不正あるいは使用できない）
オブジェクト未生成（対象メッセージバッファが未登録）
パラメータエラー（msg，msgsz，tmoutが不正）待ち状態の強制解除（待ち状態の間に rel_wai を受付；
psnd_mbf以外）
ポーリング失敗またはタイムアウト（snd_mbf 以外）
待ちオブジェクトの削除（待ち状態の間に対象メッセー
ジバッファが削除；psnd_mbf以外）【機能】
mbfidで指定されるメッセージバッファに，msgで指定される番地から msgsz
で指定されるバイト数のメモリ領域に格納されたメッセージを送信する．具体的な処理内容は次の通りである．
対象メッセージバッファで受信を待っているタスクがある場合には，受信待ち行列の先頭のタスクが受信メッセージを格納する領域に送信メッセージをコ
ピーし，そのタスクを待ち解除する．この時，待ち解除されたタスクに対しては，待ち状態に入ったサービスコールの返値として，送信メッセージのサイズ（msgsz）を返す．
受信を待っているタスクがない場合は，自タスクより優先してメッセージを送信できるタスクが待っているかどうかによって処理が異なる．対象メッセージ
バッファで送信を待っているタスクがない場合や，メッセージバッファ属性に192

µITRON4.0 仕様

Ver. 4.01.00

TA_TPRI（＝ 0x01）が指定されており，送信を待っているタスクの優先度がいずれも自タスクの優先度よりも低い場合には，送信メッセージをメッセージ
バッファの末尾にコピーする．この条件を満たさない場合や，メッセージバッ
ファ領域に送信メッセージを格納するために必要な空き領域がない場合には，自タスクを送信待ち行列につなぎ，メッセージバッファへの送信待ち状態に移行させる．
他のタスクがすでに送信待ち行列につながっている場合，自タスクを送信待ち
行列につなぐ処理は次のように行う．メッセージバッファ属性に TA_TFIFO（＝ 0x00）が指定されている場合には，自タスクを送信待ち行列の末尾につな
ぐ．TA_TPRI（＝ 0x01）が指定されている場合には，自タスクを優先度順で送信待ち行列につなぐ．同じ優先度のタスクの中では，自タスクを最後につなぐ．
メッセージバッファで送信を待っているタスクが，rel_wai や ter_tskにより待ち解除されたり，タイムアウトにより待ち解除された結果，送信待ち行列の先頭のタスクが変化する時には，新たに先頭になったタスクから順に可能ならメッ セージ を送信 させ る処理 を行う 必要 がある．具 体的 な処理 内容は，
rcv_mbf によってメッセージバッファからメッセージが取り出された後の処理と同様であるため，rcv_mbfの機能説明を参照すること．また，メッセージ
バッファで送信を待っているタスクの優先度が，chg_pri やミューテックスの操作によって変更された結果，メッセージバッファの送信待ち行列の先頭のタ
スクが変化する時にも，同様の処理が必要である．
psnd_mbfは，snd_mbf の処理をポーリングで行うサービスコール，
tsnd_mbf
は，snd_mbf にタイムアウトの機能を付け加えたサービスコールである．
tmout には，正 の値のタイ ムアウト時 間に加えて， TMO_POL（＝ 0）とTMO_FEVR（＝ –1）を指定することができる．
msgsz が，メッセージバッファの最大メッセージサイズよりも大きい場合には，E_PAR エラーを返す．また，msgsz に 0 が指定された場合にも，E_PAR
エラーを返す．
【補足説明】
tsnd_mbf は，tmout に TMO_POLが指定された場合，E_CTXエラーにならな
い限りは psnd_mbf と全く同じ動作をする．また，tmout に TMO_FEVRが指定された場合は，snd_mbfと全く同じ動作をする．
【µITRON3.0 仕様との相違】
パラメータの順序を変更した．また，msgsz のデータ型を INT から UINTに変
更した．

193

µITRON4.0 仕様

rcv_mbf
prcv_mbf
trcv_mbf

Ver. 4.01.00

メッセージバッファからの受信
メッセージバッファからの受信（ポーリング）
メッセージバッファからの受信（タイムアウトあり）【C 言語 API】
ER_UINT msgsz = rcv_mbf ( ID mbfid, VP msg ) ;ER_UINT msgsz = prcv_mbf ( ID mbfid, VP msg ) ;ER_UINT msgsz = trcv_mbf ( ID mbfid, VP msg, TMO tmout ) ;【パラメータ】
ID
VP
TMO

mbfid
msg
tmout

【リターンパラメータ】
ER_UINT msgsz【エラーコード】
E_ID
E_NOEXS
E_PAR
E_RLWAIE_TMOUT
E_DLT

受信対象のメッセージバッファの ID 番号
受信メッセージを格納する先頭番地
タイムアウト指定（trcv_mbf のみ）
受信メッセージのサイズ（バイト数，正の値）
またはエラーコード

不正 ID 番号（mbfidが不正あるいは使用できない）
オブジェクト未生成（対象メッセージバッファが未登録）
パラメータエラー（msg，tmoutが不正）待ち状態の強制解除（待ち状態の間に rel_wai を受付；
prcv_mbf 以外）
ポーリング失敗またはタイムアウト（rcv_mbf以外）
待ちオブジェクトの削除（待ち状態の間に対象メッセー
ジバッファが削除；prcv_mbf 以外）【機能】
mbfidで指定されるメッセージバッファからメッセージを受信し，msgで指定される番地以降に格納する．受信したメッセージのバイト数は， msgsz に返す．具体的な処理内容は次の通りである．
対象メッセージバッファにメッセージが格納されている場合には，その先頭のメッセージを msg で指定された番地以降にコピーし，そのメッセージサイズを
msgsz に返す．コピーしたメッセージは，メッセージバッファ領域から削除する．メッセージバッファで送信を待っているタスクがある場合には，メッセー
ジを削除した結果，メッセージバッファ領域に，送信待ち行列の先頭のタスク
が送信しようとしているメッセージを格納するために必要な空き領域ができたかを調べる．格納できる場合には，そのタスクが送信しようとしているメッ
セージをメッセージバッファの末尾にコピーし，そのタスクを待ち解除する．
この時，待ち解除されたタスクに対しては，待ち状態に入ったサービスコール
194

µITRON4.0 仕様

Ver. 4.01.00の返値として E_OKを返す．さらに，送信を待っているタスクが残っている場
合には，新たに送信待ち行列の先頭になったタスクに対して同じ処理を繰り返す．
メッセージが格納されていない場合で，対象メッセージバッファで送信を待っているタスクがある場合には（このような状況が起こるのは，メッセージバッ
ファ領域のサイズが，メッセージのサイズによっては一つのメッセージも格納できないほど小さい場合のみである），送信待ち行列の先頭のタスクが送信しようとしているメッセージを msgで指定された番地以降にコピーし，そのタスクを待ち解除する．また，コピーしたメッセージのサイズを msgszに返す．待ち解除されたタスクに対しては，待ち状態に入ったサービスコールの返値として E_OKを返す．
メッセージが格納されていない場合で，送信を待っているタスクもない場合には，自タスクを受信待ち行列につなぎ，メッセージバッファからの受信待ち状
態に移行させる．他のタスクがすでに受信待ち行列につながっている場合には，自タスクを受信待ち行列の末尾につなぐ．
prcv_mbf は，rcv_mbf の処理をポーリングで行うサービスコール，trcv_mbf
は，rcv_mbf にタイムアウトの機能を付け加えたサービスコールである．
tmout には，正 の値のタイ ムアウト時 間に加えて， TMO_POL（＝ 0）とTMO_FEVR（＝ –1）を指定することができる．
【補足説明】
これらのサービスコールにより，複数のタスクが待ち解除される場合，メッ
セージバッファの送信待ち行列につながれていた順序で待ち解除する．そのため，実行可能状態に移行したタスクで同じ優先度を持つものの間では，送信待ち行列の中で前につながれていたタスクの方が高い優先順位を持つことになる．
trcv_mbf は，tmout に TMO_POLが指定された場合，E_CTXエラーにならな
い限りは prcv_mbf と全く同じ動作をする．また，tmout に TMO_FEVRが指定された場合は，rcv_mbfと全く同じ動作をする．
【µITRON3.0 仕様との相違】
受信メッセージのサイズ（msgsz）を，サービスコールの返値として返すこととした．パラメータの順序を変更した．また，msgsz のデータ型を INT から
UINT（実際には， ER_UINT）に変更した．

195

µITRON4.0 仕様

ref_mbf

Ver. 4.01.00

メッセージバッファの状態参照【C 言語 API】
ER ercd = ref_mbf ( ID mbfid, T_RMBF *pk_rmbf ) ;【パラメータ】
ID
mbfid
T_RMBF * pk_rmbf【リターンパラメータ】
ER
ercd

状態参照対象のメッセージバッファの ID 番号
メッセージバッファ状態を返すパケットへのポインタ
正常終了（E_OK）またはエラーコード

pk_rmbf の内容（T_RMBF 型）
メッセージバッファの送信待ち行列の先頭のIDstskidタスクの ID 番号
メッセージバッファの受信待ち行列の先頭のID
rtskidタスクの ID 番号UINT
smsgcnt メッセージバッファに入っているメッセージの数
メッセージバッファ領域の空き領域のサイズ
SIZE
fmbfsz（バイト数，最低限の管理領域を除く）（実装独自に他の情報を追加してもよい）【エラーコード】
E_ID
E_NOEXS
E_PAR

不正 ID 番号（mbfidが不正あるいは使用できない）
オブジェクト未生成（対象メッセージバッファが未登録）
パラメータエラー（pk_rmbf が不正）【機能】
mbfidで指定されるメッセージバッファに関する状態を参照し，pk_rmbfで指定されるパケットに返す．
対象メッセージバッファの送信待ち行列の先頭のタスクの ID番号
stskidには，を返す．送信を待っているタスクがない場合には，TSK_NONE（＝ 0）を返す．
対象メッセージバッファの受信待ち行列の先頭のタスクの ID番号
rtskidには，を返す．受信を待っているタスクがない場合には，TSK_NONE（＝ 0）を返す．
対象メッセージバッファに現在入っているメッセージの個数を
smsgcnt には，
返す．
fmbfszには，対象メッセージバッファ領域の空き領域のサイズ（バイト数）から，最低限の管理領域のサイズを引いた値を返す．具体的には，対象メッセー
ジバッファ領域に，最大サイズのメッセージを格納するのに十分な空き領域が196

µITRON4.0 仕様

Ver. 4.01.00

ない場合には，空き領域に格納できるメッセージの最大サイズを fmbfsz に返す．対象メッセージバッファ領域に，最大サイズのメッセージを格納できる空き領域がある場合には，メッセージバッファ領域にあとどの程度のメッセージを格納できるかの目安となる値を fmbfsz に返す．
【補足説明】
fmbfsz に返す値以下のサイズのメッセージであっても，対象メッセージバッ
ファで送信を待っているタスクがある場合（stskid ≠ TSK_NONE の場合）には，待ち状態に入ることなく送信できるとは限らない．
rtskid ≠ TSK_NONE と smsgcnt ≠ 0 が同時に成立することはない．また，
stskid≠ TSK_NONE の時には，fmbfszはメッセージの最大サイズよりも小さい値となる．
【µITRON3.0 仕様との相違】参照できる情報から拡張情報を削除した．待ちタスクの有無ではなく待ち行列の先頭のタスクの ID番号を，次に受信されるメッセージのサイズに代えてメッ
セージバッファに入っているメッセージの数を返すこととした．これらに伴って，リターンパラメータの名称とデータ型を変更した．また，fmbfsz に返す
値から，最低限の管理領域のサイズを除くこととし，メッセージバッファ領域の空き領域が少ない場合に返す値の意味を厳密化した．
リターンパラメータの名称を frbufsz から fmbfsz に変更し，そのデータ型をINTから SIZEに変更した．また，パラメータとリターンパラメータの順序を変
更した．

197

µITRON4.0 仕様

Ver. 4.01.00

4.5.3 ランデブ
ランデブ機能は，タスク間で同期通信を行うための機能で，あるタスクから別のタスクへの処理依頼と，後者のタスクから前者のタスクへの処理結果の返却を，一連の手順としてサポートする．双方のタスクが待ち合わせるためのオブジェクトを，ランデブポートと呼ぶ．ランデブ機能は，典型的にはクライアン
ト／サーバモデルのタスク間通信を実現するために用いられるが，クライアン
ト／サーバモデルよりも柔軟な同期通信モデルを提供するものである．
ランデブ機能には，ランデブポートを生成／削除する機能，ランデブポートに対して処理の依頼を行う機能（ランデブの呼出し），ランデブポートで処理依頼を受け付ける機能（ランデブの受付），処理結果を返す機能（ランデブの終了），受け付けた処理依頼を他のランデブポートに回送する機能（ランデブの回送）ランデブポートおよびランデブの状態を参照する機能が含まれる．ラン
デブポートは ID 番号で識別されるオブジェクトである．ランデブポートの ID
番号をランデブポート ID と呼ぶ．
ランデブポートに対して処理依頼を行う側のタスク（クライアント側のタスク）は，ランデブポートとランデブ条件，依頼する処理に関する情報を入れた
メッセージ（これを呼出しメッセージと呼ぶ）を指定して，ランデブの呼出しを行う．一方，ランデブポートで処理依頼を受け付ける側のタスク（サーバ側のタスク）は，ランデブポートとランデブ条件を指定して，ランデブの受付を行う．
ランデブ条件は，ビットパターンで指定する．あるランデブポートに対して，呼び出したタスクのランデブ条件のビットパターンと，受け付けたタスクのランデブ条件のビットパターンをビット毎に論理積をとり，結果が 0以外の場合にランデブが成立する．ランデブを呼び出したタスクは，ランデブが成立するまでランデブ呼出し待ち状態となる．逆に，ランデブを受け付けるタスクは，ランデブが成立するまでランデブ受付待ち状態となる．
ランデブが成立すると，ランデブを呼び出したタスクから受け付けたタスク
へ，呼出しメッセージが渡される．ランデブを呼び出したタスクはランデブ終了待ち状態へ移行し，依頼した処理が完了するのを待つ．一方，ランデブを受け付けたタスクは待ち解除され，依頼された処理を行う．ランデブを受け付けたタスクが依頼された処理を完了すると，処理結果を返答メッセージの形で呼び出したタスクに渡し，ランデブを終了する．この時点で，ランデブを呼び出したタスクが，ランデブ終了待ち状態から待ち解除される．
ランデブポートは，ランデブ呼出し待ち状態のタスクをつなぐための呼出し待
ち行列と，ランデブ受付待ち状態のタスクをつなぐための受付待ち行列を持つ．それに対して，ランデブが成立した後は，ランデブした双方のタスクはランデブポートから切り離される．すなわち，ランデブポートは，ランデブ終了
待ち状態のタスクをつなぐための待ち行列は持たない．また，ランデブを受け付け，依頼された処理を実行しているタスクに関する情報も持たない．
カーネルは，同時に成立しているランデブを識別するために，オブジェクト番
198

µITRON4.0 仕様

Ver. 4.01.00

号を付与する．ランデブのオブジェクト番号をランデブ番号と呼ぶ．ランデブ
番号の付与方法は実装依存であるが，少なくとも，ランデブを呼び出したタス
クを指定するための情報を含んでいなければならない．また，同じタスクが呼び出したランデブであっても，1 回目のランデブと 2 回目のランデブで異なる
ランデブ番号を付与するなど，できる限りユニークにしなければならない．
ランデブ機能では，次のデータ型を用いる．
RDVPTN
RDVNO

ランデブ条件のビットパターン（符号無し整数）
ランデブ番号

ランデブ機能に関連して，次のカーネル構成定数を定義する．
TBIT_RDVPTN

ランデブ条件のビット数（RDVPTNの有効ビット数）

ランデブポート生成情報，ランデブポート状態，およびランデブ状態のパケット形式として，次のデータ型を定義する．
typedef struct t_cpor {ATR
poratr ;/* ランデブポート属性 */UINT
maxcmsz ; /* 呼出しメッセージの最大サイズ（バイト数）*/
UINT
maxrmsz ; /* 返答メッセージの最大サイズ（バイト数）*//* 実装独自に他のフィールドを追加してもよい */} T_CPOR ;typedef struct t_rpor {IDctskid ;/* ランデブポートの呼出し待ち行列の先頭のタスクの ID番号 */ID
atskid ;/* ランデブポートの受付待ち行列の先頭のタスクの ID番号 *//* 実装独自に他のフィールドを追加してもよい */} T_RPOR ;typedef struct t_rrdv {ID
wtskid ;/* ランデブ終了待ち状態のタスクの ID
番号 *//* 実装独自に他のフィールドを追加してもよい */} T_RRDV ;ランデブ機能の各サービスコールの機能コードは次の通りである．
TFN_CRE_POR
TFN_ACRE_POR
TFN_DEL_POR
TFN_CAL_POR
TFN_TCAL_POR
TFN_ACP_POR
TFN_PACP_POR
TFN_TACP_POR

–0x95
–0xc8
–0x96
–0x97
–0x98
–0x99
–0x9a
–0x9b

cre_por の機能コード
acre_por の機能コード
del_porの機能コード
cal_por の機能コード
tcal_porの機能コード
acp_porの機能コード
pacp_por の機能コード
tacp_porの機能コード

199

µITRON4.0 仕様

Ver. 4.01.00

TFN_FWD_POR
TFN_RPL_RDV
TFN_REF_POR
TFN_REF_RDV

–0x9c
–0x9d
–0x9e
–0x9f

fwd_porの機能コード
rpl_rdv の機能コード
ref_porの機能コード
ref_rdv の機能コード【補足説明】
ランデブ機能は，ADAの言語仕様に導入されている同期／通信機能であり，その元になっているのは CSP（Communicating Sequential Processes）である．ただし，ADA のランデブ機能は言語仕様の一部であり，リアルタイムカーネル仕様である µITRON4.0 仕様が提供するランデブ機能とは位置付けが異なる．具体的には，リアルタイムカーネルが提供するランデブ機能は，言語のランデブ機能を実現するためのプリミティブに位置付けられるものであるが，ADA のランデブ機能と µITRON4.0 仕様のランデブ機能にはいくつかの相違があり，ADAのランデブを実現するために，µITRON4.0 仕様のランデブ機能を使えるとは限らない．
ランデブの動作を図 4-3 の例を用いて説明する．この図で，タスク A とタスク
B は非同期に実行しているものとする．

タスクA

タスクB

タスクA

acp_por ( porid )cal_por ( porid )
呼出し
待ち状態
終了待ち
状態

タスクB

acp_por ( porid )rpl_rdv ( rdvno )cal_por ( porid )
終了待ち
状態

受付待ち
状態

rpl_rdv ( rdvno )(b) acp_por が先の場合(a) cal_por が先の場合

図 4-3. ランデブの動作• もしタスク A が先に cal_por を呼び出した場合には，タスク Bが acp_porを呼び出すまでタスク Aは待ち状態となる．この時タスク Aは，ランデブの呼出し待ち状態になっている（図 4-3 (a)）．
• 逆にタスク B が先に acp_por を呼び出した場合には，タスク Aが cal_porを呼び出すまでタスク B は待ち状態となる．この時タスク B は，ランデブの受付待ち状態になっている（図 4-3 (b)）．
• タスク A が cal_por を呼び出し，タスク Bが acp_porを呼び出した時点でランデブが成立し，タスク A を待ち状態としたまま，タスク Bが待ち解除される．この時タスク Aは，ランデブの終了待ち状態になっている．

200

µITRON4.0 仕様

Ver. 4.01.00• タスク B が rpl_rdvを呼び出した時点で，タスク A は待ち解除される．その後は，両タスクとも実行できる状態となる．
ランデブ番号の具体的な付与方法の例として，ランデブ番号の下位ビットをラ
ンデブを呼び出したタスクの ID 番号，上位ビットをシーケンシャルな番号とする方法がある．例えば，ID 番号が 16 ビットの場合には，シーケンシャルな
番号も 16ビットとし，ランデブ番号を 32ビットの整数値とすることができる．
【µITRON3.0 仕様との相違】
ポートに代えて，ランデブポートという用語を用いることとした．
ランデブ条件のビットパターンを入れるパラメータのデータ型を，UINT から
専用のデータ型として新設した RDVPTN に変更した．また，ランデブ番号のデータ型を，RNOから RDVNO に変更した．
【仕様決定の理由】
ランデブ機能は，他の同期・通信機能を組み合わせて実現することも可能であるが，返答を伴う通信を行う場合には，それ専用の機能を用意した方が，アプ
リケーションプログラムが書きやすく，他の同期・通信機能を組み合わせるよ
りも効率を上げることができると考えられる．一例として，ランデブ機能は，メッセージの受渡しが終わるまで双方のタスクを待たせておくために，メッ
セージを格納するための領域が必要ないという利点がある．
同じタスクが呼び出したランデブであっても，ランデブ番号をできる限りユ
ニークにしなければならないのは，次の理由による．ランデブが成立してランデブ終了待ち状態となっているタスクが，タイムアウトや待ち状態の強制解除などにより待ち解除された後，再度ランデブを呼び出してランデブが成立した場合を考える．この時，最初のランデブのランデブ番号と，後のランデブのラ
ンデブ番号が同一の値であると，最初のランデブを終了させようとした時に，ランデブ番号が同一であるために後のランデブが終了してしまう．2 つのラン
デブに異なるランデブ番号を付与し，ランデブ終了待ち状態のタスクに待ち対
象のランデブ番号を記憶しておけば，最初のランデブを終了させようとした時にエラーとすることができる．

201

µITRON4.0 仕様

CRE_POR
cre_poracre_porVer. 4.01.00

ランデブポートの生成（静的 API）
ランデブポートの生成
ランデブポートの生成（ID番号自動割付け）【静的 API】
CRE_POR ( ID porid, { ATR poratr, UINT maxcmsz,
UINT maxrmsz } ) ;【C 言語 API】
ER ercd = cre_por ( ID porid, T_CPOR *pk_cpor ) ;ER_ID porid = acre_por ( T_CPOR *pk_cpor ) ;【パラメータ】
ID
T_CPOR *porid
pk_cpor

生成対象のランデブポートのID番号（acre_por
以外）
ランデブポート生成情報を入れたパケットへのポインタ（CRE_PORではパケットの内容を直接記述する）

pk_cporの内容（T_CPOR型）
ランデブポート属性
ATR
poratrUINT
maxcmsz 呼出しメッセージの最大サイズ（バイト数）
UINT
maxrmsz 返答メッセージの最大サイズ（バイト数）（実装独自に他の情報を追加してもよい）【リターンパラメータ】
cre_por の場合
ER
ercd
acre_por の場合
ER_ID
porid
【エラーコード】
E_ID
E_NOID
E_RSATR
E_PAR
E_OBJ

正常終了（E_OK）またはエラーコード
生成したランデブポートの ID 番号（正の値）またはエラーコード

不正 ID 番号（porid が不正あるいは使用できない；
cre_porのみ）
ID 番号不足（割付け可能なランデブポート ID がない；
acre_porのみ）
予約属性（poratrが不正あるいは使用できない）
パラメータエラー（pk_cpor，maxcmsz，maxrmszが不正）
オブジェクト状態エラー（対象ランデブポートが登録済
み；cre_porのみ）

202

µITRON4.0 仕様

Ver. 4.01.00【機能】
poridで指定される ID番号を持つランデブポートを，pk_cporで指定されるランデブポート生成情報に基づいて生成する．poratr はランデブポートの属性，
maxcmszは呼出しメッセージの最大サイズ（バイト数），maxrmszは返答メッ
セージの最大サイズ（バイト数）である．
CRE_POR においては，poridは自動割付け対応整数値パラメータ，poratrはプ
リプロセッサ定数式パラメータである．
acre_por は，生成するランデブポートの ID 番号をランデブポートが登録されていない ID 番号の中から割り付け，割り付けた ID 番号を返値として返す．
poratrには，（TA_TFIFO‖ TA_TPRI）の指定ができる．ランデブポートの呼出し待ち行列は，TA_TFIFO（＝ 0x00）が指定された場合には FIFO順，TA_TPRI（＝ 0x01）が指定された場合にはタスクの優先度順となる．
maxcmszまたは maxrmszに，実装定義の最大値よりも大きい値が指定された場合には，E_PARエラーを返す．maxcmsz と maxrmszに 0を指定することは可能である．
【補足説明】
ランデブポートの受付待ち行列は，常に FIFO順となる．
【µITRON3.0 仕様との相違】
ランデブ属性（TA_TPRI）により，ランデブの呼出し待ち行列をタスクの優先度順とする機能を追加した．
ランデブポート生成情 報から，拡張情報を削除した．また， maxcmsz とmaxrmsz のデータ型を，INTから UINT に変更した．
acre_porは新設のサービスコールである．

203

µITRON4.0 仕様

del_porVer. 4.01.00

ランデブポートの削除【C 言語 API】
ER ercd = del_por ( ID porid ) ;【パラメータ】
ID

porid【リターンパラメータ】
ER
ercd【エラーコード】
E_ID
E_NOEXS

削除対象のランデブポートの ID 番号
正常終了（E_OK）またはエラーコード

不正 ID 番号（poridが不正あるいは使用できない）
オブジェクト未生成（対象ランデブポートが未登録）【機能】
poridで指定されるランデブポートを削除する．
【補足説明】
ランデブポートを削除しても，すでに成立したランデブには影響を与えない．
ランデブを受け付け，依頼された処理を実行しているタスクには通知されない
し，ランデブを呼び出して，ランデブ終了待ち状態となっているタスクもラン
デブ終了待ち状態のままである．また，ランデブポートが削除されていても，ランデブの終了は正常に実行することができる．
それに対して，対象ランデブポートで呼出しまたは受付を待っているタスクがある場合の扱いについては，3.8 節を参照すること．

204

µITRON4.0 仕様

cal_por
tcal_porVer. 4.01.00

ランデブの呼出し
ランデブの呼出し（タイムアウトあり）【C 言語 API】
ER_UINT rmsgsz = cal_por ( ID porid, RDVPTN calptn, VP msg,
UINT cmsgsz ) ;ER_UINT rmsgsz = tcal_por ( ID porid, RDVPTN calptn, VP msg,
UINT cmsgsz, TMO tmout ) ;【パラメータ】
ID
RDVPTN

porid
calptn

VP

msg

UINT
TMO

cmsgsztmout【リターンパラメータ】
ER_UINT rmsgsz【エラーコード】
E_ID
E_NOEXS
E_PAR
E_RLWAIE_TMOUT
E_DLT

呼出し対象のランデブポートの ID番号
呼出し側のランデブ条件を示すビットパター
ン
呼出しメッセージの先頭番地／返答メッセー
ジを格納する先頭番地
呼出しメッセージのサイズ（バイト数）
タイムアウト指定（tcal_por のみ）
返答メッセージのサイズ（バイト数，正の値または 0）またはエラーコード

不正 ID 番号（porid が不正あるいは使用できない）
オブジェクト未生成（対象ランデブポートが未登録）
パラメータエラー（calptn，msg，cmsgsz，tmout が
不正）待ち状態の強制解除（待ち状態の間に rel_waiを受付）
ポーリング失敗またはタイムアウト（tcal_por のみ）
待ちオブジェクトの削除（ランデブの呼出し待ち状態の間に対象ランデブポートが削除）【機能】
poridで指定されるランデブポートに対して，calptnで指定されるランデブ条
件により，ランデブを呼び出す．msg で指定される番地から cmsgszで指定されるバイト数のメモリ領域に格納されたメッセージを，呼出しメッセージとする．また，返答メッセージを msg で指定される番地以降に格納し，返答メッ
セージのバイト数を rmsgsz に返す．具体的な処理内容は次の通りである．
対象ランデブポートにランデブ受付待ち状態のタスクがあり，そのタスクのランデブ条件と calptn で指定されたランデブ条件が成立する場合には，ランデブを成立させる．ランデブ受付待ち状態のタスクが複数ある場合には，受付待ち行列の先頭のタスクから順にランデブ条件を調べ，条件が成立する最初のタ
205

µITRON4.0 仕様

Ver. 4.01.00

スクとの間でランデブを成立させる．
この時，成立したランデブにランデブ番号を付与し，自タスクをランデブ終了
待ち状態に移行させる．また，成立したランデブの相手タスク（ランデブ受付
待ち状態であったタスク）が呼出しメッセージを格納する領域に，msg とcmsgsz で指定される呼出しメッセージをコピーし，そのタスクを待ち解除する．待ち解除されたタスクに対しては，待ち状態に入ったサービスコールの返値として呼出しメッセージのサイズ（cmsgsz）を返し，付与したランデブ番号を成立したランデブ番号として返す．
対象ランデブポートにランデブ受付待ち状態のタスクがない場合や，ランデブ
受付待ち状態のタスクがあってもランデブ条件が成立しない場合には，自タスクを呼出し待ち行列につなぎ，ランデブ呼出し待ち状態に移行させる．
他のタスクがすでに呼出し待ち行列につながっている場合，自タスクを呼出し待ち行列につなぐ処理は次のように行う．ランデブポート属性に TA_TFIFO（＝ 0x00）が指定されている場合には，自タスクを呼出し待ち行列の末尾につなぐ．TA_TPRI（＝ 0x01）が指定されている場合には，自タスクを優先度順で呼出し待ち行列につなぐ．同じ優先度のタスクの中では，自タスクを最後につなぐ．
tcal_por は，cal_por にタイムアウトの機能を付け加えたサービスコールである．tcal_por が呼び出されてから，tmoutで指定された時間が経過してもランデブが終了しない場合に，処理をキャンセルして E_TMOUT エラーを返す．
tmoutには，正の値のタイムアウト時間に加えて，TMO_FEVR（＝ –1）を指定することができる．tmout に TMO_POL（＝ 0）が指定された場合には，
E_PAR エラーを返す．
tcal_por が呼び出され，ランデブが成立した後にタイムアウトした場合，一旦成立したランデブを成立する前の状態に戻すことはできず，「サービスコールがエラーコードを返した場合には，サービスコールを呼び出したことによる副作用はない」という原則の例外となっている．この場合，ランデブ相手のタス
クには，ランデブを終了させようとした時点でエラーが報告される．cal_por
または tcal_por でランデブが成立した後のタスクに対して rel_waiが呼び出され，ランデブ終了待ち状態が強制解除された場合（この時，サービスコールは
E_RLWAI エラーを返す）も同様である．それに対して，ランデブポートの削除はすでに成立したランデブには影響を与えないため，ランデブが成立した後に E_DLTエラーを返すことはない．
calptnに 0 が指定された場合には，E_PAR エラーを返す．また，cmsgsz が，対象ランデブポートの呼出しメッセージの最大サイズよりも大きい場合には，
E_PAR エラーを返す．cmsgsz に 0を指定することは可能である．
【補足説明】
アプリケーションは，呼び出したランデブが回送される可能性がある場合には，期待する返答メッセージのサイズにかかわらず，msgで指定される番地から，対象ランデブポートの返答メッセージの最大サイズ分のメモリ領域を確保
206

µITRON4.0 仕様

Ver. 4.01.00

すべきである．また，確保したメモリ領域の内容が破壊されることを想定して，アプリケーションを記述すべきである．これは，ランデブを回送する際に，回送後の呼出しメッセージを msgで指定される番地以降にコピーする場合があるためである．
tcal_por は，tmout に TMO_FEVR が指定された場合，cal_porと全く同じ動作をする．
【µITRON3.0 仕様との相違】
tcal_por のタイムアウト時間の解釈を変更した．それに伴って，pcal_porは意
味を持たなくなったため，µITRON4.0 仕様では廃止した．また，tmout に
TMO_POLが指定された場合には，E_PARエラーを返すこととした．
サイズ 0の呼出しメッセージも許すことにした．
返答メッセージのサイズ（rmsgsz）を，サービスコールの返値として返すこととした．calptn のデータ型を UINT から RDVPTN に，cmsgsz と rmsgszのデータ型を INT から UINT（実際には，rmsgsz は ER_UINT）にそれぞれ変更した．また，パラメータとリターンパラメータの順序を変更した．
【仕様決定の理由】
calptn に 0 が指定された場合を E_PAR エラーとしたのは，この指定をした場
合，決してランデブが成立せず，ランデブ呼出し待ち状態から抜けることができなくなるためである．

207

µITRON4.0 仕様

acp_por
pacp_portacp_porVer. 4.01.00

ランデブの受付
ランデブの受付（ポーリング）
ランデブの受付（タイムアウトあり）【C 言語 API】
ER_UINT cmsgsz = acp_por ( ID porid, RDVPTN acpptn,
RDVNO *p_rdvno, VP msg ) ;ER_UINT cmsgsz = pacp_por ( ID porid, RDVPTN acpptn,
RDVNO *p_rdvno, VP msg ) ;ER_UINT cmsgsz = tacp_por ( ID porid, RDVPTN acpptn,
RDVNO *p_rdvno, VP msg, TMO tmout ) ;【パラメータ】
ID
RDVPTN
VP
TMO

porid
acpptnmsg
tmout【リターンパラメータ】
ER_UINT cmsgsz
RDVNO【エラーコード】
E_ID
E_NOEXS
E_PAR
E_RLWAIE_TMOUT
E_DLT

rdvno

受付対象のランデブポートの ID 番号
受付側のランデブ条件を示すビットパターン
呼出しメッセージを格納する先頭番地
タイムアウト指定（tacp_por のみ）
呼出しメッセージのサイズ（バイト数，正の値
または 0）またはエラーコード成立したランデブ番号

不正 ID 番号（poridが不正あるいは使用できない）
オブジェクト未生成（対象ランデブポートが未登録）
パラメータエラー（acpptn，msg，tmout が不正）待ち状態の強制解除（待ち状態の間に rel_wai を受付；
pacp_por以外）
ポーリング失敗またはタイムアウト（acp_por 以外）
待ちオブジェクトの削除（待ち状態の間に対象ランデブ
ポートが削除；pacp_por以外）【機能】
poridで指定されるランデブポートに対して，acpptnで指定されるランデブ条
件により，ランデブを受け付ける．呼出しメッセージは msgで指定される番地
以降に格納し，呼出しメッセージのバイト数を cmsgszに，成立したランデブ
番号を rdvno に返す．具体的な処理内容は次の通りである．
対象ランデブポートにランデブ呼出し待ち状態のタスクがあり，acpptn で指定されたランデブ条件とそのタスクのランデブ条件が成立する場合には，ランデブを成立させる．ランデブ呼出し待ち状態のタスクが複数ある場合には，呼出し待ち行列の先頭のタスクから順にランデブ条件を調べ，条件が成立する最208

µITRON4.0 仕様

Ver. 4.01.00

初のタスクとの間でランデブを成立させる．
この時，成立したランデブにランデブ番号を付与し，それを rdvno に返す．また，成立したランデブの相手タスク（ランデブ呼出し待ち状態であったタスク）の呼出しメッセージを msg で指定された番地以降にコピーし，そのメッ
セージサイズを cmsgszに返す．ランデブの相手タスクは，ランデブ呼出し待ち行列から外し，ランデブ終了待ち状態に移行させる．
対象ランデブポートにランデブ呼出し待ち状態のタスクがない場合や，ランデブ呼出し待ち状態のタスクがあってもランデブ条件が成立しない場合には，自タスクを受付待ち行列につなぎ，ランデブ受付待ち状態に移行させる．他のタスクがすでに受付待ち行列につながっている場合には，自タスクを受付待ち行
列の末尾につなぐ．
pacp_porは， acp_por の処理をポーリングで行うサービスコール，tacp_por
は，acp_por にタイムアウトの機能を付け加えたサービスコールである．
tmout には，正 の値のタイ ムアウト時 間に加えて， TMO_POL（＝ 0）とTMO_FEVR（＝ –1）を指定することができる．
acpptn に 0 が指定された場合には，E_PAR エラーを返す．
【補足説明】
acp_porにより他のタスクとのランデブが成立したタスクが，そのランデブを終了させる前に，再度 acp_por によりランデブを受け付けることも可能である．新たなランデブの受付は，成立しているランデブと異なるランデブポートを対象としたものであっても，同じランデブポートを対象としたものであってもよい．したがって，同じランデブポートを対象とした場合には，一つのタスクが同一のランデブポートに対して複数のランデブを行っている状態になる．
さらに，成立しているランデブの相手タスクが，タイムアウトや待ち状態の強制解除などにより待ち解除された後，再度ランデブを呼び出す場合を考えると，一つのタスクが同一のランデブポートに対して同一のタスクを相手に複数のランデブを行っている状態も起こりうる．
tacp_por は，tmoutに TMO_POLが指定された場合，E_CTXエラーにならな
い限りは pacp_por と全く同じ動作をする．また，tmout に TMO_FEVR が指定された場合は，acp_porと全く同じ動作をする．
【µITRON3.0 仕様との相違】
呼出しメッセージのサイズ（cmsgsz）を，サービスコールの返値として返すことにした．acpptn のデータ型を UINT から RDVPTN に，rdvno のデータ型
を RNO から RDVNO に，cmsgsz のデータ型を INT から UINT（実際には，
ER_UINT）にそれぞれ変更した．また，パラメータとリターンパラメータの順序を変更した．
【仕様決定の理由】
acpptnに0が指定された場合を E_PARエラーとしたのは，この指定がされた場
合，決してランデブが成立せず，ランデブ受付待ち状態から抜けることができ
209

µITRON4.0 仕様

Ver. 4.01.00

なくなるためである．

210

µITRON4.0 仕様

fwd_porVer. 4.01.00

ランデブの回送【C 言語 API】
ER ercd = fwd_por ( ID porid, RDVPTN calptn, RDVNO rdvno,
VP msg, UINT cmsgsz ) ;【パラメータ】
ID
RDVPTN

porid
calptn

RDVNO
VP
UINT

rdvno
msg
cmsgsz【リターンパラメータ】
ER
ercd【エラーコード】
E_ID
E_NOEXS
E_PAR
E_ILUSE
E_OBJ

回送先のランデブポートの ID番号
呼出し側のランデブ条件を示すビットパター
ン
回送するランデブ番号
呼出しメッセージの先頭番地
呼出しメッセージのサイズ（バイト数）
正常終了（E_OK）またはエラーコード

不正 ID 番号（porid が不正あるいは使用できない）
オブジェクト未生成（対象ランデブポートが未登録）
パラメータエラー（calptn，msg，cmsgsz が不正）サービスコール不正使用（回送先のランデブポートの返答メッセージの最大サイズが大きすぎる）
オブジェクト状態エラー（rdvno が不正）【機能】
rdvno で指定されるランデブ番号を付与されたランデブを，porid で指定されるランデブポートに対して，calptn で指定されるランデブ条件により回送する．msg で指定される番地から cmsgszで指定されるバイト数のメモリ領域に格納されたメッセージを，回送後の呼出しメッセージとする．
fwd_porを呼び出すと，rdvnoで指定されるランデブを呼び出したタスク（以下，これをタスク A と表記する）が，porid で指定されるランデブポートに対して，fwd_porのパラメータとして指定されたランデブ条件と呼出しメッセー
ジにより，ランデブを呼び出したのと同じ結果になる．
fwd_porの具体的な処理内容は次の通りである．
回送先のランデブポートにランデブ受付待ち状態のタスクがあり，そのタスクのランデブ条件と calptn で指定されたランデブ条件が成立する場合には，タスク A とそのタスクとの間でランデブを成立させる．ランデブ受付待ち状態のタスクが複数ある場合には，受付待ち行列の先頭のタスクから順にランデブ条件を調べ，条件が成立する最初のタスクとの間でランデブを成立させる．
この時，新たに成立したランデブにランデブ番号を付与し，タスク Aを新しいランデブに対するランデブ終了待ち状態に移行させる．また，成立したランデ
211

µITRON4.0 仕様

Ver. 4.01.00

ブの相手タスク（ランデブ受付待ち状態であったタスク）が呼出しメッセージを格納する領域に，
msgと cmsgszで指定される呼出しメッセージをコピーし，そのタスクを待ち解除する．待ち解除されたタスクに対しては，待ち状態に入ったサービスコールの返値として呼出しメッセージのサイズ（cmsgsz）を返し，付与したランデブ番号を成立したランデブ番号として返す．
回送先のランデブポートにランデブ受付待ち状態のタスクがない場合や，ラン
デブ受付待ち状態のタスクがあってもランデブ条件が成立しない場合には，タスク A を回送先のランデブポートの呼出し待ち行列につなぎ，ランデブ呼出し待ち状態に移行させる．この時，タスク Aが返答メッセージを格納する領域に，msg と cmsgszで指定される呼出しメッセージをコピーする．
他のタスクがすでに呼出し待ち行列につながっている場合，タスク Aを呼出し
待ち行列につなぐ処理は，次のように行う．回送先のランデブポート属性に
TA_TFIFO（＝ 0x00）が指定されている場合には，タスク Aを呼出し待ち行列の末尾につなぐ．TA_TPRI（＝ 0x01）が指定されている場合には，タスク Aを
優先度順で呼出し待ち行列につなぐ．同じ優先度のタスクの中では，タスク A
を最後につなぐ．
回送先のランデブポートの返答メッセージの最大サイズは，回送するランデブが成立したランデブポートの返答メッセージの最大サイズ以下でなければならない．この条件が満たされない場合には，E_ILUSE エラーを返す．
cmsgsz が，回送先のランデブポートの呼出しメッセージの最大サイズよりも大きい場合や，回送するランデブが成立したランデブポートの返答メッセージの最大サイズよりも大きい場合には，E_PAR エラーを返す．cmsgszに 0を指定することは可能である．
rdvno に，他のタスクが受け付けたランデブ番号を指定することも可能である．言い換えると，fwd_porを呼び出してランデブを回送するタスクは，ランデブを受け付けたタスクとは別のタスクであってもよい．
rdvnoで指定されたランデブを呼び出したタスクが，指定されたランデブの終了待ち状態でない場合には， E_OBJ エラーを返す．また，rdvno に指定された値が，ランデブ番号として解釈できない場合にも，E_OBJエラーを返す．
calptnに 0 が指定された場合には，E_PAR エラーを返す．
【補足説明】
fwd_por の処理が終わった後は，タスク Aがランデブを呼び出した後と同じ状態となることから，ランデブが回送された履歴を記憶しておく必要はない．したがって，回送されてきたランデブをさらに回送することも可能である．
fwd_por の処理はすぐに終了し，fwd_porを呼び出したタスクが待ち状態に入ることはない．msg と cmsgszで指定される呼出しメッセージは，fwd_porの処理で他の領域にコピーされるため，fwd_por からリターンした後は，アプリ
ケーションは呼出しメッセージが格納されていた領域を別の目的に使うことができる．また，fwd_por を呼び出したタスクは，fwd_porの処理が終わった

212

µITRON4.0 仕様

Ver. 4.01.00

後には，回送するランデブが成立したランデブポート，回送先のランデブポー
ト，回送したランデブ，（もしあれば）新たに成立したランデブのいずれとも無関係となる．
tcal_por に対するタイムアウト指定は，tcal_porが呼び出されてからランデブが終了するまでの時間に適用される．そのため，タスク Aが tcal_porによりランデブを呼び出していた場合，ランデブの回送後もタイムアウト指定は継続して有効である．
回送先のランデブポートとして，回送するランデブが成立したランデブポートを指定することも可能である．この場合は，一旦受け付けたランデブを，受け付ける前の状態に戻すことになる．ただし，ランデブ条件と呼出しメッセージ
は，fwd_porで指定されたものを使う．
ランデブを呼び出したタスクが，ランデブが成立した後に，タイムアウトや待ち状態の強制解除などによりランデブ終了待ち状態から待ち解除された場合
でも，ランデブを受け付けたタスクには通知されない．この場合，ランデブを受け付けたタスクが fwd_por を呼び出してランデブを回送しようとすると，
E_OBJ エラーとなる．ランデブの相手タスクが，指定するランデブで終了待ち状態であるかどうかは，ref_rdvを用いて調べることができる．
fwd_porを用いたサーバ分配タスクの動作イメージを図 4-4に示す．

サービス
要求タスク

サーバ分配タスク
acp_por

cal_porポート

fwd_por

fwd_porポート

ポート

acp_por

fwd_porポート

acp_por

処理A
サーバ
タスク

rpl_rdv

acp_por

処理B
サーバ
タスク

rpl_rdv

処理C
サーバ
タスク

rpl_rdv

図 4-4. fwd_porを使ったサーバ分配タスク
213

µITRON4.0 仕様

Ver. 4.01.00【µITRON3.0 仕様との相違】
タスク A がランデブ呼出し待ち状態になる時に，msg と cmsgszで指定される
呼出しメッセージを保存する領域を，タスク Aが返答メッセージを格納する領域とすることを規定した．
tcal_por のタイムアウト時間の解釈を変更したことに伴って，fwd_porにおけるタイムアウトの扱いが変更になった．
ランデブを受け付けたタスクとは別のタスクがランデブを回送できることを明確にした．
サイズ 0 の呼出しメッセージも許すことにした．
calptn のデータ型を UINT から RDVPTN に， rdvno のデータ型を RNO から
RDVNO に，cmsgszのデータ型を INTから UINTにそれぞれ変更した．
【仕様決定の理由】
ランデブが回送された履歴を記憶しておく必要がない仕様としたのは，システ
ムで持つべき状態の数を減らすためである．履歴を記憶しておく必要がある用
途では，fwd_por を使って回送する代わりに，cal_por を使ってランデブを（多段に）呼び出せばよい．
回送先のランデブポートの返答メッセージの最大サイズが，回送するランデブが成立したランデブポートの返答メッセージの最大サイズより大きい場合にエラーとするのは，次の理由による．タスク Aは，返答メッセージを格納するための領域として，最初に呼び出したランデブポートの返答メッセージの最大サイズを確保しておかなければならないとしているが，回送先のランデブポー
トの返答メッセージの最大サイズがこれより大きいと，タスク Aが確保した領域に返答メッセージが収まらなくなる可能性があるためである．
cmsgsz が，回送するランデブが成立したランデブポートの返答メッセージの最大サイズよりも大きい場合にエラーとするのは，タスク Aがランデブ呼出し待ち状態になる時に，msgと cmsgsz で指定される呼出しメッセージを，タス
ク A が返答メッセージを格納するための確保した領域にコピーするためである．

214

µITRON4.0 仕様

rpl_rdv

Ver. 4.01.00

ランデブの終了【C 言語 API】
ER ercd = rpl_rdv ( RDVNO rdvno, VP msg, UINT rmsgsz ) ;【パラメータ】
RDVNO
VP
UINT

rdvno
msg
rmsgsz【リターンパラメータ】
ER
ercd【エラーコード】
E_PAR
E_OBJ

終了させるランデブ番号
返答メッセージの先頭番地
返答メッセージのサイズ（バイト数）
正常終了（E_OK）またはエラーコード

パラメータエラー（msg，rmsgsz が不正）オブジェクト状態エラー（rdvno が不正）【機能】
rdvno で指定されるランデブ番号を付与されたランデブを終了させる．msgで指定される番地から rmsgszで指定されるバイト数のメモリ領域に格納されたメッセージを，返答メッセージとする．
具体的には，rdvno で指定されたランデブを呼び出したタスクが，指定されたランデブの終了待ち状態である場合には，相手タスクが返答メッセージを格納する領域に msgと rmsgszで指定される返答メッセージをコピーし，相手タスクを待ち解除する．また，待ち解除された相手タスクに対しては，待ち状態に入ったサービスコールの返値として返答メッセージのサイズ（rmsgsz）を返す．
rdvno で指定されたランデブを呼び出したタスクが，指定されたランデブの終了待ち状態でない場合には，E_OBJ エラーを返す．また，rdvno に指定された値が，ランデブ番号として解釈できない場合にも，E_OBJエラーを返す．
rdvno に，他のタスクが受け付けたランデブ番号を指定することも可能である．言い換えると，rpl_rdv を呼び出してランデブを終了させるタスクは，ランデブを受け付けたタスクとは別のタスクであってもよい．
rmsgsz が，ランデブが成立したランデブポートの返答メッセージの最大サイズよりも大きい場合には，E_PAR エラーを返す．rmsgsz に 0を指定することは可能である．
【補足説明】
ランデブを呼び出したタスクが，ランデブが成立した後に，タイムアウトや待ち状態の強制解除などによりランデブ終了待ち状態から待ち解除された場合
でも，ランデブを受け付けたタスクには通知されない．この場合，ランデブを受け付けたタスクが rpl_rdv を呼び出してランデブを終了させたようとする
215

µITRON4.0 仕様

Ver. 4.01.00と，E_OBJ エラーとなる．ランデブの相手タスクが，指定するランデブで終了待ち状態であるかどうかは，ref_rdvを用いて調べることができる．
ランデブが成立した後は，ランデブした双方のタスクともランデブポートから切り離されるが，ランデブポートの返答メッセージの最大サイズは，返答メッ
セージのサイズ（rmsgsz）が最大サイズ以下であるかを調べるために参照する必要があるため，ランデブに関連付けて記憶しておく必要がある．実装方法の例として，呼出し待ち状態となっているタスクの TCB または TCB から参照
可能な領域（スタック領域など）に入れておく方法が考えられる．
【µITRON3.0 仕様との相違】
ランデブを受け付けたタスクとは別のタスクがランデブを終了できることを明確にした．
サイズ 0 の返答メッセージも許すことにした．
rdvnoのデータ型を RNOから RDVNOに，rmsgszのデータ型を INT から UINTにそれぞれ変更した．
【仕様決定の理由】
rpl_rdvのパラメータにランデブポートの ID番号を指定しないのは，ランデブが成立した後は，ランデブを呼び出したタスクはランデブポートから切り離されるためである．
rdvnoが不正の場合に，E_PARエラーではなく E_OBJエラーとしているのは，
rdvnoの不正を静的に検出することはできないためである．

216

µITRON4.0 仕様

ref_porVer. 4.01.00

ランデブポートの状態参照【C 言語 API】
ER ercd = ref_por ( ID porid, T_RPOR *pk_rpor ) ;【パラメータ】
ID
T_RPOR *porid
pk_rpor【リターンパラメータ】
ER
ercd

状態参照対象のランデブポートの ID番号
ランデブポート状態を返すパケットへのポイ
ンタ
正常終了（E_OK）またはエラーコード

pk_rporの内容（ T_RPOR型）
ランデブポートの呼出し待ち行列の先頭のタIDctskidスクの ID番号
ランデブポートの受付待ち行列の先頭のタスIDatskidクの ID番号（実装独自に他の情報を追加してもよい）【エラーコード】
E_ID
E_NOEXS
E_PAR

不正 ID 番号（porid が不正あるいは使用できない）
オブジェクト未生成（対象ランデブポートが未登録）
パラメータエラー（pk_rpor が不正）【機能】
porid で指定されるランデブポートに関する状態を参照し，pk_rpor で指定されるパケットに返す．
対象ランデブポートの呼出し待ち行列の先頭のタスクの ID番号を
ctskidには，返 す．ラン デ ブ 呼 出 し 待 ち 状態 で 待 っ て い る タス ク が な い 場 合 には，
TSK_NONE（＝ 0）を返す．
対象ランデブポートの受付待ち行列の先頭のタスクのID番号を返
atskidには，
す．ランデブ受付待ち状態で待っているタスクがない場合には， TSK_NONE（＝ 0）を返す．
【µITRON3.0 仕様との相違】参照できる情報から拡張情報を削除した．また，待ちタスクの有無ではなく待ち行列の先頭のタスクの ID 番号を返すこととした．これに伴って，リターン
パラメータの名称とデータ型を変更した．また，パラメータとリターンパラ
メータの順序を変更した．

217

µITRON4.0 仕様

ref_rdv

Ver. 4.01.00

ランデブの状態参照【C 言語 API】
ER ercd = ref_rdv ( RDVNO rdvno, T_RRDV *pk_rrdv ) ;【パラメータ】
RDVNO
T_RRDV *rdvno
pk_rrdv【リターンパラメータ】
ER
ercd

状態参照対象のランデブ番号
ランデブポート状態を返すパケットへのポイ
ンタ
正常終了（E_OK）またはエラーコード

pk_rrdv の内容（T_RRDV 型）
ランデブ終了待ち状態のタスクの ID 番号ID
wtskid（実装独自に他の情報を追加してもよい）【エラーコード】
E_PAR

パラメータエラー（pk_rrdvが不正）【機能】
rdvno で指定されるランデブ番号を付与されたランデブに関する状態を参照
し，pk_rrdv で指定されるパケットに返す．
rdvnoで指定されたランデブを呼び出したタスクが，指定されたランデブの終了待ち状態である場合には，そのタスクの ID 番号を wtskidに返す．そのタスクが指定されたランデブの終了待ち状態でない場合や，rdvnoに指定された値がランデブ番号として解釈できない場合，wtskid には TSK_NONE（＝ 0）を返す．
【補足説明】
このサービスコールで wtskidにタスクの ID番号が返る
rpl_rdvや fwd_porが，ランデブ番号を指定して呼びされた場合，E_OBJエラーになることはない．
【µITRON3.0 仕様との相違】
新設のサービスコールである．ITRON2 のランデブ機能には，
このサービスコールに対応する rdv_stsが用意されていた．

218

µITRON4.0 仕様

Ver. 4.01.00

4.6 メモリプール管理機能
メモリプール管理機能は，ソフトウェアによって動的なメモリ管理を行うための機能である．固定長メモリプール，可変長メモリプールの各機能が含まれる．
【補足説明】µITRON4.0 仕様では，多重論理空間やハードウェアのメモリ管理ユニット（MMU）を操作するための機能は規定されない．

4.6.1 固定長メモリプール
固定長メモリプールは，固定されたサイズのメモリブロックを動的に管理するためのオブジェクトである．固定長メモリプール機能には，固定長メモリプー
ルを生成／削除する機能，固定長メモリプールに対してメモリブロックを獲得／返却する機能，固定長メモリプールの状態を参照する機能が含まれる．固定長メモリプールは ID番号で識別されるオブジェクトである．
固定長メモリプー
ルの ID 番号を固定長メモリプール ID と呼ぶ．
固定長メモリプールは，固定長メモリプールとして利用するメモリ領域（これを固定長メモリプール領域，または単にメモリプール領域と呼ぶ）と，メモリブロックの獲得を待つタスクの待ち行列を持つ．固定長メモリプールからメモ
リブロックを獲得するタスクは，メモリプール領域に空きがなくなった場合，
次にメモリブロックが返却されるまで固定長メモリブロックの獲得待ち状態となる．固定長メモリブロックの獲得待ち状態になったタスクは，その固定長
メモリプールの待ち行列につながれる．
固定長メモリプール機能に関連して，次のカーネル構成マクロを定義する．
SIZE mpfsz = TSZ_MPF ( UINT blkcnt, UINT blksz )サイズが blkszバイトのメモリブロックを blkcnt個獲得できるのに必要な固定長メモリプール領域のサイズ（バイト数）
固定長メモリプール生成情報および固定長メモリプール状態のパケット形式
として，次のデータ型を定義する．
typedef struct t_cmpf {ATR
mpfatr ;UINT
blkcnt ;/* 固定長メモリプール属性 *//* 獲得できるメモリブロック数（個
数）*/
UINT
blksz ;/* メモリブロックのサイズ（バイト
数）*/
VP
mpf ;
/* 固定長メモリプール領域の先頭番
地 *//* 実装独自に他のフィールドを追加してもよい */} T_CMPF ;typedef struct t_rmpf {219

µITRON4.0 仕様
ID

Ver. 4.01.00
wtskid ;/* 固定長メモリプールの待ち行列の先頭のタスクの ID番号 */固定長メモリプールの空きメモリブ
UINT
fblkcnt ;/*ロック数（個数）*//* 実装独自に他のフィールドを追加してもよい */} T_RMPF ;固定長メモリプール機能の各サービスコールの機能コードは次の通りである．
TFN_CRE_MPF
TFN_ACRE_MPF
TFN_DEL_MPF
TFN_GET_MPF
TFN_PGET_MPF
TFN_TGET_MPF
TFN_REL_MPF
TFN_REF_MPF

–0x45
–0xc9
–0x46
–0x49
–0x4a
–0x4b
–0x47
–0x4c

cre_mpf の機能コード
acre_mpf の機能コード
del_mpfの機能コード
get_mpfの機能コード
pget_mpfの機能コード
tget_mpf の機能コード
rel_mpf の機能コード
ref_mpfの機能コード【スタンダードプロファイル】
スタンダードプロファイルでは，固定長メモリプールを動的に生成／削除する機能（cre_mpf，acre_mpf，del_mpf），固定長メモリプールの状態を参照する機能（ref_mpf）を除いて，固定長メモリプール機能をサポートしなければならない．
スタンダードプロファイルでは，TSZ_MPF を定義する必要はない．
【補足説明】
固定長メモリプールの場合，何種類かのサイズのメモリブロックが必要となる場合には，サイズ毎に複数のメモリプールを用意する必要がある．

220

µITRON4.0 仕様

CRE_MPF
cre_mpf
acre_mpf

Ver. 4.01.00

固定長メモリプールの生成（静的 API）

【 S】

固定長メモリプールの生成
固定長メモリプールの生成（ ID番号自動割付け）【静的 API】
CRE_MPF ( ID mpfid, { ATR mpfatr, UINT blkcnt, UINT blksz,
VP mpf } ) ;【C 言語 API】
ER ercd = cre_mpf ( ID mpfid, T_CMPF *pk_cmpf ) ;ER_ID mpfid = acre_mpf ( T_CMPF *pk_cmpf ) ;【パラメータ】
ID
T_CMPF *mpfid

生成対象の固定長メモリプールの ID 番号（acre_mpf 以外）
pk_cmpf 固定長メモリプール生成情報を入れたパケッ
トへのポインタ（CRE_MPFではパケットの内容を直接記述する）

pk_cmpfの内容（ T_CMPF型）
ATR
mpfatr
固定長メモリプール属性
UINT
blkcnt獲得できるメモリブロック数（個数）
UINT
blksz
メモリブロックのサイズ（バイト数）
VP
mpf
固定長メモリプール領域の先頭番地（実装独自に他の情報を追加してもよい）【リターンパラメータ】
cre_mpfの場合
ER
ercd
acre_mpfの場合
ER_ID
mpfid
【エラーコード】
E_ID
E_NOID
E_NOMEM
E_RSATR
E_PAR
E_OBJ

正常終了（E_OK）またはエラーコード
生成した固定長メモリプールの ID 番号（正の値）またはエラーコード

不正 ID 番号（mpfid が不正あるいは使用できない；
cre_mpfのみ）
ID 番号不足（割付け可能な固定長メモリプール ID がな
い；acre_mpfのみ）
メモリ不足（メモリプール領域などが確保できない）
予約属性（mpfatrが不正あるいは使用できない）
パラメータエラー（pk_cmpf， blkcnt，blksz，mpf が
不正）
オブジェクト状態エラー（対象固定長メモリプールが登221

µITRON4.0 仕様

Ver. 4.01.00
録済み；cre_mpfのみ）【機能】
mpfidで指定される ID番号を持つ固定長メモリプールを，pk_cmpfで指定される固定長メモリプール生成情報に基づいて生成する．mpfatr は固定長メモリ
プールの属性，blkcntは固定長メモリプールから獲得できるメモリブロックの個数，blksz は獲得するメモリブロックのサイズ（バイト数），mpfは固定長メ
モリプール領域の先頭番地である．
CRE_MPFにおいては，mpfid は自動割付け対応整数値パラメータ，mpfatrはプリプロセッサ定数式パラメータである．
acre_mpfは，生成する固定長メモリプールの ID番号を固定長メモリプールが登録されていない ID 番号の中から割り付け，割り付けた ID 番号を返値として返す．
（TA_TFIFO‖ TA_TPRI）の指定ができる．固定長メモリプール
mpfatrには，の待ち行列は，TA_TFIFO（＝ 0x00）が指定された場合には FIFO順，TA_TPRI（＝ 0x01）が指定された場合にはタスクの優先度順となる．
mpfで指定された番地から，blksz バイトのメモリブロックを blkcnt個獲得できるのに必要なサイズのメモリ領域を，メモリプール領域として使用する．
TSZ_MPF を用いると，アプリケーションプログラムから，blkszバイトのメモ
リブロックを blkcnt個獲得できるのに必要なサイズを知ることができる．mpfに NULL（＝ 0）が指定された場合には，必要なサイズのメモリ領域をカーネルが確保する．
実装定義の最大値よりも大きい値
blkcntまたはblkszに0が指定された場合や，が指定された場合には，E_PAR エラーを返す．
【スタンダードプロファイル】
スタンダードプロファイルでは，mpfに NULL以外の値が指定された場合の機能はサポートする必要がない．
【µITRON3.0 仕様との相違】
固定長メモリプール生成情報に，メモリプール領域の先頭番地（mpf）を追加
し，拡張情報を削除した．パラメータの名称を mpfcnt から blkcnt に， blfsz
から blkszにそれぞれ変更し，それらのデータ型を INT から UINT に変更した．
acre_mpfは新設のサービスコールである．

222

µITRON4.0 仕様

del_mpf

Ver. 4.01.00

固定長メモリプールの削除【C 言語 API】
ER ercd = del_mpf ( ID mpfid ) ;【パラメータ】
ID

mpfid

削除対象の固定長メモリプールの ID番号

【リターンパラメータ】
ER
ercd

正常終了（E_OK）またはエラーコード【エラーコード】
E_ID
E_NOEXS

不正 ID 番号（mpfid が不正あるいは使用できない）
オブジェクト未生成（対象固定長メモリプールが未登録）【機能】
mpfid で指定される固定長メモリプールを削除する．メモリプール領域をカーネルで確保した場合には，その領域を解放する．
【補足説明】
対象固定長メモリプールからメモリブロックの獲得を待っているタスクがある場合の扱いについては，3.8 節を参照すること．

223

µITRON4.0 仕様

get_mpf
pget_mpf
tget_mpf

Ver. 4.01.00

固定長メモリブロックの獲得【S】

固定長メモリブロックの獲得（ポーリング）
固定長メモリブロックの獲得（タイムアウトあり）

【S】
【S】

【C 言語 API】
ER ercd = get_mpf ( ID mpfid, VP *p_blk ) ;ER ercd = pget_mpf ( ID mpfid, VP *p_blk ) ;ER ercd = tget_mpf ( ID mpfid, VP *p_blk, TMO tmout ) ;【パラメータ】
ID
TMO

mpfid
tmout

【リターンパラメータ】
ER
ercd
VP
blk
【エラーコード】
E_ID
E_NOEXS
E_PAR
E_RLWAIE_TMOUT
E_DLT

メモリブロック獲得対象の固定長メモリプー
ルの ID 番号
タイムアウト指定（tget_mpfのみ）
正常終了（E_OK）またはエラーコード獲得したメモリブロックの先頭番地

不正 ID 番号（mpfidが不正あるいは使用できない）
オブジェクト未生成（対象固定長メモリプールが未登録）
パラメータエラー（p_blk，tmoutが不正）待ち状態の強制解除（待ち状態の間に rel_wai を受付；
pget_mpf以外）
ポーリング失敗またはタイムアウト（get_mpf 以外）
待ちオブジェクトの削除（待ち状態の間に対象固定長メ
モリプールが削除；pget_mpf以外）【機能】
mpfidで指定される固定長メモリプールから，固定長メモリプール生成時に指定されたサイズのメモリブロックを獲得し，その先頭番地を blkに返す．具体的には，対象固定長メモリプール領域に空きメモリブロックがある場合には，その内のいずれかを選んで獲得された状態とし，その先頭番地を blk に返す．
空きメモリブロックがない場合には，自タスクを待ち行列につなぎ，固定長メ
モリブロックの獲得待ち状態に移行させる．
他のタスクがすでに待ち行列につながっている場合，自タスクを待ち行列につなぐ処理は次のように行う．固定長メモリプール属性に TA_TFIFO（＝ 0x00）が指定されている場合には，自タスクを待ち行列の末尾につなぐ．TA_TPRI（＝ 0x01）が指定されている場合には，自タスクを優先度順で待ち行列につなぐ．同じ優先度のタスクの中では，自タスクを最後につなぐ．
pget_mpfは， get_mpf の処理をポーリングで行うサービスコール，tget_mpf
224

µITRON4.0 仕様

Ver. 4.01.00

は，get_mpf にタイムアウトの機能を付け加えたサービスコールである．
tmout には，正 の値のタイ ムアウト時 間に加えて， TMO_POL（＝ 0）とTMO_FEVR（＝ –1）を指定することができる．
【補足説明】
獲得するメモリブロックのサイズは，固定長メモリプール生成時に指定されたメモリブロックのサイズ以上であれば，それよりも大きくてもよい．またこれらのサービスコールは，獲得したメモリブロックのクリアは行わないため，その内容は不定となる．
tget_mpfは，tmoutに TMO_POLが指定された場合，E_CTXエラーにならな
い限りは pget_mpf と全く同じ動作をする．また， tmout に TMO_FEVR が指定された場合は，get_mpf と全く同じ動作をする．
【µITRON3.0 仕様との相違】
サービスコールの名称を，get_blf，pget_blf，tget_blfから，それぞれ get_mpf，
pget_mpf，tget_mpfに変更した．リターンパラメータの名称を blf から blkに変更した．また，パラメータとリターンパラメータの順序を変更した．

225

µITRON4.0 仕様

rel_mpf

Ver. 4.01.00

固定長メモリブロックの返却【S】【C 言語 API】
ER ercd = rel_mpf ( ID mpfid, VP blk ) ;【パラメータ】
ID

mpfid

VP

blk

メモリブロック返却対象の固定長メモリプー
ルの ID 番号
返却するメモリブロックの先頭番地【リターンパラメータ】
ER

ercd

正常終了（E_OK）またはエラーコード【エラーコード】
E_ID
E_NOEXS
E_PAR

不正 ID 番号（mpfidが不正あるいは使用できない）
オブジェクト未生成（対象固定長メモリプールが未登録）
パラメータエラー（blk が不正，異なるメモリプールへの返却，獲得したメモリブロックの先頭番地以外の返却）【機能】
mpfid で指定される固定長メモリプールに対して， blk を先頭番地とするメモ
リブロックを返却する．
対象固定長メモリプールでメモリブロックの獲得を待っているタスクがある
場合には，返却したメモリブロックを待ち行列の先頭のタスクに獲得させ，そのタスクを待ち解除する．この時，待ち解除されたタスクに対しては，待ち状態に入ったサービスコールの返値として E_OK を返し，固定長メモリブロックから獲得したメモリブロックの先頭番地として blkの値を返す．
メモリブロックを返却する対象の固定長メモリプールは，メモリブロックの獲得を行った固定長メモリプールと同じものでなければならない．メモリブロッ
クを返却する対象の固定長メモリプールが，メモリブロックの獲得を行った固定長メモリプールと異なっている場合には，E_PAR エラーを返す．
また，返却するメモリブロックの先頭番地は，get_mpf，pget_mpf，tget_mpfのいずれかのサービスコールが，獲得したメモリブロックの先頭番地として返したもので，まだ返却されていないものでなければならない．blk にそれ以外の番地が指定された場合の振舞いは未定義である．エラーを報告する場合には，E_PAR エラーを返す．
【µITRON3.0 仕様との相違】
サービスコールの名称を，rel_blfから rel_mpf に変更した．パラメータの名称
を blf から blk に変更した．
226

µITRON4.0 仕様

ref_mpf

Ver. 4.01.00

固定長メモリプールの状態参照【C 言語 API】
ER ercd = ref_mpf ( ID mpfid, T_RMPF *pk_rmpf ) ;【パラメータ】
ID
T_RMPF *mpfid
pk_rmpf【リターンパラメータ】
ER
ercd

状態参照対象の固定長メモリプールの ID番号
固定長メモリプール状態を返すパケットへのポインタ
正常終了（E_OK）またはエラーコード

pk_rmpf の内容（T_RMPF型）
固定長メモリプールの待ち行列の先頭のタスIDwtskidクの ID番号
固定長メモリプールの空きメモリブロック数
UINT
fblkcnt（個数）（実装独自に他の情報を追加してもよい）【エラーコード】
E_ID
E_NOEXS
E_PAR

不正 ID 番号（mpfid が不正あるいは使用できない）
オブジェクト未生成（対象固定長メモリプールが未登録）
パラメータエラー（pk_rmpfが不正）【機能】
mpfid で指定される固定長メモリプールに関する状態を参照し，pk_rmpfで指定されるパケットに返す．
wtskid には，対象固定長メモリプールの待ち行列の先頭のタスクの ID 番号を返す．メモリブロックの獲得を待っているタスクがない場合には，TSK_NONE（＝ 0）を返す．
fblkcnt には，対象固定長メモリプール領域内の空きメモリブロックの個数を返す．
【補足説明】
wtskid ≠ TSK_NONE と fblkcnt≠ 0 が同時に成立することはない．
【µITRON3.0 仕様との相違】参照できる情報から拡張情報を削除した．また，待ちタスクの有無ではなく，待ち行列の先頭のタスクの ID 番号を返すこととした．これに伴って，リター
ンパラメータの名称とデータ型を変更した．
リターンパラメータの名称をfrbcntからfblkcntに変更し，そのデータ型をINT

227

µITRON4.0 仕様

Ver. 4.01.00

から UINT に変更した．また，パラメータとリターンパラメータの順序を変更
した．

228

µITRON4.0 仕様

Ver. 4.01.00

4.6.2 可変長メモリプール
可変長メモリプールは，任意のサイズのメモリブロックを動的に管理するためのオブジェクトである．可変長メモリプール機能には，可変長メモリプールを生成／削除する機能，可変長メモリプールに対してメモリブロックを獲得／返却する機能，可変長メモリプールの状態を参照する機能が含まれる．可変長メ
モリプールは ID 番号で識別されるオブジェクトである．可変長メモリプールの ID 番号を可変長メモリプール ID と呼ぶ．
可変長メモリプールは，可変長メモリプールとして利用するメモリ領域（これを可変長メモリプール領域，または単にメモリプール領域と呼ぶ）と，メモリブロックの獲得を待つタスクの待ち行列を持つ．可変長メモリプールからメモ
リブロックを獲得するタスクは，メモリプール領域の空き領域が足りなくなった場合，十分なサイズのメモリブロックが返却されるまで可変長メモリブロックの獲得待ち状態となる．可変長メモリブロックの獲得待ち状態になったタス
クは，その可変長メモリプールの待ち行列につながれる．
可変長メモリプール機能に関連して，次のカーネル構成マクロを定義する．
SIZE mplsz = TSZ_MPL ( UINT blkcnt, UINT blksz )サイズが blkszバイトのメモリブロックを blkcnt個獲得できるのに必要な可変長メモリプール領域のサイズ（目安のバイト数）
このマクロは，あくまでもメモリプール領域のサイズを決める際の目安として使うためのものである．このマクロを使って，異なるサイズのメモリブロックを獲得できるのに必要なサイズを決定することはできない．また，フラグメン
トが起こった場合などには，指定した数のメモリブロックが獲得できない場合もある．
可変長メモリプール生成情報および可変長メモリプール状態のパケット形式
として，次のデータ型を定義する．
typedef struct t_cmpl {ATR
mplatr ;SIZE
mplsz ;/* 可変長メモリプール属性 *//* 可変長メモリプール領域のサイズ（バイト数）*/VP
mpl ;/* 可変長メモリプール領域の先頭番
地 *//* 実装独自に他のフィールドを追加してもよい */} T_CMPL ;typedef struct t_rmpl {IDwtskid ;/* 可変長メモリプールの待ち行列の先頭のタスクの ID番号 */SIZEfmplsz ;/* 可変長メモリプールの空き領域の合計サイズ（バイト数）*/
UINT
fblksz ;/* すぐに獲得可能な最大メモリブロッ
クサイズ（バイト数）*//* 実装独自に他のフィールドを追加してもよい */229

µITRON4.0 仕様

Ver. 4.01.00} T_RMPL ;可変長メモリプール機能の各サービスコールの機能コードは次の通りである．
TFN_CRE_MPL
TFN_ACRE_MPL
TFN_DEL_MPL
TFN_GET_MPL
TFN_PGET_MPL
TFN_TGET_MPL
TFN_REL_MPL
TFN_REF_MPL

–0xa1
–0xca
–0xa2
–0xa5
–0xa6
–0xa7
–0xa3
–0xa8

cre_mplの機能コード
acre_mplの機能コード
del_mpl の機能コード
get_mpl の機能コード
pget_mplの機能コード
tget_mplの機能コード
rel_mpl の機能コード
ref_mpl の機能コード【スタンダードプロファイル】
スタンダードプロファイルでは，可変長メモリプール機能はサポートする必要がない．
【補足説明】
可変長メモリプールでメモリブロックの獲得を待っているタスクは，待ち行列につながれている順序でメモリブロックを獲得する．例えば，ある可変長メモ
リプールに対して 400バイトのメモリブロックを獲得しようとしているタスク
A と，100 バイトのメモリブロックを獲得しようとしているタスク B が，この順で待ち行列につながれている時に，別のタスクからのメモリブロックの返却により 200 バイトの連続空きメモリ領域ができたとする．
このような場合でも，
タスク A がメモリブロックを獲得するまで，タスク Bはメモリブロックを獲得できない．ただし，実装独自に，このような場合にタスク B に先にメモリブロックを獲得させる指定を，可変長メモリプール属性に追加することは許される．
【µITRON3.0 仕様との相違】
可変長メモリプールでメモリブロックの獲得を待っているタスクが，待ち行列につながれている順序でメモリブロックを獲得するか，メモリブロックを獲得できるものから先に獲得するかが実装依存となっていたのを，前者に標準化した．

230

µITRON4.0 仕様

CRE_MPL
cre_mplacre_mpl

Ver. 4.01.00

可変長メモリプールの生成（静的 API）
可変長メモリプールの生成
可変長メモリプールの生成（ ID番号自動割付け）【静的 API】
CRE_MPL ( ID mplid, { ATR mplatr, SIZE mplsz, VP mpl } ) ;【C 言語 API】
ER ercd = cre_mpl ( ID mplid, T_CMPL *pk_cmpl ) ;ER_ID mplid = acre_mpl ( T_CMPL *pk_cmpl ) ;【パラメータ】
ID
T_CMPL *mplid

生成対象の可変長メモリプールの ID 番号（acre_mpl以外）
pk_cmpl 可変長メモリプール生成情報を入れたパケッ
トへのポインタ（ CRE_MPLではパケットの内容を直接記述する）

pk_cmplの内容（T_CMPL型）
ATR
mplatr
可変長メモリプール属性
SIZE
mplsz
可変長メモリプール領域のサイズ（バイト数）
VP
mpl
可変長メモリプール領域の先頭番地（実装独自に他の情報を追加してもよい）【リターンパラメータ】
cre_mpl の場合
ER
ercd
acre_mpl の場合
ER_ID
mplid
【エラーコード】
E_ID
E_NOID
E_NOMEM
E_RSATR
E_PAR
E_OBJ

正常終了（E_OK）またはエラーコード
生成した可変長メモリプールの ID 番号（正の値）またはエラーコード

不正 ID 番号（mplid が不正あるいは使用できない；
cre_mplのみ）
ID 番号不足（割付け可能な可変長メモリプール ID がな
い；acre_mplのみ）
メモリ不足（メモリプール領域などが確保できない）
予約属性（mplatrが不正あるいは使用できない）
パラメータエラー（pk_cmpl，mplsz，mplが不正）
オブジェクト状態エラー（対象可変長メモリプールが登録済み；cre_mplのみ）

231

µITRON4.0 仕様

Ver. 4.01.00【機能】
mplidで指定される ID番号を持つ可変長メモリプールを，pk_cmplで指定される可変長メモリプール生成情報に基づいて生成する．mplatr は可変長メモリ
プールの属性，mplsz は可変長メモリプール領域のサイズ（バイト数），mpl
は可変長メモリプール領域の先頭番地である．
CRE_MPL においては，mplid は自動割付け対応整数値パラメータ，mplatrはプリプロセッサ定数式パラメータである．
acre_mpl は，生成する可変長メモリプールの ID番号を可変長メモリプールが登録されていない ID 番号の中から割り付け，割り付けた ID 番号を返値として返す．
（TA_TFIFO‖ TA_TPRI）の指定ができる．可変長メモリプール
mplatr には，の待ち行列は，TA_TFIFO（＝ 0x00）が指定された場合には FIFO順，TA_TPRI（＝ 0x01）が指定された場合にはタスクの優先度順となる．
mplで指定された番地から mplsz バイトのメモリ領域を，メモリプール領域として使用する．メモリプール領域内には，メモリブロックを管理するための情報も置くため，メモリプール領域のすべてをメモリブロックとして獲得できる
わけではない．TSZ_MPL を用いると，アプリケーションプログラムから，
mplszに指定すべきサイズの目安を知ることができる．mplに NULL（＝ 0）が指定された場合には，mplsz で指定されたサイズのメモリ領域を，カーネルが確保する．
mplszに 0が指定された場合や，実装定義の最大値よりも大きい値が指定された場合には，E_PAR エラーを返す．
【補足説明】
mplに NULLが指定された場合にカーネルが確保するメモリプール領域のサイズは，mplszに指定されたサイズ以上であれば，それよりも大きくてもよい．
【µITRON3.0 仕様との相違】
可変長メモリプール生成情報に，メモリプール領域の先頭番地（ mpl）を追加し，拡張情報を削除した．
また，
mplszのデータ型を，INTから SIZEに変更した．
acre_mpl は新設のサービスコールである．

232

µITRON4.0 仕様

del_mplVer. 4.01.00

可変長メモリプールの削除【C 言語 API】
ER ercd = del_mpl ( ID mplid ) ;【パラメータ】
ID

mplid

削除対象の可変長メモリプールの ID番号

【リターンパラメータ】
ER
ercd

正常終了（E_OK）またはエラーコード【エラーコード】
E_ID
E_NOEXS

不正 ID 番号（mplidが不正あるいは使用できない）
オブジェクト未生成（対象可変長メモリプールが未登録）【機能】
mplidで指定される可変長メモリプールを削除する．メモリプール領域をカーネルで確保した場合には，その領域を解放する．
【補足説明】
対象可変長メモリプールからメモリブロックの獲得を待っているタスクがある場合の扱いについては，3.8 節を参照すること．

233

µITRON4.0 仕様

get_mplpget_mpl
tget_mpl

Ver. 4.01.00

可変長メモリブロックの獲得
可変長メモリブロックの獲得（ポーリング）
可変長メモリブロックの獲得（タイムアウトあり）【C 言語 API】
ER ercd = get_mpl ( ID mplid, UINT blksz, VP *p_blk ) ;ER ercd = pget_mpl ( ID mplid, UINT blksz, VP *p_blk ) ;ER ercd = tget_mpl ( ID mplid, UINT blksz, VP *p_blk,
TMO tmout ) ;【パラメータ】
ID
UINT
TMO

mplid
blksz
tmout

【リターンパラメータ】
ER
ercd
VP
blk
【エラーコード】
E_ID
E_NOEXS
E_PAR
E_RLWAIE_TMOUT
E_DLT

メモリブロック獲得対象の可変長メモリプー
ルの ID 番号獲得するメモリブロックのサイズ（バイト数）
タイムアウト指定（tget_mplのみ）
正常終了（E_OK）またはエラーコード獲得したメモリブロックの先頭番地

不正 ID 番号（mplidが不正あるいは使用できない）
オブジェクト未生成（対象可変長メモリプールが未登録）
パラメータエラー（p_blk，tmoutが不正）待ち状態の強制解除（待ち状態の間に rel_wai を受付；
pget_mpl 以外）
ポーリング失敗またはタイムアウト（get_mpl以外）
待ちオブジェクトの削除（待ち状態の間に対象可変長メ
モリプールが削除；pget_mpl 以外）【機能】
mplid で指定される可変長メモリプールから，blksz で指定されるサイズのメ
モリブロックを獲得し，その先頭番地を blkに返す．
具体的な処理内容は，自タスクより優先してメモリブロックを獲得できるタス
クが待っているかどうかによって異なる．対象可変長メモリプールでメモリブロック獲得を待っているタスクがない場合や，可変長メモリプール属性に
TA_TPRI（＝ 0x01）が指定されており，メモリブロック獲得を待っているタス
クの優先度がいずれも自タスクの優先度よりも低い場合には，メモリプール領域から blkszバイトのメモリブロックを獲得する．この条件を満たさない場合
や，メモリブロックを獲得するのに十分な空きメモリ領域がない場合には，自タスクを待ち行列につなぎ，可変長メモリブロックの獲得待ち状態に移行させ
234

µITRON4.0 仕様

Ver. 4.01.00

る．
他のタスクがすでに待ち行列につながっている場合，自タスクを待ち行列につなぐ処理は次のように行う．可変長メモリプール属性に TA_TFIFO（＝ 0x00）が指定されている場合には，自タスクを待ち行列の末尾につなぐ．TA_TPRI（＝ 0x01）が指定されている場合には，自タスクを優先度順で待ち行列につなぐ．同じ優先度のタスクの中では，自タスクを最後につなぐ．
可変長メモリブロックの獲得を待っているタスクが，rel_wai や ter_tskにより待ち解除されたり，タイムアウトにより待ち解除された結果，待ち行列の先頭のタスクが変化する時には，新たに先頭になったタスクから順に可能ならメモ
リブロックを獲得させる処理を行う必要がある．
具体的な処理内容は，rel_mpl
によってメモリブロックが返却された後の処理と同様であるため，rel_mplの機能説明を参照すること．また，可変長メモリブロックの獲得を待っているタ
スクの優先度が，chg_pri やミューテックスの操作によって変更された結果，
可変長メモリプールの待ち行列の先頭のタスクが変化する時にも，同様の処理が必要である．
pget_mpl は，get_mpl の処理をポーリングで行うサービスコール，tget_mpl
は，get_mpl にタイムアウトの機能を付け加えたサービスコールである．
tmout には，正 の値のタイ ムアウト時 間に加えて， TMO_POL（＝ 0）とTMO_FEVR（＝ –1）を指定することができる．
【補足説明】
獲得するメモリブロックのサイズは，blkszに指定されたサイズ以上であれば，それよりも大きくてもよい．またこれらのサービスコールは，獲得したメモリ
ブロックのクリアは行わないため，その内容は不定となる．
tget_mplは，tmoutに TMO_POL が指定された場合，E_CTXエラーにならな
い限りは pget_mpl と全く同じ動作をする．また，tmout に TMO_FEVR が指定された場合は，get_mpl と全く同じ動作をする．
【µITRON3.0 仕様との相違】
サービス コールの名 称を，get_blk，pget_blk， tget_blk から，それ ぞれ
get_mpl，pget_mpl， tget_mpl に変更した．blksz のデータ型を，INT からUINT に変更した．また，パラメータとリターンパラメータの順序を変更した．

235

µITRON4.0 仕様

rel_mplVer. 4.01.00

可変長メモリブロックの返却【C 言語 API】
ER ercd = rel_mpl ( ID mplid, VP blk ) ;【パラメータ】
ID

mplid

VP

blk

【リターンパラメータ】
ER
ercd【エラーコード】
E_ID
E_NOEXS
E_PAR

メモリブロック返却対象の可変長メモリプー
ルの ID 番号
返却するメモリブロックの先頭番地正常終了（E_OK）またはエラーコード

不正 ID 番号（mplidが不正あるいは使用できない）
オブジェクト未生成（対象可変長メモリプールが未登録）
パラメータエラー（blk が不正，異なるメモリプールへの返却，獲得したメモリブロックの先頭番地以外の返却）【機能】
mplid で指定される可変長メモリプールに対して，blk を先頭番地とするメモ
リブロックを返却する．
対象可変長メモリプールでメモリブロックの獲得を待っているタスクがある
場合には，メモリブロックを返却した結果，待ち行列の先頭のタスクが獲得しようとしているサイズのメモリブロックが獲得できるようになったかを調べる．獲得できる場合には，そのタスクにメモリブロックを獲得させ，そのタスクを待ち解除する．この時，待ち解除されたタスクに対しては，待ち状態に入ったサービスコールの返値として E_OK を返し，可変長メモリブロックから獲得したメモリブロックの先頭番地として獲得したメモリブロックの先頭番地を返す．さらに，メモリブロックの獲得を待っているタスクが残っている場
合には，新たに待ち行列の先頭になったタスクに対して同じ処理を繰り返す．
メモリブロックを返却する対象の可変長メモリプールは，メモリブロックの獲得を行った可変長メモリプールと同じものでなければならない．メモリブロッ
クを返却する対象の可変長メモリプールが，メモリブロックの獲得を行った可変長メモリプールと異なっている場合には，E_PAR エラーを返す．
また，返却するメモリブロックの先頭番地は，get_mpl，pget_mpl，tget_mplのいずれかのサービスコールが，獲得したメモリブロックの先頭番地として返したもので，まだ返却されていないものでなければならない．blk にそれ以外の番地が指定された場合の振舞いは未定義である．エラーを報告する場合には，E_PAR エラーを返す．
236

µITRON4.0 仕様

Ver. 4.01.00【補足説明】
このサービスコールにより，複数のタスクが待ち解除される場合，可変長メモ
リプールの待ち行列につながれていた順序で待ち解除する．そのため，実行可能状態に移行したタスクで同じ優先度を持つものの間では，待ち行列の中で前につながれていたタスクの方が高い優先順位を持つことになる．
【µITRON3.0 仕様との相違】
サービスコールの名称を，rel_blk から rel_mpl に変更した．

237

µITRON4.0 仕様

ref_mplVer. 4.01.00

可変長メモリプールの状態参照【C 言語 API】
ER ercd = ref_mpl ( ID mplid, T_RMPL *pk_rmpl ) ;【パラメータ】
ID
T_RMPL *mplid
pk_rmpl【リターンパラメータ】
ER
ercd

状態参照対象の可変長メモリプールの ID 番号
可変長メモリプール状態を返すパケットへのポインタ
正常終了（E_OK）またはエラーコード

pk_rmplの内容（ T_RMPL型）
可変長メモリプールの待ち行列の先頭のタスIDwtskidクの ID 番号
可変長メモリプールの空き領域の合計サイズ
SIZE
fmplsz（バイト数）
すぐに獲得可能な最大メモリブロックサイズ
UINTfblksz（バイト数）（実装独自に他の情報を追加してもよい）【エラーコード】
E_ID
E_NOEXS
E_PAR

不正 ID 番号（mplidが不正あるいは使用できない）
オブジェクト未生成（対象可変長メモリプールが未登録）
パラメータエラー（pk_rmpl が不正）【機能】
mplidで指定される可変長メモリプールに関する状態を参照し，pk_rmplで指定されるパケットに返す．
wtskid には，対象可変長メモリプールの待ち行列の先頭のタスクの ID 番号を返す．メモリブロックの獲得を待っているタスクがない場合には，TSK_NONE（＝ 0）を返す．
fmplsz には，対象可変長メモリプールの現在の空き領域の合計サイズ（バイト数）を返す．
fblksz には，対象可変長メモリプールからすぐに獲得できる最大のメモリブ
ロックサイズ（バイト数）を返す．すぐに獲得できる最大のメモリブロックサ
イズが，UINT 型で表せる最大値よりも大きい場合には，UINT型で表せる最大値を fblkszに返す．
【補足説明】
カーネル内部で動的なメモリ管理を用いている場合に，アプリケーションプロ
238

µITRON4.0 仕様

Ver. 4.01.00

グラムから，カーネルの管理するメモリの空き領域などを参照するための API
として，このサービスコールを流用することができる．具体的には，ID番号が（–4）の可変長メモリプールを指定してこのサービスコールを呼び出すと，カーネルの管理するメモリに関する情報を参照できることとする．ただしこの場
合，参照できる情報の内，wtskid は意味を持たない．さらに，カーネルがメ
モリを複数の単位に分けて管理している場合には，ID 番号が（–3）〜（ –2）の可変長メモリプールを同様の目的に使うことができる．
【µITRON3.0 仕様との相違】参照できる情報から拡張情報を削除した．また，待ちタスクの有無ではなく，待ち行列の先頭のタスクの ID 番号を返すこととした．これに伴って，リター
ンパラメータの名称とデータ型を変更した．
リターンパラメータの名称を，frsz から fmplsz に，maxsz から fblksz にそれぞれ変更し，fmplszのデータ型を INT から SIZE に，fblkszのデータ型を INTから UINTにそれぞれ変更した．また，パラメータとリターンパラメータの順
序を変更した．

239

µITRON4.0 仕様

Ver. 4.01.00

4.7 時間管理機能
時間管理機能は，時間に依存した処理を行うための機能である．システム時刻
管理，周期ハンドラ，アラームハンドラ，オーバランハンドラの各機能が含まれる．周期ハンドラ，アラームハンドラ，オーバランハンドラを総称して，タイムイベントハンドラと呼ぶ．
【補足説明】
タイムイベントハンドラを実行するコンテキストと状態については，次のように整理できる．
• タイムイベントハンドラは，それぞれ独立したコンテキストで実行する（3.5.1 節参照）
．タイムイベントハンドラを実行するコンテキストは，非タス
クコンテキストに分類される（3.5.2 節参照）．
• タイムイベントハンドラの優先順位は，isig_timを呼び出した割込みハンドラの優先順位以下で，ディスパッチャの優先順位よりも高い（3.5.3節参照）．
• タイムイベントハンドラの実行開始直後は，CPUロック解除状態になっている．タイムイベントハンドラからリターンする際には，CPUロック解除状態にしなければならない（3.5.4 節参照）．
• タイムイベントハンドラの起動と，そこからのリターンによって，ディスパッチ禁止／許可状態は変化しない．タイムイベントハンドラ内でディスパッチ禁止／許可状態を変化させた場合には，タイムイベントハンドラからリターンする前に元の状態に戻さなければならない（3.5.5 節を参照）．
【µITRON3.0 仕様との相違】
周期起動ハンドラに代えて，周期ハンドラという用語を用いることとした．
オーバランハンドラは新たに導入した機能である．また，自タスクの実行を遅延する機能（dly_tsk）をタスク付属同期機能に分類することにした．ret_tmr
は廃止した（3.9 節参照）．

4.7.1 システム時刻管理
システム時刻管理機能は，システム時刻を操作するための機能である．システ
ム時刻を設定／参照する機能，タイムティックを供給してシステム時刻を更新する機能が含まれる．
システム時刻は，システム初期化時に 0 に初期化し（3.7 節参照）
，以降，アプリケーションによってタイムティックを供給するサービスコール（isig_tim）
が呼び出される度に更新する．isig_timが呼び出される度にシステム時刻をどれだけ更新するか，言い換えるとアプリケーションが isig_timを呼び出すべき周期は，実装定義で定める．ただし，システム時刻を更新する機構をカーネル内部に持つことも可能で，その場合には，isig_timをサポートする必要はない．
システム時刻に依存して，タイムアウト処理，dly_tsk による時間経過待ち状

240

µITRON4.0 仕様

Ver. 4.01.00

態からの解除，周期ハンドラの起動，アラームハンドラの起動の各処理を行う．同じタイムティックで行うべき処理が複数ある場合，それらの実行順序は実装依存とする．
システム時刻管理機能に関連して，次のカーネル構成定数を定義する．
TIC_NUME
TIC_DENO

タイムティックの周期の分子
タイムティックの周期の分母

これらのカーネル構成定数は，システム時刻に依存して行われる処理のおおよ
その時間精度をアプリケーションが参照するためのもので，TIC_NUME/
TIC_DENO がタイムティックの周期を示す（時間単位はシステム時刻と同じ）．システム時刻の更新を一定周期で行わない場合，これらのカーネル構成
定数には，イベントの発生時刻の時間精度が同等になるタイムティックの周期を定義する．
システム時刻管理機能の各サービスコールの機能コードは次の通りである．
TFN_SET_TIM
TFN_GET_TIM
TFN_ISIG_TIM

–0x4d
–0x4e
–0x7d

set_tim の機能コード
get_timの機能コード
isig_tim の機能コード【スタンダードプロファイル】
スタンダードプロファイルでは，システム時刻管理機能をサポートしなければならない．ただし，システム時刻を更新する機構をカーネル内部に持つ場合には，タイムティックを供給するサービスコール（isig_tim）をサポートする必要はない．
【補足説明】
システムコンフィギュレーションファイルないしはアプリケーションが用意するヘッダファイルで TIC_NUME と TIC_DENO を定義することで，アプリ
ケーションが isig_timを呼び出す周期をカーネルに知らせる方法もある．
【µITRON3.0 仕様との相違】
システムクロックに代えて，システム時刻という用語を用いることとした．タイムティックを供給するサービスコールを新たに導入した．これは，タイマのハードウェアに依存しない形でカーネルを提供できるようにするためである．
システム時刻のビット数に関する推奨値（ µITRON3.0 仕様では，48 ビット）を定め な い こと に した．ま た，シ ス テム 時 刻 の起 点 とし て 絶 対的 な 日時（µITRON3.0 仕様では，1985 年 1月 1日 0 時（GMT））を推奨することに代えて，システム初期化時にシステム時刻を 0に初期化するものと規定した．

241

µITRON4.0 仕様

set_timVer. 4.01.00【S】

システム時刻の設定【C 言語 API】
ER ercd = set_tim ( SYSTIM *p_systim ) ;【パラメータ】
SYSTIMsystim【リターンパラメータ】
ER
ercd【エラーコード】
E_PAR

システム時刻に設定する時刻
正常終了（E_OK）またはエラーコード

パラメータエラー（p_systim， systimが不正）【機能】現在のシステム時刻を，systimで指定される時刻に設定する．
【補足説明】
このサービスコールによってシステム時刻を変更した場合にも，相対時間を用いて指定されたイベントの発生する実時刻は変化しない．言い換えると，相対時間を用いて指定されたイベントの発生するシステム時刻は変化する（2.1.9節
参照）．
【µITRON3.0 仕様との相違】
systimのデータ型を SYSTIMEから SYSTIM に変更した．また，systimを格納するパケットを廃止し，C 言語 API の引数の名称を pk_tim から p_systimに変更した．
【仕様決定の理由】
systimをポインタによって渡しているのは，SYSTIM型が構造体として定義されている時に，そのままパラメータとして渡すと効率が悪くなる場合を考慮したためである．

242

µITRON4.0 仕様

get_timVer. 4.01.00【 S】

システム時刻の参照【C 言語 API】
ER ercd = get_tim ( SYSTIM *p_systim ) ;【パラメータ】
なし【リターンパラメータ】
ER
ercd
SYSTIMsystim【エラーコード】
E_PAR

正常終了（E_OK）またはエラーコード
現在のシステム時刻

パラメータエラー（p_systim が不正）【機能】
現在のシステム時刻を呼び出し，systimに返す．
【µITRON3.0 仕様との相違】
systimのデータ型を SYSTIMEから SYSTIM に変更した．また，systimを格納するパケットを廃止し，C 言語 API の引数の名称を pk_tim から p_systimに変
更した．

243

µITRON4.0 仕様

isig_tim

Ver. 4.01.00

タイムティックの供給【S】【C 言語 API】
ER ercd = isig_tim ( ) ;【パラメータ】
なし【リターンパラメータ】
ER
ercd

正常終了（E_OK）またはエラーコード【エラーコード】
特記すべきエラーはない【機能】
システム時刻を更新する．
【スタンダードプロファイル】
システム時刻を更新する機構をカーネル内部に持つ場合には，このサービス
コールをサポートする必要はない．
【補足説明】
このサービスコールは，システム時刻に依存して行うべき処理のきっかけとなるものであり，該当する処理がこのサービスコール内で行われるとは限らない．言い換えると，このサービスコールからリターンした時点で，該当する処理が完了しているとは限らない．
【µITRON3.0 仕様との相違】
新設のサービスコールである．

244

µITRON4.0 仕様

Ver. 4.01.00

4.7.2 周期ハンドラ
周期ハンドラは，一定周期で起動されるタイムイベントハンドラである．周期
ハンドラ機能には，周期ハンドラを生成／削除する機能，周期ハンドラの動作を開始／停止する機能，周期ハンドラの状態を参照する機能が含まれる．周期
ハンドラは ID 番号で識別されるオブジェクトである．周期ハンドラの ID 番号を周期ハンドラ ID と呼ぶ．
周期ハンドラの起動周期と起動位相は，周期ハンドラの生成時に，周期ハンド
ラ毎に設定することができる．カーネルは，周期ハンドラの操作時に，設定された起動周期と起動位相から，周期ハンドラを次に起動すべき時刻を決定す
る．周期ハンドラの生成時には，周期ハンドラを生成した時刻に起動位相を加えた時刻を，次に起動すべき時刻とする．周期ハンドラを起動すべき時刻になると，その周期ハンドラの拡張情報（exinf）をパラメータとして，周期ハンドラを起動する．またこの時，周期ハンドラの起動すべき時刻に起動周期を加えた時刻を，次に起動すべき時刻とする．また，周期ハンドラの動作を開始する時に，次に起動すべき時刻を決定しなおす場合がある．
周期ハンドラの起動位相は，起動周期以下であることを原則とする．起動位相に，起動周期よりも長い時間が指定された場合の振舞いは，実装依存とする．
周期ハンドラは，動作している状態か動作していない状態かのいずれかの状態をとる．周期ハンドラが動作していない状態の時には，周期ハンドラを起動すべき時刻となっても周期ハンドラを起動せず，次に起動すべき時刻の決定のみを行う．周期ハンドラの動作を開始するサービスコール（ sta_cyc）が呼び出されると，周期ハンドラを動作している状態に移行させ，必要なら周期ハンド
ラを次に起動すべき時刻を決定しなおす．周期ハンドラの動作を停止するサー
ビスコール（stp_cyc）が呼び出されると，周期ハンドラを動作していない状態に移行させる．周期ハンドラを生成した後にどちらの状態になるかは，周期ハンドラ属性によって決めることができる．
周期ハンドラの起動位相は，周期ハンドラを生成するサービスコールが呼び出された時刻（静的 APIで生成する場合にはシステム初期化時）を基準に，周期ハンドラを最初に起動する時刻を指定する相対時間と解釈する．周期ハンドラの起動周期は，周期ハンドラを（起動した時刻ではなく）起動すべきであった
時刻を基準に，周期ハンドラを次に起動する時刻を指定する相対時間と解釈する．そのため，周期ハンドラが起動される時刻の間隔は，個々には起動周期よりも短くなる場合があるが，長い期間で平均すると起動周期に一致する．
周期ハンドラの C言語による記述形式は次の通りとする．
void cychdr ( VP_INT exinf ){周期ハンドラ本体}
周期ハンドラ生成情報および周期ハンドラ状態のパケット形式として，次のデータ型を定義する．
245

µITRON4.0 仕様

Ver. 4.01.00

typedef struct t_ccyc {ATR
cycatr ;/* 周期ハンドラ属性 */VP_INT
exinf ;/* 周期ハンドラの拡張情報 */FP
cychdr ;/* 周期ハンドラの起動番地 */RELTIM
cyctim ;/* 周期ハンドラの起動周期 */RELTIM
cycphs ;/* 周期ハンドラの起動位相 *//* 実装独自に他のフィールドを追加してもよい */} T_CCYC ;typedef struct t_rcyc {STAT
cycstat ;RELTIM
lefttim ;/* 周期ハンドラの動作状態 *//* 周期ハンドラを次に起動する時刻までの時間 *//* 実装独自に他のフィールドを追加してもよい */} T_RCYC ;周期ハンドラ機能の各サービスコールの機能コードは次の通りである．
TFN_CRE_CYC
TFN_ACRE_CYC
TFN_DEL_CYC
TFN_STA_CYC
TFN_STP_CYC
TFN_REF_CYC

–0x4f
–0xcb
–0x50
–0x51
–0x52
–0x53

cre_cyc の機能コード
acre_cyc の機能コード
del_cycの機能コード
sta_cyc の機能コード
stp_cycの機能コード
ref_cyc の機能コード【スタンダードプロファイル】
スタンダードプロファイルでは，周期ハンドラを動的に生成／削除する機能（cre_cyc，acre_cyc，del_cyc），周期ハンドラの状態を参照する機能（ref_cyc）
を除いて，周期ハンドラ機能をサポートしなければならない．
スタンダードプロファイルでは，周期ハンドラの起動位相を保存する機能（周期ハンドラ属性の TA_PHS 指定）をサポートする必要はない．
【補足説明】
起動位相を保存するとは，周期ハンドラを生成した時刻から周期ハンドラを起動すべき時刻までの時間を起動周期で割った余りが一定になるように，周期ハンドラを起動すべき時刻を決定することをいう．図 4-5 に，周期ハンドラ属性に TA_STA を指定せずに周期ハンドラを生成した後に，sta_cyc によって周期ハンドラの動作を開始した場合の，周期ハンドラの起動の様子を示す．起動位相を保存する場合には，周期ハンドラを次に起動すべき時刻は，常に周期ハンドラを生成した時刻を基準に決定する（図 4-5 (a)）．それに対して，起動位相を保存しない場合には，sta_cyc が呼び出された時刻を基準として，周期ハンドラを次に起動すべき時刻を決定する（図 4-5 (b)）．
周期ハンドラの起動は，システム時刻に依存して行われる処理である．そのため周期ハンドラの起動は，起動すべき時刻以降の最初のタイムティックで行う．周期ハンドラの起動位相は，周期ハンドラを生成するサービスコールが呼び出された時刻からの相対時間であるため，周期ハンドラの初回の起動は，周246

µITRON4.0 仕様

Ver. 4.01.00

cre_cyc （TA_STA 指定なし）

起動位相

起動周期

sta_cyc

周期ハンドラ起動

起動周期(a) 起動位相を保存する場合（TA_PHS 指定あり）
cre_cyc （TA_STA 指定なし）

起動位相

sta_cyc

起動周期

周期ハンドラ起動

起動周期(b) 起動位相を保存しない場合（TA_PHS 指定なし）
図 4-5. 起動位相の保存
期ハンドラを生成するサービスコールが呼び出されてから，指定された起動位
相以上の時間が経過した後に行うことを保証しなければならない（周期ハンドラが動作している状態の時．以下同じ）．周期ハンドラの起動周期は，周期ハンドラを起動すべき時刻からの相対時間である．すなわち，周期ハンドラの n
回目の起動は，周期ハンドラを生成するサービスコールが呼び出されてから，（起動位相＋起動周期×（n–1））以上の時間が経過した後に行うことを保証しなければならない．例えば，タイムティックの周期が 10ミリ秒のシステムにおいて，起動位相が 15ミリ秒，起動周期が 25 ミリ秒の周期ハンドラを静的 APIで生成すると，周期起動ハンドラが起動されるシステム時刻は，20ミリ秒，40ミ
リ秒，70 ミリ秒，90 ミリ秒，120 ミリ秒，…のようになる．相対時間でイベントの発生する時刻を指定する場合の扱いについては，2.1.9 節を参照すること．
この仕様上は，周期ハンドラが動作していない状態の時にも，次に起動すべき時刻の管理を行うこととしているが，同じ振舞いをするのであれば，実装上はこの管理を省略してもよい．
【µITRON3.0 仕様との相違】
周期起動ハンドラに代えて，周期ハンドラという用語を用いることとした．周期ハンドラを ID 番号で識別するオブジェクトとし，周期ハンドラの定義（def_cyc）を生成（cre_cyc），周期ハンドラ番号を周期ハンドラ ID と呼ぶことにした．また，周期ハンドラの削除を行うサービスコール（del_cyc）を新設した．
周期ハンドラの活性制御を行うサービスコール（act_cyc）の機能を，周期ハンドラの動作を開始するサービスコール（sta_cyc）と停止するサービスコー
ル（stp_cyc）に分割した．

247

µITRON4.0 仕様

CRE_CYC
cre_cycacre_cycVer. 4.01.00

周期ハンドラの生成（静的 API）

【S】

周期ハンドラの生成
周期ハンドラの生成（ID番号自動割付け）【静的 API】
CRE_CYC ( ID cycid, { ATR cycatr, VP_INT exinf, FP cychdr,
RELTIM cyctim, RELTIM cycphs } ) ;【C 言語 API】
ER ercd = cre_cyc ( ID cycid, T_CCYC *pk_ccyc ) ;ER_ID cycid = acre_cyc ( T_CCYC *pk_ccyc ) ;【パラメータ】
ID
T_CCYC *cycid
pk_ccyc

生成対象の周期ハンドラの ID 番号（ acre_cyc
以外）
周期ハンドラ生成情報を入れたパケットへのポインタ（ CRE_CYCではパケットの内容を直接記述する）

pk_ccyc の内容（T_CCYC 型）
周期ハンドラ属性
ATR
cycatr
周期ハンドラの拡張情報
VP_INT
exinf
周期ハンドラの起動番地
FP
cychdr
周期ハンドラの起動周期
RELTIM
cyctim
周期ハンドラの起動位相
RELTIM
cycphs（実装独自に他の情報を追加してもよい）【リターンパラメータ】
cre_cycの場合
ER
ercd
acre_cycの場合
ER_ID
cycid
【エラーコード】
E_ID
E_NOID
E_RSATR
E_PAR
E_OBJ

正常終了（E_OK）またはエラーコード生成した周期ハンドラの ID 番号（正の値）またはエラーコード

不正 ID 番号（cycid が不正あるいは使用できない；
cre_cyc のみ）
ID 番号不足（割付け可能な周期ハンドラ ID がない；
acre_cyc のみ）
予約属性（cycatr が不正あるいは使用できない）
パラメータエラー（pk_ccyc，cychdr，cyctim，cycphs
が不正）オブジェクト状態エラー（対象周期ハンドラが登録済
248

µITRON4.0 仕様

Ver. 4.01.00
み；cre_cyc のみ）【機能】
cycid で指定される ID 番号を持つ周期ハンドラを，pk_ccycで指定される周期
ハンドラ生成情報に基づいて生成する．cycatr は周期ハンドラの属性，exinf
は周期ハンドラを起動する時にパラメータとして渡す拡張情報，cychdr は周期ハンドラの起動番地，cyctimは周期ハンドラを起動する周期，cycphsは周期ハンドラを起動する位相である．
CRE_CYC においては，cycid は自動割付け対応整数値パラメータ，cycatr は
プリプロセッサ定数式パラメータである．
acre_cycは，生成する周期ハンドラのID番号を周期ハンドラが登録されていな
い ID 番号の中から割り付け，割り付けた ID 番号を返値として返す．
cycatr には，（（TA_HLNG ‖ TA_ASM）｜［TA_STA］｜［TA_PHS］）の指定ができる．TA_HLNG（＝ 0x00）が指定された場合には高級言語用のインタ
フェースで，TA_ASM（＝ 0x01）が指定された場合にはアセンブリ言語用のイ
ンタフェースで周期ハンドラを起動する．TA_STA（＝ 0x02）が指定された場
合には，周期ハンドラを生成した後に，周期ハンドラを動作している状態とす
る．そうでない場合には，周期ハンドラを動作していない状態とする．TA_PHS（＝ 0x04）が指定された場合には，周期ハンドラの動作を開始する時に，周期ハンドラの起動位相を保存して，次に起動すべき時刻を決定する．周期ハンドラの動作を開始する時の振舞いに関しては，sta_cyc の機能説明を参照すること．
周期ハンドラを最初に起動すべき時刻は，これらのサービスコールが呼び出された時刻（静的 APIの場合にはシステム初期化の時刻）に，指定された起動位相を加えた時刻とする．
cyctimに 0 が指定された場合には，E_PAR エラーを返す．cycphs に cyctimよりも大きい値が指定された場合の振舞いは実装依存である．エラーを報告する
場合には，E_PAR エラーを返す．
【スタンダードプロファイル】
スタンダードプロファイルでは，cycatrに TA_PHSが指定された場合の機能と
TA_ASM が指定された場合の機能はサポートする必要がない．
【補足説明】
cycatr に TA_STAと TA_PHSのいずれも指定されない場合には，周期ハンドラの起動位相（cycphs）は意味を持たない．
【µITRON3.0 仕様との相違】
周期ハンドラの定義（def_cyc）に代えて，生成（cre_cyc）と呼ぶことにした．周期ハンドラの起動位相を指定する機能を追加し，周期ハンドラ生成情報に周期ハンドラの起動位相（cycphs）を追加した．周期ハンドラを生成した
後の動作状態を指定する方法を変更した．

249

µITRON4.0 仕様

Ver. 4.01.00

周期ハンドラ生成情報を入れたパケット中での cycatr と exinfの順序を交換した．
また，
exinfのデータ型をVPから VP_INTに，
cyctimのデータ型を CYCTIMEから RELTIMに変更した．
acre_cyc は新設のサービスコールである．

250

µITRON4.0 仕様

del_cycVer. 4.01.00

周期ハンドラの削除【C 言語 API】
ER ercd = del_cyc ( ID cycid ) ;【パラメータ】
ID

cycid【リターンパラメータ】
ER
ercd【エラーコード】
E_ID
E_NOEXS

削除対象の周期ハンドラの ID番号
正常終了（E_OK）またはエラーコード

不正 ID 番号（cycidが不正あるいは使用できない）
オブジェクト未生成（対象周期ハンドラが未登録）【機能】
cycid で指定される周期ハンドラを削除する．
【µITRON3.0 仕様との相違】
新設のサービスコールである．µITRON3.0 仕様では，周期ハンドラを定義する
サービスコール（def_cyc）が，周期ハンドラの登録を解除する機能を持って
いる．

251

µITRON4.0 仕様

sta_cycVer. 4.01.00

周期ハンドラの動作開始【S】【C 言語 API】
ER ercd = sta_cyc ( ID cycid ) ;【パラメータ】
ID

cycid

動作開始対象の周期ハンドラの ID 番号【リターンパラメータ】
ER
ercd

正常終了（E_OK）またはエラーコード【エラーコード】
E_ID
E_NOEXS

不正 ID 番号（cycid が不正あるいは使用できない）
オブジェクト未生成（対象周期ハンドラが未登録）【機能】
cycid で指定される周期ハンドラを，動作している状態に移行させる．
周期ハンドラ属性に TA_PHS（＝ 0x04）が指定されていない場合には，このサービスコールが呼び出された時刻に，周期ハンドラの起動周期を加えた時刻を，周期ハンドラを次に起動すべき時刻とする．
対象周期ハンドラに，周期ハンドラ属性に TA_PHSが指定されていない動作している状態の周期ハンドラが指定された場合には，周期ハンドラを次に起動すべき時刻の再設定のみを行う．対象周期ハンドラに，TA_PHSが指定されている動作している状態の周期ハンドラが指定された場合には，何もしない．
【µITRON3.0 仕様との相違】
周期ハンドラの活性制御を行うサービスコール（act_cyc）の機能を，周期ハンドラの動作を開始するサービスコール（sta_cyc）と停止するサービスコー
ル（stp_cyc）に分割した．µITRON3.0 仕様の act_cyc でカウントを初期化する指定（ TCY_INI）は，周期ハンドラ属性で TA_PHSを指定しない場合に対応
する．

252

µITRON4.0 仕様

stp_cycVer. 4.01.00

周期ハンドラの動作停止【 S】【C 言語 API】
ER ercd = stp_cyc ( ID cycid ) ;【パラメータ】
ID

cycid

動作停止対象の周期ハンドラの ID番号

【リターンパラメータ】
ER
ercd

正常終了（E_OK）またはエラーコード【エラーコード】
E_ID
E_NOEXS

不正 ID 番号（cycidが不正あるいは使用できない）
オブジェクト未生成（対象周期ハンドラが未登録）【機能】
cycid で指定される周期ハンドラを動作していない状態に移行させる．対象周期ハンドラに，動作していない状態の周期ハンドラが指定された場合には，何もしない．
【µITRON3.0 仕様との相違】
周期ハンドラの活性制御を行うサービスコール（act_cyc）の機能を，周期ハンドラの動作を開始するサービスコール（sta_cyc）と停止するサービスコー
ル（stp_cyc）に分割した．

253

µITRON4.0 仕様

ref_cycVer. 4.01.00

周期ハンドラの状態参照【C 言語 API】
ER ercd = ref_cyc ( ID cycid, T_RCYC *pk_rcyc ) ;【パラメータ】
ID
T_RCYC *cycid
pk_rcyc【リターンパラメータ】
ER
ercd

状態参照対象の周期ハンドラの ID 番号
周期ハンドラ状態を返すパケットへのポイン
タ
正常終了（E_OK）またはエラーコード

pk_rcyc の内容（T_RCYC 型）
周期ハンドラの動作状態
STAT
cycstat
周期ハンドラを次に起動する時刻までの時間
RELTIM
lefttim（実装独自に他の情報を追加してもよい）【エラーコード】
E_ID
E_NOEXS
E_PAR

不正 ID 番号（cycid が不正あるいは使用できない）
オブジェクト未生成（対象周期ハンドラが未登録）
パラメータエラー（pk_rcycが不正）【機能】
cycid で指定される周期ハンドラに関する状態を参照し，pk_rcyc で指定されるパケットに返す．
cycstat には，対象周期ハンドラが動作している状態か動作していない状態かによって，次のいずれかの値を返す．
TCYC_STP
TCYC_STA

0x00
0x01

周期ハンドラが動作していない
周期ハンドラが動作している

lefttimには，対象周期ハンドラが動作している状態の場合に，対象周期ハンド
ラを次に起動する時刻までの相対時間を返す．具体的には，対象周期ハンドラ
を次に起動する時刻から現在時刻を減じた値を返す．ただし，lefttim に返す
値は，対象周期ハンドラが起動されるまでの時間以下でなければならない．そのため，次のタイムティックで周期ハンドラが起動される場合には，lefttimに0 を返す．対象周期ハンドラが動作していない状態の場合に lefttimに返す値は実装依存である．
【µITRON3.0 仕様との相違】参照できる情報から拡張情報を削除した．周期ハンドラの動作状態を参照する
方法を変更した．lefttim のデータ型を CYCTIME から RELTIM に変更した．また，パラメータとリターンパラメータの順序を変更した．

254

µITRON4.0 仕様

Ver. 4.01.00

4.7.3 アラームハンドラ
アラームハンドラは，指定した時刻に起動されるタイムイベントハンドラである．アラームハンドラ機能には，アラームハンドラを生成／削除する機能，ア
ラームハンドラの動作を開始／停止する機能，アラームハンドラの状態を参照
する機能が含まれる．アラームハンドラは ID 番号で識別されるオブジェクトである．アラームハンドラの ID 番号をアラームハンドラ ID と呼ぶ．
アラームハンドラを起動する時刻（これをアラームハンドラの起動時刻と呼ぶ）は，アラームハンドラ毎に設定することができる．アラームハンドラの起動時刻になると，そのアラームハンドラの拡張情報（exinf）をパラメータとして，アラームハンドラを起動する．
アラームハンドラの生成直後には，アラームハンドラの起動時刻は設定されておらず，アラームハンドラの動作は停止している．アラームハンドラの動作を開始するサービスコール（ sta_alm）が呼び出されると，アラームハンドラの起動時刻を，サービスコールが呼び出された時刻から指定された相対時間後に設定する．アラームハンドラの動作を停止するサービスコール（stp_alm）が呼び出されると，アラームハンドラの起動時刻の設定を解除する．また，アラームハンドラを起動する時にも，アラームハンドラの起動時刻の設定を解除
し，アラームハンドラの動作を停止する．
アラームハンドラの C言語による記述形式は次の通りとする．
void almhdr ( VP_INT exinf ){アラームハンドラ本体}
アラームハンドラ生成情報およびアラームハンドラ状態のパケット形式として，次のデータ型を定義する．
typedef struct t_calm {ATR
almatr ;/* アラームハンドラ属性 */VP_INT
exinf ;/* アラームハンドラの拡張情報 */FP
almhdr ; /* アラームハンドラの起動番地 *//* 実装独自に他のフィールドを追加してもよい */} T_CALM ;typedef struct t_ralm {STAT
almstat ;RELTIM
lefttim ;/* アラームハンドラの動作状態 *//* アラームハンドラの起動時刻までの時間 *//* 実装独自に他のフィールドを追加してもよい */} T_RALM ;アラームハンドラ機能の各サービスコールの機能コードは次の通りである．
TFN_CRE_ALM
TFN_ACRE_ALM
TFN_DEL_ALM

–0xa9
–0xcc
–0xaa

cre_almの機能コード
acre_almの機能コード
del_almの機能コード
255

µITRON4.0 仕様
TFN_STA_ALM
TFN_STP_ALM
TFN_REF_ALM

Ver. 4.01.00
–0xab
–0xac
–0xad

sta_alm の機能コード
stp_almの機能コード
ref_almの機能コード【スタンダードプロファイル】
スタンダードプロファイルでは，アラームハンドラ機能はサポートする必要がない．
【補足説明】
アラームハンドラの起動は，システム時刻に依存して行われる処理である．そのため，アラームハンドラの起動は，起動時刻以降の最初のタイムティックで行う．また，アラームハンドラの起動は，アラームハンドラの動作を開始する
サービスコールが呼び出されてから，指定された以上の時間が経過した後に行うことを保証しなければならない（2.1.9 節参照）．
アラームハンドラの起動時刻の設定解除は，アラームハンドラを起動する時（すなわちアラームハンドラの実行前）に行われる．そのため，非タスクコン
テキストからアラームハンドラの動作を開始するサービスコールを実装独自に呼出し可能とした場合には，起動されたアラームハンドラ内で，それ自身の起動時刻を再設定して，アラームハンドラの動作を開始することができる．
【µITRON3.0 仕様との相違】
アラームハンドラを ID 番号で識別するオブジェクトとし，アラームハンドラの定義（ def_alm）を生成（cre_alm），アラームハンドラ番号をアラームハン
ドラ ID と呼ぶことにした．また，アラームハンドラの削除を行うサービスコー
ル（del_alm）を新設した．
アラームハンドラを静的に生成する場合を考慮し，アラームハンドラの起動時
刻の設定をアラームハンドラの登録時に行わず，新設のアラームハンドラの動作を開始するサービスコール（sta_alm）で設定することとした．また，アラームハンドラの動作を停止するサービスコール（stp_alm）を新設した．
アラームハンドラの起動時刻を絶対時刻で指定する機能は廃止した．

256

µITRON4.0 仕様

CRE_ALM
cre_alm
acre_alm

Ver. 4.01.00

アラームハンドラの生成（静的 API）
アラームハンドラの生成
アラームハンドラの生成（ ID番号自動割付け）【静的 API】
CRE_ALM ( ID almid, { ATR almatr, VP_INT exinf, FP almhdr } ) ;【C 言語 API】
ER ercd = cre_alm ( ID almid, T_CALM *pk_calm ) ;ER_ID almid = acre_alm ( T_CALM *pk_calm ) ;【パラメータ】
ID
T_CALM *almid

ID
生成対象のアラームハンドラの番号（acre_alm 以外）
pk_calm アラームハンドラ生成情報を入れたパケット
へのポインタ（CRE_ALMではパケットの内容を直接記述する）

pk_calm の内容（T_CALM 型）
ATR
almatr
アラームハンドラ属性
VP_INT
exinf
アラームハンドラの拡張情報
FP
almhdr
アラームハンドラの起動番地（実装独自に他の情報を追加してもよい）【リターンパラメータ】
cre_almの場合
ER
ercd
acre_almの場合
ER_ID
almid
【エラーコード】
E_ID
E_NOID
E_RSATR
E_PAR
E_OBJ

正常終了（E_OK）またはエラーコード
生成したアラームハンドラの ID番号（正の値）またはエラーコード

不正 ID 番号（almid が不正あるいは使用できない；
cre_alm のみ）
ID 番号不足（割付け可能なアラームハンドラ ID がない；
acre_alm のみ）
予約属性（almatr が不正あるいは使用できない）
パラメータエラー（pk_calm，almhdrが不正）
オブジェクト状態エラー（対象アラームハンドラが登録済み；cre_alm のみ）【機能】
almid で指定される ID番号を持つアラームハンドラを，pk_calmで指定される
257

µITRON4.0 仕様

Ver. 4.01.00

アラームハンドラ生成情報に基づいて生成する．almatr はアラームハンドラの属性，exinf はアラームハンドラを起動する時にパラメータとして渡す拡張情報，almhdrはアラームハンドラの起動番地である．
CRE_ALMにおいては，almid は自動割付け対応整数値パラメータ，almatrはプリプロセッサ定数式パラメータである．
acre_almは，生成するアラームハンドラの ID番号をアラームハンドラが登録されていない ID 番号の中から割り付け，割り付けた ID番号を返値として返す．
アラームハンドラの生成直後には，アラームハンドラの起動時刻は設定されておらず，アラームハンドラの動作は停止している．
（TA_HLNG‖ TA_ASM）の指定ができる．TA_HLNG（＝ 0x00）
almatrには，が指定された場合には高級言語用のインタフェースで，TA_ASM（＝ 0x01）が指定された場合にはアセンブリ言語用のインタフェースでアラームハンドラを起動する．
【µITRON3.0 仕様との相違】
アラームハンドラの定義（ def_alm）に代えて，生成（cre_alm）と呼ぶことにした．アラームハンドラを静的に生成する場合を考慮し，アラームハンドラの起動時刻の設定をアラームハンドラの登録時には行わないこととした．
アラームハンドラ生成情報を入れたパケット中でのalmatrと exinfの順序を交換した．また，exinfのデータ型を，VPから VP_INT に変更した．
acre_almは新設のサービスコールである．

258

µITRON4.0 仕様

del_alm

Ver. 4.01.00

アラームハンドラの削除【C 言語 API】
ER ercd = del_alm ( ID almid ) ;【パラメータ】
IDalmid

削除対象のアラームハンドラの ID番号

【リターンパラメータ】
ER
ercd

正常終了（E_OK）またはエラーコード【エラーコード】
E_ID
E_NOEXS

不正 ID 番号（almid が不正あるいは使用できない）
オブジェクト未生成（対象アラームハンドラが未登録）【機能】
almid で指定されるアラームハンドラを削除する．
【補足説明】
対象アラームハンドラが動作している場合には，対象アラームハンドラの起動時刻の設定を解除し，アラームハンドラの動作を停止する．
【µITRON3.0 仕様との相違】
新設のサービスコールである．µITRON3.0 仕様では，アラームハンドラを定義するサービスコール（def_alm）が，アラームハンドラの登録を解除する機能を持っている．

259

µITRON4.0 仕様

sta_alm

Ver. 4.01.00

アラームハンドラの動作開始【C 言語 API】
ER ercd = sta_alm ( ID almid, RELTIM almtim ) ;【パラメータ】
ID
RELTIMalmid
almtim【リターンパラメータ】
ER
ercd【エラーコード】
E_ID
E_NOEXS
E_PAR

動作開始対象のアラームハンドラの ID 番号
アラームハンドラの起動時刻（相対時間）
正常終了（E_OK）またはエラーコード

不正 ID 番号（almid が不正あるいは使用できない）
オブジェクト未生成（対象アラームハンドラが未登録）
パラメータエラー（almtimが不正）【機能】
almid で指定されるアラームハンドラの起動時刻を，サービスコールが呼び出された時刻から almtim で指定された相対時間後に設定し，アラームハンドラの動作を開始する．
対象アラームハンドラに，すでに動作しているアラームハンドラが指定された場合には，以前の起動時刻の設定を解除し，新しい起動時刻を設定する．
almtim は，サービスコールが呼び出された時刻を基準に，アラームハンドラの起動時刻を指定する相対時間と解釈する．
【µITRON3.0 仕様との相違】
新設のサービスコールである．µITRON3.0 仕様では，アラームハンドラを定義するサービスコール（def_alm）が，アラームハンドラの起動時刻を設定する機能を持っている．

260

µITRON4.0 仕様

stp_alm

Ver. 4.01.00

アラームハンドラの動作停止【C 言語 API】
ER ercd = stp_alm ( ID almid ) ;【パラメータ】
ID

almid【リターンパラメータ】
ER
ercd【エラーコード】
E_ID
E_NOEXS

動作停止対象のアラームハンドラの ID番号
正常終了（E_OK）またはエラーコード

不正 ID 番号（almid が不正あるいは使用できない）
オブジェクト未生成（対象アラームハンドラが未登録）【機能】
almid で指定されるアラームハンドラの起動時刻の設定を解除し，アラームハ
ンドラの動作を停止する．対象アラームハンドラに，動作していないアラーム
ハンドラが指定された場合には，何もしない．
【µITRON3.0 仕様との相違】
新設のサービスコールである．µITRON3.0 仕様では，アラームハンドラの登録を解除する以外の方法で，アラームハンドラの動作を停止することはできな
い．

261

µITRON4.0 仕様

ref_alm

Ver. 4.01.00

アラームハンドラの状態参照【C 言語 API】
ER ercd = ref_alm ( ID almid, T_RALM *pk_ralm ) ;【パラメータ】
ID
T_RALM *almid
pk_ralm【リターンパラメータ】
ER
ercd

状態参照対象のアラームハンドラの ID 番号
アラームハンドラ状態を返すパケットへのポインタ
正常終了（E_OK）またはエラーコード

pk_ralm の内容（T_RALM型）
アラームハンドラの動作状態
STAT
almstatアラームハンドラの起動時刻までの時間
RELTIM
lefttim（実装独自に他の情報を追加してもよい）【エラーコード】
E_ID
E_NOEXS
E_PAR

不正 ID 番号（almid が不正あるいは使用できない）
オブジェクト未生成（対象アラームハンドラが未登録）
パラメータエラー（pk_ralm が不正）【機能】
almid で指定されるアラームハンドラに関する状態を参照し，pk_ralmで指定されるパケットに返す．
almstat には，対象アラームハンドラが動作しているかどうか（言い換えると，
対象アラームハンドラに起動時刻が設定されているかどうか）によって，次のいずれかの値を返す．
TALM_STPTALM_STA

0x00
0x01

アラームハンドラが動作していない
アラームハンドラが動作している

lefttimには，対象アラームハンドラが動作している場合に，対象アラームハン
ドラの起動時刻までの相対時間を返す．具体的には，対象アラームハンドラの起動時刻から現在時刻を減じた値を返す．ただし，lefttim に返す値は，対象
アラームハンドラが起動されるまでの時間以下でなければならない．そのため，次のタイムティックでアラームハンドラが起動される場合には，lefttimに0 を返す．対象アラームハンドラが動作していない場合に lefttimに返す値は実装依存である．
【µITRON3.0 仕様との相違】参照できる情報に，アラームハンドラの動作状態（almstat）を追加し，拡張情報を削除した．lefttimのデータ型を ALMTIMEから RELTIMに変更した．また，パラメータとリターンパラメータの順序を変更した．
262

µITRON4.0 仕様

Ver. 4.01.00

4.7.4 オーバランハンドラ
オーバランハンドラは，タスクが設定された時間を越えてプロセッサを使用した場合に起動されるタイムイベントハンドラである．オーバランハンドラ機能には，オーバランハンドラを定義する機能，オーバランハンドラの動作を開始／停止する機能，オーバランハンドラの状態を参照する機能が含まれる．
オーバランハンドラの起動条件として設定される時間（これをタスクの上限プ
ロセッサ時間と呼ぶ）は，タスク毎に設定することができる．カーネルは，上限プロセッサ時間が設定されたタスクに対して，上限プロセッサ時間が設定されて以降にそのタスクが使用した累積プロセッサ時間（これをタスクの使用プ
ロセッサ時間と呼ぶ）を管理し，タスクの使用プロセッサ時間が上限プロセッ
サ時間を越えると，オーバランハンドラを起動する．システムに定義できる
オーバランハンドラは 1つだけであるため，オーバランハンドラには，起動の原因となったタスクの ID 番号（tskid）と拡張情報（exinf）をパラメータとして渡す．
タスクの生成直後には，タスクの上限プロセッサ時間は設定されていない．
オーバランハンドラの動作を開始するサービスコール（sta_ovr）が呼び出されると，指定されたタスクに対して指定された上限プロセッサ時間を設定し，使用プロセッサ時間を 0にクリアする．オーバランハンドラの動作を停止する
サービスコール（stp_ovr）が呼び出されると，指定されたタスクの上限プロ
セッサ時間の設定を解除する．タスクの上限プロセッサ時間の設定は，そのタスクが原因となってオーバランハンドラを起動する時や，そのタスクが終了する時にも解除する．
タスクが使用したプロセッサ時間には，少なくとも，そのタスク（タスク例外
処理ルーチンを含む）とそのタスクから呼び出したサービスコールの実行時間が含まれる．逆に，他のタスク（タスク例外処理ルーチンを含む）と他のタスクから呼び出したサービスコールの実行時間は含まれない．タスクディスパッ
チにかかる時間やタスクの実行中に起動された割込みハンドラの実行時間など，その他の処理の実行時間が含まれるかどうかは実装依存とする．また，使用したプロセッサ時間の計測精度も実装依存である．ただし，オーバランハン
ドラが起動されるのは，タスクの使用プロセッサ時間が，設定した上限プロ
セッサ時間を越えた場合に限る．
オーバランハンドラ機能では，次のデータ型を用いる．
OVRTIM

プロセッサ時間（符号無し整数，時間単位は実装定義）

オーバランハンドラの C言語による記述形式は次の通りとする．
void ovrhdr ( ID tskid, VP_INT exinf ){オーバランハンドラ本体}
オーバランハンドラ生成情報およびオーバランハンドラ状態のパケット形式
として，次のデータ型を定義する．
263

µITRON4.0 仕様

Ver. 4.01.00

typedef struct t_dovr {ATR
ovratr ;/* オーバランハンドラ属性 */FP
ovrhdr ;/* オーバランハンドラの起動番地 *//* 実装独自に他のフィールドを追加してもよい */} T_DOVR ;typedef struct t_rovr {STAT
ovrstat ;/* オーバランハンドラの動作状態 */OVRTIM leftotm ;/* 残りのプロセッサ時間 *//* 実装独自に他のフィールドを追加してもよい */} T_ROVR ;オーバランハンドラ機能の各サービスコールの機能コードは次の通りである．
TFN_DEF_OVR
TFN_STA_OVR
TFN_STP_OVR
TFN_REF_OVR

–0xb1
–0xb2
–0xb3
–0xb4

def_ovr の機能コード
sta_ovrの機能コード
stp_ovr の機能コード
ref_ovr の機能コード【スタンダードプロファイル】
スタンダードプロファイルでは，オーバランハンドラ機能はサポートする必要がない．
【補足説明】
オーバランハンドラの起動は，システム時刻に依存して行われる処理ではな
い．そのため，オーバランハンドラは，タイムティックに同期して起動されるとは限らない（タイムティックに同期してオーバランハンドラを起動する実装も禁止されてはいない）．
タスクの上限プロセッサ時間の設定解除は，オーバランハンドラを起動する時（すなわちオーバランハンドラの実行前）に行われる．そのため，非タスクコ
ンテキストからオーバランハンドラの動作を開始するサービスコールを実装
独自に呼出し可能とした場合には，オーバランハンドラ起動の原因となったタスクに対して，オーバランハンドラ内で上限プロセッサ時間を再設定することができる．
タスクの使用プロセッサ時間が上限プロセッサ時間を越えた場合の処理を，そのタスクのコンテキストで処理させたい場合には，オーバランハンドラからタスク例外処理を要求し，タスク例外処理ルーチンで必要な処理を行う方法で実現することができる．
【µITRON3.0 仕様との相違】
オーバランハンドラ機能は，µITRON4.0 仕様において新たに導入した機能である．

264

µITRON4.0 仕様

DEF_OVR
def_ovr

Ver. 4.01.00

オーバランハンドラの定義（静的 API）
オーバランハンドラの定義【静的 API】
DEF_OVR ( { ATR ovratr, FP ovrhdr } ) ;【C 言語 API】
ER ercd = def_ovr ( T_DOVR *pk_dovr ) ;【パラメータ】
T_DOVR * pk_dovr

オーバランハンドラ定義情報を入れたパケッ
トへのポインタ（DEF_OVRではパケットの内容を直接記述する）

pk_dovrの内容（T_DOVR型）
ATR
ovratrオーバランハンドラ属性
FP
ovrhdrオーバランハンドラの起動番地（実装独自に他の情報を追加してもよい）【リターンパラメータ】
ER
ercd【エラーコード】
E_RSATR
E_PAR

正常終了（E_OK）またはエラーコード

予約属性（ovratrが不正あるいは使用できない）
パラメータエラー（pk_dovr， ovrhdrが不正）【機能】
pk_dovr で指定されるオーバランハンドラ定義情報に基づいて，オーバランハ
ンドラを定義する．ovratr はオーバランハンドラの属性，ovrhdr はオーバラ
ンハンドラの起動番地である．
DEF_OVR においては，ovratr はプリプロセッサ定数式パラメータである．
pk_dovr に NULL（＝ 0）が指定されると，すでに定義されているオーバランハ
ンドラの定義を解除し，オーバランハンドラが定義されていない状態にする．
この時，すべてのタスクの上限プロセッサ時間の設定を解除する．また，すでにオーバランハンドラが定義されている状態で，再度オーバランハンドラが定義された場合には，以前の定義を解除し，新しい定義に置き換える．この時は，タスクの上限プロセッサ時間の設定解除は行わない．
ovratr には，（TA_HLNG ‖ TA_ASM）の指定ができる．TA_HLNG（＝ 0x00）が指定された場合には高級言語用のインタフェースで，TA_ASM（＝ 0x01）が指定された場合にはアセンブリ言語用のインタフェースでオーバランハンド
ラを起動する．
【仕様決定の理由】
オーバランハンドラの定義を解除する時に，タスクの上限プロセッサ時間の設
265

µITRON4.0 仕様

Ver. 4.01.00

定を解除するのは，オーバランハンドラが定義されていない時には，タスクの上限プロセッサ時間が設定されていない状態を保つためである（オーバランハ
ンドラが定義されていない時には，タスクに対して上限プロセッサ時間を設定することができないため，この状態が保たれる）．

266

µITRON4.0 仕様

sta_ovr

Ver. 4.01.00

オーバランハンドラの動作開始【C 言語 API】
ER ercd = sta_ovr ( ID tskid, OVRTIM ovrtim ) ;【パラメータ】ID
OVRTIMtskid
ovrtim【リターンパラメータ】
ER
ercd【エラーコード】
E_ID
E_NOEXS
E_PAR
E_OBJ

動作開始対象のタスクの ID番号
設定するタスクの上限プロセッサ時間
正常終了（E_OK）またはエラーコード

不正 ID 番号（tskidが不正あるいは使用できない）
オブジェクト未生成（対象タスクが未登録）
パラメータエラー（ovrtim が不正）オブジェクト状態エラー（オーバランハンドラが定義されていない）【機能】
tskidで指定されるタスクに対して，オーバランハンドラの動作を開始する．具
体的には，対象タスクの上限プロセッサ時間を，ovrtim で指定される時間に設定する．また，対象タスクの使用プロセッサ時間を 0にクリアする．
対象タスクに，すでに上限プロセッサ時間が設定されているタスクが指定された場合には，以前の上限プロセッサ時間の設定を解除し，新しい上限プロセッ
サ時間を設定する．この時にも，使用プロセッサ時間を 0にクリアする．
tskidに TSK_SELF（＝ 0）が指定されると，自タスクを対象タスクとする．

267

µITRON4.0 仕様

stp_ovr

Ver. 4.01.00

オーバランハンドラの動作停止【C 言語 API】
ER ercd = stp_ovr ( ID tskid ) ;【パラメータ】
IDtskid【リターンパラメータ】
ER
ercd【エラーコード】
E_ID
E_NOEXS
E_OBJ

動作停止対象のタスクの ID 番号
正常終了（E_OK）またはエラーコード

不正 ID 番号（tskidが不正あるいは使用できない）
オブジェクト未生成（対象タスクが未登録）
オブジェクト状態エラー（オーバランハンドラが定義されていない）【機能】
tskidで指定されるタスクに対して，オーバランハンドラの動作を停止する．具
体的には，対象タスクの上限プロセッサ時間の設定を解除する．対象タスクに，上限プロセッサ時間が設定されていないタスクが指定された場合には，何もしない．
tskidに TSK_SELF（＝ 0）が指定されると，自タスクを対象タスクとする．

268

µITRON4.0 仕様

ref_ovr

Ver. 4.01.00

オーバランハンドラの状態参照【C 言語 API】
ER ercd = ref_ovr ( ID tskid, T_ROVR *pk_rovr ) ;【パラメータ】
ID
T_ROVR *tskid
pk_rovr【リターンパラメータ】
ER
ercd

状態参照対象のタスクの ID番号
オーバランハンドラ状態を返すパケットへのポインタ
正常終了（E_OK）またはエラーコード

pk_rovrの内容（T_ROVR型）
オーバランハンドラの動作状態
STAT
ovrstat
残りのプロセッサ時間
OVRTIM
leftotm（実装独自に他の情報を追加してもよい）【エラーコード】
E_ID
E_NOEXS
E_PAR
E_OBJ

不正 ID 番号（tskidが不正あるいは使用できない）
オブジェクト未生成（対象タスクが未登録）
パラメータエラー（pk_rovrが不正）
オブジェクト状態エラー（オーバランハンドラが定義されていない）【機能】
tskid で指定されるタスクの，オーバランハンドラに関する状態を参照し，
pk_rovrで指定されるパケットに返す．
ovrstat には，対象タスクに対してオーバランハンドラが動作しているかどうかを返す．具体的には，対象タスクに上限プロセッサ時間が設定されているかどうかによって，次のいずれかの値を返す．
TOVR_STPTOVR_STA

0x00
0x01

上限プロセッサ時間が設定されていない
上限プロセッサ時間が設定されている

leftotm には，対象タスクに対して上限プロセッサ時間が設定されている場合に，対象タスクを原因としてオーバランハンドラが起動されるまでの残りプロ
セッサ時間を返す．具体的には，対象タスクの上限プロセッサ時間から使用プ
ロセッサ時間を減じた値を返す．ただし，leftotm に返す値は，対象タスクを原因としてオーバランハンドラが起動されるまでに対象タスクが使用できるプロセッサ時間以下でなければならない．そのため，オーバランハンドラが起動される直前には，leftotm には 0が返される可能性がある．対象タスクに対して上限プロセッサ時間が設定されていない場合に leftotm に返す値は実装依存
である．

269

µITRON4.0 仕様

Ver. 4.01.00

tskidに TSK_SELF（＝ 0）が指定されると，自タスクを対象タスクとする．

270

µITRON4.0 仕様

Ver. 4.01.00

4.8 システム状態管理機能
システム状態管理機能は，システムの状態を変更／参照するための機能である．タスクの優先順位を回転する機能，実行状態のタスク IDを参照する機能，
CPUロック状態へ移行／解除する機能，タスクディスパッチを禁止／解除する
機能，コンテキストやシステム状態を参照する機能が含まれる．
システム状態のパケット形式として，次のデータ型を定義する．
typedef struct t_rsys {/* 実装独自のフィールドが入る */} T_RSYS ;システム状態管理機能の各サービスコールの機能コードは次の通りである．
TFN_ROT_RDQ
TFN_IROT_RDQ
TFN_GET_TID
TFN_IGET_TID
TFN_LOC_CPU
TFN_ILOC_CPU
TFN_UNL_CPU
TFN_IUNL_CPU
TFN_DIS_DSP
TFN_ENA_DSP
TFN_SNS_CTX
TFN_SNS_LOC
TFN_SNS_DSP
TFN_SNS_DPN
TFN_REF_SYS

–0x55
–0x79
–0x56
–0x7a
–0x59
–0x7b
–0x5a
–0x7c
–0x5b
–0x5c
–0x5d
–0x5e
–0x5f
–0x60
–0x61

rot_rdq の機能コード
irot_rdqの機能コード
get_tidの機能コード
iget_tid の機能コード
loc_cpu の機能コード
iloc_cpuの機能コード
unl_cpu の機能コード
iunl_cpuの機能コード
dis_dsp の機能コード
ena_dsp の機能コード
sns_ctxの機能コード
sns_locの機能コード
sns_dsp の機能コード
sns_dpn の機能コード
ref_sys の機能コード【スタンダードプロファイル】
スタンダードプロファイルでは，システムの状態を参照する機能（ref_sys）を除いて，システム状態管理機能をサポートしなければならない．
【µITRON3.0 仕様との相違】
システム状態管理機能という分類を，新たに設けることにした．

271

µITRON4.0 仕様

rot_rdq
irot_rdq

Ver. 4.01.00

タスクの優先順位の回転

【S】
【S】

【C 言語 API】
ER ercd = rot_rdq ( PRI tskpri ) ;ER ercd = irot_rdq ( PRI tskpri ) ;【パラメータ】
PRI

tskpri【リターンパラメータ】
ER
ercd【エラーコード】
E_PAR

優先順位を回転する対象の優先度
正常終了（E_OK）またはエラーコード

パラメータエラー（tskpriが不正）【機能】
tskpriで指定される優先度のタスクの優先順位を回転する．すなわち，対象優先度を持った実行できる状態のタスクの中で，最も高い優先順位を持つタスクを，同じ優先度を持つタスクの中で最低の優先順位とする．
tskpriに TPRI_SELF（＝ 0）が指定されると，自タスクのベース優先度を対象優先度とする．ただし，非タスクコンテキストからの呼出しでこの指定が行われた場合には，E_PAR エラーを返す．
【補足説明】
このサービスコールを周期的に呼び出すことにより，ラウンドロビン方式を実現することができる．対象優先度を持った実行できる状態のタスクがない場合
や，一つしかない場合には，何もしない（エラーとはしない）．
ディスパッチ許可状態で，対象優先度に自タスクの現在優先度を指定してこのサービスコールが呼び出されると，自タスクの実行順位は同じ優先度を持つタ
スクの中で最低となる．そのため，このサービスコールを用いて，実行権の放棄を行うことができる．ディスパッチ禁止状態では，同じ優先度を持つタスクの中で最高の優先順位を持ったタスクが実行されているとは限らないため，この方法で自タスクの実行順位が同じ優先度を持つタスクの中で最低となるとは限らない．自タスク の現在優先度がベ ース優先度に一致 している場合（ミューテックス機能を使わない場合には，この条件は常に成り立つ）には，
tskpriに TPRI_SELF を指定しても同じ結果となる．
【µITRON3.0 仕様との相違】
非タスクコンテキストから呼び出された場合に，実行状態のタスクの優先度を
対象優先度とする指定は規定しないこととした．これに伴って，TPRI_RUNを
T P R I _ S E L F に名称変 更した．また，ミュ ーテックス の導入に伴 って，
TPRI_SELF は自タスクのベース優先度を指定するものとした．
272

µITRON4.0 仕様

get_tid
iget_tid

Ver. 4.01.00

実行状態のタスク ID の参照

【 S】
【 S】

【C 言語 API】
ER ercd = get_tid ( ID *p_tskid ) ;ER ercd = iget_tid ( ID *p_tskid ) ;【パラメータ】
なし【リターンパラメータ】
ER
ercd
ID
tskid
【エラーコード】
E_PAR

正常終了（E_OK）またはエラーコード
実行状態のタスクの ID番号

パラメータエラー（p_tskid が不正）【機能】
実行状態のタスク（タスクコンテキストから呼び出された場合は，自タスクに一致する）の ID 番号を参照し，tskid に返す．非タスクコンテキストから呼び出された場合で，実行状態のタスクがない時には，tskidに TSK_NONE（＝ 0）を返す．
【補足説明】
アプリケーションが用意したタスクがどれも実行できる状態にない場合に，カーネルが用意したタスク（一般的にはアイドルタスクと呼ばれる）を実行するような実装では，アイドルタスクが実行状態の時にこのサービスコールが呼び出された場合，アイドルタスクの ID 番号ではなく，TSK_NONE を返す．
【µITRON3.0 仕様との相違】
自タスクの ID 番号を返すサービスコールから，実行状態のタスクの ID 番号を返すものに変更した．具体的には，非タスクコンテキストから呼び出した場合の振舞いが変更になった．
【仕様決定の理由】
tskidをサービスコールの返値としなかったのは，タスクの ID番号が負の値になる場合に対応するためである．

273

µITRON4.0 仕様

loc_cpu
iloc_cpu

Ver. 4.01.00

CPU ロック状態への移行

【S】
【S】

【C 言語 API】
ER ercd = loc_cpu ( ) ;ER ercd = iloc_cpu ( ) ;【パラメータ】
なし【リターンパラメータ】
ER
ercd

正常終了（E_OK）またはエラーコード【エラーコード】
特記すべきエラーはない【機能】CPUロック状態に移行する．CPUロック状態で呼び出された場合には何もしない．
【補足説明】
loc_cpu（または iloc_cpu）が複数回 呼び出され ても，unl_cpu（また は
iunl_cpu）が一回呼び出されると CPU ロック解除状態となる．したがって，
loc_cpu（または iloc_cpu）と unl_cpu（または iunl_cpu）の対をネストさせたい場合には，次のような方法で対処することが必要である．
{
BOOL cpu_locked = sns_loc ( ) ;if ( !cpu_locked )loc_cpu ( ) ;CPUロック状態で行うべき処理
if ( !cpu_locked )unl_cpu ( ) ;}【µITRON3.0 仕様との相違】
CPU ロック状態の意味を変更した（3.5.4 節参照）
．また，非タスクコンテキス
トからも呼び出せるものとした．

274

µITRON4.0 仕様

unl_cpu
iunl_cpu

Ver. 4.01.00

CPU ロック状態の解除

【 S】
【 S】

【C 言語 API】
ER ercd = unl_cpu ( ) ;ER ercd = iunl_cpu ( ) ;【パラメータ】
なし【リターンパラメータ】
ER
ercd

正常終了（E_OK）またはエラーコード【エラーコード】
特記すべきエラーはない【機能】CPUロック状態解除に移行する．CPUロック解除状態で呼び出された場合には何もしない．
【µITRON3.0 仕様との相違】
CPU ロック状態の意味を変更した（3.5.4 節参照）
．これにより，このサービス
コールを呼び出しても，ディスパッチ許可状態になるとは限らないこととなった．また，非タスクコンテキストからも呼び出せるものとした．

275

µITRON4.0 仕様

dis_dspVer. 4.01.00【S】

ディスパッチの禁止【C 言語 API】
ER ercd = dis_dsp ( ) ;【パラメータ】
なし【リターンパラメータ】
ER
ercd

正常終了（E_OK）またはエラーコード【エラーコード】
特記すべきエラーはない【機能】
ディスパッチ禁止状態に移行する．ディスパッチ禁止状態で呼び出された場合には何もしない．
【補足説明】
dis_dspが複数回呼び出されても，ena_dspが一回呼び出されるとディスパッ
チ許可状態となる．したがって，dis_dsp と ena_dspの対をネストさせたい場
合には，次のような方法で対処することが必要である．
{
BOOL dispatch_disabled = sns_dsp ( ) ;if ( !dispatch_disabled )dis_dsp ( ) ;ディスパッチ禁止状態で行うべき処理
if ( !dispatch_disabled )ena_dsp ( ) ;}【µITRON3.0 仕様との相違】
ディスパッチ禁止状態の意味を変更した（3.5.5 節参照）．

276

µITRON4.0 仕様

ena_dspVer. 4.01.00【 S】

ディスパッチの許可【C 言語 API】
ER ercd = ena_dsp ( ) ;【パラメータ】
なし【リターンパラメータ】
ER
ercd

正常終了（E_OK）またはエラーコード【エラーコード】
特記すべきエラーはない【機能】
ディスパッチ許可状態に移行する．ディスパッチ許可状態で呼び出された場合には何もしない．
【µITRON3.0 仕様との相違】
ディスパッチ禁止状態の意味を変更した（3.5.5 節参照）．

277

µITRON4.0 仕様

sns_ctx

Ver. 4.01.00【S】

コンテキストの参照【C 言語 API】
BOOL state = sns_ctx ( ) ;【パラメータ】
なし【リターンパラメータ】
BOOL
state

コンテキスト【機能】
非タスクコンテキストから呼び出された場合に TRUE，タスクコンテキストから呼び出された場合に FALSEを返す．
【µITRON3.0 仕様との相違】
新設のサービスコールである．

278

µITRON4.0 仕様

sns_locVer. 4.01.00

CPU ロック状態の参照【 S】【C 言語 API】
BOOL state = sns_loc ( ) ;【パラメータ】
なし【リターンパラメータ】
BOOL
state

CPU ロック状態【機能】
システムが，CPU ロック状態の場合に TRUE，CPU ロック解除状態の場合にFALSEを返す．
【µITRON3.0 仕様との相違】
新設のサービスコールである．

279

µITRON4.0 仕様

sns_dspVer. 4.01.00

ディスパッチ禁止状態の参照【S】【C 言語 API】
BOOL state = sns_dsp ( ) ;【パラメータ】
なし【リターンパラメータ】
BOOL
state

ディスパッチ禁止状態【機能】
システムが，ディスパッチ禁止状態の場合に TRUE，ディスパッチ許可状態の場合に FALSEを返す．
【µITRON3.0 仕様との相違】
新設のサービスコールである．

280

µITRON4.0 仕様

sns_dpnVer. 4.01.00

ディスパッチ保留状態の参照【 S】【C 言語 API】
BOOL state = sns_dpn ( ) ;【パラメータ】
なし【リターンパラメータ】
BOOL
state

ディスパッチ保留状態【機能】
システムが，ディスパッチ保留状態の場合に TRUE，そうでない場合に FALSEを返す．すなわち，ディスパッチャよりも優先順位の高い処理が実行されているか，CPUロック状態であるか，ディスパッチ禁止状態であるかのいずれかの場合に，TRUEを返す．
【補足説明】
このサービスコールが FALSE を返す状態では，自タスクを広義の待ち状態にする可能性のあるサービスコールを呼び出すことができる．
【µITRON3.0 仕様との相違】
新設のサービスコールである．

281

µITRON4.0 仕様

ref_sysVer. 4.01.00

システムの状態参照【C 言語 API】
ER ercd = ref_sys ( T_RSYS *pk_rsys ) ;【パラメータ】
T_RSYS *pk_rsys【リターンパラメータ】
ER
ercd

システム状態を返すパケットへのポインタ
正常終了（E_OK）またはエラーコード

pk_rsys の内容（T_RSYS 型）（実装独自の情報が入る）【エラーコード】
E_PAR

パラメータエラー（pk_rsys が不正）【機能】システムの状態を参照し，pk_rsysで指定されるパケットに返す．具体的にどのような情報が参照できるかは，実装定義である．
【補足説明】
このサービスコールで参照できるようにする情報の候補としては，システム状
態を参照する他のサービスコール（get_tid，sns_ctx，sns_loc，sns_dsp，
sns_dpn）で参照できる情報，実行状態のタスクの優先度，割込みの禁止／許可状態，割込みマスク，プロセッサの実行モード，その他ターゲットプロセッ
サのアーキテクチャに依存した情報などが挙げられる．
【µITRON3.0 仕様との相違】µITRON3.0 仕様で参照できるシステム状態（sysstat）は，他のサービスコー
ル（sns_ctx，sns_loc，sns_dsp）で参照できるため，µITRON4.0 仕様では規定しないこととした．

282

µITRON4.0 仕様

Ver. 4.01.00

4.9 割込み管理機能
割込み管理機能は，外部割込みによって起動される割込みハンドラおよび割込
みサービスルーチンを管理するための機能である．割込みハンドラを定義する
機能，割込みサービスルーチンを生成／削除する機能，割込みサービスルーチ
ンの状態を参照する機能，割込みを禁止／許可する機能、割込みマスクを変更／参照する機能が含まれる．割込みサービスルーチンは ID 番号で識別される
オブジェクトである．
割込みサービスルーチンの ID番号を割込みサービスルー
チン ID と呼ぶ．
割込み管理機能では，次のデータ型を用いる．
INHNO
INTNO
IXXXX

割込みハンドラ番号
割込み番号
割込みマスク

割込みマスクのデータ型の一部の XXXX は，実装定義で，ターゲットプロセッ
サのアーキテクチャに応じた適切な文字列に定める．
割込みハンドラの記述形式は，実装定義である．
割込みサービスルーチンを起動する際には，その割込みサービスルーチンの拡
張情報（exinf）をパラメータとして渡す．割込みサービスルーチンの C 言語
による記述形式は次の通りとする．
void isr ( VP_INT exinf ){割込みサービスルーチン本体}
割込みハンドラ定義情報，割込みサービスルーチン定義情報，および割込み
サービスルーチン状態のパケット形式として，次のデータ型を定義する．
typedef struct t_dinh {ATR
inhatr ;/* 割込みハンドラ属性 */FP
inthdr ;/* 割込みハンドラの起動番地 *//* 実装独自に他のフィールドを追加してもよい */} T_DINH ;typedef struct t_cisr {ATR
isratr ;VP_INT
exinf ;/* 割込みサービスルーチン属性 *//* 割込みサービスルーチンの拡張情
報 */
INTNO
intno ;/* 割込みサービスルーチンを付加する
割込み番号 */
FP
isr ;/* 割込みサービスルーチンの起動番
地 *//* 実装独自に他のフィールドを追加してもよい */} T_CISR ;typedef struct t_risr {/* 実装独自のフィールドが入る */283

µITRON4.0 仕様

Ver. 4.01.00} T_RISR ;割込み管理機能の各サービスコールの機能コードは次の通りである．
TFN_DEF_INH
TFN_CRE_ISR
TFN_ACRE_ISR
TFN_DEL_ISR
TFN_REF_ISR
TFN_DIS_INT
TFN_ENA_INTTFN_CHG_IXX
TFN_GET_IXX

–0x65
–0x66
–0xcd
–0x67
–0x68
–0x69
–0x6a
–0x6b
–0x6c

def_inhの機能コード
cre_isrの機能コード
acre_isrの機能コード
del_isr の機能コード
ref_isr の機能コード
dis_int の機能コード
ena_intの機能コード
chg_ixxの機能コード
get_ixxの機能コード【スタンダードプロファイル】
スタンダー ドプロファ イルでは，割込 みハンドラ を定義する 静的 A P I（DEF_INH）をサポートしなければならない．ただし，割込みサービスルーチ
ンを追加する静的 API（ ATT_ISR）をサポートした場合には，DEF_INH をサポートする必要はない．
【補足説明】
割込みハンドラを実行するコンテキストと状態については，次のように整理できる．
• 割込みハンドラは，それぞれ独立したコンテキストで実行する（3.5.1 節参照）．割込みハンドラを実行するコンテキストは，非タスクコンテキストに分類される（3.5.2 節参照）．
• 割込みハンドラの優先順位は，ディスパッチャの優先順位よりも高い（3.5.3
節参照）．
• 割込みハンドラの実行開始直後に，CPU ロック状態か CPU ロック解除状態のいずれになっているかは実装依存であるが，割込みハンドラ内で CPUロッ
ク解除状態にする方法を明示しなければならない．また，CPUロック解除状
態にした後に，割込みハンドラから正しくリターンするための方法も明示しなければならない（3.5.4 節参照）．
• 割込みハンドラの起動と，そこからのリターンによって，ディスパッチ禁止／許可状態は変化しない．割込みハンドラ内でディスパッチ禁止／許可状態を変化させた場合には，割込みハンドラからリターンする前に元の状態に戻さなければならない（3.5.5 節参照）．
また，割込みサービスルーチンを実行するコンテキストと状態については，次のように整理できる．
• 割込みサービスルーチンは，それぞれ独立したコンテキストで実行する（3.5.1 節参照）
．割込みサービスルーチンを実行するコンテキストは，非タス
クコンテキストに分類される（3.5.2 節参照）．

284

µITRON4.0 仕様

Ver. 4.01.00• 割込みサービスルーチンの優先順位は，ディスパッチャの優先順位よりも高い（ 3.5.3 節参照）．
• 割込みサービスルーチンの実行開始直後は，CPUロック解除状態になってい
る．割込みサービスルーチンからリターンする際には，CPUロック解除状態にしなければならない（ 3.5.4 節参照）．
• 割込みサービスルーチンの起動と，そこからのリターンによって，ディスパッチ禁止／許可状態は変化しない．割込みサービスルーチン内でディスパッチ禁止／許可状態を変化させた場合には，割込みサービスルーチンから
リターンする前に元の状態に戻さなければならない（ 3.5.5 節参照）．
【µITRON3.0 仕様との相違】
CPUロック状態へ移行する機能（loc_cpu）とそれを解除する機能（unl_cpu）をシステム状態管理機能に分類することにした．ret_int と ret_wup は廃止した（3.9 節参照）．
割込みマスクを入れるパラメータおよびリターンパラメータのデータ型を，UINT から専用のデータ型として新設した IXXXX に変更した．

285

µITRON4.0 仕様

DEF_INH
def_inh

Ver. 4.01.00

割込みハンドラの定義（静的 API）

【S】

割込みハンドラの定義【静的 API】
DEF_INH ( INHNO inhno, { ATR inhatr, FP inthdr } ) ;【C 言語 API】
ER ercd = def_inh ( INHNO inhno, T_DINH *pk_dinh ) ;【パラメータ】
INHNO
T_DINH *inhno
pk_dinh

定義対象の割込みハンドラ番号
割込みハンドラ定義情報を入れたパケットへのポインタ（DEF_INH ではパケットの内容を直接記述する）

pk_dinhの内容（ T_DINH型）
ATR
inhatr
割込みハンドラ属性
FP
inthdr
割込みハンドラの起動番地（実装独自に他の情報を追加してもよい）【リターンパラメータ】
ER
ercd【エラーコード】
E_RSATR
E_PAR

正常終了（E_OK）またはエラーコード

予約属性（inhatrが不正あるいは使用できない）
パラメータエラー（inhno，pk_dinh， inthdrが不正）【機能】
inhno で指定される割込みハンドラ番号に対して，pk_dinhで指定される割込
みハンドラ定義情報に基づいて，割込みハンドラを定義する．inhatrは割込み
ハンドラの属性，inthdrは割込みハンドラの起動番地である．
DEF_INH においては，inhno は自動割付け非対応整数値パラメータ，inhatr
はプリプロセッサ定数式パラメータである．
inhno の具体的な意味は実装定義であるが，一般的な実装ではプロセッサの割込みベクトル番号に対応する．割込みベクトルを持たないプロセッサにおいては，指定することができる割込みハンドラ番号が一つのみとなる場合もある．
pk_dinh に NULL（＝ 0）が指定されると，すでに定義されている割込みハンドラの定義を解除する．また，すでに割込みハンドラが定義されている割込みハ
ンドラ番号に対して，再度割込みハンドラを定義した場合には，以前の定義を解除し，新しい定義に置き換える．
inhatrに指定できる値とその意味は実装定義である．

286

µITRON4.0 仕様

Ver. 4.01.00【スタンダードプロファイル】
ATT_ISR をサポートした場合には，DEF_INHをサポートする必要はない．
【µITRON3.0 仕様との相違】
割込みハンドラを示す略称を，int から inh に変更した．これにより，サービ
スコールの名称を def_int から def_inh にするなどの変更を行った．inhatr に指定できる属性とその意味を実装定義とした．

287

µITRON4.0 仕様

ATT_ISR
cre_isr
acre_isr

Ver. 4.01.00

割込みサービスルーチンの追加（静的 API）
割込みサービスルーチンの生成
割込みサービスルーチンの生成（ID番号自動割付け）【静的 API】
ATT_ISR ( { ATR isratr, VP_INT exinf, INTNO intno, FP isr } ) ;【C 言語 API】
ER ercd = cre_isr ( ID isrid, T_CISR *pk_cisr ) ;ER_ID isrid = acre_isr ( T_CISR *pk_cisr ) ;【パラメータ】
ID
T_CISR *isrid
pk_cisr

生成対象の割込みサービスルーチンの ID 番号（cre_isr のみ）
割込みサービスルーチン生成情報を入れたパケットへのポインタ（ATT_ISRではパケットの内容を直接記述する）

pk_cisr の内容（T_CISR型）
割込みサービスルーチン属性
ATR
isratr
割込みサービスルーチンの拡張情報
VP_INT
exinf
割込みサービスルーチンを付加する割込み番
INTNO
intno
号
割込みサービスルーチンの起動番地
FP
isr（実装独自に他の情報を追加してもよい）【リターンパラメータ】
cre_isr の場合
ER
ercd
acre_isr の場合
ER_ID
isrid
【エラーコード】
E_ID
E_NOID
E_RSATR
E_PAR
E_OBJ

正常終了（E_OK）またはエラーコード
生成した割込みサービスルーチンの ID 番号（正の値）またはエラーコード

不正 ID 番号（isridが不正あるいは使用できない；cre_isr
のみ）
ID 番号不足（割付け可能な割込みサービスルーチン IDがない；acre_isr のみ）
予約属性（isratr が不正あるいは使用できない）
パラメータエラー（pk_cisr，intno，isr が不正）オブジェクト状態エラー（対象割込みサービスルーチンが登録済み；cre_isr のみ）

288

µITRON4.0 仕様

Ver. 4.01.00【機能】
isridで指定される ID番号を持つ割込みサービスルーチンを，pk_cisrで指定される割込みサービスルーチン生成情報に基づいて生成する．isratr は割込み
サービスルーチンの属性， exinf は割込みサービスルーチンを起動する時にパラメータとして渡す拡張情報，intno は割込みサービスルーチンを起動する割込みを指定する割込み番号，isrは割込みサービスルーチンの起動番地である．
ATT_ISR は，isrid を指定せずに割込みサービスルーチンを追加する．追加した割込みサービスルーチンは ID 番号を持たない．ATT_ISRにおいては，isratr
はプリプロセッサ定数式パラメータ，intno は自動割付け非対応整数値パラメータである．
acre_isr は，生成する割込みサービスルーチンの ID番号を割込みサービスルー
チンが登録されていない ID 番号の中から割り付け，割り付けた ID 番号を返値として返す．
isratr には，（TA_HLNG ‖ TA_ASM）の指定ができる．TA_HLNG（＝ 0x00）が指定された場合には高級言語用のインタフェースで，TA_ASM（＝ 0x01）が指定された場合にはアセンブリ言語用のインタフェースで割込みサービス
ルーチンを起動する．
【スタンダードプロファイル】
スタンダードプロファイルでは，ATT_ISR をサポートすれば DEF_INH をサポートする必要はないが，その際には，isratrに TA_ASMが指定された場合の機能はサポートする必要がない．
【補足説明】
同じ割込み番号を指定して，複数の割込みサービスルーチンを登録することができる．同じ割込み番号に対して登録された複数の割込みサービスルーチンの起動方法については，3.3.2 節を参照すること．
【µITRON3.0 仕様との相違】
新設のサービスコールである．

289

µITRON4.0 仕様

del_isrVer. 4.01.00

割込みサービスルーチンの削除【C 言語 API】
ER ercd = del_isr ( ID isrid ) ;【パラメータ】
ID

isrid【リターンパラメータ】
ER
ercd【エラーコード】
E_ID
E_NOEXS

削除対象の割込みサービスルーチンの ID 番号
正常終了（E_OK）またはエラーコード

不正 ID 番号（isridが不正あるいは使用できない）
オブジェクト未生成（対象割込みサービスルーチンが未
登録）

【機能】
isrid で指定される割込みサービスルーチンを削除する．
【補足説明】
ATT_ISRで追加した割込みサービスルーチンは，ID番号を持たないために，削除することができない．
【µITRON3.0 仕様との相違】
新設のサービスコールである．

290

µITRON4.0 仕様

ref_isrVer. 4.01.00

割込みサービスルーチンの状態参照【C 言語 API】
ER ercd = ref_isr ( ID isrid, T_RISR *pk_risr ) ;【パラメータ】
ID
T_RISR *isrid
pk_risr【リターンパラメータ】
ER
ercd

状態参照対象の割込みサービスルーチンの ID
番号
割込みサービスルーチン状態を返すパケット
へのポインタ
正常終了（E_OK）またはエラーコード

pk_risrの内容（T_RISR 型）（実装独自の情報が入る）【エラーコード】
E_ID
E_NOEXS
E_PAR

不正 ID 番号（isridが不正あるいは使用できない）
オブジェクト未生成（対象割込みサービスルーチンが未登録）
パラメータエラー（pk_risrが不正）【機能】
isridで指定される割込みサービスルーチンの状態を参照し，pk_risrで指定されるパケットに返す．具体的にどのような情報が参照できるかは，実装定義である．
【µITRON3.0 仕様との相違】
新設のサービスコールである．

291

µITRON4.0 仕様

dis_int

Ver. 4.01.00

割込みの禁止【C 言語 API】
ER ercd = dis_int ( INTNO intno ) ;【パラメータ】
INTNO

intno

【リターンパラメータ】
ER
ercd【エラーコード】
E_PAR

割込みを禁止する割込み番号
正常終了（E_OK）またはエラーコード

パラメータエラー（intno が不正）【機能】
intnoで指定される割込みを禁止する．
intnoの具体的な意味は実装定義である
が，一般的な実装では IRC への割込み要求入力ラインに対応する．
【補足説明】
このサービスコールは，IRC を操作することで実現することを想定している．
このサービスコールを呼び出したことで，CPUロック状態やディスパッチ禁止
状態へ移行することはない．したがって，このサービスコールを使ってすべての割込みを禁止しても，ディスパッチは起こる．また，他のタスクへのディス
パッチ後も，割込みを禁止した状態は保たれる．
【µITRON3.0 仕様との相違】
IRC を操作して実現することを想定し，intno の意味を µITRON3.0 仕様よりも強く規定した．また，intnoのデータ型を UINT から INTNO に変更した．

292

µITRON4.0 仕様

ena_int

Ver. 4.01.00

割込みの許可【C 言語 API】
ER ercd = ena_int ( INTNO intno ) ;【パラメータ】
INTNO

intno

【リターンパラメータ】
ER
ercd【エラーコード】
E_PAR

割込みを許可する割込み番号
正常終了（E_OK）またはエラーコード

パラメータエラー（intno が不正）【機能】
intnoで指定される割込みを許可する．intnoの具体的な意味は実装定義である
が，一般的な実装では IRCへの割込み要求入力ラインに対応する．
【補足説明】
このサービスコールは，IRC を操作することで実現することを想定している．
このサービスコールを呼び出したことで，CPUロック解除状態やディスパッチ
許可状態へ移行することはない．したがって，このサービスコールを使ってある割込みを許可しても，その割込みが受け付けられる状態になるとは限らな
い．
【µITRON3.0 仕様との相違】
IRC を操作して実現することを想定し，intno の意味を µITRON3.0 仕様よりも強く規定した．また，intno のデータ型を UINT から INTNOに変更した．

293

µITRON4.0 仕様

chg_ixx

Ver. 4.01.00

割込みマスクの変更【C 言語 API】
ER ercd = chg_ixx ( IXXXX ixxxx ) ;【パラメータ】
IXXXX

ixxxx

【リターンパラメータ】
ER
ercd【エラーコード】
E_PAR

変更後の割込みマスク
正常終了（E_OK）またはエラーコード

パラメータエラー（ixxxxが不正）【機能】
プロセッサの割込みマスク（割込みレベル，割込み優先度などと呼ばれる場合もある）を，ixxxxで指定される値に変更する．
サービスコールの名称およびパラメータの名称の一部の xxおよび xxxxは，実装定義で，ターゲットプロセッサのアーキテクチャに応じた適切な文字列に定める．
ixxxx の値によっては，このサービスコールを呼び出したことで，CPU ロック
状態と CPUロック解除状態の間，ディスパッチ禁止状態とディスパッチ許可状
態の間の移行を行うことがある．どのような値でどのような移行を行うかは，実装定義である．
【補足説明】
CPU ロック／ロック解除状態をプロセッサの割込みマスクを使って管理している実装では，プロセッサの割込みマスクを変更すると，CPU ロック状態とCPUロック解除状態の間の移行を行うことがある．ディスパッチ禁止／許可状
態についても同様である．これらの状態をプロセッサの割込みマスクと変数を併用して管理している実装では，このサービスコールによってプロセッサの割込みマスクを変更すると，変数の値もそれと整合させる必要がある．
【µITRON3.0 仕様との相違】
ixxxxのデータ型を UINTから IXXXX に変更した．

294

µITRON4.0 仕様

get_ixx

Ver. 4.01.00

割込みマスクの参照【C 言語 API】
ER ercd = get_ixx ( IXXXX *p_ixxxx ) ;【パラメータ】
なし【リターンパラメータ】
ER
ercd
IXXXX
ixxxx
【エラーコード】
E_PAR

正常終了（E_OK）またはエラーコード
現在の割込みマスク

パラメータエラー（p_ixxxx が不正）【機能】
プロセッサの割込みマスク（割込みレベル，割込み優先度などと呼ばれる場合もある）を参照し ixxxx に返す．
サービスコールの名称およびパラメータの名称の一部の xx および xxxxは，実装定義で，ターゲットプロセッサのアーキテクチャに応じた適切な文字列に定める．
【µITRON3.0 仕様との相違】
サービスコールの名称を，ref_ixx から get_ixx に変更した．ixxxx のデータ型
を UINT から IXXXX に変更した．

295

µITRON4.0 仕様

Ver. 4.01.00

4.10 サービスコール管理機能
サービスコール管理機能は，拡張サービスコールの定義と呼出しを行うための機能である．拡張サービスコールを呼び出すための機能は，標準のサービス
コールを呼び出すために用いることもできる．
拡張サービスコールは，システム全体を 1つのモジュールにリンクしない場合に他のモジュールを呼び出すための機能である．拡張サービスコールが呼び出されると，アプリケーションによって定義された拡張サービスコールルーチンを起動する．
拡張サービスコールルーチンの C 言語による記述形式は次の通りとする．
ER_UINT svcrtn ( VP_INT par1, VP_INT par2, ...){
拡張サービスコールルーチン本体}
ここで，拡張サービスコールルーチンが受け取るパラメータ（par1，par2，...）は，必要な数だけ記述すればよい．実装定義で，受け取れるパラメータの数に上限が設けられている場合がある．ただし，少なくとも 1つはパラメータを受け取ることができる．
拡張サービスコール定義情報のパケット形式として，次のデータ型を定義す
る．
typedef struct t_dsvc {ATR
svcatr ;FP
svcrtn ;/* 拡張サービスコール属性 *//* 拡張サービスコールルーチンの起動
番地 *//* 実装独自に他のフィールドを追加してもよい */} T_DSVC ;サービスコール管理機能のサービスコールの機能コードは次の通りである．な
お，cal_svcは機能コードを持たない．
TFN_DEF_SVC–0x6d

def_svcの機能コード【スタンダードプロファイル】
スタンダードプロファイルでは，サービスコール管理機能はサポートする必要がない．
【補足説明】
拡張サービスコールルーチンを実行するコンテキストと状態については，次のように整理できる．
• 拡張サービスコールルーチンは，ルーチン毎および拡張サービスコールが呼び出されたコンテキスト毎に，それぞれ独立したコンテキストで実行する（3.5.1 節参照）
．拡張サービスコールルーチンを実行するコンテキストは，呼び出したコンテキストがタスクコンテキストであればタスクコンテキスト，
非タスクコンテキストであれば非タスクコンテキストに分類される（3.5.2節
296

µITRON4.0 仕様

Ver. 4.01.00

参照）．
• 拡張サービスコールルーチンの優先順位は，拡張サービスコールを呼び出した処理の優先順位よりも高く，拡張サービスコールを呼び出した処理よりも高い優先順位を持つ他のいずれの処理の優先順位よりも低い（3.5.3節参照）．
• 拡張サービスコールルーチンの起動と，そこからのリターンによって，CPU
ロック／ロック解除状態とディスパッチ禁止／許可状態は変化しない（ 3.5.4
節と 3.5.5 節を参照）．
• 実装定義で，タスク例外処理を禁止して実行する場合がある（ 4.3 節参照）．
【µITRON3.0 仕様との相違】
サービスコール管理機能という分類を，新たに設けることにした．
拡張 SVC に代えて拡張サービスコール，拡張 SVC ハンドラに代えて拡張サー
ビスコールルーチンという用語を用いることにした．また，拡張サービスコー
ルを実行するコンテキストと状態について，µITRON3.0 仕様よりは強く規定した．

297

µITRON4.0 仕様

DEF_SVC
def_svc

Ver. 4.01.00

拡張サービスコールの定義（静的 API）
拡張サービスコールの定義【静的 API】
DEF_SVC ( FN fncd, { ATR svcatr, FP svcrtn } ) ;【C 言語 API】
ER ercd = def_svc ( FN fncd, T_DSVC *pk_dsvc ) ;【パラメータ】
FN
T_DSVC *fncd
pk_dsvc

定義対象の機能コード
拡張サービスコール定義情報を入れたパケッ
トへのポインタ（DEF_SVCではパケットの内容を直接記述する）

pk_dsvc の内容（T_DSVC型）
ATR
svcatr
拡張サービスコール属性
FP
svcrtn拡張サービスコールルーチンの起動番地（実装独自に他の情報を追加してもよい）【リターンパラメータ】
ER
ercd【エラーコード】
E_RSATR
E_PAR

正常終了（E_OK）またはエラーコード

予約属性（svcatrが不正あるいは使用できない）
パラメータエラー（fncd，pk_dsvc，svcatr が不正）【機能】
fncd で指定される機能コードに対して，pk_dsvc で指定される拡張サービス
コール定義情報に基づいて，拡張サービスコールを定義する．svcatr は拡張
サービスコールの属性，svcrtnは拡張サービスコールルーチンの起動番地である．
DEF_SVC においては，fncdは自動割付け非対応整数値パラメータ，svcatrはプリプロセッサ定数式パラメータである．
この静的 APIおよびサービスコールでは，正の値の fncdに対して拡張サービス
コールを定義することができる．fncd に負の値が指定された場合には，E_PAR
エラーを返す．
pk_dsvc に NULL（＝ 0）が指定されると，すでに定義されている拡張サービス
コールの定義を解除し，拡張サービスコールが未定義の状態にする．また，すでに拡張サービスコールが定義されている機能コードに対して，再度拡張サー
ビスコールを定義した場合には，以前の定義を解除し，新しい定義に置き換え
る．
svcatrには，（TA_HLNG ‖ TA_ASM）の指定ができる．TA_HLNG（＝ 0x00）
298

µITRON4.0 仕様

Ver. 4.01.00が指定された場合には高級言語用のインタフェースで，TA_ASM（＝ 0x01）が指定された場合にはアセンブリ言語用のインタフェースで拡張サービスコー
ルルーチンを起動する．
【µITRON3.0 仕様との相違】
パラメータの名称を svchdr から svcrtnに変更した．

299

µITRON4.0 仕様

cal_svc

Ver. 4.01.00

サービスコールの呼出し【C 言語 API】
ER_UINT ercd = cal_svc ( FN fncd, VP_INT par1, VP_INT par2,...) ;【パラメータ】
FN
VP_INT
VP_INT
...

fncd
par1
par2
...

【リターンパラメータ】
ER_UINT ercd
【エラーコード】
E_RSFN

呼び出すサービスコールの機能コード
サービスコールへ第 1パラメータ
サービスコールへ第 2パラメータ（必要な数のパラメータを渡す）
サービスコールからの返値

予約機能コード（fncdが不正あるいは使用できない）【機能】
fncdで指定される機能コードのサービスコールを，par1，par2，...のパラメー
タで呼び出し，呼び出したサービスコールの返値を返す．
実装定義で，サービスコールに渡せるパラメータの数に，1 以上の上限を設けることができる．呼び出すサービスコールのパラメータのデータ型が VP_INT
でない場合には，実装で別に定義される場合を除いては，値を保存するように型変換して渡す．サービスコールの返値のデータ型が ER，BOOL，ER_BOOL，
ER_ID のいずれかの場合には，値を保存するように ER_UINTに型変換したものを返す．
このサービスコールで，拡張サービスコール以外の標準のサービスコールを呼び出せるかどうかは実装定義である．呼び出せない場合には，E_RSFNエラー
を返す．
【補足説明】
標準のサービスコールは負の値の機能コードを持つため，拡張サービスコールと区別することができる．なお，cal_svc 自身には機能コードが割り付けられていないため，cal_svcを使って cal_svc自身を呼び出すことはできない．
【µITRON3.0 仕様との相違】
新設のサービスコールである．

300

µITRON4.0 仕様

Ver. 4.01.00

4.11 システム構成管理機能
システム構成管理機能には，CPU例外ハンドラを定義する機能，システムのコ
ンフィギュレーション情報やバージョン情報を参照する機能，初期化ルーチンを定義する機能が含まれる．初期化ルーチンは，システム初期化時に実行されるルーチンである．初期化ルーチンの実行されるタイミングやコンテキストについては，3.7 節を参照すること．
システム構成管理機能では，次のデータ型を用いる．
EXCNO

CPU例外ハンドラ番号

CPU例外ハンドラの記述形式は，実装定義である．
初期化ルーチンを起動する際には，その初期化ルーチンの拡張情報（exinf）をパラメータとして渡す．初期化ルーチンの C言語による記述形式は次の通りとする．
void inirtn ( VP_INT exinf ){初期化ルーチン本体}
CPU例外ハンドラ定義情報，コンフィギュレーション情報，およびバージョン
情報のパケット形式として，次のデータ型を定義する．
typedef struct t_dexc {ATR
excatr ;/* CPU 例外ハンドラ属性 */FP
exchdr ;/* CPU 例外ハンドラの起動番地 *//* 実装独自に他のフィールドを追加してもよい */} T_DEXC ;typedef struct t_rcfg {/* 実装独自のフィールドが入る */} T_RCFG ;typedef struct t_rver {UHmaker ;UH
prid ;UH
spver ;UH
prver ;
UHprno[4] ;} T_RVER ;/* カーネルのメーカコード *//* カーネルの識別番号 *//* ITRON 仕様のバージョン番号 *//* カーネルのバージョン番号 *//* カーネル製品の管理情報 */システム構成管理機能の各サービスコールの機能コードは次の通りである．
TFN_DEF_EXC
TFN_REF_CFG
TFN_REF_VER

–0x6e
–0x6f
–0x70

def_excの機能コード
ref_cfgの機能コード
ref_ver の機能コード【スタンダードプロファイル】
スタンダ ードプロフ ァイルでは，CPU 例 外ハンドラ を定義する 静的 API（DEF_EXC），初期化ルーチンを追加する静的 API（ATT_INI）をサポートし301

µITRON4.0 仕様

Ver. 4.01.00

なければならない．
【補足説明】
CPU例外ハンドラを実行するコンテキストと状態については，次のように整理できる．
• CPU 例外ハンドラ内で呼出し可能なサービスコールは実装定義である（3.4.2
節参照）．
• CPU 例外ハンドラは，ハンドラ毎および CPU 例外が発生したコンテキスト
毎に，それぞれ独立したコンテキストで実行する（3.5.1 節参照）
．CPU例外ハンドラを実行するコンテキストは，CPU例外が発生したコンテキストがタ
スクコンテキストであればタスクコンテキストと非タスクコンテキストのいずれに分類されるか実装定義であり，非タスクコンテキストであれば非タ
スクコンテキストに分類される（3.5.2 節参照）．
• CPU 例外ハンドラの優先順位は，CPU 例外が発生した処理の優先順位と，
ディスパッチャの優先順位のいずれよりも高い（3.5.3 節参照）．
• CPU 例外ハンドラの起動と，そこからのリターンによって，CPU ロック／
ロック解除状態とディスパッチ禁止／許可状態は変化しない．CPU例外ハン
ドラ内で CPU ロック／ロック解除状態やディスパッチ禁止／許可状態を変化させた場合には，CPU例外ハンドラからリターンする前に元の状態に戻さなければならない（3.5.4 節と 3.5.5 節を参照）．

302

µITRON4.0 仕様

DEF_EXC
def_exc

Ver. 4.01.00

CPU 例外ハンドラの定義（静的 API）

【 S】

CPU 例外ハンドラの定義【静的 API】
DEF_EXC ( EXCNO excno, { ATR excatr, FP exchdr } ) ;【C 言語 API】
ER ercd = def_exc ( EXCNO excno, T_DEXC *pk_dexc ) ;【パラメータ】
EXCNO
excno
T_DEXC * pk_dexc

定義対象の CPU 例外ハンドラ番号
CPU 例外ハンドラ定義情報を入れたパケット
へのポインタ（DEF_EXCではパケットの内容を直接記述する）

pk_dexcの内容（T_DEXC 型）
ATR
excatr
CPU 例外ハンドラ属性
FP
exchdr
CPU 例外ハンドラの起動番地（実装独自に他の情報を追加してもよい）【リターンパラメータ】
ER
ercd【エラーコード】
E_RSATR
E_PAR

正常終了（E_OK）またはエラーコード

予約属性（excatr が不正あるいは使用できない）
パラメータエラー（excno，pk_dexc，exchdrが不正）【機能】
excno で指定される CPU 例外ハンドラ番号に対して，pk_dexc で指定されるCPU例外ハンドラ定義情報に基づいて，CPU 例外ハンドラを定義する．excatr
は CPU例外ハンドラの属性， exchdr は CPU例外ハンドラの起動番地である．
DEF_EXCにおいては，excnoは自動割付け非対応整数値パラメータ，excatr
はプリプロセッサ定数式パラメータである．
excno の具体的な意味は実装定義であるが，一般的な実装では，プロセッサで区別される例外の種類に対応する．
pk_dexcに NULL（＝ 0）が指定されると，すでに定義されている CPU例外ハン
ドラの定義を解除する．また，すでに CPU 例外ハンドラが定義されている CPU
例外ハンドラ番号に対して，再度 CPU 例外ハンドラを定義した場合には，以前の定義を解除し，新しい定義に置き換える．
excatr に指定できる値とその意味は実装定義である．
【µITRON3.0 仕様との相違】
このサービスコールを，CPU例外ハンドラを定義するものと定めた．CPU例外

303

µITRON4.0 仕様

Ver. 4.01.00

ハンドラを識別するオブジェクト番号を CPU例外ハンドラ番号（excno）とし，そのデータ型を EXCNO とした．また，excatrに指定できる値とその意味を実装定義とした．

304

µITRON4.0 仕様

ref_cfg

Ver. 4.01.00

コンフィギュレーション情報の参照【C 言語 API】
ER ercd = ref_cfg ( T_RCFG *pk_rcfg ) ;【パラメータ】
T_RCFG *pk_rcfg【リターンパラメータ】
ER
ercd

コンフィギュレーション情報を返すパケット
へのポインタ
正常終了（E_OK）またはエラーコード

pk_rcfg の内容（T_RCFG型）（実装独自の情報が入る）【エラーコード】
E_PAR

パラメータエラー（pk_rcfg が不正）【機能】システムの静的な情報やコンフィギュレーションで指定された情報を参照し，
pk_rcfg で指定されるパケットに返す．具体的にどのような情報が参照できる
かは，実装定義である．
【補足説明】
このサービスコールで参照できるようにする情報の候補としては，カーネル構
成定数に定義されている値，各オブジェクトの ID 番号の範囲，メモリマップの概要や使用可能なメモリ量，周辺チップや入出力装置などに関する情報，時間を指定するデータ型の時間単位や精度などが挙げられる．

305

µITRON4.0 仕様

ref_verVer. 4.01.00

バージョン情報の参照【C 言語 API】
ER ercd = ref_ver ( T_RVER *pk_rver ) ;【パラメータ】
T_RVER *pk_rver【リターンパラメータ】
ER
ercd

バージョン情報を返すパケットへのポインタ
正常終了（E_OK）またはエラーコード

pk_rver の内容（T_RVER 型）
カーネルのメーカコード
UH
maker
カーネルの識別番号
UH
prid
UH
spver
ITRON仕様のバージョン番号
カーネルのバージョン番号
UH
prver
カーネル製品の管理情報UH
prno[4]【エラーコード】
E_PAR

パラメータエラー（ pk_rver が不正）【機能】使用しているカーネルのバージョン情報を参照し，pk_rver で指定されるパケットに返す．具体的には，次の情報を参照することができる．
maker は，このカーネルを実装したメーカコードである．具体的なメーカコー
ドの割付けについては，5.4 節を参照すること．
prid は，カーネルの種類を区別するための番号である．pridの具体的な値の割付けは，カーネルを実装したメーカに任される．したがって，maker と pridの組でカーネルの種類を一意に識別することができる．
spverでは，上位 4 ビットで TRON 仕様の種類と，下位 12ビットでカーネルが準拠する仕様のバージョン番号をあらわす．spver の上位 4 ビットの値の具体的な割付けは次の通りである．
0x0
0x1
0x2
0x3
0x5
0x6

TRON 共通の仕様（TAD など）
ITRON 仕様（ITRON1，ITRON2）BTRON 仕様CTRON 仕様µITRON 仕様（µITRON2.0，µITRON3.0，µITRON4.0）µBTRON 仕様

仕様のバージョン番号の上位3桁を，
上位から4ビッspverの下位 12ビットには，トずつに入れる．すなわち，バージョン番号の上位 3桁を BCD形式で入れたことになる．検討中の仕様や暫定仕様では，バージョン番号に英文字が使われることがあるが，その場合にはその英文字を 16 進数と解釈した値を入れる．
306

µITRON4.0 仕様

Ver. 4.01.00

ITRON仕様のバージョン番号の形式については，5.3節を参照すること．
prver は，カーネル実装上のバージョン番号をあらわす．prver の具体的な値の割付けは，カーネルを実装したメーカに任される．
prno は，カーネル製品の管理情報や製品番号などを入れるために使用するためのリターンパラメータである．prno の具体的な値の意味は，カーネルを実装したメーカに任される．
【補足説明】
例えば，µITRON4.0 仕様の Ver. 4.02.10 に準拠するカーネルの spver は 0x5402，
Ver. 4.A1.01 に準拠するカーネルの spver は 0x54A1 となる．このように，ドラ
フト版の仕様に準拠して実装されたカーネルでは，仕様書の新旧関係と spverの大小関係が必ずしも一致しない．
このサービスコールが返す情報の内，prno以外の 4 つの情報は，それぞれカー
ネル構成定数 TKERNEL_MAKER， TKERNEL_PRID，TKERNEL_SPVER，
TKERNEL_PRVER によって参照することができる．
【µITRON3.0 仕様との相違】
サービスコールの名称を，get_verから ref_verに変更した．参照できる情報から，CPU 情報とバリエーション記述子を削除し，prverのフォーマットを規定しないこととした．
また，
リターンパラメータの名称を id から pridに変更した．
【仕様決定の理由】
バージョン番号の上位 3 桁より下位の桁は spver に入れていないが，これは，これらの桁が仕様の表記に関するバージョンを示すものであり，仕様の内容には関係しないためである．

307

µITRON4.0 仕様

ATT_INI

Ver. 4.01.00

初期化ルーチンの追加（静的 API）

【S】

【静的 API】
ATT_INI ( { ATR iniatr, VP_INT exinf, FP inirtn } ) ;【パラメータ】
初期化ルーチン属性
ATR
iniatr
初期化ルーチンの拡張情報
VP_INT
exinf
初期化ルーチンの起動番地
FP
inirtn（実装独自に他の情報を追加してもよい）【機能】
初期化ルーチンを，指定される各パラメータに基づいて追加する．iniatrは初期化ルーチンの属性，exinf は初期化ルーチンを起動する時にパラメータとして渡す拡張情報，inirtn は初期化ルーチンの起動番地である．
ATT_INI においては，iniatr はプリプロセッサ定数式パラメータである．
追加された初期化ルーチンは，システム初期化時に，静的 APIの処理の一環として実行する．詳しくは，3.7 節を参照すること．
（TA_HLNG ‖ TA_ASM）の指定ができる．TA_HLNG（＝ 0x00）
iniatr には，が指定された場合には高級言語用のインタフェースで，TA_ASM（＝ 0x01）が指定された場合にはアセンブリ言語用のインタフェースで初期化ルーチンを起動する．
【スタンダードプロファイル】
スタンダードプロファイルでは，iniatrに TA_ASMが指定された場合の機能はサポートする必要がない．
【補足説明】
システムコンフィギュレーションファイル中には，複数の ATT_INIを記述することができる．ATT_INI を複数記述した場合の実行順序については，3.7 節を参照すること．
【µITRON3.0 仕様との相違】
新たに導入した機能である．

308

µITRON4.0 仕様

Ver. 4.01.00

第 5 章 付属規定
5.1 µITRON4.0 仕様準拠の条件
5.1.1 基本的な考え方µITRON 仕様は，弱い標準化の方針に基づいて策定された仕様である．アプリ
ケーションプログラムの移植性よりも，多様なハードウェアやアプリケーショ
ンに対する適応化を重視し，ソフトウェア技術者の教育を容易にするための標準化を狙っている．そのため，リアルタイムカーネルとしての最低限の要件を満たしていれば，仕様で定められている機能をどこまで持たせるかや，実装独自の拡張機能を持たせるかどうかは，実装毎に自由に決定することができる．
具体的には，実装が µITRON4.0 仕様に準拠しているというためには，以下の条件を満たしていなければならない．
(a) µITRON4.0 仕様に準拠しているというために必要な最低限の機能を持っていること（5.1.2 節参照）．
(b) µITRON4.0 仕様で規定されている機能と同等の機能を持つ場合には，その機能仕様が，µITRON4.0 仕様の規定に合致していること．ただし，コンフィ
ギュレータを用意しない場合には，µITRON4.0 仕様の静的 APIの仕様に合致している必要はない．
(c) µITRON4.0 仕様で規定されていない機能を持つ場合には，その機能仕様が，µITRON4.0 仕様が実装独自の拡張方法に関して設けている規定に合致していること．た だし，実装が複 数種類の A P I をサポ ートする場 合には，µITRON4.0 仕様準拠の API 以外の APIに対してはこの規定は適用されない．
また，サービスコールの機能をサブセット化する場合や機能に制限を設ける場
合，µITRON4.0 仕様で規定されていない実装独自の機能を持つ場合には，実装について説明する製品マニュアルなどで，それらの点を明示しなければならな
い．
プロファイル規定は，高級言語で記述されたアプリケーションプログラムの移植性を保つために，カーネルが最低限満たすべき機能条件を定めるものである．µITRON4.0 仕様に準拠した実装があるプロファイル規定に準拠するためには，そのプロファイル規定に含まれるすべての機能を持っており，プロファイ
ル規定に関するすべての規定に合致していることが必要である．プロファイル
規定に含まれていない機能や実装独自の拡張機能を持っていてもよいが，プロ
ファイル規定に含まれる機能のみで動作するように記述されたアプリケー
ションプログラムが，そのまま動作することが必要である．
なお，実装したカーネルをアプリケーションに組み込む場合には，アプリケー
ションプログラムが必要としている機能だけを組み込むことができる．

309

µITRON4.0 仕様

Ver. 4.01.00【スタンダードプロファイル】
スタンダードプロファイルは，µITRON4.0 仕様におけるプロファイル規定の一つである．
【補足説明】
実装が µITRON4.0 仕様に準拠しているというための条件を例を使って説明する．例えば，実装がセマフォの機能を持つ場合には，サービスコールの名称と機能，パラメータとリターンパラメータの種類・順序・名称・データ型，メイ
ンエラーコードの種類と名称などが，µITRON4.0 仕様に規定されているセマ
フォ機能に合致していることが必要である．その際に，アプリケーションプロ
グラムの移植性を犠牲にして，サービスコールの機能をサブセット化することは許される（µITRON4.0 仕様で規定されている機能と同等の機能を持たないと見なせるため）．また，優先度継承機能を持った計数型セマフォなど，同等の機能が µITRON4.0 仕様に規定されていない機能については，実装独自に機能仕様を定めることができる．さらに，サブセット化や実装独自の機能仕様で必要になる場合には，パラメータやリターンパラメータを追加または削除することも許される．
この節の条件は，アプリケーションに組み込まれた状態について規定するものではない．スタンダードプロファイルに準拠したカーネルであっても，アプリ
ケーションに組み込む際には，アプリケーションプログラムが必要としているものだけに機能を絞り込んだり，ID番号や優先度の範囲を制限することができ
る．

5.1.2 µITRON4.0 仕様準拠の最低機能µITRON4.0 仕様に準拠しているというために必要な最低限の機能は次の通り
である．
(a) タスクを生成できること．タスクは少なくとも，実行状態，実行可能状態，
休止状態の 3 つの状態を持つこと．
(b) µITRON4.0 仕様のスケジューリング規則に従ったタスクスケジューリング
を行うこと．ただし，優先度毎のタスクを 1 つに制限することや，優先度を1 段階に制限することは許される．
(c) 割込みハンドラ（または割込みサービスルーチン）を登録できること．
(d) タスクおよび割込みハンドラ（または割込みサービスルーチン）から，タスクを起動する（休止状態から実行できる状態にする）手段が用意されていること．
(e) 自タスクを終了する（実行状態から休止状態にする）手段が用意されていること．
【補足説明】
例えば，以下のサービスコールおよび静的 API を用意し，タスクスケジューリ

310

µITRON4.0 仕様

Ver. 4.01.00

ングの規則が仕様に従っていれば，上記の最低限の機能を満たすことができる．
CRE_TSK
act_tsk ／ iact_tsk
ext_tsk
DEF_INH

タスクの生成（静的 API）
タスクの起動自タスクの終了
割込みハンドラの定義（静的 API）

この中で，割込みハンドラの定義（DEF_INH）は，割込みサービスルーチンの追加生成（ATT_ISR）で代えることができる．コンフィギュレータを用意しない場合には，静的 API の仕様に合致している必要はなく，それと同等の手段が用意されていればよい．また，act_tsk，iact_tsk では起動要求のキューイ
ングをサポートする必要はなく，ext_tsk はメインルーチンからのリターンで代用することができる．
【µITRON3.0 仕様との相違】
タスクが最低限持つべき状態を，実行状態，実行可能状態，待ち状態の 3つから，実行状態，実行可能状態，休止状態の 3つに変更した．また，最低限サポー
トすべきサービスコール（レベル R）は規定しないこととした．

5.1.3 µITRON4.0 仕様に対する拡張µITRON4.0 仕様で規定されていない機能を実現するために，実装独自にサービ
スコールを追加する場合には，サービスコール名称の前に “v” を付加しなければならない．実装独自の静的 APIの名称もこれに準ずる．ただし，非タスクコ
ンテキストから呼び出せるサービスコールを実装独自に追加する場合の名称
は，この規則の例外となる（3.6.3 節参照）
．また，実装独自のサービスコールの機能コードの値は，そのために用意された範囲内で定めなければならない．
実装独自にメインエラーコードを追加する場合には，その名称を EV_XXXXXの形とし，メインエラーコードの値をそのために用意された範囲内で定めなければならない．また，実装独自にデータ型，エラーコード以外の定数やマクロを定義する場合にも，名称中に “V” を入れるなどの方法で，µITRON4.0 仕様で定義されたものと区別することが推奨される．
µITRON4.0 仕様では，オブジェクト属性とサービスコールの動作モードを指定する定数には，8 ビットで表現できる値が割り付けられている．また，一部の例外を除いて，オブジェクトの状態をあらわす定数にも 8ビットで表現できる
値が割り付けられている．これらのパラメータまたはリターンパラメータの値の下位 8ビットは，ITRON 仕様の将来の拡張のために予約されている．これらのパラメータまたはリターンパラメータに用いるための定数を実装独自に追加する場合には，この仕様に規定されている定数で用いられているビットと，予約されている下位 8ビットを除いた，残りのビットを用いた値を割り付けなければならない．
その他，オブジェクト登録情報やオブジェクト状態を入れるためのパケット形
311

µITRON4.0 仕様

Ver. 4.01.00

式など，実装独自に拡張する方法について規定がある場合には，その規定に合致していることが必要である．

5.2 自動車制御用プロファイルµITRON4.0 仕様の自動車制御用プロファイルは，自動車制御応用を主なターゲットとして定められた µITRON4.0 仕様のプロファイル規定の 1 つである．
カーネルのオーバヘッドやメモリ使用量の削減を目指して，機能のサブセット
化およびメモリ使用量を削減するための機能追加を行っている．
具体的には，スタンダードプロファイルと比較して，自動車制御用プロファイ
ルでは，次の機能をサポートする必要はない．
• タイムアウト付きのサービスコール• タスクの優先度順の待ち行列• 強制待ち状態• タスク例外処理機能• メールボックス• 固定長メモリプール• その他，いくつかのサービスコール
逆に，メモリ使用量を削減するために追加された機能として，制約タスクの機能がある．制約タスクは，文字どおり，通常のタスクに比べて機能が制限されたものであるため，制限されて使えなくなった機能を使おうとした場合にエラーが返る（ E_NOSPT エラーが返る）ことに依存していない限りは，通常のタスクに置き換えても同じ振舞いをする．この意味で，制約タスクの機能が追加されているにも関わらず，自動車制御用プロファイルはスタンダードプロ
ファイルに対する下位互換性を有している．

5.2.1 制約タスク
制約タスクは，タスクの持つ機能を制限することで，複数のタスクを同一のスタック空間を用いて動作させることを可能にし，それによりタスクのスタックのためのメモリ領域の削減を図るものである．具体的には，制約タスクは，通常のタスクと比較して以下の制限を持つ．
• 待ち状態に入ることができない．
• 優先度を変更することができない．また，タスク生成時の初期優先度の指定に，式を用いることができない．
• タスクのメインルーチンからのリターン以外の方法で，タスクを終了することはできない．
タスクが制約タスクであるかどうかは，タスクの生成時に，タスク属性によって指定する．

312

µITRON4.0 仕様

Ver. 4.01.00【補足説明】
制約タスクにおいても，タスクの生成時のパラメータの 1つであるスタック領域のサイズの指定は有効である．例えば，同じ優先度を持った複数の制約タス
クに同じスタック領域を割り付ける場合，カーネルで確保するスタック領域のサイズを，各タスクのスタックサイズの最大値にすることが必要である．スタンダードプロファイルと同様に，スタック領域の先頭番地の（NULL 以外の）指定はサポートする必要がない．

5.2.2 自動車制御用プロファイルに含まれる機能
自動車制御用プロファイルは，制約タスクの機能を除いては，スタンダードプ
ロファイルに含まれている機能のみを含む．自動車制御用プロファイルでサ
ポートしなければならない静的 APIおよびサービスコールは，
次の通りである．
(1) タスク管理機能
CRE_TSK
act_tsk ／ iact_tsk
can_act
ext_tsk
ter_tsk
chg_priget_pri

タスクの生成（静的 API）
タスクの起動タスク起動要求のキャンセル
自タスクの終了
タスクの強制終了
タスク優先度の変更
タスク優先度の参照(2) タスク付属同期機能
slp_tsk
wup_tsk／ iwup_tsk
can_wuprel_wai／ irel_wai

起床待ち
タスクの起床タスク起床要求のキャンセル
待ち状態の強制解除(4) 同期・通信機能
セマフォ
CRE_SEM
sig_sem／ isig_sem
wai_sem
pol_sem

セマフォの生成（静的 API）
セマフォ資源の返却
セマフォ資源の獲得
セマフォ資源の獲得（ポーリング）

イベントフラグ
CRE_FLG
set_flg ／ iset_flg
clr_flg
wai_flg
pol_flg

イベントフラグの生成（静的 API）
イベントフラグのセット
イベントフラグのクリア
イベントフラグ待ち
イベントフラグ待ち（ポーリング）

データキュー
CRE_DTQ

データキューの生成（静的 API）
313

µITRON4.0 仕様
psnd_dtq ／ ipsnd_dtq
fsnd_dtq／ ifsnd_dtq
rcv_dtq
prcv_dtq

Ver. 4.01.00
データキューへの送信（ポーリング）
データキューへの強制送信
データキューからの受信
データキューからの受信（ポーリング）(7) 時間管理機能
システム時刻管理
isig_tim

タイムティックの供給※ システ ム時刻 を更 新する 機構を カー ネル内 部に持 つ場 合には，
isig_timをサポートする必要はない．
周期ハンドラ
CRE_CYC
sta_cyc
stp_cyc

周期ハンドラの生成（静的 API）
周期ハンドラの動作開始
周期ハンドラの動作停止(8) システム状態管理機能
get_tid ／ iget_tid
loc_cpu／ iloc_cpu
unl_cpu／ iunl_cpu
dis_dspena_dspsns_ctx
sns_loc
sns_dspsns_dpn

実行状態のタスク IDの参照
CPU ロック状態への移行
CPU ロック状態の解除
ディスパッチの禁止
ディスパッチの許可
コンテキストの参照
CPU ロック状態の参照
ディスパッチ禁止状態の参照
ディスパッチ保留状態の参照(9) 割込み管理機能
DEF_INH

割込みハンドラの定義（静的 API）

※ ATT_ISRをサポートした場合には，DEF_INHをサポートする必要はない．
(11) システム構成管理機能
DEF_EXCATT_INICPU 例外ハンドラの定義（静的 API）
初期化ルーチンの追加（静的 API）

これらの静的 APIおよびサービスコールの中で，自動車制御用プロファイルでサポートしなければならない機能が，スタンダードプロファイルに比べて制限
ないしは拡張されているものは次の通りである．
• CRE_TSK
タスク属性に TA_RSTR（＝ 0x04）を指定することができる．TA_RSTR が指定されると，制約タスクを生成する． TA_RSTR が指定された場合には，
itskpri は自動割付け非対応整数値パラメータとなる．
• CRE_SEM，CRE_FLG，CRE_DTQ

314

µITRON4.0 仕様

Ver. 4.01.00

各オブジェクトの属性に TA_TPRI が指定された場合の機能はサポートする必要がない．
• ext_tsk
制約タスクから呼び出された場合の振舞いは実装定義である．
• ter_tsk，chg_pri
対象タスクが制約タスクである場合には， E_NOSPT エラーを返す．
• slp_tsk，wai_sem，wai_flg，rcv_dtq
制約タスクから呼び出された場合には， E_NOSPT エラーを返す．
【補足説明】
自動車制御用プロファイルの範囲では，イベントフラグ属性に TA_TFIFO，
TA_TPRIのいずれが指定されたとしても，その振舞いは同じである．また，タスクがデータキューへの送信待ち状態になることはないため，データキュー属
性の TA_TFIFO，TA_TPRI の指定は意味を持たない．したがって，イベントフ
ラグ属性とデータキュー属性に TA_TPRI が指定された場合の機能をサポートする必要がないという制限は，実質的には，TA_TPRI が指定された場合にエラーとしても良いことのみを示している．

5.3 仕様のバージョン番号
ITRON仕様のバージョン番号は，次の形式とする．
Ver. X.YY.ZZ［ .WW］
この内，X は ITRON仕様のメジャーなバージョンを示す．カーネル仕様の場合の割付けは次の通りである．
1
2
3
4

ITRON1ITRON2または µITRON（ Ver. 2.0）
µITRON3.0µITRON4.0

YY は，仕様の内容に関する変更や追加を伴うようなバージョンの区別を示す番号である．仕様の公開後は，仕様のバージョンアップにあわせて，YY＝ 00，
01，02，... の順に増加させる．仕様の呼称を変更するような大幅なバージョン
アップの場合には， YY を不連続に増加させることもある．一方，検討中の仕様や暫定仕様（ドラフト）の場合は，YY のいずれかの桁を ‘A’，‘B’，‘C’ のい
ずれかとする．
バージョン番号の内，X.YYの部分は，カーネル構成マクロ TKERNEL_SPVERと ref_ver サービスコールのリターンパラメータ spver として参照することができる．YY が ‘A’，‘B’，‘C’ を含む場合は，16 進数の ‘A’，‘B’，‘C’を用いる．
ZZ は，仕様書の表記に関するバージョンの区別を示す番号である．仕様書の構
成や章立ての変更，ミスプリントの修正などがあった場合に， ZZ ＝ 00， 01，315

µITRON4.0 仕様

Ver. 4.01.00

02，... の順に増加させる．
仕様書の表記に関してさらにマイナーな区別を行いたい場合には，WWの桁を設ける場合がある．WW が省略されている場合には，WW が 00 であるものとみなす．

5.4 メーカコード
カーネル構成マクロ TKERNEL_MAKERと ref_verサービスコールのリターン
パラメータ maker として参照できるメーカコードは，トロン協会が割り付ける．
仕様書の発行時点で割り付けられているメーカコードは次の通りである．
0x00000x00010x00020x00080x00090x000a0x000b0x000c0x000d0x000e0x000f0x00100x00110x00120x00130x00140x00150x01010x01020x01030x01040x01050x01060x01070x01080x01090x010a0x010b
0x010dメーカコードなし（実験システムなど）
東京大学 坂村研究室
大学・研究機関個人（または個人事業者）
富士通株式会社
株式会社日立製作所
松下電器産業株式会社
三菱電機株式会社
日本電気株式会社
沖電気工業株式会社
株式会社東芝アルプス電気株式会社
株式会社ワコムパーソナルメディア株式会社
ソニー株式会社
Motorola, Inc.
National Semiconductor Corporation
オムロン株式会社
セイコープレシジョン株式会社
株式会社システムアルゴ
東京コンピュータサービス株式会社
ヤマハ株式会社
株式会社モアソンジャパン
東芝情報システム株式会社
株式会社ミスポスリーエース・コンピュータ株式会社
ファームウェアシステム株式会社
イーソル株式会社
株式会社 ACCESS

316

µITRON4.0 仕様
0x010e0x010f0x01100x0111

Ver. 4.01.00
富士通デバイス株式会社
Accelerated Technology Incorporated
株式会社エルミックシステム
エフ・ジェイ・ビー・ウェッブテクノロジー株式会社

大学・研究機関が実装したカーネルはメーカコードを 0x0002に，個人（または個人事業者）が実装したカーネルはメーカコードを 0x0008 にする．さらに，カーネルの実装者を識別できるようにするために，大学・研究機関の研究室および個人（または個人事業者）に対して，カーネルの識別番号（カーネル構成
マクロ TKERNEL_PRID と ref_ver サービスコールのリターンパラメータ pridとして参照できる値）の上位 8ビットに用いる値を割り付ける．

317

µITRON4.0 仕様

Ver. 4.01.00

318

µITRON4.0 仕様

Ver. 4.01.00

第 6 章 付録
6.1 仕様と仕様書の利用条件µITRON4.0 仕様および仕様書の利用条件は次の通りである．
仕様の利用条件µITRON4.0 仕様は，オープンな仕様である．誰でも自由に，µITRON4.0 仕様に準拠したソフトウェアを開発・使用・配布・販売することができる．トロン協会 ITRON部会へのライセンス料の支払いや届け出は必要ない．
ただし，トロン協会 ITRON 部会は，µITRON4.0 仕様に準拠したソフトウェアの製品マニュアルなどに，以下の文言（ないしは同じ趣旨の文言）を入れることを強く推奨する．
• TRON は “The Real-time Operating system Nucleus” の略称です．
• ITRON は “Industrial TRON” の略称です．
• µITRON は “Micro Industrial TRON”の略称です．
• TRON，ITRON，および µITRON は，特定の商品ないしは商品群を指す名称ではありません．
また，µITRON4.0 仕様に準拠したソフトウェアの製品マニュアルなどに，以下の文言（ないしは同じ趣旨の文言）を入れることを推奨する．
µITRON4.0 仕様は，トロン協会 ITRON 部会が中心となって策定されたµITRON4.0仕様の仕様書は，オープンなリアルタイムカーネル仕様です．
ITRON プロジェクトホームページ（http://www.itron.gr.jp/）から入手することができます．
仕様書を改変して製品マニュアルを作成する許諾を受けた場合（後述）や，
ITRON仕様準拠製品登録制度に登録する場合（6.2 節参照）には，これらの 2つの推奨に従うことが条件となる．
仕様書の利用条件µITRON4.0 仕様書の著作権は，トロン協会 ITRON部会に属する．
トロン協会 ITRON 部会は，µITRON4.0 仕様書の全文または一部分を改変することなく複写し，無料または実費程度の費用で再配布することを許諾する．ただし，µITRON4.0 仕様書の一部分を再配布する場合には，µITRON4.0 仕様書からの抜粋である旨，抜粋した箇所，および µITRON4.0 仕様書の全文を入手する
方法を明示しなければならない．
トロン協会 ITRON 部会の書面による事前の許可がない限り，µITRON4.0 仕様書を改変することは堅く禁ずる．
319

µITRON4.0 仕様

Ver. 4.01.00

トロン協会 ITRON 部会は，トロン協会会員に対して，µITRON4.0 仕様書を改変して製品マニュアルを作成し，それを配布・販売することを，有料で許諾する．許諾条件やその申請方法については，ITRON 部会に問い合わせること．
無保証
トロン協会 ITRON 部会は，µITRON4.0 仕様および仕様書に関して，いかなる保証も行わない．また，µITRON4.0 仕様および仕様書を利用したことによって直接的または間接的に生じたいかなる損害も補償しない．
また，トロン協会 ITRON 部会は，µITRON4.0 仕様書を予告なく改訂する場合がある．

6.2 仕様の保守体制と参考情報
ITRON 仕様の保守体制と問い合わせ先
ITRON 仕様および仕様書の作成・保守は，トロン協会 ITRON部会が中心となって行っている．仕様ならびに仕様書に関する問い合わせ先は，次の通りである．
( 社 )トロン協会 ITRON 部会〒 108-0073 東京都港区三田 1 丁目 3 番 39号 勝田ビル 5 階
TEL: 03-3454-3191 FAX: 03-3454-3224
ITRON プロジェクトホームページ
トロン協会 ITRON部会では，ITRON プロジェクトならびに ITRON仕様に関する情報を発信する拠点として，ITRONプロジェクトホームページを開設している．ITRON プロジェクトホームページからは，各種の ITRON 仕様書を入手できるのに加えて， ITRON プロジェクトの概要， ITRON ニュースレター，標準化活動の状況，RTOS の利用動向に関するアンケートなどの調査活動の結果，
ITRON 仕様準拠製品登録制度への登録製品の一覧，セミナーの開催や展示会への出展に関するお知らせ，講演などに用いた資料，ITRON部会のメンバなどの情報を得ることができる．
ITRON プロジェクトホームページの URLは次の通りである．
http://www.itron.gr.jp/
ITRON ニュースレター
トロン協会 ITRON 部会では，ITRON プロジェクトに関連する最新の情報や
ITRON 部会の活動状況を広く知らせることを目的に，ITRON ニュースレター
を隔月で発行している．ITRONニュースレターは，同一の内容で，日本語版と英語版を用意している．ITRON 仕様の追加・訂正に関する情報や，ITRON 部会が発行している書籍の訂正情報は，ITRON ニュースレターに掲載する．また，ITRON仕様に関連する製品の紹介，書籍や文献の紹介，セミナーや展示会
320

µITRON4.0 仕様

Ver. 4.01.00などのイベントのお知らせにも，ITRONニュースレターを活用している．
ITRONニュースレターは，TRONWARE誌（日本語版のみ）およびトロン協会の機関誌に掲載される．また，ITRONプロジェクトホームページからも読むことができる．
ITRON仕様準拠製品登録制度
トロン協会 ITRON部会では，ITRON 仕様の普及と発展を促進するため，ITRON
仕様準拠製品登録制度を設けている．この制度は，各社で開発された ITRON仕様準拠の製品の一覧を作成・保守し，ITRON 部会の広報活動などを通じて，
ITRON 仕様ならびに準拠製品の普及を図ることを目的としたものである．なお，この制度は，いわゆる検定制度とは異なり，登録された製品が ITRON仕様に準拠していることを認証するためのものではない．
この制度に登録されている製品の一覧は，ITRONプロジェクトホームページで閲覧することができる．また，ITRON仕様準拠製品登録制度への登録を希望される方は，ITRON部会まで連絡されたい．
参考文献
トロンプロジェクト全般の紹介資料として，「THE TRON PROJECT」がトロン協会により定期的に作成され，無料で配布されている．この資料には，トロンの各サブプロジェクトや応用プロジェクトの活動状況の紹介や，トロンプロ
ジェクトの歴史，トロンプロジェクトに関する参考文献リストが含まれている．
トロンプロジェクトの最新情報については，パーソナルメディア社が隔月で発行している TRON 関連技術情報誌「TRONWARE」が参考になる．また，トロンプロジェクトに関する研究成果については，毎年開催されているトロンプロ
ジェクト国際シンポジウムの論文集が参考になる．
ITRON 仕様に関する教科書として，トロン協会 ITRON 部会では，ITRON標準
ガイドブックを編集・発行している．
坂村 健 編，「ITRON 標準ガイドブック 2」，パーソナルメディア， 1994
（ISBN4-89362-133-5）．
「ITRON 標準ガイドブック 2」は µITRON3.0 仕様に準拠して書かれており，µITRON4.0 仕様には対応していないが，ITRON 部会では今後，µITRON4.0 仕様に準拠した版を編集・発行することを計画している．

6.3 仕様策定の経緯と関係者リスト
仕様策定の経緯
トロン協会 ITRON 部会では，ハードリアルタイムサポート研究会（1996 年 11
月〜 1998年 3 月）と RTOS自動車応用技術委員会（1997年 6 月〜 1998年 3 月）で321

µITRON4.0 仕様

Ver. 4.01.00の検討結果 を受けて，次世 代の µ I T RO N 仕 様を策定す ることを目 的に，µITRON4.0 仕様研究会を 1998 年 4 月に発足させた．µITRON4.0 仕様研究会は，組込みシステムの各分野のアクティブな技術者の参加を促すために，ITRON部
会メンバやトロン協会会員でなくても参加できるオープンな研究会とした．
µITRON4.0 仕様の検討は，µITRON4.0 仕様研究会の中のカーネル仕様検討 WG
において行った．カーネル仕様検討 WGは，1998 年 4月から仕様の検討活動を開始し，仕様の正式版を公表した 1999 年 6 月までの 1 年余りの期間に，毎月 1〜 2 回の頻度でミーティングを開き，また電子メールによる議論も併用して，仕様の策定作業を行った．
また µITRON4.0 仕様には，Embedded TCP/IP技術委員会における ITRON TCP/IP
API仕様の検討，Java Technology on ITRON-specification OS技術委員会におけるJTRON2.0 仕様の検討，µITRON4.0 仕様研究会 デバイスドライバ設計ガイドラ
イン WG における検討の中から出てきた要求事項やアイデアも反映されている．
トロン協会 ITRON部会および µITRON4.0 仕様研究会 カー
1999年 6月時点での，ネル仕様検討 WG のメンバリストは次の通りである．
トロン協会 ITRON部会 メンバリスト（あいうえお ABC 順）
石井 秀弘（横河ディジタルコンピュータ ( 株 )）石田 克彦（( 株 )日立製作所）
伊藤 紀彦（日本シグナスソリューションズ）
大江 哲男（沖電気工業 ( 株 )）鎌田 富久（( 株 )アクセス）亀井 達也（三菱電機 ( 株 )）副査 :工藤 健治（富士通 ( 株 )）坂村 健（東京大学）
佐藤 和夫（東芝情報システム ( 株 )）柴下 哲（メンター・グラフィックス・ジャパン ( 株 )）高木 哲郎（( 株 )デンソークリエイト）
幹事 :高田 広章（豊橋技術科学大学）
事務局 : 竹内 透（( 社 )トロン協会）
主査 :田丸 喜一郎（( 株 )東芝）
綱川 寧孝（ソニー ( 株 )）八谷 祥一（( 株 )アプリックス）
平山 亮（Hewlett-Packard Company）
広瀬 昇（ファームウェアシステム ( 株 )）本間 茂（ヤマハ ( 株 )）松為 彰（パーソナルメディア ( 株 )）門田 浩（日本電気 ( 株 )）渡辺 洋幸（セイコーインスツルメンツ ( 株 )）322

µITRON4.0 仕様

Ver. 4.01.00

CHEUCK, John（メトロワークス (株 )）µITRON4.0 仕様研究会 カーネル仕様検討 WG メンバリスト（あいうえお順）

幹事 :

幹事 :

幹事 :

青木 義彦（( 株 )サンテック）
浅井 茂昌（アイシン精機 (株 )）足立 佳啓（松下電器産業 (株 )）飯島 純一
石川 正則（横河ディジタルコンピュータ (株 )）石田 克彦（( 株 )日立製作所）
礒本 和典（マツダ (株 )）伊藤 紀彦（日本シグナスソリューションズ）
伊藤 恭直（富士電機三重設計 (株 )）稲光 一豊（富士通デバイス (株 )）伊深 和浩（日本モトローラ (株 )）岩城 喜久（( 株 )本田技術研究所）
上原 直隆（カシオ計算機 (株 )）植村 正和（富士電機三重設計 (株 )）筬島 雅之（( 株 )アクセス）
小野沢 智（アイシン精機 (株 )）加古 浩（( 株 )デンソー）
金田 久徳（データテクノロジー ( 株 )）川口 広（花塚デン気工業 (株 )）工藤 健治（富士通デバイス (株 )）工藤 隆弘（データテクノロジー ( 株 )）児玉 剛（アルパイン情報システム (株 )）小早川 学（( 株 )日立製作所）
小林 正和（( 株 )日立超 LSI システムズ）
小林 康浩（富士通 (株 )）坂本 秀人（イーエスティ ( 株 )）佐藤 浩司（トヨタ自動車 (株 )）佐藤 修治（東芝エンジニアリング (株 )）澤田 勉（エルグ (株 )）繁田 雅信（富士電機 (株 )）嶋崎 和（( 株 )セネット）
宿口 雅弘（三菱電機マイコン機器ソフトウエア (株 )）菅沼 賢治（( 株 )デンソー）
菅沼 英明（トヨタ自動車 (株 )）杉本 明彦（データテクノロジー ( 株 )）多岡 和彦（( 有 )宮崎システム設計事務所）
高田 広章（豊橋技術科学大学）
高梨 修二（( 株 )東芝）
323

µITRON4.0 仕様

Ver. 4.01.00

高野 陽介（日本電気 ( 株 )）事務局 : 竹内 透（( 社 )トロン協会）
田中 憲昭（( 株 )デンソークリエイト）
千葉 昭仁（日本情報通信コンサルティング ( 株 )）綱島 真一（( 株 )アクセス）
寺内 一浩（東芝情報システム ( 株 )）内藤 隆一（日立ビジネスソリューション ( 株 )）仲井 裕育（( 株 )電産）
永作 浩之（( 株 )クレスコ）
中村 憲一（日本シグナスソリューションズ）
南角 茂樹（三菱電機 ( 株 )）橋本 真一（( 株 )アクセス）
八谷 祥一（( 株 )アプリックス）
東原 修（( 株 )NEC情報システムズ）
檜原 弘樹（日本電気 ( 株 )）堀内 美智太郎（( 株 )アクセス）
正木 忠勝（( 株 )松下電器情報システム広島研究所）
松永 高幸（矢崎総業 ( 株 )）三木 敦志（住友電工 ( 株 )）宮内 哲夫（日本電気マイコンテクノロジー ( 株 )）宮崎 久則（( 有 )宮崎システム設計事務所）
宮本 久也（( 株 )東芝）
麦谷 浩平（シャープ ( 株 )）村木 宏行（三菱電機セミコンダクタシステム ( 株 )）山田 真二郎（( 株 )日立製作所）
山田 達雄（日本モトローラ ( 株 )）山中 勝（日本シグナスソリューションズ）
横澤 彰（( 株 )東芝）
吉田 智明（( 株 )東芝）
吉野 由紀夫（キャッツ ( 株 )）吉村 美代子（エルグ ( 株 )）渡辺 政彦（キャッツ ( 株 )）6.4 バージョン履歴1999 年 5月 10 日
1999 年 5月 17 日
1999 年 6月 1 日
1999 年 6月 10 日
1999 年 6月 30 日
2001 年 4月 23 日

Ver. 4.A0.00
Ver. 4.A1.00
Ver. 4.B0.00
Ver. 4.B1.00
Ver. 4.00.00
Ver. 4.01.A0

ドラフト版を公開して意見を公募
未完成部分を追加（カーネル仕様検討 WGでの検討資料）（カーネル仕様検討 WGでの検討資料）
正式版を公開（仕様改訂のための検討資料）
324

µITRON4.0 仕様
2001 年 5月 3 日
2001 年 5月 31 日

Ver. 4.01.00
Ver. 4.01.A1
Ver. 4.01.00（仕様改訂のための検討資料）
改訂版を公開325

µITRON4.0 仕様

Ver. 4.01.00

326µITRON4.0 仕様

Ver. 4.01.00

第 7 章 リファレンス
7.1 サービスコール一覧(1) タスク管理機能
ER ercd = cre_tsk ( ID tskid, T_CTSK *pk_ctsk ) ;ER_ID tskid = acre_tsk ( T_CTSK *pk_ctsk ) ;ER ercd = del_tsk ( ID tskid ) ;ER ercd = act_tsk ( ID tskid ) ;ER ercd = iact_tsk ( ID tskid ) ;ER_UINT actcnt = can_act ( ID tskid ) ;ER ercd = sta_tsk ( ID tskid, VP_INT stacd ) ;void ext_tsk ( ) ;void exd_tsk ( ) ;ER ercd = ter_tsk ( ID tskid ) ;ER ercd = chg_pri ( ID tskid, PRI tskpri ) ;ER ercd = get_pri ( ID tskid, PRI *p_tskpri ) ;ER ercd = ref_tsk ( ID tskid, T_RTSK *pk_rtsk ) ;ER ercd = ref_tst ( ID tskid, T_RTST *pk_rtst ) ;(2) タスク付属同期機能
ER ercd = slp_tsk ( ) ;ER ercd = tslp_tsk ( TMO tmout ) ;ER ercd = wup_tsk ( ID tskid ) ;ER ercd = iwup_tsk ( ID tskid ) ;ER_UINT wupcnt = can_wup ( ID tskid ) ;ER ercd = rel_wai ( ID tskid ) ;ER ercd = irel_wai ( ID tskid ) ;ER ercd = sus_tsk ( ID tskid ) ;ER ercd = rsm_tsk ( ID tskid ) ;ER ercd = frsm_tsk ( ID tskid ) ;ER ercd = dly_tsk ( RELTIM dlytim ) ;(3) タスク例外処理機能
ER ercd = def_tex ( ID tskid, T_DTEX *pk_dtex ) ;ER ercd = ras_tex ( ID tskid, TEXPTN rasptn ) ;ER ercd = iras_tex ( ID tskid, TEXPTN rasptn ) ;ER ercd = dis_tex ( ) ;ER ercd = ena_tex ( ) ;BOOL state = sns_tex ( ) ;ER ercd = ref_tex ( ID tskid, T_RTEX *pk_rtex ) ;327

µITRON4.0 仕様

Ver. 4.01.00(4) 同期・通信機能
セマフォ
ER ercd = cre_sem ( ID semid, T_CSEM *pk_csem ) ;ER_ID semid = acre_sem ( T_CSEM *pk_csem ) ;ER ercd = del_sem ( ID semid ) ;ER ercd = sig_sem ( ID semid ) ;ER ercd = isig_sem ( ID semid ) ;ER ercd = wai_sem ( ID semid ) ;ER ercd = pol_sem ( ID semid ) ;ER ercd = twai_sem ( ID semid, TMO tmout ) ;ER ercd = ref_sem ( ID semid, T_RSEM *pk_rsem ) ;イベントフラグER ercd = cre_flg ( ID flgid, T_CFLG *pk_cflg ) ;ER_ID flgid = acre_flg ( T_CFLG *pk_cflg ) ;ER ercd = del_flg ( ID flgid ) ;ER ercd = set_flg ( ID flgid, FLGPTN setptn ) ;ER ercd = iset_flg ( ID flgid, FLGPTN setptn ) ;ER ercd = clr_flg ( ID flgid, FLGPTN clrptn ) ;ER ercd = wai_flg ( ID flgid, FLGPTN waiptn, MODE wfmode,
FLGPTN *p_flgptn ) ;ER ercd = pol_flg ( ID flgid, FLGPTN waiptn, MODE wfmode,
FLGPTN *p_flgptn ) ;ER ercd = twai_flg ( ID flgid, FLGPTN waiptn, MODE wfmode,
FLGPTN *p_flgptn, TMO tmout ) ;ER ercd = ref_flg ( ID flgid, T_RFLG *pk_rflg ) ;データキューER ercd = cre_dtq ( ID dtqid, T_CDTQ *pk_cdtq ) ;ER_ID dtqid = acre_dtq ( T_CDTQ *pk_cdtq ) ;ER ercd = del_dtq ( ID dtqid ) ;ER ercd = snd_dtq ( ID dtqid, VP_INT data ) ;ER ercd = psnd_dtq ( ID dtqid, VP_INT data ) ;ER ercd = ipsnd_dtq ( ID dtqid, VP_INT data ) ;ER ercd = tsnd_dtq ( ID dtqid, VP_INT data, TMO tmout ) ;ER ercd = fsnd_dtq ( ID dtqid, VP_INT data ) ;ER ercd = ifsnd_dtq ( ID dtqid, VP_INT data ) ;ER ercd = rcv_dtq ( ID dtqid, VP_INT *p_data ) ;ER ercd = prcv_dtq ( ID dtqid, VP_INT *p_data ) ;ER ercd = trcv_dtq ( ID dtqid, VP_INT *p_data, TMO tmout ) ;ER ercd = ref_dtq ( ID dtqid, T_RDTQ *pk_rdtq ) ;メールボックス
ER ercd = cre_mbx ( ID mbxid, T_CMBX *pk_cmbx ) ;328

µITRON4.0 仕様

Ver. 4.01.00

ER_ID mbxid = acre_mbx ( T_CMBX *pk_cmbx ) ;ER ercd = del_mbx ( ID mbxid ) ;ER ercd = snd_mbx ( ID mbxid, T_MSG *pk_msg ) ;ER ercd = rcv_mbx ( ID mbxid, T_MSG **ppk_msg ) ;ER ercd = prcv_mbx ( ID mbxid, T_MSG **ppk_msg ) ;ER ercd = trcv_mbx ( ID mbxid, T_MSG **ppk_msg,
TMO tmout ) ;ER ercd = ref_mbx ( ID mbxid, T_RMBX *pk_rmbx ) ;(5) 拡張同期・通信機能
ミューテックス
ER ercd = cre_mtx ( ID mtxid, T_CMTX *pk_cmtx ) ;ER_ID mtxid = acre_mtx ( T_CMTX *pk_cmtx ) ;ER ercd = del_mtx ( ID mtxid ) ;ER ercd = loc_mtx ( ID mtxid ) ;ER ercd = ploc_mtx ( ID mtxid ) ;ER ercd = tloc_mtx ( ID mtxid, TMO tmout ) ;ER ercd = unl_mtx ( ID mtxid ) ;ER ercd = ref_mtx ( ID mtxid, T_RMTX *pk_rmtx ) ;メッセージバッファER ercd = cre_mbf ( ID mbfid, T_CMBF *pk_cmbf ) ;ER_ID mbfid = acre_mbf ( T_CMBF *pk_cmbf ) ;ER ercd = del_mbf ( ID mbfid ) ;ER ercd = snd_mbf ( ID mbfid, VP msg, UINT msgsz ) ;ER ercd = psnd_mbf ( ID mbfid, VP msg, UINT msgsz ) ;ER ercd = tsnd_mbf ( ID mbfid, VP msg, UINT msgsz,
TMO tmout ) ;ER_UINT msgsz = rcv_mbf ( ID mbfid, VP msg ) ;ER_UINT msgsz = prcv_mbf ( ID mbfid, VP msg ) ;ER_UINT msgsz = trcv_mbf ( ID mbfid, VP msg, TMO tmout ) ;ER ercd = ref_mbf ( ID mbfid, T_RMBF *pk_rmbf ) ;ランデブ
ER ercd = cre_por ( ID porid, T_CPOR *pk_cpor ) ;ER_ID porid = acre_por ( T_CPOR *pk_cpor ) ;ER ercd = del_por ( ID porid ) ;ER_UINT rmsgsz = cal_por ( ID porid, RDVPTN calptn, VP msg,
UINT cmsgsz ) ;ER_UINT rmsgsz = tcal_por ( ID porid, RDVPTN calptn, VP msg,
UINT cmsgsz, TMO tmout ) ;ER_UINT cmsgsz = acp_por ( ID porid, RDVPTN acpptn,
RDVNO *p_rdvno, VP msg ) ;329

µITRON4.0 仕様

Ver. 4.01.00

ER_UINT cmsgsz = pacp_por ( ID porid, RDVPTN acpptn,
RDVNO *p_rdvno, VP msg ) ;ER_UINT cmsgsz = tacp_por ( ID porid, RDVPTN acpptn,
RDVNO *p_rdvno, VP msg, TMO tmout ) ;ER ercd = fwd_por ( ID porid, RDVPTN calptn, RDVNO rdvno,
VP msg, UINT cmsgsz ) ;ER ercd = rpl_rdv ( RDVNO rdvno, VP msg, UINT rmsgsz ) ;ER ercd = ref_por ( ID porid, T_RPOR *pk_rpor ) ;ER ercd = ref_rdv ( RDVNO rdvno, T_RRDV *pk_rrdv ) ;(6) メモリプール管理機能
固定長メモリプール
ER ercd = cre_mpf ( ID mpfid, T_CMPF *pk_cmpf ) ;ER_ID mpfid = acre_mpf ( T_CMPF *pk_cmpf ) ;ER ercd = del_mpf ( ID mpfid ) ;ER ercd = get_mpf ( ID mpfid, VP *p_blk ) ;ER ercd = pget_mpf ( ID mpfid, VP *p_blk ) ;ER ercd = tget_mpf ( ID mpfid, VP *p_blk, TMO tmout ) ;ER ercd = rel_mpf ( ID mpfid, VP blk ) ;ER ercd = ref_mpf ( ID mpfid, T_RMPF *pk_rmpf ) ;可変長メモリプール
ER ercd = cre_mpl ( ID mplid, T_CMPL *pk_cmpl ) ;ER_ID mplid = acre_mpl ( T_CMPL *pk_cmpl ) ;ER ercd = del_mpl ( ID mplid ) ;ER ercd = get_mpl ( ID mplid, UINT blksz, VP *p_blk ) ;ER ercd = pget_mpl ( ID mplid, UINT blksz, VP *p_blk ) ;ER ercd = tget_mpl ( ID mplid, UINT blksz, VP *p_blk,
TMO tmout ) ;ER ercd = rel_mpl ( ID mplid, VP blk ) ;ER ercd = ref_mpl ( ID mplid, T_RMPL *pk_rmpl ) ;(7) 時間管理機能
システム時刻管理
ER ercd = set_tim ( SYSTIM *p_systim ) ;ER ercd = get_tim ( SYSTIM *p_systim ) ;ER ercd = isig_tim ( ) ;周期ハンドラER ercd = cre_cyc ( ID cycid, T_CCYC *pk_ccyc ) ;ER_ID cycid = acre_cyc ( T_CCYC *pk_ccyc ) ;ER ercd = del_cyc ( ID cycid ) ;ER ercd = sta_cyc ( ID cycid ) ;ER ercd = stp_cyc ( ID cycid ) ;330

µITRON4.0 仕様

Ver. 4.01.00

ER ercd = ref_cyc ( ID cycid, T_RCYC *pk_rcyc ) ;アラームハンドラ
ER ercd = cre_alm ( ID almid, T_CALM *pk_calm ) ;ER_ID almid = acre_alm ( T_CALM *pk_calm ) ;ER ercd = del_alm ( ID almid ) ;ER ercd = sta_alm ( ID almid, RELTIM almtim ) ;ER ercd = stp_alm ( ID almid ) ;ER ercd = ref_alm ( ID almid, T_RALM *pk_ralm ) ;オーバランハンドラ
ER ercd = def_ovr ( T_DOVR *pk_dovr ) ;ER ercd = sta_ovr ( ID tskid, OVRTIM ovrtim ) ;ER ercd = stp_ovr ( ID tskid ) ;ER ercd = ref_ovr ( ID tskid, T_ROVR *pk_rovr ) ;(8) システム状態管理機能
ER ercd = rot_rdq ( PRI tskpri ) ;ER ercd = irot_rdq ( PRI tskpri ) ;ER ercd = get_tid ( ID *p_tskid ) ;ER ercd = iget_tid ( ID *p_tskid ) ;ER ercd = loc_cpu ( ) ;ER ercd = iloc_cpu ( ) ;ER ercd = unl_cpu ( ) ;ER ercd = iunl_cpu ( ) ;ER ercd = dis_dsp ( ) ;ER ercd = ena_dsp ( ) ;BOOL state = sns_ctx ( ) ;BOOL state = sns_loc ( ) ;BOOL state = sns_dsp ( ) ;BOOL state = sns_dpn ( ) ;ER ercd = ref_sys ( T_RSYS *pk_rsys ) ;(9) 割込み管理機能
ER ercd = def_inh ( INHNO inhno, T_DINH *pk_dinh ) ;ER ercd = cre_isr ( ID isrid, T_CISR *pk_cisr ) ;ER_ID isrid = acre_isr ( T_CISR *pk_cisr ) ;ER ercd = del_isr ( ID isrid ) ;ER ercd = ref_isr ( ID isrid, T_RISR *pk_risr ) ;ER ercd = dis_int ( INTNO intno ) ;ER ercd = ena_int ( INTNO intno ) ;ER ercd = chg_ixx ( IXXXX ixxxx ) ;ER ercd = get_ixx ( IXXXX *p_ixxxx ) ;331

µITRON4.0 仕様

Ver. 4.01.00(10) サービスコール管理機能
ER ercd = def_svc ( FN fncd, T_DSVC *pk_dsvc ) ;ER_UINT ercd = cal_svc ( FN fncd, VP_INT par1, VP_INT par2,...) ;(11) システム構成管理機能
ER ercd = def_exc ( EXCNO excno, T_DEXC *pk_dexc ) ;ER ercd = ref_cfg ( T_RCFG *pk_rcfg ) ;ER ercd = ref_ver ( T_RVER *pk_rver ) ;7.2 静的 API一覧(1) タスク管理機能
CRE_TSK ( ID tskid, { ATR tskatr, VP_INT exinf, FP task,
PRI itskpri, SIZE stksz, VP stk } ) ;(3) タスク例外処理機能
DEF_TEX ( ID tskid, { ATR texatr, FP texrtn } ) ;(4) 同期・通信機能
CRE_SEM ( ID semid, { ATR sematr, UINT isemcnt,
UINT maxsem } ) ;CRE_FLG ( ID flgid, { ATR flgatr, FLGPTN iflgptn } ) ;CRE_DTQ ( ID dtqid, { ATR dtqatr, UINT dtqcnt, VP dtq } ) ;CRE_MBX ( ID mbxid, { ATR mbxatr, PRI maxmpri,
VP mprihd } ) ;(5) 拡張同期・通信機能
CRE_MTX ( ID mtxid, { ATR mtxatr, PRI ceilpri } ) ;CRE_MBF ( ID mbfid, { ATR mbfatr, UINT maxmsz, SIZE mbfsz,
VP mbf } ) ;CRE_POR ( ID porid, { ATR poratr, UINT maxcmsz,
UINT maxrmsz } ) ;(6) メモリプール管理機能
CRE_MPF ( ID mpfid, { ATR mpfatr, UINT blkcnt, UINT blksz,
VP mpf } ) ;CRE_MPL ( ID mplid, { ATR mplatr, SIZE mplsz, VP mpl } ) ;(7) 時間管理機能
CRE_CYC ( ID cycid, { ATR cycatr, VP_INT exinf, FP cychdr,
RELTIM cyctim, RELTIM cycphs } ) ;CRE_ALM ( ID almid, { ATR almatr, VP_INT exinf, FP almhdr } ) ;DEF_OVR ( { ATR ovratr, FP ovrhdr } ) ;332

µITRON4.0 仕様

Ver. 4.01.00(9) 割込み管理機能
DEF_INH ( INHNO inhno, { ATR inhatr, FP inthdr } ) ;ATT_ISR ( { ATR isratr, VP_INT exinf, INTNO intno, FP isr } ) ;(10) サービスコール管理機能
DEF_SVC ( FN fncd, { ATR svcatr, FP svcrtn } ) ;(11) システム構成管理機能
DEF_EXC ( EXCNO excno, { ATR excatr, FP exchdr } ) ;ATT_INI ( { ATR iniatr, VP_INT exinf, FP inirtn } ) ;ITRON仕様共通静的 API
INCLUDE ( 文字列 ) ;7.3 スタンダードプロファイルの静的 APIとサービ
スコール(1) タスク管理機能
CRE_TSK
act_tsk ／ iact_tsk
can_act
ext_tsk
ter_tsk
chg_priget_pri

タスクの生成（静的 API）
タスクの起動タスク起動要求のキャンセル
自タスクの終了
タスクの強制終了
タスク優先度の変更
タスク優先度の参照(2) タスク付属同期機能
slp_tsktslp_tsk
wup_tsk／ iwup_tsk
can_wuprel_wai／ irel_wai
sus_tsk
rsm_tsk
frsm_tsk
dly_tsk

起床待ち
起床待ち（タイムアウトあり）
タスクの起床タスク起床要求のキャンセル
待ち状態の強制解除
強制待ち状態への移行
強制待ち状態からの再開
強制待ち状態からの強制再開
自タスクの遅延(3) タスク例外処理機能
DEF_TEX
ras_tex ／ iras_tex
dis_texena_texsns_tex

タスク例外処理ルーチンの定義（静的 API）
タスク例外処理の要求
タスク例外処理の禁止
タスク例外処理の許可
タスク例外処理禁止状態の参照

333

µITRON4.0 仕様

Ver. 4.01.00(4) 同期・通信機能
セマフォ
CRE_SEM
sig_sem ／ isig_sem
wai_sem
pol_sem
twai_sem

セマフォの生成（静的 API）
セマフォ資源の返却
セマフォ資源の獲得
セマフォ資源の獲得（ポーリング）
セマフォ資源の獲得（タイムアウトあり）

イベントフラグ
CRE_FLG
set_flg ／ iset_flg
clr_flg
wai_flg
pol_flg
twai_flg

イベントフラグの生成（静的 API）
イベントフラグのセット
イベントフラグのクリア
イベントフラグ待ち
イベントフラグ待ち（ポーリング）
イベントフラグ待ち（タイムアウトあり）

データキュー
CRE_DTQ
snd_dtq
psnd_dtq ／ ipsnd_dtq
tsnd_dtq
fsnd_dtq／ ifsnd_dtq
rcv_dtq
prcv_dtq
trcv_dtq

データキューの生成（静的 API）
データキューへの送信
データキューへの送信（ポーリング）
データキューへの送信（タイムアウトあり）
データキューへの強制送信
データキューからの受信
データキューからの受信（ポーリング）
データキューからの受信（タイムアウトあり）

メールボックス
CRE_MBX
snd_mbx
rcv_mbx
prcv_mbx
trcv_mbx

メールボックスの生成（静的 API）
メールボックスへの送信
メールボックスからの受信
メールボックスからの受信（ポーリング）
メールボックスからの受信（タイムアウトあり）(6) メモリプール管理機能
固定長メモリプール
CRE_MPF
get_mpf
pget_mpf
tget_mpf
rel_mpf

固定長メモリプールの生成（静的 API）
固定長メモリブロックの獲得
固定長メモリブロックの獲得（ポーリング）
固定長メモリブロックの獲得（タイムアウトあり）
固定長メモリブロックの返却

334

µITRON4.0 仕様

Ver. 4.01.00(7) 時間管理機能
システム時刻管理
set_tim
get_timisig_tim

システム時刻の設定
システム時刻の参照
タイムティックの供給※ シス テム時 刻を更 新する 機構 をカー ネル内 部に 持つ場 合には，
isig_timをサポートする必要はない．
周期ハンドラ
CRE_CYC
sta_cyc
stp_cyc

周期ハンドラの生成（静的 API）
周期ハンドラの動作開始
周期ハンドラの動作停止(8) システム状態管理機能
rot_rdq／ irot_rdq
get_tid ／ iget_tid
loc_cpu／ iloc_cpu
unl_cpu／ iunl_cpu
dis_dspena_dspsns_ctx
sns_loc
sns_dspsns_dpn

タスクの優先順位の回転
実行状態のタスク ID の参照
CPUロック状態への移行
CPUロック状態の解除
ディスパッチの禁止
ディスパッチの許可
コンテキストの参照
CPUロック状態の参照
ディスパッチ禁止状態の参照
ディスパッチ保留状態の参照(9) 割込み管理機能
DEF_INH

割込みハンドラの定義（静的 API）

※ ATT_ISR をサポートした場合には，DEF_INHをサポートする必要はない．
(11) システム構成管理機能
DEF_EXCATT_INI

CPU例外ハンドラの定義（静的 API）
初期化ルーチンの追加（静的 API）

7.4 データ型µITRON4.0 仕様で規定しているデータ型は次の通り（パケットのためのデータ
型を除く）
．
B
H
W
D

符号付き 8ビット整数
符号付き 16ビット整数
符号付き 32ビット整数
符号付き 64ビット整数

335

µITRON4.0 仕様

Ver. 4.01.00

UB
UH
UW
UD

符号無し 8ビット整数
符号無し 16ビット整数
符号無し 32ビット整数
符号無し 64ビット整数

VB
VH
VW
VD

データタイプが定まらない 8ビットの値
データタイプが定まらない 16ビットの値
データタイプが定まらない 32ビットの値
データタイプが定まらない 64ビットの値

VP
FP

データタイプが定まらないものへのポインタ
プログラムの起動番地（ポインタ）

INT
UINT

プロセッサに自然なサイズの符号付き整数
プロセッサに自然なサイズの符号無し整数

BOOL

真偽値（TRUE または FALSE）

FN
ER
ID
ATR
STAT
MODE
PRI
SIZE

機能コード（符号付き整数）
エラーコード（符号付き整数）
オブジェクトの ID 番号（符号付き整数）
オブジェクト属性（符号無し整数）
オブジェクトの状態（符号無し整数）
サービスコールの動作モード（符号無し整数）
優先度（符号付き整数）
メモリ領域のサイズ（符号無し整数）TMO
RELTIM
SYSTIM

タイムアウト指定（符号付き整数，時間単位は実装定義）
相対時間（符号無し整数，時間単位は実装定義）
システム時刻（符号無し整数，時間単位は実装定義）

VP_INT

データタイプが定まらないものへのポインタまたはプロセッサに自然なサイズの符号付き整数

ER_BOOL
ER_ID

エラーコードまたは真偽値
エラーコードまたは ID 番号（負の ID 番号は表現できない）
エラーコードまたは符号無し整数（符号無し整数の有効ビット数は UINT より 1ビット短い）

ER_UINTTEXPTNFLGPTN
T_MSG
T_MSG_PRIRDVPTNRDVNOOVRTIM

タスク例外要因のビットパターン（符号無し整数）
イベントフラグのビットパターン（符号無し整数）
メールボックスのメッセージヘッダ
メールボックスの優先度付きメッセージヘッダ
ランデブ条件のビットパターン（符号無し整数）
ランデブ番号
プロセッサ時間（符号無し整数，時間単位は実装定義）336

µITRON4.0 仕様
INHNO
INTNO
IXXXX
EXCNO

Ver. 4.01.00
割込みハンドラ番号
割込み番号
割込みマスクCPU例外ハンドラ番号

これらの中で，次のデータ型は定義が標準化されている．
typedef struct t_msg_pri {T_MSG
msgque ;PRI
msgpri ;} T_MSG_PRI ;/* メッセージヘッダ *//* メッセージ優先度 */【スタンダードプロファイル】
スタンダードプロファイルで定義しなければならないデータ型と，それらの有効ビット数と時間単位は次の通り（パケットのためのデータ型を除く）．
B
H
W

符号付き 8ビット整数
符号付き 16ビット整数
符号付き 32ビット整数

UB
UH
UW

符号無し 8ビット整数
符号無し 16ビット整数
符号無し 32ビット整数

VB
VH
VW

データタイプが定まらない 8ビットの値
データタイプが定まらない 16ビットの値
データタイプが定まらない 32ビットの値

VP
FP

データタイプが定まらないものへのポインタ
プログラムの起動番地（ポインタ）

INT

プロセッサに自然なサイズの符号付き整数（16ビット以上）プロセッサに自然なサイズの符号無し整数（16ビット以
上）

UINT
BOOL

真偽値（TRUEまたは FALSE）

FN
ER
ID
ATR
STAT
MODE

機能コード（符号付き整数，16 ビット以上）
エラーコード（符号付き整数，8 ビット以上）
オブジェクトの ID 番号（符号付き整数，16ビット以上）
オブジェクト属性（符号無し整数，8 ビット以上）
オブジェクトの状態（符号無し整数，16 ビット以上）
サービスコールの動作モード（符号無し整数，8 ビット
以上）
優先度（符号付き整数，16 ビット以上）
メモリ領域のサイズ（符号無し整数，ポインタと同じ
ビット数）

PRI
SIZE

337

µITRON4.0 仕様
TMO
RELTIM
SYSTIM

Ver. 4.01.00
タイムアウト指定（符号付き整数，16ビット以上，時間
単位は 1ミリ秒）
相対時間（符号無し整数，16 ビット以上，時間単位は 1
ミリ秒）
システム時刻（符号無し整数，16ビット以上，時間単位
は 1ミリ秒）VP_INT

データタイプが定まらないものへのポインタまたはプロセッサに自然なサイズの符号付き整数（VP と INT の大きい方と同じビット数）

ER_BOOL

エラーコードまたは真偽値（符号付き整数，ER と BOOLの大きい方と同じビット数）
エラーコードまたは ID 番号（符号付き整数，ERと IDの大きい方と同じビット数，負の ID 番号は表現できない）
エラーコードまたは符号無し整数（符号付き整数，ERと UINT の大きい方と同じビット数，符号無し整数の有効ビット数は UINT より 1ビット短い）

ER_ID
ER_UINTTEXPTNFLGPTN
T_MSG
T_MSG_PRI
INHNO
INTNO
EXCNO

タスク例外要因のパターン（符号無し整数，16ビット以上）
イベントフラグのパターン（符号無し整数，16ビット以上）
メールボックスのメッセージヘッダ
メールボックスの優先度付きメッセージヘッダ
割込みハンドラ番号（DEF_INHをサポートする場合）
割込み番号（ATT_ISR をサポートする場合）
CPU例外ハンドラ番号

7.5 パケット形式(1) タスク管理機能
タスク生成情報のパケット形式
typedef struct t_ctsk {ATRtskatr ;VP_INT
exinf ;
FP
task ;
PRI
itskpri ;SIZEstksz ;/* タスク属性 *//* タスクの拡張情報 *//* タスクの起動番地 *//* タスクの起動時優先度 *//* タスクのスタックサイズ（バイト
数）*/
VP
stk ;
/* タスクのスタック領域の先頭番地 *//* 実装独自に他のフィールドを追加してもよい */} T_CTSK ;338

µITRON4.0 仕様

Ver. 4.01.00

タスク状態のパケット形式
typedef struct t_rtsk {STAT
tskstat ;/* タスク状態 */PRI
tskpri ;/* タスクの現在優先度 */PRI
tskbpri ;/* タスクのベース優先度 */STAT
tskwait ; /* 待ち要因 */ID
wobjid ;/* 待ち対象のオブジェクトの ID番号 */TMO
lefttmo ;/* タイムアウトするまでの時間 */UINT
actcnt ;/* 起動要求キューイング数 */UINTwupcnt ; /* 起床要求キューイング数 */UINTsuscnt ;/* 強制待ち要求ネスト数 *//* 実装独自に他のフィールドを追加してもよい */} T_RTSK ;タスク状態（簡易版）のパケット形式
typedef struct t_rtst {STAT
tskstat ;/* タスク状態 */STAT
tskwait ; /* 待ち要因 *//* 実装独自に他のフィールドを追加してもよい */} T_RTST ;(3) タスク例外処理機能
タスク例外処理ルーチン定義情報のパケット形式
typedef struct t_dtex {ATR
texatr ;/* タスク例外処理ルーチン属性 */FP
texrtn ;/* タスク例外処理ルーチンの起動番
地 *//* 実装独自に他のフィールドを追加してもよい */} T_DTEX ;タスク例外処理状態のパケット形式
typedef struct t_rtex {STAT
texstat ;/* タスク例外処理の状態 */TEXPTN
pndptn ; /* 保留例外要因 *//* 実装独自に他のフィールドを追加してもよい */} T_RTEX ;(4) 同期・通信機能
セマフォ生成情報のパケット形式
typedef struct t_csem {ATR
sematr ;/* セマフォ属性 */UINT
isemcnt ; /* セマフォの資源数の初期値 */UINTmaxsem ; /* セマフォの最大資源数 *//* 実装独自に他のフィールドを追加してもよい */} T_CSEM ;セマフォ状態のパケット形式
typedef struct t_rsem {339

µITRON4.0 仕様
ID

Ver. 4.01.00
wtskid ;/* セマフォの待ち行列の先頭のタスクの ID番号 */UINTsemcnt ; /* セマフォの現在の資源数 *//* 実装独自に他のフィールドを追加してもよい */} T_RSEM ;イベントフラグ生成情報のパケット形式
typedef struct t_cflg {ATR
flgatr ;/* イベントフラグ属性 */FLGPTN
iflgptn ;/* イベントフラグのビットパターンの初期値 *//* 実装独自に他のフィールドを追加してもよい */} T_CFLG ;イベントフラグ状態のパケット形式
typedef struct t_rflg {IDwtskid ;/* イベントフラグの待ち行列の先頭のタスクの ID番号 */FLGPTN
flgptn ;/* イベントフラグの現在のビットパ
ターン *//* 実装独自に他のフィールドを追加してもよい */} T_RFLG ;データキュー生成情報のパケット形式
typedef struct t_cdtq {ATR
dtqatr ;/* データキュー属性 */UINT
dtqcnt ;/* データキュー領域の容量（データの
個数）*/
VP
dtq ;
/* データキュー領域の先頭番地 *//* 実装独自に他のフィールドを追加してもよい */} T_CDTQ ;データキュー状態のパケット形式
typedef struct t_rdtq {IDstskid ;/* データキューの送信待ち行列の先頭のタスクの ID番号 */ID
rtskid ;/* データキューの受信待ち行列の先頭のタスクの ID番号 */UINT
sdtqcnt ; /* データキューに入っているデータの数 *//* 実装独自に他のフィールドを追加してもよい */} T_RDTQ ;メールボックス生成情報のパケット形式
typedef struct t_cmbx {ATR
mbxatr ;/* メールボックス属性 */PRI
maxmpri ; /* 送信されるメッセージの優先度の最大値 */VP
mprihd ; /* 優先度別のメッセージキューヘッダ
領域の先頭番地 *//* 実装独自に他のフィールドを追加してもよい */340

µITRON4.0 仕様

Ver. 4.01.00} T_CMBX ;メールボックス状態のパケット形式
typedef struct t_rmbx {ID
wtskid ;/* メールボックスの待ち行列の先頭のタスクの ID番号 */T_MSG * pk_msg ; /* メッセージキューの先頭のメッセー
ジパケットの先頭番地 *//* 実装独自に他のフィールドを追加してもよい */} T_RMBX ;(5) 拡張同期・通信機能
ミューテックス生成情報のパケット形式
typedef struct t_cmtx {ATR
mtxatr ;/* ミューテックス属性 */PRI
ceilpri ;/* ミューテックスの上限優先度 *//* 実装独自に他のフィールドを追加してもよい */} T_CMTX ;ミューテックス状態のパケット形式
typedef struct t_rmtx {IDhtskid ;/* ミューテックスをロックしているタ
スクの ID番号 */ID
wtskid ;/* ミューテックスの待ち行列の先頭のタスクの ID番号 *//* 実装独自に他のフィールドを追加してもよい */} T_RMTX ;メッセージバッファ生成情報のパケット形式
typedef struct t_cmbf {ATR
mbfatr ;/* メッセージバッファ属性 */UINT
maxmsz ; /* メッセージの最大サイズ（バイト
数）*/
SIZE
mbfsz ;/* メッセージバッファ領域のサイズ（バイト数）*/VP
mbf ;/* メッセージバッファ領域の先頭番
地 *//* 実装独自に他のフィールドを追加してもよい */} T_CMBF ;メッセージバッファ状態のパケット形式
typedef struct t_rmbf {IDstskid ;/* メッセージバッファの送信待ち行列の先頭のタスクの ID番号 */ID
rtskid ;/* メッセージバッファの受信待ち行列の先頭のタスクの ID番号 */UINT
smsgcnt ; /* メッセージバッファに入っているメッセージの数 */341

µITRON4.0 仕様
SIZE

Ver. 4.01.00
fmbfsz ;/* メッセージバッファ領域の空き領域のサイズ（バイト数，最低限の管理領域を除く）*//* 実装独自に他のフィールドを追加してもよい */} T_RMBF ;ランデブポート生成情報のパケット形式
typedef struct t_cpor {ATR
poratr ;/* ランデブポート属性 */UINT
maxcmsz ; /* 呼出しメッセージの最大サイズ（バイト数）*/
UINT
maxrmsz ; /* 返答メッセージの最大サイズ（バイト数）*//* 実装独自に他のフィールドを追加してもよい */} T_CPOR ;ランデブポート状態のパケット形式
typedef struct t_rpor {IDctskid ;/* ランデブポートの呼出し待ち行列の先頭のタスクの ID番号 */ID
atskid ;/* ランデブポートの受付待ち行列の先頭のタスクの ID番号 *//* 実装独自に他のフィールドを追加してもよい */} T_RPOR ;ランデブ状態のパケット形式
typedef struct t_rrdv {ID
wtskid ;/* ランデブ終了待ち状態のタスクの ID
番号 *//* 実装独自に他のフィールドを追加してもよい */} T_RRDV ;(6) メモリプール管理機能
固定長メモリプール生成情報のパケット形式
typedef struct t_cmpf {ATR
mpfatr ;/* 固定長メモリプール属性 */UINT
blkcnt ;/* 獲得できるメモリブロック数（個
数）*/
UINT
blksz ;/* メモリブロックのサイズ（バイト
数）*/
VP
mpf ;
/* 固定長メモリプール領域の先頭番
地 *//* 実装独自に他のフィールドを追加してもよい */} T_CMPF ;固定長メモリプール状態のパケット形式
typedef struct t_rmpf {IDwtskid ;/* 固定長メモリプールの待ち行列の先頭のタスクの ID番号 */342

µITRON4.0 仕様
UINT

Ver. 4.01.00
fblkcnt ;/* 固定長メモリプールの空きメモリブ
ロック数（個数）*//* 実装独自に他のフィールドを追加してもよい */} T_RMPF ;可変長メモリプール生成情報のパケット形式
typedef struct t_cmpl {ATR
mplatr ;/* 可変長メモリプール属性 */SIZE
mplsz ;/* 可変長メモリプール領域のサイズ（バイト数）*/VP
mpl ;/* 可変長メモリプール領域の先頭番
地 *//* 実装独自に他のフィールドを追加してもよい */} T_CMPL ;可変長メモリプール状態のパケット形式
typedef struct t_rmpl {IDwtskid ;/* 可変長メモリプールの待ち行列の先頭のタスクの ID番号 */SIZEfmplsz ;/* 可変長メモリプールの空き領域の合計サイズ（バイト数）*/
UINT
fblksz ;/* すぐに獲得可能な最大メモリブロッ
クサイズ（バイト数）*//* 実装独自に他のフィールドを追加してもよい */} T_RMPL ;(7) 時間管理機能
周期ハンドラ生成情報のパケット形式
typedef struct t_ccyc {ATR
cycatr ;/* 周期ハンドラ属性 */VP_INT
exinf ;/* 周期ハンドラの拡張情報 */FP
cychdr ;/* 周期ハンドラの起動番地 */RELTIM
cyctim ;/* 周期ハンドラの起動周期 */RELTIM
cycphs ;/* 周期ハンドラの起動位相 *//* 実装独自に他のフィールドを追加してもよい */} T_CCYC ;周期ハンドラ状態のパケット形式
typedef struct t_rcyc {STAT
cycstat ;/* 周期ハンドラの動作状態 */RELTIM
lefttim ;/* 周期ハンドラを次に起動すべき時刻
までの時間 *//* 実装独自に他のフィールドを追加してもよい */} T_RCYC ;アラームハンドラ生成情報のパケット形式
typedef struct t_calm {ATR
almatr ;/* アラームハンドラ属性 */VP_INT
exinf ;/* アラームハンドラの拡張情報 */FP
almhdr ; /* アラームハンドラの起動番地 */343

µITRON4.0 仕様

Ver. 4.01.00/* 実装独自に他のフィールドを追加してもよい */} T_CALM ;アラームハンドラ状態のパケット形式
typedef struct t_ralm {STAT
almstat ; /* アラームハンドラの動作状態 */RELTIM
lefttim ;/* アラームハンドラの起動時刻までの時間 *//* 実装独自に他のフィールドを追加してもよい */} T_RALM ;オーバランハンドラ定義情報のパケット形式
typedef struct t_dovr {ATR
ovratr ;/* オーバランハンドラ属性 */FP
ovrhdr ;/* オーバランハンドラの起動番地 *//* 実装独自に他のフィールドを追加してもよい */} T_DOVR ;オーバランハンドラ状態のパケット形式
typedef struct t_rovr {STAT
ovrstat ;/* オーバランハンドラの動作状態 */OVRTIM leftotm ;/* 残りのプロセッサ時間 *//* 実装独自に他のフィールドを追加してもよい */} T_ROVR ;(8) システム状態管理機能
システム状態のパケット形式
typedef struct t_rsys {/* 実装独自のフィールドが入る */} T_RSYS ;(9) 割込み管理機能
割込みハンドラ定義情報のパケット形式
typedef struct t_dinh {ATR
inhatr ;/* 割込みハンドラ属性 */FP
inthdr ;/* 割込みハンドラの起動番地 *//* 実装独自に他のフィールドを追加してもよい */} T_DINH ;割込みサービスルーチン生成情報のパケット形式
typedef struct t_cisr {ATR
isratr ;/* 割込みサービスルーチン属性 */VP_INT
exinf ;/* 割込みサービスルーチンの拡張情
報 */
INTNO
intno ;/* 割込みサービスルーチンを付加する
割込み番号 */
FP
isr ;/* 割込みサービスルーチンの起動番
地 *//* 実装独自に他のフィールドを追加してもよい */} T_CISR ;344

µITRON4.0 仕様

Ver. 4.01.00

割込みサービスルーチン状態のパケット形式
typedef struct t_risr {/* 実装独自のフィールドが入る */} T_RISR ;(10) サービスコール管理機能
拡張サービスコール定義情報のパケット形式
typedef struct t_dsvc {ATR
svcatr ;/* 拡張サービスコール属性 */FP
svcrtn ;/* 拡張サービスコールルーチンの起動
番地 *//* 実装独自に他のフィールドを追加してもよい */} T_DSVC ;(11) システム構成管理機能
CPU例外ハンドラ定義情報のパケット形式
typedef struct t_dexc {ATR
excatr ;/* CPU 例外ハンドラ属性 */FP
exchdr ;/* CPU 例外ハンドラの起動番地 *//* 実装独自に他のフィールドを追加してもよい */} T_DEXC ;コンフィギュレーション情報のパケット形式
typedef struct t_rcfg {/* 実装独自のフィールドが入る */} T_RCFG ;バージョン情報のパケット形式
typedef struct t_rver {UHmaker ;UH
prid ;UH
spver ;UH
prver ;
UHprno[4] ;} T_RVER ;/* カーネルのメーカコード *//* カーネルの識別番号 *//* ITRON 仕様のバージョン番号 *//* カーネルのバージョン番号 *//* カーネル製品の管理情報 */7.6 定数とマクロ(1) 一般NULL

0

無効ポインタ

TRUE
FALSE

1
0

真
偽

E_OK

0

正常終了

345

µITRON4.0 仕様

Ver. 4.01.00(2) オブジェクト属性
TA_NULL

0

オブジェクト属性を指定しない

TA_HLNG
TA_ASM

0x00
0x01

高級言語用のインタフェースで処理単位を起動
アセンブリ言語用のインタフェースで処理単位
を起動

TA_TFIFO
TA_TPRI

0x00
0x01

タスクの待ち行列を FIFO 順に
タスクの待ち行列をタスクの優先度順に

TA_MFIFO
TA_MPRI

0x00
0x02

メッセージのキューを FIFO 順に
メッセージのキューをメッセージの優先度順に

TA_ACT
TA_RSTR

0x02
0x04

タスクを起動された状態で生成
制約タスク

TA_WSGL

0x00

TA_WMUL

0x02

TA_CLR

0x04

イベントフラグを複数のタスクが待つことを許さない
イベントフラグを複数のタスクが待つことを許す
待ち解除時にイベントフラグをクリア

TA_INHERIT

0x02

TA_CEILING

0x03

TA_STA
TA_PHS

0x02
0x04

周期ハンドラを動作している状態で生成
周期ハンドラの位相を保存

0
–1
–2

ポーリング
永久待ち
ノンブロッキング

ミューテックスが優先度継承プロトコルをサ
ポート
ミューテックスが優先度上限プロトコルをサ
ポート(3) タイムアウト指定
TMO_POL
TMO_FEVRTMO_NBLK(4) サービスコールの動作モード
TWF_ANDWTWF_ORW

0x00
0x01

イベントフラグの AND 待ち
イベントフラグの OR待ち

(5) オブジェクトの状態
TTS_RUNTTS_RDY
TTS_WAITTS_SUSTTS_WAS

0x01
0x02
0x04
0x08
0x0c

実行状態
実行可能状態
待ち状態
強制待ち状態
二重待ち状態346

µITRON4.0 仕様

Ver. 4.01.00

TTS_DMT

0x10

TTW_SLPTTW_DLY
TTW_SEM
TTW_FLG
TTW_SDTQ
TTW_RDTQ
TTW_MBX
TTW_MTX
TTW_SMBF
TTW_RMBF
TTW_CAL
TTW_ACP
TTW_RDVTTW_MPF
TTW_MPL

0x00010x00020x00040x00080x00100x00200x00400x00800x01000x02000x04000x08000x10000x20000x4000

TTEX_ENATTEX_DIS

0x00
0x01

タスク例外処理許可状態
タスク例外処理禁止状態

TCYC_STP
TCYC_STA

0x00
0x01

周期ハンドラが動作していない
周期ハンドラが動作している

TALM_STPTALM_STA

0x00
0x01

アラームハンドラが動作していない
アラームハンドラが動作している

TOVR_STPTOVR_STA

0x00
0x01

上限プロセッサ時間が設定されていない
上限プロセッサ時間が設定されている

TSK_SELF
TSK_NONE00

自タスク指定該当するタスクが無い

TPRI_SELF
TPRI_INI

00

自タスクのベース優先度の指定
タスクの起動時優先度の指定

休止状態
起床待ち状態
時間経過待ち状態
セマフォ資源の獲得待ち状態
イベントフラグ待ち状態
データキューへの送信待ち状態
データキューからの受信待ち状態
メールボックスからの受信待ち状態
ミューテックスのロック待ち状態
メッセージバッファへの送信待ち状態
メッセージバッファからの受信待ち状態
ランデブの呼出し待ち状態
ランデブの受付待ち状態
ランデブの終了待ち状態
固定長メモリブロックの獲得待ち状態
可変長メモリブロックの獲得待ち状態(6) その他の定数(7) マクロER ercd = ERCD ( ER mercd, ER sercd )メインエラーコードとサブエラーコードからエラーコードを生成する．
ER mercd = MERCD ( ER ercd )エラーコードからメインエラーコードを取り出す．

347

µITRON4.0 仕様

Ver. 4.01.00

ER sercd = SERCD ( ER ercd )エラーコードからサブエラーコードを取り出す．

7.7 構成定数とマクロ(1) 優先度の範囲
TMIN_TPRI
TMAX_TPRI

タスク優先度の最小値（＝ 1）
タスク優先度の最大値

TMIN_MPRI
TMAX_MPRI

メッセージ優先度の最小値（＝ 1）
メッセージ優先度の最大値(2) バージョン情報
TKERNEL_MAKER
TKERNEL_PRID
TKERNEL_SPVER
TKERNEL_PRVER

カーネルのメーカコード
カーネルの識別番号
ITRON仕様のバージョン番号
カーネルのバージョン番号(3) キューイング／ネスト回数の最大値
TMAX_ACTCNTTMAX_WUPCNTTMAX_SUSCNT

タスクの起動要求キューイング数の最大値
タスクの起床要求キューイング数の最大値
タスクの強制待ち要求ネスト数の最大値(4) ビットパターンのビット数
TBIT_TEXPTN
TBIT_FLGPTNTBIT_RDVPTN

タスク例外要因のビット数
イベントフラグのビット数
ランデブ条件のビット数(5) タイムティックの周期
TIC_NUME
TIC_DENO

タイムティックの周期の分子
タイムティックの周期の分母(6) 必要なメモリ領域のサイズ
SIZE dtqsz = TSZ_DTQ ( UINT dtqcnt )dtqcnt個のデータを格納するのに必要なデータキュー領域のサイズ（バイト数）
SIZE mprihdsz = TSZ_MPRIHD ( PRI maxmpri )送信されるメッセージの優先度の最大値が maxmpri のメールボックスに必要な優先度別メッセージキューヘッダ領域のサイズ（バイト数）
348

µITRON4.0 仕様

Ver. 4.01.00

SIZE mbfsz = TSZ_MBF ( UINT msgcnt, UINT msgsz )サイズが msgsz バイトのメッセージを msgcnt個バッファリングするのに必要なメッセージバッファ領域のサイズ（目安のバイト数）
SIZE mpfsz = TSZ_MPF ( UINT blkcnt, UINT blksz )サイズが blkszバイトのメモリブロックを blkcnt個獲得できるのに必要な固定長メモリプール領域のサイズ（バイト数）
SIZE mplsz = TSZ_MPL ( UINT blkcnt, UINT blksz )サイズが blkszバイトのメモリブロックを blkcnt個獲得できるのに必要な可変長メモリプール領域のサイズ（目安のバイト数）(7) その他
TMAX_MAXSEM

セマフォの最大資源数の最大値

7.8 エラーコード一覧
E_SYS
E_NOSPT
E_RSFN
E_RSATR
E_PAR
E_ID
E_CTX
E_MACV
E_OACV
E_ILUSE
E_NOMEM
E_NOID
E_OBJ
E_NOEXSE_QOVR
E_RLWAIE_TMOUT
E_DLT
E_CLS
E_WBLK
E_BOVR

–5
–9
–10
–11
–17
–18
–25
–26
–27
–28
–33
–34
–41
–42
–43
–49
–50
–51
–52
–57
–58

システムエラー
未サポート機能
予約機能コード
予約属性
パラメータエラー
不正 ID番号
コンテキストエラー
メモリアクセス違反
オブジェクトアクセス違反
サービスコール不正使用
メモリ不足
ID番号不足オブジェクト状態エラー
オブジェクト未生成
キューイングオーバフロー
待ち状態の強制解除
ポーリング失敗またはタイムアウト
待ちオブジェクトの削除
待ちオブジェクトの状態変化
ノンブロッキング受付け
バッファオーバフロー

349

µITRON4.0 仕様

Ver. 4.01.00

7.9 機能コード一覧
–0

–1

–2

–3

–0x01
–0x05
–0x09
–0x0d
–0x11
–0x15
–0x19
–0x1d
–0x21
–0x25
–0x29
–0x2d
–0x31
–0x35
–0x39
–0x3d
–0x41
–0x45
–0x49
–0x4d
–0x51
–0x55
–0x59

予約
cre_tsk
sta_tsk
chg_prislp_tsk
rel_wai
dly_tsk
dis_texcre_sem
wai_sem
cre_flg
wai_flg
cre_dtq
snd_dtq
rcv_dtq
cre_mbx
rcv_mbx
cre_mpf
get_mpf
set_timsta_cycrot_rdq
loc_cpu

予約
del_tsk
ext_tsk
get_pritslp_tsk
sus_tsk
予約
ena_texdel_sem
pol_sem
del_flg
pol_flg
del_dtq
psnd_dtq
prcv_dtq
del_mbx
prcv_mbx
del_mpf
pget_mpf
get_tim
stp_cyc
get_tid
unl_cpu

予約
act_tsk
exd_tsk
ref_tsk
wup_tsk
rsm_tsk
def_texsns_texsig_sem
twai_sem
set_flg
twai_flg

予約
can_act
ter_tsk
ref_tstcan_wupfrsm_tsk
ras_tex
ref_tex予約
tsnd_dtq
trcv_dtq
snd_mbx
trcv_mbx
rel_mpf
tget_mpf
cre_cyc
ref_cyc

予約
fsnd_dtq
ref_dtq–0x5d

sns_ctx

–0x61
–0x65
–0x69
–0x6d
–0x71
–0x75
–0x79
–0x7d
–0x81
–0x85
–0x89
–0x8d

ref_sys
def_inh
dis_int
def_svc
iact_tsk
isig_sem
irot_rdq
isig_tim
cre_mtx
loc_mtx
cre_mbf
snd_mbf

予約
ref_sem
clr_flg
ref_flg

予約
ref_mbx
予約
ref_mpf
del_cyc予約
dis_dsp

予約
予約
ena_dspsns_loc

sns_dspsns_dpn

予約
cre_isr
ena_int
def_exc
iwup_tsk
iset_flg
iget_tid

予約
del_isr
chg_ixx
ref_cfg
irel_wai
ipsnd_dtq
iloc_cpu

予約
ref_isr
get_ixx
ref_veriras_tex
ifsnd_dtq
iunl_cpu

予約
del_mtx
ploc_mtx
del_mbf
psnd_mbf

予約
unl_mtxtloc_mtx

予約
予約
ref_mtx

予約
tsnd_mbf

予約
予約

350

µITRON4.0 仕様
–0x91
–0x95
–0x99
–0x9d
–0xa1
–0xa5
–0xa9
–0xad
–0xb1
–0xb5
–0xb9
–0xbd
–0xc1
–0xc5
–0xc9
–0xcd
–0xd1
–0xd5
–0xd9
–0xdd
–0xe1
–0xe5
–0xe9
–0xed
–0xf1
–0xf5
–0xf9
–0xfd

Ver. 4.01.00
rcv_mbf
cre_por
acp_por
rpl_rdv
cre_mplget_mplcre_alm
ref_alm
def_ovr

prcv_mbf
del_por
pacp_por
ref_pordel_mplpget_mpl
del_alm

trcv_mbf
cal_por
tacp_por
ref_rdv
rel_mpltget_mpl
sta_alm

ref_mbftcal_por
fwd_por予約
sta_ovr

予約
stp_ovr

予約
ref_ovr

予約
予約
予約
acre_tsk
acre_mbx
acre_mpf
acre_isr

予約
予約
予約
acre_sem
acre_mtx
acre_mpl

予約
予約
予約
acre_flg
acre_mbf
acre_cyc

予約
予約
予約
acre_dtq
acre_poracre_alm

予約
予約
予約
予約

予約
予約
予約
予約
予約
予約
予約
予約
予約
予約
実装独自のサービスコール
実装独自のサービスコール
実装独自のサービスコール
実装独自のサービスコール
実装独自のサービスコール
実装独自のサービスコール
実装独自のサービスコール
実装独自のサービスコール

351

予約
予約
ref_mplstp_alm

予約
予約
予約
予約
予約

µITRON4.0 仕様

Ver. 4.01.00

352

µITRON4.0 仕様

Ver. 4.01.00

索引
この索引は，µITRON4.0 仕様の本体（第 2 章〜第 5 章）で用いている用語の索引で，用語が定義または説明されているページを参照するものである．
A
API ...........................................................................................................................24
C
CPU例外ハンドラ .........................................................................................60, 301
CPUロック解除状態 .............................................................................................64
CPUロック状態 .....................................................................................................64
F
FCFS ........................................................................................................................55
I
ID番号（オブジェクトの）...................................................................................26
IRC ..........................................................................................................................57
ITRON仕様共通規定 .............................................................................................23
ITRON仕様共通静的 API ......................................................................................50
ITRON仕様共通定数 .............................................................................................45
ITRON仕様共通データ型 .....................................................................................43
ITRON仕様共通マクロ .........................................................................................49
T
TCB .......................................................................................................................120
あアラームハンドラ ...............................................................................................255
い一般定数式パラメータ .........................................................................................36
イベントフラグ ...................................................................................................139
え
エラークラス .........................................................................................................28
エラーコード .........................................................................................................28
おオーバランハンドラ ...........................................................................................263
オブジェクト .........................................................................................................26
オブジェクト状態エラークラス .........................................................................47
オブジェクト属性 .................................................................................................30353

µITRON4.0 仕様

Ver. 4.01.00

オブジェクト番号 .................................................................................................26
かカーネル構成定数 .................................................................................................76
カーネル構成マクロ .............................................................................................76
カーネルの管理外の割込み .................................................................................58
返値（サービスコールの）...................................................................................28
拡張サービスコール ...........................................................................................296
拡張サービスコールルーチン .....................................................................62, 296
拡張情報 .................................................................................................................30
可変長メモリプール ...........................................................................................229
簡略化した優先度制御規則 ...............................................................................175
き
起床待ち状態 .......................................................................................................106
起床要求キューイング数 ...................................................................................104
起動（タスクの）...................................................................................................53
起動コード（タスクの）.......................................................................................81
起動された状態 .....................................................................................................53
起動要求キューイング数 .....................................................................................81
機能コード .............................................................................................................28
キューイング（タスクに対する起床要求の）.................................................104
キューイング（タスクに対する起動要求の）...................................................81
休止状態 .................................................................................................................53
強制待ち状態 .........................................................................................................52
強制待ち要求ネスト数 .......................................................................................104
け
警告クラス .............................................................................................................48
現在優先度 .............................................................................................................81
厳密な優先度制御規則 .......................................................................................175こ
広義の待ち状態 .....................................................................................................52
コールバック .........................................................................................................24
固定長メモリプール ...........................................................................................219
コンテキスト .........................................................................................................51
コンフィギュレータ .............................................................................................32
さ
サービスコール .....................................................................................................24
再開（強制待ちからの）.......................................................................................53
削除（オブジェクトの）.......................................................................................74354

µITRON4.0 仕様

Ver. 4.01.00

サブエラーコード .................................................................................................28
サブセット化（サービスコールの機能の）.....................................................309
し時間経過待ち状態 ...............................................................................................116
資源不足エラークラス .........................................................................................47
システムオブジェクト .........................................................................................27
システムコール .....................................................................................................24
システムコンフィギュレーションファイル .....................................................32
システム時刻 .................................................................................................32, 240
自タスク .................................................................................................................51
実行可能状態 .........................................................................................................52
実行状態 .................................................................................................................52
実行できる状態 .....................................................................................................52
実時刻 .....................................................................................................................32
実装依存 .................................................................................................................23
実装定義 .................................................................................................................23
実装独自 .................................................................................................................23
自動車制御用プロファイル ...............................................................................312
自動割付け（コンフィギュレータによる）.......................................................36
自動割付け（サービスコールによる）...............................................................74
自動割付け結果ヘッダファイル .........................................................................26
自動割付け対応整数値パラメータ .....................................................................36
自動割付け非対応整数値パラメータ .................................................................36
周期ハンドラ .......................................................................................................245
終了（タスクの）...................................................................................................53
上限プロセッサ時間 ...........................................................................................263
状態遷移（タスクの）...........................................................................................53
使用プロセッサ時間 ...........................................................................................263
初期化ルーチン .............................................................................................74, 301
処理単位 .................................................................................................................61
す推移的な優先度継承 ...........................................................................................175
スケジューラ .........................................................................................................51
スケジューリング .................................................................................................51
スケジューリング規則 .........................................................................................55
スタンダードプロファイル ...............................................................................310
せ制限（サービスコールの機能の）.....................................................................309
整数値パラメータ .................................................................................................37355

µITRON4.0 仕様

Ver. 4.01.00

生成（オブジェクトの）.................................................................................26, 74
静的 API ..................................................................................................................24
静的 APIの処理 ......................................................................................................73
制約タスク ...........................................................................................................312
セマフォ ...............................................................................................................130
そ
相対時間 .................................................................................................................32
ソフトウェア部品識別名 .....................................................................................38
た大域脱出 ...............................................................................................................119
タイムアウト .........................................................................................................30
タイムイベントハンドラ .............................................................................61, 240
タイムティック ...................................................................................................240
タスク .....................................................................................................................51
タスクコンテキスト .............................................................................................62
タスクコンテキスト専用のサービスコール .....................................................70
タスク状態 .............................................................................................................52
タスクスケジューラ .............................................................................................51
タスクスケジューリング .....................................................................................51
タスクディスパッチ .............................................................................................51
タスクディスパッチャ .........................................................................................51
タスク例外処理許可状態 ...................................................................................117
タスク例外処理禁止状態 ...................................................................................117
タスク例外処理ルーチン .............................................................................60, 117
タスク例外要因 ...................................................................................................117
ち
遅延実行（サービスコールの）...........................................................................71
つ追加（オブジェクトの）.......................................................................................74て定義（オブジェクトの）.......................................................................................27
定数 .........................................................................................................................25
ディスパッチ .........................................................................................................51
ディスパッチ許可状態 .........................................................................................66
ディスパッチ禁止状態 .........................................................................................66
ディスパッチ保留状態 .........................................................................................68
ディスパッチャ .....................................................................................................51
出入口処理（CPU 例外ハンドラの）...................................................................60356

µITRON4.0 仕様

Ver. 4.01.00

出入口処理（割込みハンドラの）.......................................................................57
データ型 .................................................................................................................25
データキュー .......................................................................................................151と登録（オブジェクトの）.......................................................................................26
な
内部エラークラス .................................................................................................46
内部識別子 .............................................................................................................43に二重待ち状態 .........................................................................................................52ね
ネスト（タスクに対する強制待ち要求の）.....................................................104のノンブロッキング .................................................................................................31
はパケット .................................................................................................................25
パラメータ .............................................................................................................25
パラメータエラークラス .....................................................................................46
ひ引数 .........................................................................................................................25
非タスクコンテキスト .........................................................................................62
非タスクコンテキスト専用のサービスコール .................................................69
ふ
不可分性（サービスコールの）...........................................................................64
プリエンプト .........................................................................................................53
プリプロセッサ定数式パラメータ .....................................................................36
プロファイル規定 ...............................................................................................309
へ
ベース優先度 .........................................................................................................81
ヘッダファイル .....................................................................................................26
返答メッセージ（ランデブの）.........................................................................198
ほ
ポーリング .............................................................................................................31
保留例外要因 .......................................................................................................117357

µITRON4.0 仕様

Ver. 4.01.00

まマクロ .....................................................................................................................26
待ち解除 .................................................................................................................53
待ち解除エラークラス .........................................................................................48
待ち状態 .................................................................................................................52
み未サポートエラークラス .....................................................................................46
未定義 .....................................................................................................................23
未登録状態 .............................................................................................................53
ミューテックス ...................................................................................................174め
メインエラーコード .......................................................................................28, 46
メールボックス ...................................................................................................163
メッセージパケット ...........................................................................................163
メッセージバッファ ...........................................................................................185
メッセージヘッダ ...............................................................................................163
メモリプール .......................................................................................................219
ゆユーザオブジェクト .............................................................................................27
優先順位 .................................................................................................................51
優先順位（処理単位の）.......................................................................................63
優先順位（タスクの）...........................................................................................55
優先度 .....................................................................................................................27
優先度（タスクの）...............................................................................................81
優先度逆転 ...........................................................................................................174
優先度継承プロトコル .......................................................................................174
優先度上限プロトコル .......................................................................................174
よ呼出しコンテキストエラークラス .....................................................................46
呼出しメッセージ（ランデブの）.....................................................................198
弱い標準化 ...........................................................................................................309
らラウンドロビン方式 .....................................................................................55, 272
ランデブ ...............................................................................................................198
ランデブポート ...................................................................................................198り
リターンパラメータ .............................................................................................25358

µITRON4.0 仕様

Ver. 4.01.00

わ
割込み .....................................................................................................................57
割込みサービスルーチン .............................................................................57, 283
割込み番号 .............................................................................................................59
割込みハンドラ .............................................................................................57, 283
割込みハンドラ番号 .............................................................................................59359