こんにちは。NoMaYです。最近、以下のスレッドに関わったのですが、そういえばFITのR_SCI_RXモジュールでは送信リングバッファを使えますので、仕組み上は、割り込みルーチン内からでもprintfを使うことが出来ても良さそうな気がします。ということで、いつものように、ちょっと好奇心からスレッドを立ててみました。いつものように、ぼちぼちと続きます。Config_ICUでのIRQの設定についてcommunity-ja.renesas.com/cafe_rene/forums-groups/beginners/f/002-2095199602/9604/config_icu-irq本当は、割り込みルーチン内からデバッグコンソールへ出力する方法を考えたいところですけれども、以下の理由で今回は保留です。(1) 割り込み駆動方式でデバッグコンソールへ文字書き込みする方法が無い(少なくとも公開されている情報では出来ない)(2) ポーリング方式でデバッグコンソールへ文字書き込みする方法では割り込みルーチン内で使うには性能上の懸念がある[追記]こんなことを考えたのも、以前に別スレッドにURLを書いた個人事業主?さんが、こういう記事を執筆されていましたのを、たまたま見掛けたからかも知れません。RAファミリprintfデバッグ3方法2022年10月7日 WithHappyhappytech.jp/wordpress/2022/10/07/ra-family-printf-debug-3-method/
> 割り込みルーチン内からデバッグコンソールへ出力する方法を考えたいところですけれども、FreeRTOSを使っているなら、以下の手法で楽チンにやれるかも。(1) 出力したい情報を格納する配列を用意しておく(文字列だと無駄なので数値データの構造体の配列とか)(2) 割り込みルーチン内で(1)の配列に情報を書き込む(3) タイマタスクで(1)に書き込まれた情報を文字列化してデバッグコンソールに出力する[追記]そういえば、うろ覚えですけれども、タイマタスク自体は出来るだけ短時間で終わらせるようにして、時間が掛かる部分は、タイマタスクからタスクもどきを起動出来るようになっているので、そちらで処理するように、とか有ったような無かったような、、、、(もちろん通常のタスクを起動しても構わないけれども、、、)
> FreeRTOSを使っているなら、考えてみたらスーパーループでも同様でしたね。(このままスレッドが終わりそうな予感も、、、)(1) 出力したい情報を格納する配列を用意しておく(文字列だと無駄なので数値データの構造体の配列とか)(2) 割り込みルーチン内で(1)の配列に情報を書き込む(3) スーパーループ内の1つの処理として(1)に書き込まれた情報を文字列化してデバッグコンソールに出力する
例えばRX65N/RX651ならばCMTWで割り込み無しで9分31秒ほど計測出来る筈である。(先ほどの投稿の構造体の配列へ割り込み処理の入口/出口でカウント値を書き込んでおいて、マイコンの空時間にデバッグコンソールへ出力すれば割り込みタイミングの概略は把握出来る筈である。もっとも数値の羅列だと良く分からないので何かしらのツールで可視化した方が良いのではありますけれども。)(A) カウントクロック: PCLKB÷8 = 60MHz(max)÷8 = 7.5MHz(max) = 133nsec(min)(B) カウンタ1周時間: カウントクロック×0xFFFFFFFF = 133nsec×4294967295 = 571230650235nsec = 571.230650235sec ≒ 9分31秒
ICLK同期でカウントアップする32ビットカウンタで手軽にヒョイッと使えるカウンタが欲しいと幾度か思いました。
くだんの関わったスレッドについては、以下のようにすると症状を第三者向けに提示出来るかも、と思いました。(オシロ無しでも。)(1) 1msecのtick割り込みを用意して割り込み毎にカウントアップするtickカウンタを用意する(割り込み発生回数計測用)(2) 100μsecでカウントアップするfreerunカウンタを用意する(真の経過時間計測用)(3) tick割り込みの中で以下を行う(3') エンコーダのカウント値が増減していたら以下の値を配列に記録する(3'') tickカウント値(3'') freerunカウント値(3'') エンコーダのカウント値の増減値(4) 適当なところでプログラム実行を止める(5) デバッガのメモリウィンドウに記録された配列の内容を表示させるメモリウィンドウで確認し易いよう配列にする構造体は以下のようにする。配列サイズは200個程で良いかと思う。(1周で40カウントのロータリエンコーダで、数回転で症状が出るようなので。)struct encoder_debug_info { uint32_t tick; uint32_t time; uint32_t delta; uint32_t padding;}ただ、気掛かりは、RAMの残りが大変少なかった筈なので、3200バイト確保出来るか微妙でもあり、その場合には、uint32_tではなくてuint16_tにするなどした方が良いかも知れない、というあたりです。
こんにちは。NoMaYです。脱線しますけれども、くだんの関わったスレッドはロータリエンコーダ(推測で光学式かな?)を使った位置検出の話題だったのですけれども、こういう位置検出の方法もあるのですね。(探せばRXマイコン版もあるのかな、、、)RA6T2によるインダクティブポジションセンサIC(IPS2200)付きBLDCモータの評価環境のご紹介www.renesas.com/jp/ja/blogs/introduce-evaluation-environment-bldc-motor-inductive-position-sensor-ic-ips2200-ra6t2
「最後のメリットは、低コストです。一般的に、光学式エンコーダや磁気式エンコーダよりインダクティブポジションセンサの方が、採用している素子や部品点数からトータルコストを下げやすいという特長があります。光学式エンコーダはセンサ自体が高価であり、磁気式エンコーダは光学式エンコーダ自体よりは安価ですが、磁気シールドなどが必要となりますのでインダクティブポジションより高価になります。図4にそれぞれのコストのイメージを示します。」
こんにちは。NoMaYです。これも脱線なのですけれども、e2 studioでE1/E2LiteでのRXマイコンのオンチップトレースでデータクオリファイトレースが出来た(いつの頃からか出来るようになった?)のですね。昔(大昔?)はちょっと触ってもまともには動いていない感じがして、トレース機能を必要とするようなデバッグはCS+に移ってやるようにしていたので、今までは気付きませんでした。(今回、GNURXを使う案件で、自分以外の人が使うかも知れない案件があったので、たまたま試してみて、ようやく気付きました。)とはいえ、せっかくカラム幅を調整して見易くしたのに、次のGo/Breakでカラム幅がデフォルトに戻ってしまい、まあ毎度毎度のe2 studioの低品質クオリティですかね、とは思ってしまいましたけれども、、、(トホホ、、、)以下、e2 studioの画面コピーです。[追記]アクセスイベントポイントの全ての設定条件がデータクオリファイトレースに影響するかどうか、ドキュメントを探して読んでみないと、ちょっと分からないです。
こんにちは。NoMaYです。脱線ついでなのですけれども、e2 studioでE1/E2LiteでのRXマイコンのオンチップトレースでデータクオリファイトレースの小手調べをしていて気付いたのですが、RX65N Envison Kitで以下の画面コピーの通りに1msの実行時間ループをfor文で作って実行させてトレースデータを見てみると、1つ(あるいは複数)の割り込みによるのだと思いますが、時々8.8msという実行時間になってしまっていることがありますね。こんな使い方も出来たという例です。以下、e2 studioの画面コピーです。
こんにちは。NoMaYです。脱線ついでのその2ですけれども、先ほどの件でclrpsw iして割り込み禁止にしても再現してしまいました。DMAか何かの影響なのでしょうかね。以下、e2 studioの画面コピーです。
こんにちは。NoMaYです。脱線ついでのその3ですけれども、先ほどの件でemWin(及び関連ドライバ)が動き出すところより前の筈のところでやってみても再現してしまいました。以下、e2 studioの画面コピーです。