息抜きに赤外線リモコン電子ボリュームを作っている

　DE0が到着したというのに、なぜかここへきて急にフォトフレームもFPGAも制作意欲を失ってしまった。DE0は、あまりにも沢山の玩具を見て足がすくんでしまった子供のように、どうにも動けない。それでも開発環境はインストールしたが（QuartusはLatticeと違ってCドライブでなくても動いた）、気力はそこまで。先へ進まなくなった。

　JPEGはJPEGで、ライブラリのインストール手順をこと細かに解説した(UNIX上だが)とてもわかりやすいサイトが見つかった途端、先に進む意欲を失った。昔から道筋がついてしまうと急に安心してしまって、やる気がなくなる癖がある。

　JPEGが進まないのは他にも理由がある。JPEGファイルには、必ずオリジナルのピクセルサイズがあり、デコードでこれを可変にできないことがわかった。ということは、このフォトフレームに入れるJPEGファイルは常に640×480ドットの画像でないと、正しく表示されない。

　それは困る。多種多様なJPEGファイルを放り込んでも、それとなく表示できなければフォトフレームとは言えない。しかし、そうするためには、デコードしたあとのビットマップデータをプロセッサーで処理してサイズを合わせてから、FPGAに送るという手順が必要になる。

　画質を落とさないリサイズやリサンプリングは結構、厄介な作業である。ユーザーインターフェースを良くするためには相当な開発が必要なことがわかった。どの程度まで踏み込むか簡単には判断がつかない。これが先に進めなくなった大きな原因だ。

　というので、このあいだから少しづつ準備していた赤外線リモコンによる電子ボリュームのプロジェクトを立ち上げ、少し気分を変えて意欲が回復するのを待つことにする。

赤外線リモコンの全体構成を考える(11/10/2010)
　おりしも、エッジの取替え修理に出していた30年もののタンノイスピーカー(Berkeley)が工場から戻ってきた。送料を入れると費用は2本で軽く3万円を越したが、気のせいではなく明らかにスピーカーは生き返った。今までの何となくしまらない（響きが悪い）音から、きっちりしたメリハリのある音に戻った。これでまた暫くこのセットで音が楽しめる。

　赤外線リモコンはこのオーディオセットの音量調整に使うつもりである。以前からこのオーディオセットのリモコン化が懸案だった。昔々LPレコードのHiFi（これは死語か）オートチェンジャー（これもか）を探し回って馴染みのオーディオショップの店主から叱られたことを思い出す。

　時代は変わった。音量調整用の電子ボリュームICは既に買ってある。TI社のPGA2311である。FPGA評価ボードDE0を買う時に一緒にDigiKeyで買った(￥1,080)。市場には、沢山の電子ボリュームICが出回っているが、スペックによるとこの石の性能(高調波歪だけだが)は他と較べて群を抜いて高い（そのぶん値段も高い）。高級オーディオ装置向けのようだ。

　ウェブにも沢山制作例が出ている。しかし、キットや既製品が多く、この世界は組み込み系というより、オーディオの世界なのでプログラムやロジックの詳しいサイトは少ない。この石の電子ボリュームだけで￥20,000を超える高級既製品もある。

　一方、赤外線リモコンの方は「赤外線　リモコン」で検索すると、あるわ、あるわ、沢山の人がこのしかけを調べ、解析し、自作している。こちらはラジコン、工作関係の人のサイトが多い。自分が作ろうとしている電子ボリュームリモコンの記事もある。自作、キット、既製品いくらでもある。今さら、ここで制作記を書いてもあまり喜ばれないかもしれない。

　まあ、売り物にするわけではない。あくまでも自分の実用のためだ。気にすることはない。今のところQUADのプリアンプ405とメインアンプ44の間のオーディオケーブルの間にはさんで音量調節をする。7セグLEDなどで現在音量値を表示し、電源を切ってもその値を記憶しておくようにする。大まかな仕様は出来た。

PGA2311を調べ始める(11/12/2010)
　調べているうち、こいつはアナログアンプでもあることを知った。最大ボリュームでは、31.5dbも増幅する。ボリュームが増幅するというのはちょっと不安なので、0dbを上限にした方が使いやすいかもしれない。それでも192段階調整できる。データシートがあるので制作上の不安はない。

　PGA2311は正負両電源を必要とする（幸い±5V）。昔買ってあったトランスと7805、7905によるシリーズ電源にしたい。5Vの正負電源なら秋月のFG(ファンクションジェネレーター）のときに作ったDC-DCコンバータの予備があるが、ここはそれ気持ちの問題である。スイッチング電源でも殆ど問題ないと思われるが、高級品の電子ボリュームICの顔も立ててやりたい。それに買ったまま使っていない電源トランスの活用にもなる。

　PGA2311のデジタルインターフェースはSPIである。プロセッサーから8ビットづつの左右の音量値を受け取るだけである。プロセッサーにはEEPROMに設定値を覚え込ませておく。AVRのEEPROMは10万回くらい書き換えできるようだが、毎回変化するたびに記録するのではさすがに寿命が心配だ。

　電源を大容量キャパシタかなにかで保持し、EEPROMに記録した後、リセットICか何かで、このバックアップ電源もシャットダウンすれば、書き込み回数は最小になるが、ここまで凝ることもあるまい。まあ、5回に一回とか、一分に一回とかのタイミングでEEPROMに書いておけば十分だろう。こういう工夫を考えるのも電子工作の楽しいところだ。

久しぶりのAVRの開発(11/14/2010)
　最初に、赤外線の受信部を作る。赤外線の受信モジュール(PL-IRM0101-3)は大分前に秋月で入手し簡単なテストは済んでいる(前記事9/11/2010「フォトフレーム：　デジタル液晶を動かす準備」)。

　赤外線信号のフォーマットは多種多様で機器によって全部違う。オーディオなどのAV機器には、いくつかの業界統一フォーマットがあるようだが、外国製品（QUAD）は全く違うし、エアコンなどは数十ビット以上のコードで何が何やらわからない。変調方式はなぜかみなパルス位置変調PPM(Pulse Position Modulation)である。

　この解析だけで沢山のページを使っているサイトもある。当研究所のモットーは「実用」である。役に立てばそれで良い。フォーマットに凝る趣味はない。ざっとみて、ビット数が少なく(12bits)、一番簡単な（自分にとって）Sonyのフォーマットを使うことにした。

　ソフト開発に入る。ターゲットはAVRである。AVRマイコンはここの研究所の名前どおり、当研究所の電子工作発祥の石である。このところFPGAとかARMとかに走っていたけれど、久しぶりにAVRStudioに戻ってきた。何故か懐かしいふるさとに帰ってきたかのように気分が休まる。

　AVRStudioの新しいプロジェクトを作る。とりあえず、石は秋月で￥100のATTiny2313を選ぶ（7セグLEDまで入るか少し心配だが）。ブレッドボードに実装する。ソフトは前から擬似コーディングを片手間に始めており、PPMの信号をデコードするロジックは出来上がっている。

　印刷されたAVRのデータシートを久しぶりに開けてタイマーのところをおさらいした。このデータシートは2年以上前に日本語サイトからダウンロードしたものである。このサイトは一時、閉じていたが、最近、復活した。いくつかの電子パーツショップが協賛している。AVRの日本語データシートが自由にこれからも見られることは有難い限りだ。

　データシートを見ているうち、前から気になっていた、「捕獲入力」（キャプチャー入力のことだが、ちょっとおおげさな翻訳）機能のところで、はたと気がついた。これは今、自分がGPIOで普通のタイマーを使いながらやろうとしていることと全く同じではないか。

パルスが入れば、タイマーを動かし、次のパルスでその間の時間を測る。この間隔の大きさの違いで、0か1を判断しようとしていた。赤外線リモコンのパルス位置変調(PPM)のデコードはこれで出来るはずだが、タイマーの設定と外部割り込みの2つの設定が必要である。これに対して、キャプチャー入力を使うとタイマーの設定だけで一発でデコードできるのだ。しかも遅れもない。これは感動した（常識だったらごめんなさい）。

　おや、Tiny2313のキャプチャー入力は、片側のエッジでしか反応しない。ふーむ、ウェブでは両エッジで動く動作例が殆どだ。まあ、これは割り込みのたびに設定を換えてやればよいだけの話だ。

　赤外線を出す送信機は、昔々面白半分に買った汎用のリモコンを使う予定だ。こいつは設定ボタンで各社(10社以上）のリモコン信号を出力することが出来る。今回使うコマンドは、音量上下、それに無音（MUTE)の3つだけなので、これで十分である。

　うーむ、ロジアナで見ていると、赤外線リモコンというのは同じ信号を何回も出してしまうようだ（このリモコンだけではなかった）。音量アップの信号が多数回でるのはまずい。チャタリング防止のような感じでまとめる必要がある。

同じようなミスを立て続け(11/15/2010)
　AVRで赤外線モジュールの信号をデコードし、UARTにビット列を0,1で表示するテストプログラムの開発が終わった。キャプチャー入力のパルス間隔を測り、所定(12ビット)のデータ量が来れば、UART出力ルーチンのゲートを開いて結果を出力する。たいしたコード量ではない（1KB少々）。すぐ動くと思ったけれど、やはり久しぶりのAVR開発は、バグだらけで思ったようにすんなりとは動いてくれなかった。

　いくつかあったバグをつぶしたあと、バグの原因をリストアップしてみて思わず苦笑いする。前にやったミスを忠実に繰り返しているのだ。ちょうど生物は進化の過程を胚から胎児の間に再現する（個体発生は系統発生を再現する）という生物学の法則みたいだ。

・まず、ポートレジスターのビット順の数え方を間違えていた。最初、赤外線モジュールの出力を入力ピンにつけるとデータが消えてしまうので大騒ぎした。これはピン順を間違えインピーダンスの低い出力ピンに入れていたためだった。前にADコンバータで同じ間違いをやったことを思い出す。

・キャプチャー割り込みのピン（ICP)の状態が見えなくて苦労する。一生懸命、PORTからデータを読もうとしていた。入力はPINだ。これも最初の頃やって大はまり。

・タイマーの割り込み先を定義していなくて暴走する。コンペアマッチなのにオーバーフローのエントリを定義して、暴走しリセットを繰り返していた。ソースコードの使いまわしをするとこういうミスが出る。

・フラグがたたずに必要な処理を素通りする。ローカル変数に同じ名前を定義していた。

いずれも、以前にやったミスばかり。FPGAと違って、LEDやprintfで途中経過が出せるので、すぐ解決したが、余りにも以前やったミスと同じことを繰り返す自分に感心してしまう。

　UARTのところは最後まで、てこずった。本番ではUARTは使わない。しかし、採集したパルス間隔の正確な閾値を求めるためには、UART出力が欠かせない。考えてみたら、赤外線リモコンのデータは、1ビット単位が、0.6～1.8ms、このあいだに悠長にUARTで出力をだしていたら（1バイト0.2msで3文字くらいをパルス単位に出す）、赤外線データの方を取りこぼしてしまう。

　今は、強力なロジアナが手に入ったので、パルス間隔を無理にUARTで測ることもないのだが、バグ続きで少し意地になっている。不具合の原因ははっきりしている。UART送信関数が、ハードウエアがデータを送り終わるまでループで待っているので、次の赤外線割り込みがそのあいだに入り前のデータを消してしまうからだ。

　これはUARTの送信関数にバッファーを設け、UART送信を割り込みで処理すれば解決する。ChaNさんのFATFsのモニターのUARTでも使われている方法だ。そっくりこちらに持ち込んでも良いが、せっかくなので自前で作ってみることにする。

　送信割り込みは、送るデータが空になると割り込みが上がり続けるので、ちょっとした工夫が必要だ。ChaNさんのソースを、そっとカンニングする。ああ、やっぱりね。バッファーのポインターを監視していて、送るデータがなくなると、UARTのレジスターを叩いて、割り込みを止めている。そうだよな。これしかない。割り込みの開始は、新たな送信要求のときに設定する。ここは何度繰り返しても問題ない。

　改良版が出来た。途中経過が暴れる時もあるが、12ビットの赤外線データは、ほぼ100%正しくデコードされた。 最初は安定しなかったが丁寧に閾値を調整すると100発100中になった。これもUARTでパルスの幅を調整できたお陰だ。その後途中経過が暴れる不具合もリングバッファー終点の計算間違いが発見され解決した。

　よーし、赤外線リモコンの部分は完全だ。送信割り込みのUARTも前々から気になっていたが、これで安心して高速なところにUARTを使える。赤外線データの解析はフォーマットが多種多様なのでこれ以上深入りせず、次の電子ボリュームの制御の方に開発の方向を移した。

ソフトSPI（マスター）を作った(11/16/2010)
　電子ボリュームPGA2311の入力インターフェースはSPIである。Tiny2313にはSPIはない。USIを使っても良いが、こいつは癖があって簡単には動かない。速さも量も求められていないし、GPIOで作るほうが簡単なように思えた。というのでGPIO（汎用ピン）でソフトSPI（マスター）を作ってみた。

　この開発には、このあいだ買ったZeroPlusのロジックアナライザーが大活躍した。プロトコルアナライザーがついているので、SPIのデータもいちいち波形を数えて調べる必要がない。UARTも簡単にデコードしてくれる。とても楽だ。

　ほぼ出来上がったが、送信したビットがどうしても1ビットずれて送信されてしまう。簡単なロジックなのにどこが悪いのか、いくら調べても解決できない。諦めてもう寝ようと風呂に入っているとき気がついた。

　赤外線のデータをSPIに送るとき、データを左シフトさせながらMSBを取り出し、8回ループして送信データを作る。あっあっあっ、こりゃ、だめだ。最後の1ビットのあとに次の（不要な）シフトをして見事に1ビット欠けた送信データを作っている。Whileではなく、do{..}whileでないといけないケースである。

　しかし、風呂に入らないと、この程度のバグも見つけられないというのは困ったものだ。これを直して、基本的な開発は完成した。あとは、電子ボリュームの値をどう保存し、表示を7セグLEDかLCDにするか、付加機能をどこまでつけるかなどの細かい仕様が残っているが、開発の峠は越したようだ。

ブレッドボードでは完成(11/20/2010)
　実際のケースに実装する前に、ブレッドボードにPGA2311を載せ、音源を先のLPCMプレーヤー（テスト用にブレッドボードに常駐）にして動作テストをした。7セグLEDはFPGAで使った基板を流用し、その2ヶ分をTiny2313につなぐ。ピンを全部使い切った。受信確認用のLEDはつけられない。まあ、これはデバッグ用のUARTをはずしたときにつけられる。

　そろそろフラッシュも一杯になってきた。ChaNさんの便利なxprintfはもう入らない。7セグLEDが動くまではUARTが欲しいので自前の十進変換ルーチンを使ってしのぐ。ブレッドボードなので配線はすぐ終わった。7セグの開発はあとまわしにして、まずPGA2311の動作を確認する。

　ありゃあ、動かない。データを送ると、「ポソポソ」という小さいノイズは聞こえるので信号がPGA2311まで行っているのは間違いないが、肝腎の音が出ない。ロジアナで見る限り、SPIは完全に仕様どおり音量データ(0～255のバイナリ)を両チャンネル分送っている。電源配線も間違いない。MUTEという音を止めるピンは負論理なので関係ないはずだ。念のためこれをpull upしてみるが当然何の変わりもない。

　困った。これ以上調べるところがない。やることがなくなって、さっきは動かなかったMUTEピンを最初からpull upして動かしてみた。何ということだ、これで動いたのである。MUTEは浮かせておくと動かないのだ。しかもSPIでデータを一回は送らないと音が出ない。それならそうとデータシートに、はっきり書いておいて欲しい。

　動いたときの気分はいつも爽快このうえない。ブレッドボードではあるがリモコンで自由に音量が変えられる。暫く音を上下させて遊ぶ。ご満悦である。音の変化は、PCのスピーカー程度では全くわからない。音量変化のときのノイズも全くない。好調である。

　勢いに乗って7セグLEDと音量値のEEPROMへの記録機能（5回ごとに値が異なれば記録する）を一気に書き上げる。良かった。フラッシュ消費は全部で1700バイトどまりだ。UARTを入れてもフラッシュにまだ余裕がある。

　これらの機能も一部を除いて順調に動いた。一時不調だったのは7セグLEDである。FPGAのときのトランジスタアレイを使った7セグLED基板を流用したのだが、どうもLEDが薄くピンによって明るさが違う。色々調べた結果、トランジスタアレイのドライブには適切なプルアップ抵抗が必要なことがわかった。10KではAVRのピンのドライブが不足（プルアップされすぎて点灯しっぱなし）で、47Kにするとちょうど良くなった。意外に微妙なものである。

　このところソフトを公開していないので、今回のブレッドボードで動いている赤外線リモコンのテストベンチのソースコードを公開することにする。ソフトSPIとバッファードUART（送信割り込みを使って高速出力が可能）のライブラリ、それに7セグLEDの表示コードが入っている。

　回路図はまだ試作中なので完成してから公開することにする。おおよその結線はソースコードにコメントがある。それぞれの部品の標準接続で特に問題なく動いている。

　UARTの部分は実装では不要だが、高速送信の出来るUARTは他に有用だと思うのであえてUARTを残した。何かの開発の参考になると嬉しい。現在のソフトでは、UARTに赤外線リモコン（Sony限定）の送信コードを行単位に出力し、キーボードから音量の上下の指示と音量値の表示が出来る。

ここに例によってAVRSｔudioのプロジェクトフォルダーとして固めたソースを置きます。時間がなく乱雑なコードになっていることはご容赦ください。uart2313.cとUART2313.hが目玉です。2313だけでなく標準UARTを持つAVRチップで殆ど共通に使えます。

11/22に公開したバージョンにはEEPROM関連にバグがありました（最初の書き込みのときボリュームが最大になってしまう）。以前のバージョンをダウンロードした方は破棄し、以下の修正版をダウンロードし直してください。

「Rcon2313_1126.zip」をダウンロード

CQ-STARM基板のCPU換装とDE0の到着

チップの換装で肝を冷やす(11/2/2010)
　今年2月から始めたフォトフレームプロジェクトは最終段階に入った。JPEG画像ファイルをデコードする機能の開発である(第8ステップ)。このほかに液晶モニターにFPGA基板とプロセッサー基板を取り付ける工作(第9ステップ)が残っているが、これはそう大した話ではない。こちらのほうが難易度が高い。

　まず、プラットホームを整えなければいけない。前記事にあるように、現在のCQ-STARM基板の石、STM32F103VBT6は、フラッシュは128KBあるが、SRAMが20KBで、JPEGファイルをデコードするためには、SRAMの容量(24KB以上必要）が足らない。

　手持ちの石にこのあいだXilinxのFPGAチップと一緒に買った、フラッシュ512KB、SRAM 64KBのSTM32F103VET6があるが、今問題なく動いている基板のチップをはがすのはどうも抵抗があってすぐには踏み切れなかった。

　しかし、このままVET6を残していても、この先何か使うあてがあるわけではない。暫く悩んでいたが、思い切って換装することにした。

　定番のサンハヤトの低温ハンダを取り出す。この前のFPGAのときと同じようにチップの裏面にフラックスが固着していて、とりはずしは少し難渋した。ハンダは溶けているのにチップがずれてくれない。ずらすのではなくピンセットの先端を隅に差し込み、少しこじるように浮かすと、きれいにはがれた。

　ハンダ吸い取り線で念入りに低温ハンダを除去し、クリーナーで基板を綺麗にする。何回目かの0.5ミリピッチICのハンダ付けである。大分慣れてきてこの前のようにピンの微調整もなくぴったりハンダ付けが出来た。うーむだいぶ腕が上がったぞ（しかし、これが落とし穴だった）。

　何も入っていない新品のCPUチップの動作テストは、JTAGのOpenOCDのコマンドである。通電する。全く反応はない。用心のためすぐ電源を切る。

　うわあ、この間とりかえたばかりのレギュレータ(LDS3985)が火傷しそうに熱い。ショートだ。こういうときに限って、ショートチェックを怠っている。良かった、電源をすぐ切って。いや、駄目になったかもしれない。どきどきしてきた。まあ、これはいずれわかる。壊したとしてもレギュレーターだけだろう。

　基板を点検する。見たところ、ハンダブリッジもない。きれいなもんだ。しかし、テスターで測ると、しっかり0オーム。やれやれ。ピンコンパチなので疑うのはハンダ付けしかない。どこかでショートしている。なおもルーペで目検。

　ありました、ありました。STM32の電源は、VddとVssが４隅に隣接して配置されている。その一箇所のパッドのピン位置より奥のところで波しぶきのように細くハンダが浮いて付いているところを発見した。（写真にとろうと思ったが微小すぎて撮れなかった）

　こういうこともあるんだ。恐らくフラックスで流動化したハンダが飛び散って空中で握手をしたようだ。半田ごてをあてれば苦もなくなくなった。テスターで測る。大丈夫。ショートはやっぱりここだった。

それこそ、祈る気持ちで通電する。OpenOCDを動かす。良かったあー、動いているぞ。

JTAG tap: stm32.cpu tap/device found: 0x3ba00477 (Manufacturer: 0x23b, Part: 0xba00, Version: 0x3)
JTAG Tap/device matched
JTAG tap: stm32.bs tap/device found: 0x06414041 (Manufacturer: 0x020, Part: 0x6414, Version: 0x0)
JTAG tap: stm32.bs             got: 0x06414041 (mfg: 0x020, part: 0x6414, ver: 0x0)

JTAGはこの石を認識した。レギュレーターは壊れていなかった。
コマンドを入れる。

> flash probe 0
device id = 0x10016414
flash size = 512kbytes
flash 'stm32x' found at 0x08000000

　よーし、フラッシュ512KBも認めた。これでSTM32103VET6のハードは動いている。電圧を測る。3.29V。問題ない。

　ほっと胸を撫で下ろす。それにしても、レギュレーターひとつでこんな波乱万丈の気分が味わえるのを喜ぶべきなのか、情けないと思うべきなのか。たかが、￥100程度の石なのだが、生きとし生けるものを無駄にすることは、どんなものでも心が深く傷付いてしまう（単にケチなだけかも）。

「ねむい」さんの尽力でVE6が動かない問題は解決した(11/3/2010)
　次は、ソフトだ。当面、DFUを入れてとりあえずは前の石の状態にもどすことにする。以前お世話になった「ねむい」さんのサイトから頂いたDFUのプロジェクトのソース一式をEclipseにインストールする。これはVB6用なので、これをVE6用に変えなければならない。　　

　詳しく調べると、MakefileでCPUなどを定義する環境変数を換えれば、ソース内の細かいコードはすべて、それにならって変わるようなので、変数のMedium Density(VB6など)の定義をHigh Density（VE6など）に切り替える。ビルドは特に問題なくOKとなった。

　この前、不調だったフラッシュローダーを動かしてみるが、相変わらず動かない。次の手段、OpenOCDを立ち上げJTAGモードに入る。TelnetからOCDのコマンド、

flash write_image erase ../main.bin 0x08000000 bin
　
でDFUのbinファイルを素直に書き込む。よーし書けた。順調だ。これでPCからDFUSeを動かせば、USBを通してこのボードをPCが認識するはずだ。

　あれえ、音沙汰がない。PCのデバイスマネージャーを見てみると、USBの不明なディバイスのアイコンは出るが、肝心のDFUSeの反応がない。さて、どこが悪いのだろう。

　32ビットマシンのスタートアップまわりの、この種のトラブルシューティングは、ちょっとまだ手が出ない。何から調べれば良いのかもわからない。しかし、この「ねむい」さんが提供してくれたDFUは前のVB6のチップのときは、何の問題なく動いていた。フラッシュが128Kから512Kに増えたからといって、フラッシュの開始アドレスが動いたわけでもない。普通なら何もしなくても動くはずだ。試しにVB6用のオリジナルのbinファイルを入れてみたが、これも動かなかった。やっぱり何かは換えないといけないようだ。

　とりあえずはご当人にそれとなく聞いてみよう。勝手にいじっておいて動かないと言うのも気が引けるが、このところご無沙汰しているし、「ねむい」さんのブログに挨拶代わりに遠慮がちにコメントを出してみた。JPEGでもあわよくばお世話になりたい下心もある。

　すると、次の日、詳しく調べたいのでソースを送って欲しいというレスポンスが帰ってきた。お言葉に甘えて、すぐソースコードを送ると、また2日もしないうちに、詳細な修正手順が送られてきた。いやいやありがたい話である。

　それによると、103VE6に換えるときに、103VB6_EVALという基板の設定変数を一緒に103VE6_EVALに換えているが、これがどうもまずいようだ。考えてみたら当然である。このCQ-STARM基板はもともとVB6用の基板であり、これにVE6が載るとは想定していない。VE6_EVALという評価ボードは物理的にこのボードとは別にあるのだ。その証拠に、VB6ボードにはない、NORメモリの初期化までやっている。これだ。これだ。

VE6が動いた。JPEGライブラリの準備OK(11/6/2010)
　謎が解けた。このMakefileにはチップによって換わる変数は3つあって、ひとつはCPUのモデルを決める、　　　　　      SUBMODEL　= STM32F103VET6(VBT6)
と、メモリサイズを決める　　   MPU_DENSITY = STM32F10X_HD(MD)
それに、評価ボードの定義　　EVAL_BOARD = USE_STM3210E_EVAL(10B_EVAL)　
                                                                                              (カッコ内はVB用)
があるが、このうち一番下の変数をはずして（元のVBに戻す）ビルドし直す。

　JTAGで書き込む。USBの設定が少し複雑（ハブの電源を切らないとコードを抜いただけでは初期化しにいかない）で少し手間取ったが、無事、DFUSeが石を認識した。試しにLEDブリンクのテストプログラムをDFUSeで書き込む。順調に書けた。リセットし直すとLEDが点滅した。よーし、動いたようだぞ。

　次は、前のフォトフレームの本番プログラムだ。ついでにロングファイルネーム(LFN)の対応を止める。何とフラッシュサイズは、89KBから20KBに激減した。

　新しいDFUSeで書き込む。おおお、FatFSが動いた。ファイルをFPGAに送り込み、前の画像が出た。久しぶりの画像である。いとおしく眺める。これでJPEGファイルデコードの準備は整った。「ねむい」さんには感謝、感謝である。さらに、メールのやりとりの間にあと２つ贈り物をもらった。本当にありがとうございました。

(1)STMフラッシュローダーのフリー版を教えてもらったhttp://www.mcuisp.com/　のmcuisp.exeである。始め漢字が全面に出て思わずたじろいだが、英語の翻訳ページがあり、ダウンロードできた。動かしてみた。こいつはすごい。これまで散々手こずってきた純正のフラッシュローダーの機嫌の悪さに較べれば、圧倒的に安定してチップに書くことが出来る。メッセージも豊富で動かしていて安心感がある。サイトの情報によるとARMだけでなくAVRやPICにも使えるようだ。これは良いものを教えてもらった。

(2)どうしても動かなかったHex2DFUが動いた
　Makefileに定義してあって、hexやbinファイルを作る手順に上記フリーソフトが動くように設定してあったのだが、これまでどうしても動かなかった。スペースの入ったディレクトリのパスは受け付けないということを教えられ、これを別のところへ持って行ったらあっさり動いた。他のディレクトリパスは"Program Files"などを受け付けていたので、まさかと思っていた。これでHexファイルからDFUファイルに変換する手間が省けて、DFUでの開発が楽になる。

DE0を発注してしまった（11/5/2010）
　すんさんの掲示板にも書いたけれど、遂にALTERAのFPGA評価ボードDE0をDigiKeyに発注してしまった。この評価ボードは、Altera CycloneⅢに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ライブラリを入れてフォトフレームを完成させなければ。

フォトフレーム： SRAMを増設して15ビットカラーに

　雑誌(デジタルデザインテクノロジー誌2009年1号)の付録基板Lattice 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の増設にまずとりかかった。

　メモリ増設は色々なところで紹介されているように簡略なSRAMチップの2階建て(Piggy Back)方式で実装することにする。同じアドレス、データ線を使い、アドレス最高ビットでOE（OutPut Enable）を用いてバンク切り替え（OEの意味が始めて分かった）する。OEとWEを独立させて制御すれば、簡単に動くはずだ。

　SRAMの変換基板を重ねるため、最初ピンヘッダーで重ねようと、ローハイトのピンヘッダーを準備して、一方のピンが変換基板の穴に入るよう細く削りだした。しかし、全部の削りだしが終わる頃、SRAMがFPGA基板のソケットの下に半田付けしてあったことに気が付く。しまった。ピンヘッダー経由では高さがあってFPGA基板の下側にはいらない。

　仕方がないので、強引だが0.5ミリ錫メッキ線を一本づつピンポストに立てて半田付けし密着させることにする。始めてこずったが、写真のように一旦テープで線を揃え、基板の穴を通して一度に半田付けするとうまく行くことがわかった。

　2階建てが終わった。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のビデオバッファーが実現した。今度のミスは配線間違いとハンダ付け不良というハードミスが２つ、ソフトのうっかりミスが一つ、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換装か。それとも別の基板を買ってくるか。