フォトフレーム： ケースの実装とI2CフラッシュROM

　恒例の北海道のスキー合宿があって、ほぼ1週間、電子工作から遠ざかっていた。以下は出かける前に書いてあった記録のまとめである。

「STM32マイコン徹底入門」を購入(1/21/2011)
　どうしようか迷っていたが、たまたま図書券を貰ったので仕事の帰りに買ってしまった(￥2310)。著者は何と専門家ではない、IT関係の弁護士さん（ブログがある）が書いたSTM32プロセッサーの入門書である。

　良く出来ている。専門家でないので説明の仕方が独特である。コラムには、今さら聞けない電子技術の基本的なノウハウの紹介がある。とてもためになる。

　所長が、これまでウェブの情報を手がかりに、あーでもない、こーでもないと試行錯誤して何とか動かしてきたペリフェラルの解説が丁寧で詳しい。もう少し早めに出版されていたら、これを読んであんなに苦労しなかったなあと思うところが沢山ある。

　そういった意味では、STM32をまともに動かそうとしている人にとっては大変おすすめの本だ。しかし、入門書という位置づけとなると少し苦しいところがある。そもそも32ビットプロセッサーを入門のプラットホームにするところに無理があるようだ。

　本当のマイコンの入門というのならやはり8ビットプロセッサーから始めるのが一番だろう。データのハンドリングは8ビットが基本でわかりやすいし、タイマーやポートの設定は簡単で初心者にも直感的に理解し易い。最近はCPUチップのフラッシュの量も増えてきたのでソフトの開発はC言語でサイズを気にしないで自由に書ける。

　それに対してSTM32などの32ビットプロセッサーのペリフェラルの設定は半端な量ではない。おまじないのようなスタートアップルーチンを始め、割り込み環境は猛烈に複雑だ。この本の程度の解説では予備知識なしには全く先に進めないだろう。初心者は記事のあとを辿るだけならできるが、この本だけで自分の思い通りにプロセッサーを自由に動かすところまでは残念ながら不可能に近いと思う。

　32ビットに必要なのは、Ardiunoに代表されるような簡易なOS（またはモニター）が組み込まれた開発環境だ。簡単なコーディングで色々なペリフェラルが自由に使えれば言うことはない（mbedがそれに近いのかも）。普通の人にとっては、LEDがついたり消えたり、モーターの速度が制御できたりすれば良いので、中のPWMなどのレジスターの動きはどうでも良い。

　非力な8ビットマシンには、オーバーヘッドによる性能低下が心配な開発環境が用意され、性能に何の問題ない32ビットには、そういう便利なものがないという矛盾したことになっている。著者に責任があるわけではないが、何か状況が逆さまになっているような気がしてならない。

フォトフレームの第9ステップ、実装(1/22/2011)
　雑誌付録のFPGA XP2基板とARMプロセッサー基板（CQ-STARM、但しCPUはSTM32F103VEに換装）を使ったフォトフレームプロジェクトは大詰めを迎えた。基板の実装である。いかにも素人工作だが、裏蓋にビス穴を空けて基板をそこに固定することにする。ケースの中に入れるのは少し無理だ。

　そもそも、このケースは、以前買った中古(パチンコ)アナログ液晶のタバコのヤニで色の付いたジャンク品だが、思ったよりしっかりしているので、スイッチをつけたりスタンドをつけたりしてみた。本式には、もう少しまともなケースに入れるべきだろうが無精している。

　電源は、この間、秋月で手に入れた更に強力な5V 3AのDCアダプター(￥750)にした。これだけ余裕があると殆ど熱を持たない。DC-DCコンバーターも快調だ。これで十分である。第9ステップの工作は、電源ケーブルをFPGA基板とARM基板に振り分け、基板の四隅の固定穴（それもさぼって半分づつの4ヶしか空けない）にセパレーターを経由してケースに固定するだけであっけなく終了した。これでハード的には完成である。

　問題はソフトの改修だ。現在のソフトはありあわせのものなので、UARTをつないで端末からコマンドでJPEGファイルを指定しないと表示されない。これではスタンドアロンのフォトフレームにならない。少なくとも、フォトフレームは電源を入れるだけで、画像が次々に映し出されるスライドショー機能が動かないと話にならない。

　とはいえ、ソフト開発の前の段階、全体の仕様が中々決まらない。ファイル名を表示するLCDなどが必要かどうかで迷う。タクトスイッチだけにするか。LEDくらいはつけたほうがわかり易いかもしれない。このへんを決めずに気ままに開発していくやりかたもあるが、明らかに効率は悪い。

　BMP画像ファイルの表示は、色々考えたが、難しいので結局やめることにする。BMPファイルの画像分のバッファーがなければ逆さまから転送することは出来ないし、液晶モニターの制御信号で換えるのは、FPGAに画像データ以外のインテリジェントな機能を持たせる必要があり、大掛かりな変更が必要でしかも美しくない（STM32から別の制御線を引けばできるけれど）。

　実用的なフォトフレームとしては、他にも不満なところが多い。まず、画像の切り替えに2秒近くを要し、そのあいだ画面が消えてしまう。JPEGも4：3の比率以外の画像は表示できないし、この比率でも表示できないJPEGファイルがある（800x600 1600x1200など)

　みんな何とかしようと思えば出来ないものではないが、まあ、試作品としては、この程度で良いだろう。元はといえば、FPGAの勉強のための習作として企画したプロジェクトだ。これだけ動いただけでも上出来と思わなければならない。

秋月電子で1MHzの早いI2C EEPROMを調達してきた(1/24/2011)
　とはいえ、スライドショーでいつもSDカードの最初のJPEGファイルから表示されるのはつまらない。この前のリニアPCMプレーヤーのように、前の表示を記憶しておいてSDカード単位に頭出しをするようにしたり、任意のファイルから開始するランダム表示機能くらいは欲しいところだ。それには不揮発メモリが必要だが、STM32にはAVRのようにEEPROMはついていない。

　フラッシュメモリなら、Lattice XP2基板のためにSPI接続のフラッシュROM（EEPROM)、M25P40（512KB)を余分に買ってあるが、こんなに多量のメモリは必要ない。STM32用のフラッシュROMとしては、だいぶ前に千石電商でROHMの2KBのもの（BR24-S16  ￥100)を買ってあった。SPIインターフェースは、SDカードやFPGAで使っているので、このフラッシュのインターフェースは勉強の意味をこめてI2Cである。

　STM32でI2Cを使う機会が出来た。千石ではデータシートを別売りしているが買わなかった。最近は、ウェブでもっと詳細なデータシートが簡単に手に入る。今度もウェブから適当なデータシートを落としてアクセス法を勉強し始めた。

　ところがウェブを探しているうち秋月で、RHOMよりもっと安くて、早いI2CのフラッシュROMを売っているのを見つけた。MicroChip社の24FC256(￥90)である。こちらのほうが安くてメモリ量16倍。しかも早い（1MHzで動く）。早速手に入れる。秋月電子の安さを実感する。繁盛して店が混雑するわけである。

　I2Cフラッシュのアクセスは、アドレスの設定が少し違うくらいで、どのメーカーもほとんど同じである。共通のアクセス手段で読み書きができそうだ。気をつけなければならないのは、どのROMも複数データをページをまたがって連続してアクセスできないことで、読み書きはページ単位でしかできない。

　1バイト単位なら問題ないが、複数データのアクセスのユーザーインターフェースをどうすれば良いかあれこれ考える。このあたりは参考情報が少ない。3年前にAVRのEEPROMで開発したUNIXの標準入出力的な考え方が一番素直だが、今度のアプリケーション（ファイル情報の記録）は配列操作なのであまり合わないようにも思える。

　まあ、I2Cは、これまで色々開発してきているので、そう不安はないが、連続データの送受信のインターフェースはなかなか難しい。しかし今度のアプリケーションでは速度を期待されているわけでもない。一度に送れるといっても1ページ(BR24-S16で16バイト、サイズによって異なる)単位でしか送れない。しかも送った後は5ms以上待たされる。遅くはなるが、1バイト単位の転送で全部を組み立てる方法が一番楽そうだ。

　全体のソフトの構成はこのあいだのLPCMプレーヤーの考え方がそっくりスライドショーのつくりに適用できそうだ。ただランダムに画像を選ぶテクニックは新しく考える必要がある。ファイル数の制限はしたくないが、ランダムにするには最大数がいる。まあ、256葉（枚）を最大にしておけば良いか。

ヘッダーファイルにソースコードが入っている(1/27/2011)
　おおよその方針が決まったので、これまで、間借りするように組み込んでいたフォトフレームのソースコードを、少しづつまとめて一本にしはじめた。STM32のソースコードだけは公開しようと思っているので、もうちょっと見易くしておきたい。これだって人のソースに手を入れただけで気が引けるのだが、FPGAの方は、オリジナルといえども、ちょっと今のところ公開できる自信がない。

　FPGAの方は回路図も作っていないし、VerilogHDLのソースもつぎはぎだらけである。何とか動いているが、たまに画像の抽出をはずして白エッジが見える不具合が解決されていない。これが発表をためらっている一番大きな理由だが、コード自体が書き散らしである。12ビットRGBから15ビットに改修した跡地や、UARTでモニターらしいものを作ろうとしたときの残骸などがいたるところに残されており、とても公開できるレベルではない。

　STM32の方は少し手を入れれば、何かの参考にはなるだろう。ただオリジナルのソースコードはRTC(Real Timer Clock)や、UARTのテストルーチンが入ったままで、整理に気を使う。

　SysTickのあたりが勉強できたのが収穫だった。Eclipseの検索機能が強力なので、ソースの解析（探検）はとても楽だ。変数や関数のところにカーソルをあててファンクションキーを押すと、定義しているファイルに飛んでくれる。

　ところが、SystickConfigというシステムの基本関数が見当たらなくて苦労した。何と、ヘッダーファイルでソースコードを見つけた。やれやれ、変なところにソースを入れるものだから時間の無駄をしてしまった（ヘッダーファイルにソースを入れないというのは鉄則なのだが、インライン関数は例外らしい）。

スライドショーの基本機能は完成(1/29/2011)
　恒例の北海道スキー合宿（60代後半の元国体選手と一緒に新雪に挑戦する）を前に、フォトフレームプログラムのスライドショーの基本部分が動き始めた。この2日間は、久しぶりにコーディングに没頭していた。これでこのフォトフレームは、UARTなどをつながなくても電源を入れるだけでSDカードのJPEGファイルを連続して表示してくれる。

　テスト用のUARTの分離に手間取ったが、本来のスライドショーの部分は、systickのタイマーが使いやすく、組み上げて動かしたら一発で動いた。全くデバッグなし。気分が良い。

　このChaNさんのFatFSをARMに移植したMartin Thomasさんのソースコードは、いろいろなしかけがあって面白いが、改修するのは最初難儀した。リエントラントと書いてあるのでソースを一生懸命追ったが、どこにもリエントラントなタスクは起きない構造になっている。

　普通、リエントラントと言うと、ユーザーから次々に仕事(マルチタスク)を受け取るイメージであり、LEDのブリンクや、RTCの表示などのコマンドをどうやってリエントラントしているのか、首を傾げていたのだが、ソースを調べていくうち、UARTがいつでも受信受付可能なことを単にリエントラントと言っているだけだということがわかり一気に改造が楽になった。

　夜半、ソフトが完成し嬉々としてフォトフレームを居間に持ち込んで家族に見せたが、反応なし。予想はしていたけれど、やっぱり落ち込む。この液晶、綺麗に見える角度が限られており、反射が多くて見難かったのかもしれないと一人慰める。

　ランダムな表示、スイッチによる自由な画像の選択などの機能は、スキー合宿が終わってから着手することにする。

　とにかくフォトフレームプロジェクトは、このあたりの開発をもって一段落させることにしよう。小手先の操作を便利にしてもあまり意味がない。基本的なVGA画像をもっと早く表示することの方が大事だ。となるとやっぱりDE0の出番だろうか。ただDE0をフォトフレームにしてしまうのはもったいない。