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

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


お礼とご挨拶。

 投稿者:neko_sax  投稿日:2015年 4月16日(木)21時02分59秒
返信・引用
  失礼いたします。

「MIDIマスターキーボードシールド」の記事、を読ませていただいたものです。
とても、ためになる分かりやすい記事を有り難うございます。

私は、3オクターブ分の「足で踏んで鳴らせるMIDIキーボード」を自作したくて、現在、書籍を買って読んでみたり、いろいろと部品や道具を揃えたりしている最中の初心者です。

いろいろ検索して参考になる記事を探していまして、こちらのサイトでの記事がかなり近いように思い、参考にさせていただいております。
(記事を印刷して毎日、にらめっこしています・・・。)

同じようなMIDIシールドが作れるようになりましたら、これをタッチセンサー式に変えて作り上げたいと考えております。

以上、お礼とご挨拶まで。
突然失礼いたしました。
 
 

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

 投稿者:nekosan  投稿日:2015年 1月24日(土)01時01分40秒
返信・引用
  > No.725[元記事へ]

matsuさんへのお返事です。


> 関数を呼ぶマクロでした。ヘッダファイルで検索してみました。


FCYマクロの情報、ありがとうございました。
動作内容が理解できました。

FCYを定義しておくと、delay系関数で引数として
利用されてるんですね。
 

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

 投稿者:matsu  投稿日:2015年 1月23日(金)20時37分24秒
返信・引用
  > No.724[元記事へ]

nekosanさんへのお返事です。

> 解決できたんですね。よかったです。

先陣の皆様の教えはとても助かります。
突破口を作っていただいてありがとうございました。

> FCYっていうタグは、プログラム内だけでなく、
> ライブラリでも参照されている定数なんで
> しょうかね?(delay系関数とか?)

関数を呼ぶマクロでした。ヘッダファイルで検索してみました。

/*
* __delay32() provides a 32-bit delay routine which will delay for the number
* of cycles denoted by its argument.  The minimum delay is 12 cycles
* including call and return statements.  With this function only the time
* required for argument transmission is not accounted for.  Requests for
* less than 12 cycles of delay will cause an 12 cycle delay.
*/

extern void __delay32(unsigned long cycles);

/*
* __delay_ms() and __delay_us() are defined as macros. They depend
* on a user-supplied definition of FCY. If FCY is defined, the argument
* is converted and passed to __delay32(). Otherwise, the functions
* are declared external.
*
* For example, to declare FCY for a 10 MHz instruction rate:
*
* #define FCY 10000000UL
*/

#if !defined(FCY)
extern void __delay_ms(unsigned long);
extern void __delay_us(unsigned long);
#else
#define __delay_ms(d) \
  { __delay32( (unsigned long) (((unsigned long long) d)*(FCY)/1000ULL)); }
#define __delay_us(d) \
  { __delay32( (unsigned long) (((unsigned long long) d)*(FCY)/1000000ULL)); }
#endif



unsigned long longなんて知らなかった・・・。


> あまりお役に立ててないと思いますが、なんにしても、
> 原因まですっきりでなによりでした。

いえいえ,めちゃくちゃ助かりました。
ありがとうございました。
 

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

 投稿者:nekosan  投稿日:2015年 1月23日(金)01時02分15秒
返信・引用
  > No.723[元記事へ]

matsuさんへのお返事です。


> 突破口になりました。


解決できたんですね。よかったです。



> FCYは,FOSCの1/2(32MHz駆動なら16MHz)にセットする必要がある。
> タイマでカウントするクロックにシステムクロックを選択した場合,
> FOSCの1/2の周波数をカウントする。
>
> 突破口を開いていただき,ありがとうございました。
> 6%,カウントがずれる件も解決でき,すっきりあしました。
>


データシートの、エラッタとまでは行かなくても、
微妙な舌足らずは、PICに限らず、結構悩ましいですね。

FCYっていうタグは、プログラム内だけでなく、
ライブラリでも参照されている定数なんで
しょうかね?(delay系関数とか?)
最近のPICのコンパイラには手付かずなもので…

あまりお役に立ててないと思いますが、なんにしても、
原因まですっきりでなによりでした。

 

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

 投稿者:matsu  投稿日:2015年 1月22日(木)14時02分41秒
返信・引用
  > No.722[元記事へ]

nekosanさんへのお返事です。

いつもありがとうございます。

> 想定どおりの速度で動くケースがあるということで、
> 比較対象ができた、というのが、ひとつの突破口に
> なるかもしれませんね。

突破口になりました。

> その場合、PIC24シリーズは2クロックで1命令のRISCだったと
> 思うので、32Mhzでの処理速度は、16Mcycle(16MIPS)になる
> かと思います。
> それを踏まえて、delay系の関数の時間調整に使っている
> クロック源(nop命令?)や、キャプチャが入力している
> クロック源(システムクロック?)が、どのルートでどの
> ように(減速されて)伝わってくるのかを整理してみると、
> どこが正しくて、どこが計算と外れているのかが整理できて、
> 根っこが見えてくるような気がします。

まさにその通りで,
リファレンスマニュアルに次のように書かれていました。

The processor clock
source is divided by two to produce the internal instruction
cycle clock, FCY.

2サイクルクロックで1命令を実行する訳なので,
おそらく,FCYの値からnop数を決めているであろう,delayについて,
FOSCを絡めて,次のようにしました。

#ifndef FOSC
#define FOSC 32000000L
#endif
#ifndef FCY
#define FCY FOSC/2
#endif

> > __delay_ms(xxx);の動作,USBの動作,タイマーキャプチャの動作をすべて
> > 説明をつけるためには,System Clockの1/3固定分周が
> > 1/6でないと説明がつきません。

これも解決できました。
リファレンスマニュアル 専用タイマ付き入力キャプチャ
に,

タイマのクロック源の選択は,ICTSEL制御ビット(ICxCON<12:10>)を介して行います。
タイマは内部クロック源(FOSC/2)も使用できますし,TxCKピンに入力される
外部クロック源をタイマ内で同期モードを有効にしても使用できます。

とありました。これからは,FOSCでなく,FOSC/2をカウントすることがわかりました。
残念なことに,ICxCONレジスタのICTSELビットの説明には,単に,

111 = システムクロックをキャプチャ用カウンタ源とする

としか書かれてないので,FOSC/2をカウントするとはわかりませんでした。
ここが,

111 = システムクロックFOSCの1/2をキャプチャ用カウンタ源とする

となっていればすぐに気がついただろうと思うのですが・・・。

まとめると,

FCYは,FOSCの1/2(32MHz駆動なら16MHz)にセットする必要がある。
タイマでカウントするクロックにシステムクロックを選択した場合,
FOSCの1/2の周波数をカウントする。

突破口を開いていただき,ありがとうございました。
6%,カウントがずれる件も解決でき,すっきりあしました。
 

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

 投稿者:nekosan  投稿日:2015年 1月22日(木)00時40分53秒
返信・引用
  > No.721[元記事へ]

matsuさんへのお返事です。


> 32MHzでなく,16MHzで動作させると,キャプチャ値の6%近かったずれがほぼ無くなります。
> しかし,96MHz PLLブロックの動作がどうしても説明がつきません。
>


情報ありがとうございます。拝読しました。
想定どおりの速度で動くケースがあるということで、
比較対象ができた、というのが、ひとつの突破口に
なるかもしれませんね。



> <図 6-8>について
> PLLブロックで,PLL Prescalerで1/2にして4MHz Branchを作り,96MHzPLLの出力,
> 96MHz BranchをUSB Clockで1/2されることで,48MHzを作っています。
> これで,USBの通信はできていますので,48MHzで間違いないと思います。
>
> System Clockでは,CPDIVレジスタの設定で,1/1分周とし,その後1/3されて,
> PLL Output for System Clockとしています。
> つまり,システムクロックは,32MHzとなることを期待しています。
> しかし,実際にタイマーでキャプチャしてみると,16MHzとなっています。
> 割込み無しで,__delay_ms(xxx);の動作を試すと,やはり16MHzで動作して
> いるようです。
>
> PLL Prescalerを1/1分周とすると,タイマーキャプチャも__delay_msも32MHzで
> 動作していることが確認できました。しかしこの場合はUSB通信ができなく
> なるばかりでなく,キャプチャの値が5%少なくなります。
> (16MHzの時は,キャプチャの値の誤差はほとんどありません)
>
> おそらく,96MHz Branchが2倍の192MHzになって,タイマが間に合わなく
> なったのではないかと推測しています。(ありえるのかわかりませんが)
>
> __delay_ms(xxx);の動作,USBの動作,タイマーキャプチャの動作をすべて
> 説明をつけるためには,System Clockの1/3固定分周が
> 1/6でないと説明がつきません。


ブロック図と、設定内容を眺めると、USB側に96Mhz÷2=48Mhz
が供給されているとしたら、PLLの出力は96Mhzになっているもの
と思います。
(USBの通信ができているなら、48Mhzが正確に供給されて
 いるはずだと思うので)

一方で、PLL出力の分周比を1:1に、後段の分周が1/3だと、
システムクロックは32Mhzになっているはずなので、CPUの
マスタークロックも、たぶん32Mhzが供給されているのでは、
と想像します。

その場合、PIC24シリーズは2クロックで1命令のRISCだったと
思うので、32Mhzでの処理速度は、16Mcycle(16MIPS)になる
かと思います。


それを踏まえて、delay系の関数の時間調整に使っている
クロック源(nop命令?)や、キャプチャが入力している
クロック源(システムクロック?)が、どのルートでどの
ように(減速されて)伝わってくるのかを整理してみると、
どこが正しくて、どこが計算と外れているのかが整理できて、
根っこが見えてくるような気がします。
(ある程度、ライブラリコアのソースを読んでみる必要が
 あるかもしれません)

ちなみに、PLLの出力が192Mhzとなる使い方だと、多分
スペック外の動作になるので、何らかの誤差(6%とか)が
出るのは、なんとなく仕方ないのかなという気がします。


内蔵RCではなく、外付けのクリスタルやクリスタルオシレータ
を使ってPLLに4Mhzを供給しても、同じように誤差6%が生じたり、
動作が半分になったりするんでしょうかね?多分、192Mhzでは
なく、96Mhzの場合は、6%の誤差は出ないのでは、と思うの
ですが。

 

キャプチャの値が6%ほどずれる件

 投稿者:matsu  投稿日:2015年 1月21日(水)20時23分48秒
返信・引用
  nekosanさん,
いつも,すぐにお返事いただき,ありがとうございます。
先日の,キャプチャ値がずれる件ですが,少しわかってきました。
(同時に,picfunの掲示板でも質問していますが,御容赦ください)

32MHzでなく,16MHzで動作させると,キャプチャ値の6%近かったずれがほぼ無くなります。
しかし,96MHz PLLブロックの動作がどうしても説明がつきません。

こんな状況です。picfunの掲示板での投稿内容です。
どうしても,図6-8が間違っているとしか考えられないです。

-----
Configurationで,
#pragma config FNOSC = FRCPLL
// Initial Oscillator Select (Fast RC Oscillator with Postscaler and PLL module (FRCPLL))
として,ポストスケーラ付のFRCとPLLを使って,システムクロックを作っています。

「PIC24F ファミリ リファレンス マニュアル、セクション 06. オシレータ」
http://ww1.microchip.com/downloads/jp/DeviceDoc/39700C_JP.pdf
のマニュアルの2,19ページに

「図 6-1: PIC24F 全般のシステム クロック回路図」
「図 6-8: 96 MHz PLL ブロック」

があります。

<図 6-1>について
ポストスケーラを1分周としました。PLL Blockに8MHzが入力するはず。


<図 6-8>について
PLLブロックで,PLL Prescalerで1/2にして4MHz Branchを作り,96MHzPLLの出力,
96MHz BranchをUSB Clockで1/2されることで,48MHzを作っています。
これで,USBの通信はできていますので,48MHzで間違いないと思います。

System Clockでは,CPDIVレジスタの設定で,1/1分周とし,その後1/3されて,
PLL Output for System Clockとしています。
つまり,システムクロックは,32MHzとなることを期待しています。
しかし,実際にタイマーでキャプチャしてみると,16MHzとなっています。
割込み無しで,__delay_ms(xxx);の動作を試すと,やはり16MHzで動作して
いるようです。

PLL Prescalerを1/1分周とすると,タイマーキャプチャも__delay_msも32MHzで
動作していることが確認できました。しかしこの場合はUSB通信ができなく
なるばかりでなく,キャプチャの値が5%少なくなります。
(16MHzの時は,キャプチャの値の誤差はほとんどありません)

おそらく,96MHz Branchが2倍の192MHzになって,タイマが間に合わなく
なったのではないかと推測しています。(ありえるのかわかりませんが)

__delay_ms(xxx);の動作,USBの動作,タイマーキャプチャの動作をすべて
説明をつけるためには,System Clockの1/3固定分周が
1/6でないと説明がつきません。

いくら何でも,図 6-8が間違っているとは思えないのですが,どうしても
1/6としないとつじつまが合わない状況です。

USBも動作させた上で,マイコンを32MHz駆動したいのですが,
アドバイスいただけませんでしょうか?
 

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

 投稿者:matsu  投稿日:2015年 1月 8日(木)02時14分43秒
返信・引用
  > No.719[元記事へ]

nekosanさんへのお返事です。

すみません。原因がわかりました。
割込み許可や割込みフラグクリア,設定の順番が適切ではありませんでした。
現在,waitを入れなくても大丈夫になっています。
ご心配をおかけしました。
 

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

 投稿者:nekosan  投稿日:2015年 1月 8日(木)01時19分57秒
返信・引用
  > No.717[元記事へ]

matsuさんへのお返事です。


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


リセット回路周りが原因でなければ、
キャプチャやタイマ周りでなにか悪さを
している部分があるのかも…

ちなみに、リセットというのは、HALTが
掛かることでしょうか?それとも、何度も
再起動がかかってしまうのでしょうか?
 

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

 投稿者:nekosan  投稿日:2015年 1月 8日(木)01時16分54秒
返信・引用
  > No.716[元記事へ]

matsuさんへのお返事です。


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


なんともいえないんですよね…。

といっても、もう10年位前に、16F873とCCS-Cでの話し
ですが、C言語と言っても、内部的にはSFRを操作して
いるだけだし、プログラムの組み方によってはおかしな
動作になってしまったりすることもあり、結局、
展開リストを眺めて、ようやく原因がわかったりとか、
なんか苦労した記憶があります。

最近のコンパイラがどうなっているかは、正直わからない
のですが。

そのあたりもあって、最近は何かとAVRばかり弄って
います。
 

レンタル掲示板
/79