いつも大変お世話になっております。リューキィです。
現在、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です。その後、どうでしょうか?既に解決済みでしょうか?前回の後、hirakuni45さんからアドバイスがあったものの、他には、発生しているトラブルの原因の特定に繋がりそうな、また、その原因の回避策に繋がりそうな、そういうリプライは無かったですね。実は、あれから何か調査方法はないかと以下のスレッドで私は考えていたのですが、ちょっと難易度が高いかな、という案しか思い浮かばなかったのですが、今しがた、難易度は低めだろう、と思われる案が思い浮かびました。難易度は低めだろう、と思われる調査方法案(1) 今のプログラムとは別にもうひとつプログラムを作る(2) LCDの表示とかそういったものをバッサバッサと捨てて、ロータリエンコーダの信号を調べることのみに専念するプログラムを作る ← 重要(3) 1μsec程度でカウントアップするフリーランカウンタをRXスマートコンフィグレータのCGコンポーネントで作る(4) まずはロータリエンコーダのA相の信号をP32(IRQ2-DS)とPD1(IRQ1-DS)に入れる(5) P32(IRQ2-DS)では立ち上がりエッジのみ検出し、PD1(IRQ1-DS)では立下りエッジのみ検出する(6) 検出したら上記の(3)のフリーランカウンタの値をメモリにどんどん残していく(7) 文房具屋さんへ行って方眼紙を買ってくる(8) 買ってきた方眼紙上で上記の(6)で集めたデータをプロットしてロータリエンコーダの信号の波形を手作業で描いてみる(8') 最近、日本で、未だにFAXが使われているとか、未だにフロッピーディスクが使われているとか、話題になったけれども気にしない ← 重要(8'') たぶん、ロボットを多用した最先端の自動車工場でも、人手で何かをやっている作業は存在する(と思うのだけれども)(9) A相の確認が出来たらB相についても確認する(10) もし波形にバタつきが見られたら、それを証拠にロータリエンコーダのメーカさんに原因として考えられることを聞く(11) そして波形にバタつきが見られたら、それで症状の説明が付くか考察する(12) また波形にバタつきが見られたら、機械式ロータリエンコーダのチャタリング除去と同じやり方を実装してみる(X) バタつきが見られなかったら、その時は、また、何か考える[メモ]あれこれ考えていた別スレッド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/46949#46949
NoMaYさん、こんにちは。リューキィです。
いつもいつもありがとうございます。別件の締切が差し迫った仕事が山積みになり、そちらに明け暮れていました。
ロータリーエンコーダですが、どうもギアの嚙み合わせでのバタつきやノイズ等もかなり影響しているのでは?というところで作業が止まっています。それらを確認するために配線の整理をしたりしていたのですが、また別でコンパイル中にエラーログが出るようになり、それを解析してみようと試行錯誤してたところ、ぐちゃぐちゃになっている状態です。エラーログ自体が意味不明な表示が多いので、難易度が高いです。。。話がそれてすみません。
A相・B相の波形は撮影していません。
main()のemWinの部分をコメントアウトしようとしたのですが、どれか分からず、とりあえず「APPW_」の部分と
最後にある
-------------------------------------
while (GUI_Exec1()) { APPW_Exec(); } APPW_Exec(); GUI_Delay(5);
をコメントアウトしたのですが、そうすると割込み自体が発生しません。エンコーダには電源が入っているので信号は出ています。コメントアウトしている場所を間違えているのだとは思うのですが。。。すみません。
リューキィさん、こんにちは。NoMaYです。では、こうして下さい。
void main(void){ //MainTask(); IRQを使えるようにする初期化コードをここに(既に作られているものをコピペすれば良い筈) for(;;) { }}
すみません。。。上記作業に入る前に
なぜか立上り検出そのものをマイコンが認識しなくなりました。。。
R_Config_ICU_IRQ2_Start();もメインにありますし、SCFG上でも割込みの設定はされていて、エラー等も出ていないのですが。コメントアウトしたところも戻しましたが、動いていたカウントの上下も反応しない状態です。。。
オシロはエンコーダからの信号を得ているので、回路が外れたりとかは無いです。。。
デバッグ起動時に、インクリメント or デクリメントをすることがあるので、1度は検出しているのだと思いますが、連続しての検出がされなくなってしまいました。コンポーネントの設定でも立上りエッジですし、Stopもかけていないので検出されなくなる事自体が不自然なのですが。。。と言われても困りますよね。。。すみません。。。
リューキィさん、こんにちは。NoMaYです。そういう場合は、コーヒーを一杯飲む、とか、タバコを一服、とか、気持ちを落ち着かせてみて下さい。こちらは急ぎません。(ただ、これまで頂いていた投稿から感じるのは、そちらの環境がいくら何でも不安定過ぎるかなぁ、ということはあります。)
上記解決しました。。。すみません。。。
自分が非常に未熟なだけだと思います。。。本当にすみません。。。
1ms毎でCMT割込みのオシロです。
上記のタイマーでの割込みは、特にメインの中身はいじらずに(単純に今までのメインにタイマースタートを入れただけです)この状態になりました。
先ほどのはカウンタクリアがコンペアマッチBでされていたので、間が大きいでした。今回の物が1ms毎の画像です。
それとついでに、A相・B相の波形も撮影しまし。
リューキィさん、こんにちは。NoMaYです。main()を弄りに行ったところで、「上記解決しました」、で波形が取れるようになって、その写真はまだ送られてきていなのですけれども、添付し忘れていた、ということはないですか?あと、くだんの1msの波形のチェックにより、割り込みが長期間禁止になっているのでは無かったようだ、という判断に辿り付きますが、その場合、昨日撮った写真の波形と辻褄が合わなくなります。(と私は考えています。)そこで、次に確認したいのは、もっと素朴にIRQの立ち上がりエッジの割り込み処理の先頭で素朴にポート出力をトグルするようにしてみるとどうなるのかです。IRQ割り込みがごっそりとすっぽ抜けているのかどうかを、もうすこし確実に明確に把握したい、ということですIRQ1(情報が分からないですがA相と仮定しておきます)が立ち上がった際に → 割り込み処理の先頭で素朴にポート出力をトグルするIRQ2(情報が分からないですがB相と仮定しておきます)が立ち上がった際に → 何もしない1msの波形のチェックを見て以降の予想IRQ1割り込みがごっそりとすっぽ抜けているのではないけれども、A相のパルスの立ち上がりからハイ幅の半分以上は遅れてから、IRQ1の割り込みが発生している(ハイ幅の半分以上は遅れてからポート出力がトグルする)ことがあるのではなかろうか。つまり、IRQ1の発生がB相の立ち上がり以降にずれ込んでいることがあるのではないだろうか。(これが先日のhirakuni45さんの指摘です。)
上の写真は解決した後に撮影したものです。記載しなくてすみません。
自分もIRQ2を使っているのですが、その端子の入力が怪しいのか?と予測を立てて、今度は1ms毎で端子を読み込んで、状態をトルグしてみました。以下の画像がその結果です。
IRQ2(これでA相の立ち上がりを見ています)とタイマでチェックをし続けた結果がほぼ揃っていました。なので、入力が取れていない事は無さそうです。
A相・B相の入力端子はP32(IRQ2)・P33(IRQ3)を使用しています。
20ms幅でも撮影してみました。
リューキィさん、こんにちは。NoMaYです。ごめんなさい、そちらが何を試したのか以下の文面では分からなかったです。何のタイミングでトグルさせたのでしょうか?「端子を読み込んで」とは書かれていますが、それだけでは文面から読み取れないのですが、私がお願いしたことに相当する(←これの意味は私のIRQの番号の勘違いを訂正した上での)写真になりますか?> 今度は1ms毎で端子を読み込んで、状態をトルグしてみました。以下の画像がその結果です。そして、その写真はMainTask()を動かして(これまでの通常の使用時)での写真ですよね?ああっ、私の方もお願いした時、MainTask()を動かして(これまでの通常の使用時)での、というセンテンスを書き忘れていますね。すみませんでした。
言葉足らずで申し訳ございません。
試したのは、1ms毎のタイマでの割込みが可能かは計測出来たので、今度はそのタイマでIRQ2の入力の状態を見て、きちんと入力が取れているのか(端子の入力自体に何かしら制限があったりしないのか?)を確認したくてやってみました。その結果がトルグが重なっている分です。(黄色線はあくまでセンサーからの信号、ピンク線は1ms毎に端子の入力状態を見て、入力がなされていれば出力・切れれば停止を繰り返しました。計測が1ms毎なので若干のズレが生じる事はあるようですが、高速で回してもおおむね揃っていました。)MainTask等は通常通り動かしていました。
NoMaYさんからのお願いが来る前にやったので、行き違いになっています。
以下が単純に立上りの割り込みにトルグを入れた結果です。
NoMaYさんから頂いた事をちゃんと自分が理解しているか不安なのでソースの画像も付けます。
見づらかったので、幅を変えた物です。
基本的に、今まではIRQ2が立ち上がった時に、IRQ3の状態(HIGH or LOW)を見て、++ or --をしていたんですが、通常IRQ3の立ち上がりも見る必要があるんでしょうか??
リューキィさん、こんにちは。NoMaYです。ちょっと待って下さい。幅を広げた写真ですが、これはIRQ2の割り込み処理でポート出力(ピンク色)がトグルしているタイミングが、ロータリエンコーダのA相のパルス(黄色)のハイ幅の半分より後になっていますよね?(なっている箇所が幾つもありますよね?)ひょっとして、この文章の意味が既に分からない、の?か??も???、、、
そうなんですよね。なんでズレるのかがわからないです。なのでソースがおかしいのかも!?と思い、ソースの画像も付けた次第です。自分が思い描いている感じだと、立ち上がる度にオン/オフしているので、2つの信号の立ち上がりにトルグの立ち上がりと立下りが重なるはずなんですけど。。。
もしかして、やっぱり自分が意味を書き違えていますでしょうか???