7. PSRAMディスクへのRAWアクセスを行った後データが化けまくる
性能も大分上がったので、いろんなパターンの性能も取ってみようと、ファイルシステムを経由せず、直接readblocks() で未使用の領域をテストしてみた。
ちゃんと読み書きはエラーにならず、性能もファイルシステム経由より速い。妥当だ。
と喜んだが、テストを実行した後、それ以降のアクセスで read データが異常な値になる。具体的には同じ値が連続する。333333とか"""""""とか
PSRAMが誤動作してんのかな？
と思って性能測定プログラム内でデータ確認すると、その時点でデータが化けてる。ダメじゃん。
色々試してみたがreadblocks() を実行した後にダメになるのは確定。原因がわからないと気持ち悪くて使えない。
しばらく悩んだがさっぱりわからないんで、放置することにした。
バグったソフトは時間を置くといいアイデアが出ることがあるし。
＜数日後＞
ドライバの構造を見直してて気が付いた。
PsramDevice というクラスを定義したドライバだが、PIOやDMAを使う部分はクラスで共通でアクセスしたいのでクラスメソッドにしていた。一方、ファイルシステムで使用するPSRAMのサイズを指定したいので __init__ の引数で指定した。
つまり、クラスメソッドとインスタンスメソッドが混在した作りになっている。
これだけなら良かったが、3.PIOのトラブルまみれ と同じことをやらかしてた。
__init__ の先頭でCSやCLK信号ピンの初期化をして、PSRAMのリセットなどの後、PIOとDMAの初期化をしていた。ファイルシステムとして使っている間は、これで問題ない。
ただ性能測定用にこのクラスをimport をして ps = psram_dma.PsramDevice() と別のインスタンスを作成したのがアウト。 __init__では CLK 信号ピンの初期化を行っているので、PIOの設定後にGPIOの初期化を行っていたことになる。
なるほど、CLK信号が出ていない状態でQSPIで 4bit の入力を繰り返してるから、全く同じデータが連続するわけだ。
原因がわかってすっきりしたし、初期化済みフラグをクラス変数に記憶すれば解決。
あとは、どこまでクロックを上げられるかを確認して、安心して使える数値を割り出す感じで。
