12.jpegデコーダを動かすとメモリ破壊をやらかす（原因は分かったが...）
SDカードもスピードが出るようになって本格的に動かそうと、複数のjpegデータをtarでまとめて連続描画
おや？時々フレームをスキップしてる感じがする 処理が追い付かなくてもスキップする仕様じゃないんだが？
デバッグしてみたら jpegデコードがエラーになってる
詳細エラーコードが出てこないからデコーダを修正して内容を見ると、デコードエラーを起こし、次の数フレームが異常ファイルのエラーになり、その後正常データに戻っている
これはSDカードの読み取りに失敗してるか？
SDカードの高速化改造が悪さをしてるのを想定してボーレートを標準に変えたが現象変わらない
別のSDカードに交換しても現象変わらない
じゃぁ jpeg デコーダがメモリ破壊やらかしてるのか？今まで問題なく動いていたのに調査キツイなぁ。
とりあえず壊れた画像データをダンプしてみると、最初のエラー時は12バイト目以降が０。連続エラー時はすべてが０になっている。解せん。
再現性はあるので、読み込んだ直後のデータを確認すると正常だった。ということはデコーダを呼び出した直後に破壊しているっぽい。キツイ。だれがやってるかわからないメモリ書き込みって、一番厄介な破壊パターンだし。
少しずつ処理を切り離してみることにして、デコード処理を外してJPEG情報を取得するだけにしたが異常。はて？呼び出しただけで壊してる？
JPEG情報を取得する直前の処理って、BSS領域の初期化の０クリアぐらいだが…
0クリア？そ～いやデータ破壊パターンは０なんだが、いや、まさか。
念のため、バッファのアドレスを全部表示してみたら、デコーダが確保してるBSS領域に対して、micropythonが read用のバッファを割り当ててる
readで読み取った画像データに対して、デコーダの初期化処理で０クリアしてるんじゃプログラム見てもわからないよなぁ。
メモリのダブルブッキングなんてmicropython本体のやらかしまで面倒見切れんぞ
バグレポートだすしかないかなぁ。と単純に巨大なBSS領域を確保するモジュールを作ったが、こっちは正常。TEXT領域も巨大な場合だけ発生するのかねぇ？内部処理では実は32kBが上限とか？
かといって、どこで処理してるかわからない micropythonのソース本体を読むのは無理ゲー
コードを追っててとんでもないものをみつけてしまった どうしよう ．．．
このデコーダはmicropython内部モジュールとして組み込んでた処理を外にだして、改造を楽にするためのテスト品だったので、元に戻せばいいだけなんだがね。
