(toppers-users 4377) Re: カウンタ最大値2倍+1までカウントする理由について。

鴫原一人 ksigihar @ fsi.co.jp
2015年 5月 15日 (金) 11:44:37 JST


久江様

お世話になっております。
富士ソフト 鴫原です。


> 現在値タイマは、常に0から「ユーザ定義カウンタ最大値2倍+1」までのカウントを
> 繰り返していると思いますので、アプリケーションがGetElapsedValueをコール
> するタイミングによって、ラップアラウンドが発生していたり、いなかったりして
> しまうのではないでしょうか?
はい、ラップアラウンドの発生有無はタイミング次第です。
大前提としてですが、OS内部では「ユーザ定義カウンタ最大値2倍+1」で
現在値カウンタを管理していますが、ユーザは「ユーザ定義カウンタ最大値」の
範囲へ変換した値しか見えません。

> 例えば、現在値タイマがたまたま、「ユーザ定義カウンタ最大値」より大きく、かつ
> 「ユーザ定義カウンタ最大値2倍+1」以下の範囲だった時に、GetElapsedValueが
> コールされた場合は、ラップアラウンドしていると見なされて、経過時間は13と
> なってしまいます。
> 今度は、現在値タイマがたまたま、0以上かつ「ユーザ定義カウンタ最大値」以下
> の範囲だった時にGetElapsedValueがコールされた場合は、ラップアラウンドして
> いないと見なされて、経過時間は2となります。
こちらは最初に挙げた以下のケースの話ですよね?
・カウンタ最大値が10 (OS内部の最大値は10*2+1=21)
・現在値が5 (OS内部カウンタは5 or 16)
・経過時間の基準値に3を指定してGetElapsedValueを呼び出す

GetElapsedValue呼び出しの前に、この基準値とする"3"をユーザが得た時点で、
この"3"がOS内部的に"3"なのか"14"であったのかが、まず異なります。
そして、GetElapsedValueを呼び出した時点でのOS内部のカウンタ値を使って
計算するわけですから、ユーザ定義のカウンタ最大値で1回のラップアラウンドしか
発生していなければ、正しい経過時間を返すことができます。
実際にコードをご確認頂ければと思います。

> つまり、ラップアラウンドが発生しているかどうかは、アプリケーションが
> GetElapsedValueをコールするタイミング次第ということになり、又、
> 現在値タイマの値が現在どちらの範囲にあるかを、アプリケーションが知る方法は
> ないように思えます。
前述の通り、アプリケーション側はラップアラウンドの
発生有無を知る必要がありません。


また、OS内部でカウンタ最大値を「ユーザ定義カウンタ最大値2倍+1」で
管理するのは別の理由もあります。

この辺りの情報はATK2の設計書に書かれていますが、
以下の通り、ATK2の設計書は現在は非公開となっています。
http://www.nces.is.nagoya-u.ac.jp/press/131120_ap-conso-intro.pdf#page=11
名古屋大学で実施しているAPコンソに参加するか、
有償ライセンスで入手することもできますので、
より詳しいATK2の設計情報が必要であれば設計書の
入手を推奨致します。



2015年5月15日 9:29 <hisae @ jp.tdk.com>:

> 鴫原様
>
> お世話になっております。久江です。
>
> > 或いは単純に、現在値タイマの値が「ユーザ定義カウンタ最大値」以下の時は
> > ラップアラウンドが発生していないと見なし、それより大きく、かつ「ユーザ定
>> > カウンタ最大値2倍+1」以下の時はラップアラウンドが発生していると見なすの
> > でしょうか?
> 上記認識で合っているとすると、一点疑問があります。
>
> 現在値タイマは、常に0から「ユーザ定義カウンタ最大値2倍+1」までのカウントを
> 繰り返していると思いますので、アプリケーションがGetElapsedValueをコール
> するタイミングによって、ラップアラウンドが発生していたり、いなかったりして
> しまうのではないでしょうか?
>
> 例えば、現在値タイマがたまたま、「ユーザ定義カウンタ最大値」より大きく、か
>> 「ユーザ定義カウンタ最大値2倍+1」以下の範囲だった時に、GetElapsedValueが
> コールされた場合は、ラップアラウンドしていると見なされて、経過時間は13と
> なってしまいます。
> 今度は、現在値タイマがたまたま、0以上かつ「ユーザ定義カウンタ最大値」以下
> の範囲だった時にGetElapsedValueがコールされた場合は、ラップアラウンドして
> いないと見なされて、経過時間は2となります。
>
> つまり、ラップアラウンドが発生しているかどうかは、アプリケーションが
> GetElapsedValueをコールするタイミング次第ということになり、又、
> 現在値タイマの値が現在どちらの範囲にあるかを、アプリケーションが知る方法は
> ないように思えます。
>
> この辺りはどのように解決されているのでしょうか?
> たびたび申し訳ありませんが、ご教示頂けますようお願い申し上げます。
>
>
>
> 送信元:
> 鴫原一人 <ksigihar @ fsi.co.jp>
> 宛先:
> users @ toppers.jp
> 日付:
> 2015/05/15 00:20
> 件名:
> (toppers-users 4375) Re:        カウンタ最大値2倍+1までカウントする理由に
> ついて。
> 送信者:
> users-bounces @ toppers.jp
>
>
>
> 久江様
>
> お世話になっております。
> 富士ソフト 鴫原です。
>
>
> > 下記の例について、1回ラップアラウンドが発生していた場合は経過時間が8と
> > ありますが、基準値3から1回ラップアラウンドして現在値5ならば、基準値3から
>> > 経過時間は11+(5-3)=13ではないのですか?
> 失礼しました。
> ご指摘の通り13ですね。
>
>
> > 或いは単純に、現在値タイマの値が「ユーザ定義カウンタ最大値」以下の時は
> > ラップアラウンドが発生していないと見なし、それより大きく、かつ「ユーザ定
>> > カウンタ最大値2倍+1」以下の時はラップアラウンドが発生していると見なすの
> > でしょうか?
> ご認識の通りです。
> ラップアラウンドが2回以上発生していた場合の値は保証しなくてよい
> わけですから、上記の振る舞いでSWS_Os_00533は満たされるという認識です、
> 本設計で問題となるケースがありますでしょうか?
>
>
>
> 2015年5月14日 18:41 <hisae @ jp.tdk.com>:
> 鴫原様
>
> お世話になっております。久江です。
>
> 下記の例について、1回ラップアラウンドが発生していた場合は経過時間が8と
> ありますが、基準値3から1回ラップアラウンドして現在値5ならば、基準値3からの
> 経過時間は11+(5-3)=13ではないのですか?
> 経過時間は8が正しいとすれば、基準値をどこに取って、どのような計算を
> 行っているのでしょうか。
>
> 又、OSの処理は、どのタイミングでラップアラウンド回数のカウントを開始するの
> でしょうか?
> 例えば、一回目のGetElapsedValueコールで基準値が3であることがOSに伝わり、
> 二回目以降のコールで、OSはラップアラウンドの回数をカウントするのでしょう
> か?(この例では、一回目にラップアラウンドが発生することはない。)
> 或いは単純に、現在値タイマの値が「ユーザ定義カウンタ最大値」以下の時は
> ラップアラウンドが発生していないと見なし、それより大きく、かつ「ユーザ定義
> カウンタ最大値2倍+1」以下の時はラップアラウンドが発生していると見なすの
> でしょうか?
>
> ややこしい質問をしてしまい、申し訳ありません。
> ご教示頂けますようお願い申し上げます。
>
>
>
> 送信元:
> 鴫原一人 <ksigihar @ fsi.co.jp>
> 宛先:
> users @ toppers.jp
> 日付:
> 2015/05/14 17:04
> 件名:
> (toppers-users 4373) Re:        カウンタ最大値2倍+1までカウントする理由に
> ついて。
> 送信者:
> users-bounces @ toppers.jp
>
>
>
> 久江様
>
> お世話になっております。
> 富士ソフト 鴫原です。
>
>
> 現在値タイマを、ユーザ定義カウンタ最大値2倍+1までカウントする理由は、
> GetElapsedValueの以下の仕様を実現するためです。
>
> [SWS_Os_00533] Caveats of GetElapsedValue():
> If the timer already passed the <Value> value a second (or multiple) time,
> the result returned is wrong. The reason is that the service can not
> detect
> such a relative overflow.
>
> 例えば、カウンタ最大値が10で、現在値が5であるとします。
> この時に、経過時間の基準値に3を指定してGetElapsedValueを
> 呼び出した際、経過時間が単純に2なのか、1回ラップアラウンドが
> 発生していて8なのか、を区別できるようにしています。
> SWS_Os_00533の通り、2回以上基準値(Value)を通過していた場合
> (2回ラップアラウンドしていた場合)は、不正値が返ることになりますが、
> 1回のラップアラウンドでは正しい値を返すために、OS内部では、
> 「ユーザ定義カウンタ最大値2倍+1」で管理しています。
>
>
> 以上、宜しくお願いします。
>
>
> 2015年5月14日 16:31 <hisae @ jp.tdk.com>:
> 各位
>
> お世話になっております。
>
> TDK株式会社の久江と申します。
>
> 現在、TOPPERS/ATK2のFL850F1L(テセラ・テクノロジー)簡易パッケージ の
> ソースコードを解析させて頂いております。
>
> 下記ファイル
> ・arch\v850_gcc\tauj_hw_counter.c
> のヘッダコメント部分を読みますと、OSのカウンタオブジェクトの一つは、
> 二つのハードウェアタイマを使用して構成されているようです。
> 一つが現在値タイマで、もう一つが差分タイマです。
>
>  *  使用するタイマ:
>  *    差分タイマ:目的の時間を設定する時の現在時間(現在値タイマ)
>  *              と次の満了時間との相対時間をカウントすることで
>  *              目的の絶対時間に満了したこととする
>  *              count mode:count down once
>  *
>  *    現在値タイマ:カウンタ周期分のベースタイマを実現
>  *              (絶対時間をカウント)
>  *              count mode:continuous count down
>  *
>  *    また上記のタイマは32bitのダウンカウンタタイマである
>  *
>  *  制御方針:
>  *
>  *   現在値タイマはユーザ定義カウンタ最大値2倍+1までカウントし,
>  *   周期タイマとして連続カウントダウンして,常に現在時刻を
>  *   取得する.割込み発生する必要がないため,割込みなしモード
>  *
>  *   差分タイマは,満了処理を行うため,割込みありモードで動く
>  *   アラームなどの満了点とタイマー1で示した現在時刻の差を
>  *   現在値タイマに設定する
>  *
>  *  ポイント:
>  *   満了処理は,現在時刻を影響しないため,現在値タイマを設けている>・サン
> プルプログラムにて,TAUJ0, TAUJ1を使用.
>
> 二つのハードウェアタイマを使用する理由は理解できたのですが、
> 「制御方針」に書いてある内容で、「現在値タイマはユーザ定義
> カウンタ最大値2倍+1までカウント」する必要がある理由が分かりません。
>
> 「ユーザ定義カウンタ最大値」とは、コンフィギュレーションファイルに
> 設定される値、詳しくはtarget_hw_counter.yamlにて記述する、
> コンテナOsCounterMaxAllowedValueの値になります。
> サンプルでは次のように定義されていますので、
> OsCounterMaxAllowedValue: 0x1FFFFFFF
> このカウンタオブジェクトは0から0x1FFFFFFFまでカウントしたら
> 0に戻るカウンタということになります。
>
> 普通に考えれば、現在値タイマは0から0x1FFFFFFFまでカウント
> すれば必要十分に思えます。
> にも関わらず、「現在値タイマはユーザ定義カウンタ最大値2倍+1
> までカウント」する必要がある理由について、ご教示頂きたく
> お願い申し上げます。
>
> よろしくお願いいたします。
>
>
>
>
>
>
>
>
-------------- next part --------------
HTMLの添付ファイルを保管しました...
URL: <http://www.toppers.jp/pipermail/users/attachments/20150515/25ce1875/attachment.html>