マイコン工作実験日記

Microcontroller を用いての工作、実験記録

LED追加実装

2024-02-17 10:59:02 | DoomPlayer

ボードの右端に長らくと未実装だったLEDを追加実装。音楽プレーヤで再生時に、曲に合わせて点滅します。元々のlvgl音楽プレーヤーが 4つの帯域に分割したスペクトル表示をする仕組みになっているので、その強さに応じて4色のLEDの明るさをPWMで変化させています。PWM制御にはちょうど4チャンネルのPWM出力ができるTIM2を使用。PWM出力に割り当てた端子に抵抗を介してLEDを直結しているだけの簡単な仕組みです。

それなりに明滅してくれますが、緑が暗めで青が明るめに表示されている印象。電流制限抵抗を調節するとか、PWMのデューティ比を各チャンネル毎に調節するとかした方がいいのでしょうが、試行錯誤するのも大変そうなのでこれで我慢。

LEDには秋月で購入した1608サイズのロームのチップLEDを使用しました。このサイズなら手半田作業できるのですが、ピンセットで掴み損ねて弾いてしまって赤色をひとつ紛失。カーペットの上に落としてしまうと、もう発見不可能です。

袋の張られた品番シールに色付けされているのが、とっても助かる。こういう気配りが嬉しいですね。


LVGL v9.0.0

2024-02-04 11:49:10 | Weblog

2週間前近くにLVGL v.9.0.0がリリースされました。メジャーバージョンが上がったことに伴い、機能追加だけでなくAPIの変更も生じているので、Nucleo-U575ZI版のDoomPlayerの対応作業を進めています。主要な変更はCHANGELOGに書かれていますが、わたしなりに気になった点を列挙しておきます。

  • リリース直後は、ドキュメントの更新が追いついていない箇所が多い印象を受けましたが、日々改善されているようです。
  • APIの変更では用語統一のために名前だけが変更されたものも数多くあります。旧バージョンとの互換性のためにlv_api_map.hというヘッダが用意されていますが、このファイルはlvgl.hからincludeされているので、気をつけないと新しい名前への変更を忘れてしまいます。
  • 座標を表現する型lv_coord_tが廃止され、int32_tを使うようになりました。以前は、int16_tとint32_tのどちらを使うかlv_conf.hで選択することができました。chart widgetで点数の多いグラフを描画する場合には、使用するメモリが倍になるかもしれません。
  • サポートするカラーフォーマットの名前と種類が変更されています。また、ビットマップイメージを表現する型lv_image_dsc_t (旧 lv_img_dsc_t)も変更されています。そのため、ビットマップ画像を埋め込んでいるアプリは、画像データの再変換作業が必要となります。
  • 1ヶ月ほどのベータ期間がありましたが、まだバグは残っています。
  • GPUサポートは、公式パートナーになってくれたベンダーのチップしかサポートしないという基本姿勢になりました。そのため、以前はSTM32のDMA2Dを使用するコードが含まれていましたが、v9.0.0ではDMA2Dは全くサポートされていません。DoomPlayerでは、ほとんど気になりませんが。。

 


8BitDo Zero 2

2024-01-27 14:10:24 | DoomPlayer

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

このコントローラは、Switch, Window, Android, MacOS, Keyboardの4つの動作モードを有しており、ベアリングの開始方法によって動作モードを選択できるようになっています。どのモードを使うのがいいのか迷うところですが、ちょっと調べたところ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の接続

2024-01-15 20:19:19 | DoomPlayer

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


OCTOSPIによるQSPI Flash/PSRAMの接続

2024-01-04 12:08:17 | DoomPlayer

現在作業中の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にクロックを落としたところ、問題解消。