2015ARMコンパイラの動作については了解しました。ありがとうございます。↓こうする必要があるという事ですね。危ないので覚えておきます。count_clock);確かに、暗黙的なdoubleから整数型への変換は整数部がオーバーフローする時の動作は未定義なので実装依存でした。組み込み系だと最大値に丸める実装が定番なんでしょうか。(uint32_tへのキャストを指定しなければそうなっても仕方が無いと思いますが、指定しているので違う気も...)UNIX系だと、整数化後に代入先のサイズに切り詰める実装が多いのでこちらを期待してしまいした。元のコードを書いた方も同じ認識だったのではないかと。aCCのいずれも後者でした。ARMコンパイラの動作については了解しました。ありがとうございます。↓こうする必要があるという事ですね。危ないので覚えておきます。確かに、暗黙的なdoubleから整数型への変換は整数部がオーバーフローする時の動作は未定義なので実装依存でした。組み込み系だと最大値に丸める実装が定番なんでしょうか。UNIX系だと、整数化後に代入先のサイズに切り詰める実装が多いのでこちらを期待してしまいした。元のコードを書いた方も同じ認識だったのではないかと。aCCのいずれも後者でした。2015Akagawaさんコードのご提示ありがとうございます。ご提示いただいたコードでも、正常に動作します。>組み込み系だと最大値に丸める実装が定番なんでしょうか。修正前のコードの場合、最終的にはCortex-A9のハード処理により、最大値に丸められています。詳細について、ARMさんに確認をしてみます。>UNIX系だと、整数化後に代入先のサイズに切り詰める実装が多いのでこちらを期待してしまいした。元のコードを書いた方も同じ認識だったのではないかと。おっしゃる通り、上記を期待してコードを書いておりました。Araiさん該当箇所の計算精度は倍精度計算です。除算は33.333333で除算しています。除算結果は、浮動小数点から整数への変換命令(キャスト)にて丸め込まれます。long型への変換命令となります。整数への変換命令で最大値に丸め込まれます。long型への変換命令となります。整数への変換命令で0xFFFFFFFFへの丸め込みは発生しません。long型の戻り値として採用します。コードのご提示ありがとうございます。ご提示いただいたコードでも、正常に動作します。>組み込み系だと最大値に丸める実装が定番なんでしょうか。修正前のコードの場合、最終的にはCortex-A9のハード処理により、最大値に丸められています。詳細について、ARMさんに確認をしてみます。>UNIX系だと、整数化後に代入先のサイズに切り詰める実装が多いのでこちらを期待してしまいした。元のコードを書いた方も同じ認識だったのではないかと。おっしゃる通り、上記を期待してコードを書いておりました。該当箇所の計算精度は倍精度計算です。除算は33.333333で除算しています。除算結果は、浮動小数点から整数への変換命令(キャスト)にて丸め込まれます。long型への変換命令となります。整数への変換命令で最大値に丸め込まれます。long型への変換命令となります。整数への変換命令で0xFFFFFFFFへの丸め込みは発生しません。long型の戻り値として採用します。20151/19の修正後、再度テストしましたがEthernetと同時に動作させるとおかしくなるようです。修正前は1時間以内の不定時間で停止していたものが連続動作するようになりしたが、およそ1時間11分30秒後からwait_ms()が指定した時間の前に返ってくるようになります。wait_ms(5000)ではなく、Thread::wait(5000)だと問題無く動作します。Ethernetを使わないプログラム(SNIC版の方)ではこの現象は発生しないため、RTOSというよりはEthernetの問題なのかもしれません。これは制約事項になるのでしょうが、uint64_t→doubleなので、wrap_arroundが1048576を超えた辺りから怪しくなると思います。2^20=1048576。4年3ヶ月ちょいですかね。動作不良は1/19のRTOSに関しての議論と同件でした。444:219e1437f2ffで解消していることを確認しました。--1/19の修正後、再度テストしましたがEthernetと同時に動作させるとおかしくなるようです。--修正前は1時間以内の不定時間で停止していたものが連続動作するようになりしたが、およそ1時間11分30秒後からwait_ms()が指定した時間の前に返ってくるようになります。--wait_ms(5000)ではなく、Thread::wait(5000)だと問題無く動作します。--Ethernetを使わないプログラム(SNIC版の方)ではこの現象は発生しないため、RTOSというよりはEthernetの問題なのかもしれません。これは制約事項になるのでしょうが、uint64_t→doubleなので、wrap_arroundが1048576を超えた辺りから怪しくなると思います。2^20=1048576。4年3ヶ月ちょいですかね。動作不良は[[https://developer.mbed.org/forum/team-886-GR-PEACH_producer_meeting-community/topic/5365/?page=2#comment-26992|1/19のRTOSに関しての議論]]と同件でした。444:219e1437f2ff]]で解消していることを確認しました。2015EthernetInterfaceのソースを読んでいると、us_ticker_read()を呼び出している様なので、1/19のRTOSに関しての議論と同件かもしれません。正式な修正版のリリース後に再度テストしたいと思います。EthernetInterfaceのソースを読んでいると、us_ticker_read()を呼び出している様なので、[[https://developer.mbed.org/forum/team-886-GR-PEACH_producer_meeting-community/topic/5365/?page=2#comment-26992|1/19のRTOSに関しての議論]]と同件かもしれません。正式な修正版のリリース後に再度テストしたいと思います。2015修正版のライブラリでは問題なく動作する様なので、昨晩の問題については撤回します。修正版のライブラリでは問題なく動作する様なので、昨晩の問題については撤回します。2015Akagawaさん現象が最新版のmbed-srcで発生しなくなったとのことですが、ちょっと気になりませんか?蒸し返す意図はありませんが、us_ticker_read()を割り込み禁止にしてrtosの問題は解決しましたが、割り込み禁止する以前のプログラムでは現象はいつでも起こる事で1時間11分31秒前に起こって何の不思議もありません。issues」でTickerを二つ定義して動作させるとタイミングが狂う現象が確認できている模様です。us_tickerのコードを覗く時間が多くなり、私が感じるのは読み出しで問題があったと同様に、次の未来最短イベントのためにキューを生成していますが、キューへの追加部分などにも何かまだ問題があるように思えます(たぶんまた割り込み関係)。いずれにしても1時間以上何もなくそれから問題が現れるのは納得できません。感情だけで申し訳ありませんが・・・・しかし素人でprintfでのDebugでは限界であり、中の人の活動にお任せするしかありません。蒸し返す意図はありませんが、us_ticker_read()を割り込み禁止にしてrtosの問題は解決しましたが、割り込み禁止する以前のプログラムでは現象は**いつでも起こる事**で1時間11分31秒前に起こって何の不思議もありません。issues」でTickerを二つ定義して動作させるとタイミングが狂う現象が確認できている模様です。us_tickerのコードを覗く時間が多くなり、私が感じるのは読み出しで問題があったと同様に、次の未来最短イベントのためにキューを生成していますが、キューへの追加部分などにも何かまだ問題があるように思えます(たぶんまた割り込み関係)。いずれにしても1時間以上何もなくそれから問題が現れるのは納得できません。素人でprintfでのDebugでは限界であり、中の人の活動にお任せするしかありません。2015独り言1)殆どのmbedは、1μSを32ビットタイマーで計測して4294秒ちょっとまで計測2)GR-PEACHは、30nSちょっとを32ビットタイマーで計測して128秒ちょっとまで計測して、上位をソフトウェアカウンターで計測3)wait()やTicker等の時間管理は、全てこのタイマーへの時系列順のキューが生成され、順番に入れ出し(キューへの登録、削除)が行われる4)タイマーのアウトプットコンペア割り込みを利用してイベントを管理。時系列の先頭を次の割り込みのアウトプットコンペア値としてイベントを待つ。4)タイマーのアウトプットコンペア割り込みを利用してイベントを管理。時系列の先頭を次の割り込みのアウトプットコンペア値としてイベントを待つ。2015Akagawaさんmbed-src-v442-pre(v444)でのご確認、ありがとうございます。No.6」にTickerの新たな問題をアップしました。進捗あり次第、情報を展開します。Araiさんご見解ありがとうございます。Tickerについて解析を進め、あらためてコメントさせていただきます。mbed-src-v442-pre(v444)でのご確認、ありがとうございます。No.6」にTickerの新たな問題をアップしました。進捗あり次第、情報を展開します。ご見解ありがとうございます。Tickerについて解析を進め、あらためてコメントさせていただきます。2015Araiさん修正版で何度かテストしても発生しませんし、24時間以上動作させても発生しなくなりました。不具合の証拠が提出できないので、引っ込めました。解消した理由について究明できてませんが、RZのEthernetInterfaceの実装において、複数の場所でus_ticker_read()を利用しているということから、us_ticker_read()の戻り値がラップアラウンドするタイミングでなんらかの問題があったのであろうと判断しています。mbed-src-v442-pre(v444)においても、割り込み禁止に関する部分をコメントアウトするだけで再現できます。実はTCPのコネクションを確立する必要すらなく、以下のプログラムでも再現可能です。接続先のサーバ用意する必要はありません。LANケーブルを繋げなくてもOKです。}※実際には毎度1:11:31も待てないので、wrap_arround=32;としてテストしています。162秒ほどで発生させることが可能です。RZはメモリもCPUも有り余っているので、Tickerやwaitではなくて、RTOSのRtosTimerやThread::waitを使うべきなんでしょうね。修正版で何度かテストしても発生しませんし、24時間以上動作させても発生しなくなりました。不具合の証拠が提出できないので、引っ込めました。解消した理由について究明できてませんが、RZのEthernetInterfaceの実装において、複数の場所でus_ticker_read()を利用しているということから、us_ticker_read()の戻り値がラップアラウンドするタイミングでなんらかの問題があったのであろうと判断しています。mbed-src-v442-pre(v444)においても、割り込み禁止に関する部分をコメントアウトするだけで再現できます。実はTCPのコネクションを確立する必要すらなく、以下のプログラムでも再現可能です。接続先のサーバ用意する必要はありません。LANケーブルを繋げなくてもOKです。※実際には毎度1:11:31も待てないので、wrap_arround=32;としてテストしています。162秒ほどで発生させることが可能です。RZはメモリもCPUも有り余っているので、Tickerやwaitではなくて、RTOSのRtosTimerやThread::waitを使うべきなんでしょうね。2015Akagawaさん追加情報、ありがとうございます。皆さんと違って、私はGR-PEACHで何もまだ作れていないので、ユーザーが専念すべき方向に舵を切りたいと思います。事務局から今後の計画も発表があるようですし、rtos、I2Cを含めmbed-srcが安定してきたので、言い訳が出来なくなってきました。追加情報、ありがとうございます。皆さんと違って、私はGR-PEACHで何もまだ作れていないので、ユーザーが専念すべき方向に舵を切りたいと思います。事務局から今後の計画も発表があるようですし、rtos、I2Cを含めmbed-srcが安定してきたので、言い訳が出来なくなってきました。