| (a) | μITRON4.0仕様に準拠しているというために必要な最低限の機能を持っていること． |
| (b) | μITRON4.0仕様で規定されている機能と同等の機能を持つ場合には，その機能仕様が，μITRON4.0仕様の規定に合致していること．ただし，コンフィギュレータを用意しない場合には，μITRON4.0仕様の静的APIの仕様に合致している必要はない． |
| (c) | μITRON4.0仕様で規定されていない機能を持つ場合には，その機能仕様が，μITRON4.0仕様が実装独自の拡張方法に関して設けている規定に合致していること．ただし，実装が複数種類のAPIをサポートする場合には，μITRON4.0仕様準拠のAPI以外のAPIに対してはこの規定は適用されない． |
第2世代 Xiaoの検討その2
| 作成日 | : | 2020/07/09 |
|---|---|---|
| 最終更新日 | : | 2020/07/09 |
第2世代 Xiaoの検討その2
| 作成日 | : | 2020/07/09 |
|---|---|---|
| 最終更新日 | : | 2020/07/09 |
概要
第2世代のXiaoの仕様について検討します。今回はμITRON4.0仕様[1]について主に検討します。
μITRON4.0仕様準拠の条件
μITRON4.0仕様 Ver.4.03.03の第5章に仕様に準拠しているというための条件が記されています。
表1. μITRON4.0仕様準拠の条件
(a)については別に規程されているので後で考えることにします。(b)については問題はないでしょう。悩ましいのは(c)ですが、μITRON4.0仕様準拠でないAPIに対してはこの規定は適用されないとあるので独自仕様のAPIの追加は問題ない認識で良さそうです。
ただし、別項にμITRON4.0仕様で規程されていない実装独自の機能を持つ場合には、実装について説明する製品マニュアルなどでそれらの点を明示しなければならないとあるので注意が必要そうです。
μITRON4.0仕様準拠の最低機能
μITRON4.0仕様準拠の条件の(a)について必要な最低限の機能が以下になります。
表2. μITRON4.0仕様準拠の最低条件
| (a) | タスクを生成できること．タスクは少なくとも，実行状態，実行可能状態，休止状態の3つの状態を持つこと． |
| (b) | μITRON4.0仕様のスケジューリング規則に従ったタスクスケジューリングを行うこと．ただし，優先度毎のタスクを1つに制限することや，優先度を1段階に制限することは許される |
| (c) | 割込みハンドラ（または割込みサービスルーチン）を登録できること． |
| (d) | タスクおよび割込みハンドラ（または割込みサービスルーチン）から，タスクを起動する（休止状態から実行できる状態にする）手段が用意されていること． |
| (e) | 自タスクを終了する（実行状態から休止状態にする）手段が用意されていること． |
ここで、タスクスケジューリングを優先度に基づくプリエンプティブな優先度ベーススケジューリング方式であり、同じ優先度を持つタスクはFirst Come First Served(FCFS)方式でスケジューリングを実現できればよいです。サービスコールとしては以下をサポートすれば満たすことができると記されています。
表3. 必要最低限のサービスコール
| CRE_TSK | タスクの生成 |
| act_tsk/iact_tsk | タスクの起動 |
| ext_tsk | タスクの終了 |
| DEF_INH | 割込みハンドラの定義 |
実装しなければならないものをここまで減らせるとなると、実装できるのではないかという気がしてきます。
μITRON4.0仕様に対する拡張
μITRON4.0仕様準拠の条件の(c)に関する条項です。μITRON4.0仕様に規程されていない機能を実現するために独自にサービスコールを追加する場合にはサービスコール名称の前に「v」を付与する必要があるようです。
上記を踏まえた現時点での結論
第2世代のXiaoとしては、まず「μITRON4.0仕様の最低条件に合致するOSを実装する」が基点になりそうです。その上で「μITRON4.0仕様に沿う形で機能拡張を進める」ものと「別路線で機能拡張を進める」ものとに分かれそうです。別路線は例えばセンサノード向けのOSとしてタスクスケジューリングアルゴリズムを変更したものが一番考えられそうです。そうなった場合、μITRON4.0仕様互換のAPIを持つOSという形になるのでしょうか。
次はTOPPERS/SSPカーネルについて掘り下げて調べます。