いつも大変お世話になっております。リューキィです。
現在、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フラグの読み方は分かりますかね?> ・・・これのやり方がイマイチ掴めません。