(toppers-users 3129) Re: cq_starmのCFGについて

[yasuo kominami(nifty)]

小南です。

2010/3/31 koizumi yoshiyuki <koizumiyoshiyuki ＠ gmail.com>:
> 小南さま
>
> 　有難うございます。小生、UARTのポートの修正はオリジナルとは異なる手法をとりました。オリジナルはUART#2を使う場合はUART#1のバッファも確保しています。UARTを2台使用できるようにして、2台目を使用するようにしていますが、小生はメモリの制限を考慮しUARTはコンソールとしてしか使用しないので、一台のUARTのバッファとしています。ご指摘の#define
> INTNO_SIO
> IRQ_VECTOR_USART2は有効になっています。小生の考え方は間違ってはいないようなので、.tfファイルをいじって色々試しています。時間があれば、何処かにたどり着けると思っています。
>
了解しました。

> 　追加の質問ですが、CFGのバージョン問題の話が出ていましたが、JSP用のcfgとASP用のcfgは同じものと考えてよいのでしょうか。ASP用のｃｆｇをJSPで使用しても問題は無いか知りたいのです。Cortex-M3用のJSPを考えています。（簡単ではないとは思っています）
>

ASPのcfgとJSPのcfgはまったく別の実装です。

また、ASP用の*.cfgファイルと、JSP用の*.cfgファイルも非互換の部分があり、そのままでは異なるコンフィギュレータには処理出来ません。
sample1.cfgでもそれぞれのものを使う必要があります。

JSPのcfgの入力ファイルは、コンフィギュレーションファイル(*.cfg)のみですが、ASPのcfgは*.tfファイルも必要になります。

また、JSPのcfgは*.cfgをCプリプロセッサで処理した後のものを解釈しますが、ASPのcfgは生の*.cfgを解釈します。

ASPのcfgは、ASPだけのcfgではなく、TOPPERSの新世代カーネルのcfgという位置づけになります。
以前のカーネルは、JSPの開発後、それをベースにFMDPとかFI4とかHRPとかを開発していましたが、そのたびにcfgを拡張するとか、新たにcfgを開発するのか常に課題になっていました。

そこであらかじめ拡張が容易に行える構造のものを開発することにしました。
それが、現在のcfgです。

また、JSPのcfgでは対応が難しかった、（それぞれのターゲット依存部に有った）静的APIの（パラメータの）エラーチェックや、データ構造の生成なども行えるようになっています。

kernelディレクトリや、targetディレクトリの下にある*.tfファイルをcfgが解釈実行することで実現しています。

また、*.cfgの文法もJSPのものから変更された部分があります。
これは、JSPなどれの利用経験からのフィードバックに基づき、こちらの方が使い易い（利用されやすい）と判断したものです。
その意味では厳密なuITRON4.0仕様準拠ではなく、TOPPERSのスタイルになっています。

例：「INCLUDE」と「#include」の意味が逆
　　静的APIの実パラーメタには識別子を必ず指定（整数を指定出来ない）


ｔｆファイルの文法は、別途ドキュメントが用意されていますので、そちらを参照してください。

当初は賢い、便利なマクロが使えるという雰囲気でしたが、プログラミング言語（スクリプト言語？）風になってきたいます。

tfファイルは他のtfファイルを内部で読み込むことが出来ます。
というよりも、カーネルのターゲット非依存部のtfファイルからターゲット依存部のtfファイルを読み込んでいます。
最初に読み込むtfファイルはcfgのコマンドラインで指定されています。
具体的にはMakefileを参照してください。

ASPのcfgは処理内容に応じて、４段階のステージを想定しています。
最初に呼ばれるときに第１段階の処理をして出力し、、次に呼ばれるときに（それ以前の段階の出力ファイルを利用して）、指定された段階の処理を行います。