![[micon-bu]](image/miconbu_logo_03.gif "[micon-bu]"){kind=logo}
目次
最新の10件を表示しています。 コメントページを参照
Analog Column Clock*1を使用するので、VC1の周波数をDACの動作周波数以下に分周しておく必要があるらしい。今回はVC1を8分周(3MHz)とした。
http://www.pastelmagic.com/psocbbs/index.cgi?m=look&bnum=930
アナログ出力時は"High Z Analog"としなければならない。
プリチャージする必要がある。とくにWLの負荷容量が大きいと、その影響で読み出せず、SRAMの電圧が書き換わってしまう。
そのため、本来はVDD/2にプリチャージしておく。
ばらつきに弱い原因のひとつとして、面積が小さいことが挙げられる。
構成そのものを見直すか、あるいは面積をかえて詳細なシミュレーションをするか。
もし面積が余っているようなら、そこに載せてもらうことはできないか？
あるいはIPとして登録することを条件に設計するか？
どうやらばらつきに対してかなり弱い回路構成だったことが判明。
なんで作っている最中に気がつかなかったのだろうか。。
出力部分にバッファを入れるべきだったorz
電位差も0.5Vくらいの差がないと動作しない。オワットルな。
どうやら、DIGITAL用IOバッファは3.3V出力をするらしい。あめちゃんの回路も同様だった。
回路が悪いのかIOが悪いのか分からない。IOを想定して回路シミュレーションをしてみる必要があるかも。
6月22日設計のチップ動作検証をPSoCでやる。
正しく動作していることは確認できた。
次は、どれくらいの速度が出るかを知りたい。どうしよう？
正しいと思い込んでいる設定が、実は違うのかもしれない。確認する必要あり。
理由はこれまた不明。検証不足。
ちゃんとジャンパピンを外してあるため、開放状態である。関係なし。
できている。
そもそも"1"を書き込めない。BL2とBL2_Nは同じような波形で、10mV程度。
1KHzでも動作していない。。
アナログ入出力のあるピンの割り込み制御がうまくいかない。たとえばP0[1]
理由はよく分からないので、とりあえず別のピンに置き換えて使用することにした。
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回実行されるらしい。なんでだろう。
タイミング良くADCからの情報を得られない原因が分かりました。
PSoCのADCは、指定されたサンプルレートでデータをPSoCの変数に格納します。
DELSIG11の場合は7.8Kspsなので、およそ0.13msごとにADCが完了します。
したがって、PSoCのプログラム内からは、すでにADCが完了し、変数に格納されている値を呼び出すことしか出来ないです。
▲ リセット信号、フォトダイオード、ADCのタイミング
イメージセンサの行リセット信号がOFFになってから、フォトダイオードからの出力電圧が0Vまで落ちるのは、室内蛍光灯の明るさでおよそ500μsなので、これが落ちきる前にすべての行のデータをADCするのは、さすがに不可能です。
より高速に動作するADCとして、「DELSIG11」を使ってみました。最高で7.8Kspsであり、およそ100μsの間隔でADCを実行できるので、うまいことタイミングを合わせれば、イメージセンサの出力を意図したタイミングで変換できると思います。
そこで、緑色の信号線が立ち上がった瞬間にADCの結果を読み出す、というようにプログラムを書きましたが、どうも正しい結果が出力されません。
▲図の青色の信号線が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の結果を出力することさえ出来ればよいのですが。。
ちゃんとデータシートを確認してみると、ADCに与えるべきクロック周波数が間違っていることに気がつきました。そこだけ修正したらちゃんと動作してくれました。
使用していたADCモジュールは「ADCINC14」という、高精度だけど動作が最速でも120spsというものだったのですが、これだと意図したタイミングでデータをとることができませんでした。イメージセンサのフレームレートが10fps程度だったので、これくらいで充分かな？と、深く考えずに使用していましたが、そもそも数msで電圧降下してしまうため、120spsだと(1/120=8.3ms)で動作が間に合わないみたいです。
というわけで、もう少し速いモジュールを使ってみたいと思います。
2/4のときにはダメでしたが、改めて配線やプロパティ値を確認して見たところ、与えるべきクロックが間違っていました。やはり凡ミスでした。。そこを修正したらうまく動きました。
UARTのAPIに、数字を文字列として返す関数が無いので、自分で1桁ずつ文字に変換して、UART_1_PutCharを用いて出力することにしました。
今度はADCがうまく動いてくれません。もう少し詳しくデータシートを読むべきみたいです。。
まずは(x,y)=(0,0)のイメージセンサを選択して、信号を出力できるかどうか試してみました。単体測定のときと同様の結果が得られました。
イメージセンサからのアナログ信号をA/D変換し、その値をUARTでPCに送信し、画像として表示できるようにしたいと考えています。
まずは(x,y)=(0,0)におけるイメージセンサの信号を変換して、正しくUARTでPCに出力できるかどうか試しています。
▲(x,y)=(0,0)におけるイメージセンサの信号
▲(x,y)=(0,0)におけるイメージセンサの信号(拡大図)
図の緑色の信号は、リセット信号(青)と同じ周波数で、デューティ比の異なる信号で、この緑色の信号が立ち上がるタイミングにおいてアナログ信号をA/D変換するつもりです。
ですが、どういう訳かUARTがうまくいきません。。どこかに凡ミスがあると思うのですが、、、
▲常に"0x00"が表示され続ける状態
確かに、たとえ明るいときであるとはいえ、非常に電圧降下が速いです。なのでもう少し拡大して見てみました。
▲明るいとき(拡大図)
電圧は、わずか100μsで0Vに落ちてしまいます。ちなみにこれははんだ部屋の室内蛍光灯を点灯している際に測定したもので、卓上の蛍光灯スタンドを使うと、さらに速く電圧降下します
イメージセンサ単体の測定を行ってみました。回路構成はこんな感じになっています。
結果はこのような感じです。バイアス電圧は1.35Vくらいです。
▲暗いとき
▲明るいとき
明るいときの方が、イメージセンサに流れる電流が多く、したがって出力電圧が下がるのが速いことが確認できました。
質問箱にあるフィルタを適用してみましたが、ランダムな文字列のスパム書き込みが未だに消えません。というわけで、今度はUSER_AGENTで監視してみるしかないかも。。
PukiWiki Plus!用のスパムフィルタ spam_filter.php - モーグルとカバとパウダーの日記
http://d.hatena.ne.jp/stealthinu/20070516/p2
ようやく終わりました。。はんだ付けに慣れていなかったため、えらく時間がかかってしまいました。これから、9月試作のChip測定に移りたいと思います。まずは、すでに動作確認がされている、富山商船高専の新田君が作ったNAND回路から行きます。
過去の日記をアーカイブしたときに、ファイルのリンク切れを防ぐために、添付ファイル置き場を作成しました。あとコメント欄も#pcommentで別ページにして統一しました。以前より使いやすくなったかな。。
PSoC周辺のはんだ付けが終わったので、DUTソケットをつける前にPSoCの動作確認をしたいと思います。
どんなプログラムで確認しようか。。
いよいよはんだ付けを始めたいと思います。QFPパッケージのはんだ付けは、やはり難しいです。。くっついているように見えてくっついていなかったり、隣どうしのピンが導通してしまったりorz
結局ほとんど秋田先生にやってもらっちゃいました(；'∀`)
ようやく完成しました！
基板製作会社から手直しの依頼がこなければ完成です。
基板をつくるために、注意しなければいけないことがけっこうあるので、まとめていきたいと思っています。。
昨日、ついにPSoCが届きました！
紙に印刷した、原寸大のPCBデータの上にPSoCをおいて、実際にはんだ付けできそうかを確認してみたところ、ランドが狭すぎてはんだ付けできそうにないので、もう少し広げた方がいい、というアドバイスを秋田先生にいただきました。
手直しして1mm程度のばそうとしましたが、これが意外と大変な作業でしたorz
▲PSoCのQFPパッケージによって、ランドが隠れてしまい、はんだ付けが難しい状態
すでに場所を決めてしまったパッドを動かそうとすると、ランドとくっついてしまったりします。。
また、なぜか部品として呼び出したPSoCのフットプリントのグリッドがうまくあわず、ひとつひとつのパターンを座標を指定しながら移動しないといけなくなり、かなり面倒な作業に…。
QFPパッケージの部品のフットプリントを作る際は、ちゃんと確認しないとえらいことになりますorz
PSoC周辺の配線を描いている最中なのですが、CY8C29866-24AXIはTQFPパッケージで、しかも配線間隔が0.5mmという設定なので、いちいちグリッドを2.54mmと切り替えなくてはいけないので、面倒くさいですorz
しかもピンが64ピンもあるので、これが案外やっかいです。うっかり配線をぎりぎりに配置してしまったので、ビアホールが置けなくなってしまったorz
▲完全にやり直しだorz
先にTQFPまわりの配線をすべてやるべきだったようです。。
下準備するだけでずいぶんと時間がかかってしまいましたorz
下準備というのは
などです。
さっそくPCBEを使って描くことにします。
秋田先生、北川先生のマニュアルページがすごく参考になりました。
どうしても、PCBEとVirtuosoの操作を混同してしまいます。。
Chip測定環境としてPSoC CY8C29866-24AXIを使うことになりました。PSoCのくせに100ピン(そのうち、I/Oピンは64個)もあります！！
しかし、性能はCY8C29466と同じようだ。ただピン数が増えただけかorz
あと、全体的にはInkscapeを使って編集しときました。
▲svg形式のファイル
▲svg形式(フォントをパスに変換したもの)のファイル*3
あと、faviconも作っちゃいましたorz
▲favicon用のPNGファイル
これをIrfanViewを使って縮小して、.icoで保存しました。
logo_miconb.svg
logo_miconb_path.svg