teacup. [ 掲示板 ] [ 掲示板作成 ] [ 有料掲示板 ] [ ブログ ]

 投稿者
  題名
  内容 入力補助画像・ファイル<IMG> youtubeの<IFRAME>タグが利用可能です。(詳細)
    
 URL
[ ケータイで使う ] [ BBSティッカー ] [ 書込み通知 ] [ 検索 ]


Re: キャプチャの値が6%ほどずれるのは?

 投稿者:matsu  投稿日:2014年12月29日(月)14時47分47秒
返信・引用
  > No.706[元記事へ]

nekosanさんへのお返事です。

お返事が遅くなり済みません。

> delay関数内部で参照しているクロックって、どこの
> クロックなんでしょうね?
> タイマ1やキャプチャが利用しているクロックと、
> delayが利用しているクロックのソースが異なっている
> と考えるのが自然な気がするのですが…

たぶん,nopを回しているだけじゃないかと思うのですが,
つまり,nopの実行クロック数がわかっているので,
割り込み等がない前提で,比較的正確なdelayができていると
思うのですが,どうでしょうか。(すみません。なにぶん,
経験が浅いので想像で書いています)
delay関数は,#defineでクロック周波数を明記しておく必要が
あるので,そのクロック周波数に応じてnopの実行回数を
変更しているだけじゃないかと思っています。
(まちがっていたらごめんなさい)

> あと気になっているのは、何も処理していない時間には、
> sleepモードを使っていますか?
> もし使っているとしたら、sleep中のクロック周りの動作や、
> sleep開始時、復帰時のクロックの動作がどのようになるか
> が少し気になっています。

いえ,つかってないです。今,ソースが手元にない場所にいるので,
コピペできませんが,main関数内では,while(1)ループ内で,
自作のprintf互換のlcdprintfでキャプチャ値の表示とLEDの
点滅をやっているだけです。

今,他のマイコンのタイマーで,正確に正確なクロックを
出力させて,それでキャプチャタイミングを取ってみようかと
思っています。それでも2桁もふらつくようならどうしよう・・・。
 
 

Re: キャプチャの値が6%ほどずれるのは?

 投稿者:nekosan  投稿日:2014年12月27日(土)00時46分37秒
返信・引用
  > No.705[元記事へ]

matsuさんへのお返事です。

> nekosan様
> お世話になっています。
> 割込み関数で,タイマー1の値を読み出すように,
>
> volatile unsigned short num=0;
> volatile unsigned short new=0,old=0,dif=0;
> void __attribute__ ((__interrupt__,__no_auto_psv__)) _IC1Interrupt(void)
> {
>     IFS0bits.IC1IF = 0; // Reset respective interrupt flag
>     //new = IC1BUF; // Read capture entry
>     new = TMR1; // Read Timer1
>     dif = new-old;
>     old = new;
>     dat[num++]=dif;
> }
>
> とやってみましたが,同じ結果と相成りました。
> 専用タイマの値をキャプチャしても,タイマ1の値を読み出しても,結果は同じでした。
> difの値をmainでループを組んで,LCDに表示させていますが,
> 302xx位の値が読み出されます。1800位足らないです。
> (現在,アナログのFGを使っています)
> 分周を256まで試しましたが,得られた値を256すると,302xxになります。
> つまりdifの値は同じ割合だけ足らないことになります。
>
> とすると,やっぱりFGの発信周波数の誤差でしょうか・・・。でも6%もの誤差って大きすぎる
> と思うのです。デジタルストレージオシロスコープで測定すると結構正確な1kHzが出ていて,
> どうみても6%なんてずれてないんです。その1kHzでキャプチャしているので,6%もずれるとは
> 考えにくいです。さて,困りました・・・。
>


delay関数内部で参照しているクロックって、どこの
クロックなんでしょうね?
タイマ1やキャプチャが利用しているクロックと、
delayが利用しているクロックのソースが異なっている
と考えるのが自然な気がするのですが…


PLLで8MHzから32MHzを作り出す部分でおかしなことに
なってるのかな?と思ったんですが、delayとクロック
ソースが同じだと、説明がつかないんですよね…
なので、delayが使ってるクロックは、話題の機能が
使ってる部分とはソースが異なるのかな?と。



あと気になっているのは、何も処理していない時間には、
sleepモードを使っていますか?
もし使っているとしたら、sleep中のクロック周りの動作や、
sleep開始時、復帰時のクロックの動作がどのようになるか
が少し気になっています。

sleepをもし利用しているとしたら、それを一旦無効に
して、ただの空回しにしてみると、どうなりますかね?

 

Re: キャプチャの値が6%ほどずれるのは?

 投稿者:matsu  投稿日:2014年12月26日(金)22時18分47秒
返信・引用
  > No.704[元記事へ]

nekosan様
お世話になっています。
割込み関数で,タイマー1の値を読み出すように,

volatile unsigned short num=0;
volatile unsigned short new=0,old=0,dif=0;
void __attribute__ ((__interrupt__,__no_auto_psv__)) _IC1Interrupt(void)
{
    IFS0bits.IC1IF = 0; // Reset respective interrupt flag
    //new = IC1BUF; // Read capture entry
    new = TMR1; // Read Timer1
    dif = new-old;
    old = new;
    dat[num++]=dif;
}

とやってみましたが,同じ結果と相成りました。
専用タイマの値をキャプチャしても,タイマ1の値を読み出しても,結果は同じでした。
difの値をmainでループを組んで,LCDに表示させていますが,
302xx位の値が読み出されます。1800位足らないです。
(現在,アナログのFGを使っています)
分周を256まで試しましたが,得られた値を256すると,302xxになります。
つまりdifの値は同じ割合だけ足らないことになります。

とすると,やっぱりFGの発信周波数の誤差でしょうか・・・。でも6%もの誤差って大きすぎる
と思うのです。デジタルストレージオシロスコープで測定すると結構正確な1kHzが出ていて,
どうみても6%なんてずれてないんです。その1kHzでキャプチャしているので,6%もずれるとは
考えにくいです。さて,困りました・・・。
 

Re: キャプチャの値が6%ほどずれるのは?

 投稿者:matsu  投稿日:2014年12月26日(金)18時50分24秒
返信・引用
  > No.703[元記事へ]

nekosanさんへのお返事です。

エラッタの情報,ありがとうございます。
ただ,こんな大きなバグ,発売されたから数年経過してますから,
考えにくいかな・・・。

http://ww1.microchip.com/downloads/en/DeviceDoc/80000504g.pdf
を見る限り,キャプチャに関する物は,見当たらないようです。

> > ±1以内程度に収まらないとおかしいと私も思うのですが,
> > 実際には,32000と出るべき所,下二桁が常時ばらつきます。
> > 液晶で何を表示しているかわからない状態です。
>
> アナログのFGの周波数安定性がどのくらいなのかが
> よくわかってないのですが、下2桁っていうと、1%には
> 届いてない感じですよね。
>
> アナログだと、RC発振なんでしょうかね?RCだと、DDS式
> よりはジッタが多くなったりするのかも…という気が
> しました。

ロジック周波数設定のFGを使ってみましたが,表示は31000で,まだ1000の
差があります。下二桁は安定しません。アナログのFDで1200の差でしたから,
やっぱり変ですよね。困りました。

それで,キャプチャは当てにせず,タイマ1を走らせっぱなしにして,
IC1の割込みが入ったら,割込み関数内でタイマ1の値を読むように
してみたいと思います。この場合,読み出しタイミングの問題って
あるんでしょうか? いずれにしろやってみます。

PIC24Fのインプットキャプチャは専用タイマもついていて便利
なのですが,さすがにこれだけ合わないと使えないですし,
メーカーが書いたサンプルプログラムとほとんど大差ないので,
対処法が見えてこないです。

> すみません。8ビットアクセスだと思ってしまってました。
> PIC24は、内部バス16ビットなんですね。

はい。タイマ2と組み合わせて,32ビットタイマーもできます。
32ビットタイマーにして,5ビット右シフトして1MHzカウントの
値が取れないかやってみたいと思います。
 

Re: キャプチャの値が6%ほどずれるのは?

 投稿者:nekosan  投稿日:2014年12月26日(金)00時38分29秒
返信・引用
  > No.702[元記事へ]

matsuさんへのお返事です。

> すみません。エラッタって,なんでしょうか?


errata は、ICの設計上などにバグがあったときに、
どのリビジョンでどんなバグがあったかが、各
データシートに記載されていて、その項目名が
各メーカーともerrataとなっているかと思います。

PIC24は詳しいこと解らないのですが、もしかしたら
一部リビジョンについてerrata が載ってないかな、と。

(バグが無ければerrataは載って無いかも知れません。
 が、無くても、リビジョンごとに変更があれば
 そのリビジョン情報に何か関係する情報が何か
 掲載されているかも知れません)



> ±1以内程度に収まらないとおかしいと私も思うのですが,
> 実際には,32000と出るべき所,下二桁が常時ばらつきます。
> 液晶で何を表示しているかわからない状態です。

アナログのFGの周波数安定性がどのくらいなのかが
よくわかってないのですが、下2桁っていうと、1%には
届いてない感じですよね。

アナログだと、RC発振なんでしょうかね?RCだと、DDS式
よりはジッタが多くなったりするのかも…という気が
しました。



> 元々,16ビットカウンタなので,一度に読み込めるはずなのです。
> しかも,CPUの仕様書に書かれていたサンプルプログラムと
> 大差なく,そのあたりのおまじないはいじってないのです。


すみません。8ビットアクセスだと思ってしまってました。
PIC24は、内部バス16ビットなんですね。

 

Re: キャプチャの値が6%ほどずれるのは?

 投稿者:matsu  投稿日:2014年12月25日(木)18時02分19秒
返信・引用
  > No.701[元記事へ]

nekosanさんへのお返事です。

> エラッタにもそこらへんの情報はないですよね?

すみません。エラッタって,なんでしょうか?

> キャプチャって、普通はフリーランしてるだけの
> カウンタなので、その値が狂うって原因っていうのが、
> あまり想像できないんですよね…

その通りなんです。

> カウンタ値は、1回きりの値ですか?それとも、
> 複数回キャプチャした時の平均値ですか?

何度も液晶に重ね書き表示してみています。

> 複数回であれば、1回1回のカウンタ値(の差分)は
> ジッタが生じてますか?それとも安定(±1以内程度)
> してますか?

±1以内程度に収まらないとおかしいと私も思うのですが,
実際には,32000と出るべき所,下二桁が常時ばらつきます。
液晶で何を表示しているかわからない状態です。

> あと、32000のレンジを扱うとなると、16ビットカウンタ
> だろうと思うのですが、上位バイト、下位バイトを
> 読み出すシーケンスとか、読み出しする際の割りこみ
> 禁止制御とか、その辺は大丈夫ですかね?

元々,16ビットカウンタなので,一度に読み込めるはずなのです。
しかも,CPUの仕様書に書かれていたサンプルプログラムと
大差なく,そのあたりのおまじないはいじってないのです。

> (アセンブラ展開されたソースレベルの話になると
>  思いますが)
>
> そのあたりくらいしか、思いつかないですねぇ。

一度,アセンブラを見てみないとダメですかね。
もう少し,いろいろ試してみます。
 

Re: キャプチャの値が6%ほどずれるのは?

 投稿者:nekosan  投稿日:2014年12月25日(木)00時33分50秒
返信・引用
  > No.700[元記事へ]

matsuさんへのお返事です。

> その辺りも疑ってみました。
> でも,正しい32000になるよう,FGの方で調整すると,
> オシロの画面上で,明らかに周波数(というか周期)がずれるんです。
> 6%もずれれば,デジタルストレージオシロの画面で余裕で確認できるわけで・・・。
> 困りました。DDS方式もあるにはあるので,そちらでも試してみます。
> でもオシロとFGの両方がNGってことは,ないと思うんですが・・・。
>


そうでしたか。やっぱりよくわからないですねぇ。

エラッタにもそこらへんの情報はないですよね?

キャプチャって、普通はフリーランしてるだけの
カウンタなので、その値が狂うって原因っていうのが、
あまり想像できないんですよね…


カウンタ値は、1回きりの値ですか?それとも、
複数回キャプチャした時の平均値ですか?

複数回であれば、1回1回のカウンタ値(の差分)は
ジッタが生じてますか?それとも安定(±1以内程度)
してますか?


あと、32000のレンジを扱うとなると、16ビットカウンタ
だろうと思うのですが、上位バイト、下位バイトを
読み出すシーケンスとか、読み出しする際の割りこみ
禁止制御とか、その辺は大丈夫ですかね?
(アセンブラ展開されたソースレベルの話になると
 思いますが)

そのあたりくらいしか、思いつかないですねぇ。
 

Re: キャプチャの値が6%ほどずれるのは?

 投稿者:matsu  投稿日:2014年12月24日(水)10時38分30秒
返信・引用
  > No.699[元記事へ]

nekosanさんへのお返事です。

お返事ありがとうございます。
その辺りも疑ってみました。
でも,正しい32000になるよう,FGの方で調整すると,
オシロの画面上で,明らかに周波数(というか周期)がずれるんです。
6%もずれれば,デジタルストレージオシロの画面で余裕で確認できるわけで・・・。
困りました。DDS方式もあるにはあるので,そちらでも試してみます。
でもオシロとFGの両方がNGってことは,ないと思うんですが・・・。


> ファンクションジェネレータの発振周波数
> の誤差は影響してないんでしょうかね?
>
> DDS方式のファンクションジェネレータだと
> 発振用のクリスタルに合わせて正確な周波数
> が出てくるんだろうとおもうんですが、
> アナログだと、ある程度の誤差が含まれると
> 思うので…
 

Re: キャプチャの値が6%ほどずれるのは?

 投稿者:nekosan  投稿日:2014年12月23日(火)23時50分51秒
返信・引用
  > No.698[元記事へ]

matsuさんへのお返事です。

> ずれる割合が一定です。ファンクションジェネレータの出力周波数を
> 10倍又は1/10倍すると,正確に一桁変わるだけで,ずれ量の割合は一定の
> 6%です。
>
> > あと、1KHzの波形は、鈍ったり、ノイズが載ったりしては
> > いないでしょうか?
>
> オシロスコープで見ながらやってます。ノイズは見る限りありません。
> それで,途方に暮れています。
>


ファンクションジェネレータの発振周波数
の誤差は影響してないんでしょうかね?

DDS方式のファンクションジェネレータだと
発振用のクリスタルに合わせて正確な周波数
が出てくるんだろうとおもうんですが、
アナログだと、ある程度の誤差が含まれると
思うので…

 

Re: キャプチャの値が6%ほどずれるのは?

 投稿者:matsu  投稿日:2014年12月23日(火)22時31分57秒
返信・引用
  > No.697[元記事へ]

nekosanさんへのお返事です。

nekosanさん
いつも素早い対応,ありがとうございます。

> > キャプチャについて,教えていただけないでしょうか。どうしても6%ほどキャプチャ値が少ないのです。
> > CPUは,pic24fなのですが,
>
> クロック源(原発)は内蔵RCで、PLLの32MHzなのでしょうか?
> それとも外付けのクリスタル32MHzなのでしょうか?

前者です。内蔵RCでPLLの32MHzです。

> RCでも、さすがに出荷時点で6%ずれていると、シリアル通信
> すらまともに行えない状態なので、そこまでずれているとは
> 考えにくいなぁと言う気がするのですが。

付属ライブラリ?のdelay関数で,時計のようなものを作って,
ストップウォッチで計測すると6%なんて全然ずれてないんです。
手動計測では誤差ゼロ。

> ちなみに、1KHz以外の信号を入力させたときに、やはり6%の
> ズレがでるのでしょうか?(つまり、比例しているので
> しょうか?)

はい。比例しています。

> それとも、入力の周波数によらず、ズレる量(時間)が一定
> なのでしょうか?

ずれる割合が一定です。ファンクションジェネレータの出力周波数を
10倍又は1/10倍すると,正確に一桁変わるだけで,ずれ量の割合は一定の
6%です。

> あと、1KHzの波形は、鈍ったり、ノイズが載ったりしては
> いないでしょうか?

オシロスコープで見ながらやってます。ノイズは見る限りありません。
それで,途方に暮れています。
 

レンタル掲示板
/79