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

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


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

 投稿者:matsu  投稿日:2015年 1月 7日(水)02時51分30秒
返信・引用
  > No.714[元記事へ]

nekosanさんへのお返事です。

これは,pic独特の問題でしょうか?
下のプログラムですが,キャプチャをスタートする関数なんですけど,
1msのウェイトを入れてからでないと,なぜかリセットがかかってしまいます。

void startCapture(void)
{
    IFS0bits.IC1IF = 0; // Clear the IC1 interrupt status flag
    IPC0bits.IC1IP = 1; // Set module interrupt priority as 1
    waitms(1);//ないとリセットがかかる場合がある
    IEC0bits.IC1IE = 1; // Enable IC1 interrupts
}

希にかからないこともあるんですが・・・。
おそらく,これより先に,キャプチャ関係のタイマ等の初期化を終えて
いるので,interrupt status flagが立ってしまっていて,
0を書き込んだ後,少し待たないと実際に0にならないのかな・・・,
と考えました。可能性ありますでしょうか。

だとすると,同様にレジスタ書き込みを行っているので,

> また、プログラム上の処理順序によって、先に設定
> しておいたSFRが、後から別のレジスタを設定した
> ことによって、意図しない値に上書きされたりして
> ないでしょうかね?

って可能性もありそうな気がします・・・。
 
 

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

 投稿者:matsu  投稿日:2015年 1月 7日(水)01時17分53秒
返信・引用
  > No.714[元記事へ]

nekosanさんへのお返事です。


> あともうひとつ気になるところがあります。
> SFRにパラメタを設定する順序です。

C言語なのでその辺はうまくやってくれていると
思うんですが・・・。

> PICの場合、一部のSFRを変更すると、他のSFRに
> 自動的に反映されたりするケースがあったように
> 思います。(チップによる?)

これはいやですね。もしそれが考慮されてなければ,
コンパイラ(ライブラリ?)の方の問題になりそうですね。

> で、とりあえずシミュレータにバグがないという
> 前提で考えるとします。
>
> ステップ実行で、SFRへの設定の直前に、全SFR
> (今回弄る機能以外も含めて)をダンプしておいて、
> SFR設定後に改めて全部ダンプ取って、それらを比較
> してみて、何か意図以外に変化している部分はない
> でしょうかね?

mplabの使い方が慣れてないので,ちとお時間ください。

> また、プログラム上の処理順序によって、先に設定
> しておいたSFRが、後から別のレジスタを設定した
> ことによって、意図しない値に上書きされたりして
> ないでしょうかね?
>
> 特に、タイマ関係、クロック関係のSFRが、意図しない
> 値になっていないか…

C言語で書いていてもそういう可能性ありますでしょうか。
 

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

 投稿者:matsu  投稿日:2015年 1月 7日(水)01時08分10秒
返信・引用
  > No.713[元記事へ]

nekosanさんへのお返事です。

> 別のチップでも同じ結果が出るということは、
> チップ単体固有の問題ではないと考えてよさそう
> ですね。

あす,再度確認しますが,別のチップだと誤差割合が
また微妙に違ってくるだろうと思います。
明日,再度確認してみますが,もしそうなれば,
内蔵RCクロックの誤差なのか・・・,と思ってしまいます。
5%もずれてるなんて,信じられないですけど,
picのRC内蔵クロックってどの程度の精度でしょうか?

> 同一の原発から出力されるクロックを元にして
> 計測しても誤差が出るなら、クロックの速度調整
> ではどうやっても調整することは不可能である
> と思います。(周波数が一緒に上下するので)
>
>
> 多分、やってみると誤差は出るものと想像します。
> (2つの個体で同じような結果になっているので)
> また、その場合、そもそもクロック調整は意味が
> ないところに原因があると判断できると思います。
> (原因の切り分け)

picでPWMを出すというのをまだやったことがないので,
少しお時間ください。とりあえず作ってしまわなければ
ならないものを先に作ってしまいます。
32MHzをカウントしてみましたが,実際は1MHzでよいので,
difを5ビット右シフトしますので,かなり誤差は気にならなく
なるはずです。

> できないと思うので、ほかのサイトでも手広く
> 質問されると安心です。

ありがとうございます。そうしてみます。

> …それにしても、やはりナニが原因なのか、よく
> 判らないですねぇ。

いやー,ほんとに参りました。
一定割合の誤差っていうのが,もうRC発信器の
誤差としか考えられないです。ただその誤差が
大きすぎるような・・・。
 

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

 投稿者:nekosan  投稿日:2015年 1月 7日(水)00時46分59秒
返信・引用
  > No.712[元記事へ]

matsuさんへのお返事です。


あともうひとつ気になるところがあります。
SFRにパラメタを設定する順序です。


PICの場合、一部のSFRを変更すると、他のSFRに
自動的に反映されたりするケースがあったように
思います。(チップによる?)


で、とりあえずシミュレータにバグがないという
前提で考えるとします。

ステップ実行で、SFRへの設定の直前に、全SFR
(今回弄る機能以外も含めて)をダンプしておいて、
SFR設定後に改めて全部ダンプ取って、それらを比較
してみて、何か意図以外に変化している部分はない
でしょうかね?

また、プログラム上の処理順序によって、先に設定
しておいたSFRが、後から別のレジスタを設定した
ことによって、意図しない値に上書きされたりして
ないでしょうかね?

特に、タイマ関係、クロック関係のSFRが、意図しない
値になっていないか…


AVRはその手の仕様がなかったと思うのですが、PICは
その手の親切機能(老婆心機能)によって、むしろ
面倒が起こることがあったと記憶しているので。
 

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

 投稿者:nekosan  投稿日:2015年 1月 7日(水)00時35分56秒
返信・引用
  > No.710[元記事へ]

matsuさんへのお返事です。

> 何というか・・・,一定の誤差ですから,それを考慮して計算してしまうことも可能では
> ありますが・・・。厳しいですね。
> (すみません。他の掲示板でも質問してみて良いでしょうか?)



別のチップでも同じ結果が出るということは、
チップ単体固有の問題ではないと考えてよさそう
ですね。


で、思うのですが、使っていないPWMピンから
一定周波数の矩形波を出力しておいて、その波形
をキャプチャ用の端子から入力して、それでも
理論値と誤差が出るなら、そこにかかわる設定
周りが、誤差が出ないなら、外部に要因があるの
では、という気がします。

同一の原発から出力されるクロックを元にして
計測しても誤差が出るなら、クロックの速度調整
ではどうやっても調整することは不可能である
と思います。(周波数が一緒に上下するので)


多分、やってみると誤差は出るものと想像します。
(2つの個体で同じような結果になっているので)
また、その場合、そもそもクロック調整は意味が
ないところに原因があると判断できると思います。
(原因の切り分け)

なお、多分私の知識と技術では、責任もって解決
できないと思うので、ほかのサイトでも手広く
質問されると安心です。

…それにしても、やはりナニが原因なのか、よく
判らないですねぇ。
 

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

 投稿者:matsu  投稿日:2015年 1月 7日(水)00時03分58秒
返信・引用
  > No.711[元記事へ]

nekosanさん
お世話になります。
一定割合の誤差が出るので,5.86%だけ強制的に増えるようにして,ほぼ理論上の値が
出るようにしました。ちょっと対処療法過ぎて気持ち悪いのですが,まだ先があるので,
この先を作りたいと思います。
(他の掲示板にも投稿してみたいのですが,よろしいでしょうか?)

__eds__ unsigned long dat [16384] __attribute__((eds)); /*dat[0]-dat[16384]が使用可能*/
volatile unsigned long low=0, high=0;
volatile unsigned long old=0, new=0, dif=0;
volatile unsigned short num=0;

void __attribute__ ((__interrupt__,__no_auto_psv__)) _IC1Interrupt(void)
{
    IFS0bits.IC1IF = 0; // Reset respective interrupt flag
    low  = IC1BUF; // Read capture entry
    high = IC2BUF; // Read capture entry
    new = (high<<16)|low;
    new= new+(new>>4)-(new>>8);//5.86%強制補正
    dif = new-old;
    old = new;
    dat[num++]=dif;
    num&=0x3fff;//上位ビットを消して0-16383までにする
}


int main(int argc, char** argv)
{
    initCLK();
    initLED();
    initLCD();
    initPushSW();
    initDipSW();
    initCaptureControl();


    clrscr();
    while(1){
        waitms(200);
        gotoxy(0,0); lcdprintf("%u %5u",_RF5,num-1);
        gotoxy(0,1); lcdprintf("%u %10lu",_RF5,dat[num-1]);
        ledFlow();
    }

    return (EXIT_SUCCESS);
}





> --------------------------
> 32MHzの内部クロックを32ビットカウンタでカウントしてキャプチャ。
> FGのクロックの立ち上がりでキャプチャ。-5.5%位の誤差が出る。
>
> FG有効数字  FG(Hz)  計測↑キャプチャ値 見た目の変動 理論上↑キャプチャ値 差分%
>      2        10          3031700             ±400      3200000         -5.259375
>      3       100           302370              ±40       320000         -5.509375
>      4      1000            30215               ±5        32000         -5.578125
>      4     10000             3020               ±1         3200         -5.625
> --------------------------
 

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

 投稿者:matsu  投稿日:2015年 1月 6日(火)23時24分50秒
返信・引用
  > No.709[元記事へ]

失礼しました。単位を間違えていたので,
再度投稿します。

--------------------------
32MHzの内部クロックを32ビットカウンタでカウントしてキャプチャ。
FGのクロックの立ち上がりでキャプチャ。-5.5%位の誤差が出る。

FG有効数字  FG(Hz)  計測↑キャプチャ値 見た目の変動 理論上↑キャプチャ値 差分%
     2        10          3031700             ±400      3200000         -5.259375
     3       100           302370              ±40       320000         -5.509375
     4      1000            30215               ±5        32000         -5.578125
     4     10000             3020               ±1         3200         -5.625
--------------------------

クロックを調整するレジスタでもほとんど変化がないので,困ってしまいました。
そもそも,調整するレジスタでは5%も変化は出せないですし・・・。
 

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

 投稿者:matsu  投稿日:2015年 1月 6日(火)23時18分55秒
返信・引用
  > No.709[元記事へ]

nekosanさん

いつもお世話になります。
PIC24Fのタイマー内蔵キャプチャが32ビットでも動作させられたので,
32MHz内蔵RCクロックを10, 100, 1000Hzの立ち上がりでキャプチャしてみました。
その結果です。

-----------
32MHzの内部クロックを32ビットカウンタでカウントしてキャプチャ。
FGのクロックの立ち上がりでキャプチャ。-5.5%位の誤差が出る。

FG有効数字  FG(Hz)  計測↑エッジ間隔(us) 見た目の変動 理論上↑エッジ間隔(us) 差分%
     2        10          3031700             ±400      3200000          -5.259375
     3       100           302370              ±40       320000          -5.509375
     4      1000            30215               ±5        32000          -5.578125
     4     10000             3020               ±1         3200          -5.625
-----------

何というか・・・,一定の誤差ですから,それを考慮して計算してしまうことも可能では
ありますが・・・。厳しいですね。
(すみません。他の掲示板でも質問してみて良いでしょうか?)
 

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

 投稿者:matsu  投稿日:2015年 1月 6日(火)00時55分3秒
返信・引用
  > No.708[元記事へ]

nekosanさんへのお返事です。

いつもお世話になります。

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

他のマイコン(H8で50Hz)を出力させて,20msが測定できるかやってみました。
タイマ1を分周してカウントさせましたが,やはり6%ほどずれます。

> もしかしたら、この1個だけでしか再現しなくて、同じ型番の
> ICでも再現しないみたいなことは、ないでしょうかね?

いえ。2個で試していますが,同じ状況です。手がなくなってきました。

あと,内部クロックのチューンを調整してみましたが,1%も変わらないくらいで
調整できましたが,しばらくすると下の3つのどれでも徐々に同じ値になります。
内部クロックってそういうものなんでしょうか。今ひとつ安定しない感じです。

    OSCTUNbits.TUN = 0b000000; //オシレータ調整レジスタ,メーカー校正結構正確
    //OSCTUNbits.TUN = 0b100000; //オシレータ調整レジスタ,最小周波数,あんまり変わらない
    //OSCTUNbits.TUN = 0b011111; //オシレータ調整レジスタ,最大周波数,あんまり変わらない

μsで,パルスの立ち上がり周期を測定したかったんですが,難しいですね。
32MHzでの動作周波数を下げてみる手はありますでしょうか?
処理が遅くなるので,あまりしたくないのですけど,
 

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

 投稿者:nekosan  投稿日:2014年12月30日(火)00時52分27秒
返信・引用
  > No.707[元記事へ]

matsuさんへのお返事です。

> いえ,つかってないです。今,ソースが手元にない場所にいるので,
> コピペできませんが,main関数内では,while(1)ループ内で,
> 自作のprintf互換のlcdprintfでキャプチャ値の表示とLEDの
> 点滅をやっているだけです。
>
> 今,他のマイコンのタイマーで,正確に正確なクロックを
> 出力させて,それでキャプチャタイミングを取ってみようかと
> 思っています。それでも2桁もふらつくようならどうしよう・・・。


そうですか。sleepの前後で何か変なことになってないかなと
思ったので。

もしかしたら、この1個だけでしか再現しなくて、同じ型番の
ICでも再現しないみたいなことは、ないでしょうかね?
 

レンタル掲示板
/79