#contents(); *2009年10月27日(火) [#uc493b29] **PSoC DAC使用時の注意 [#r8630f5b] ***Analog Column Clock [#y1a4ddec] Analog Column Clock((アナログブロックの左側にあるClockセレクタ、デフォルトはVC1))を使用するので、VC1の周波数をDACの動作周波数以下に分周しておく必要があるらしい。今回はVC1を8分周(3MHz)とした。 http://www.pastelmagic.com/psocbbs/index.cgi?m=look&bnum=930 ***IO設定 [#a9a32cb5] アナログ出力時は"High Z Analog"としなければならない。 *2009年10月23日(金) [#r3f62858] **報告 [#e765fe0f] ***SRAMについて [#add92fa2] プリチャージする必要がある。とくにWLの負荷容量が大きいと、その影響で読み出せず、SRAMの電圧が書き換わってしまう。 そのため、本来はVDD/2にプリチャージしておく。 ***コンパレータについて [#ade95d2e] ばらつきに弱い原因のひとつとして、面積が小さいことが挙げられる。 構成そのものを見直すか、あるいは面積をかえて詳細なシミュレーションをするか。 ***IPプロジェクトについて [#nd3ec332] もし面積が余っているようなら、そこに載せてもらうことはできないか? あるいはIPとして登録することを条件に設計するか? *2009年10月22日(木) [#mbf6bd2d] **Comparatorシミュレーション [#r984f298] ***実はかなりばらつきに弱い。。 [#jb26a2cc] どうやらばらつきに対してかなり弱い回路構成だったことが判明。 なんで作っている最中に気がつかなかったのだろうか。。 **SRAMシミュレーション [#odc2479e] ***PAD、DUTボードの寄生容量の影響大 [#f5e32d7a] 出力部分にバッファを入れるべきだったorz *2009年10月21日(水) [#c623cdf9] **Comparator測定 [#gd318617] ***なぜか出力電圧が3.3V。どう考えてもおかしい。。 [#c16cda55] 電位差も0.5Vくらいの差がないと動作しない。オワットルな。 どうやら、DIGITAL用IOバッファは3.3V出力をするらしい。あめちゃんの回路も同様だった。 回路が悪いのかIOが悪いのか分からない。IOを想定して回路シミュレーションをしてみる必要があるかも。 *2009年10月20日(火) [#r8f293f5] 6月22日設計のチップ動作検証をPSoCでやる。 **Comparator動作確認 [#uedcf36a] 正しく動作していることは確認できた。 次は、どれくらいの速度が出るかを知りたい。どうしよう? **PSoCのDAC6が動作せず [#h523a7da] 正しいと思い込んでいる設定が、実は違うのかもしれない。確認する必要あり。 **SRAM動作せず [#nb5cd985] 理由はこれまた不明。検証不足。 ***検証1:PSoCプルダウンとつながっているため? [#i2140e8a] ちゃんとジャンパピンを外してあるため、開放状態である。関係なし。 ***検証2:WL1を正しくONしていないのでは? [#vc4eb126] できている。 ***試しに"1"だけ書き込んでみるとどうなるか? [#a77911aa] そもそも"1"を書き込めない。BL2とBL2_Nは同じような波形で、10mV程度。 ***速度が速すぎるのではないか? [#d6e9057a] 1KHzでも動作していない。。 **割り込み処理 [#w876c6bf] アナログ入出力のあるピンの割り込み制御がうまくいかない。たとえばP0[1] 理由はよく分からないので、とりあえず別のピンに置き換えて使用することにした。 **PSoC タイマー割り込み + switch文 [#m3726fd8] switch(mode){ case 0: PRT0DR = PRT0DR & 0x7F; // BL1 = 1 PRT0DR = PRT0DR | 0x02; // BL1_N = 0 break; case 1: PRT0DR = PRT0DR | 0x80; // BL1 = 0 PRT0DR = PRT0DR & 0xFE; // BL1_N = 1 break; case 2: PRT0DR = PRT0DR & 0x7F; // BL1 = 1 PRT0DR = PRT0DR | 0x02; // BL1_N = 0 break; case 3: PRT0DR = PRT0DR | 0x80; // BL1 = 0 PRT0DR = PRT0DR & 0xFE; // BL1_N = 1 break; case 4: PRT0DR = PRT0DR & 0x7F; // BL1 = 1 PRT0DR = PRT0DR | 0x02; // BL1_N = 0 break; default: PRT0DR = PRT0DR | 0x80; // BL1 = 0 PRT0DR = PRT0DR & 0xFE; // BL1_N = 1 break; } // RW control mode++; if(mode>5)mode=0; このような記述だと、mode=0〜5で6回実行されるらしい。なんでだろう。 *2009年5月1日(金) [#de86a805] **ADCのタイミング3 [#z671fc75] タイミング良くADCからの情報を得られない原因が分かりました。 PSoCのADCは、指定されたサンプルレートでデータをPSoCの変数に格納します。 DELSIG11の場合は7.8Kspsなので、およそ0.13msごとにADCが完了します。 したがって、PSoCのプログラム内からは、すでにADCが完了し、変数に格納されている値を呼び出すことしか出来ないです。 #ref(../upload/2009-05-02-graph.png,,,50%) ▲ リセット信号、フォトダイオード、ADCのタイミング イメージセンサの行リセット信号がOFFになってから、フォトダイオードからの出力電圧が0Vまで落ちるのは、室内蛍光灯の明るさでおよそ500μsなので、これが落ちきる前にすべての行のデータをADCするのは、さすがに不可能です。 *2009年2月12日(木) [#q454dab1] **ADCのタイミング2 [#y502e5cf] より高速に動作するADCとして、「DELSIG11」を使ってみました。最高で7.8Kspsであり、およそ100μsの間隔でADCを実行できるので、うまいことタイミングを合わせれば、イメージセンサの出力を意図したタイミングで変換できると思います。 そこで、緑色の信号線が立ち上がった瞬間にADCの結果を読み出す、というようにプログラムを書きましたが、どうも正しい結果が出力されません。 #ref(../upload/delsig.JPG,,,70%) ▲図の青色の信号線が0のときにリセットがかかっています。なぜかリセット時の電圧(1.2〜1.3V)をA/D変換した結果が出力されてしまいます。 そして、変換された結果がかなりばらついています。なんでだろう? こんな感じのプログラムです。P1[1]が、図の緑色の信号線です。これが"1"になったらADCの結果を取り出すようにしています。 while(1){ if((PRT1DR & 0x02) && n==0){ //PRT4DR & 0x10 //ADC while(!DELSIG11_1_fIsDataAvailable()); isensor = DELSIG11_1_iGetData(); if(isensor<0) isensor = -(isensor ^ 0xFFFF | 0x0001); //convert to voltage tmp=isensor; vol=( (tmp-1024)/1024 * 1.28 + 1.28*2 ) * 1000; //UART number to strings str = num2str(vol); uart_1_putchars(str); UART_1_CPutString("\r\n"); n=1; } else if((PRT1DR & 0x02)==0){ n=0; } } 直流電圧源を使用して変換したときは、正しい結果が安定して出力されていたので、ADCは正しく動作していると思われます。あとは、意図したタイミングでADCの結果を出力することさえ出来ればよいのですが。。 *2009年2月9日(月) [#vbb2c614] **ADCのタイミング [#f9484601] ちゃんとデータシートを確認してみると、ADCに与えるべきクロック周波数が間違っていることに気がつきました。そこだけ修正したらちゃんと動作してくれました。 使用していたADCモジュールは「ADCINC14」という、高精度だけど動作が最速でも120spsというものだったのですが、これだと意図したタイミングでデータをとることができませんでした。イメージセンサのフレームレートが10fps程度だったので、これくらいで充分かな?と、深く考えずに使用していましたが、そもそも数msで電圧降下してしまうため、120spsだと(1/120=8.3ms)で動作が間に合わないみたいです。 というわけで、もう少し速いモジュールを使ってみたいと思います。 *2009年2月6日(金) [#fd55f423] **UART通信成功 [#ze30c996] 2/4のときにはダメでしたが、改めて配線やプロパティ値を確認して見たところ、与えるべきクロックが間違っていました。やはり凡ミスでした。。そこを修正したらうまく動きました。 UARTのAPIに、数字を文字列として返す関数が無いので、自分で1桁ずつ文字に変換して、UART_1_PutCharを用いて出力することにしました。 **ADC [#c1a557fe] 今度はADCがうまく動いてくれません。もう少し詳しくデータシートを読むべきみたいです。。 *2009年2月4日(水) [#a290cf33] **128×128イメージセンサの測定 [#c688ada9] まずは(x,y)=(0,0)のイメージセンサを選択して、信号を出力できるかどうか試してみました。単体測定のときと同様の結果が得られました。 **URAT通信 [#a825388e] イメージセンサからのアナログ信号をA/D変換し、その値をUARTでPCに送信し、画像として表示できるようにしたいと考えています。 まずは(x,y)=(0,0)におけるイメージセンサの信号を変換して、正しくUARTでPCに出力できるかどうか試しています。 #ref(../upload/imagesensor00.JPG,,,70%) ▲(x,y)=(0,0)におけるイメージセンサの信号 #ref(../upload/imagesensor00r.JPG,,,70%) ▲(x,y)=(0,0)におけるイメージセンサの信号(拡大図) 図の緑色の信号は、リセット信号(青)と同じ周波数で、デューティ比の異なる信号で、この緑色の信号が立ち上がるタイミングにおいてアナログ信号をA/D変換するつもりです。 ですが、どういう訳かUARTがうまくいきません。。どこかに凡ミスがあると思うのですが、、、 #ref(../upload/ack001.png,,,60%) ▲常に"0x00"が表示され続ける状態 *2009年2月2日(月) [#vfcc828c] **イメージセンサ単体の測定2 [#se86d6c1] 確かに、たとえ明るいときであるとはいえ、非常に電圧降下が速いです。なのでもう少し拡大して見てみました。 #ref(../upload/bright_z.JPG,,,70%) ▲明るいとき(拡大図) 電圧は、わずか100μsで0Vに落ちてしまいます。ちなみにこれははんだ部屋の室内蛍光灯を点灯している際に測定したもので、卓上の蛍光灯スタンドを使うと、さらに速く電圧降下します *2009年1月31日(土) [#ofb3cedc] **イメージセンサ単体の測定 [#xf8b5815] イメージセンサ単体の測定を行ってみました。回路構成はこんな感じになっています。 #ref(../upload/imagesensor.png,,,50%) 結果はこのような感じです。バイアス電圧は1.35Vくらいです。 #ref(../upload/dark.JPG,,,70%) ▲暗いとき #ref(../upload/bright.JPG,,,70%) ▲明るいとき 明るいときの方が、イメージセンサに流れる電流が多く、したがって出力電圧が下がるのが速いことが確認できました。 *2009年1月19日(月) [#wa7e52d5] **スパム対策 [#w8f34283] [[質問箱]]にあるフィルタを適用してみましたが、ランダムな文字列のスパム書き込みが未だに消えません。というわけで、今度はUSER_AGENTで監視してみるしかないかも。。 PukiWiki Plus!用のスパムフィルタ spam_filter.php - モーグルとカバとパウダーの日記 http://d.hatena.ne.jp/stealthinu/20070516/p2 *2009年1月16日(金) [#a7075000] **Chip測定準備終わる [#ma9cd55e] ようやく終わりました。。はんだ付けに慣れていなかったため、えらく時間がかかってしまいました。これから、9月試作のChip測定に移りたいと思います。まずは、すでに動作確認がされている、富山商船高専の新田君が作ったNAND回路から行きます。 IP:133.28.96.26 TIME:"2010-04-21 (水) 15:22:39" REFERER:"http://merl.ec.t.kanazawa-u.ac.jp/micon-bu/index.php" USER_AGENT:"Mozilla/5.0 (Windows; U; Windows NT 5.1; ja; rv:1.9.2.3) Gecko/20100401 Firefox/3.6.3 (.NET CLR 3.5.30729)"