« 2010年9月 | トップページ | 2010年11月 »

2010年10月の2件の記事

2010年10月19日 (火)

フォトフレーム:最後まで難航したが遂に成功

 久しぶりに晴れ晴れとした気分でブログを書いている。そう、悪戦苦闘していたLattice XP2基板のFPGAデジタルフォトフレームが、やっとのことで想定どおりの640×480ドット12ビットカラーの画像をBMPファイルから描画するようになったのだ。

 フォトフレーム計画(プロジェクト)を立ち上げて、ほぼ7ヶ月。今年のがた老AVR研究所はほとんどの時間をこれにあてていた。毎日のように一喜一憂していたが、遂に第7ステップのBMPファイルの描画に成功した。当面のゴールである。嬉しいというより背負っていた重い荷をおろしたときのような解放感が強い。

 綺麗な画がでるまでは、本当に暗かった。何度もプロジェクトを投げ出しそうになった。その度に気持ちを奮い立たせて元へ戻った。たかが趣味で何でこんな苦しい思いをするのか時々馬鹿馬鹿しくなるが、うまく行ったときの快感が忘れられない。前にも書いたが、相当中毒が進んでいる。

 思い通りにならない時は、世の中すべてが自分に反対しているように見え、今までの生き方そのものが否定されているような暗澹たる気分になるのだが、一旦解決したとなるともう有頂天、まるで天下をとったような気分になる。これだから電子工作はやめられない。

ピクセルのずれが直らない(10/10/2010)
 前記事にあるとおり、XP2のフォトフレーム基板に何とか画像らしいものが出て、あとはもう一息、微調整で上手く行くという考えは甘かった。どうやっても、まともな画像になってくれないのである。

 左右の逆表示は、液晶モニターのスキャン方向ビットの調整(この液晶のデータシートの垂直方向指示ビットは間違っている。0->上から 1->下からが正しい)で直ったが、ピクセルドットの食い違いによる不具合はどうやってもうまくいかない。

Aa123286

 12ビットカラーは6バイトで4ピクセルを表現するので、1ピクセルでもずれると、とんでもない色になってしまう。連続しているところはちゃんと12ビットをとりだしているのだが、1ライン(640ドット)描いた次のラインで、SRAM読み込みがスタートせず、1ドットずれてデータが入り、48ラインごとに元の状態に戻り、結果として縞模様の斜めにずれた画像になる。

 状況は、画面の状態から良く分かるのだが、これをどう解決するかの方策が見つからない。1ライン中の連続表示ではうまく行っているので、ラインのスタートのときにSRAMアクセスのトリガーをかけてやれば、良いように思えるのだが、どんなあわせ方をしても斜めの縞模様は解消できない。

 描画範囲と、画像の幅は1ピクセルでも違うと、大きく左右にずれる。しかしこの傾きは微妙だ。ドットで言えば、40ピクセルくらいしか傾いていない。縦の行は480行あるので、12行について1ドットの勘定だ。

 ピクセルドットの計算違いや、SRAMのアドレスインクリメントの狂いで、こんな微妙な違いは起こらないことに大分経ってから気づいた。FPGAの中のビットハンドリングがどこかで変調をきたしている。

 非同期アクセスか、ハザードの問題だろうか。ステートマシンのグレイコードをいじってみたり、非同期だったSPIのCS信号を同期させてみたり、SRAMアドレスハンドリングを調べてみたりするが、状況は全く変わらない。

 いくつかBMPファイルを入れてテストしてみるが、みな同じ現象。画像データそのものを疑ってペイントソフトが作ったファイルをバイナリエディターで確認するが問題なし。現象ははっきりしているが、原因がわからないので解決できない。

やっぱりバグは外にあった(10/13/2010)
 ひとつめの不具合、画像が斜めに傾く現象は、意外なところが犯人だった。最初、FPGAのビットハンドリングをしつこく調べていたが、どうしても不具合を発見できない。少し冷静になって「デバッグは外へ、外へ」の鉄則どおり、データを送り出すところから調べてみることにした。

 SPIからのデータは、BMPファイルのヘッダーを取り除いた色信号そのもののデータが果てしなく続くデータストリームである。ここで1バイトでもずれたら画像は間違いなく斜めになる。しかしコードはSDカードの読み込みブロックサイズを意識せず、ブロックをまたがってもちゃんとデコードできるようになっている。ずれるわけはない、うっ、待てよ。このブロックの終了条件、おかしくないかい。

 うはあ、大小比較は等しいときはFalseだ。これだ。1バイト、ブロックサイズを行き過ぎている。2KBごとに1バイト、1ライン960バイトなので3ラインごとに1ドット(12ビット)ずれる理屈だ。これだこれだ。あせる手でSTM32のコードをコンパイルしなおし、テストする。

Aa143291

 良いぞ、画像の傾きは直った。しかし、3原色の背景は少し色が出てきたが、まだ縞模様のままで本来の色ではない。次の不具合、色を正しくするトラブルシューティングだ。

「デバッグは外へ」にならって、送られてくるSPIの画像データをロジアナでさらにくわしく調べる。うーむ、でだしのところから既におかしいぞ。今のロジアナはプロトコルアナライザー機能がないので、8ビット波形を手でデコードしてみるが、明らかにBMPファイルの通りになっていない。

 どうも、8ビットデータの処理を間違えているのではないか。データのシフトがおかしい、おや、この<<(ビットシフト)が式全体にかかっているように見える。ああー、C言語の文法を間違えている? 参考書を確認する。 そうだ、+(プラス)の方が<<より優先順位が高い。今のコーディングでは4ビットシフトしてデータをつけたすのでなく、全体に足してからシフトしてしまう。括弧が必要だ。

 よーし、縞模様になる原因はわかったぞ。これで問題は解決だ。意気込んでコンパイルし、テストする。画が出るのをわくわくして待つ。あれえ、縞模様は消えない。前より少し色が出たようにも見えるが、本来の赤は緑がかった青に、青は黄色になり黒い細い縦線が残ったままだ。期待していただけに、反動ですっかり落ち込む。

高性能のロジアナを注文してしまう(10/14/2010)
 負けず嫌いの当研究所の所長は、こういう状況ではたいてい意地になる。こうなったら徹底的に原因究明をしてやる。ちょうど良い機会だ。これまで欲しくても我慢していた、200Mhzのロジアナ(ZeroPlus LAP-C16128、¥38,800 )を勢いで注文してしまった。深夜にネットで注文し、振込みもネットですませる。

 2日で到着した。おお、これは便利だ。ソフトが充実している。しかしプロトコルアナライザーでつまづく。標準で付いているSPIが設定できない。ラインが足らないと文句を言われる。BUSにはちゃんと3本定義した。思いあぐねて夜中の1時半、販売元のストロベリーリナックスに到着の報告も兼ねて問い合わせのメールをした。

Aa143301

 何と30分後に回答が帰ってきた。その日はもう気力がなかったので、次の日テスト。何だと、CTRキーを押しながらadd channelしないと同じバスに入っていかないという。マニュアルにあるのかもしれないが、読みきれない。早い回答があるというのは、FAQなのだろう。

 CTRキーを使わなくてもバスに最初に設定したラインを右クリックしても同じことができることがわかった。知ってしまえばなんと言うこともない設定だが、概念を理解していないと難しい。

W1014

 しかし、やっぱり道具や測定器には金をかけるものである。次々に新事実が明らかになってきた。プローブがまともなので測定が手軽に出来るのが良い。それにこのクラスのロジアナには、まだ使っていないけれど0.5ミリピッチICにもつけられる極小のプローブ16本がサービスでついている。お買い得だ。

 SRAMアドレス、制御線、カラー信号などつけられるだけのプローブをつけてタイミングチャートを出し、何度も測定した結果、明らかになったのは、

 ・色信号が安定して出されていない。データによるものか、FPGAのコードによるものか、FPGAの出力ピンのハードの影響か今のところわからないが、単純な単色の色コードが周期的に描画されている(画像の通りだけれど)。

・個別の色はでたらめだが、全体としては想定どおり(カラーバー)の色信号が出ている。つまり4ビットカラーの送出シーケンスに誤りがなく、中のデータだけが問題である。

・SRAMアクセスは完全にうまく行っている。

W1015

何のことはない原因はやっぱり単純なミスだった(10/17/2010)
 ロジアナの測定で原因がだいぶ絞られてきた。FPGAの描画プロセス、SRAMの読み込みには、ほぼ問題がない。不具合はやはり、送られてくるデータと、それをデコードするプロセスのところにある。

順番としては、SRAMに本来の12ビットデータが入っているか確認するのが先だ。UARTを復活させて16進表示でSRAMの中味を別の手段で確認しようとしたが失敗する。画像データをスキャンさせながらUARTを動かしてSRAMの中味を誤りなく表示させることは難しい。垂直同期期間だけUARTを動かそうとするが、どうもエラーが出るようで表示するたびに内容が違う。

 万策が尽きた。少し開発の手を休めて家族と買い物に行ったりする。こういう気分転換がデバッグに効果があるようだ。いずれにしてもSRAMは間違いなく読んでいる。STM32は、画像データをデータブロックなしに果てしなく500KB近くをSRAMに送り込んでいる。それで狂いもなく一画面分が表示されるのだから、FPGAのハザードやノイズで色が変わるならもっとランダムに色が変わらないとおかしい。現在の画はきれいに縦線が揃っている。

 16ビットのSRAMへの送り込み、取り出しはUARTの時に2バイトコードで正しく処理されていることを確認しているのであまり深く調べてこなかったが、どう考えてもここで何かが間違っているとしか考えられない。しかし、何度見返してみても16ビットデータは最初の24ビットBMPファイルから4ビットを3つづつ取り出し、それをSRAMに貯めこんでいる。SRAMから取り出す順序も間違っていない。

 ところが、ロジアナで見たRGBデータの組み合わせ(赤一色が青と黒のまだらになる。画面もそうなっている)は、SRAMデータのMSBとLSBを逆にすると赤一色からその色の組み合わせになることが紙の上でわかった。うーむ、もしかするとこれかもしれない。

 半信半疑だけれど、もうやることがない。おかしいとは思うが、これを逆に(SPIで受ける時upperバイトとlowerバイトを逆にする)して見る事にした。おおー、何ということだ。逆にすると、カラーバーを入れたテストファイルの画面が見事に原画と同じように表示されたではないか。

Aa173314

 ばんざい。ばんざい。これまでUARTで動いていた順序を逆にしたわけだから、おかしくなるはずなのだが、現実には綺麗に画像が出ている。理屈はわからないがうまく行ったことだけは確実だ。嬉しくて記念撮影をする。ここ一週間ばかり頭を悩ませていた問題が遂に解決した。 

 とにかく嬉しい。ガッツポーズをしながら部屋の中を歩き回る。これまでの暗い気分がうそのように晴れて、体中に充実感がみなぎる。この成功した時の気分がたまらない。しかし、今度は本当に大変だった。もう少しでこの計画を断念するところまで追い込まれていた。諦めずに粘った甲斐があった。

 興奮が納まって改めて冷静に原因を考える。何故以前のUARTでは問題にならなかったのだろう。そうか、UARTは8ビット単位だったのでSRAMに入ったものをそのまま返すだけで問題にならなかったのだ。今度は、バイトをまたがってデータを作り直している。SPIはMSBファーストだが、SRAMに入るときは丁度逆になるようだ。

 その証拠に、テスト画面でなく、昔のデジカメの写真(640×480)を出してみると見事にネガ写真になった。そう、色信号まで逆なのだ。これはFPGAのピンアサインを逆に設定し直して、無事、写真もそれらしく出た。まだ、どこか不具合が残っていて少し色がおかしいが、これまでの化け化けの写真と違ってだいぶましな画像になった。

Aa173315

 とにかく、フォトフレームプロジェクトはこれで一段落した。教訓は、言い古された表現だけれど、「デバッグは外へ、外へ」「大丈夫と思ったところが危ない」「デバッグに疲れたら別のことをやって気分転換」だ。最後に今まで疑っていたFPGAやSRAM、STM32などハードのみなさん、この場を借りてお詫び申し上げます。疑って申し訳ありませんでした。

| | コメント (2) | トラックバック (0)

2010年10月10日 (日)

フォトフレーム: 画像らしいものが出てあともう一息

デジタル液晶も画面が真っ暗(9/30/2010)
 どうも何かに呪われている。フォトフレームのHDLソースのロジック追加は、擬似コードレベルからのコーディングは特に問題なく完成し、論理合成やコンフィギュレーションも順調に終わったので、通電したのだが、画面には何の反応もない。オシロで見る限り同期周波数も、色信号も規定どおりに出ている。しかし画面はアナログ液晶のときと同じように真っ暗なままである。

 いったい何が悪いのだ。手探りで作ったPLLは見事に33Mhzのクロックを逓倍して62Mhz(正確には61.875Mhz)のマスタークロックを作っている。デジタル液晶のピクセルクロック31Mhzも正確に出ている(実際は30.938Mhzだが)。同期信号も所定どおりの間隔で出ていることをオシロで確認した。

 今度の液晶はピクセルクロックと、色信号の出る間のDATAイネーブル信号を要求しているが、これも想定どおりちゃんと入っている。それなのに、どうして画面に何もでてこないのか。SRAMにデータを書き込まないで描画すると、メモリのランダムな値でちょうど砂をまいたような画面になるはずなのだが、全く暗いままだ。このままでは何の手がかりがない。何処から手をつけてよいのかわからない。やっぱりカラーバーから確かめていくしかないか。

カラーバーも真っ暗(10/2/2010)
 SRAMからの描画をあきらめて、わかりやすいカラーバーを出してみることにする。急いでコーディングし、試してみた。しかし、こいつも駄目である。ところが、電源を切ろうとして一瞬カラーバーが出た。ありゃあ、前と同じだ。過渡的なときには色が出るが、一旦電源を入れてしまうと出ない。前のアナログ液晶と同じである。良く画面を見てみるとカラーバーがうっすらと出ているのが見えている。しかし、そのうちもっと暗くなって、画面は視認できなくなる。

 何が原因なのだろう。デジタル液晶なので色信号の電圧はLVTTLだ。オシロにもきれいな3.3Vパルスが出ている。DATAイネーブルを疑ったが、ここは正論理で間違いなく正しいピンに所定の描画サイクルで出ている。このデジタル液晶はピクセルドット周波数を要求する。この立ち上がりと立下りのどちらでRGBデータを拾うのかはデータシートに明記されていない。まさかと思うが両方やってみる。もちろん状態に変化はない。

 電源を切ったときとか、入れた瞬間に鮮やかな色が出て、定常になると色が消えるというのが不可解だ。何かの条件が色を出すのを止めている感じだが、この条件が見えない。
前のアナログのときと同じような状態というのが気にかかる。

S_aa033247

遂に鮮やかなカラーバーが出た。原因は意外なところ(10/3/2010)
 ここ数日は暗い日々だった。苦労して作ったデジタル液晶が、このあいだのアナログ液晶と同じように、まともな明るさにならない。ピクセルクロックもデータイネーブルも規定どおり、水平・垂直同期も正確に出ている。色信号もオシロで見る限り正常。しかし、画面は暗いままである。前と同じように電源投入直後は少し明るいが次第に暗くなる。この次第に暗くなるというのが何ともおかしい。

 原因がわからない。液晶パネルのドット描画のロジックが良く見えていないので対策のしようがない。ピクセルクロックの立下りでデータを拾う仕様で、データが逆に出ていたら真っ暗になるのかとか妄想してみるがピクセルデータは期間中、同じ値(のはず)であり、そんなわけはない。同期の裏側で描画しているから? そんなことあるわけない。

 アナログの場合は、色信号の電位差で明るさが決まるが、デジタルは各ビットが1であれば問題なく何らかの色は出るはずである。電源を疑ってケースを開け、それぞれの接続を確かめ、パネルに近いところで波形や電圧を見る。電源は少しパルスが乗っているが、3.05Vと正常範囲内だ。しかし、レギュレーターが、触った時火傷しそうに熱いのに気が付いた。

 一段目のレギュレーターは液晶パネルのバックライト用の12Vから5Vにするため7V分を熱にしているからだが、ちょっと熱すぎる。熱抵抗を計算してみると最初のTA48M05(500mA)では125°C/Wでヒートシンクなしでは少し苦しい。大きめのレギュレーターTA4805S(1A、62.5°C/W)に換えてみることにする。

 換装して電源を入れる。お、ほんの少し画面が明るくなったように見える。しかし大勢に影響はない。解決策をもとめてウェブを探していたら他社の液晶パネルのデータシートが見つかった。そこにはロジック部の消費電流が出ている。そういえば、この液晶のデータシートには、ロジック部の消費電流が記号でTBDとあるだけで実数値が出ていない。ウェブの消費電流の方を見て驚いた。5Vで120mA、3.3Vでは160mAも流れると書いてある。

 ロジック部の消費電流がこんなに大きいとは思っていなかった(100mA以下とみていた)。3.3Vのレギュレーターは例のLPCMプレーヤーに入れてビートが出たため使っていないXC6202である(8ヶも余っている)。 150mAとれるので余裕と思っていたが足りない可能性がある。これはいけない。この液晶パネルの実際の消費電流を測ってみた。

 結果は125mAで、XC6202の定格内だ。こちらのレギュレーターは熱もそうない。電圧もちゃんと3.05Vでている。しかし、これまでの状況から、どうも電源が臭い。調べるところがなくなって、だめもとで別の3.3V電源アダプターでロジック部を供給することにしてみた。

 何と、何と、これで液晶モニターに鮮やかな色が戻ったのである。ええー、オシロで測った今までの電源電圧は一体なんだったのか。きれいな3原色が表示される。夢にまで見た鮮やかさである。

 また、XC6202が悪者になってしまった。こいつが力不足で120mAを消費するロジック部を正常に駆動できなかったのだ。定格内なのにおかしいが、これが原因であることは間違いない。急いで、500mAとれるTA48M33にしてみる。鮮やかな色が出た。結局、電源容量不足という単純な原因が画面が明るくならない原因だった(あとでデータシートを良く見たら電源の最小電圧は3.135Vだった。たった0.085Vの差で真っ暗になるとは)。わかってしまえば何でもないが、ここにたどり着くまでえらい時間がかかった。

S_aa043267

SRAMを読んだ画面が出た!(10/6/2010)
 液晶に色が戻ったので、ロジックを更にいじって、カラーバーを上段に、コメントアウトしてあったSRAMの内容を表示するルーチンを生き返らせて、下段に出すレイアウトにする。出ました、出ました。まだSPIが動いていないのでデータは更新できないが、SRAMのランダムなデータを拾って、ちょうど大理石模様のようなこまかい画像が表示された。

 今までは、縦縞ばかりだった(1ライン中のデータが同じままのとき)が、これはSRAMを順調にラインを越えてアクセスしていることを意味する。いやあ、嬉しい。これまでの暗い気持ちがいっぺんに吹き飛ぶ。これで画像表示まで大きく近づいた。しかしそれにしても長い道のりだった。この爽快感はいつ経験してもこたえられない。ランナーがマラソンにはまるのと同じである。苦しみが大きければ大きいほど、喜びが倍増する。

 いよいよ次は実際の画像の確認である。SPIから送られた画像データが表示出来れば、フォトフレームの第7ステップ(一期完成ステージ)は完了する。STM32プロセッサーのBMPデータの抽出コードはまだ出来ていないので、とりあえずSPIの動作を確認するため、UARTでSRAMを確認できるようにする。

 データ読み込み中は画面を止めることにしたので、SPIの動作を優先しSPIデータが入る(チップセレクト)とただちに読み出しを停止するように変更する。UARTは別のSRAMアドレスを用意し、画面の垂直ブランクの時だけSRAMをアクセス出来るよう、assign文で読み込みアドレスの切り替えを2段にする。

 VerilogHDLの変更が終わった。わくわくしながら電源ON。しかし、データを送れば画面はかわるものの一色でぬりつぶされ、UARTからはデタラメな文字しか出てこない。かえって退歩してしまった(最初はSRAMを読んでいる証拠の砂模様画像だった)。まあ、これからが勝負である。ひとつづつつぶしていこう。

やっとのことで画像らしいものが出た。あと一息(10/8/10)
 FPGAのソースコード開発をひとまず横に置き、画像ファイルを送るSTM32側の開発を再開した。BMPファイルを読み、ヘッダー情報からRGBデータだけを抽出して、FPGAにSPIで送るロジックの開発だ。

 24ビットのRGBデータを12ビットRGBに抜き出すロジックは、はじめSDカードからの読み込みの単位で処理を考え、読み込みブロックをまたがるRGBの分離に頭を捻っていたが(RGBは3バイトで1ピクセルを構成するので、端数が出る可能性がある)、これは発想の転換でいっぺんに解決した。いや気分が良い。

 つまりプログラムはRGBをとりだす処理の方をメインループにし、ブロックサイズを越える時点で、次のSDカードを読む処理を入れてデータブロックを更新すればよい。今まであれこれ悩んでいた継ぎ目でのロジックはこの方法では考える必要がない。一気に解決した。このあたりがソフトウエア開発の醍醐味だろう。幾何でいう補助線一本で証明が出来たときの快感と同じである。

 機嫌よくコーディングを終えて、BMPファイルを用意する。ペイントプログラムはどうもピクセル単位にキャンバスを作れないようなので、一旦ペイントで適当に画像を作り、デジカメについていたおまけソフトで640×480のピクセル24ビットBMPファイルに切り出す。

Photo

 さあ、これで画像ファイルも出来た。PCでSDカードに移し、STM32のSDカードスロットに入れて、FPGAに送り込む。さあどうだ、FPGAは、その後UARTを止めたりして前の状態に戻しSRAMが読める状態になっているはずだ。あれえ、全く変わらない。

 SPIは読んでいるようだが(LEDが点滅)、SRAMにちゃんと書いていないようだ。こうなってくると、もうオシロは役に立たない。ロジックアナライザーの出番である。FPGA基板のコネクターに例のスタブ(0.5mm銅線)をたて下位のSRAMアドレスやいくつかの制御線にプローブをあて慎重に解析を開始した。

 今度のソースはこれまでになく複雑になっている。画像を出すロジックは、同期信号を作成するモジュール、色信号を所定のドットに乗せるロジック、12ビット色信号を16ビットSRAMデータを読みながら作るロジックの3段が並行し、これにSRAMを読むモジュールと計4つのプロセスが同時に走る。

 ロジアナの威力はやはりすごい。次から次に不具合が見つかっていく。しかし現在のロジアナの限界が見えてきて解析が順調に進まなくなった。今使っているロジアナは、2年前に買ったオプティマイズの100Mhz、32CHの安いけれどなかなかの性能で、これまで重宝してきた。

 しかし、今のFPGAのマスタークロックは、62Mhzでピクセルクロックは31Mhzである。ピクセルクロックくらいまでは見えるが、60Mhz台のSRAMアクセスのタイミングを正確にとることは難しい。実際に、このタイミングをはずしているのかロジアナが捕まえられなかったのかがわからないのでは解析しようがない。うーむ、「すん」さんがこのあいだ買ったという200Mhz台のロジアナが欲しいな。少し高いけど(¥38,800)。

 それはともかく、とりあえずは先に進まなければならない。コードを少し修正しては、ロジアナでタイミングを調べ、さらにおかしそうなところを修正してタイミングチャートを調べる。RGBをぬきだすところと、画面に出すところのタイミングが少しづつ合ってきてSRAMのアクセスが順調になってきた。ドット単位にアドレスが増えていく。

Wvga

しかし、SPIで入れたデータがどうしても順調にSRAMに書き込まれない。出来る時と出来ない時がある。散々調べた結果、原因は、やっぱりFPGAのコードではなく外であることがわかった。やれやれ。

 STM32のCS(チップセレクト)が間違っていたのである。データを送る以前に正しくCSがセットされていなかった。これを直すと画面のSRAM初期画面と明らかに異なる画面が出た。ちょうど水平同期が乱れた時の横線である。これだ。SRAMに新しくデータが送られた証拠である。画像のサイズが狂っているので横流れになっているが、これを補正していけば画像になるはずである。

 今度のデジタル液晶は、800×480のWVGAなので汎用性を持たせるため、両側の80ドットを黒くして画面を640×480にしている。もしかしたらSRAMアクセスは黒いところも動き、画像を縦の長さを無視して展開しているのではないか。ソースコードをいじって640ドットだけSRAMを読むようにする。

 出た。元の画に較べれば、色は殆ど出ていないし、表示が斜めに傾き、画像がちょうど裏になっている(スキャン方向を間違えている)が、明らかにBMPファイルの画像の絵である。フォトフレームを志して半年、はじめて出た記念すべき画像だ。

S_aa093281

 いやいやそれにしても普段何気なく使っている映像機器の画面表示の裏にはとんでもなく複雑なロジックが動いていることを実感する。スクラッチから静止画をひとつ出すのにこんなに苦労するとは正直言って始める前には想像もしていなかった。

 ここまでくればもうあと一息である。ハードや画面描画には問題なくなったので、あとは中のRGBデータのハンドリングを正しくしてやれば、ちゃんとした映像になる見通しがついた。デジタルフォトフレームのプロジェクトもそろそろ大詰めが近い。

| | コメント (0) | トラックバック (0)

« 2010年9月 | トップページ | 2010年11月 »