すごいです。まさか、ピコで動かすとは。
ここで説明されているように、かなり苦労しているようですが、音楽や効果音、テキストモード画面までサポートしており、機能的な出来上がりは完璧です。
なるほど、音楽部分はOPL2のエミュレーションソフトを使っているのですね。こういうのがあるとは知りませんでした。わたしも試してみようかな。
すごいです。まさか、ピコで動かすとは。
ここで説明されているように、かなり苦労しているようですが、音楽や効果音、テキストモード画面までサポートしており、機能的な出来上がりは完璧です。
なるほど、音楽部分はOPL2のエミュレーションソフトを使っているのですね。こういうのがあるとは知りませんでした。わたしも試してみようかな。
TIが出しているPython機能を持った電卓では、Python機能の実態としてATSAMD21E18が使われているという分解レポート。SAMD21は 3:50秒あたりで大写しになっています。
このチップAdafruitのQT Pyで使われているのと同一のM0 MCUなんですね。TIの電卓のクセしてMicrochip(ATMEL)のチップ使って、しかもUART接続で使っているという実態が明らかにされています。電卓も生き残りのための新鮮味を出すために必死というところでしょうか。
前記事でも述べたように、現在のDoom Playerでは内蔵メモリの大きなSTM32H7A3ですらメモリ不足になる場合があります。nrf-doom がやっているようにline_t 構造体を大幅に小さくするような工夫を凝らせば、動作に必要なメモリを減らすことはできますが、かなりのコード変更が必要となります。Doom Player ではゲーム本体のコードへの大幅な変更はできるだけやりたくなかったので、どうしてもメモリが必要であれば、シリアルPSRAMを増設して対処すれば良いということにしました。しかし、実際にシリアルPSRAMを使おうとすると一筋縄ではいかないことがわかったので、本記事ではシリアルPSRAMを使う上での問題点と、その対処法について書くことにします。実際に使っているのは、AP MemoryのAPS1604M-3SQRです。下の写真の左側がAPS1604M-3SQRで、右側はフラッシュのW25Q128JVになります。
シリアルPSRAMをSTM32H7A3に接続するためには、OCTOSPIを使います。その名前が示すように、8ビット幅のSPI接続をサポートします。しかしOCTOSPI対応のPSRAMを探すと、どのデバイスもBGAパッケージとなってしまい、ユニバーサル基板に手はんだで組み上げるスタイルがメインの自分には手におえません。そこで、4ビット幅のQSPI対応のPSRAMを使うことにします。フラッシュと同じように8ピンSOP変換基板で配線できるので、アマチュアにとってはとても手軽に使えます。
4ビット幅であれば、従来のSTM32F4/L4/F7/H7 MCUでもQSPIというペリフェラルが用意されていたのですが、OCTOSPIとQSPIにはビット幅以外にも大きな違いがひとつあります。それは、QSPIはSPIフラッシュを接続することを意図して用意されており、PSRAMには使えないということです。具体的には、メモリマップ動作での書き込みを全くサポートしていないのです。対して、OCTOSPIではメモリマップ動作での書き込みをサポートしているので、外部メモリとしてPSRAMを使うことができます。しかしながら、実際に使おうとすると、幾つもの障害が待ち受けていました。
DQS信号の設定
残念なことにOCTOSPIには幾つものエラッタが存在するのですが、その中でも "Memory-mapped write error response when DQS output is disabled". というエラッタに注目せねばなりません。DQS信号が禁止されていると、メモリマップモードでの書き込みができないという致命的な問題です。DQS信号を禁止するも何も、そもそも8ピンSOPパッケージのQSPI PSRAMの場合には、DQS信号そのものがありません。このタイトルだけ読むと、QSPI PSRAMを使うことはできず、DQS信号をサポートするOCTO SPIのPSRAMを使う必要があるように思えました。しかしながら、エラッタ本文をよく読むと、この問題には回避策があり、DQS信号の無いQSPI PSRAMを使う場合には、DQS信号を使う設定で使用し、実際の配線は不要であることがわかりました。
MPUの設定
DQS信号については、誤魔化して設定することで回避できることはわかりましたが、この回避策には制約があることも書かれています。AXIバス経由でのバイトアクセスでの書き込みが行われると、正しくバイトマスクが行われずに、余計なメモリまで書き変わってしまうという問題です。OCTOSPIは、AXIバスにつながっているインターフェースなので、バイトアクセスすれば必ずこの問題が発生してしまうことになります。具体的には、PSRAMの最初の1バイトだけ書き換えようとすると、後続する7バイトが0に書き変わってしまうという問題が発生します。この制約への対処策については、エラッタでは言及されていませんが、MPUを設定してPSRAMで使用するメモリ空間を "Strongly Ordered"に設定すれば良いことがわかりました。Normal Memoryではないので、キャッシュの効果が得られず、メモリアクセス性能は低下することになります。
ドライブ能力の設定
MPUの設定をすることで、任意のアドレスへの書き込み/読み出しが行えるようになったのですが、メモリパターンを変えながら書き込んでみると、時折ランダムにデータ化けが生じました。クロックを下げても現象に変化がないので悩みましたが、メモリ側のモードレジスタの設定を変更して、出力インピーダンスをディフォルトの50オームから100オームに変更したところ、問題を解消できました。何しろNucleoの上にユニバーサル基板を積んでいますので、どうしても配線長が長くなってしまうので、その影響があるのかもしれません。
OCTOSPI を使ったQSPI PSRAMの接続に関しては、AN5050においてもサンプルプログラムを含む言及があります。しかしながら、その内容は元々 STM34L4+向けに書かれたものであり、STM32H7で必要となるMPUの設定までは説明されていないので注意が必要です。もちろんSTのCommunityは貴重な情報源です。例えば、このスレッドが大変参考になりました。
QSPIのフラッシュやPSRAMは少ないピン数でメモリ容量を増やすことができ、ESP32ではその真価が十分に発揮されています。残念なことにSTM32では、比較的新しいデバイスでないと使うことができませんので、これらのデバイスを使う際には以下の点に注意が必要です。
64pinとか100pinで両方が使えると便利なんですが。。。