もくじ
ツッコミ
else ifをたくさんつけたり、ifの条件をいろいろORしたりすると、場合によって、リンク時あたりに、よくわからんエラーが出る(再現性あり)。Tempにあるtempなファイルの中にあるエラー、と表示されるだけで、そのtempなファイルがみあたらないので、原因がわからない。
elseやORなどを減らすと、問題なくコンパイルがとおる。
なんじゃこりゃ?
割り込み処理中に、(念のためDisableIntしたうえで)もう1バイト受信すると、また割り込みフラグがたってしまうようだ。そのため、割り込み処理が終わると、また割り込みがかかってしまう。
レジスタレベルでこのフラグをクリア(DCB??を指定しないといけないので、Place依存なのでまりやりたくない)するか、割り込み処理中には1バイトしか受信しない(本来はこうするべき)ようにプログラムを書く、というところか。
1バイト単位での受信割り込みに、いまいち恐怖心というか避けたい気分があったのだけど、冷静に考えてみれば、あまりややこしい話ではないようだ。
http://web.sfc.keio.ac.jp/~shokai/archives/2008/03/psoc-cy8c2946-uart-recv-int.html
http://projectmcx.cocolog-nifty.com/blog/2007/01/psoc_f00e.html
要は、本来の受信割り込みは1バイト受信した時点で起こるが、標準で生成されるCmdBuffer関係の処理がUART_int.asmに書かれているので、その前に、自分の割り込み処理ルーチンへljmpさせてしまえばOK、ということになる。
なるほど。
sleepに入ると、pull-upはoffになる(=電圧が0Vになる)ようだ。つまりpull-upの上の電源がoffになる、ということか。
PSoCの外部IO割り込みのenableは、PRTxIEの当該ビットを1にして、かつ、PRTxIC1/0の当該ビットで00(disable)/01(立ち下がり)/10(立ち上がり)/11(両エッジ)を設定する。PRTxIEの設定を忘れがちなので注意。
備忘録。アクリル板だと意外と簡単に開く。
http://homepage3.nifty.com/yamaca/jisaku2/tap.htm
下穴は、仕上がり穴径-1mm程度、か。最初にボール盤を使って垂直にタップをあてるのがポイント。
オーディオ用語。シャーという音。高周波成分なので、LPFである程度カットできる。メインアンプ前が効果的。
http://www.computar.jp/modules/computar/index.php?page=cat&id=23
このあたりのボードレンズのマウントを自作してみようと考える。
マウントはM13P1.0、つまりネジ径13mmでネジのピッチが1.0mm。けっこう特殊なサイズのようだ。
汎用品でのナットはなかなかみつからず、
http://store.shopping.yahoo.co.jp/kokua/yamawatnp13100b.html
このあたりのタップを使ってみようと考える。
タップの「先」「中」「上」というのは、用途に応じた先端の形状らしい。
http://www.recoilj.com/recoil-tap.html
いろいろ関連技術がまとまっているので備忘録。いろいろある。
http://www.tsukuba-tech.ac.jp/info/kenkyu/kaken/disp2.html
作ってみた。コネクタ部分は、↓と同じ回路。とりあえずテスト的な測定ならば十分そう。
同期式シリアル通信であるSPI送受信回路を、HDLで書いてみるが、Behaviorシミュレーションでは動くのに、実機だとどうも挙動があやしい。
always @(negedge CK or posedge RST) begin ... case (rcnt) 8 : DBi[9] <= MISO; 9 : DBi[8] <= MISO; ...
こんな感じで、何ビット目かのカウンタ(rcnt)の値に応じて、結果レジスタの各ビットに受信データを書き込んでいるわけだが、書いているが、SPIの仕様上、送信と受信はCKのエッジが逆なので、送信側と受信側で、posedgeとnegedgeを使い分ける(か、2倍の周波数のクロックを使う)しかないわけだが、どうもこいつがマズいっぽい。論理合成後のRTLレベル回路図を見ると、各ビットのフリップフロップの前の組み合わせ論理回路がえらいことになっている(そりゃそうだ)。
そこで、同じようなものだが、1ビットずつシフトするように書き直してみた。
always @(negedge CK or posedge RST) begin ... else begin DBi[9:0] <= {DBi[8:0], MISO}; end
クロックの逆エッジを使っているのは同じなので、ダメかなあ、と思ったら、意外とあっさり動くようだ。
しかしこういう両エッジを使わざるを得ない回路の場合は、どうやって書くのがスマートというか流儀なんだろうか。やっぱ2倍クロックで立ち上がりのみ、なのかなあ。
簡易測定用に、先端がつまみやすい形状のプローブっぽいものを作ってみようかと思い立った。プローブ校正用のトリマ付近の等価回路
http://techon.nikkeibp.co.jp/article/NEWS/20070905/138795/
忘れないうちにまとめてみた。
http://akita11.jp/plan/pcbeguide/
けっこう難しい。近いうちに、いろいろまとめる予定。
前々から微妙に気になっていた、VLSI Solutions(http://www.vlsi.fi/)のMP3デコーダVS1011eを試してみる。
秋月でも売っている。http://akizukidenshi.com/catalog/g/gI-01484/
本来は、MP3形式(など)のバイナリデータをSCI経由で流し込むと、デコードして再生してくれる、というものなのだが、ファームウエアを持たせることができて、SDカードをつないでそこの中のMP3ファイルを再生する、みたいな機能もできる。
アプリケーションノートにある、Standalone Playerをみてみると、こういうプログラムを起動時にSCI経由で流し込めばOK、というのが載っているので、そのまま使ってみる。ファームウエアといっても5KB程度なので、制御用のマイコンのプログラム自体に入れてしまうこともできる。
で、ちょっと苦労しながら試してみた備忘録。(少し参考:http://www.picfun.com/PIC24F/AP/app24F08.html)
しかし、どうもこいつのデータシートは、性にあわないのか、非常に理解しにくかった。レジスタ名とフラグ名が、似ていてまぎらわしい、のが理由なんだろうか。
備忘録。VDDを分圧してVrefとして与えるものしかない。
つまり電源電圧が変動すると、Vrefも、それに比例して変動するということ。
電池駆動しての絶対電圧の比較には向かない。3端子regなどで電源を安定化するか、ADCを使うか。
PSoC Designer5.0で、WorkspaceとProjectの関係が、ごちゃごちゃしてきたので、備忘録。
http://doggie.blog.so-net.ne.jp/2007-03-17
JP1のジャンパーピンを下側へ移動させるだけ。
PSoCのI/Oピンの駆動モードを例えばPull-downにすると、PRTxDRで、そのピンのビットを0にしないと、Pull-downは有効にならない。
で、そのピンでSWなんかをつないでRising-Edge割り込みをかけたいとすると、そのピンが1になったときに割り込みがかかるわけだが、それにあわせてPRTxDRのビットが1になる。これを、再び0にしないとPull-downが有効にならないわけだが、その割り込み処理ルーチン内でPRTxDRのビットを0にしても、SWを押している間は、そのピンが1なので、PRTxDRのビットも、0にできない。つまりSWを離したあと、改めてPRTxDRのビットを0にしないといけない。(ただし当然ながら、そのSWを離したことは、PRTxDRのビットを0にできないので、Falling-edge割り込みでは検出できない)
PRTxDRのビットを適宜0にする方法は、例えばmainルーチン内のwhileループ内で常時やタイマ割り込みで定期的にPRTxDRのビットを0にする、といったところ。
http://www.aki-den.jp/kit_manual/start.html
マトリクスLEDを、センサとして使う、という話。元ネタはいろいろあって、例えばhttp://elm-chan.org/junk/leddet/report.html など。
(以下、行:アノード側、列:カソード側と定義)
以下の手順。
ふと思い立って、リセット動作を、行・列ともに"0"にしてみて、蓄積中の当該列を"0"にしてみる。
蓄積にしたがって電位は上がっていくが、どうもこのほうが動作の安定度がよいようだ。
うまくやると、CもRもつけなくても大丈夫。
レーザーポインタぐらいの明るさだったら問題ないようだ。ペンライトぐらいの明かりで、どれぐらい動作するかは要チェック。
ややノイズにシビアな信号を扱う回路で、アナログと高速で動くディジタル(FPGA)が混載している回路のノイズを退治する。
いろいろトライして、結果として最も効果があったのが、アナログ回路(アンプ)に対するパスコン(0.1uF程度)。最初は、ディジタル回路の方にパスコンをつけて、そこが発する電源系に乗るノイズを退治しようとしていたが、なかなかうまくいかない。そこで、そこから出るのはしょうがない、と割り切ったら、それなりに効果があった。
たとえばFDKのCR2032で、220mAh@2.0V程度らしい。思ったより大きい。
http://www.fdk.co.jp/battery/lithium/cs03.html
↓の結果。併用すると、かなりよくなった。
最後は、ADCに入ってくる信号にのるクロック由来のノイズ。
こればっかりは、アナログ系のPCB配線をしっかりやるしかない。
CPLD(XC2C256)で、シリアルのADCをつついてみるが、どうも誤作動する。
具体的には、CPLDから与えているクロックの立下りでADCから出てくるデータが変化するはずなのだが、毎立下り以外でもデータが変化しているっぽい。オーバーシュートか。
ADCの入力ピンの規格だと、Lは0.8V以下、Hは2V以上となっているが、確かに0.8Vに近いオーバーシュートが出ている。
考えられる対策:
ついでに、コンデンサマイクで拾った音をライン出力まで持っていく増幅回路の備忘録。
http://cba.sakura.ne.jp/sub04/jisaku19.htm
PCで、ちょろっと音を取り込んで、ちょろっと加工して出力したくて、調べてみると、Pdというやつがある。
http://d.hatena.ne.jp/octech/searchdiary?word=*[PD]
ただ、マイクは、どうもモノラルしかできないようだ。
http://blog.atamanikita.com/?eid=817204
ちょっと気が向いて、DirectSoundのプログラムを書いてみたいと思ってみる。ちょっと調べた範囲の備忘録。
http://quickprogram.blogspot.com/2008/07/managed-directx.html
http://www.tnksoft.com/reading/classgame/engine/03/030.php
http://hikari-hinomoto.hp.infoseek.co.jp/
http://www.clks.jp/csg/dx001.html (環境構築とか)
http://www.geocities.jp/chako_ratta/micon/psoc_rectifier.html
久しぶりにDCモータの定速回転を半日で仕上げる。エンコーダの出力のカウントがキモなわけだが、けっこう周波数が低いので、パルスがHになる時間をカウントすることにする。PSoCでやる方策をいろいろ考えてみたが、Counterで基準クロックをカウントさせ、そのEnableにエンコーダのパルスをあたえ、そのエンコーダの立下りで割り込みをかけてCounterの値の差分をとる(Counterの値をリセットする、という方法がわからない)、というのが、現実的のような気がする。
↓と書いたものの、動作が微妙にあやしいので、Post-fit Simulationをやってみると、予想以上にSetup-timeが短い。こりゃ動作が微妙なはずだ。
というわけで、全体を同期のステートマシンになるようにVerilogの記述をなおしてみるが、根本的には解決できず。
冷静に考えたら、クロック周波数が48MHzなのに、tpdが10nsのCPLDを使っているのが、そもそも無茶なようだ。もう少しtpdが短いCPLDを使ってみることにする。
比較的高速に動く回路をXilinxのCPLDに焼いてみるが、微妙に動かないところがある。
具体的には、ビット列のうち、特定のビットだけ、値が1に張り付く。
どうも遅延っぽいなあ、と思って、fittingのpropertyにあるOptimizatingをSpeed優先にしてみたら(デフォルトはSize優先)、あっさり動いた。
千石(http://www.sengoku.co.jp)で売っていて、よく使うんだけど、型番不明で、千石以外では入手ができなかったコネクタのメーカと型番を、やっと見つけた。
https://www.linkman.jp/user/shohin.php?p=57596
リンクマンという会社のZL2543シリーズ。
昔作ったやつを久しぶりに動かそうとしたら、どうもうまく動かない。
原因を探っていったら、基板の裏に通っているビニール線が、挿入実装部品の足のでっぱりに刺さっていて、運悪くショートしてしまっていたようだ。
USBでデータをもらいながらグラフを描画していると、どうも時々、エラーになる。
デバッガで原因をさぐってみると、どうもBeginTransferに失敗することがあるようだ。
原因をいろいろ考えてみたが、グラフの描画(とその準備の処理)に時間がかかる(ことがある)のが原因のような気がする。
グラフの描画の頻度を下げるしかなさそうだ。
PSoCのI2CHWのデータシートに載っているsampleに、どうもバグがあるような気がする。
WriteやReadの終了判定を
while(!I2C_RTC_bReadI2CStatus() & I2CHW_WR_COMPLETE);
とやっているのだが、&より!が優先されるので、
while(!(I2C_RTC_bReadI2CStatus() & I2CHW_WR_COMPLETE));
じゃないとマズい。
ちょっと多めのビニール線を半田付けしないといけないことがあり、買ったけどつかっていなかった半田槽を使ってみる。
棒はんだ(やになし、Sn60%)を細かく切って槽にいれ、設定温度を400℃ぐらいにして溶かす。その後、ビニール線を突っ込んで、少し待つと、だいたいきれいにできるようだ。
一度冷ますと、半田の表面に酸化膜っぽいのができるが、内側は大丈夫なので、再度溶かせば、また使える。
結局、送信が終わったあと(=受け側がデータを受け終わったあと)、受け側の送信端子(=PSoC側の受信端子)がHighになるようなので、送信が終わるまでUART_bReadTxStatus()をみて送信が終わるまでまち、その後、(必要であれば、その受信端子が1になるのをポーリングで待ってから)受信を開始するようにすると、うまくいくようだ。
どうもPSoCに限らず、UARTの受信エラーと、その対策が、いまいちよくわからない。
例えば受信端子をずーっと0にしてしまうと、フレーミングエラーが出るわけだが、
そのエラーフラグをクリアすれば、次からはまた普通に受信ができそうなものなんだけど、どうもうまくいかない。もっとシビアにタイミングを見てあげないといけないのかなあ。具体的には、受信端子のサンプリングのタイミングと、データ受信完了のタイミング。
5Vで動作するようにconfigしてあるPSoCを一度書き込んでしまうと、3.3V用に改造したMiniProgでは書き込みができないようだ。
ときどきコンパイル時に謎のエラーがでる。
HITECH-Cのフォーラムで質問してみたら、どうもServicePack2で
修正される問題、らしい。
Xilinx ISEで、Runをすると、その段階だけ実行される(ことがある)。例えばGenerate Programming FileのところをRunすると、SynthesisやImplementationは実行されない(ことがある)。Rerun allだと、最初から全実行。
作ったはずの回路ができず、これで1時間ほどつぶしてしまった。
教訓:コンパイルの過程に注目しよう。
ためしにPWM16をStartしなくしても、パルスが出てくる。
そんなはずはない。
もしかして、と思って、プロジェクト内のmain.cを見たら、ずいぶん前のプログラムだった。ということは、どこかで違うmain.cをひらいて、そいつを編集していたわけだorz
すごく簡単なプログラムを作ってみるが、どうもうまく動かない。
PWM16で、PWM16_WritePeriod()とPWM16_WritePulseWidthを設定してパルスの周波数を変えたいのに、InterconnectViewで設定している値から変更がきかない。なんじゃ?
ちなみにPWM16などのクロック信号は、電源3.3Vでは、グローバルバスに引き出せるのは12MHzまでらしい。見落としていた。
いろいろ検索して、2chに行き当たる。
結論として、(Tutorialにも書いてある)いままでのImagecraftコンパイラの書き方でも、Warningは出るが、使える、ということらしい。(本当は割り込みベクタのアドレスを記述するのがHITEC-C流らしいが、boot.asmをみないとブロックごとの割り込みベクタがわからないので、面倒といえば面倒)
実際使えたので、Warningは気にせずにこのまいくことにする。
新しいマシンに、PSoC Designer5.0をインストールしてみる。HITECH-C Liteを選んでいるんだが、
!E C:(Path名)\tools\InvalidCompilerLicense.txt(0): ...Operation terminated. Compiler License invalid or not accessible
と出てしまい、コンパイルができない。なんでだろう?
Googleで検索した範囲では、古いコンパイラの情報が残っている場合などに出ることがあるようだが、今回は更に入れたマシンなので、そんなことはないはず。
ためしに、45日評価版のライセンスに切り替ええても、やはり同様のエラー。
困った。
三端子レギュレータの出力電圧が、予定より0.5Vほど高くなる現象に遭遇。負荷はFPGAのI/O電源。
もしかして、と思ってデータシートを読み直してみると、出力電圧の項が、負荷電流が5mA以上、という条件で書いてある。
というわけで、適当な抵抗を負荷につないでみたら、無事本来の出力電圧になった。
スイッチングレギュレータで負荷の下限があるのは知っていたが、三端子のようなシリーズレギュレータでもあるんだね。
ふと思うところがあり、ちっこいWebサーバを攻めてみる。
http://www.olimex.com/dev/pic-mini-web.html
ここのTCPスタック(バージョンは最新ではない)を書き込んでみるが、どうもうまくいかない。1回だけうまくいったんだけど、それ以外は反応がない。リバースケーブルでつないでも、HUB経由でもだめ。IPパケットをのぞいてみると、どうもARPに反応していないっぽい。なんでだろう。まさかARPってICMP_SERVERをイネーブルにしないと反応しないんだろうか?そんなわけないよなあ。
BluetoothモジュールについているSMAコネクタを交換するため、コネクタをとりはずす。
思いのほかコネクタの熱容量が大きいのか、熱風ブロアではビクともしない。
そこで、サンハヤトのSMD取り外し半田を使ってみる。
http://www.sunhayato.co.jp/products/details.php?u=797&id=02043
→あっさりとれた。すげー。脱帽。
北川先生より情報。
http://zedgraph.org/wiki/index.php?title=Main_Page
PSoC Designer5.0を入れてみる。統合環境としては、なかなか使いやすいような気はする。
カメレオンUSB FX2
http://optimize.ath.cx/cusb_fx2/index.html
USB2.0経由で、高速にデータを送り続けるような用途に吉。
いろいろと備忘録。
PSoC Designer 5.0を入れてみる。Cコンパイラが、HI-TECH Cになっている。
機能制限版は無料、フル版は有償(アカデミックで$650程度のようだ)、とのことで、とりあえず無料版でいってみる。
http://ameblo.jp/2st-rider/entry-10091603285.html
ここによると、いままで使っていたImagecraftのCコンパイラより、この無償版の方がいいこともあるようだ。むーん。
アカデミック版を買うかなあ・・・マルチユーザライセンスだし。
JST(日本圧着端子製造)のコネクタ(ACHシリーズ)のコンタクトピンにケーブルを圧着しようとする。
http://www.jst-mfg.com/product/detail.php?series=9
が、あまりにも小さいので、断念して半田付け。JSTに問い合わせてみると、専用の手動圧着工具がある。10万円ぐらいするが、これは専用工具を使わないと無理だ・・・
ちなみに、昔買っていた、同じくJSTのSSRシリーズのコネクタは、ピンにワイヤを押し込んで固定する圧接、という方法で固定するが、こちらも、同じくJSTの専用工具があるようだ。しかし15万円ぐらいする。まあこちらは、それほどまではよく使うわけじゃないので、精密ドライバで押し込むか・・・
アナログブロックを全く使わないとき、GlobalResourceからAnalog PowerをOffにすると、2mAぐらい消費電流が減るようだ(CY8C29466の場合)
ちょっと手が空いたときに、実験や測定するときの、ちょっとした環境整備。
DC電源を何系統か使うとき、どの線がどの電源につながっているかわからなくなっちゃうことがあるので、色をつけてみる。あと、平行コードで線がバラけないように。
オシロのプローブで基板上のICの信号などを見ているとき、プローブだとつまみにくいところをつまみやすいようにクリップ(Sunhayatoの、本当は0.5mmピッチQFPの足もつまめるシロモノらしい)。やはり同じように色分け。あと反対側は、プローブでつまむように皮をむいただけだけど、もちろん半田メッキ。
いろんなリモコンの信号をみてみる。
リモコンの赤外線を受信したくなって、久しぶりにちゃんと使ってみる。
備忘録。ユニクロメッキのナットを基板に半田付けしたい場合(ってかなりレアだな・・・)に、けっこううまくいく方法を発見。
備忘録。PSoC Programmerの2種類の書き込み方法
しばらくまえにいじろうと思って、なかなかうまくいかなかったので、しばらく放置プレイぎみだった、Cypressの2.4GHz帯無線機つきPSoCの、PRoC (CYWUSB6953)
http://www.cypress.com/products/?fid=65&rpn=CYWUSB6953&ref=sch
久しぶりにひっぱりだす。いろいろリハビリ。
多点CSD(具体的にはとりあえず12点)で、ちょっと電極までの距離が長いやつのタッチ検出。デフォルトのパラメータだと、感度がいまいち(というか誤検出が多い)ので、CSDのDocumentの最後の方に載っているチューニングの方法に従って、チューニングしてみる。
ちなみにCSDモジュールのReferenceは、ASE11がおすすめ、と書いてあった。ScanSpeedはNormal, Resolutionは12bitに設定。
チューニングの手順の要点は以下の通り。
結果は以下の通り。
(12個のスイッチのうち、SW0, SW5, SW11の3個のみ記録。値はけっこうバタつくので、俺フィルタを通したあとの平均値。タッチの強さによっても値が変わるが、弱めにタッチ(ワーストケースに近い)にしてみる。
OFF | On | Diff | ||||||||
Rb | Cmod | SW0 | SW5 | SW11 | SW0 | SW5 | SW11 | SW0 | SW5 | SW11 |
2.2k | 10n | 650 | 950 | 1100 | 1800 | 2050 | 2500 | 1150 | 1100 | 1400 |
2.2k | 4.7n | 650 | 970 | 1100 | 1800 | 2000 | 2600 | 1150 | 1030 | 1500 |
2.2k | 39n | 660 | 970 | 1100 | 2100 | 2200 | 2700 | 1440 | 1230 | 1600 |
2.2k | 47n | 660 | 970 | 1100 | 2000 | 2100 | 2500 | 1340 | 1130 | 1400 |
4.7k | 10n | 1300 | 1900 | 2200 | 3900 | 3800 | 4000 | 2600 | 1900 | 1800 |
10k | 10n | 2400 | 3300 | 3700 | 4096 | 4096 | 4096 | 1696 | 796 | 396 |
4.7k | 39n | 1300 | 1900 | 2200 | 3500 | 3800 | 4000 | 2200 | 1900 | 1800 |
4.7k | 4.7n | 1300 | 1900 | 2200 | 3800 | 3900 | 4000 | 2500 | 2000 | 1800 |
3.3k | 10n | 930 | 1360 | 1600 | 3000 | 3500 | 3600 | 2070 | 2140 | 2000 |
3.3k | 39n | 960 | 1390 | 1620 | 2700 | 2800 | 3500 | 1740 | 1410 | 1880 |
3.3k | 4.7n | 920 | 1360 | 1600 | 3400 | 3000 | 3700 | 2480 | 1640 | 2100 |
この結果から、微妙なラインではあるが、Rb=3.3kΩ, Cmd=10nFを採用。
本来は、このカウント値とBaselineとの差がFingerThreshold以上になったら、ON、になるはずなのだが、FingerThresholdの値が5〜255しか設定できない。これはResolutionが8bitのとき用で、12bitのときとかは、換算しないといけないんだろうか。
そのあたりをさぐるのが面倒なので、カウント値-baselineであるCSD_waSnsDiff[]を順番にみて、その値が閾値以上(例えば700)であればON、と判定するようにした。
ちなみにCSDは、勝手にVC1〜VC3のクロック源・分周比を設定してしまうので、TX8などのクロック源を自分で分周したVC3にできないので、SysClk*2で、PC側のUARTのボーレートをそれにあわせるか、CSDでセンスしたあとに、レジスタを直接いじってVC3のクロック源・分周比を設定(OSC_CR3/OSC_CR4)などしてTX8_Start()して、TX8でデータを送る。送り終わったら、TX8_Stop()して、レジスタを戻しておくのを忘れずに。(ただしTX8_PutCharの関数から戻るのは、送信開始時なので、送信が終わるまで待ってからTX8_Stop()しないと、途中で送信が止まってしまう)
電極までちょっと長め(最大で1m弱)の線で引っ張るタッチセンサをCSDでつくってみる。
電極までの線を、電極につながる線とGNDが交互になっているフラットケーブルにしてみて、どれぐらいイケるか挑戦してみた。(未来日記)
場合によっては、ShieldElectrodeを使うようにして、このフラットケーブル内のGNDをShieldElectrode端子につないだほうがいいのかもしれないが、それは結果をみてから、にする。