8BitDo Zero 2

BT860-SAを使ったゲームパッドのBluetooth接続もできるようになったので、新たなコントローラーとして8BitDo の Zero 2のサポートを追加しました。DualSenseやDualShock4はアナログパッドや６軸センサー機能も有しており機能豊富なのですが、大きくてそこそこの重量もある上に高価でもあるので、もっと手頃なコントローラを探したところZero2を見つけました。

このコントローラは、Switch, Window, Android, MacOS, Keyboardの４つの動作モードを有しており、ベアリングの開始方法によって動作モードを選択できるようになっています。どのモードを使うのがいいのか迷うところですが、ちょっと調べたところMacOSモードを使うのが都合がいいことがわかりました。その理由は簡単でこのモードではデバイス名が 'Wireless Controller' となり、ペアリング時にDualSenseやDualShockと同じ名前になるためです。DoomPlayerではBluetoothでコントローラを検索する際にデバイス名とCoD (Class of Device)の情報をチェックしているのですが、このMacOSモードを使うとDualSense/DualShock4と同じデバイス名/CoDを使ってくれるので、容易に判別できるのです。

逆にデバイス名とCoDだけでは、DualSense/DualShock4/8BitDo Zero 2の違いは判別できないのですが、そこはさらにVendor ID/Product IDを調べて識別を行うようにしています。

さて、実際にZero 2 をつなげてみると、出力されるHIDのInput Reportは DualSense/DualShock4とはかなり異なります。ボタン数が少なくセンサーもないのでInput Reportのサイズが小さくなるのは当然なのですが、出力されるタイミングが全く異なります。DualSense/DualShock4では、毎秒800回ほどのレートで常時継続してInput Reportが出てくるのですが、Zero 2ではボタンを押したり/離したりして状態変化があった時にのみInput Reportが送られてきます。毎秒800回のInput Reportの受信処理はそれなりの負荷になりますので、小さなマイコンや省電力化を図りたい場合には、Zero 2の動作は好ましいとも言えます。

 

BT860-SAの接続

今回のNucleo-U575ZIを使ったDoomPlayerでは、USBホスト機能が使えないため、UART接続で使えるBluetoothモジュールとして、BT860-SAを使っています。最近では、BLEのモジュールは簡単に入手できますが、Classicをサポートしたモジュールは数が少なくなっている印象です。秋月で売られているClassicをサポートしたモジュールはSPP接続用のものばかりのようです。日本での認証を受けたUART接続のHCIモジュールというとかなり限定されてしまうようです。BT860-SAは1,600円程度しましたので、コスト的にはESP32とかPico-WとかをBluetooth HID処理専用に使った方が安いというのが皮肉なところ。

このBT860-SAですが端子パッドの銅面がモジュール裏側のヘリまでついており、フラックスの助けを借りてなんとか手半田作業で実装できました。当初は、QFNのパッケージのように側面にもパッドが出ていることを期待していたので、実物を見て側面には銅面が無いことを知り、かなり焦りました。

モジュールは、UARTのHCIで動くので、MCUとはRX, TX, RTS, CTSの４線をつなげば、動いてくれます。ディフォルトは 115,200 baud, 8bit, パリティ無しとなっており、データシートにはconfigファイルを設定したり、ベンダー独自のHCIコマンドを送れば、通信速度を変更できると書いてあります。しかしながら、その具体的な内容や手順に関しては、データシートには書かれていません。ちょっと検索しても明記されたわかりやすいページが見つからずに悩んでいましたが、BTStackのhci_transport_h4.cを読んだところ、速度変更するコマンドを送っていることが判明。port/posix-h4-bcm/main.c を参考にして速度変更できることを確認できました。現在、1.5M baudで使っていますが、問題なく動いてくれているようです。

OCTOSPIによるQSPI Flash/PSRAMの接続

現在作業中のNucleo-U575ZIを使ったDoomPlayerの開発ですが、ようやくと音楽、効果音、ゲームの再生、実行機能が動くようになってきました。音楽の再生時には、SDカードとDACを使っており、効果音の再生とゲームの実行時にはQSPI FlashとQSPI PSRAMの両方へのアクセスが発生しているので、Bluetooth部分を除いて基板上に追加実装したパーツのひととおりの動作確認が取れたことになります。

GUIとして使っているlvglは もうすぐv9.0がリリースされる予定ですが、今のところはv.8.3.11を使っています。

Music Playerでは、Timerで生成した44.1KHzのクロックをトリガとしてDACで変換することで音楽を再生。

効果音については、従来通り11.025KHzの8bit PCMを4倍して44.1KHzに変換して再生します。

BluetoothのモジュールであるBT860とはUARTを介してHCIのリセットコマンドを送り、その応答が返ってくることは確認したのですが、BTStackの移植作業は未着手となっています。そのため、Doomの実行時にはデモ画面が流れるのを見ることができるだけで、操作は一切できない状態となっています。

今回のプロジェクトの大きな目的のひとつは、STM32U5のOCTOSPIインターフェースを使って、QSPI FlashとQSPI PSRAMをつなげてアクセスすることでしたので、この目的は達成できたと言えます。おさらいしておくと、2年近く前にはNucleo-H7A3を使ってPSRAMをつなげてみましたが、シリコンバグを回避するために大きな制約を受け入れてようやくなんとか使えるというもので、不満が残っていました。STM32シリーズではデバイスによりQSPI PSRAMの読み書きができるかどうかが異なるので注意が必要です。STは公式にはその一覧を出していないようですが、フォーラムではAP MemoryのAlexさんがデバイス別の対応表を出してくれており、参考になります。

QSPI FlashとQSPI PSRAMは、OCTOSPIMのマルチプレックス機能を使ってIOnとCLK信号を共有することで使用ピン数を削減しています。実際のところNucleo-U575ZIを使えば、FlashとPSRAMにそれぞれ独立したIOnとCLK信号ピンを割り当てることも可能なのですが、マルチプレックス機能を使って問題なく動くようであれば、将来的に100ピンのパッケージを使った基板を作成してみようかとも妄想しているので、確認することにしました。試行錯誤の結果、現在動くようになった設定は...

• 当初は、FlashとPSRAMのどちらも80MHzのクロックで問題なく動くように見えたのですが、いざDoomを動かしてみると両方へのアクセスが頻繁に発生するためか、動作が不安定になり、hardfaultが頻発。160MHz/3 = 53.33MHzに落としたところ安定して動いているようです。PSRAMの方は 80MHzで問題なく動いています。
• 使用したQSPI Flash W25Q256JVはDTR (Double Transfer Rate)をサポートしているので、設定を試したみたのですが動作を確認できませんでした。DelayBlockを使ってやれば、うまくタイミングを調整できるのかもしれませんが、80MHzでの動作が不安なこともあり、あまり期待できないように思われます。

今後は、BTStackを動かしてPS4/PS5のコントローラをつなげる計画なのですが、現在残りメモリが少なくなっており、使用メモリを削減しないと苦しくなりそうです。。

1/17 追記

80MHzで動いていたPSRAMですが、ソフトを作り進めるうちにPSRAM上においた効果音データをDACで再生しようとするとノイズばかりになるようになってしまいました。Flashと同じ53MHzにクロックを落としたところ、問題解消。