TOPPERSのメインターゲットを考えてみる
TOPPERSはiTRONの全関数が使えるわけではない。個人的に一番やっかいだと思ったのが cre_tsk() / cre_flg() といったOSリソースを稼働中に生成する関数がないことだ。
稼働中にOSリソースが作れないとライブラリを作るときに「最初に静的生成でスタックサイズ10KBのタスクをID何番〜何番まで３個作っておいてください。イベントフラグとセマフォもID何番〜何番まで３個必要です。その後main関数からxxx_start(）関数を実行してください。」という指定が必要になるからだ。こんな方式のライブラリがいっぱいできると、
- 各ライブラリでIDが重複する可能性がある。
- 製品仕様でタスク数を変えたい場合（例えばHTTPサーバ）、複数の箇所を変更しないといけない
という問題がある。また、稼働中のリソース生成をサポートしている商用iTRONからOSを移植する時に初期化シーケンスを一から作り直す必要があるだろう。
TOPPERSが静的生成をサポートしない理由はきっとメインターゲットの要望にないから。その辺の関係を図にしてみた。
TOPPERSに主に口（＆金＆人）を出しているのはトヨタ関連企業、JAXAなので省メモリ、高信頼用の機能を優先しているのだろう。
