＝ TOPPERS/JSPカーネル ユーザズマニュアル ＝ （Release 1.4.4対応，最終更新: 29-Dec-2010） ※ このユーザズマニュアルは，μITRON4.0仕様書（Ver. 4.02.00）の内容を 前提に記述してあります．μITRON4.0仕様書は，以下のURLからダウンロード することができます． http://www.ertl.jp/ITRON/SPEC/mitron4-j.html ---------------------------------------------------------------------- TOPPERS/JSP Kernel Toyohashi Open Platform for Embedded Real-Time Systems/ Just Standard Profile Kernel Copyright (C) 2000-2003 by Embedded and Real-Time Systems Laboratory Toyohashi Univ. of Technology, JAPAN Copyright (C) 2004-2007 by Embedded and Real-Time Systems Laboratory Graduate School of Information Science, Nagoya Univ., JAPAN 上記著作権者は，以下の (1)〜(4) の条件か，Free Software Foundation によって公表されている GNU General Public License の Version 2 に記 述されている条件を満たす場合に限り，本ソフトウェア（本ソフトウェア を改変したものを含む．以下同じ）を使用・複製・改変・再配布（以下， 利用と呼ぶ）することを無償で許諾する． (1) 本ソフトウェアをソースコードの形で利用する場合には，上記の著作 権表示，この利用条件および下記の無保証規定が，そのままの形でソー スコード中に含まれていること． (2) 本ソフトウェアを，ライブラリ形式など，他のソフトウェア開発に使 用できる形で再配布する場合には，再配布に伴うドキュメント（利用 者マニュアルなど）に，上記の著作権表示，この利用条件および下記 の無保証規定を掲載すること． (3) 本ソフトウェアを，機器に組み込むなど，他のソフトウェア開発に使 用できない形で再配布する場合には，次のいずれかの条件を満たすこ と． (a) 再配布に伴うドキュメント（利用者マニュアルなど）に，上記の著 作権表示，この利用条件および下記の無保証規定を掲載すること． (b) 再配布の形態を，別に定める方法によって，TOPPERSプロジェクトに 報告すること． (4) 本ソフトウェアの利用により直接的または間接的に生じるいかなる損 害からも，上記著作権者およびTOPPERSプロジェクトを免責すること． 本ソフトウェアは，無保証で提供されているものである．上記著作権者お よびTOPPERSプロジェクトは，本ソフトウェアに関して，その適用可能性も 含めて，いかなる保証も行わない．また，本ソフトウェアの利用により直 接的または間接的に生じたいかなる損害に関しても，その責任を負わない． @(#) $Id: user.txt,v 1.90 2007/05/28 02:06:45 honda Exp $ ---------------------------------------------------------------------- * μITRON4.0仕様は，トロン協会が中心となって策定されたオープンなリア ルタイムカーネル仕様です．μITRON4.0仕様の仕様書は，トロン協会のホー ムページ（http://www.assoc.tron.org/）から入手することができます． ---------------------------------------------------------------------- * TRON は "The Real-time Operating system Nucleus" の略称です． * ITRON は "Industrial TRON" の略称です． * μITRON は "Micro Industrial TRON" の略称です． * TRON，ITRON，およびμITRONは，特定の商品ないしは商品群を指す名称で はありません． * TOPPERS は "Toyohashi OPen Platform for Embedded Real-time Systems" の略称，JSP は "Just Standard Profile" の略称です． * 本マニュアル中の商品名は，各社の商標または登録商標です． ---------------------------------------------------------------------- １．TOPPERS/JSPカーネルの概要 TOPPERS/JSPカーネル（以下，単にJSPカーネルと書く）は，TOPPERSプロジェ クトにおいて開発したμITRON4.0仕様に準拠したリアルタイムカーネルである． JSP（Just Standard Profile）の名前が示す通り，μITRON4.0仕様のスタンダ ードプロファイル規定に従って実装されている． 1.1 ターゲットプロセッサ／ターゲットシステム JSPカーネルは，現時点で，以下のターゲットプロセッサ／ターゲットシステ ムをサポートしている． ディレクトリ名 開発環境 プロセッサ（型番） システム（メーカ名） m68k GNU開発環境 M68040（MC68LC040） DVE-68K/40（電産） sh1 GNU開発環境 SH1（SH7032） KZ-SH1-01（京都マイクロコンピュータ） ※ RISC評価キットSH-1（CQ出版）でも動作 SH1（SH7034） μITRON搭載SH1CPUボード（(株)中央製作所） sh2 GNU開発環境 SH2(SH7145) AP_SH2F_6A（アルファプロジェクト） SH2(SH7615) HSB7615IT （北斗電子） sh3 GNU開発環境 SH3（SH7709A） MS7709ASE01 （日立超LSIシステムズ） SH3（SH7729R） MS7729RSE01 （日立超LSIシステムズ） SH3（SH7727） MS7727CP01 （日立超LSIシステムズ） SH4（SH7750） MS7750SE01 （日立超LSIシステムズ） sh3-ghs GHS開発環境 SH3（SH7709A） MS7709ASE01 （日立超LSIシステムズ） SH3（SH7727） MS7727CP01 （日立超LSIシステムズ） h8 GNU開発環境 H8（H8/3052F） AKI-H8/3052F（秋月電子通商） H8（H8/3069F） AKI-H8/3069F（秋月電子通商） h8-renesas Renesas社の開発環境 H8(HSB8F3048BF25) H8/3048F-ONEスタータキット((株)北斗電子) h8s-renesas Renesas社の開発環境 H8S(H8S/2339F) MiNET-H8S/2339F（株式会社ミスポ製） armv4 GNU開発環境 ARM9（ARM922T） Integrator/AP+CM922T（ARM） ARM9（ARM926EJ-S） AZ9360MB（YDK） armv4-ghs GHS開発環境 ARM9 （ARM920T） Integrator/AP+CM920T（ARM） ARM9E（ARM966E-S） Integrator/AP+CM966E-S（ARM） m32r GNU開発環境 M32R（M32102S6FP） M3A-2131G50（三菱電機） M32R（M32102S6FP） M3A-ZA36 （三菱電機） m32c-renesas Renesas社の開発環境 M32C OAKS32（オークス電子） microblaze GNU開発環境 MicroBlaze MIREF（YDK） MicroBlaze MIRE_MULTI3000（YDK） MicroBlaze MultiMedia Board（Xilinx） MicroBlaze Suzaku(アットマークテクノ) tms320c54x TI社の開発環境 TMS320C54x（TSM320C5402）TMS320VC5402 DSK（TI） xstormy16 GNU開発環境 Xstormy16 三洋マイコン開発ツール（三洋電機） m16c-renesas Renesas社の開発環境 M16C（M30620FCAFP-CPU） OASKS16（オークス電子） M16C（M30262F8FG-CPU） OAKS16-MINI（オークス電子） s1c33 GNU開発環境 SC33 DMT33209（EPSON） SC33 LUXUN2（EPSON） s1c33-gnu33 GNU33開発環境 SC33 DMT33209（EPSON） SC33 LUXUN2（EPSON） nios2 GNU開発環境 Nios2 NiosII Development Board（アルテラ） v850 GNU開発環境 V850 TK-850/KJ1+ (Application Corp.) V850 TK-850/SG2 (Application Corp.) tlcs900 東芝セミコンダクタ社製の開発環境 TMP91CY22-CPU Zup-F16拡張ボード(タマデン工業株式会社) また，以下のターゲットは，以前のバージョン(1.4.1)のコードからアップデ ートされておらず，動作確認を行っていないため，1.4.2以降では，参考実装 扱いとする． h8 GNU開発環境 H8（H8/3048F） AKI-H8/3048F（秋月電子通商） H8 (H8/3069F) NKEV-010H8 (品川通信計装サービス) h8s GNU開発環境 H8S（2350） H8S/2350 評価ボード(ミスポ) powerpc32 GNU開発環境 PowerPC32（MPC860T） TB6102S（タンバック） mips3 GNU開発環境 MIPS3（VR4131） KZ-Vr4131PCI-01（京都マイクロコンピュータ） MIPS3（VR5500） RTE-VR5500-CB(64)（マイダス・ラボ） JSPカーネルは，カーネルのできる限り多くの部分をC言語で記述する，ターゲッ ト非依存部と依存部を明確に分離するなど，他のターゲットプロセッサへのポ ーティングが容易な構造になっている．ただし，ポーティングにどの程度の手 間がかかるかは，ターゲットプロセッサのアーキテクチャやシステムの構成な どに依存する． このユーザズマニュアルでは，ターゲット（ターゲットプロセッサおよびター ゲットシステム）に依存しない機能についてのみ説明している．ターゲットに 依存する機能については，ターゲット毎のマニュアルを参照すること． 1.2 開発環境 JSPカーネルは，GCCなどのGNU開発環境を標準のソフトウェア開発環境として いるが，他の種類の開発環境も利用できるように考慮している．利用できる開 発環境については，ターゲット毎または開発環境毎のマニュアルで説明する． ターゲット非依存部は，大部分は標準的なC言語によって記述されているが， 性能と可読性を両立させるために，一部でインライン関数を用いている．イン ライン関数の機能を持たない開発環境の場合でも，改造なしに対応可能ではあ るが，非効率／無駄なコードが生成されるおそれがある． カーネル本体は，外部のライブラリ関数に依存しないように記述している．た だし，コンパイラが標準Cライブラリ関数を呼び出すコードを生成する場合が あり，その場合には標準Cライブラリが必要である．また，システムサービス やサポートライブラリ，アプリケーションプログラムで標準Cライブラリが必 要になる場合も考えられる．実際，標準配布キットに含まれる中で，システム ログ機能を呼び出すためのライブラリ関数内で，可変数引数を処理するための 機能（stdarg.h, va_list, va_start, va_arg）を用いている（実際には，GNU 開発環境では，可変数引数を処理するための機能はGCC本体でサポートしてい るため，標準Cライブラリは必要ない）．これらの理由により，標準Cライブラ リを用いる構成もとれるようにしている． 1.3 シミュレーション環境 JSPカーネルのシミュレーション環境として，Linux上で動作する環境と Windows上で動作する環境を用意している．これらのシミュレーション環境は， LinuxおよびWindowsの一つのプロセスの中で複数のタスクを切り替えて動作さ せるもので，スレッドライブラリとして使うこともできる． これらのシミュレーション環境についての詳細は，シミュレーション環境毎の マニュアルを参照すること． 1.4 カーネルがサポートする機能 JSPカーネルは，名前が示す通り，μITRON4.0仕様のスタンダードプロファイ ルに含まれる機能をすべてサポートしている．スタンダードプロファイルでは， 割込みハンドラと割込みサービスルーチンのいずれかをサポートすればよいが， JSPカーネルは，現状では割込みハンドラのみをサポートしている． スタンダードプロファイルに含まれない機能として，ターゲット依存に以下の 割込み管理機能およびサービスコールをサポートする場合がある．これらの機 能の具体的な内容については，ターゲット毎に異なる．詳しくは，ターゲット 毎のマニュアルを参照すること． dis_int 割込みの禁止 ena_int 割込みの許可 chg_ixx 割込みマスクの変更 get_ixx 割込みマスクの参照 ※ xx はターゲット毎に定められる． また，μITRON4.0仕様に定義されている以外に，以下の独自の拡張機能および サービスコールをサポートしている． (1) CPU例外発生時のシステム状態の参照 スタンダードプロファイルでは，CPU例外ハンドラ内で，CPU例外が発生したコ ンテキストや状態を参照できることが必要であるが，そのためのAPIは定めて いない．JSPカーネルでは，CPU例外が発生した処理でsns_yyyを呼び出した場 合の結果を，CPU例外ハンドラ内で取り出せるようにするために，以下の五つ のサービスコールを独自にサポートしている． vxsns_ctx CPU例外発生時のコンテキストの参照 vxsns_loc CPU例外発生時のCPUロック状態の参照 vxsns_dsp CPU例外発生時のディスパッチ禁止状態の参照 vxsns_dpn CPU例外発生時のディスパッチ保留状態の参照 vxsns_tex CPU例外発生時のタスク例外処理禁止状態の参照 (2) 性能評価用システム時刻参照機能 性能評価用システム時刻参照機能とは，JSPカーネル上で動作するタスクやJSP カーネル自身の性能を計測するための，システム時刻をμ秒単位で読み出す機 能である．この機能のために追加したサービスコールは次の通りである． vxget_tim 性能評価用システム時刻の参照 性能評価用システム時刻参照機能をサポートするかどうかは，ターゲット依存 部の定義ファイルで指定することができる．また，ターゲットシステムの制限 により，この機能をサポートできない場合もある． (3) 終了処理ルーチン機能 JSPカーネルでは，システムの終了時に呼び出される終了処理ルーチンを登録 するための機能をサポートしている．この機能のために追加した静的APIは次 の通りである． VATT_TER 終了処理ルーチンの追加（静的API） 終了処理ルーチンについては，「2.12 システム終了手順と終了処理ルーチン」 を参照のこと． (4) カーネル動作状態の参照 カーネル上で動作するタスクから呼び出される関数が，カーネルの初期化完了 前や終了処理開始後にも呼び出される可能性がある場合には，その中でカーネ ルのサービスコールを呼び出せるかを判別することが必要となる．JSPカーネ ルでは，この判別を可能にするために，次のサービスコールを追加している． vsns_ini カーネル動作状態の参照 1.5 既知の問題点 現バージョンでは，静的APIの処理中のエラーの検出機能の中で，ターゲット 依存のエラーの検出が不十分である．例えば，割込みハンドラ番号が不正な値 である場合，カーネルとコンフィギュレータのいずれもエラーを検出せず，カー ネルが正しく動作しない結果となる． kernel_cfg.cは，カーネル，システムサービス，アプリケーションのいずれの インクルードファイルもインクルードし，いずれのシンボルも参照する可能性 がある．そのため，カーネル，システムサービス，アプリケーションでシンボ ル等が衝突している場合や，コンパイルオプションが食い違っている場合に， kernel_cfg.cが正しくコンパイルできなくなる場合が考えられる．カーネルの シンボルをリネームするなどの方法でかなり軽減されてはいるが，問題がなく なっているわけではない． シリアルインタフェースドライバで，シリアルポートをクローズした後にオー プンしなおした場合に，正しく動作しない．これは，シリアルインタフェース ドライバが使用しているセマフォが初期化されないためである． 1.6 注意事項 CRE_DTQのパラメータdtqcntは，μITRON4.0仕様のVer. 4.01.00では一般定数 式パラメータと規定されているが，JSPカーネルではVer. 4.02.00に準拠して， プリプロセッサ定数式パラメータと扱っている． ２．JSPカーネルの機能 この節では，μITRON4.0仕様で実装定義となっている事項を中心に，JSPカー ネルの機能について解説する． 2.1 実装方針とモデル μITRON4.0仕様のスタンダードプロファイルは，システム全体を一つのモジュー ルにリンクすることを想定して規定されている．また，サービスコールの呼出 しは，単なるサブルーチンコールによって行うことが想定されている．JSPカー ネルは，この想定に従い，アプリケーションとカーネルを一つのモジュールに リンクし，サブルーチンコールによってサービスコールを呼び出す方法のみを サポートしている． JSPカーネル上で動作するアプリケーションは，すべてC言語で記述することを 原則としている．そのため，タスクや割込みハンドラなどの処理単位をアセン ブリ言語で記述する方法は，特別には用意していない（もちろん，インタフェー スさえC言語の関数にあわせれば，記述にアセンブリ言語を使うことは問題な い）． JSPカーネルでは，サービスコールの大部分を一つの割込み禁止区間として実 装しているため，サービスコールの不可分性は厳密に保証される．逆に欠点と しては，最大割込み禁止時間（最大割込み応答時間も同様）が，待ちキューに つながれるタスクの最大数やタイムイベントの最大数に依存することになるが， スタンダードプロファイルの機能セットの範囲内では，この方法でもそれほど 問題にならないと思われる． 2.2 データ型 JSPカーネルでは，以下にリストアップするデータ型を，signed int型， unsigned int型，またはsize_t型に定義している．これらの型のサイズは， JSPカーネルがポーティングされているターゲットプロセッサ／コンパイラの 多くにおいて 32ビットであるため，そうでない場合にのみターゲット毎のマ ニュアルに明示する．すなわち，ターゲット毎のマニュアルに明示されていな い限り，以下にリストアップするデータ型のサイズは 32ビットである． signed int型に定義しているデータ型 INT 符号付き整数 BOOL 真偽値 FN 機能コード ER エラーコード ID ID番号 PRI 優先度 TMO タイムアウト値 ER_BOOL ER または BOOL ER_ID ER または ID ER_UINT ER または UINT unsigned int型に定義しているデータ型 UINT 符号無し整数 ATR 属性 STAT 状態 MODE 動作モード RELTIM 相対時間 TEXPTN タスク例外要因のビットパターン FLGPTN イベントフラグのビットパターン size_t型に定義しているデータ型 SIZE サイズ ただし，RELTIM型の有効ビット数は31ビットを越えることはない．すなわち， unsigned int型のサイズが32ビットの場合には，RELTIM型の有効ビット数は 31ビットであり，(2^31 - 1)を越える値を RELTIM型のパラメータに渡した場 合，E_PARエラーとなる．unsigned int型のサイズが16ビットの場合には， RELTIM型の有効ビット数も16ビットである．スタンダードプロファイルでは， RELTIM型は16ビット以上と規定しており，この仕様でスタンダードプロファイ ル規定に準拠している． SYSTIM型は，32ビットの符号無し整数型に定義しており，構造体として定義す る方法は用いていない． 時間をあらわすデータ型（TMO，RELTIM，SYSTIM）の時間単位は，スタンダー ドプロファイルの規定に従い，すべて1ミリ秒としている． 2.3 オブジェクトのID番号と優先度 オブジェクトのID番号には，1から連続した正の値を用いる．オブジェクトの ID番号に抜けがある場合（例えば，ID=1とID=3のオブジェクトが登録され， ID=2のオブジェクトが登録されない場合）には，コンフィギュレータがエラー を報告する．負のID番号を用いたシステムオブジェクトとユーザオブジェクト の区別はサポートしていない． 生成できるオブジェクトの最大数は，カーネルのコード上は，ID番号がID型 （signed int型に定義している）で表現できる範囲内であるが，実際にはメモ リ容量によって制限される．なお，JSPカーネルでは，オブジェクトを生成す るためのサービスコールはサポートしていない． タスクとメッセージの優先度には，1〜16の正の値を用いる． 2.4 エラーチェックとエラーコード JSPカーネルでは，以下に示すメインエラーコードを返すエラーの検出を省略 している． E_SYS システムエラー E_MACV メモリアクセス違反 また，ポインタの値が不正な場合のパラメータエラー（E_PAR）の検出も省略 している．メモリアクセス違反（E_MACV）の検出も省略しているため，引数に ポインタを渡すサービスコールに対して，存在しないメモリ番地を差すポイン タなど，不正なアクセスを引き起こすポインタを渡した場合，プロセッサがバ スエラーなどのCPU例外を起こす場合がある（具体的な動作はターゲットプロ セッサに依存）． μITRON4.0仕様書に定義されているメインエラーコードの中で，スタンダード プロファイルの機能では発生しないものや，JSPカーネルの実装上発生しない ものがある．JSPカーネルでサービスコールが返すメインエラーコードについ ては，「9.3 メインエラーコード一覧」を参照のこと． JSPカーネルでは，サブエラーコードは用いていない．サブエラーコードには 常に-1が返る． 2.5 割込みハンドラ JSPカーネルでは，割込みハンドラの機能とそれを定義する静的API（DEF_INH） をサポートしており，割込みサービスルーチンの機能とそれを追加する静的 API（ATT_ISR）はサポートしていない． 割込みハンドラのC言語による記述形式は次の通りとする． void interrupt_handler(void) { 割込みハンドラ本体 } JSPカーネルでは，C言語で記述された割込みハンドラが呼ばれる時点で，CPU ロック解除状態になっている．また，割込みハンドラからリターンするには， C言語の関数から単にリターンすればよい． 割込みハンドラをアセンブリ言語で記述する方法は，サポートしていない． NMI（マスクできない割込み）以外にカーネルの管理外の割込みがあるかどう かは，ターゲット依存である．具体的な仕様については，ターゲット毎のマニュ アルを参照すること． 2.6 タイムイベントハンドラ JSPカーネルでは，タイムイベントハンドラとして，周期ハンドラのみをサポー トしている．周期ハンドラは，isig_timサービスコールの中から，サブルーチ ンコールで呼び出される．そのため，周期ハンドラの優先順位は，isig_timを 呼び出した割込みハンドラよりも一つだけ高い（厳密に言うと，isig_timを呼 び出した割込みハンドラよりも高く，その割込みハンドラよりも高い優先順位 を持つ他のいずれの処理よりも低い）． 2.7 CPU例外ハンドラ JSPカーネルでは，スタンダードプロファイル規定に従って，CPU例外ハンドラ の機能とそれを定義する静的API（DEF_EXC）をサポートしている． JSPカーネルでは，CPU例外ハンドラは非タスクコンテキストで実行される．非 タスクコンテキストから呼び出せるサービスコールは，CPU例外ハンドラ内か ら呼び出すことができる．ただし，CPU例外がCPUロック状態で発生した場合に は，CPU例外ハンドラ中でCPUロックを解除することはできず，非タスクコンテ キストから呼び出せるサービスコールを呼び出すこともできない． μITRON4.0仕様において，CPU例外ハンドラ内で行えるべきものとして規定さ れている各操作は，次のような方法で行うことができる． (a) CPU例外が発生したコンテキストや状態の参照は，そのために用意された JSPカーネル独自のサービスコール（vxsns_ctx，vxsns_loc，vxsns_dsp， vxsns_dpn，vxsns_tex）を用いて行うことができる．詳しくは，「3.10 CPU例外発生時のシステム状態参照」を参照すること． (b) CPU例外が発生したタスクのID番号の参照は，iget_tidサービスコールを 呼び出すことによって行うことができる． (c) タスク例外処理の要求は，iras_texサービスコールを呼び出すことによっ て行うことができる． CPU例外ハンドラの優先順位は，タスクコンテキストを実行中にCPU例外が発生 した場合には，ディスパッチャよりも高く，すべての割込みハンドラおよびタ イマハンドラよりも低い．非タスクコンテキストを実行中にCPU例外が発生し た場合には，CPU例外が発生した処理の優先順位よりも一つだけ高い（厳密に 言うと，CPU例外が発生した処理よりも高く，CPU例外が発生した処理よりも高 い優先順位を持つ他のいずれの処理よりも低い）． CPU例外ハンドラのC言語による記述形式は次の通りとする． void cpu_exception_handler(VP p_excinf) { CPU例外ハンドラ本体 } p_excinf には，CPU例外に関する情報を記憶している領域の先頭番地が渡され る．これは，CPU例外ハンドラ内で，CPU例外が発生したコンテキストや状態を 参照する際に必要となる．詳しくは，「3.10 CPU例外発生時のシステム状態参 照」参照すること．CPU例外ハンドラからリターンするには，C言語の関数から 単にリターンすればよい． CPU例外ハンドラをアセンブリ言語で記述する方法は，サポートしていない． 2.8 非タスクコンテキストからのサービスコール呼出しと割込み禁止区間 JSPカーネルでは，タスクコンテキスト専用のサービスコールと，非タスクコ ンテキスト専用のサービスコールを厳密に区別している．タスクコンテキスト 専用のサービスコールを非タスクコンテキストから呼び出した場合や，非タス クコンテキスト専用のサービスコールをタスクコンテキストから呼び出した場 合には，E_CTXエラーを返す． また，非タスクコンテキストから呼び出されたサービスコールの遅延実行は行っ ていない．そのため，非タスクコンテキストから呼び出したサービスコールも， 操作対象のオブジェクトの状態に依存して発生するエラーを検出することがで きる． 2.9 システム初期化手順と初期化ルーチン カーネルを起動するには，ターゲットに依存して行わなければならない最低限 の初期化を行った後，CPUロック状態と同等の状態で，kernel_start関数を呼 び出す．JSPカーネルでは，ターゲット毎にスタートアップモジュールを用意 して，この処理を行っている．詳しくは，ターゲット毎のマニュアルを参照す ること． ATT_INIによって追加された初期化ルーチンは，カーネル内部のデータ構造の 初期化や他の静的APIの処理を終えた後に，システムコンフィギュレーション ファイル中でのATT_INIの記述順と同じ順序で呼び出される．初期化ルーチン 内では，サービスコールを呼び出してはならない．初期化ルーチン内でサービ スコールを呼び出した場合，システムの動作は保証されない（実際には，ター ゲットによって，呼び出しても差し支えないサービスコールがある）．また， 初期化ルーチンを実行中にカーネルの管理外の割込みが禁止されているかどう かは，ターゲットおよびkernel_start関数が呼び出された時の状態に依存する． 具体的には，ターゲット毎のマニュアルを参照すること． 2.10 静的APIとコンフィギュレータ JSPカーネルは，μITRON4.0仕様に規定されたシステムコンフィギュレーショ ン手順に準拠した手順で，コンフィギュレーションを行う． システムの構成を記述したシステムコンフィギュレーションファイルは，まず C言語のプリプロセッサで処理され，その結果をカーネルのコンフィギュレー タ（cfgプログラム）に入力する．カーネルのコンフィギュレータは，カーネ ル構成・初期化ファイルをkernel_cfg.cに，ID自動割付け結果ヘッダファイル をkernel_id.hに生成する．また，静的APIのパラメータチェックに用いるファ イルをkernel_chk.cに，静的APIの解析内容を含むオブジェクト定義ファイル をkernel_obj.datに生成する．静的APIの文法エラー（および処理中のエラー の一部）が検出されれば，カーネルのコンフィギュレータがエラーを報告する． kernel_cfg.cは，コンパイルされて，アプリケーションプログラムおよびカー ネルと共にリンクされる．リンクにより生成されたロードモジュールは，カー ネルのパラメータチェックプログラム（chkプログラム）によって，静的APIの パラメータチェックが行われる．パラメータの値のエラーが検出されると，パ ラメータチェックプログラムがエラーを報告するが，「1.5 既知の問題点」で 述べた通り，現バージョンではパラメータエラーのチェックは不完全である． 以上の手順は，Makefile内に記述されている．ソフトウェア部品のコンフィギュ レータを組み込みたい場合には，Makefileを修正する必要がある． 2.11 インクルードファイル アプリケーションが用いることができるインクルードファイルは，includeディ レクトリの下に置かれている． t_services.hは，カーネル上で動作するプログラムのソースファイルでインク ルードするべき標準インクルードファイルである．この中で，kernel.h（さら にここから，t_stddef.h，itron.h，tool_defs.h，sys_defs.h，cpu_defs.h， t_syslog.h）とserial.hをインクルードしている．また，アプリケーションに 有益と思われる定義をいくつか含んでいる． s_services.hは，直接ハードウェアにアクセスするデバイスドライバのソース ファイルでインクルードするべき標準インクルードファイルである．この中で， sil.h（さらにここから，t_stddef.h，itron.h，tool_defs.h，sys_defs.h， cpu_defs.h，t_syslog.h）とt_config.h（さらにここから，sys_config.h， cpu_config.h，tool_config.h）をインクルードしている．また，アプリケー ションから呼ばれるデバイスドライバのインクルードファイルで，インライン 関数などでシステムインタフェースレイヤを用いている場合にも，このファイ ルをインクルードする． この2つのファイルからインクルードされるファイル（上に列挙したもの）は， 直接インクルードしないのが原則であるが，次の3つのケースは例外である． (1) カーネルから呼ばれるデバイスドライバのインクルードファイルで，イン ライン関数などでシステムインタフェースレイヤを用いている場合には， sil.hをインクルードする． (2) カーネル上で動作するプログラムで，ターゲット依存情報を参照したい場 合には，t_config.hをインクルードする． (3) 他のITRON仕様OSからソフトウェアをポーティングする場合などには， kernel.hを直接インクルードしてもよい． (4) ITRON仕様共通規定に準拠するソフトウェア部品のインクルードファイル は，itron.hを直接インクルードしてもよい． JSPカーネルのRelease 1.3以前のバージョンでは，t_services.hは jsp_services.hというファイル名になっていた．バージョンを問わずに動作す るプログラムを作る際には，t_services.hをインクルードし，古いバージョン でjsp_services.hをt_services.hにシンボリックリンクを貼る方法を推奨する． なお，jsp_kernel.hは，カーネルを構成するプログラムのソースファイルでイ ンクルードするべき標準インクルードファイルであり，カーネル上で動作する プログラムのソースファイルからは通常はインクルードしない． 2.12 システム終了手順と終了処理ルーチン アプリケーションから kernel_exit関数を呼び出すことで，カーネルを終了す ることができる．kernel_exit関数が呼び出されると，カーネルは，終了処理 ルーチンの実行，開発環境依存の終了処理（atexit によって登録された関数 や C++ におけるデストラクタの実行）を行った後，カーネルの終了処理を行 う． 終了処理ルーチンは，アプリケーションで用意し，VATT_TER を使ってカーネ ルに登録する．VATT_TER によって追加された終了処理ルーチンは，カーネル の管理外の割込みを除くすべての割込みを禁止した状態で，システムコンフィ ギュレーションファイル中での VATT_TER の記述順と逆の順序で呼び出される． 終了処理ルーチン内では，サービスコールを呼び出してはならない．終了処理 ルーチン内でサービスコールを呼び出した場合，システムの動作は保証されな い（実際には，ターゲットによって，呼び出しても差し支えないサービスコー ルがある）． 2.13 その他 JSPカーネルでは，t_stddef.h の中で，次のマクロを定義している． (1) assert(exp) JSPカーネルでは，assertマクロを独自に定義している．開発環境の標準の assertマクロは使われない． (2) throw() C言語とEC++言語では，throw() が空になるように定義している．C++言語から 呼び出す可能性のあるC言語で記述された関数のプロトタイプ宣言に，throw() をつけることを想定している． また，t_services.h の中で，次のマクロを定義している． (3) syscall(s) サービスコール s を呼び出し，返値がエラーであれば，エラーメッセージを 出力する． (4) _syscall(s) サービスコール s を呼び出し，返値がエラーであれば，エラーメッセージを 出力し，カーネルを異常終了させる． ３．JSPカーネルのサービスコールと静的API この節では，JSPカーネルのサービスコールと静的APIについて，μITRON4.0仕 様で実装定義となっている事項とJSPカーネル独自のサービスコールを中心に 解説する． 3.1 タスク管理機能 タスクの起動要求キューイング数の最大値（TMAX_ACTCNT）は1に固定している． (1) CRE_TSK タスクの生成（静的API） tskatr に TA_ASM が指定された場合の機能（タスクをアセンブリ言語で記述 する）はサポートしていない．また，stk に NULL 以外が指定された場合の機 能（スタック領域の先頭番地を指定する）もサポートしていない． (2) act_tsk, iact_tsk タスクの起動 (3) can_act タスク起動要求のキャンセル (4) ext_tsk 自タスクの終了 ext_tsk が非タスクコンテキストから呼ばれた場合，システムログ機能を用い てエラー情報を出力し（LOG_EMERGレベル），そのまま実行を続けるが，動作 は保証されない． ext_tsk がCPUロック状態（またはディスパッチ禁止状態）で呼ばれた場合， システムログにエラーを記録し（LOG_WARNINGレベル），CPUロック解除状態 （またはディスパッチ許可状態）にしてからタスクを終了する． (5) ter_tsk タスクの強制終了 (6) chg_pri タスク優先度の変更 (7) get_pri タスク優先度の参照 3.2 タスク付属同期機能 タスクの起床要求キューイング数の最大値（TMAX_WUPCNT）は 1 に固定してい る．また，タスクの強制待ち要求ネスト数の最大値（TMAX_SUSCNT）も 1 に固 定している． (1) slp_tsk 起床待ち (2) tslp_tsk 起床待ち（タイムアウトあり） (3) wup_tsk, iwup_tsk タスクの起床 (4) can_wup タスク起床要求のキャンセル (5) rel_wai, irel_wai 待ち状態の強制解除 (6) sus_tsk 強制待ち状態への移行 (7) rsm_tsk 強制待ち状態からの再開 (8) frsm_tsk 強制待ち状態からの強制再開 タスクの強制待ち要求ネスト数の最大値（TMAX_SUSCNT）が 1 であるため， rsm_tsk と frsm_tsk の処理内容は同一である． (9) dly_tsk 自タスクの遅延 3.3 タスク例外処理機能 TEXPTN型は，unsigned int型に定義している．よって TBIT_TEXPTN は， unsigned int型が 32ビットの場合は 32，16ビットの場合は 16 になる． (1) DEF_TEX タスク例外処理ルーチンの定義（静的API） texatr に TA_ASM が指定された場合の機能（タスク例外処理ルーチンをアセ ンブリ言語で記述する）はサポートしていない． (2) ras_tex, iras_tex タスク例外処理の要求 (3) dis_tex タスク例外処理の禁止 (4) ena_tex タスク例外処理の許可 (5) sns_tex タスク例外処理禁止状態の参照 3.4 同期・通信機能 3.4.1 セマフォ セマフォの最大資源数は，UINT型（unsigned int型に定義している）で表現で きる数値の範囲内である．すなわち，unsigned int型が 32ビットの場合は (2^32 - 1)，16ビットの場合は (2^16 - 1) = 65535 である．TMAX_MAXSEM は 定義していない． (1) CRE_SEM セマフォの生成（静的API） (2) sig_sem, isig_sem セマフォ資源の返却 (3) wai_sem セマフォ資源の獲得 (4) pol_sem セマフォ資源の獲得（ポーリング） (5) twai_sem セマフォ資源の獲得（タイムアウトあり） 3.4.2 イベントフラグ 一つのイベントフラグで複数のタスクが待ち状態になれる機能はサポートして いない． FLGPTN型は，unsigned int型に定義している．よって TBIT_FLGPTN は， unsigned int型が 32ビットの場合は 32，16ビットの場合は 16 になる． (1) CRE_FLG イベントフラグの生成（静的API） flgatr に TA_WMUL が指定された場合の機能（イベントフラグで複数のタスク が待ち状態になれる）はサポートしていない． (2) set_flg, iset_flg イベントフラグのセット (3) clr_flg イベントフラグのクリア (4) wai_flg イベントフラグ待ち (5) pol_flg イベントフラグ待ち（ポーリング） (6) twai_flg イベントフラグ待ち（タイムアウトあり） 3.4.3 データキュー dtqcnt個のデータを格納するのに必要なデータキュー領域のサイズは， sizeof(VP_INT) * dtqcnt バイトである．TSZ_DTQ は定義していない． (1) CRE_DTQ データキューの生成（静的API） dtq に NULL 以外が指定された場合の機能（データキュー領域の先頭番地を指 定する）はサポートしていない． (2) snd_dtq データキューへの送信 (3) psnd_dtq, ipsnd_dtq データキューへの送信（ポーリング） (4) tsnd_dtq データキューへの送信（タイムアウトあり） (5) fsnd_dtq, ifsnd_dtq データキューへの強制送信 (6) rcv_dtq データキューからの受信 (7) prcv_dtq データキューからの受信（ポーリング） (8) trcv_dtq データキューからの受信（タイムアウトあり） 3.4.4 メールボックス T_MSG型は下記のように定義されている．T_MSG型のサイズは，ターゲットプロ セッサ／コンパイラのポインタのサイズに一致する． typedef struct t_msg { struct t_msg *next; } T_MSG; JSPカーネルでは，優先度別メッセージキューヘッダ領域は用いていない． TSZ_MPRIHD は定義していないが，定義するとしたら 0 となる． (1) CRE_MBX メールボックスの生成（静的API） mprihd に NULL 以外が指定された場合の機能（優先度別メッセージキューヘッ ダ領域の先頭番地を指定する）はサポートしていない． (2) snd_mbx メールボックスへの送信 (3) rcv_mbx メールボックスからの受信 (4) prcv_mbx メールボックスからの受信（ポーリング） (5) trcv_mbx メールボックスからの受信（タイムアウトあり） 3.5 メモリプール管理機能 3.5.1 固定長メモリプール サイズが blkszバイトのメモリブロックを blkcnt個獲得できるのに必要な固 定長メモリプール領域のサイズは，TROUND_VP(blksz) * blkcnt バイトである． ここで，TROUND_VP(blksz) は，blksz をターゲットプロセッサ／コンパイラ のポインタのサイズの倍数になるよう切り上げた数を表す．TSZ_MPF は定義し ていない． (1) CRE_MPF 固定長メモリプールの生成（静的API） mpf に NULL 以外が指定された場合の機能（固定長メモリプール領域の先頭番 地を指定する）はサポートしていない． (2) get_mpf 固定長メモリブロックの獲得 (3) pget_mpf 固定長メモリブロックの獲得（ポーリング） (4) tget_mpf 固定長メモリブロックの獲得（タイムアウトあり） (5) rel_mpf 固定長メモリブロックの返却 blkパラメータ（返却するメモリブロックの先頭番地）の値が，返却先のメモ リプール領域の外や，メモリブロックの途中を指す場合には，E_PARエラーを 返す．未獲得のメモリブロックを返却した場合や，返却済のメモリブロックを 再度返却した場合の動作は保証されない． 3.6 時間管理機能 タイムイベントハンドラに関しては，「2.6 タイムイベントハンドラ」を参照 すること． 3.6.1 システム時刻管理 JSPカーネルでは，タイムティックの供給（isig_tim を周期的に呼び出す処理） はシステムサービスのシステムクロックドライバによって実現している．シス テムクロックドライバの主要部分は，ターゲット毎にハードウェアタイマを使っ て実現されており，isig_tim を呼び出す周期はターゲット毎に定める．その ため TIC_NUME と TIC_DENO は，ターゲット依存部のアプリケーション用のイ ンクルードファイル（cpu_defs.h および sys_defs.h）の中で定義している． ターゲットによっては，この数値を変更するだけで isig_tim を呼び出す周期 を変更できるように実装されている場合もある．詳しくは，ターゲット毎のマ ニュアルを参照すること． (1) set_tim システム時刻の設定 (2) get_tim システム時刻の参照 (3) isig_tim タイムティックの供給 isig_tim は，ターゲット依存に定義された TIC_NUME と TIC_DENO で指定さ れる時間だけシステム時刻を進め，必要なタイムイベント（タイムアウト，周 期ハンドラの起動など）の処理を行う．JSPカーネルでは，システムクロック ドライバがこのサービスコールを周期的に呼び出すため，アプリケーションか ら呼び出す必要はない． 3.6.2 周期ハンドラ 周期ハンドラの起動位相を保存する機能はサポートしていない． (1) CRE_CYC 周期ハンドラの生成（静的API） cycatr に TA_PHS が指定された場合の機能（周期ハンドラの起動位相を保存 する）はサポートしていない．また，TA_ASM が指定された場合の機能（周期 ハンドラをアセンブリ言語で記述する）もサポートしていない． cycatr に TA_STA を指定し，cycphs に 0 を指定した場合，周期ハンドラの 初回の起動は，システム起動後の最初のタイムティックで行われる．すなわち， cycphs に 1 を指定した場合と同じ振る舞いとなる．混乱の原因となるため， cycphs に 0 を指定することは推奨しない． (2) sta_cyc 周期ハンドラの動作開始 (3) stp_cyc 周期ハンドラの動作停止 3.7 システム状態管理機能 (1) rot_rdq, irot_rdq タスクの優先順位の回転 (2) get_tid, iget_tid 実行状態のタスクIDの参照 (3) loc_cpu, iloc_cpu CPUロック状態への移行 (4) unl_cpu, iunl_cpu CPUロック状態の解除 (5) dis_dsp ディスパッチの禁止 (6) ena_dsp ディスパッチの許可 (7) sns_ctx コンテキストの参照 (8) sns_loc CPUロック状態の参照 (9) sns_dsp ディスパッチ禁止状態の参照 (10) sns_dpn ディスパッチ保留状態の参照 (11) vsns_ini カーネル動作状態の参照 【C言語API】 BOOL state = vsns_ini(); 【パラメータ】 なし 【リターンパラメータ】 BOOL state カーネル動作状態 【機能】 カーネルの初期化完了前または終了処理開始後に呼び出された場合に TRUE， カーネルの動作中に呼び出された場合に FALSE を返す． このサービスコールが TRUE を返す時には，他のサービスコールを呼び出して はならない．このサービスコールが TRUE を返す時に他のサービスコールを呼 び出した場合，システムの動作は保証されない． 3.8 割込み管理機能 割込みハンドラに関しては，「2.5 割込みハンドラ」を参照すること． (1) DEF_INH 割込みハンドラの定義（静的API） INHNO型の定義と inhno の意味はターゲット毎に定める．inhatr には， TA_HLNG のみを指定することができる． (2) dis_int 割込みの禁止 (3) ena_int 割込みの許可 (4) chg_ixx 割込みマスクの変更 (5) get_ixx 割込みマスクの参照 これらのサービスコールがサポートされているかどうか，サポートされている 場合の仕様（xx の部分の名称，型とパラメータの名称と意味，CPUロック状態 やディスパッチ状態との関連）については，ターゲット依存である．具体的に は，ターゲット毎のマニュアルを参照すること． 3.9 システム構成管理機能 CPU例外ハンドラに関しては「2.7 CPU例外ハンドラ」を，初期化ルーチンに関 しては「2.9 システム初期化手順と初期化ルーチン」参照すること． (1) DEF_EXC CPU例外ハンドラの定義（静的API） EXCNO型の定義と excno の意味はターゲット毎に定める．excatr には， TA_HLNG のみを指定することができる． (2) ATT_INI 初期化ルーチンの追加（静的API） iniatr に TA_ASM が指定された場合の機能（初期化ルーチンをアセンブリ言 語で記述する）はサポートしていない． (3) VATT_TER 終了処理ルーチンの追加（静的API） 【静的API】 VATT_TER({ ATR teratr, VP_INT exinf, FP terrtn }); 【パラメータ】 ATR teratr 終了処理ルーチン属性 VP_INT exinf 終了処理ルーチンの拡張情報 FP terrtn 終了処理ルーチンの起動番地 【機能】 終了処理ルーチンを，指定される各パラメータに基づいて追加する．teratr は終了処理ルーチンの属性，exinf は終了処理ルーチンを起動する時にパラメ ータとして渡す拡張情報，terrtn は終了処理ルーチンの起動番地である． VATT_TER においては，teratr はプリプロセッサ定数式パラメータである． teratr には，TA_HLNG の指定ができる．TA_HLNG（＝0x00）が指定された場合 には高級言語用のインタフェースで終了処理ルーチンを起動する． VATT_ATR によって追加された終了処理ルーチンは，システム終了処理時に実 行される．詳しくは，「2.12 システム終了手順と終了処理ルーチン」を参照 すること． 3.10 CPU例外発生時のシステム状態参照 CPU例外ハンドラ内で，CPU例外が発生したコンテキストや状態を参照するため のサービスコールとして，JSPカーネルでは，五つのサービスコールを独自に サポートしている．サービスコール vxsns_yyy は，CPU例外が発生した処理で sns_yyy を呼び出した場合の結果を取り出すもので，CPU例外ハンドラに渡さ れるパラメータ p_excinf をパラメータとする． (1) vxsns_ctx CPU例外発生時のコンテキストの参照 【C言語API】 BOOL state = vxsns_ctx(VP p_excinf); 【パラメータ】 VP p_excinf CPU例外に関する情報を記憶している領域の 先頭番地 【リターンパラメータ】 BOOL state コンテキスト 【機能】 CPU例外が発生したコンテキストが，非タスクコンテキストの場合に TRUE，タ スクコンテキストの場合に FALSE を返す．p_excinf には，CPU例外ハンドラ に渡される p_excinfパラメータをそのまま渡す．CPU例外ハンドラ以外から呼 び出した場合や，p_excinf を正しく渡さなかった場合の振舞いは保証されな い． (2) vxsns_loc CPU例外発生時のCPUロック状態の参照 【C言語API】 BOOL state = vxsns_loc(VP p_excinf); 【パラメータ】 VP p_excinf CPU例外に関する情報を記憶している領域の 先頭番地 【リターンパラメータ】 BOOL state CPUロック状態 【機能】 CPU例外が発生した状態が，CPUロック状態の場合に TRUE，CPUロック解除状態 の場合に FALSE を返す．p_excinf には，CPU例外ハンドラに渡される p_excinfパラメータをそのまま渡す．CPU例外ハンドラ以外から呼び出した場 合や，p_excinf を正しく渡さなかった場合の振舞いは保証されない． (3) vxsns_dsp CPU例外発生時のディスパッチ禁止状態の参照 【C言語API】 BOOL state = vxsns_dsp(VP p_excinf); 【パラメータ】 VP p_excinf CPU例外に関する情報を記憶している領域の 先頭番地 【リターンパラメータ】 BOOL state ディスパッチ禁止状態 【機能】 CPU例外が発生した状態が，ディスパッチ禁止状態の場合に TRUE，ディスパッ チ許可状態の場合に FALSE を返す．p_excinf には，CPU例外ハンドラに渡さ れる p_excinfパラメータをそのまま渡す．CPU例外ハンドラ以外から呼び出し た場合や，p_excinf を正しく渡さなかった場合の振舞いは保証されない． 【補足説明】 CPU例外ハンドラの起動によってディスパッチ禁止／許可状態は変化せず，CPU 例外ハンドラ中ではディスパッチの禁止や許可は行えないため，vxsns_dsp の 返り値は sns_dsp の返り値に常に一致する．そのため，vxsns_dsp と sns_dsp の処理内容は同一となっている． (4) vxsns_dpn CPU例外発生時のディスパッチ保留状態の参照 【C言語API】 BOOL state = vxsns_dpn(VP p_excinf); 【パラメータ】 VP p_excinf CPU例外に関する情報を記憶している領域の 先頭番地 【リターンパラメータ】 BOOL state ディスパッチ保留状態 【機能】 CPU例外が発生した状態が，ディスパッチ保留状態の場合に TRUE，そうでない 場合に FALSE を返す．すなわち，ディスパッチャよりも優先順位が高い処理 が実行されていた時，CPUロック状態であった時およびディスパッチ禁止状態 であった時は，TRUE を返す．p_excinf には，CPU例外ハンドラに渡される p_excinfパラメータをそのまま渡す．CPU例外ハンドラ以外から呼び出した場 合や， p_excinf を正しく渡さなかった場合の振舞いは保証されない． (5) vxsns_tex CPU例外発生時のタスク例外処理禁止状態の参照 【C言語API】 BOOL state = vxsns_tex(VP p_excinf); 【パラメータ】 VP p_excinf CPU例外に関する情報を記憶している領域の 先頭番地 【リターンパラメータ】 BOOL state タスク例外処理禁止状態 【機能】 CPU例外が発生した時に実行状態であったタスクが，タスク例外処理禁止状態 の場合に TRUE，タスク例外処理許可状態の場合に FALSE を返す．CPU例外が 非タスクコンテキストで発生し，その時に実行状態のタスクがなかった場合に も，FALSE を返す．p_excinf には，CPU例外ハンドラに渡される p_excinfパ ラメータをそのまま渡す．CPU例外ハンドラ以外から呼び出した場合や， p_excinf を正しく渡さなかった場合の振舞いは保証されない． 【補足説明】 CPU例外ハンドラの起動によってタスク例外処理禁止／許可状態は変化せず， CPU例外ハンドラ中ではタスク例外処理の禁止や許可は行えないため， vxsns_tex の返り値は sns_tex の返り値に常に一致する．そのため， vxsns_tex と sns_tex の処理内容は同一となっている． 3.11 性能評価用システム時刻参照機能 JSPカーネルでは，JSPカーネル上で動作するタスクやJSPカーネル自身の性能 を計測するために，システム時刻より精度の高い性能評価用システム時刻を読 み出す機能を，ターゲット依存にサポートしている．性能評価用システム時刻 は，μ秒単位で表現されるが，実際の精度はターゲット依存である．具体的に は，ターゲット毎のマニュアルを参照すること． 性能評価用システム時刻参照機能では，次のデータ型を用いる． SYSUTIM 性能評価用システム時刻（符号無し整数） SYSUTIM型のサイズ数はターゲット依存である．具体的には，ターゲット毎の マニュアルを参照すること． (1) vxget_tim 性能評価用システム時刻の参照 【C言語API】 ER ercd = vxget_tim(SYSUTIM *p_sysutim); 【パラメータ】 なし 【リターンパラメータ】 ER ercd エラーコード SYSUTIM sysutim 現在の性能評価用システム時刻 【エラーコード】 E_CTX コンテキストエラー 【機能】 現在の性能評価用システム時刻を読み出し，sysutim に返す． このサービスコールは，タスクコンテキストからのみ呼び出すことができる． 非タスクコンテキストから呼び出した場合には，E_CTXエラーとなる． タスクコンテキストであれば，CPUロック状態であっても呼び出せるが，CPUロッ ク状態が長時間継続すると，タイマ割込みが入らないためにシステム時刻が更 新されず，このサービスコールも正しい性能評価用システム時刻を返せなくな る．時間測定区間が短い場合を除いては，時間測定区間全体をCPUロック状態 とするのは適切ではない． ４．システムログ機能 システムログ機能は，カーネル内で発生した異常事象（アサーションの失敗， エラーコードを返せないエラー）を，システムの外部に通知するための機能で ある．カーネルのトレースログ，システムサービスやアプリケーション内で発 生した異常事象やトレースログにも，同じ機能を利用することができる． 4.1 システムログ機能の位置付け カーネル内で発生した異常事象をシステムの外部に通知するための方法として， シリアルインタフェースに出力する，ディスクに書き出すなどの方法が考えら れる． システムログ機能は，カーネル内部から呼び出されるという観点からは，カー ネルの一部と考えるのが自然である．一方，シリアルインタフェースやディス クにアクセスするためのサービス（デバイスドライバなど）はカーネル上で動 作するため，それらを用いるシステムログ機能は，カーネル上に実装されたシ ステムサービスと考える方が自然で，位置づけが微妙である． そこでJSPカーネルでは，カーネルの拡張機能として，異常事象に関する情報 やトレースログ情報（これを，ログ情報と総称する）を，カーネル内のバッファ （これをログバッファと呼ぶ）に記録する機能と，ログバッファからログ情報 を読み出す機能を用意する．これを，システムログ機能と呼ぶ．ログ情報をロ グバッファから読み出し，デバイスにアクセスするサービスを用いて外部に出 力する機能は，システムログタスクとしてカーネル上に実現する． 4.2 ログバッファへの記録と低レベル出力 上述したように，ログ情報をシステムの外部に出力するために，デバイスにア クセスするサービスが必要になるが，これらのサービスはカーネル上で動作し ているため，カーネルの動作を継続できないような重大な異常事象が起こった 場合には，これらのサービスを使うことができない．また，これらのサービス 自身をデバッグする場合にも，デバイスにアクセスするサービスを使うことが できない． そこで，カーネル上で動作するサービスが使えない場合にでもログ情報を出力 するために，低レベル出力機能を用意する．低レベル出力機能は，ターゲット 依存に用意する低レベルの文字出力関数（sys_putc）を用いてログ情報を出力 する機能である．低レベルの文字出力関数は，ターゲット依存部で用意するこ ととしているが，最終製品に組み込まれる場合などでは，文字を出力する方法 がない状況も考えられる．そのような場合，低レベルの文字出力関数に送られ た文字は，メモリ上に残しておくか，捨ててしまうしかない． ログ情報を，ログバッファへ記録するか低レベル出力機能を用いて出力するか の設定は，カーネルの拡張サービスコール（vmsk_log）によって行うことがで きる．vmsk_log の使い方については後述する． 低レベル出力機能を用いると，ログメッセージの作成処理（printf 相当の処 理）と低レベルの文字出力処理をカーネル内で行うために，カーネルの応答性 が悪くなることに注意しなければならない．特に，低レベルの文字出力処理は デバイスをポーリングする形で実装するのが通常で，その場合には，カーネル の応答性は実用的と言えない程に悪くなる． 一方，カーネルの動作を継続できるような（あまり重大でない）事象について は，ログ情報をカーネル内のログバッファに記録し，記録したログ情報の出力 は，デバイスにアクセスするサービスを用いて動作するシステムログタスクに 任せる．システムログタスクはカーネル上で動作するタスクであり，カーネル の拡張サービスコール（vrea_log）を用いて，ログバッファからログ情報を読 み出す．JSPカーネルの標準配布キットには，システムログタスクの一例とし て，シリアルインタフェースにログ情報を文字列の形で出力するシステムログ タスクを含めている． 4.3 ログ情報の種別 JSPカーネルのシステムログ機能は，ログ情報に以下の種別を設けている． LOG_TYPE_INH 割込みハンドラ LOG_TYPE_ISR 割込みサービスルーチン LOG_TYPE_CYC 周期ハンドラ LOG_TYPE_EXC CPU例外ハンドラ LOG_TYPE_TEX タスク例外処理ルーチン LOG_TYPE_TSKSTAT タスク状態変化 LOG_TYPE_DSP ディスパッチャ LOG_TYPE_SVC サービスコール LOG_TYPE_COMMENT コメント LOG_TYPE_ASSERT アサーションの失敗 これらの種別は，ITRONデバッギングインタフェース仕様を参考に定めている． ただし，ITRONデバッギングインタフェース仕様におけるトレースログ形式は， RIM（RTOS Interface Module）がデバッグツールに渡す場合の形式を定めたも のであり，カーネルが出力する形式と一致している必要はない（RIM が変換す ればよいため）．実際，上の種別の中で，LOG_TYPE_CYC と LOG_TYPE_ASSERT は，デバッギングインタフェース仕様と一致していない． ログ情報の種別の中で，LOG_TYPE_COMMENT と LOG_TYPE_ASSERT 以外はカーネ ルのトレースログのためのもので，どのように用いるかはターゲット依存部に 任されている（4.5節参照）． 4.4 ログ情報の重要度 JSPカーネルのシステムログ機能は，ログ情報を出力する際に指定する重要度 に基づいて，実際に出力するログ情報を動的に設定することができる．これは， UNIX のシステムログ機能をまねたもので，ログの重要度の種類や指定方法も UNIX の API を参考にしている．また，低レベル出力機能を用いて出力するロ グ情報も，重要度に基づいて動的に設定することができる． 具体的には，ログの重要度として次の8段階を用意している． LOG_EMERG システムをシャットダウンすべきエラー LOG_ALERT LOG_CRIT LOG_ERROR 重要性の低いシステムエラー LOG_WARNING 警告メッセージ．システムは安全に継続動作できる LOG_NOTICE LOG_INFO LOG_DEBUG デバッグのためのメッセージ なお，アサーションの失敗は，LOG_EMERG で出力する．カーネルのトレースロ グは，LOG_DEBUG で出力するのを標準とする（ターゲット依存）． どの重要度のログ情報をログバッファに記録するかと，どの重要度のログ情報 を低レベル出力機能を用いて出力するかは，カーネルの拡張サービスコール （vmsk_log）によって設定することができる．vmsk_log の各パラメータは， 指定するログ情報の集合を表すビットマップである．また，ビットマップを作 るためのマクロとして，LOG_MASK と LOG_UPTO を用意している． 4.5 トレースログ機能 JSPカーネルは，カーネルのトレースログを取得するための基本的な仕組みを 持っているが，トレースログの実際の取得方法はターゲット依存となる．カー ネルのトレースログの取得に，システムログ機能を使うのも選択肢の1つであ る．ただし，カーネルのトレースログをシステムログタスクを用いて取り出す 方法は考えていない（システムログタスクが動作することによりトレースログ が生成され，取り出すより多くのログ情報が生成される可能性があるため）． 4.6 システムログ機能の拡張サービスコール システムログ機能の提供する拡張サービスコールは次の通りである． (1) ER vwri_log(UINT prio, SYSLOG *p_log) システムログ機能に，重要度 prio でログ情報を出力する（ログバッファへ記 録するか低レベル出力機能を用いて出力する）．SYSLOG は，ログ情報を格納 するためのデータ型（構造体）で，この拡張サービスコールには，それへのポ インタを渡す． (2) ER_UINT vrea_log(SYSLOG *p_log) ログバッファからログ情報を1つ取り出す．ログバッファが空の時は E_OBJ， そうでない場合は，失われたログ情報の数（ログ情報が失われていない場合は 0）を返す．システムログタスクが用いることを想定している． (3) ER vmsk_log(UINT logmask, UINT lowmask) ログバッファに記録すべきログ情報の重要度のビットマスク（logmask）と， 低レベル出力機能を用いて出力すべきログ情報の重要度のビットマスク （lowmask）を設定する． 4.7 システムログ機能のためのライブラリ関数とマクロ システムログ機能は，上記のサービスコールに加えて，次のライブラリ関数と マクロを提供する． (1) void _syslog_n(UINT prio, UINT type, VP_INT arg1, ..., VP_INT argn) ※ n は 0〜6 のいずれか． ログ種別が type，パラメータが arg1〜argn のログ情報を，重要度 prio で 出力するためのライブラリ関数． (2) void syslog_n(UINT prio, const char *format, arg1, ..., argn) ※ n は 0〜5 のいずれか． format 文字列およびそれに続く引数から作成されるコメント（ログ種別が LOG_TYPE_COMMENT のログ情報）を，重要度 prio で出力するためのマクロ． format はメッセージのフォーマット記述，arg1〜argn はフォーマット記述中 で参照される値で，printf のフォーマット記述のサブセットとなっている． arg1〜argn は VP_INT型にキャストされるため，VP_INT型に型変換できる任意 の型を渡すことができ，型チェックはされない．format および arg1〜argn には，次の制限がある． ・format のフォーマット記述は，このマクロから戻った後も変化してはなら ない．定数文字列を渡すことを想定している． ・format 中に使えるフォーマット指定は次の通り． %d 引数をsigned int型とみなし，10進数で表示 %u 引数をunsigned int型とみなし，10進数で表示 %x 引数をunsigned int型とみなし，16進数（英文字は小文字）で表示 %X 引数をunsigned int型とみなし，16進数（英文字は大文字）で表示 %p 引数をポインタとみなし，16進数（英文字は小文字）で表示 %c 引数を文字コードとみなし，文字を表示 %s 引数を文字列を示すポインタとみなし，文字列を表示 %% '%' を表示（引数は取らない） %d, %u, %x, %X においては，'%' の直後に表示桁数を指定する10進数値を記述 することができる．その場合，表示すべき文字列が指定した桁数に満たない場 合には，指定した桁数内に右詰めで表示する．10進数値が '0' で始まる場合 には，その間に '0' を埋める． また，VP_INT型のサイズが long型のサイズ以上である環境においては，次の フォーマット指定も使用することができる．この他のフォーマット指定に 'l' を付加した場合には無視する（%lcと%lsには対応していない）． %ld 引数をsigned long型とみなし，10進数で表示 %lu 引数をunsigned long型とみなし，10進数で表示 %lx 引数をunsigned long型とみなし，16進数（英文字は小文字）で表示 %lX 引数をunsigned long型とみなし，16進数（英文字は大文字）で表示 ・arg1〜argn にポインタを渡す場合（%s に対応する引数の場合）に，ポイン タの指すデータは，このマクロから戻った後も変化してはならない．定数文字 列を渡すことを想定している． (3) void syslog(UINT prio, const char *format, ...) format 文字列およびそれに続く引数から作成されるメッセージを，重要度 prio でログ情報として出力するためのライブラリ関数で，引数の数を可変に したもの．format に続く引数は最大5個まで．format およびそれに続く引数 には，syslog_n と同様の制限がある． このライブラリ関数は，可変数引数を処理するために内部で文字列をスキャン する．そのため，実行時間が長くなる可能性があり，割込み禁止状態で呼び出 すべきではない．主にアプリケーションプログラムが用いることを想定してい る．そのため，このライブラリ関数のソースファイルは，サポートライブラリ のディレクトリに置いている． (4) UINT LOG_MASK(UINT prio) 重要度 prio のみセットされたビットマップを作るマクロ．vmsk_log に渡す 引数を作るために用いる． (5) UINT LOG_UPTO(UINT prio) 重要度 prio 以上の重要度がすべてセットされたビットマップを作るマクロ． vmsk_log に渡す引数を作るために用いる． (6) void syslog_printf(const char *format, VP_INT *args, void (*putc)(char)) (7) void syslog_print(SYSLOG *p_sys, void (*putc)(char)) (8) void syslog_output(void (*putc)(char)) ログ情報をフォーマット出力するためのライブラリ関数．syslog_printf は渡 されたフォーマット文字列と引数を，syslog_print は渡されたログ情報を， syslog_output はログバッファに格納されたログ情報をフォーマット出力する． システムログタスクが用いることを想定しているため，このライブラリ関数の ソースファイルはサポートライブラリのディレクトリに置いている．ただし， 低レベル出力を行うために，システムログ機能内部でも用いている． 4.8 システムログ機能の設定方法 JSPカーネルのシステムログ機能の想定されている設定方法は，以下の通りで ある． (a) 重大な異常事象を示すログ情報は低レベル出力機能を用いて出力し，そう でないログ情報の出力はシステムログタスクに任せる． ログバッファに記録するログ情報の重要度と，低レベル出力を用いて出力する ログ情報の重要度を適切に設定する．また，ログバッファからログ情報を読み 出して外部へ通知するシステムログタスクと，低レベルの文字出力関数を用意 する． (b) すべてのログ情報を，低レベル出力機能を用いて出力する． 必要なログ情報はすべて低レベル出力機能を用いて出力するよう設定 （vmsk_log の第1パラメータを 0 に設定）する．また，低レベルの文字出力 関数を用意する．システムログタスクは不要． (c) ログ情報はメモリ上に記録するだけで，システム外部には出力しない． 必要なログ情報はすべてログバッファへ記録するように設定（vmsk_log の第2 パラメータを 0 に設定）する．システムログタスクは不要． (d) ログ情報は記録も出力もしない． いずれのログ情報も記録／出力しないように設定（vmsk_log の両パラメータ ともに 0 に設定）する． 別の方法として，OMIT_SYSLOG を定義してコンパイルすることで，システムロ グ機能をカーネルから取り外し，カーネルのコードサイズを小さくすることが できる．ただし，アプリケーションから syslog，syslog_printf，syslog_print， syslog_output の各関数を呼び出している場合，それらの関数のコードは外れ ない．また，カーネルからのログ情報は記録／出力しないが，アプリケーショ ンからのログ情報は記録／出力したい場合には，カーネルのみ OMIT_SYSLOG を定義してコンパイルすればよい．この場合，システムログ機能の初期化関数 （_kernel_syslog_initialize）と終了処理関数（_kernel_syslog_teminate） は，アプリケーションから呼び出す必要がある． なお，(b)〜(c) の設定に固定して使用する場合にも，カーネル内の一部のコー ドが不要になり，コードサイズを小さくできる余地があるが，簡易な方法は用 意していない． ５．システムサービス この節では，JSPカーネルがサポートしているシステムインタフェースレイヤ （SIL）と，JSPカーネルが標準的に動作させるドライバおよびシステムタスク について説明する． 5.1 システムインタフェースレイヤ（SIL） JSPカーネルは，ITRONデバイスドライバ設計ガイドラインの一部分として検討 されているシステムインタフェースレイヤ（SIL）の中で，以下に挙げる機能 をサポートしている．SILを用いるプログラムからは，t_services.hに代えて， s_services.hをインクルードする． ITRONデバイスドライバ設計ガイドラインでは，デバイスドライバの中で，SIL を通して直接デバイスにアクセスするモジュール（PDIC）と，カーネルの機能 を用いるモジュール（GDIC）を分離することにしている．すなわち，PDICは SILを用いるがカーネルの機能は用いず，GDICはカーネルの機能は用いるがSIL を用いてはならない．そのため，s_services.hには，カーネルを用いるための 宣言や定義は含まれていない． 5.1.1 割込みロック状態の制御 デバイスを扱うプログラムの中では，すべての割込み（NMIを除く，以下同じ） を禁止したい場合がある．μITRON4.0仕様のCPUロック状態は，カーネルの管 理外の割込み（NMI以外にカーネルの管理外の割込みがあるかは，JSPカーネル ではターゲット依存）を禁止するとは限らず，このような場合に用いるのは適 切でない． そこで，すべての割込みを禁止した状態を割込みロック状態と呼び，SILでは 割込みロック状態を制御するための以下の機能を用意している． (1) SIL_PRE_LOC 割込みロック状態の制御に必要な変数を宣言し，それを初期化するマクロ．こ のマクロを記述した時点で，割込みの禁止状態を記録する．SIL_LOC_INT， SIL_UNL_INTを用いる関数（ブロック）の先頭の変数宣言部に記述しなければ ならない． (2) SIL_LOC_INT() すべての割込みを禁止し，割込みロック状態に移行する． (3) SIL_UNL_INT() SIL_PRE_LOCを記述した時点の状態に戻す． 割込みロック状態の制御機能の使用例は次の通り． { SIL_PRE_LOC; SIL_LOC_INT(); この間はすべての割込みが禁止される この間にサービスコールを呼び出してはならない SIL_UNL_INT(); } なお，JSPカーネル自身は割込みロック状態は管理していないため，割込ロッ ク状態ではサービスコールを呼び出してはならない（呼び出した場合の動作は 保証されない）． 5.1.2 微少時間待ち デバイスをアクセスする際に，微少な時間待ちを入れなければならない場合が ある．そのような場合に，nopをいくつか入れるなどの方法で対応すると，ポ ータビリティが悪くなる．そこでSILでは，微少な時間待ちを行うための機能 を用意している． (1) void sil_dly_nse(UINT dlytim) dlytimで指定された以上の時間（単位はナノ秒），ループなどによって待つ． 指定した値によっては，指定した時間よりもかなり長く待つ場合があるので注 意すること． 5.1.3 エンディアン プロセッサのエンディアンを知るためのマクロとして，以下のマクロを定義し ている． (1) SIL_ENDIAN リトルエンディアンプロセッサではSIL_ENDIAN_LITTLE（＝0），ビッグエンディ アンプロセッサではSIL_ENDIAN_BIG（＝1）にマクロ定義される． 5.1.4 メモリ空間アクセス関数 メモリ空間にマッピングされたデバイスレジスタや，デバイスとの共有メモリ をアクセスするために，以下の関数を用意している． (1) VB sil_reb_mem(VP mem) memで指定されるアドレスから，8ビット単位で読んだ値を返す． (2) void sil_wrb_mem(VP mem, VB data) memで指定されるアドレスに，dataで指定される値を8ビット単位で書き込む． (3) VH sil_reh_mem(VP mem) memで指定されるアドレスから，16ビット単位で読んだ値を返す． (4) void sil_wrh_mem(VP mem, VH data) memで指定されるアドレスに，dataで指定される値を16ビット単位で書き込む． (5) VH sil_reh_lem(VP mem) memで指定されるアドレスから，16ビット単位でリトルエンディアンで読んだ 値を返す．リトルエンディアンプロセッサでは，sil_reh_memと一致する． (6) void sil_wrh_lem(VP mem, VH data) memで指定されるアドレスに，dataで指定される値を16ビット単位でリトルエ ンディアンで書き込む．リトルエンディアンプロセッサでは，sil_wrh_memと 一致する． (7) VH sil_reh_bem(VP mem) memで指定されるアドレスから，16ビット単位でビッグエンディアンで読んだ 値を返す．ビッグエンディアンプロセッサでは，sil_reh_memと一致する． (8) void sil_wrh_bem(VP mem, VH data) memで指定されるアドレスに，dataで指定される値を16ビット単位でビッグエ ンディアンで書き込む．ビッグエンディアンプロセッサでは，sil_wrh_memと 一致する． (9) VW sil_rew_mem(VP mem) memで指定されるアドレスから，32ビット単位で読んだ値を返す． (10) void sil_wrw_mem(VP mem, VW data) memで指定されるアドレスに，dataで指定される値を32ビット単位で書き込む． (11) VW sil_rew_lem(VP mem) memで指定されるアドレスから，32ビット単位でリトルエンディアンで読んだ 値を返す．リトルエンディアンプロセッサでは，sil_rew_memと一致する． (12) void sil_wrw_lem(VP mem, VW data) memで指定されるアドレスに，dataで指定される値を32ビット単位でリトルエ ンディアンで書き込む．リトルエンディアンプロセッサでは，sil_wrw_memと 一致する． (13) VW sil_rew_bem(VP mem) memで指定されるアドレスから，32ビット単位でビッグエンディアンで読んだ 値を返す．ビッグエンディアンプロセッサでは，sil_rew_memと一致する． (14) void sil_wrw_bem(VP mem, VW data) memで指定されるアドレスに，dataで指定される値を32ビット単位でビッグエ ンディアンで書き込む．ビッグエンディアンプロセッサでは，sil_wrw_memと 一致する． なお，JSPカーネルのターゲット非依存部では，I/O空間にアクセスするための 関数を用意していないが，ターゲット依存部でサポートすることは可能である． 詳しくは，ターゲット毎のマニュアルを参照すること． 5.2 システムクロックドライバ システムクロックドライバは，ハードウェアタイマを用いて周期的に割込みを 発生させ，isig_timを呼び出してカーネルにタイムティックを供給する．シス テムクロックドライバは，システムコンフィギュレーションファイルに timer.cfgをインクルードすることで，システムに組み込むことができる． 5.2.1 システムクロックドライバの内部構成 システムクロックドライバは，タイマの起動処理，タイマ割込みハンドラ，タ イマの停止処理で構成される． (1) void timer_initialize(VP_INT exinf) タイマの起動処理．タイマを初期化し，周期的なタイマ割込み要求を発生させ る．カーネルに初期化ルーチンとして登録する．exinfは無視する． (2) void timer_handler() タイマ割込みハンドラ．タイマ割込み要求をクリアした後，isig_timを呼び出 してタイムティックを供給する．カーネルに割込みハンドラとして登録する． (3) void timer_terminate(VP_INT exinf) タイマの停止処理．周期的なタイマ割込み要求を停止させる．カーネルに終了 処理ルーチンとして登録する．exinf は無視する． 5.3 シリアルインタフェースドライバ シリアルインタフェースドライバは，シリアルポートを扱うためのドライバで ある．シリアルインタフェースドライバは，システムコンフィギュレーション ファイルにserial.cfgをインクルードすることで，システムに組み込むことが できる． シリアルインタフェースドライバは，ポート毎にセマフォを2個ずつ使用する． セマフォを生成する静的APIは，serial.cfgに含まれている． NEWLIBやGLIBCなどの標準Cライブラリを使用する場合には，標準Cライブラリ の低レベル入出力ルーチンをシリアルインタフェースドライバを呼び出すもの にすることで，タスクの標準入出力をシリアルインタフェースドライバ経由に 切り替えることができる．具体的な方法は，用いる標準Cライブラリに依存す る． 5.3.1 シリアルインタフェースドライバのサービスコール シリアルインタフェースドライバを呼び出すサービスコールの仕様は下記の通 りである．この中で，シリアルポートのID番号（portid）の解釈はターゲット 依存となる． これらのサービスコールは，非タスクコンテキストから呼び出すことはできな い．また，serial_rea_datとserial_wri_datは，ディスパッチ保留状態で呼び 出すことはできない．いずれも，呼び出した場合にはE_CTXエラーとなる． (1) ER serial_opn_por(ID portid) portidで示されるシリアルポートをオープンし，受信／送信が可能な状態にす る． (2) ER serial_cls_por(ID portid) portidで示されるシリアルポートをクローズする． (3) ER_UINT serial_rea_dat(ID portid, char *buf, UINT len) portidで示されるシリアルポートから，lenバイトの文字列を受信し，bufから の領域に入れる．lenバイト受信するまで，待ち状態となる．受信した文字数 またはエラーコードを返す． (4) ER_UINT serial_wri_dat(ID portid, char *buf, UINT len) portidで示されるシリアルポートに，bufからのlenバイトの文字列を送信する． lenバイト送信バッファに入れるまで，待ち状態となる．送信した文字数また はエラーコードを返す． (5) ER serial_ctl_por(ID portid, UINT ioctl) portidで示されるシリアルポートの制御情報を，ioctlで示される値に設定す る． ioctlには，以下の制御情報を表す定数を，ビット毎に論理和をとったものを 指定する． IOCTL_ECHO（エコーバックモード） このビットを設定すると，シリアルインタフェースドライバがエコー バックを行う．具体的には，バッファから文字を取り出す度に，その 文字を書き出す． IOCTL_CRLF（改行モード） LF（line feed）を書き出すと，CR（carriage return）+ LFに変換し て書き出す． IOCTL_FCSND（出力フロー制御） 文字を送信する処理に対して，XON/XOFFによるフロー制御を行う． すなわち，STOP（コントロール-S）を受信すると送信を停止し， START（コントロール-Q）を受信すると送信を再開する． IOCTL_FCANY（送信フロー制御で任意の文字で送信再開） IOCTL_FCOUTを指定している時に，送信停止中に受信した任意の文字 で送信を再開する． IOCTL_FCRCV（受信フロー制御） 文字を受信する処理に対して，XON/XOFFによるフロー制御を行う． すなわち，受信バッファの残り領域が少なくなるとSTOP（コントロー ル-S）を送出し，残り領域が増えればSTART（コントロール-Q）を送 出する． なお，オープン直後のデフォルトの設定値は(IOCTL_ECHO | IOCTL_CRLF | IOCTL_FCOUT | IOCTL_FCIN)である． (6) ER serial_ref_por(ID portid, T_SERIAL_RPOR *pk_rpor) portidで示されるシリアルポートの状態を参照し，pk_rporで指定されるパケッ トに返す．パケット中のreacntには受信バッファ中の文字数を，wricntには送 信バッファ中の文字数を返す． 5.3.2 シリアルインタフェースドライバの内部構成 シリアルインタフェースドライバは，前記のサービスコールに加えて，初期化 処理と割込みハンドラで構成される．初期化処理は，カーネルに初期化ルーチ ンとして登録する．割込みハンドラは，カーネルに割込みハンドラとして登録 する．これらの登録処理はserial.cfgに含まれる． (1) void serial_initialize(VP_INT exinf) シリアルインタフェースドライバを初期化する．カーネルに初期化ルーチンと して登録する．exinfは無視する． (2) 割込みハンドラ シリアルI/Oデバイスの種類によって，割込みハンドラの種類や数は異なる． 具体的には，送信割込みと受信割込みが別れているものと別れていないものや， ポートを複数持つシリアルI/Oデバイスでポート毎に割込みハンドラが別れて いるものと別れていないものがある．シリアルインタフェースドライバの割込 みハンドラは，カーネルに割込みハンドラとして登録する． 5.4 システムログタスク システムログタスクは，カーネル内のログバッファからログ情報を取り出し， デバイスにアクセスするサービスを用いて外部に出力するタスクである． JSPカーネルの標準配布キットに含まれるシステムログタスクは，シリアルイ ンタフェースにログ情報を文字列の形で出力するもので，システムログタスク の一例という位置付けで提供している．このシステムログタスクは，システム コンフィギュレーションファイルにlogtask.cfgをインクルードすることで， システムに組み込むことができる． ６．サポートライブラリ サポートライブラリは，アプリケーションやシステムサービスを作成するため に利用できるライブラリ関数群である．現バージョンでは，システムサービス やサンプルプログラムで使う最低限の関数しか用意していない． (1) const char *itron_strerror(ER ercd) ercd で示されるメインエラーコードに対応するエラーコードの文字列を返す． 返された文字列を書き換えてはならない． (2) void t_perror(const char *file, int line, const char *expr, ER ercd) エラーメッセージをシステムログサービスに出力する．assertマクロなどで利 用することを想定している． ７．開発環境・インストール・ポーティング 7.1 ディレクトリ・ファイル構成 ソースファイルのディレクトリ構成は次の通り． include/ 共通ヘッダファイル kernel/ カーネルソースファイル systask/ システムサービスソースファイル library/ サポートライブラリソースファイル config/ ターゲット依存部 m68k/ M68040 プロセッサ依存ファイル dve68k/ DVE-68K/40 システム依存ファイル sh1/ SH1 プロセッサ依存ファイル kz_sh1/ KZ-SH1-01 システム依存ファイル zunda_sh1/ ZUNDA/SH1 システム依存ファイル sh2/ SH2 プロセッサ依存ファイル apsh2f6a/ APSH2F6A システム依存ファイル hsb7616it/ HSB7616IT システム依存ファイル sh3/ SH3 プロセッサ依存ファイル ms7727cp01/ MS7727CP01 システム依存ファイル solution_engine/ Solution Engine システム依存ファイル sh3-ghs/ SH3 プロセッサ依存ファイル（GHS開発環境） ms7727cp01/ MS7727CP01 システム依存ファイル solution_engine/ Solution Engine システム依存ファイル h8/ H8 プロセッサ依存ファイル akih8_3048f/ AKI-H8/3048F システム依存ファイル akih8_3052f/ AKI-H8/3052F システム依存ファイル akih8_3069f/ AKI-H8/3069F システム依存ファイル nkev_010h8/ NKEV-010H8 システム依存ファイル h8-renesas/ H8 プロセッサ依存ファイル(Renesas開発環境) hsb8f3048bf25/ H8_3048F システム依存ファイル h8s/ H8S プロセッサ依存ファイル h8s2350/ H8S_2350 システム依存ファイル h8s2351/ H8S_2351 システム依存ファイル armv4/ ARMV4 プロセッサ依存ファイル integrator/ Integrator システム依存ファイル az9360mb/ AZ9360MB システム依存ファイル armv4-ghs/ ARMV4 プロセッサ依存ファイル（GHS開発環境） integrator/ Integrator システム依存ファイル microblaze/ MicroBlaze プロセッサ依存ファイル miref/ MIREF システム依存ファイル mire_multi/ MIRE_MULTI3000 システム依存ファイル mutlimedia/ MultiMedia Board システム依存ファイル suzaku/ Suzaku システム依存ファイル tms320c54x/ TMS320C54x プロセッサ依存ファイル c5402dsk/ TMS320VC5402 DSK システム依存ファイル xstormy16/ Xstormy16 プロセッサ依存ファイル simulator/ 三洋マイコン開発ツール環境 依存ファイル mips3/ MIPS3 プロセッサ依存ファイル vr4131/ VR4131 システム依存ファイル vr5500/ VR5500 システム依存ファイル m16c-renesas/ M16C プロセッサ依存ファイル(Renesas開発環境) oaks16/ OAKS16 システム依存ファイル oaks16_mini/ OAKS16_MINI システム依存ファイル m32c-renesas/ M32C プロセッサ依存ファイル(Renesas開発環境) oaks32/ OAKS32 システム依存ファイル m32r/ M32R プロセッサ依存ファイル m3a2131g50/ M3A-2131G50 システム依存ファイル m3a_za36/ M3A-ZA36 システム依存ファイル s1c33/ S1C33 プロセッサ依存ファイル dmt33209/ DMT33209 システム依存ファイル dmt33401/ DMT33401 システム依存ファイル luxun2/ LUXUN2 システム依存ファイル luxun4/ LUXUN4 システム依存ファイル s1c33-gnu33/ S1C33 プロセッサ依存ファイル(GNU33開発環境) dmt33209/ DMT33209 システム依存ファイル dmt33401/ DMT33401 システム依存ファイル luxun2/ LUXUN2 システム依存ファイル luxun4/ LUXUN4 システム依存ファイル powerpc32/ POWERPC32 プロセッサ依存ファイル ibm_ppc_emb_sample/ The IBM PowerPC Embedded Environment システム依存ファイル mpc860t/ MPC860T システム依存ファイル nios2/ NIOS2 プロセッサ依存ファイル altera_dev_board/ ALTERA_DEV システム依存ファイル v850/ V850 プロセッサ依存ファイル tk850_kj1/ TK-850ES システム依存ファイル tk850_sg2/ TK-850SG2 システム依存ファイル tlcs900-toshiba/ TLCS900 プロセッサ依存部ファイル zup_f16_ex/ Zup-F16拡張ボード システム依存ファイル linux/ Linux上のシミュレーション環境依存ファイル windows/ Windows上のシミュレーション環境依存ファイル tools/ 開発環境依存ディレクトリ WINDOWS/ Windows上のサンプルプログラムとプロジェクトファイル GHS/ GHS（Green Hills Software）開発環境用のファイル C5402DSK/ TMS320VC5402 DSK用のプロジェクトファイル H8-RENESAS/ H8-RENESAS用のプロジェクトディレクトリ M16C-RENESAS/ M16C-RENESAS用のプロジェクトディレクトリ M32C-RENESAS/ M32C-RENESAS用のプロジェクトディレクトリ pdic/ PDIC（デバイスドライバのOS非依存部分） simple_sio/ 簡易SIOドライバ（シリアルドライバが使用するもの） cfg/ カーネルコンフィギュレータ utils/ ユーティリティ h8/ H8用ベクターテーブル生成ユーティリティ h8-renesas/ H8-RENESAS用ベクターテーブル生成ユーティリティ m16c-renesas/ M16C-RENESAS用ベクターテーブル生成ユーティリティ sample/ サンプルプログラムと Makefile doc/ ドキュメント windev/ Windowsデバイスマネージャ ターゲット非依存部（カーネルコンフィギュレータは除く）の各ファイルの概 要は次の通り． README TOPPERS/JSPカーネルの簡単な紹介 configure コンフィギュレーションスクリプト include/ itron.h ITRON仕様共通規定に関連する定義 kernel.h μITRON4.0仕様に関連する定義 kernel_debug.h μITRON4.0仕様 デバッグ用インクルードファイル sil.h システムインタフェースレイヤ（SIL） t_stddef.h カーネル・アプリケーション 共通インクルードファイル t_config.h ターゲット依存情報の定義 t_syslog.h システムログサービス関連の定義 t_services.h アプリケーション用 標準インクルードファイル s_services.h デバイスドライバ用 標準インクルードファイル kernel_cfg.h kernel_cfg.c用のインクルードファイル timer.h システムクロックドライバ関連の定義 serial.h シリアルインタフェースドライバ関連の定義 logtask.h システムログタスク関連の定義 linux_sigio.h Linux用 ノンブロッキングI/Oサポート kernel/ Makefile.kernel カーネルのファイル構成の定義 jsp_kernel.h JSPカーネル用 標準インクルードファイル jsp_rename.def カーネルの内部識別名のリネーム定義 jsp_rename.h カーネルの内部識別名のリネーム jsp_unrename.h カーネルの内部識別名のリネーム解除 check.h エラーチェック用マクロ queue.h ダブルリンクキューの構造と操作 startup.c カーネルの初期化処理 banner.c カーネルの起動メッセージの出力 task.h タスク操作ルーチン関連の定義 task.c タスク操作ルーチン wait.h 待ち状態操作ルーチン関連の定義 wait.c 待ち状態操作ルーチン time_event.h タイムイベント管理関連の定義 time_event.c タイムイベント管理 syslog.h システムログ機能関連の定義 syslog.c システムログ機能 task_manage.c タスク管理機能 task_sync.c タスク付属同期機能 task_except.c タスク例外処理機能 semaphore.h セマフォ機能関連の定義 semaphore.c セマフォ機能 eventflag.h イベントフラグ機能関連の定義 eventflag.c イベントフラグ機能 dataqueue.h データキュー機能関連の定義 dataqueue.c データキュー機能 mailbox.h メールボックス機能関連の定義 mailbox.c メールボックス機能 mempfix.h 固定長メモリプール関連の定義 mempfix.c 固定長メモリプール time_manage.c システム時刻管理機能 cyclic.h 周期ハンドラ機能関連の定義 cyclic.c 周期ハンドラ機能 sys_manage.c システム管理機能 interrupt.h 割込み管理機能関連の定義 interrupt.c 割込み管理機能 exception.h CPU例外管理機能関連の定義 exception.c CPU例外管理機能 systask/ timer.c システムクロックドライバ timer.cfg システムクロックドライバの設定記述 serial.c シリアルインタフェースドライバ serial.cfg シリアルインタフェースドライバの設定記述 logtask.c システムログタスク logtask.cfg システムログタスクの設定記述 linux_sigio.c Linux用 ノンブロッキングI/Oサポート linux_sigio.cfg Linux用 ノンブロッキングI/Oサポートの設定記述 linux_serial.c Linux用 疑似シリアルドライバ linux_serial.cfg Linux用 疑似シリアルドライバの設定記述 cxxrt.c C++対応ランタイム本体 cxxrt.cfg C++対応ランタイム用オブジェクト設定 newlibrt.c NEWLIB対応ランタイム library/ log_output.c システムログ機能用ライブラリ関数（syslog_outputなど） strerror.c itron_strerror関数 t_perror.c t_perror関数 vasyslog.c syslog関数 utils/ makedep 依存関係定義の生成 genoffset offset.h 生成プログラム gencheck パラメータチェック用ファイルの生成 genrename 内部シンボルリネーム定義の生成 rename 内部シンボルのリネーム処理 sample/ Makefile サンプルの Makefile Makefile.linux サンプルの Makefile（Linux用） Makefile.mware サンプルの Makefile（ミドルウェアとの組み合わせ用） sample1.cfg サンプルプログラム(1)の設定記述 sample1.h サンプルプログラム(1)に関する定義 sample1.c サンプルプログラム(1)の本体 cxx_sample1.cfg C++用サンプルプログラム(1)の設定記述 cxx_sample1.h C++用サンプルプログラム(1)に関する定義 cxx_sample1.c C++用サンプルプログラム(1)の本体 cxx_sample2.cfg C++用サンプルプログラム(1)の設定記述 cxx_sample2.h C++用サンプルプログラム(1)に関する定義 cxx_sample2.c C++用サンプルプログラム(1)の本体 doc/ user.txt TOPPERS/JSPカーネル ユーザズマニュアル gnu_install.txt GNU開発環境構築マニュアル m68k.txt M68040 ターゲット依存部マニュアル sh1.txt SH1 ターゲット依存部マニュアル sh2.txt SH2 ターゲット依存部マニュアル sh3.txt SH3 ターゲット依存部マニュアル h8.txt H8 ターゲット依存部マニュアル h8-renesas.txt H8-RENESAS ターゲット依存部マニュアル h8s.txt H8S ターゲット依存部マニュアル armv4.txt ARMV4 ターゲット依存部マニュアル microblaze.txt MicroBlaze ターゲット依存部マニュアル tsm320c54x.txt TMS320C54x ターゲット依存部マニュアル xstormy16.txt Xstormy16 ターゲット依存部マニュアル mips3.txt MIPS3 ターゲット依存部マニュアル m16c.txt M16C ターゲット依存部マニュアル m32c.txt M32C ターゲット依存部マニュアル m32r.txt M32R ターゲット依存部マニュアル nios2.txt Nios2 ターゲット依存部マニュアル powerpc32.txt POWERPC32 ターゲット依存部マニュアル s1c33.txt S1C33 ターゲット依存部マニュアル v850.txt V850 ターゲット依存部マニュアル linux.txt Linux シミュレーション環境依存部マニュアル windows.txt Windows シミュレーション環境依存部マニュアル config.txt JSPカーネル ターゲット依存部 ポーティングガイド configurator.txt JSPカーネル コンフィギュレータ仕様 design.txt JSPカーネル 設計メモ 7.2 開発環境 JSPカーネルを用いたシステム構築には，以下のツールが必要である． ホスト環境用のツール 標準規格に準拠したCコンパイラ，Cライブラリ C++コンパイラ，C++ライブラリ，STL 動作確認: GNU C++ 2.95.3，3.2，3.3（Linux環境） GNU C++ 3.2（Cygwin環境） Visual C++ 6.0，.NET (Windowsシミュレーション) perl（動作確認は 5.6.1） GNU Make（動作確認は 3.79.1） クロス環境用のツール GNU開発環境 BINUTILS（アセンブラ，リンカなど） GCC または GCC-CORE（Cコンパイラ） GDB（デバッガ） NEWLIB（標準Cライブラリ） GNU開発環境をインストール方法については，「GNU開発環境構築マニュアル」 を用意しているので，それを参照するとよい．また，動作確認バージョンにつ いては，ターゲット毎のマニュアルを参照すること． ホスト環境用のCコンパイラとCライブラリは，クロス環境用のツールのインス トールに必要になる．また，C++コンパイラ，C++ライブラリと STL（Standard Template Library）は，カーネルのコンフィギュレーションツールのコンパイ ルに必要である．クロス環境用のツールとコンフィギュレーションツールをバ イナリで入手した場合には，これらのツールは必要ない． クロス環境用の標準Cライブラリは，アプリケーションが標準Cライブラリを使 用しない場合には，必要ない．ただし，コンパイラが標準Cライブラリ関数 （memcpy，memsetなど）を呼び出すコードを生成する場合があり，その場合に は標準Cライブラリが必要である．ないしは，生成したコードが呼び出す関数 のみを自分で用意してもよい． 以下では，これらのツールが用意できていることを前提に，UNIXマシン（動作 確認は Linux）上で構築手順を説明する．また以下の説明では，makeコマンド が GNU Make であるものとする（JSPカーネルの Makefile は，GNU Make の拡 張機能を用いている）． 7.3 コンフィギュレーションツールの構築 カーネルを構築する前に，まず，コンフィギュレーションツールをコンパイル する必要がある（コンフィギュレーションツールをバイナリで入手した場合に は，このステップは必要ない）． JSPカーネルのコンフィギュレーションツールは，コンフィギュレータ（cfgプ ログラム）とパラメータチェックプログラム（chkプログラム）から構成され る．コンフィギュレーションツールの使い方については，「7.9 コンフィギュ レーションツールの使い方」を参照すること． コンフィギュレーションツール（cfgプログラムとchkプログラム）は，cfgディ レクトリに移動し，make dependで依存関係ファイル（Makefile.depend）を生 成した後，makeコマンドにより生成される． % cd cfg % make depend % make また，Microsoft Visual C++ 6.0 (MSVC++6.0)でコンフィギュレーションツール をビルドするためのファイル群がJSPカーネルのソースファイルには含まれている． その際には，cfg/vc_project 内の configurator.dsw を開き，ビルドする． MSVC++6.0 と上位互換を持つ統合開発環境でもビルドできるはずであるが， 十分な確認が取れているわけではない． 7.4 サンプルプログラムの構築 次に，サンプルプログラムを構築する方法を説明する． まず，サンプルプログラムのオブジェクトファイルを置くディレクトリを作成 し，コンフィギュレーションスクリプトを実行する．例えば，オブジェクトファ イルを置くディレクトリを，JSPカーネルのソースファイルを展開したディレ クトリの下のOBJという名称のディレクトリにする場合には，次のコマンドを 実行する（ディレクトリの場所は名称は任意に決めてよい）． % mkdir OBJ % cd OBJ % perl ../configure -C m68k -S dve68k ここで，m68kはターゲットプロセッサ名，dve68kはターゲットシステム名であ る．これらのコンフィギュレーションスクリプトのオプションについては，次 の節で説明する． コンフィギュレーションスクリプトの実行により，カレントディレクトリには， サンプルプログラムを構築するためのMakefile，サンプルプログラム用のコン フィギュレーションファイル（sample1.cfg），サンプルプログラム本体 （sample1.hおよびsample1.c）が生成される． コンフィギュレーションスクリプトの実行後，必要であればMakefileを修正す る．Makefileの修正方法については，「7.7 Makefileの修正」を参照すること． その後，make dependで依存関係ファイル（Makefile.depend）を生成した後， makeコマンドによりサンプルプログラムのロードモジュール（jspまたは jsp.exe）が生成できる．依存関係ファイルの生成には若干時間がかかる． % make depend % make ここで構築したサンプルプログラム（sample1.h，sample1.c，sample1.cfg） は，JSPカーネルの基本的な動作を確認するためのものである．このプログラ ムの概要説明は，sample1.cの先頭のコメントにある． 7.5 アプリケーションとカーネルを別々に構築する方法 前節で説明した方法では，アプリケーションとカーネルを同時に生成するため， オブジェクトファイルを置くディレクトリに非常に多くのファイルが作成され て，扱いにくくなる．そこで，カーネルを修正する頻度が低い場合には，カー ネルは事前に構築しておき，後でアプリケーションだけを構築する方法を用意 している．以下では，サンプルプログラムを構築を例に，その手順について説 明する． まず，カーネルを構築するディレクトリを作成し，コンフィギュレーションス クリプトを実行する．例えば，カーネルを構築するディレクトリを，JSPカー ネルのソースファイルを展開したディレクトリの下のkernel_libという名称の ディレクトリにする場合には，次のコマンドを実行する（ディレクトリの場所 は名称は任意に決めてよい）． % mkdir kernel_lib % cd kernel_lib % perl ../configure -C m68k -S dve68k これにより，カーネルを構築するディレクトリに，Makefile，sample1.cfg， sample1.h，sample1.cが生成されるが，Makefile以外は使用しない． make dependで依存関係ファイル（Makefile.depend）を生成した後，make libkernel.aによりカーネルライブラリ（libkernel.a）が生成できる． % make depend % make libkernel.a 次に，アプリケーションを構築するディレクトリを作成し，コンフィギュレー ションスクリプトを実行する．例えば，アプリケーションを構築するディレク トリを，JSPカーネルのソースファイルを展開したディレクトリの下のAPLとい う名称のディレクトリにする場合には，次のコマンドを実行する（ディレクト リの場所は名称は任意に決めてよい）． % cd .. % mkdir APL % cd APL % perl ../configure -C m68k -S dve68k -L ../kernel_lib ここで-Lオプションには，カーネルを構築したディレクトリのパスを指定する． 最後に，make dependで依存関係ファイル（Makefile.depend）を生成した後， makeコマンドによりサンプルプログラムのロードモジュール（jspまたは jsp.exe）が生成できる． % make depend % make この手順では，アプリケーション構築時にはカーネルの再構築が必要かチェッ クしないため，カーネルのソースコードを修正した場合には，カーネルを構築 したディレクトリでmake libkernel.aを再実行する必要がある．また，アプリ ケーション構築時にカーネルライブラリが更新されたかチェックしないため， アプリケーションを構築したディレクトリで，ロードモジュールを削除した後 にmakeを再実行する必要がある． 以上では，カーネルとアプリケーションを別々のディレクトリで構築したが， -Lオプションにカレントディレクトリ（"."）を指定することで，同じディレ クトリで（別々に）構築することもできる．具体的には，次の手順となる． % mkdir OBJ % cd OBJ % perl ../configure -C m68k -S dve68k -L . % make depend % make libkernel.a % make cleankernel % make ここで，make cleankernelは，カーネルライブラリを生成するための中間ファ イルを削除するものである．この手順では，make dependによりカーネルライ ブラリに関する依存関係を生成しないため，カーネルのソースコードを修正し た場合には，必ずmake cleankernel（または，make clean）してから，make libkernel.aする必要があるので注意すること．さらに，ロードモジュールを 削除した後にmakeを再実行する必要があるのは，前の場合と同様である． 7.6 コンフィギュレーションスクリプトの使い方 コンフィギュレーションスクリプトは，JSPカーネルおよびアプリケーション プログラムを構築するために必要な基本的なコンフィギュレーションを行うた めのプログラムである．JSPカーネルを用いてアプリケーションを作成する場 合には，まずオブジェクトファイルを置くディレクトリを作成し，そのディレ クトリでコンフィギュレーションスクリプトを実行する．オブジェクトファイ ルを置くディレクトリの場所や名称は，任意に決めてよい． コンフィギュレーションスクリプトに対するオプションは次の通り． -C <プロセッサ名> ターゲットプロセッサ名またはシミュレーション環境名を，configディ レクトリの下のディレクトリ名称で指定する（必須）． -S <システム名> ターゲットシステム名を，configの下のプロセッサのディレクトリの 下のディレクトリ名称で指定する．シミュレーション環境の場合には， 指定する必要がない． -T <開発環境名> 開発環境名を，configの下のディレクトリ名称の後半の名称で指定す る．GNU開発環境を用いる場合には，指定する必要がない． -A <アプリケーションプログラム名> アプリケーションプログラムの名称を指定する．省略した場合には， 標準のサンプルプログラム（sample1）となる． -U <オブジェクトファイル名> アプリケーションプログラムのメインのオブジェクトファイル（-A で指定したアプリケーションプログラム名に".o"を付加したもの）以 外に，リンクすべきオブジェクトファイルの名称を，".o"を付加した 形で指定する．""で囲むことによって，複数のファイルを指定するこ とも可能である（-U オプションを複数使ってはならない）． -L <カーネルライブラリのディレクトリ名> 事前に構築したカーネルを用いて，アプリケーションのみを構築する 場合には，このオプションにカーネルライブラリ（libkernel.a）の 置かれたディレクトリ名を指定する．このオプションの使用方法につ いては，「7.5 アプリケーションとカーネルを別々に構築する方法」 を参照すること． -D JSPカーネルのソースコードを置いたディレクトリ名を指定する．省 略した場合には，configureの置かれているディレクトリとなる． コンフィギュレーションスクリプトが行う処理は次の通りである． (1) Makefileの生成 sampleディレクトリから適切なMakefileを選択し，必要な箇所を書き換えて， Makefileを生成する． (2) サンプルプログラムの生成 指定したアプリケーションプログラムがsampleディレクトリにある場合，適切 なサンプルプログラムのソースファイルを選択し，必要な箇所を書き換えて， サンプルプログラムのソースファイル（例えば，sample1.h，sample1.c， sample1.cfg）を生成する． 7.7 Makefileの修正 JSPカーネルの実行環境によっては，コンフィギュレーションスクリプトが生 成したMakefileを修正することが必要になる．ここでは，Makefileの中で，修 正が必要となる可能性の高い箇所について説明する． なお，Makefileを修正した後にコンフィギュレーションスクリプトを再実行す ると，修正したMakefileが上書きされてしまうので注意すること（古いものが Makefile.bakに保存される）． (A) ターゲット名の定義 CPUはターゲットプロセッサ名，SYSはターゲットシステム名，TOOLは開発環境 名に定義する．これらの定義は，コンフィギュレーションスクリプトが行う． (B) オブジェクトファイルの拡張子の設定 Cygwin環境でコンパイルする時には，OBJEXTを"exe"に定義する必要がある． これは，Cygwin環境では，オブジェクトプログラムに拡張子"exe"が付加され るのに対応するためのものである．Cygwin環境であることを判定できれば，コ ンフィギュレーションスクリプトがこの定義を行う． (C) 実行環境の定義（ターゲット依存） ターゲットによっては，実行環境に対応してターゲット依存部のコードを差し 換える場合がある．これを可能にするために，実行環境の名称をDBGENVに定義 している．標準では，GDBスタブを用いることを想定して，これをGNU_STUBに 定義しているが，ターゲット依存の定義を入れたMakefile.configで上書きさ れる場合もある．どのターゲットがどの実行環境に対応しているかは，ターゲッ ト毎のマニュアルを参照すること． (D) カーネルライブラリのディレクトリ名の定義 KERNEL_LIBには，カーネルライブラリの置かれたディレクトリ名を定義する． この定義は，通常はコンフィギュレーションスクリプトが行うが，事後に KERNEL_LIBの定義を変更してもかまわない． (E) 共通コンパイルオプションの定義 全体に共通するコンパイルオプションの追加が必要な場合には，下の変数の定 義を変更する．そのコンパイルオプションが，特定のターゲットで常に必要な 場合には，ターゲット依存の定義を入れたMakefile.configを修正すべきであ る．追加の可能性のあるコンパイルオプションについては，「7.8 コンパイル オプション」を参照のこと． CDEFS -D オプションを記述する． INCLUDES -I オプションを記述する． COPTS コンパイラに対するその他のオプションを記述する． LDFLAGS リンカに対するオプションを記述する． LIBS ライブラリリンクのためのオプションを記述する． (F) アプリケーションプログラムに関する定義 アプリケーションプログラムが一つのCソースファイル（*.c）のみで構成され ている場合には，UNAMEにそのファイル名を定義すればよい．アプリケーショ ンプログラムが複数のソースファイルで構成される場合には，UNAMEにそのア プリケーション名を定義し，オブジェクトファイル名をUTASK_ASMOBJSおよび UTASK_COBJSに列挙する．いずれの場合にも，コンフィギュレーションファイ ルは，UNAMEに定義した名前に拡張子"cfg"を付加した名前とする． ソースファイルをコンパイルするのとは別のディレクトリに置く場合には， UTASK_DIRSにそのディレクトリを追加する．また，アプリケーションのコンパ イルに必要なコンパイルオプションや，アプリケーションがライブラリを必要 とする場合には，UTASK_CFLAGSおよびUTASK_LIBS に定義する． (G) オブジェクトファイル名の定義 オブジェクトファイル名をOBJNAMEに定義する．デフォルトはjspである． (H) ターゲットファイルの定義 ロードモジュールの形式を指定する．具体的には，ELF形式の時は$(OBJFILE) または$(OBJNAME).out（PARTNER-J環境の時），バイナリ形式の時は $(OBJNAME).bin，モトローラ S形式の時は$(OBJNAME).srecを指定する． $(OBJFILE) は，Cygwin環境でOBJEXTを"exe"に定義した時には$(OBJNAME).exe， そうでない場合には$(OBJNAME)となる． (I) カーネルのコンフィギュレーションファイルの生成 ソフトウェア部品のコンフィギュレータを追加する場合には，この規則を修正 することが必要である． 7.8 コンパイルオプション JSPカーネルのコード中には，assertマクロが使われている．assertマクロは， NDEBUGを定義することで，オブジェクトコード中から消すことができる．カー ネルのデバッグが終了すれば，CDEFSに-DNDEBUGを指定してコンパイルした方 が効率がよくなる． また，システムログ機能を取り外すためのOMIT_SYSLOGを用意している．詳し くは，「4.8 システムログ機能の設定方法」を参照すること． 7.9 コンフィギュレーションツールの使い方 以下では，cfgプログラムとchkプログラムのオプションについて説明する．こ れらのプログラムによるコンフィギュレーション手順については，「2.10 静 的APIとコンフィギュレータ」を参照すること． cfgプログラムとchkプログラムに共通のオプションは次の通り． -cpu <プロセッサ名> ターゲットプロセッサ名を指定する． -system <システム名> ターゲットシステム名を指定する． -h, --help ヘルプメッセージを表示する． -v 処理の途中結果を表示する． -le, --english メッセージを英語で表示する（デフォルト）． -lj, --japanese メッセージを日本語で表示する． cfgプログラムに対するオプションは次の通り． -s, --source <ファイル名> <ファイル名>で指定されたシステムコンフィギュレーションファイル （C言語のプリプロセッサで処理したもの）を読み込む．<ファイル名> を省略した場合は，システムコンフィギュレーションファイルを標準 入力から読み込む（オプション自身を省略してはならない）． -c, --check 静的APIのパラメータチェックに用いるファイルをkernel_chk.cに生 成する（デフォルトでは生成しない）． -obj, --dump-object <ファイル名> 静的APIの解析内容を含むオブジェクト定義ファイルを，<ファイル名> で指定されたファイルに生成する．<ファイル名>を省略した場合は， kernel_obj.datに生成する． -z, --nonzero __EMTPY_LABELマクロの使用を抑止する． -ao=xxx IDの割付順序を指定する．xxxに指定できる内容は次の通り． alphabetic 名称の昇順（Aに近いものほど小さな値） fcfs 定義順の昇順 (先に宣言したものほど小さな値) alphabetic,reverse 名称の降順 fcfs,reverse 定義順の降順 -id=<ファイル名> 自動ID割付け結果ヘッダファイル（kernel_id.h）の名称を変更する． -cfg=<ファイル名> カーネル構成ファイル(kernel_cfg.c)の名称を変更する． -oproto ハンドラやタスク本体などの関数のプロトタイプ宣言をカーネル構成 ファイル（kernel_cfg.c）に出力する． -il カーネル関連のヘッダをインクルードする際に，"ファイル名" ではなく <ファイル名> を使用する． -1.3 TOPPERS/JSPカーネル Release 1.3互換の形式で生成する． （注意: -1.3で生成したファイルは1.4以降では使用できない） -iapi カーネルコンフィギュレータが処理できない静的APIを無視する． -t カーネルコンフィギュレータが処理できない静的APIを標準出力に出力 する． -ext 標準外の拡張機能の使用を許可する． chkプログラムに対するオプションは次の通り． -m, --module <モジュール記述> チェックするロードモジュールを指定する．標準のchkプログラムは， ロードモジュールのシンボルファイル（GNU BINUTILSのnmが出力する 形式）とモトローラSレコードファイルを読み込んでパラメータチェッ クを行なう．この場合，<モジュール記述>には，シンボルファイルと Sレコードファイルの2つを","で区切って指定する． -cs, --script <ファイル名> <ファイル名>で指定されたチェックファイルを用いてチェックする． チェックファイルとは，cfgプログラムが生成したkernel_chk.cを， コンパイラおよび utils/gencheck により加工したファイルのことで ある．このオプションを省略した場合，いくつかのチェックが行われ なくなる．オプションを指定した場合には，<ファイル名>は省略でき ない． -obj, --load-object <ファイル名> 静的APIの解析内容を含むオブジェクト定義ファイルを，<ファイル名> で指定されたファイルから読み込む．<ファイル名>を省略した場合は， kernel_obj.datから読み込む． -cl <エラーレベル> エラー検出レベルを変更する．レベルはLAZY（重大なエラーのみ検 出），STANDARD（ITRON仕様の範囲のみで検出），TOPPERS（JSPカー ネルの制限違反まで検出），RESTRICTED（すべてのエラーを検出）の 4種類のうちから選択する（デフォルトはRESTRICTED）． 7.10 リンカスクリプトとメモリ領域 JSPカーネルのリンク方法は，ターゲット依存のリンカスクリプト（*.ld）に 記述されている．サンプルプログラムの Makefile では，ターゲット依存の定 義を入れた Makefile.config の中で LDSCRIPT を定義すると，定義した名前 のファイルをリンカスクリプトに用いる． JSPカーネル動作時には，以下のメモリ領域が必要になる． (a) コード領域 カーネルおよびアプリケーションのプログラムおよび定数データが置かれる領 域．ROM上に置くことも可能である．先頭アドレスを，カーネルをリンクする 際の -Ttext オプションで指定する．サンプルプログラムの Makefile では， ターゲット依存の定義を入れた Makefile.config の中で TEXT_START_ADDRESS を定義すると，リンク時に -Ttext オプションが付加される． (b) データ領域 カーネルおよびアプリケーションの使用するデータ領域．固定的なデータ領域 と，sbrk関数によって取られるヒープ領域からなる．カーネルはヒープ領域を 使用しない．先頭アドレスを，カーネルをリンクする際の -Tdata オプション で指定する．サンプルプログラムの Makefile では，ターゲット依存の定義を 入れた Makefile.config の中で DATA_START_ADDRESS を定義すると，リンク 時に -Tdata オプションが付加される． (c) 非タスクコンテキスト用のスタック領域 割込みハンドラなどの非タスクコンテキストが使用するスタック領域．領域の 設定方法はターゲット依存であるが，通常は，ターゲットシステム依存のイン クルードファイル（sys_config.h）でスタックの初期値を定義し，ターゲット プロセッサ依存のスタートアップモジュール（start.S）中で初期化される． 7.11 他のターゲットへのポーティング JSPカーネルを他のターゲットへポーティングするために必要な作業は，カー ネル自身のポーティング，システムサービスのポーティング，開発環境の構築 と標準の開発環境との差異の吸収などからなる．詳しくは，「JSPカーネル タ ーゲット依存部 ポーティングガイド」（config.txt）を参照すること． 7.12 カーネルの内部識別子のリネーム μITRON4.0仕様は，カーネルの内部識別子を_kernel_または_KERNEL_で始める ことを要求している．ところが，カーネルのソースコード中で直接このような 識別子を用いると，識別子の長さが長くなり，可読性を損なう．そこでJSPカー ネルでは，xxxxxというカーネルの内部識別子を_kernel_xxxxxにリネームする 仕組みを入れている． ところが，この仕組みにより，デバッグ作業が非効率になるケースが考えられ る．具体的には，ソースコード中の識別子がオブジェクトコード中の識別子と 一致しないために，ソースコード中の変数を指定してその値を読んだり，関数 を指定してそこにブレークポイントを置くといったことができない． この問題を解決するために，JSPカーネルでは，ソースコード中の必要な識別 子をリネームするためのユーティリティ（utils/rename）を用意している． renameユーティリティに，リネーム定義ファイル（xxx_rename.def）のプリ フィックス（xxxの部分）と，リネームしたいファイルリストを与えると，リ ネーム処理を行なう．例えば，kernelディレクトリのすべてのファイルに対し て，カーネルの内部識別名をリネームするには，次のコマンドを用いればよい． % cd kernel % ../utils/rename jsp * ８．その他 8.1 ウェブサイト TOPPERSプロジェクトおよびJSPカーネルのためのウェブサイトを，以下のURL に用意している． http://www.toppers.jp/ 配付キットの最新版は，このウェブサイトからダウンロードすることができる． また，後述のメーリングリストのアーカイブなども，このウェブサイトで閲覧 することができる． 8.2 利用条件・著作権 JSPカーネルの利用条件は，各ファイルの先頭に明示されている（このドキュ メントの先頭にもついている）．著作権は，各ファイルの先頭に表示されてい る著作権者が保有している． 利用条件の (3) の (b) において，利用の形態をTOPPERSプロジェクトに報告 する方法としては，JSPカーネルを利用した製品の名称と応用分野，製品化し た会社名と業種等の情報を，以下のURLのページから報告するものとする． http://www.toppers.jp/report.html またその際に，JSPカーネルを使用してのコメントやご意見もいただけると幸 いである． 8.3 保証・サポート・適用性 JSPカーネルは無保証で提供されているものである．開発者は，その適用可能 性も含めて，いかなる保証も行わない．また，サポートの約束もしていない． 質問がある場合は，後述のメーリングリストを利用していただけると幸いであ る． 8.4 メーリングリスト JSPカーネルのユーザに対する情報提供およびユーザ相互間の情報交換を容易 にするために，TOPPERSユーザズメーリングリストを用意している．このメー リングリストには，誰でも自由にメールを送付することができる．また，送付 されたメールは，誰でも自由にウェブサイトで読むことができる．JSPカーネ ルにバグや問題点を発見した場合には，このメーリングリストに報告して欲し い． メーリングリストへのメールの送付先は次の通り． users@toppers.jp メーリングリストにバグや問題点などを報告する場合には，必要に応じて，次 の情報を知らせて欲しい． ターゲットに関する情報 ・ターゲットプロセッサの種類 ・ターゲットボードの種類 ホストに関する情報 ・OSのバージョン（サービスパックの適用状況も） ・コンパイラなどの開発環境のバージョン（Cygwinのバージョンも） このメーリングリストへの登録を希望する場合は，まず， users-ctl@toppers.jp 宛てに，本文に subscribe あなたの名前 例: subscribe Hiroaki Takada と書いたメールを送付する（上記のコマンド中には半角英文字のみを使うこと）． 折り返し，登録確認のためのメールが送られてくるので，その指示に従って登 録する． 8.5 TOPPERSプロジェクトへの参加 TOPPERSプロジェクトでは，何からの形でプロジェクトに貢献されたい方，プ ロジェクトで開発したソフトウェアをお使いの方，プロジェクトに興味をお持 ちの方の参加を求めている．TOPPERSプロジェクトへの参加方法については， TOPPERSプロジェクトのウェブサイトを参照すること． 8.6 ミドルウェア用の Makefile サンプルディレクトリにある Makefilew.mware はJSPカーネルにミドルウェア を組み合わせてコンパイルするための Makefile である．この Makefile から インクルードするミドルウェア用の Makefile では，以下の変数を定義するこ と． (1) MTASK_CFG ミドルウェアのコンフィギュレーションファイル（ソース）を追加する． (2) MTASK_KERNEL_CFG ミドルウェアのコンフィギュレータから出力され，JSPカーネル のシステムコ ンフィギュレーションファイルにインクルードされるファイルを追加する． (3) MTASK_DIR ミドルウェアのディレクトリを追加する． (4) MTASK_LCSRCS ミドルウェアをライブラリ化するソースファイルを追加する． (5) MTASK_ASMOBJS ミドルウェアのアセンブリ言語のオブジェクトファイルを追加する． (6) MTASK_CXXOBJS ミドルウェアの C++ 言語のオブジェクトファイルを追加する． (7) MTASK_COBJS ミドルウェアの C 言語のオブジェクトファイルを追加する． (8) MTASK_CFLAGS ミドルウェアをコンパイルするときのオプションを指定する． (9) MTASK_LIBS ミドルウェアのライブラリを追加する． (10) MAKE_MTASK ライブラリ化したミドルウェアを指定する． ９．リファレンス 9.1 サービスコール一覧 (1) タスク管理機能 ER ercd = act_tsk(ID tskid); ER ercd = iact_tsk(ID tskid); ER_UINT actcnt = can_act(ID tskid); void ext_tsk(); ER ercd = ter_tsk(ID tskid); ER ercd = chg_pri(ID tskid, PRI tskpri); ER ercd = get_pri(ID tskid, PRI *p_tskpri); (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 = 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(); (4) 同期・通信機能 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 = 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 = 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 = 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); (5) メモリプール管理機能 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); (6) 時間管理機能 ER ercd = set_tim(const SYSTIM *p_systim); ER ercd = get_tim(SYSTIM *p_systim); ER ercd = isig_tim(); ER ercd = sta_cyc(ID cycid); ER ercd = stp_cyc(ID cycid); (7) システム状態管理機能 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(); BOOL state = vsns_ini(); (8) 割込み管理機能 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); ※ xx，xxxx，XXXX はターゲット毎に定められる． (9) CPU例外発生時のシステム状態参照 BOOL state = vxsns_ctx(VP p_excinf); BOOL state = vxsns_loc(VP p_excinf); BOOL state = vxsns_dsp(VP p_excinf); BOOL state = vxsns_dpn(VP p_excinf); BOOL state = vxsns_tex(VP p_excinf); (10) 性能評価用システム時刻参照機能 ER ercd = vxget_tim(SYSUTIM *p_sysutim); 9.2 静的API一覧 CRE_TSK(tskid, { ATR tskatr, VP_INT exinf, FP task, PRI itskpri, SIZE stksz, VP stk }); DEF_TEX(ID tskid, { ATR texatr, FP texrtn }); 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 }); CRE_MPF (ID mpfid, { ATR mpfatr, UINT blkcnt, UINT blksz, VP mpf } ) ; CRE_CYC (ID cycid, { ATR cycatr, VP_INT exinf, FP cychdr, RELTIM cyctim, RELTIM cycphs } ) ; DEF_INH(INHNO inhno, { ATR inhatr, FP inthdr }); DEF_EXC(EXCNO excno, { ATR excatr, FP exchdr }); ATT_INI({ ATR iniatr, VP_INT exinf, FP inirtn }); VATT_TER({ ATR teratr, VP_INT exinf, FP terrtn }); 9.3 メインエラーコード一覧（JSPカーネルが返すもののみ） E_PAR -17 パラメターエラー E_ID -18 不正ID番号 E_CTX -25 コンテキストエラー E_ILUSE -28 サービスコール不正使用 E_OBJ -41 オブジェクト状態エラー E_QOVR -43 キューイングオーバーフロー E_RLWAI -49 待ち状態の強制解除 E_TMOUT -50 ポーリング失敗またはタイムアウト 9.4 バージョン履歴 2000年11月15日 Release 1.0 最初のリリース 2000年11月24日 Release 1.0 (PL=1) 問題点の修正 2001年2月24日 Release 1.1 V850の追加など 2001年5月9日 Release 1.1 (PL=1) SH1の追加など 2001年11月15日 Release 1.2 SH4，H8，ARM7TDMIの追加など 2002年4月15日 Release 1.3 M32R，MicroBlaze，TMS320C54x， i386，H8Sの追加など 2003年12月25日 Release 1.4 多数の改良 2004年10月14日 Release 1.4 (PL=1) SH2，M16C，SC33，PowerPC32， Nios2の追加など 2005年11月28日 Release 1.4 (PL=2) M32C-Renesas, H8-Renesas, H8S-Renesas, V850 2007年6月1日 Release 1.4 (PL=3) 問題点の修正，東芝TLCS900の追加など 以上