これまで散々手こずってきた純正のフラッシュローダーの機嫌の悪さに較べれば、圧倒的に安定してチップに書くことが出来る。メッセージも豊富で動かしていて安心感がある。サイトの情報によるとARMだけでなくAVRやPICにも使えるようだ。これは良いものを教えてもらった。(2)どうしても動かなかったHex2DFUが動いたMakefileに定義してあって、hexやbinファイルを作る手順に上記フリーソフトが動くように設定してあったのだが、これまでどうしても動かなかった。スペースの入ったディレクトリのパスは受け付けないということを教えられ、これを別のところへ持って行ったらあっさり動いた。Files"などを受け付けていたので、まさかと思っていた。これでHexファイルからDFUファイルに変換する手間が省けて、DFUでの開発が楽になる。DE0を発注してしまった(11/5/2010)すんさんの掲示板にも書いたけれど、遂にALTERAのFPGA評価ボードDE0をDigiKeyに発注してしまった。CycloneIIIにDRAMやフラッシュ、VGA、I2C、UART、PS2など盛りだくさんのペリフェラルがついた教育用評価ボードで、価格が1万円少々と破格の安値で前から注目していた。私が掲示板で勧めたこともあったのかも知れない、周りで次から次に買う人が増え、しかも面白そうなアプリケーションをDE0で動かしておられるのを掲示板で見せられて指をくわえていた。今まで買わなかったのは別に1万円の出費を惜しんでいたわけではない(え、いややっぱり1万円を越すと何かとありますが)。買うのなら、価格がDigiKeyの送料無料ラインを楽々越えるので、日頃、手に入りにくいチップが集まってから一緒に買おうと思っていた。今のところ欲しいチップは、PGA2311という電子ボリュームICだけで、なかなか次のものがあらわれない。手を出さなかった理由はほかにもある。新し物好きなので気が散って今やっているものを投げ出す恐れが強い。それに、既に2つの会社のFPGA、Xilinx、LatticeのインターフェースケーブルがごろごろしているのにまたAlteraのものも増やさなければならない。開発環境をこれ以上増やすのは今のPCはドライブがもう満杯で、ディスクを買い直す必要がある。あれやこれやで、暫くは買わないと心に堅く決めていたのだが、フォトフレームが動き出して、すっかり緊張の糸が切れ、欲しい気持ちに歯止めが効かなくなってしまった。それに今のフォトフレームで不満なところを、今度の評価ボードは埋めてくれるような気がしてきたからである。現在のフォトフレームはSPIでデータを送っているが、シリアルなのでスピードが遅い。VGAにしてしまったので、画面描画中は、全くデータを受け取ることができない。SRAMは10nsの高速だが、既にFPGAのクロックは15nsまで上がっており、パラレルバスにしないと帰線期間中の大量データ書き込みは出来ない(SPIでは送れても数十バイト)。FPGAでSDカードを読み、内部で処理すれば、うまくいけば動画レベルまで画像処理が出来そうな気がする。今の付録基板では、CPUコアは恐らく入らないだろう。DE0クラスでないと無理だ。DE0ならもしかするとウェブカメラまで出来るかもしれない。このへんを実現するのは、相当、使い込まなければ無理だと思うけれど、夢があることは大事なことだ。DigiKeyからDE0が届いた(11/8/2010)何だかんだやっているあいだに、DigiKeyから品物が到着してしまった。ここはいつも恐ろしく早い。土日を抜けば、営業日勘定で1日半(木曜午後注文して、月曜朝到着)という早さだ。梱包を開けて中を取り出す。思っていた以上にコンパクトだ。電子ボリュームのIC(PGA2311)と一緒に記念撮影。すんさんの掲示板で、発注したことを報告したら、沢山の人からレスポンスを貰った。一人新しく買う人が増えたのと、このDE0を知るきっかけとなったご当人のSimさんからもコメントを頂いた。こちらはFPGAなどまだ初心者も良いところで、色々教えてもらおうと思っているところなのに、情報提供を期待されるなんて少し面映い。当研究所のブログは、技術情報の提供は余り主眼に置いていない。みなさんの新しい情報にお世話になっている。どちらかというと、このブログは挫折しないため(動かなくてもめげずに這い上がるため)のノウハウ談だと思っている。このDE0でもせいぜいたくさん失敗を重ねることにしよう。先の話はともかく、今すぐDE0を使う手近なアプリケーションは思い当たらない。このボードのデモを動かしながら勉強をしていこうと思う。そのなかで気になっているのが、Simさんがすんさんの掲示板で紹介された、NiosのAvalon-MMというCPUバスだ。今度のフォトフレームもここの性能如何で何が出来るかが決まる。CPU設計のまさしく奥の院で、この仕様が公開され、いじれるというのは、ソフトウエア開発者にとっては夢のような話である。ああ、こんな話をしている場合ではない。CPUのSRAMサイズが大きくなったので、早くJPEGライブラリを入れてフォトフレームを完成させなければ。XP2を使ったFPGAフォトフレームは、遂にSDカードからのBMP画像ファイルを7インチWVGAデジタル液晶に表示することに成功した。細かい不具合を直すと、これが思っていた以上にきれいな画になったので、欲を出して、SRAMを増設し12ビットカラーから、もう少し本格的なデジタルフォトフレームにしようとがんばってみた。SRAMへの書き出しを逆にして直った謎は解けた(10/20/2010)さんざん悩ませてきた縞模様の画像が解消されたのは、理屈に合わないがSPIから送られてきたデータの順序を逆にすることだった。12ビットのRGBの色信号はバイトをまたがって構成されており、本来この順番を逆にしたら、でたらめなデータになってしまうはずである。落ち着いて考え直して見てその原因がわかった。SPI,UARTはMSBファーストでデータを送るのだが、送られたデータをそのまま右端(LSB)から入れていくと、出来たバイトは逆のLSBファーストになるのだ。SPIで入れたupperバイトは15から8番目のデータで、送られるとMSBから8-15と並ぶ。lowerバイトは、これと同じ、0-7。この16ビットデータ(8-15と0-7)を並べてどちらから連続して12ビットとっても元にはもどらない。このupperとlowerをひっくり返すと、0-7、8-15と並び、これで16ビットデータは連続する。メモリからUARTに出す時は、これと全く同じようにMSBから送り出すので、元のオーダーに戻る。1バイト毎の処理ならばメモリにどういう形で入っているかは問題にならない。これが解決を遅らせた要因でもある。結果としては、リトルエンディアンとビッグエンディアンを間違えたということになる。何か少し違うような気もする。いずれにしてもUARTなどのシリアル系ではビット順は注意しないといけないことを身をもって学んだ。デジタル色信号の配線の間違いがあった(10/24/2010)テスト画像のような単色画像はもう問題ないが、グラデーションのある写真画像はまだバグが残っていて鮮明な画像にならない。原因究明に、良い方法を思いついた。3原色のグラデーションの画像でテストすれば一発でどの色がおかしいかが分かる理屈だ。次女に作画を発注し、それをSDカードに移す。映し出された画像を見て、一目瞭然でおかしいところが判明した。赤と緑は問題ないが、青の暗いところが暴れている。うーむ、こいつはすごい。デジタル信号の間違いが一目で分かる。基板を調べると、画像のとおり青のビット3とビット4が逆に配線されていた。いうトラブルシューティングは実に爽快である。配線間違いはFPGAのピンアサインでも修正できるが、あとのことを考えて半田ごてで修正する。よーし、写真がきれいに出るようになった。この液晶、輝度が高すぎて正面から見ると画像が白っぽく飛んでしまう。インバーターに半固定の抵抗をつけてブライトネスの調整をしてみたが、見やすい明るさまで落とすことは出来ない。液晶パネルは見る角度でずいぶん印象が違う。液晶には最適な見る角度があるようだ。パネルを下からあおぎみるようにすると、黒がきれいに落ちて、画質が格段に向上することを発見した。逆に上からみるとパネルは白っぽくなって画像は薄く見にくくなる。フォトフレームは上から見ることが多い。ディスプレイを天地逆にセットし、スキャン方向を今までのちょうど逆にして画像を出してみる。おおー、これは美しい。今まで輝度が大きすぎて白っぽい画が、色の良く出たまともな画像になった。これなら、フォトフレームとして十分実用になる画だ。ここではたと気が付いた。こちらが正位置なのだ。垂直方向の調整ビットが逆になっていたのである。640×480のVGAは、7インチの液晶パネルの大きさで見ると非常にきめ細やかで、みごたえのある解像度になる。QVGA(320×240)とは画質が格段に違う。試しに前のアナログ液晶のQVGAと一緒に映してみた。して直接比較して見るとQVGAとの差は歴然としている。今までの苦労が報われる美しさだ。これはもう玩具の域を超えた立派なフォトフレームだ。実装が楽しみになってきた。テスト画像を作ってくれた次女が感心してくれ、「欲しい。作って」とも言ってくれる(親孝行な奴だ)。12ビットカラーの明暗の段差はどうしようもない。単色では16階調しかないので、青空などははっきり等高線がついてしまいせっかくの解像度が台無しだ。微妙に色が変わるところは貼り絵的な段差になる。ここまできれいな画像が出るのなら、もう少し多ビットカラーに拡張したくなってきた。JPEGデコードは現行のCQ-STARMでは無理とわかる(10/27/2010)フォトフレーム計画のロードマップによれば、次のステップ(第8ステップ)はJPEGファイルの描画である。実用的なフォトフレームにするには是非実現したい機能である。FPGAの方が一段落したので、JPEGライブラリの方を本格的に調べ始めた。JPEGについては、以前から実現する方法をウェブで調べている。ウェブの検索では、いくつかのサイトがヒットしていたが、詳しく調べると、これらは、すべてオープンソースのfreeJPEG(IJG)がオリジナルであることがわかった。何と、このブログにもときどきコメントを寄せてくれる、ねむいさんや、そら。さんも、このJPEGライブラリを実装されて動かされているようだ。いざとなったら教えてもらえる。オリジナルのサイトのreadme.txtで確認したところ、現在の基板CQ-STARMではSRAMの容量不足で実装できないことがわかった。この付録基板のCPUは、STM32F103VBT6でフラッシュが128KB、フラッシュは何とか入りそうだが、SRAMは20KBしかない。IJGのJPEGルーチンは、デコード時、最小でもバッファーメモリは24KBを必要とするようで、ここに詳しい報告がある。この付録基板(CQ-STARM)は、ねむいさんが以前STM32F107VC6(フラッシュ256K、SRAM48K)に換装されておられ、私もこのあいだDigiKeyに発注してあるのだが、在庫切れでまだ到着していない(3ヶ月以上待たされている)。いえばこれとは別に、STM32F103VET6を買ってあったのを思い出した。これはSTM32Primer2の石の予備に買ってあったものである。これは同じ型番の石なので問題なくピンコンパチでCQSTARM基板に換装できるはずだ。これなら今すぐにでもできる。いえ、現在機嫌良く動いている基板のCPU換装は何となく気が進まない。¥3000も出せば、512KBフラッシュ、SRAMが64KBの同じ石のARM基板が買える。いうことで、方針が固まるまで、FPGAのSRAMを増設して15ビットカラー(3万2千色)にする方を先に着手することにする。SRAMの増設も簡単には済まなかった(10/29/2010)液晶は18bitカラーだし、FPGAのピンも余っている。メモリが512KBしかないので12ビットカラー(460KB)にした。SRAMを増設して1024KBにすれば、18ビット(690KB)まで出せるが、今度はコネクターを20ピンにしてしまっているので今のハードでは15ビットカラーが限度だ。転送時間のこともあるので、とりあえずの次の目標は、15ビットカラーにする。いずれにしても必要な、SRAMの増設にまずとりかかった。Back)方式で実装することにする。Enable)を用いてバンク切り替え(OEの意味が始めて分かった)する。OEとWEを独立させて制御すれば、簡単に動くはずだ。SRAMの変換基板を重ねるため、最初ピンヘッダーで重ねようと、ローハイトのピンヘッダーを準備して、一方のピンが変換基板の穴に入るよう細く削りだした。全部の削りだしが終わる頃、SRAMがFPGA基板のソケットの下に半田付けしてあったことに気が付く。ピンヘッダー経由では高さがあってFPGA基板の下側にはいらない。仕方がないので、強引だが0.5ミリ錫メッキ線を一本づつピンポストに立てて半田付けし密着させることにする。始めてこずったが、写真のように一旦テープで線を揃え、基板の穴を通して一度に半田付けするとうまく行くことがわかった。12ビットカラーでひとまずSRAM増設のテストをする。思ったようには動かない。トラブルの切り分けのため、まず2つめをdisableにして動かす。これは問題なく動いた。それではと増設したSRAMのテストをする。これは単独でも駄目だった。2つめのSRAMのハードが疑われる。読み込みはやっているようだ。ハードをチェックする。おやおや、WEのピンの場所を1つ間違えていた。何度も確かめてピンに印をつけてあったはずなのに、この印ごと間違えている。2段になったピンアサインは本当に間違いやすい。これを直して、2つ目もやっとデータが書き込まれた。何ラインかごとに画像が櫛のようにずれる。うーむ、これもハード臭いな。画像がずれるのは、データではなくアドレスがおかしい。2段重ねの導通をテスターで何度も測る。ショート?それなら一つ目からおかしくなるはずだ。それはありえないと、独り言を言っているとき、変換基板のICチップのピンの半田付けがやけに薄いところを見つけた。ついているようなついていないような微妙な半田付けだ。テスターでは導通している。問題なさそうだが、どうもここしか考えられない。だめもとで半田付けをやり直した。よーし、やっぱり半田付け不良だった。2枚目のSRAMも正常に画像を蓄積し表示ができるようになった。テスターでの導通は、プローブで押さえたためと思われる。2枚のSRAMの切り替えのテストも手間取った。最初、2つ目のSRAMの動作を止め、スタートアドレスをいくら1枚目の後半にしても画像が切れない。アドレスの最高位ビットを何度も計算しなおし(ワードアドレスなので混乱する)、19ビット目のビットが立てば、2枚目のSRAMをアクセスしに行き、データがないので真っ白になるはずなのだが、そうならない。調べた結果、原因はこれも意外なところが犯人だった。追加したステートメントではなく、ソースリストの最後の書き込みと読み込みアドレスを区分するassign文のビットが拡張されていないという単純なミスだった(19ビット目が全く無視されていた)。これを直して、無事、SRAMをまたがって画像が蓄積された。これで1024Kのビデオバッファーが実現した。今度のミスは配線間違いとハンダ付け不良というハードミスが2つ、ソフトのうっかりミスが一つ、SRAM増設にともなうVerilogHDLのコードの方はすべて思ったように動いてくれた。HDLコーディングに大分自信がついてきた。15ビットカラーが出た(10/31/2010)メモリが増設できたので、残るは15ビットカラー化である。STM32プロセッサーとFPGAのロジックを修正する。FPGAの方は12ビットカラーに比べると格段に楽になった。ステートマシンは不要で、メモリを取り出し、16ビットを5:6:5に配分するだけである。STM32の方は少し難しくなる。奇数回での送出になるので、バッファーの切れ目にどこで遭遇しても取り間違いが出ないよう、SDカード読み出しを関数にして何度も呼び出す必要がある(最初これに気がつかなくて、前と同じ縞模様が再現し、冷や汗をかいた)。内部処理を外部関数に切り出すのは、C言語では変数のスコープが大きく変わるので非常に気を遣うのだが、この際、泣き言は言っていられない。ここの世界は何十年のキャリアがある。弱みを見せるわけには行かないのだ。何とかエラーは出さずに済んだようだ。ハードの作業が残っていた。15ビット用の3本のデジタル色信号線を追加して、それぞれRGBに追加する。論理合成、ピンアサインも順調に済み、いよいよ通電である。STM32のUART端末で恐る恐るファイルを指定する。STM32の修正も問題なく、15ビットカラーが出た。単色のグラデーションはまだ段差が目立つ(32階調)が、青空は何とか目だたない程度までなくなった。全体に画像がしっとりした感じになる。いやあ、これならフォトフレームとしても大威張りだ。次に何をするか迷っている。今動いているCQ-STARM基板のCPU換装か。それとも別の基板を買ってくるか。