18.picocalcのmicropythonのgcがアカンやつ？
実は考え方が間違ってるっぽい
gcは正しく動いてる
jpegデコーダが満足いく仕上がりになったので、ロングランで検証しようとPCから外して動かした。すぐハングアップした。はぁ？なんでやねん。
さっきまで問題なく動いてたのに。。。と思ってPCにつないで動かしたら平然と動いてる。
もしかしてPCにつながない状態でデバッグ出力した状態で動かすとダメなのか？と print 文を消してロングランスタート。
今度は問題なく動いている。
ということは terminal ドライバが文字出力しようとするとハングアップするということですね？
ともあれ文字出力してる処理をもう一度おさらいしてみた。以前RGB565対応で改造したから見慣れたコード。
でも何度見てもframebufferに書き込んでるだけなんだよねぇ。
もしや、「12.jpegデコーダを動かすとメモリ破壊をやらかす（原因は分かったが...）」と同じ現象なのか？
以前 jpegデコーダが直接 framebuffer に書き込んでた頃に、framebufferのアドレスを取得できるように改造したpicodisplay を引っ張り出した。
そして実行時の framebuffer のアドレスとサイズを保存して表示。
print(type(screen.framebuffer))
pbuf = int(id(screen.framebuffer))
pbufsize = len(screen.framebuffer)
print("pbuf1=",hex(pbuf), " size=", pbufsize )
実行結果が
<class 'bytearray'>
pbuf1= 0x2001a5d0 size= 51200
うん、ちゃんとframebuffer が取れてる。
よし、実行時にアドレスチェック処理を入れて実行してみる。
pbuf1= 0x2001a5d0 size= 0xc800
pbuf2= 0x20018ed0 size= 0x1e00
あっという間に原因確定。readが確保したバッファがframebuffer の領域を使ってた。
しかし妙だ。screen.framebuffer でidやlenを取れるってことは、python的には使用中の変数なんだよね。
なのに gc が空き領域と判定してるっておかしいでしょ。つまりは gc がバグってる？
途中でメモリ不足エラーを起こすのが嫌なので再生前に gc.collect() で強制的にgcを動かしてたけど、これをコメントアウトしたらバッファはバッティングしなくなった。
と言いつつも、しばらく動かすと自動でgc が動いたタイミングでバッファがバッティングするから全然解決になってないんだが。
どうしたもんかなぁ。
ちなみに gc.disable() するとメモリ不足で落ちます。むむん。
追記
idで取ってきたアドレスはフレームバッファ実体じゃなかったのです
でも落ちるのは事実
悩む
