一番の大物の作業台の天板を近場のカインズで買ってきました。1820ｘ910ｘ25のラジアタパイン集成材(￥8,800)です。このままでは、車にの乗らないので、作業台の大きさの1500ｘ700にカットしてもいました。
周囲のエッジをトリムし、表面をやすり掛け、オイル塗装を行う予定ですが、作業開始まで、ガーデンルームに置いておきます。
デカいです。
同じく、脚ですが、四角い枠型と迷った挙句、支柱型をポチりました。届いて、さっそく開けてみましたが、梱包もそれなり。
ネットのレビューにあるような、プレートの曲がりなどもなく、ぱっと見の仕上がりは上々です。また、強度もしっかりしているように見えました。
そのほか、ついでにポチったものも届きました。ボーズ面R3.2のトリマービットは、なかなか近くのDIYショップでは見つけられなかったので、ポチってます。
今週は、材料集めまでで、作業時間がちょっと取れ無さそうなので、来週から加工、組み立てに入ります。
続きは、こちら。
パソコン（LaVie LL750/R）修理のその後です。
一旦は、直ったPCでしたが、その後、段々と、と言うか、比較的直ぐにまた音が出なくなってしまいました。
症状としては、時々、バチッという音がして、日に日に、音量が低下していくのでありました。そして、ついに、スピーカからの音が出なくなりました。
なので、しばらくは、イヤホンで聞いているという状況でしたが、最近では、イヤホンの接触というか、イヤホン近く面(赤い丸)に力を掛けないと接触が悪いのか、イヤホンからの音も聞こえない状況が。その後、騙し騙し使っておりましたが、遂に力一杯押し続けないと、音が出なくなりました。どうやら表面実装部品の半田にクラックでも入ったのではないかと。
まず、前回修理したスピーカを見てみます。案の定、酷い状態となっていました。ボイスコイルとコーンが完全に剥がれてました。写真(1つ目)は、スピーカ単体を取り出したものです。
写真(2つ目)は、修理用に使えるかもと思って買って置いた極小径のスピーカです。φ20、8Ω、1w。本当は４Ωが定格ですが探せませんでした。
代替スピーカは、直径がΦ２０で、スピーカボックスの穴にピッタリハマりました。周りをシリコーン系のパテで埋めてます。
PCに組み込んだところです。なぜか不思議と音が出てます。ただ、インピーダンスが合って無いので(4Ωのスピーカは見つけられず）、音が小さめです。
基板の接触不良の箇所を特定します。明確に力を掛けると音が切れるので、簡単に見つかるだろうと思っていましたが、甘かったです。
まず最初にやったのは、基板に力をかけるとイヤホン出力の電圧がどうなるか。実際、イヤホン出力の電圧をオシロで確認しながら基板の隅を押すと確かに電圧が出なくなります。ただ、押しても切れない事があったりと、どこら辺が怪しいかの検討がつきません。
ついで、上のスピーカを修復する前に仮に繋いでみた時に、基板に力をかけるとイヤホンからの音が切れて、代わりにスピーカから音が出るような事がありました。これは、単にイヤホン出力が出なくなると言うことでは無く、スピーカとイヤホンの切り替え制御が上手く言って無い様でした。道理で、Windowsのステータスバーがイヤホンをつないだ時の様にチカチカしていたはずです。
RealTeckのIC（搭載してる型番のものは見つからなったので、一番近いと思われるもの）のデータシートで回路図を確認すると、イヤホン、マイクの接続判定用の端子がありました。グランドに落とす抵抗（シンク電流）の値によって判定しているようですね。回路図の赤丸のところを基板から探して、どうなっているかを確認してみました。
丁度１３番ピンとその上にある２つの抵抗がそれで、左がイヤホン、右がマイクにつながっていました。グランドにショートする形なので、IC側は常に3.3Vで、抵抗を挟んだ接地側は０V（イヤホン接続時）で本当はなにも差が無いはずです。ところが、イヤホンから音が出なくなるときは、なぜか、ICDの足（の半田）のところで0Vになっている様でした。
試しに、イアホンをつながない状態でも測ってみましたが、やはり、基板に力を掛けると3.3Vから0Vになる時がありますが、押し方が同じでも変化が無いときもあります。
この時、同時に、スピーカからかなり大きな音で、ガリッと音がすることもあります。正確にそのタイミングで測った訳ではないですが、このICはD級アンプなので、スピーカーの＋とー端子には、常に1.5V位が掛かっていて、その差分により最大＋３－３Vの出力を作っているので、どうもこの１．５Vが０Vになるようです。これが、イヤホンとスピーカの切り替えで起こるものなのか、それとは別の大元の原因で起こるものかは分かりませんが、いずれにしれも、定常状態で1.5Vがスピーカ両端に掛かることになり、４Ωのインピーダンスとしても1.5Ｖｘ1.5Ｖ／4.0Ω＝0.56Wが常時掛かることになり、実際には直流抵抗はもっと小さいのでスピーカの発熱量が大きくになりボイスコイルとコーンが分離したり、ケースが変形したりしていると推定しました。
では、何故このピンが０Vになるのか。可能性は3つ。①このピンがどこかでショート。②ICと半田の間のクラック（断線）。③IC自体が電圧を出さない（別にICの入力などが異常）。①は基板の実装を見る限り可能性は低そうです。②はあるかもしれませんが、見た目は分かりません。もっと拡大率を上げればひょっとしたらわかるかな。ということで、③の線を疑って、まずは、ICへの電源ラインが落ちていないか確認してみました。テスターのプローブを細いピンに当てながら基板に力を掛けるので、かなりやりずらかったですが、一通りやってみて、異常は分かりませんでした。他の入力ピンなどでは、検出用の13番ピンの電圧を変えることは無いだろと思いやってません。
で、結局、②の可能性を疑い、とりあえず、13番ピンの半田を当ててみることに。表面実装用の細い半田ゴテもなかったので、かなり難しかったですが、13番ピンが一番端であったので、何とか出来たかな？
結果は、一応治った感じです。ただ、13番ピンの断線では、スピーカ端子が0Vになる理由は分かりません。原因の分からない接触不良なので、たまたま、発生していないだけかもしれませんが、とりあえず再組することに。
ということで、仮にも治った感じになったので復元を開始しました。スピーカは、左側も壊れていたんですが、今回直したスピーカも再度故障するかもしれないので、様子見として、今回は手を付けないままです。
極小径のスピーカがピッタリはまって何とか復活しました。いまだ、接触不良（とスピーカ電圧0V）の原因は不明ですが、しばらく使ってみて様子をみます。音量が少し小さいですが、ボリュームを上げれば何とかなる範囲なので、それは、我慢します。
本当にこれで、パソコン修理が完了したかは、追って、報告することにします。最後までお付き合い頂きありがとう御座いました。
低消費電力化の実装に手こずっています。
まず、システムモード、バックライトモードの状態遷移を割り込み処理で行うことにしました。通常処理で、表示と各モード処理などを行うと、表示に1秒とか掛かる場合は、反応が遅くて使い物になりません。ただ反応が遅いだけならまだしも、タイムアウト処理（スイッチ操作後30秒とか、音無し１分とか）が規定時間通りうまく働かず、状態遷移が機能しないことに（デバッグでも何を確認しているか分からない状態）。 なので、タスク構造を大きく見直して、基本のモード処理を全て割り込みベースにすることしました。 ただし、表示処理は時間が掛かるので、バックグラウンドタスク化して、表示自体は出来るまで待つという方法にしました。 ここで、懸案はフレームオーバーしないかどうかということ。現状の処理時間を測ったところ、システムモードとバックライトモード判定処理は、100μS以下だったのて、3KHzサンプリングでも行けそうです。一方、スタンバイモードの時1MHzクロックでどうかと言うと単純に8倍の時間が掛かるので3KHzはとても無理、よって、1KHzサンプリングとする事に。というのも、スタンバイモードでは、音色判定としてFFTは不要だからです。 タスク構成を図に表すと、こんな感じです。 次いで、音判定も割り込み化できないかトライ。まず、音判定自体がどの位時間が掛かっているか調べると、最初500msも、rms計算でfloat演算を全部intとlong int処理に変更しても（1024の二乗の256サンプルでLong intに収まるはず）、25msが限度。判定だけなら、閾値を二乗にしておけばいいので、平方根も取ってみたけど大差なしです。なので分りやすい様に、平方根計算は残すことに。25msも掛かるので、割り込み内ででの処理は無理なので、バックブランド処理のまま残すことにしました。割り込みでのモード判定処理との間で、フラグによるやり取りが必要になります。 バックグラウンド側で、割り込みによるAD変換が256データ完了するのを待って、音判定処理開始、終わったら音判定完了フラグを立て、今度は、割り込み側でモード判定処理に使いと言った構造です。 結構、ややこしいタスク構造になってしまいました。 １０分間、音が無いと判断したらスリープモードに遷移します。これは、単にsleep命令（MLAでは、SLEEP（）関数）でOKです。 で、問題はスリープからどうやって復活するかです。PICにはいくつかの方法がありますが、ウォッチドッグタイマの使用が一番シンプルでしょうね。タイマからの割り込みと言う手もありますが。以下が、スリープモードを選んだ時の処理です。 最初の部分は、IO出力を０にして消費電力を抑えるための処理。 あとで、タイマ割り込みが入らないように割り込み禁止とし、ウッチドッグタイマをクリアするために、WDTCLRを行った後、SWDTEN=1でウォッチドッグタイマを有効にしてから、スリープに入ります。 そうすると、予め設定したウォッチドッグタイマの時間経過後に、スリープのコマンドの次からプログラムが再開するという段取りです。 ここまで、出来るようになるまで、結構、試行錯誤をしてます。今のタスク構成上は、この処理が走るのが1KHzのタイマ割り込み中なので、本当は割り込み禁止、許可は不要のハズです。 ウォッチドッグタイマの時間は、CONFIGレジスタのWDTPSで512(=約2秒）に設定する必要があります。 ここまでは、まあ、いろいろ試行錯誤はしたものの、何とかなりましたが、そこからが結構やらしいです。 まず、簡単なところからいうと、スリープ中に一旦、IO=0としたことで、LCDが初期化されます。なので、スリープから復活してもLCDに何も表示されないという問題が。ま、これは、もう一度LCD初期化ルーチンを呼べば済む話なので、単純な話ですが、そうは問屋が卸さずです。割り込みの中で、LCD初期化ルーチンを呼ぶとその中でLCDへのコマンドライト関数を呼びと、どんどん関数のネストが深くなり、ついにはスタックオーバーフローが発生してしまいました。最初は何が起こったか全くわかりませんでしたが、STKPTRレジスタの値を表示させてみて分かりました。原因が分かったのでとりあえずLCDのリセットを発生させないようにして、LCD初期はしないでデバッグしてます。いずれは、改善が必須です。 次の問題は、スタンバイ時そのものの問題です。 問題というか、必然というか。低消費電力化のため、８MHz作動を１MHz作動に切り替えると、いろいろ影響が出ます。まずは、処理スピードが1/8になるので、ソフト的に作っていた1msカウンタ、50msカウンタ、１秒カウンタなどが、ことごとくずれます。AD変換のパラメータが変ります。LCD描画速度が激遅になります。等々。 LCD描画は、SPIの速度が律速なのでどうしようもないです。ソフトタイマとAD変換パラメータは、2つの定数を切り替える様にソフト処理をそれぞれ追加しました。 最初にも書いた通り、ADサンプリングも３KHzを１KHzに変更します。なので、256サンプルに、256mSかかり、有音判定も25msだったものが、200ms必要になるので、トータル0.5秒近く必要になります。なので、当初、スリープ中は、実際には2秒スリープ、0.2秒スタンバイの繰り返しのハズが、2秒スリープ、0.5秒スタンバイとなって、低消費電力化の効果激減してしまいます。実際には、0.5秒では終わらないので、効果はもっと落ちます。単純計算で、稼働日数が約5日減少の影響になりそうです。（実測は、まだできてません） 低消費電力化と直接関係は無いですが、どの位バッテリが持つかを測るため、フラッシュメモリに作動時間を記録するように考えました。 使っているPICがプログラムメモリをプログラムから書き込みできるタイプです。 フラッシュメモリのイレーズ、ライト、リードの基本的関数を作ってみました。リードは直ぐできましたが、ライトが動くまで、結構悩みました。 最初は、フラッシュメモリのプロテクト設定です。これも、CONFIGレジスタの設定になりますが、0xF000からの４Kbyte分を書き込み可能とする設定は次の通りで、プログラムが間違っているのか設定が間違っているのか何回もトライしてます。 とりあえず、何か書けるようになってからも、何故か、０しか書けません。ちょうど、１Hz毎にタイマ値を書いて、直ぐに読み出して表示するテストプログラムで確認しましたが、全て０です。アドレス設定とか型の不整合なども、何度も見直しましたが、分かりません。で分ったきっかけが、テストプログラムを起動直後から、ずっと表示を見ていると、最初だけ何か数値があり、あとは必ず０になるという動きを発見。最初の数回だけ正しくてあとは動かなくなるモードも考えましたが、ちょっと思いつきません。数字が出るのは、テストプログラムを書き込んだ直後のみ。 で、分かりました。フラッシュメモリの”書く”＝”０にする”だからです。イレーズをすると0xFFになり、値を１回書くと、０のbitが０になり値が書き込まれます。全てのbitに０を書いたら、それ以降は１にならない。です。 値を書く前に、イレーズ処理が必要なんでした。 確かに、データシートを良く読めべば書き込みの前にイレーズがされている場合・・とあります。ワード書き込みモードを使ったんですが、これは新しいモードなので、事前のイレーズはいらないのかなと勝手に勘違していました。 ということで、以下の関数が無事動くことが確認できました。ほっ。 バッテリ電圧が下がりＢＯＲになったとき、結局はリセットなので、プログラムは最初から動くことになります。そこで、通常のPOR（Power On Reset）と区別をして、フラッシュメモリにデータを書き込むことを行えばいいはずです。 PORかBORかの区別は、RCONレジスタのPOR bit、BOR bitを使えば判別でき、コードとしては次の様になります。これで、PORの時は、フラッシュメモリーから値を復活し作動し、BORの時は、フラッシュメモリーに値を書いたあと、バッテリが死ぬまで無限ループで終了となるはずです。 ところが、これもうまくいきません。実際、プログラムがこれでいいのかを確認するのが、なかなか難しいですが、強制的にreset命令をデバッグ用に入れるなどしてみると、ロジックとしては動いているようですが、フラッシュメモリーの値が正しく書けてません。MPLAB Xでメモリを読み出しても、やはり０になっています。今回は、ちゃんとイレーズを入れているのですが。 困ったときは、まず、データシートを良く読めということで、いろいろ読みました。原因はまだ特定できていない状態ですが、ちょっと致命的なことに気づいてしまいました。 データシート上、フラッシュメモリのイレーズ（1Block分）に掛かる時間TIE＝33msとあります。つまり、BOR後、最低33ms立たないと、データを書ける状態にならないということです。バッテリが死にかけている状態で、そんなに作動できるのか微妙です。 (2022.3.9追記）実際、DC電源をつないで、だんだん電圧を落としていって、VDDCOREの電圧がどうなるか確認してみました。2.2Vを切ってからVDDCOREが２.0Vとなるまでの時間は、約1.1msでした。やっぱり時間的にも無理ですね。実際には電池の電圧はもっと滑らかに落ちるでしょうが。 もう一つは、フラッシュメモリの書き込み電圧です。VPEW＝2.25V(min)とあります。一方、BOR判定の電圧は、VBOR＝1.9～2.2Vです。つまり、BORが発生した時の電圧では、フラッシュメモリには書き込みできないということです。 なんと。 構想が見事に破綻しました。 う～ん。 ということで、少し疲れ感、満載です。（いろいろ、勉強にはなりましたが） さて、どうしようかな。 消費電流低減がどこまでできるかは結果次第ということで、Violin Timer機能本体の仕上げをしますか。バッテリ交換の頻度が上がっても、使えるもの作って、なんぼですからね。 まだ、完成まで、とっ～ても長そうですが、よろしかった、お付き合い願います。タスク構成の見直し
有音判定
SLEEP時の問題
case CPU_SLEEP:
//prepare for sleep
TFTCS = TFTCD = 0; //0 for LCD
TFTRST = 0
RC0 = RC1 = RC2 = 0; //0 for CLOCK
//WDT
di();
CLRWDT();
WDTCON = 0x01; //SWDTEN = 1 for wake up
SLEEP();
//wake up sequence
WDTCON = 0x00; //SWDTEN = 0
ei();
TFTRST = 1;
break;
スタンバイ時の問題
フラッシュメモリ活用
#pragma config WPFP = PAGE_59 //Write Protect Program Flash Page 59
#pragma config WPEND = PAGE_0 //Start protection at page 0
#pragma config WPCFG = OFF //Configuration Words page erase/write-protected
#pragma config WPDIS = ON //WPFP<5:0>/WPEND region erase/write protected
/* flash memory */
union {
unsigned int iw;
struct {
unsigned char il,ih;
};
} fd;
void flash_erase1()
{
TBLPTRU = 0x00;
TBLPTRH = 0xF0;
TBLPTRL = 0x00;
EECON1 = 0b00010100; //FREE = 1,WREN=1,WR=0
di();
EECON2 = 0x55;
EECON2 = 0xAA;
WR = 1; //WR=1
ei();
EECON1 = 0b00000000; //WPROG =0,WREN=0,WR=0
}
void flash_write_word(unsigned char adrs,unsigned int data)
{
TBLPTRU = 0x00;
TBLPTRH = 0xF0;
TBLPTRL = 0x00 + adrs+ adrs;
fd.iw = data;
TABLAT = fd.il; //LSB
__asm("TBLWT*+");
TABLAT = fd.ih; //MSB
__asm("TBLWT*");
EECON1 = 0b00100100; //WPROG = 1,WREN=1,WR=0
di();
EECON2 = 0x55;
EECON2 = 0xAA;
WR = 1; //WR=1
ei();
EECON1 = 0b00000000; //WPROG =0,WREN=0,WR=0
}
unsigned int flash_read_word(unsigned char adrs)
{
TBLPTRU = 0x00;
TBLPTRH = 0xF0;
TBLPTRL = 0x00 + adrs + adrs;
__asm("TBLRD*+");
fd.il = TABLAT;
__asm("TBLRD*+");
fd.ih = TABLAT;
return fd.iw;
}
ただ、フラッシュメモリの本質的問題は避けて通れません。書き込み回数制限があります。データシートを見ると、１０，０００回以上とあるではないですか。
ダメです。バッテリ電圧低下時に作動時間が記録されてないとけないので、１秒毎に作動時間をフラッシュメモリに書くつもりでいましたが、そんなことしたら、３時間も経つと書けなくなってしまうということ。書き込み間隔を広げても、実際の運用までに消耗してしまいそう。１０，０００時間以上の練習時間を記録（そんなに練習できるか！！）しようとすると、１時間に１回しか記録できない勘定です。
ということは、解決策は一つ。バッテリＯＦＦのタイミグで１回のみ、それまでの作動時間を記録するし無い、と考えた次第。
で、Brouwn Out Resetの機能をトライすることになりました。BOR(Brown Out Reset)活用
if((POR == 0) && (BOR == 0)) {//PORの時
POR = 1; //for detetc BOR
isBOR = 0;
}
else {//BORの時
if(BOR == 0)
isBOR = 1;
}
//
if( isBOR == 1) {
stat_to_flash();
while(1);
}
flash_to_stat();
今後の計画
作業机の具体的イメージを固めるための事前調査。
作業机を作るって、結構流行っているんでしょうか。自分の城って感じですものね。
・電子工作に関する”教育的”動画も多数です。
・囲われた感が、結構、好きです。
・”作業机”の作り方のヒントをもらいました。
・良く参考にしますが、すごいです。
・収納、整理・整頓と言う観点で。
みなさん、いろいろ工夫してますね。
作業机の更新をします。
今は、古くなったコタツを使っていて、上に自作の簡単な棚を載せているんですが、多少手狭になっているのと、パソコンデスクと高さが違うので、床に座ったり椅子に座ったりと、やりずらいという欠点があります。
なお、電動トリマを活用して何か作ってみたいと言うのも、作業台の更新をしたい理由です。
お恥ずかしながら、こんな感じで雑然としてます。3Dプリンタも仮置きのつもりが、そのまま。
構想を具体化する前に、必要要件を抜き出してみます。いわゆる、要求分析ですね。
と、こんな感じ。
という事で、まずは整理整頓。作業机の高さ方向に伸ばす関係上、今の位置だと、どうしても窓を塞ぐことになってしまうため、パソコンデスクと作業机の左右を入れ替えることにしました。
ここのスペースに、幅150の作業机を新設します。
初期イメージを作ってみました。
机は、ポチることも考えましたが寸法的に良いものが仲々見つからないので、集成材で作ろうと考えています。机の脚は、スチール製のものが只今の候補です。
未だ具体的な構想を固めてるところですが、ボチボチ作っていきます。
よろしかったら、お付き合い願います。
続きは、こちら。
相変わらず、USBのデバイス認識はうまくいっていませんが、アドレス設定までは何とか出来ているようですが、コンフィグレーション設定でコケている様。なかなか、手ごわいのでで、低消費電力化と合わせて、全体のシステム動作の設計を進めます。
消費電流の低減をある程度想定したうえで、まず、全体の作動シーケンスを考えます。大きくは、システムモード（CPUの作動周波数）と、LCDバックライト輝度の制御になります。練習時を通常時として、バイオリンの音を検知しなくなったら、スタンバイモードにて消費電流を低減し、さらに、そこから時間がたったら極低消費電流のSLEEPモードに遷移するという考えです。これをまとめると次の様になります。 SLEEPモードからの復帰は、割り込みや、WDTをトリガとしますが、ここでは、WDTによる復帰を考え、2秒周期で、通常モードへの復帰を判断することにしました。間隔をあまり長くすると反応が遅くなるし、逆に、短くすると消費電流の低減効果が減ってしまうため、２秒にしています。 一方、LCDのバックライト制御は、システムモードと基本的には独立していて、必要最小限の点灯とするため、練習中でもLED消灯とできるように考えました。 プログラムを実装するにあたり、シーケンスを状態遷移図の形に書き表しました。システムモードは大きく分けて４つ（通常、スタンバイ、SLEEP、USB）ありますが、状態としては、更に２つ増やした６つの状態で実装することにしました。 バックライトの方も同じく状態遷移図に表すと、こうなります。 状態遷移図では、他の作動モード（時計とか）に遷移したときの条件も一部追加していますが、ここは、実装を行いながら少し手直しをしていこうと考えています。 肝心の消費電流低減ですが、方法としては、 ・電源電圧を下げる ・ＣＰＵクロックを下げる ・内臓モジュールを停止 ・ＤＩＯからの電流を下げる ・バックライトの電流を下げる と言った方法があります（詳しくは、こちら）。最初のものは電源3.3Ｖ作動で、これ以上は難しいので取れません。バックライトは既に実験済みなので、CPUクロックを下げる手法で確認をしていない、CPUクロック１MHz動作と停止（内臓モジュール停止、DIO電流低減）を確認してみました。 結果は次の様になり、１MHzで2.1ｍＡ、クロック停止（SLEEP）で、0.5mAとなりました。クロック停止で0.5mAとあるのは、主にオペアンプと時計ICの電流になります。 ちなみに、USB作動用に24MHzとすると、9.5ｍＡにもなっていました。 システム作動シーケンスと実測消費電流が分かりましたので、稼働時間の予測をしてみます。一応、平日は１時間、土日は３時間の練習をするとした場合（年間573時間ですね。1万時間には17.5年も掛かってします）、 稼働時間は、32.5日と出ました。 消費電流低減の目途が立ちました（計算上は）。あとは、ソフトの実装と確認です。 Violin Timer機能本体の仕上げもまだなので、それと合わせて進めていきます。 まだ、完成までいろいろありますが、よろしかった、お付き合い願います。システム動作の設計
状態遷移図
消費電力測定
稼働時間予測
最初、電池だけで1ヵ月持たせたいと考えていましたが、計算上は、何とか持ちそうです。今後の計画
USBのトラブルシュートをした結果、原因が分かりました。
前回で、USBモードが動かないと書きましたが、以前からプログラムには、MLAからCDC-Serial Emulatorを持ってきて組み込んでありましたが、回路もちゃんと組んでない状態でしたので、一部コメントアウトしているところがありました。具体的には、下のUSBDeviceAttch()です。ここをコメントアウトしないと、プログラムが止まってしまうからでした。 今回、詳しく調べていくと関数内の次の行で、USBENが１(enable)にならず、ずっと止まっていることが分かりました。これは、USBを使うときの一番基本の設定なのに何故止まってしまうのか不思議でした。 マニュアルを見ると、 とあるので、RC発振器（INTOSC）８MHzを２分周してをPLLに食わせて48MHzを作り、それを8分周することで、LOW Speed USBに必要な６MHz設定しましたが、動きません。 (Microchip DataSheet DS39931Dより） 解決しないまま、FFTの高速化のため、この48MHzが使えるんじゃないかと思って、設定を変えてみたことがきっかけで原因が分りました。 48MHzは、CPDIVで２分周して24MHzを使うことになりますが、その後の切替スイッチのところにある注記(4)です。 このスイッチをPrimary Clock側にしないとUSBは動かないってあります！なんと。 でも、USBのクロックとCPUのクロックって別でいいと思うじゃないですか。 ただ、残念ながら、PCのデバイス認識としてはエラーが出ているので、まだ完全ではないですが、ハード的にはつながった様です。 副作用として、FFTの処理速度は３倍になりました。また、消費電流も大幅増加。 なので、結論としては、通常作動とUSB接続状態でクロックを可変とする必要があるため、USB接続の判別ハードは必要ということも分かりました。 原因が分かって、がっくりと言う感じですが、要は”マニュアルをしっかり読め”ということに尽きるんですかね。 USBのソフトは完全にできてませんが、目途が立ったということで、電池寿命延長のための消費電流低減について、いくつかトライアルをしてみます。 まだ、完成までいろいろありますが、よろしかった、お付き合い願います。USBイネーブル信号
MAIN_RETURN main(void)
{
/* Initialize I/O and Peripherals for application */
SYSTEM_Initialize(SYSTEM_STATE_USB_START);
USBDeviceInit();
//deug
// USBDeviceAttach();
while(1)
{
SYSTEM_Tasks();
・・・
void USBDeviceAttach(void)
{
・・中略・・
//debug
while(!U1CONbits.USBEN){U1CONbits.USBEN = 1;}
クロック設定
USBのD-、D＋端子もプルアップされるはずなのに、0.5Vぐらいの電圧が出て（多分浮遊電圧か）いているという状況です。
(Microchip DataSheet DS39931Dより）
で、その通り設定してみたら、ちゃんとD-,D＋端子もプルアップされるし、USBENは１になって、PCに刺すとちゃんと認識してくれました。まずは、第一段階クリアです。今後の計画
