16.JPEGデコーダのDMA対応機能を有効化してマルチコア対応
それよりもデコードに 100ms かかるのを何とかしないと
内訳はデコード＋データをLCDCに転送を合わせて 100ms という内訳。framebufferにデコードしてたときは60msだったんでかなり遅い。
JPEGの最小単位(MCU)ごとに転送してるオーバーヘッドだと思い込んでたけど、LCDCへの転送にDMAを使ってるのにDMA転送完了するまで待機してた。DMAの意味ないじゃん。
DMAの完了を待たずに次のMCUのデコードに進めば時間を節約できる。そうなるとダブルバッファに改造しないとならないが、ダブルバッファにするとメモリコピーが入るから性能落ちるけど。。。
と思いつつソースを読むと、使ってるJPEGデコーダ自体でDMA対応していた。
あ～なるほど。Framebufferにバグがあっても誰も困ってないのは不思議だったが、そういうことか。かんぺきに理解した。
ということでDMA対応はJPEGデコーダの初期化でオプション設定するだけで解決。50ms 程度まで改善したので320x180で 8fps までギリいける。pico+LCDでやったときは120x68で12fpsだったのでpico2って速いね。
性能的には満足だけど予告したのでマルチコア対応してみた。処理を前処理、デコード、後処理に分割して、デコードをcore1で動かすだけ。
と思ったが、デコード終了を検出する処理で苦戦。大域変数にフラグを用意して、フラグをチェックする無限ループを組んだんだが、ループから全く抜けない。
理由は最近のコンパイラの最適化が優秀すぎたこと。
ファイル内部だけで使ってるチェック関数とフラグ変数なので習慣としてstatic を付けてた。static を付けるとファイル外部での参照が無いという宣言だから、ビジーチェックのループ内では変化しないハズなので、ループから抜けない。
ちょっとコンパイラさん、頭良すぎませんか？
static を外して、フラグ変数に volatile つけて何とか解決。
最終的にはSDからの読み込み 60ms ぐらいだけで済むようになったので 320x180 で12fps まで楽勝。
でも連続再生してると落ちる。何が悪いんだろう。
それはそれとして、画像サイズが 320x240 のサイズを超えないのが前提のコードなので、その辺に対応できるヘルパー関数用意してから github に投げたい。
