(日々の記録)デジタルオシロを買った。XP2基板と、これも雑誌付録のARMプロセッサーSTM32基板(CQ-STARM、但しCPUをSTM32F103VE6に換装)を組み合わせたデジタルフォトフレームプロジェクトは、JPEGファイルの画像描画に成功して、いよいよ最終ゴールである液晶モニターにFPGA基板やCPU基板を実装する段階に入った(第9ステップ、2010/3/11記事参照)。Access)がどうにも言うことを聞かない。CPUでSPIを動かすのと余り性能的に変らないようなのでこだわることはないのだが意地になっている。STM32のDMA転送がうまくいかない(1/12/2011)フォトフレームの現状は、JPEGの画像は何とか出たが、画は逆さまだし、DMAを使ってSPIを動かすと同期のずれた縞模様しか出力しない。おかしなことにDMAを使ったほうが何故か時間がかかる(2.2秒以上)。DMAを使わずにSPIをCPUを使って素直に書き出しても、BMPファイル(2.2秒)より早く(1.7秒)、画像が出せたので、もうこのままでも良いのだが、プロセッサーが本来持っている折角の機能を使わずにおくのは、ソフトウエア開発の元プロとしては寝覚めが悪い。やりだしたことを途中で投げ出すのは、負けず嫌い、へそ曲がりの所長としては断じて避けたいところである。BMPファイルよりJPEGファイルの方が早いのは、ファイルサイズが1/4以下になっているのでデコードのCPU処理が増えても全体としては早くなったからである。これにSPIをDMA転送にすれば、SPIを動かしながら、CPUはJPEGデコードに専念することができるので、今よりさらに早く転送が出来るはずだ。これを活用しない手はない。なんとしてもDMAを動かしておきたい。これが言うことを聞かないのである。JPEGがデコードしたビットマップのデータをDMAを使わずそのままSPIで出す画像は、きれいに出力されるのに、一行分のバッファーにそれを移してDMAを通してSPIで送ったものは同期がずれたような縞模様の画像で、全く画にならない。DMAがおかしいことは明白である。マニュアルをみるとバッファーサイズはバイト数ではなくデータカウント数で、16ビットフレームだから半分にしないといけないはずだが、そうすると画面にデータが送れていないところが残る。元へ戻すと全部描かれるが、どちらも化け化けの映像である。それにしても謎である。サイズを半分にしたら画面の半分のところで止まる筈なのだが、4/5のあたりで止まっている。例によって、16ビット画像の位置を逆にしたら(リトルエンディアン)少し原画らしいものが見えてきたが4つぐらいが重複した縞だらけの画像になる。DMAはCPUを経ない転送なので外から様子を調べることが難しい。DMAアクセスと実際のバッファーへの移動がかぶらないように、DMA転送の終了フラグを見るようにしているが、タイマーで測っても数msしか待っておらず、どうもおかしい。1ラインごとにDMAを動かしているので計算上では480ラインでは数百ms待たないとおかしい。それに、サンプルのソースコードはDMA転送の度に、DMAのDeinit(全ての設定値のクリア)から延々と初期化をしている。これがDMAが遅い原因なのか(CPU内の処理なのでそんなわけはないのだが)と、初期化と開始の関数を、わけて動かしてみるが、ENABLEコマンドだけではDMAは全く動かない。Deinitから始まるプロセスでないとDMAは動かない。ことでDMAが動いた(1/15/2011)3日間悩んでいた。勉強しないと駄目なようだ。プロセッサーのリファレンスマニュアル(RM0008)をダウンロードしてDMAのところを本格的に調べ始めた。disabled.)というのを発見した。いやあ、こんなところに大事なことが隠れていた。これが転送の度に初期化ルーチンを動かしている理由なのか。DMA開始関数に、ENABLEの前に、DMA_cmd(DMA1,DISABLE)を入れてみると、やっとDMAが動き出した。画像が改善されるわけではない。画像の化ける原因がつかめない。ロジックアナライザーでデータをひとつひとつ調べるしかないのか。考えられるのは1行の転送が終わらないうちに次の転送が始まってデータをこわしている可能性である。転送終了フラグは初期化のときにクリアされているはずで、次のDMA転送に行くのにはこのフラグが立つのを待っているが、どうもこのあたりが動いていないような気がしてきた。転送終了を待つ時間が少ないというのも気になる(ただし0ではない)。DMA開始関数のところに、転送完了フラグをクリアする関数、DMA_ClearFlag(DMA1_FLAG_TC5)を入れてテストしてみる。うーむ、前より少し画像らしくなったが、まだ化けている。画像は縦に拡大され、一部しか出ていない。あ、あ、あ、わかったぞ。データサイズはバイト数ではなく、データ数だ。今までは、1行当たりに2倍のデータを送っていたのだ(画像が縦に拡大される)。DMAに時間がかかっていたのも2倍のデータ転送をしていたからだ。転送終了を待っている時間が0でなかったのは、最初の1行の時だけの待ち時間だ。すべてのこれまでの現象がこれを裏づける。あせる手で、ソースを修正する。終わるのが待ち遠しい。