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

[koizumi yoshiyuki]

小南さま
koisanです。

 もう一度初めからやり直したところ無事、ｃｆｇで割り込み番号が変わりました。色々有難うございました。

色々いじりすぎたので初めからやり直しました。UART#2を使用する為の修正をオリジナルの方針に変更。最初にcfgを行わず、Cソースコードを修正し動作確認後、cfgで５３が５４に変わることを確認した。

１ UART#2を使用するための修正
logtask.h
#define LOGTASK_PORTID  2  /* システムログ用のシリアルポート番号 */
target_config.h
#define SIO_PORTID  (2)
target_syssvc.h
#define TNUM_PORT        (2)  /* サポートするシリアルポートの数 */
#define TNUM_SIOP        (2)
sample1.h
#define TASK_PORTID  2   /* 文字入力するシリアルポートID */

２ タイプミスの修正(?)
target_serial.h
#elif (SIO_PORID == 2)
UARTの入力と出力の番号を別にしているのが解からず苦労しました。（前回上手く行かなかったのは細々ありますが、最終的にはコンパイルスイッチの使い方を間違えたようです。お騒がせしました）

ただし、cgfで作成したkernel_cfg.cに割り込みベクタ番号が即値になっているところがある。本来は数値ではなく、INTNO_SIOになるべきだと思っています。この部分は、
kernel.tfで処理されているようです。即値の変換は美しくないと思っています。

------
const INHINIB _kernel_inhinib_table[TNUM_INHNO] = {
 { (INHNO_TIMER), (TA_NULL), (FP)(INT_ENTRY(INHNO_TIMER,
target_timer_handler)) },
 { (54), (TA_NULL), (FP)(INT_ENTRY(54, _kernel_inthdr_54)) }
};
#define TNUM_INTNO 2
const uint_t _kernel_tnum_intno = TNUM_INTNO;
const INTINIB _kernel_intinib_table[TNUM_INTNO] = {
 { (INTNO_TIMER), (TA_ENAINT|INTATR_TIMER), (INTPRI_TIMER) },
 { (INTNO_SIO), (TA_ENAINT|INTATR_SIO), (INTPRI_SIO) }
};
------

_kernel_tnum_intno はOKですが、_kernel_inhinib_tableは即値になっています。

 まだまだですが、cfgの理解が深まりました。

以上
2010年3月31日11:14 koizumi yoshiyuki <koizumiyoshiyuki ＠ gmail.com>:

>  小南さま
>
>  色々有難うございます。大変参考になりました。次のステップに進む時にじっくり考えます。
> 初心者からの意見ですが、JSPとASPのcfgは別物と理解しました。であるなら何故、同じ名前にしたのでしょうか。cfg2、acfgにしたほうが良いと思います。
>  名前など、つまらない事に思われるかも知れませんが、小生は重要なことだと思います。（歴史的な話もあるとは思いますが）
>
>  いつも親切な説明有難うございます。
>
> 以上
>
>  2010年3月31日10:49 yasuo kominami(nifty) <ykominami ＠ nifty.com>:
>
>> 小南です。
>>
>>
>> 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は処理内容に応じて、４段階のステージを想定しています。
>> 最初に呼ばれるときに第１段階の処理をして出力し、、次に呼ばれるときに（それ以前の段階の出力ファイルを利用して）、指定された段階の処理を行います。
>>
>
>
-------------- next part --------------
HTMLの添付ファイルを保管しました...
URL: <http://www.toppers.jp/pipermail/users/attachments/20100401/cab8f75f/attachment.html>