(toppers-users 3851) Re: SSPのスタックの記述

Naoki Saito nsaito.nmiri @ gmail.com
2012年 1月 30日 (月) 16:42:02 JST


むらなかさん

斉藤です.

> その方法もありだと思いますが、単純に CRE_TSK が要求するスタック量を加
算すると、
> 必要な最小量よりも大きくなりがちのはずですね。

はい.仰る通りです.

> ターゲットのリソース次第ではありますが、制約タスクにしたメリットが出な
いかなと。
> 頑張れば静的に最小値を見積もれるはずですが、ツールチェインまで絡んで
> 結構大変ではないでしょうか。
(略)
> CRE_TSK 指定でもツールが頑張ばればスタック量を見積もれるのだから頑張れ、
> というのも、それはそれでひとつの考え方ではあります。
> (私が実装側だったら怯みますが ;-)

現状の kernel.tf には (toppers-users 3782) で示した程度の
全タスクのスタック値を見積もるような処理は入っています.
ので,その程度の対応でしたら,出来ると思います.

以上,よろしくお願いします.

(12/01/30 15:54), Masaki Muranaka wrote:
> 斉藤さん、みなさま:
> 
>> 「タスク分のスタック量を定義する API」とは,全タスクで
>> 使用されるスタックサイズという意味でよろしいでょうか?
> 
> はい。そのとおりです。
> 
>> API新設する代わりにCRE_TSK での指定値から計算する方法も
>> ありますが,そちらの方法ではいかがですか?
>> (上位互換にはならないですか?)
> 
> その方法もありだと思いますが、単純に CRE_TSK が要求するスタック量を加算すると、
> 必要な最小量よりも大きくなりがちのはずですね。
> ターゲットのリソース次第ではありますが、制約タスクにしたメリットが出ないかなと。
> 頑張れば静的に最小値を見積もれるはずですが、ツールチェインまで絡んで
> 結構大変ではないでしょうか。
> 
> 新設APIがあればその値を、無ければ CRE_TSK での指定の合計を、というのは
> アリかなと思います。
> 
> CRE_TSK 指定でもツールが頑張ばればスタック量を見積もれるのだから頑張れ、
> というのも、それはそれでひとつの考え方ではあります。
> (私が実装側だったら怯みますが ;-)
> 
> 2012年1月30日14:08 Naoki Saito<nsaito.nmiri @ gmail.com>:
>> むらなかさん
>>
>> 斉藤です.
>> ご意見ありがとうございます.
>>
>>> ICS == Interrupt Context Stack であることを考えると,名称と挙動の相違に
>>> 違和感を覚えます.
>>
>> はい.
>> 同じ名称のものを異なる意味で使っていますので不自然ですよね...
>>
>>> タスク分のスタック量を定義する API を今後追加し,その仕様に沿ったカー
>> ネルは
>>> DEF_ICS の指定と新 API での指定との和とすれば上位互換にできるのかなと
>> 思います.
>>
>> 「タスク分のスタック量を定義する API」とは,全タスクで
>> 使用されるスタックサイズという意味でよろしいでょうか?
>>
>> API新設する代わりにCRE_TSK での指定値から計算する方法も
>> ありますが,そちらの方法ではいかがですか?
>> (上位互換にはならないですか?)
>>
>> 以上,よろしくお願いします.
>>
>> (12/01/30 11:24), Masaki Muranaka wrote:
>>> みなさま:
>>> こんにちは.
>>>
>>> 脇から失礼….
>>>
>>>> 2.DEF_ICS は本来でならば非タスクコンテキスト用のスタック領域を
>>>>   指定する静的APIであるが,SSPに限っては「共有スタック領域」を
>>>>   指定するための静的APIとして使うことにする.
>>>>   つまり,DEF_ICS にはタスク分と非タスク分の両方を合わせた値を
>>>>   指定し,その値が全体のスタックサイズとしてそのまま使われる.
>>>
>>> ICS == Interrupt Context Stack であることを考えると,名称と挙動の相違に
>>> 違和感を覚えます.
>>> また,コンテキストの界面は担当者の界面になることが少なくありませんので,
>>> スタック量の指定がシステムグローバルで効いてしまうのは筋が悪いように思います.
>>> (SSPの規模では一人が全てを担当しそうに思いますが,制約タスクは
>>> SSPの専売ではないですよね?)
>>>
>>> 既にリリースされているものの仕様を変更するのは混乱の元ですので避けたいところです.
>>> タスク分のスタック量を定義する API を今後追加し,その仕様に沿ったカーネルは
>>> DEF_ICS の指定と新 API での指定との和とすれば上位互換にできるのかなと思います.
>>>
>>>
>>> 2012年1月30日10:58 Naoki Saito<nsaito.nmiri @ gmail.com>:
>>>> こいさんさん
>>>>
>>>> 斉藤です.
>>>> お答え出来そうなものだけ回答致します.
>>>>
>>>>>    Sample1の場合スタックサイズはDEF_ ICS+各タスク割り当てたスタックの合
>>>>> 計(INIT_TASK、MAIN_TASK、TASK1 ,TASK2)になると思っていましたが、即値で記
>>>>> 述されているようです。TASK3のスタックはTASK2と共用する。
>>>>
>>>> この点については...
>>>>
>>>> SSPでは一つのスタック領域を全ての処理単位で共用しますので,
>>>> そのサイズをどのように算出するかが問題となりました.
>>>>
>>>> 仕様検討時の候補としては2通りありました.
>>>> 1.CRE_TSK の設定値をもとにタスクの最大使用量を見積り,それに
>>>>    DEF_ICS の設定値を加えたものを全体のスタックサイズとする.
>>>>
>>>> 2.DEF_ICS は本来でならば非タスクコンテキスト用のスタック領域を
>>>>   指定する静的APIであるが,SSPに限っては「共有スタック領域」を
>>>>   指定するための静的APIとして使うことにする.
>>>>   つまり,DEF_ICS にはタスク分と非タスク分の両方を合わせた値を
>>>>   指定し,その値が全体のスタックサイズとしてそのまま使われる.
>>>>
>>>> 結果として,第2案になりました.CRE_TSK を変更しても
>>>> 結果のスタックサイズは変更されないことになります.
>>>>
>>>> というのが現状なのですが,どのようにお感じになりますでしょうか?
>>>>
>>>>> 又、INTHDR_ENTRYの展開がASPとは異なっています(prc_config.h)、
>>>>> LOG_ISR_ENTER()がSSPでは無くなっていますが、従来と同じ作りで良いような気
>>>>> がしています。変わった理由がありましたら、お教え願いたいと思っています。
>>>>
>>>> この点につきましては,当方のミスです.
>>>> 次期リリース版では出力するように致します.
>>>>
>>>> 以上,よろしくお願い致します.
>>>>
>>>>
>>>> (12/01/30 10:15), koizumi yoshiyuki wrote:
>>>>>    こいさんです
>>>>>    SSPのスタックの記述について疑問があります。というか、CFGでのサービスが
>>>>> 欲しいと思っています。
>>>>>
>>>>>    公開されている資料とASPを使って見ての経験かするとSSPのsample1のスタッ
>>>>> クは*.cfgで記述するCRE_TSKとDEF_ ICSからcfg.exeがkernel_cfg.cに自動生成
>>>>> してくれると思っていましたが、ssp-1.1.0.tar.gzではそのように作られていな
>>>>> いようです。
>>>>>
>>>>>    DEF_ ICSは記述は有りませんし。CRE_TSKのスタックサイズを変更しても
>>>>> kernel_cfg.c、マップファイル共変化がありませんでした。
>>>>>
>>>>>    Sample1の場合スタックサイズはDEF_ ICS+各タスク割り当てたスタックの合
>>>>> 計(INIT_TASK、MAIN_TASK、TASK1 ,TASK2)になると思っていましたが、即値で記
>>>>> 述されているようです。TASK3のスタックはTASK2と共用する。
>>>>>
>>>>>    又、sample1のスタックサイズはtarget\cq_starm_gcc\target_test.h
>>>>> の#define STACK_SIZE (128)が使われていますが、target_test.h では無く
>>>>> sample1.hで指定すべきものだと思っています。
>>>>>
>>>>>    別件です。
>>>>>
>>>>> 又、INTHDR_ENTRYの展開がASPとは異なっています(prc_config.h)、
>>>>> LOG_ISR_ENTER()がSSPでは無くなっていますが、従来と同じ作りで良いような気
>>>>> がしています。変わった理由がありましたら、お教え願いたいと思っています。
>>>>>
>>>>>    どのような経緯でこのようになったのでしょうか。
>>>>>
>>>>>    以上
>>