https://www.linusakesson.net/scene/kaleidoscopico/index.php

すげええええええええええ

PicoからVGAケーブルの信号を作ったって感じか。

周波数は抵抗の値で調整している感じかな。

今日もTab5のプログラムを書いてた。

なんでI2Cがうまくいかんのよと確認してたら・・・動作がやけに遅い。想定とは違う変数にフラグ立てたりしてる可能性が高い。

どこだろうと確認してみたら・・・あった、初期化命令だ（汗

つまり、初期化命令で値をもたせたところ、格納場所がまるごとズレた値になっている可能性がとっても高い。

しかもこのライブラリはESP32公式のライブラリであるみたい。Arduinoであれば結構な人数に使われて既に枯れてるはずなのに・・・と思ったりした。

以前からこういうのがあった様子。

https://www.mgo-tec.com/blog-entry-problem-i2c-0628-arduino-esp32.html

前からこういう状況みたいね。今もだよ（ﾋﾞｷﾋﾞｷ

https://wakwak-koba.hatenadiary.jp/entry/20171228/p1

下記で記載されてるやり方だとエラーが出る。根の深い問題ぽい。（ESP32P4独自の問題だろか）

https://qiita.com/infinite1oop/items/63722503f60a4bdd0d0c

ピンの番号も分かっているので、それであれば自分で関数作ったほうがいいのではと思った。

https://ysin1128.hatenablog.com/entry/2020/06/04/161528

ちなみにこの状態でも動きはおかしい。アドレスをスキャンすると結果が安定しない。なんだこれは・・・

ただこっちはどうもデバイスのせいな模様。どうなってだｎ・・・

追加で届いたデバイスを確認してみたところこちらは問題なし。つまり購入した物品がくs（ry

今日の成果。I2Cのテスト、I2Cのスキャナ。I2C関数の移植・再実装。

ちなみに、11日は大量描画テスト、ノイズテスト。

12日はアイコン描画、円の大量描画、フィル円の大量描画。

高速化について。

どうも画面？のキャッシュヒットの関係で縦画面のほうが描画が早いケースがあるみたいだけど、それは大きな画像を画面に描画するとき限定らしい。

実際すごい小さい矩形を表示していたら、横画面のほうが早い。

テキストも一緒に描画しているので折り返し頻度が多いケースだと影響あるのかもしれない。

ベンチマークしてみるのは必要と考える。