ともの技術メモ

続いて、PIC32MXで7segLEDを点灯してみました。

使用したのは4桁のカソードコモンの７セグメントLEDです。

回路は各桁のSEGMENTのA～G、DPをポートBのbit4～10、bit11に100Ωの抵抗を介して接続、各桁をデジタルトランジスタDTC123ESAを介してポートBのbit2,bit3、ポートAのbit2,bit3で駆動しています。

ダイナミック点灯の処理は割込みを1ms周期でかけて、1msごとに点灯する桁を変更しています。

表示している内容は0.1秒単位のストップウォッチ風の何かです。（単にカウントアップしているだけ）

さすがに28pinのDIPマイコンだとこれだけでポートを12本も使ってしまいます。PIC32MX120F032B（PIC32MX120F016BやPIC32MX220F032Bも同じ）は電源・GND関係だけで6本、さらにデバッガで3本の端子を使ってしまいますので、ちょっと苦しいかもしれません。

なお、デフォルトではJTAGやセカンダリオシレータがイネーブルになっているようで、使えない端子があります。それを解決するために、15行目に

#pragma config JTAGEN = OFF, FSOSCEN = OFF

という記述を入れて、JTAGやセカンダリオシレータを禁止しています。

なお、例によって役に立たないソースを置いておきます。→7seg駆動のソース

あ～、コメントは直し忘れていますので、無視してください。^^;

待ちループ、割り込みで点滅するLチカを紹介しましたが、MIPS CPUの場合には別の方法の時間待ちも可能です。
MIPS CPUの場合にはCPUの中のCP0（CoProcessor 0）というのがあって、その中にCOUNTレジスタというレジスタがあります。このレジスタはCPUコアの周波数の1/2の周波数でカウントアップしていきますので、CPUコアの周波数がわかっていれば、時間待ちに使うことが可能です。

#define SYS_FREQ (40000000L)

void foo(int index)
{
 register int i,j;
 i=_CP0_GET_COUNT();
 j=index;
 while(_CP0_GET_COUNT()-i<j);
}

int main(void)
{
＜途中略＞
while(1){

 foo(SYS_FREQ/20);
 mPORTAToggleBits(BIT_0);
 }

return 0;
}

本来、CP0のレジスタ読み出しには専用命令（ｍｆｃ）が必要なのですが、コンパイラにはじめからマクロ定義が用意されているのでこんな感じで使えます。この例は100ms待ってＬＥＤを反転させます。このレジスタには書き込みもできますが、基本的に読み出し専用で使います。読み出し専用で使えば複数のタスクでも共有できるからです。ただし、40MHz動作の場合には200秒程度でカウンタが１周しますし、上記の使い方だとその半分で正常に動作しなくなりますので要注意です。

ソースリストはこんな感じです→CountレジスタでLチカ

このレジスタは特定の区間のCPUの処理時間などの計測にも使えるので結構便利です。デバッガでCPUを停止させるとこのレジスタも停止するので、ブレークポイントを２箇所設定してそれぞれでこのレジスタを見れば処理時間がわかります。

Ｌチカは動いたものの、結局何MHzで動作しているのかよくわからなかったPIC32MXですが、実際の動作周波数を調べてみます。

方法はいろいろありますが、知りたいのはプログラムの実行速度なのでデバッガの表示と実際の速度から推定する手段をとってみます。

まず、ループで時間待ちするプログラムのコードに着目します。

void foo(int index)
{
 register int i;
 for(i=0;i<index;i++);
}

int main(void)
{
　＜途中略＞
while(1){
 foo(100000);
 mPORTAToggleBits(BIT_0);
 }
return 0;
}

ソースからは1回の点灯期間／消灯期間の間にｆｏｏ（）という関数が１０万回ループすることがわかります。ループ以外の時間はほとんど無視できると思われるのでループに着目します。

デバッガでプログラムをいったんスタートしてブレークし、Disassembly Listingを表示しながらアニメーション実行をさせると、

の赤い四角で囲った部分が「for(i=0;i<index;i++);」のループ内であることがわかります。実際には、最後のbne命令はDelayed Branch命令なので、その次のnopも実行しているはずです。また、ループ内にはlw命令が入っていて、メモリからのリードサイクルが発生することになりますが、頻度は低いのでここではそれが速度の制約にはおそらくならないでしょう。
となると、１ループで５命令を5clkかけて実行することになります。つまり、foo()関数では時間待ちとして約５０万clkサイクルを要することになるわけです。

一方で、runモードで実際の実行時間を計ってみると、

H区間/L区間ともに約75msであることがわかりました。ここから計算すると、50万clkサイクルが75msなので、75000000ns/500000=150ns=6.67MHzということになってしまいました。

どうやらconfigビットの設定がおかしいようですので、調べていくと、#pragma config の設定はMPLAB IDEの「Help」→「Topics」→「Language Tools」→「PIC32MX Config Setting」の中にあることがわかりました。

そこで、これを参照してConfigの設定を

#pragma config FPLLMUL = MUL_20, FPLLIDIV = DIV_2, FPLLODIV = DIV_2, FWDTEN = OFF
#pragma config POSCMOD = OFF, FNOSC = FRCPLL, FPBDIV = DIV_2

と修正したところ、H区間/L区間ともに約15msになりました。計算すると、1サイクルが30ns＝33.3MHzということになりました。
ちなみにFPLLODIV = DIV_1 のままでは暴走してしまいました。まあ、66.6MHzとなるとしかたないでしょう。

こんどはConfigの設定を

#pragma config FPLLMUL = MUL_20, FPLLIDIV = DIV_2, FPLLODIV = DIV_2, FWDTEN = OFF
#pragma config POSCMOD = OFF, FNOSC = FRC, FPBDIV = DIV_2

と修正すると、内部オシレータ（8MHz）が直接SYSCLKとして使用されるはずですが、H区間/L区間はともに約75ms＝6.67MHzに戻りました。

ここまでの結果から考察すると、1ループが5clkで回っているのではなく6clkになっていると考えると辻褄が合うようです。
（75000000ns/600000=125ns=8MHz、15000000ns/600000= 25ns=40MHz）

そこで、「Project」→「Build Option」→「main.c」でCategoriesをOptimizationを選択して、最適化を「０」から「s」に変更してみます。

すると、青の部分をみるとわかるように関数foo()の呼び出し自体が削除されてしまいました。orz・・・
この状態でリアルタイム実行させてみると、370～380nsでトグルしています。これは125nsの3クロック分、ということなのでしょう。 Configの設定を「FNOSC = FRCPLL」に変更すると70～80nsのトグルになりましたので、こちらも25nsの3クロック分、赤で囲んだ部分のループ（Delayed Branchで実行されるnopを含めて3clk）ということであっていそうです。

修正したLチカプログラムをアップロードしておきます。

• ループでＬチカ
  100万回ループで150msの待ち時間を作って、0.3秒周期でLEDが点滅します。
  ただし、最適化をかけてしまうと待ち時間そのものがなくなってしまいます。
  ＜追伸＞SYS_FREQの定数定義が間違っていました（直し忘れ）。修正していませんのでご注意を。
• 割り込みでＬチカ
  タイマー割り込みで100ms周期（1秒間に10回） でLEDが点滅します

いずれもＣＰＵは40MHz動作(SYSCLKは40MHz、PBCLKは20MHz)です。