Kenji Arai

Activity

Reply to F401RE - RTC precision - Hi Gian, You don't worry about it. F401RE CPU runs 84MHz clock (mbed standard configuration). …
Kenji Arai - 16 Feb 2015
Reply to How to store values on F401RE Nucleo? - Current F401RE (and Nucleo series) mbed library makes reset action to back-up register every power …
Kenji Arai - 14 Feb 2015
Reply to F401RE - RTC precision - Please refer following my note. I guess it works with internal clock (LSI RC 37kHz). …
Kenji Arai - 14 Feb 2015
GR-PEACH_test_on_rtos_works_well wiki was updated GR-PEACH_test_on_rtos_works_well wiki was updated
Kenji Arai - 12 Feb 2015
Program updated: GR-PEACH_test_on_rtos_works_well - use standard library mbed & mbed-rtos
Kenji Arai - 12 Feb 2015
Question import customized mbed library marked as solved by answer: Dear Christian, \\ I'm sorry to make a trouble.\\ Modified mbed-src, I put a property …
Kenji Arai - 09 Feb 2015
Reply to STM32F411 nucleo RTC - Hi Tom, Please try my program. Before using the program, you need to change BAT …
Kenji Arai - 08 Feb 2015
Reply to RTC con plaquetas STM Nucleo - I cannot understand your langage but you can see additional information for RTC @ here. …
Kenji Arai - 08 Feb 2015
SetRTC wiki was updated SetRTC wiki was updated
Kenji Arai - 07 Feb 2015
Reply to RTOSに関しての議論 - Hamanakaさん ４倍しないといけない理由は、Byte単位と32Bit(4Bytes)単位の違いと理解しました。 そうであれば、上記の説明を受けた後では、 OS_PRIVCNT 10 OS_PRIVSTKSIZE 8192 を、私としては推薦します。 追記(10分後) // <o>Total stack size [bytes] for …
Kenji Arai - 03 Feb 2015
Reply to RTOSに関しての議論 - Hamanakaさん 質問です。 1スレッドあたり平均 4Kbyte までで、合計32KB確保されている。 これは、OS_PRIVCNT 8 と4KBを掛け合わせた数値ですか? OS_PRIVSTKSIZE 8192にも、stacksz != 0で定義するスレッドの、総スタックサイズとありますが、32KBとOS_PRIVSTKSIZEの関係は？ 関係を教えてもらえませんか?
Kenji Arai - 02 Feb 2015
Reply to ADCに関する議論 - mbed-src-RZ-A1H-pre-releaseが昨日リリースされましたので、ADC変換の変更結果を再度測定してみました。 Conversion time/ave = 7.634928 [uS], Number of sample 1024, Max 10 [uS], Min 7 …
Kenji Arai - 31 Jan 2015
Reply to RTOSに関しての議論 - 追加でコメントしておきます。 私のrtos使用経験ですと、紹介したGR-PEACH_test_on_rtos_not_fixed_yetが大きいほうの部類に入ります。 各スレッドのスタックサイズは私の場合、過去の経験からすると512バイトあれば、ほとんど大丈夫だと思われます。 皆さんからの製作事例で、コメントをいただき、おおよその値を決めたらいかがでしょうか? Arai事例からのスタック確保サイズ スタックサイズ 1024バイト／スレッド スレッド総数 ８ 私の認識では、 OS_PRIVCNT 8 OS_PRIVSTKSIZE 8192 の現在の値が上記に合致しており、スレッド数が少なくなれば、各スタックの値をRTX_Conf_CA.cを変更しなくても1024バイトより大きくすることが可能で、８KBを越えなければ問題ないと解釈しています。 …
Kenji Arai - 29 Jan 2015
Reply to RTOSに関しての議論 - Hamanakaさん 詳細解説、ありがとうございました。 下記にコメントを残します。 １）スタックに関して 状況は判りました。 スタックサイズが、M3&M4と殆ど変わらなことは安心しました。 RTX_Conf_CA.cの変更は、残念ですが仕方なさそうですね。 RAMが充実しているCortex-A9(RZ_A1H)ですから、一般的なユーザーアプリでは、頻繁に変更しなくても済むように標準的な設定をお願いしたいと思います。 rtosに関するWikiの充実を望みます（期限を急ぐより、徐々にupdateしながら充実していただければと思います）。 rtosは頻繁にupdateされているために、間違ってupdateしたときに自分のConfigをうまく残す方法はないのでしょうか? 例えば、ユーザー側のファイルをIncludeで読み込むような手段とか・・・？ ２）返却 ３１日であれば、留守にする時間帯が殆どないと思いますので、問題ありません。
Kenji Arai - 29 Jan 2015
Reply to ADCに関する議論 - Hagimotoさん 詳細回答、ありがとうございました。 「一回の結果」に変更、賛成です。 mbed-src内のソースプログラムは変更せず、ANALOGIN_MEDIAN_FILTER マクロを 0に設定する事を要望します。 将来、mbedライブラリーにマージされた時には「一回の結果」で、mbed-srcを利用してマクロで「3回取得した結果の中央値を採用」が選択できるのがよいと思います。 Inomataさんが青mbedに言及しておられるので、LPC1768も測定してみました。1024回のデータ解析はRAMサイズが不足しますので、512回としました。 前回利用したシャントレギュレータとポテンショが抵抗値変更なしでそのまま残っていましたので、下記を参照ください。 追加で、最初の状態が保存されていることを確認するため、1024回の再測定値も載せておきます。 LPC1768はADCが、端子の接続時のインピーダンスに大きく左右されそうですね。 変換時間は結構速いと思います。 ---LPC1768------ ANALOGIN_MEDIAN_FILTER 1 …
Kenji Arai - 27 Jan 2015
Reply to USBコネクタ経由の電源電流に関して - 回答ありがとうございました。 将来、一般発売する場合に、下記の点に注意したらいかがでしょうか？ 電源電流が最大０．８Aと記述するより、Lチカの平均的な電流を参考値として記述し、一番大食いな一例をもう一つの参考値として列挙すると、ユーザーの事前の電源容量の検討に役立つのではないでしょうか？ I/O端子が５V耐量がないこと、シンク／ソース電流の最大値も注意点としてしっかり記述すべきと思います。
Kenji Arai - 27 Jan 2015
Reply to ひろちゃんの実験 - 加川さん 現時点で、mbed-srcを使用してLチカを行うとGR-PEACHは、4294.9秒後に停止してしまいます。 us_ticker_read()の関数に問題があり、すでに停止する問題の対策は済んでいます。 mbed-srcを削除し、最新のmbed-src-v442-preを使用して確認することをお勧めします。 mbed-src-v442-preにGR-PEACH専用の修正が入っていて、これを中の人がARMさんに依頼して正式版のmbed-srcが1月末くらいには出てくるのではと推察します。
Kenji Arai - 24 Jan 2015
Reply to delay_ms()のバラツキ - Akagawaさん 追加情報、ありがとうございます。 皆さんと違って、私はGR-PEACHで何もまだ作れていないので、ユーザーが専念すべき方向に舵を切りたいと思います。 事務局から今後の計画も発表があるようですし、rtos、I2Cを含めmbed-srcが安定してきたので、言い訳が出来なくなってきました。 しかし、まだすっきりしませんが・・・・
Kenji Arai - 22 Jan 2015
Reply to delay_ms()のバラツキ - 独り言 1）殆どのmbedは、1μSを32ビットタイマーで計測して4294秒ちょっとまで計測 2）GR-PEACHは、30nSちょっとを32ビットタイマーで計測して128秒ちょっとまで計測して、上位をソフトウェアカウンターで計測 3）wait()やTicker等の時間管理は、全てこのタイマーへの時系列順のキューが生成され、順番に入れ出し（キューへの登録、削除）が行われる 4）タイマーのアウトプットコンペア割り込みを利用してイベントを管理。時系列の先頭を次の割り込みのアウトプットコンペア値としてイベントを待つ。無くなれば割り込み禁止 5）キューは64ビットで時間管理されている（timestamp_t）が、タイマーが32ビットなので上位は無視された値でアウトプットコンペアにセットされる 6）まあ一時間ちょっと計測できるタイマーなので、まさかwaitで2時間待つユーザーはいないだろう？ という発想か？ キュー自体は64ビットなので現実は問題無し？ 7）それに対して、GR-PEACHは120秒ちょっとで毎回割り込みが発生するが、空振りで何度も割り込み設定しながら本番を待つ想定 8）上位の共通ルーチンであるus_ticker_api.cpp内us_ticker_irq_handler()が呼ばれるが、 if ((int)(head->timestamp - us_ticker_read()) …
Kenji Arai - 22 Jan 2015
Reply to delay_ms()のバラツキ - Akagawaさん 現象が最新版のmbed-srcで発生しなくなったとのことですが、ちょっと気になりませんか? 蒸し返す意図はありませんが、us_ticker_read()を割り込み禁止にしてrtosの問題は解決しましたが、割り込み禁止する以前のプログラムでは現象はいつでも起こる事で1時間11分31秒前に起こって何の不思議もありません。 何故、1時間以上逆に正常に動作してから突然起きるのでしょうか? 最新の「Known issues」でTickerを二つ定義して動作させるとタイミングが狂う現象が確認できている模様です。 us_tickerのコードを覗く時間が多くなり、私が感じるのは読み出しで問題があったと同様に、次の未来最短イベントのためにキューを生成していますが、キューへの追加部分などにも何かまだ問題があるように思えます(たぶんまた割り込み関係）。 いずれにしても１時間以上何もなくそれから問題が現れるのは納得できません。 感情だけで申し訳ありませんが・・・・ しかし素人でprintfでのDebugでは限界であり、中の人の活動にお任せするしかありません。よろしくお願いします。
Kenji Arai - 21 Jan 2015