delay_ms()ではなく、wait_ms()でした。wait_ms(1)を繰り返し実行した結果をロジアナで測定したところ、一定のパターンで0.5msec.と1msec.よりも大幅に短い動作が見受けられました。2014TickTimer割り込みを使って1/20秒間隔でLチカを行うとある時間が過ぎると1/10程度にLチカが遅くなります。タイマー関係が怪しい気がするのですが・・・TickTimer割り込みを使って1/20秒間隔でLチカを行うとある時間が過ぎると1/10程度にLチカが遅くなります。2014僕も同じくです。wait_ms(1000)を使って1秒ごとにLED点滅をするプログラムを作ったのですが、明らかに等間隔ではなく光っているように見えました。wait_ms(1000)を使って1秒ごとにLED点滅をするプログラムを作ったのですが、明らかに等間隔ではなく光っているように見えました。2014僕も同じくです。wait_ms(1000)を使って1秒ごとにLED点滅をするプログラムを作ったのですが、明らかに等間隔ではなく光っているように見えました。wait_ms(1000)を使って1秒ごとにLED点滅をするプログラムを作ったのですが、明らかに等間隔ではなく光っているように見えました。2014Lチカだけの簡単なプログラムを走らせると小一時間程度でハングします。どのプログラムでもある程度時間が経つとハングするんですが皆さんも同じでしょうか。Lチカだけの簡単なプログラムを走らせると小一時間程度でハングします。どのプログラムでもある程度時間が経つとハングするんですが皆さんも同じでしょうか。2014たぶん、私が以前指摘したこの件との関係です。http://developer.mbed.org/users/kenjiArai/notebook/lpc1114fn28---suggestion-for-improvement/#32bitのTickerタイマーオーバーフローが1時間11分過ぎに起きます。mbed-srcでなくmbedのライブラリーは、現在治っていますが、GR-PEACHが古い修正前不具合を引きずっているのではないでしょうか?関係するソフトのバージョンを最新版にすると、停止する問題は解決するでしょう。バラツキは別問題のような気がしますが・・・たぶん、私が以前指摘したこの件との関係です。32bitのTickerタイマーオーバーフローが1時間11分過ぎに起きます。関係するソフトのバージョンを最新版にすると、停止する問題は解決するでしょう。2014大変失礼いたしました。ご指摘通りmbed-srcのライブラリを使用しておりました。現在mbedライブラリを使用して動作試験中です。ご指摘通りmbed-srcのライブラリを使用しておりました。現在mbedライブラリを使用して動作試験中です。Countersのように二つのタイマーが走っている時にデータを個別に読んで足しては同期が保たれないでしょう。データ解析しないと何とも言えないですが、下位の16bitタイマーのオバーフロー前後の読み出しタイミングで連続性が保たれていないように思われます。インプットキャプチャー機能で上位、下位のそれぞれのタイマー値をソフトウェアトリガーで一緒に補足できれば使えるでしょうが、そんなことできますか?一番簡単なのは32bitタイマーを使用することだと思います。ように二つのタイマーが走っている時にデータを個別に読んで足しては同期が保たれないでしょう。データ解析しないと何とも言えないですが、下位の16bitタイマーのオバーフロー前後の読み出しタイミングで連続性が保たれていないように思われます。簡単なのは32bitタイマーを使用することだと思います。2014マニュアルを拝見すると、32Bitタイマーが二つあり、アウトプットコンペアも32bitで割り込み発生が出来そうです。片方は使っていると思いますが、もう一方が使えませんか?先のコメントで、16+16Bitで2回読み出しの問題を指摘しましたが、もっと問題なのは上位16Bitだけでアウトプットコンペア割り込みをかけている点です。これでは正確な時間計測は無理でしょう。Floatで係数を掛け算して割り出していますが、これも賛成できかねます。クロックベースを極力1μSecにすべきでしょう。暫定対策を提案してみたいですが・・・マニュアルを拝見すると、32Bitタイマーが二つあり、アウトプットコンペアも32bitで割り込み発生が出来そうです。先のコメントで、16+16Bitで2回読み出しの問題を指摘しましたが、もっと問題なのは上位16Bitだけでアウトプットコンペア割り込みをかけている点です。これでは正確な時間計測は無理でしょう。Floatで係数を掛け算して割り出していますが、これも賛成できかねます。クロックベースを極力1μSecにすべきでしょう。2014本件、ご報告ありがとうございました。本件、ご報告ありがとうございました。2014TickTimer割り込みを使用して50ms間隔でLEDを点滅させているのですが1分程すると100ms間隔に落ちます。何やらOSの重い処理が発生するのかフラグチェックからLEDの反転処理が50ms内で終わらず次のTickTime割り込みが発生してる模様。}}バラつきに関係してるのかな?ちなみにmbedのライブラリを使用したプログラムは1時間以上は動くようになったのですが寝ている間にハングしたようです。TickTimer割り込みを使用して50ms間隔でLEDを点滅させているのですが1分程すると100ms間隔に落ちます。何やらOSの重い処理が発生するのかフラグチェックからLEDの反転処理が50ms内で終わらず次のTickTime割り込みが発生してる模様。ちなみにmbedのライブラリを使用したプログラムは1時間以上は動くようになったのですが寝ている間にハングしたようです。2014とりあえず下記の対応で、暫定対策としては効果があったようです。興味のある方は試してみてください。Matsuokaさんのような良い計測手段を持っていないので確信は持てませんが、少なくとも誤計測の確率は少なくなりました。val;}やはり、2つのタイマー値を足す部分に問題があったようです。タイマークロックとして、33.33MHzのクロックしか選べないのも痛いですね!32bitタイマーがほしかったですね!とりあえず下記の対応で、**暫定対策としては効果があったようです**。興味のある方は試してみてください。Matsuokaさんのような良い計測手段を持っていないので確信は持てませんが、少なくとも誤計測の確率は少なくなりました。2つのタイマー値を足す部分に問題があったようです。postと同じ方法で測定しました。大幅な異常値は無くなりましたー!ありがとうございます。測定結果をCSVエクスポートして、Excelでグラフ化しています。以前はZEROPLUSを使っていましたが、使い勝手が悪くて...。postと同じ方法で測定しました。ありがとうございます。測定結果をCSVエクスポートして、Excelでグラフ化しています。以前はZEROPLUSを使っていましたが、使い勝手が悪くて...。10マイクロセック程度の誤差が生じていますね!float演算や再読みが原因でしょう。1マイクロセックの入力信号32ビットカウンターが正当な解決手段のはずです。33.33MHzのクロックを32MHzにしてもらうとスッキリするのですが弊害がでるでしょうか?mbedに参加すると決めた時点で1マイクロセックは基本のポイントだと思います。再考願いたい部分です。10マイクロセック程度の誤差が生じていますね!float演算や再読みが原因でしょう。1マイクロセックの入力信号32ビットカウンターが正当な解決手段のはずです。33.33MHzのクロックを32MHzにしてもらうとスッキリするのですが弊害がでるでしょうか?mbedに参加すると決めた時点で1マイクロセックは基本のポイントだと思います。再考願いたい部分です。2014tickerに32bitタイマを使用するよう変更いたしました。選択すると、変更が反映されます。さんご指摘のオーバーフローの件ですが、今回の変更で130秒ごとにタイマがオーバーフローします。回りこみの直前でwait関連関数がコールされると関数から戻ってこなくなることが予想されます。ARM様と協議の上早急に修正します。お手数ですが、対応されるまでの間、暫定的に、mbed-src\common\wait_api.cのwait_us関数を以下のように変更していただけますでしょうか。(uint32_t)us);}tickerに32bitタイマを使用するよう変更いたしました。選択すると、変更が反映されます。さんご指摘のオーバーフローの件ですが、今回の変更で130秒ごとにタイマがオーバーフローします。回りこみの直前でwait関連関数がコールされると関数から戻ってこなくなることが予想されます。ARM様と協議の上早急に修正します。お手数ですが、対応されるまでの間、暫定的に、mbed-src\common\wait_api.cのwait_us関数を以下のように変更していただけますでしょうか。2014祝32ビットタイマー採用!!!私も32ビットタイマーをマニュアルで調べたのですが、インプットクロックが33.33MHzしか選べないので落胆したところでした。1μSecのカウンターであれば、オバーフローが4294秒ごとですが、Hagimotoさんの説明のようにPEACHでは180秒ごとに発生してしまうことが弊害となって上位関数にも影響が出る結果なんですね。これで精度もかなり向上したのではないでしょうか?Matsuokaさんまた測定して結果を皆さんに紹介してしていただくと、この問題提起も(表向き)一件落着となる気がします。PEACH以外のmbedで同じプログラムを走らせる方も多いと思いますので、下記をリコメンドします。これで何も気にせずボード変更できます。私も32ビットタイマーをマニュアルで調べたのですが、インプットクロックが33.33MHzしか選べないので落胆したところでした。1μSecのカウンターであれば、オバーフローが4294秒ごとですが、Hagimotoさんの説明のようにPEACHでは180秒ごとに発生してしまうことが弊害となって上位関数にも影響が出る結果なんですね。測定して結果を皆さんに紹介してしていただくと、この問題提起も(表向き)一件落着となる気がします。PEACH以外のmbedで同じプログラムを走らせる方も多いと思いますので、下記をリコメンドします。これで何も気にせずボード変更できます。Rev.434を測定しました。Rev.434を測定しました。2014Matsuokaさんお手数かけましたが、これではっきりしましたね!私の16+16bit時の精度が、幅で12μSec、上記32bitで、幅が0.8μSecと読み取れると思いますので、精度は十分と思います。実は、NucleoF411REを使用した周波数カウンターを製作中なのですが、内部クロック100MHzを32bitカウンターでGPSの1PPSで補正をかけて使用したところ、使えないと結論を出しました。理由は100MHzがPLLで作られているのですが、制御幅として70Hz程度を30秒くらいかけてのこぎり刃上にのこぎり波状に変化します。PLL制御上、この変動幅と周期はどうにもなりません。PEACHも内部PLLの変動幅と周期の兼ね合いで上記のような変動が起きていると推察します。32bitのカウンター取り込み誤差(量子化)は、33.33MHz入力では30nSec程度のはずですから、測定値と一桁違います。周波数カウンターは、32bitを持つほかのARMでは実現できますが、ユーザーが使用できる32bitタイマーがなくてPEACHではできません。これを2月の作品にと思ったのですが残念です。私の16+16bit時の精度が、幅で12μSec、上記32bitで、幅が0.8μSecと読み取れると思いますので、精度は十分と思います。実は、NucleoF411REを使用した周波数カウンターを製作中なのですが、内部クロック100MHzを32bitカウンターでGPSの1PPSで補正をかけて使用したところ、使えないと結論を出しました。理由は100MHzがPLLで作られているのですが、制御幅として70Hz程度を30秒くらいかけて--のこぎり刃上に--のこぎり波状に変化します。PLL制御上、この変動幅と周期はどうにもなりません。PEACHも内部PLLの変動幅と周期の兼ね合いで上記のような変動が起きていると推察します。32bitのカウンター取り込み誤差(量子化)は、33.33MHz入力では30nSec程度のはずですから、測定値と一桁違います。周波数カウンターは、32bitを持つほかのARMでは実現できますが、ユーザーが使用できる32bitタイマーがなくてPEACHではできません。これを2月の作品にと思ったのですが残念です。2014もう一つ、doubleでの力任せの演算で丸め誤差もこの付近になると大きい要因と思います。32bitタイマーに自由度の大きいプリスケーラーがあると完璧だったのですが・・・ここまでで議論は終了でしょうか?あとはWishにしかならず反映が難しい話になってしまいます。一つ、doubleでの力任せの演算で丸め誤差もこの付近になると大きい要因と思います。あとはWishにしかならず反映が難しい話になってしまいます。さんご指摘のオーバーフローの件を修正致しました。本修正により、wait_api.cの変更が不要となりました。選択すると、変更が反映されます。Araiさんご指摘の通り、RTOSおよびフリーランニングで32bitタイマを使用しているため、ユーザが使用できる32bitタイマはありません。ユーザの使用できるタイマはMTU2となりますが、こちらはプリスケーラを有するものの、16bitとなります。>ここまでで議論は終了でしょうか?>あとはWishにしかならず反映が難しい話になってしまいます。ご要望にお応えできず、すいません。多数のご指摘を頂けたことにより、解決することができました。ありがとうございます。さんご指摘のオーバーフローの件を修正致しました。本修正により、[[http://developer.mbed.org/forum/team-886-GR-PEACH_producer_meeting-community/topic/5344/?page=1#comment-26331|wait_api.cの変更]]が不要となりました。選択すると、変更が反映されます。RTOSおよびフリーランニングで32bitタイマを使用しているため、ユーザが使用できる32bitタイマはありません。こちらはプリスケーラを有するものの、16bitとなります。>あとはWishにしかならず反映が難しい話になってしまいます。ご要望にお応えできず、すいません。多数のご指摘を頂けたことにより、解決することができました。ありがとうございます。2014あらためてロジアナのサンプリング周期を上げて、測定しました。良好です!ご対応、どうもありがとうございました。ロジアナのサンプリング周期を上げて、測定しました。ご対応、どうもありがとうございました。2014一週間、多忙のため反応できずに申し訳ありません。Hamanakaさん非常にスマートな解決になったと思います。32bitタイマーは、ぜひ今後のCPU開発で入れ込んでいただきたい周辺機能と思います。タイマーのオーバーフロー、アンダーフローは永遠のテーマです。インプットキャプチャーは16+16Bitでも何とかなりますが、アウトプットコンペアは16+16bitではどうにもならない(?)と思われます。Matsuokaさんいつも検証、ご苦労様です。時系列の推移は、面白いほど規則性がありそうですね。1000.1μS付近は幅があるのですか?大きく幅を持ったところは一回だけですか?時間が有るときで結構ですから、拡大して100サンプリングくらいを見せていただけないでしょうか?良い測定器を持っていないもので・・・申し訳ありません。一週間、多忙のため反応できずに申し訳ありません。非常にスマートな解決になったと思います。32bitタイマーは、ぜひ今後のCPU開発で入れ込んでいただきたい周辺機能と思います。タイマーのオーバーフロー、アンダーフローは永遠のテーマです。インプットキャプチャーは16+16Bitでも何とかなりますが、アウトプットコンペアは16+16bitではどうにもならない(?)と思われます。いつも検証、ご苦労様です。時系列の推移は、面白いほど規則性がありそうですね。良い測定器を持っていないもので・・・申し訳ありません。2014拡大を添付します。いうか、データも添付したほうが良かったですね。/media/uploads/matsujirushi/wait_ms_rev440.zip拡大を添付します。いうか、データも添付したほうが良かったですね。2014Matsuokaさん早速の対応、ありがとうございました。通常はほとんど量子化誤差だけになったということですね。70mS毎に処理による誤差が増えるのでしょうか?お手数かけました。対応、ありがとうございました。通常はほとんど量子化誤差だけになったということですね。2015us_ticker.cのus_ticker_read()に不具合を見つけました。count_clock);とありますが、2^32-1を越える(work_arround>32)と、ずっと4294967295を返します。擬似コードを作成して実行してみましたが、Cortex-Mでも同じ動作なので、ARMコンパイラの仕様でしょうか。4.1.2-54))だと、ラップします。}}work_arroundがオーバーフローしたときの動作までは検証していないので、そちらの動作は不明です。以下だと期待通りの動作をするようです。(uint32_t)val64;us_ticker.cのus_ticker_read()に不具合を見つけました。ありますが、2^32-1を越える(work_arround>32)と、ずっと4294967295を返します。擬似コードを作成して実行してみましたが、Cortex-Mでも同じ動作なので、ARMコンパイラの仕様でしょうか。4.1.2-54))だと、ラップします。work_arroundがオーバーフローしたときの動作までは検証していないので、そちらの動作は不明です。以下だと期待通りの動作をするようです。2015Akagawaさんよくたどり着きましたね!すごいです!私もこの付近のコードを追いかけたのですが、さすがに値のチェックまでしていませんでした。私もAkagawaさんの上記コードで、おかしなふるまいを確認しました。*追記を読む前に、作業完了してPCから離れていたので、私は下記コードに置き換えて動作確認してみました。5%程度の誤差にはなりますが、停止の有無確認を目的としました。クロックソースを、32MHzにしてもらうとdoubleでの計算は不要なのですが・・・・(せめて割り切れる数のクロックにしてほしかったがHW要望は締切ですね)http://developer.mbed.org/users/kenjiArai/code/GR-PEACH_test_wo_rtos/で、I2Cデバイスなど一切接続しないで、裸のGR-PEACHで上記修正プログラムを実行したところ、一晩8時間以上動きました。1時間11分30秒問題は、Akagawaさんの指摘した部分を修正すればうまく動くようになるでしょう。確認していませんが、追記した部分のcount_clockは、doubleをuint64_tにキャストしてから計算されるのでしょうか?最終的に中の人が(といってもコンパイラのふるまいだとすると、中の人にもつらい!?)どんな対策をしてもらえるか?対策方針と時期をお聞きしましょう。私もこの付近のコードを追いかけたのですが、さすがに値のチェックまでしていませんでした。私もAkagawaさんの上記コードで、おかしなふるまいを確認しました。***追記**を読む前に、作業完了してPCから離れていたので、私は下記コードに置き換えて動作確認してみました。5%程度の誤差にはなりますが、停止の有無確認を目的としました。I2Cデバイスなど一切接続しないで、裸のGR-PEACHで上記修正プログラムを実行したところ、一晩8時間以上動きました。1時間11分30秒問題は、Akagawaさんの指摘した部分を修正すればうまく動くようになるでしょう。対策方針と時期をお聞きしましょう。2015Araiさんやってみたら期待通りの動作をしたというだけなので、よくわかりません。FPUの動作にも依存するので、コンパイラの問題ではないのかもしれません。本件については、「修正しました」だけではなくて、今ダメなのはどういう動作をしていて、修正後はどういう動作になるので大丈夫ですという報告が欲しいところです。動いているだけというのでは困りますので。※そして「ちゃんとテストしてからcommitしてね」って感じです。やってみたら期待通りの動作をしたというだけなので、よくわかりません。FPUの動作にも依存するので、コンパイラの問題ではないのかもしれません。本件については、「修正しました」だけではなくて、今ダメなのはどういう動作をしていて、修正後はどういう動作になるので大丈夫ですという報告が欲しいところです。動いているだけというのでは困りますので。※そして「ちゃんとテストしてからcommitしてね」って感じです。2015Akagawaさんtickerに関し、解析ありがとうございます。tickerに関し、解析ありがとうございます。2015Akagawaさん報告が遅くなってしまい、すいません。こちらで解析を行い、修正コードにて動作確認した結果、1h30m11sの件が改善されていることを確認しました。社内にてレビュー後、詳細についてご連絡致します。報告が遅くなってしまい、すいません。1h30m11sの件が改善されていることを確認しました。社内にてレビュー後、詳細についてご連絡致します。2015Akagawaさん大変お待たせしました。プログラムを実行し、1時間11分30秒を経過すると、プログラムが止まる。下記コードのアセンブラコードを確認しました。long型のMAX値である0xFFFFFFFFに丸められていました。・・・中略・・・}【対策】コードを下記のように書き換え、アセンブラコードを確認しました。上で述べた除算結果の丸めこみは発生しません。long型に格納されます。(やっていることは、Akagawaさんからお知らせいただいたコードと同じ内容です。本コードにて、1時間11分30秒以上経過しても、処理が止まらない事を確認しました。【対策版コードの展開時期】RTOSに関しての議論と修正箇所が関連するため、そちらの動作確認が終了次第、mbed-src-v442-preにて展開させていただきます。問題がなければ、明日中に展開する予定です。us_ticker_read()に関して、解析結果をコメント致します。プログラムを実行し、1時間11分30秒を経過すると、プログラムが止まる。下記コードのアセンブラコードを確認しました。long型のMAX値である0xFFFFFFFFに丸められていました。コードを下記のように書き換え、アセンブラコードを確認しました。上で述べた除算結果の丸めこみは発生しません。long型に格納されます。(やっていることは、Akagawaさんからお知らせいただいたコードと同じ内容です。本コードにて、1時間11分30秒以上経過しても、処理が止まらない事を確認しました。そちらの動作確認が終了次第、mbed-src-v442-preにて展開させていただきます。問題がなければ、明日中に展開する予定です。