いつも大変お世話になっております。リューキィです。
現在、RX65N Envision Kitでロータリーエンコーダを使用した試作機の開発をしているのですが、
信号の入力も表示も出来ているのですが、なぜか1回転した時の数字がズレてしまう事が多々発生してしまっています。
ロータリーエンコーダの接続の方法や、接続端子の接触不良等も疑ったのですがどうやら問題なさそうで、次にマイコン側の端子の設定
を疑っている次第です。
13chのD7(IRQ1)とD6(IRQ2)ロータリーエンコーダの信号線は接続しており、
モジュールのConfig_ICUでIRQ1/2ともに立上りエッジのレベル15 フィルタ無しにしてあります。
また、メインソース上で
R_GPIO_PinDirectionSet( GPIO_PORT_D_PIN_1, GPIO_DIRECTION_INPUT ); gpio_err |=R_GPIO_PinControl (GPIO_PORT_D_PIN_1, GPIO_CMD_IN_PULL_UP_ENABLE); R_GPIO_PinDirectionSet( GPIO_PORT_3_PIN_2, GPIO_DIRECTION_INPUT ); gpio_err |=R_GPIO_PinControl (GPIO_PORT_3_PIN_2, GPIO_CMD_IN_PULL_UP_ENABLE);
で入力端子設定とプルアップ設定も行っております。
(※もしかしたらこれが二重設定とかになっていて邪魔をしているのか??とも思い始めました)
また、ロータリーエンコーダのカウントは
IRQ1が立ち上がった際に、IRQ2の状態を見て0だったらカウントをインクリメント
IRQ2が立ち上がった際に、IRQ1の状態を見て0だったらカウントをデクリメント
としています。(それぞれの立ち上がりを見ずとも、一行目にelseでデクリメントすれば良いのもわかっているのですが、ズレが発生しているので何か問題があるのかもと思い、わざと
分けてあります)
ロータリーエンコーダの1周の分解能は40なので、非常に少ないのですが数回転回すとズレる状態です。
何かわかる方がいらっしゃいましたら、ご指導いただきたく思います。
よろしくお願い致します。
リューキィさん、こんにちは。NoMaYです。あとでもう少し詳しく書きますが、IRQ割り込み(だけ?)の受付が3~4ms程も遅延することがあるようだという現象の原因を調べるということに関して、先日書いたことに加えて、以下のことを追加でやりたいです。(N-1) 現状、IRQ割り込み(だけ?)の受付が3~4ms程も遅延することがあるようだ(N-2) 現状、CMT割り込みは1ms間隔でも受け付けられている(N-3) 現状、TMR割り込みは100μ間隔でも受け付けられている(O-1) ならば、TMR割り込み処理内で、IRQ割り込みの割り込み要求フラグ(IRフラグ)の値をポート出力させてオシロで観測したい(O-2) 少なくとも、たとえIRQ割り込みの受付が遅れることはあっても、IRQ割り込み要求フラグが0→1となるタイミングは遅れない筈(O-3) もし、IRQ割り込み要求フラグが0→1となるタイミングさえも遅れるならば、今まで推測していたのとは別種類の原因の筈[関連リンク]先日書いたことcommunity-ja.renesas.com/cafe_rene/forums-groups/beginners/f/002-2095199602/9604/config_icu-irq/47571#47571[メモ]・ ロータリエンコーダのA相 → P32 → IRQ2-DS・ ロータリエンコーダのB相 → P33 → IRQ3-DS[メモ2]・ 割込みですが、別の割込みはあの時点では自分のプログラムとしてはTMR0しかなく、それ自体は動作させるときだけスタート、ストップを使っていたので、被ってはいないと思っていました。・ 他であるとすれば画面の更新の割込みかと。なので割込み優先のレベルを上記のタイマも含めて、IRQを15にして、タイマを10,LCDを6にはしていたのですが。。。[メモ3]・ RX65N Envision KitでemWinを使う場合(のみでも)に使用/予約されるベクタ割り込み(全てFITモジュールによるものです)
BUSERRCMI0CMI1TXI6GROUPBE0GROUPBL2GROUPBL0GROUPBL1GROUPAL0GROUPAL1DMAC0IDMAC1IDMAC2IDMAC3IDMAC74IINTB128 CMI2INTB129 CMI3
NoMaYさん、こんにちは。リューキィです。
もう結構自分が追いつけないところに来てる感があります。。。
現時点での計測としては、emWinが動いている状態で、100μs毎にTMR0の割込みでP32の状態をチェックし、別の端子にトルグしてみると、エンコーダからの信号と合致して波形が出ます。なので、信号自体は受け付けているのでIRQの割込みだけが遅延する事が多いのでは無いかという状態です。(100μsで割込みしても、画面の変化(数字の変化)が遅くなっている様には感じません。割込みの重複はしていない?)
以下NoMaYさんの見解に対する自分の理解状態です。
(O-1) ならば、TMR割り込み処理内で、IRQ割り込みの割り込み要求フラグ(IRフラグ)の値をポート出力させてオシロで観測したい
・・・これのやり方がイマイチ掴めません。IRQ割込みの要求フラグが立っても、実行されない事があるのでしょうか?(他の割込み作業実行中に、IRQ割込みの要求が来るんでしょうか?)
(O-2) 少なくとも、たとえIRQ割り込みの受付が遅れることはあっても、IRQ割り込み要求フラグが0→1となるタイミングは遅れない筈
・・・(O-1)の疑問の為に理解出来ていない?(この文章を読む限りでは、他の割込み実行中でも割込み要求フラグは立つって事ですかね?
(O-3) もし、IRQ割り込み要求フラグが0→1となるタイミングさえも遅れるならば、今まで推測していたのとは別種類の原因の筈
・・・逆に割込み要求フラグはエンコーダの信号とタイミングが一致するなら、他の割込みのタスク処理待ちでズレているという事ですよね?
問題は、他の割込みが3~4msも掛かる処理をしているのだろうか?(TMR0は100μs毎に計測出来ているので、そんな長時間の処理は見受けられないような気もしますが。
って感じの理解で大丈夫でしょうか?
リューキィさん、こんにちは。NoMaYです。> って感じの理解で大丈夫でしょうか?そうです、リューキィさんも理解し始めていると思うのです。そして、以下の点が私も分からないので、少しずつ裏を取って行きたいのです。(もし、現象のタイプが、数万行のソースのどこかのif文でも間違っているのかなぁ、というのであれば、私もそこまで気にしないのですが、今回の現象は、どうにも辻褄が合わなくて困惑しているのです。) 出来れば、「あぁっ、分かった~!!!」、というところまで行けないものかと思うのです。(もっとも、そちらの業務での話ですので、あまりあれこれとはお願いは出来ませんけれども。)私だって困惑しているんです:> IRQ割込みの要求フラグが立っても、実行されない事があるのでしょうか?(補足: > IRQの割込みだけが遅延する事が多いのでは無いかという状態です。> emWinが動いている状態で、100μs毎にTMR0の割込みでP32の状態をチェックし、別の端子にトルグしてみると、エンコーダからの信号と合致して波形が出ます> 他の割込みが3~4msも掛かる処理をしているのだろうか?(TMR0は100μs毎に計測出来ているので、そんな長時間の処理は見受けられないような気もしますが。> 割込みですが、別の割込みはあの時点では自分のプログラムとしてはTMR0しかなく、それ自体は動作させるときだけスタート、ストップを使っていたので、被ってはいないと思っていました。> 他であるとすれば画面の更新の割込みかと。なので割込み優先のレベルを上記のタイマも含めて、IRQを15にして、タイマを10,LCDを6にはしていたのですが。。。)ちなみに、以下の件、割り込み実行中であっても、割込み要求フラグは、すぐにポンポンと立っていきます。> この文章を読む限りでは、他の割込み実行中でも割込み要求フラグは立つって事ですかね?あと、そのやり方については、後ほどリプライします。実は気掛りは、IRフラグの読み方は分かりますかね?> ・・・これのやり方がイマイチ掴めません。
リューキィさん、こんにちは。NoMaYです。すみません、デバッグ用のポート出力のtestportは、どの端子を使われていますか?私から提示するコードで合わせておきたいのです。
ありがとうございます。PD1です。
PD1ですね。では、TMR0タイマの100μs間隔の割り込みで、P32(IRQ2-DS)(ロータリエンコーダのA相を接続)の端子の値を読んでPD1(デバッグ用ポート出力)の端子に出力していた時と同様にして、ただしTMR0の割り込み処理は以下のように変更して、どのタイミングでIRQ2の割り込み要求フラグが立つか、オシロの波形を見せて頂けないでしょうか?
void r_Config_TMR0_cmia0_interrupt(void){ /* Start user code for r_Config_TMR0_cmia0_interrupt. Do not edit comment generated here */ PORTD.PODR.BIT.B1 = IR(ICU,IRQ2); /* End user code. Do not edit comment generated here */}
なお、念の為、その前にr_Config_TMR0_cmia0_interrupt()の中身は空にし、念の為、以下のコードでIRQ2の受付が今まで通り遅れていることは、念の為、確認しておいて下さい。(確認が終わったら、以下のコードは空にしておいて下さい。) 実は、FITモジュールのGPIO APIを使わなくても、簡便には以下で出来るのです。(ただし、FITモジュールのGPIO APIで端子を出力に設定するか、以下と同様なスタイルの記法で端子を出力に設定するか、といったことは事前に必要になります。)
void r_Config_ICU_irq2_interrupt(void){ /* Start user code for r_Config_ICU_irq2_interrupt. Do not edit comment generated here */ PORTD.PODR.BIT.B1 = ~PORTD.PODR.BIT.B1; /* End user code. Do not edit comment generated here */}
それで、先日書いたことで、その後のこれまでのやり取りで状況が分かったものもありますが、以下のことに関しては状況が分かりません。上に書いたことの結果を教えて頂く時に、一緒に教えて頂けませんか?「(2) 以下の設定で上記の(1)と同じことをするとどういう波形になるか?(2-1) emWinを止める(これまでの投稿の記載で書けば、main()のMainTask()呼び出しをコメントアウトする)(2-1') 上記の(1)ではemWinが動いていた(なおemWinが動くことに伴ってLCDドライバ/DRW2Dドライバ/R_SCI_IICドライバ等も動いている)(2-2) 他方で、main()にはIRQ割り込みとポート出力が使えるようにコードを入れておく」
ありがとうございます。
すみません。ちょっと理解するのに時間ください。
リューキィさん、こんにちは。NoMaYです。今ようやく思い至ったのですけれども、私の手元にはRX65N Envision Kitがあり、別スレッドにてRXマイコン単体でオンチップデバッグ機能でマイコンの事象発生タイミングをe2 studio上で調べる技法を把握したので、あとは、RXマイコンのどれかの端子をIRQ2-DSに繋いで、私のプログラム上でその端子を0→1とすれば、私の手元で現象が再現するかどうか調べられますね、、、ちょっとやってみます、、、
リューキィさん、こんにちは。NoMaYです。とりあえず、私の手元のRX65N Envision Kitの`Hello こんにちは`プログラムで調べてみましたが、IRQ割り込みの受付の遅延のような現象は見受けられませんでした。調べていて、マイコンが壊れた?、という可能性も気になりだしたのですが、emWinとか、リューキィさんのコードとか、動かしていなくても現象が見られるのか?、という以下の件は依然として知りたいです。「(2) 以下の設定で上記の(1)と同じことをするとどういう波形になるか?(2-1) emWinを止める(これまでの投稿の記載で書けば、main()のMainTask()呼び出しをコメントアウトする)(2-1') 上記の(1)ではemWinが動いていた(なおemWinが動くことに伴ってLCDドライバ/DRW2Dドライバ/R_SCI_IICドライバ等も動いている)(2-2) 他方で、main()にはIRQ割り込みとポート出力が使えるようにコードを入れておく」なお、以下、別スレッドへ投稿した調べた結果へのリンクです。FIT R_SCI_RXモジュールでprintfをfrom inside interrupt routine内から行えるかどうか考えてみるスレッドcommunity-ja.renesas.com/cafe_rene/forums-groups/tools/f/forum21/9610/fit-r_sci_rx-printf-from-inside-interrupt-routine/47649#47649
リューキィさん、NoMay さんこんにちは。hirakuni45 です。
割り込みが予想に反して遅延する原因の一つとして、「選択型割り込み」に、同じ割り込み要因が複数登録されている場合があると思います。
この辺りの管理がどのようになっているのか判らないのですが、たとえば、初期化を二度呼ぶと、二つ登録されるとかあるのかもしれません。
「選択型割り込み」関係が関連している箇所を今一度精査される事をお勧めします。
hirakuni45さん、こんにちは。NoMaYです。アドバイスありがとうございます。実は私も選択型割り込み(及びグループ割り込み)は気になっていました。ただ、リューキィさんのプロジェクトの土台は私から提供したものでして、そして、その土台のプロジェクトでは現象が見受けれないことが昨日分かったところでした。また、リューキィさんの方でその辺りを変更するというのも、ちょっと考え難いなぁ、とも思うところです。もっとも、そう決め付けるのも良くないですが、emWinとか、リューキィさんのコードとか、動かしていなくても現象が見受けられるのならば、ソースを削れば提供して頂けるレベルにはなると思いますし、こちらからそのレベル相当のものを提供して双方の動作を比較するといった道筋とかにも進めるかも知れないとも思うのです。