勇躍、コードを入れ替えテストする。よーし、何か画面がでたぞ。バッファーがずれているようで縞模様にしかならないが、やっとSPIがDMAで動いた。あとはデータの位置を直せば画面が出るだろう。それにしてもDMAは大変だ。JPEGで画像が出た(1/8/2011)DMAは動いたが、まともな画像が出てこない。JPEGライブラリが本当に画像をデコードしているのか確かめないことにはDMAが悪いのかどうかはわからない。DMAの開発を一時中断し、時間はかかるがSPIでJPEGデコードデータを検証することにした。JPEGは3バイトのフルカラービットマップで出てくる。これを16ビットRGBに変換してやる必要があるが、これはすでにBMPのところでやっている。それをそっくり持ち込んでJPEGをSPIで出すコードはすぐ出来た。おおお、確かに画像が出た。BMPとスキャンが逆なので(BMPは下から、JPEGは上から)、画像が天地さかさまで、画面上部が例のSRAMトラブルで乱れているが、きれいな画像データが表示されている。いやあ感激の一瞬である。FPGAを使ったフォトフレームプロジェクトは遂に、第8ステップをクリアした。ARMのJPEGルーチンがやっとのことで動いたのだ。いくつかJPEGファイルを入れてみる。1024×768のファイルも問題なく表示された。スケーリングもしている。それに何となくDMAを使って表示しているときより早いような気がする。DMAからはまだまともな画像にはなっていないが、こんなに早くはなかった。気になったので、DMAに戻して例の時間計測ルーチンをファイルの読み込みから画像を出すまでに入れなおして時間を測ってみた。何と何と、結果を見て驚いた。DMA経由より、SPI単独の方が早いのだ。3つのJPEGファイルでテストしているが、どのファイルもDMA転送では、2.1秒近辺なのに対し、DMAなしが1.7秒程度と、20%以上も早い。ついでにBMPファイルでの表示時間も測ってみる。これは2秒前後であった。何だとDMAの方が遅いじゃないか。JPEGが早いのは、読み込むファイルのサイズが1/4しかないことが大きな理由であろう。DMAが遅いわけは、まだ良くわからない。DMAルーチンは元のFatFSのコードを参考にしておりDMA転送の度に初期化をし(Deinit)、設定し直して動かしている。この時間が長くかかりすぎているのかもしれない(Deinitをはずすと動かない)。TC5からHT5にする2秒から1.7秒程度に縮まった。これでもSPIで送るシリアル処理と同じ程度だ。それにDMAはまだまともな画像が出ない。ソースコードはまだぐちゃぐちゃだし、BMPとJPEGの画像の天地の問題も解決されていないし、画像の上部には縞模様が出たまま(これはあとで接触不良が判明し解決した)で、問題山積というところだが、まあ、そうは言っても、フォトフレームプロジェクトは、第9ステップの実装を残すところまで来た。このあたりでブログに報告することにしよう。(追記:上記のDMAの問題は、すべてこちらのコーディングミスでした。