Githubでlvglのプルリクを見ていたら、#6487 としてNemaGFXでの描画サポートの追加というのが出ていました。調べてみたら、NegaGFXというのは Think SilliconのGPUの API のようで、どうやらSTM32でNeoChromとかNeoChrom VGとか呼ばれているGPU機能は Think Silliconの製品を採用したもののようです。
近いうちにNeoChromがlvgl でも使えるようになることが期待できます。
そう思っていたら、いつの間にか LVGLのオフィシャルパートナーにSTのロゴが加わっていることに気づきました。正式発表も近いかな。
でも、NeoChromってNucleoボードに搭載されているMCUではサポートされていないんですよね。やっぱ、DMA2Dのサポートも復活して欲しいところです。
来週の発表になるのかもしれませんが、STM32H7R/Sシリーズが新たに出るようです。正式発表の前ですがYouTubeにDiscovery kitが紹介されています。
STのサイトで検索してみるとこんな資料が見つかりました。内蔵メモリを抑えて価格を抑えているようです。
2週間前近くにLVGL v.9.0.0がリリースされました。メジャーバージョンが上がったことに伴い、機能追加だけでなくAPIの変更も生じているので、Nucleo-U575ZI版のDoomPlayerの対応作業を進めています。主要な変更はCHANGELOGに書かれていますが、わたしなりに気になった点を列挙しておきます。
久しぶりに新しいNucleoボードを購入しました。表題のとおり Nucleo-U575ZI-Qです。以前のNucleoボードはブリスターパックでしたが、見てのとおり紙箱に変わっています。これも時代の流れですね。正面からはどのMCUを使ったボードが入っているのかわかりません。箱の裏側に貼ってある製品ラベルを見ないと判別できなくなりました。以前はのブリスターパックは、吊るしもできて売る側には好都合でしたが、この紙箱は商品陳列には不向きですねぇ。
USBコネクタがType-Cになりましたが、USB-PDの関係もあってか、デバイス側しかサポートできないハードウェアになっています。
当初はSTM32H5のNucleoを買おうと思っていたのですが、使わないEtherは邪魔なだけだし、OCTOSPIがひとつしかないことがわかったので、STM32U5に方針変更。STM32H7A3では、Quad SPIでPSRAMを使おうとして、シリコンバグの罠にハマりました。STM32U5では問題なくQaud SPIのPSRAMの読み書きができそうなので、Quad SPIのフラッシュとPSRAMの両方を使うことに再挑戦してDoomを動かしてみるつもりです。
AVRCP Cover Artは、200x200画素のJPEG データとして送られるという仕様になっています。STM32H7B3I-DKでは、LCDの画面サイズが480x272ですので、JPEG展開してそのまま表示してやるのにはピッタシの画面サイズになっています。また、MCUがJPEGデコーダをハードウェアとしてサポートしているので、展開も簡単に行うことができます。
そんなわけでLVGLを使って簡単なプレーヤ画面を作成して、アルバム画像を表示してみました。音楽のアプリとしてはAndroid携帯で Sportifyの無料バージョンを使ってみました。ところが、曲名やアーティスト名は正しく表示できるのですが、アルバム画像が１曲遅れて表示されてしまいます。
Bluetoothで接続後、最初の１曲目は正しくタイトルと画像が表示されているのですが、２曲目ではタイトルとアーティスト名は正しく表示されるものの、画像が変化せず。３曲目以降では１つ前の曲の画像が表示されてしまうのです。
Spotifyアプリの問題だろうと思い、Pulsar というアプリも試してみたのですが、同じ症状でした。使用端末の問題かとも考えたのですが、検索してみたところspotifyのコミュニティで同じ問題が報告されていることがわかり、どうやらアプリ側の問題のようです。アプリの問題であれば、Google純正であれば間違いがないのではと考えが至ったところでで、「そういえば、YouTube Music というサービスがあったなぁ」と思い出し、試してみました。
やっぱりGoogle純正アプリだけのことはあって、ちゃんと正しいアルバム画像が表示されます。しかし、無料サービスではバックグラウンド再生ができないというのが、致命的でとてもスマホで使う気になれませんね。
なお、曲名とアーティスト名の表示には、Zen Maru Gothic を使っています。
LVGLでTrueTypeフォントを使って容易に漢字表示もできることが確認できたので、これを使ってBluetooth経由での音楽プレーヤを作ろうかと思っていたところ、BlueKitchenのブログでまさしくやろうと思ったことが紹介されていました。おまけに、カバーアートの画像表示まで実現されています。
最近のスマホはAVRCP 1.6に対応しており、最新のBTstackを使えば画像データのダウンロードも可能とのこと。動画で使われているのは、Pico wを搭載しているCosmic UncornというRGB LEDボードです。Pico wでは今年の6月に更新されたSDKでBluetooth対応が追加されていますが、ここで採用されているBluetoothスタックはBTstackに他なりません。
Pico wは元々Wifi/BTのモジュールと3本の線だけで通信しており、WiFi機能の通信も通信方向を切り替える半２重通信となっています。BTのサポートを追加するための信号が別途用意されているわけでもないので、どうやってサポートするのかと思っていましたが、ファームウェアが頑張って、WiFiとBluetoothの両方の通信を同じ信号線を使ってやりとりしているようです。まぁ、Pico w のようなボードでは実用上WiFiとBluetoothの両方を使った高速通信が求められることもないでしょうから、こういった思い切った割り切りでも良いのでしょう。ただし、通信のリアルタイム性が求められるBluetoothのSCOチャネルをサポートするのは流石に無理なので、Pico wでもHFPを使って電話の通話をすることはできません。
Pico wでは日本語のTTFフォントまで載せてLCD表示させるのは苦しいので、DoomPlayerで使ったSTM32H7B3I-DKにUSBドングルをつなげて実現する方向で作業中です。
DoomPlayerの開発にはLVGLのv8.3を使用していましたが、現在LVGLプロジェクトではv9.0に向けての開発が進行中です。最新のmasterを覗いてみたところ'Tiny TTF font engine'というTrueTypeフォントの使用を可能とするライブラリが用意されていることを知ったので、どんなもんか試しに使ってみました。
使用したボードはSTM32H7B3I-DK. フォントデータはGoogle fontsから日本語のフォントを適当に選んでダウンロード。ダウンロードしたttf ファイルは '.bin' に拡張子を変更すれば、そのままSTM32CubeProg を使ってボード上のOctal SPI Flashに書き込むことができます。ライブラリのAPIとしては
lv_font_t * lv_tiny_ttf_create_data(const void * data, size_t data_size, lv_coord_t line_height);
という関数が用意されており、TTFファイルデータのあるアドレスと、そのサイズ、希望する高さを与えてやるとlv_font_t 構造体を用意してくれます。あとは、通常のフォントと同じように文字列表示を行うことができます。表示するビットマップデータは、文字表示操作が呼ばれた時にTTFデータから必要な大きさに展開されて作成されるので、RAMの使用量も抑えることができます。動画で示したように大きさを変えながら表示する場合には、ビットマップへの展開し直しが発生していますが 280MHz動作のSTM32H7B3をもってすればかなりスムーズに表示できることが確認できました。
これまではTTFのフォントデータから、あらかじめ必要なサイズのフォントビットマップデータを作成しておき、それをSDカードやフラッシュに書き込んでおくということをしていましたが、OctSPI/QuadSPIフラッシュをMemory Mappedで使えば、もうSDカードは不要な上に複数の書体/サイズのビットマップを動的に作成して使用できますね。
DualSenseに加えてDUALSHOCK4のドライバを付け加えるとともに、USB接続の場合とBT接続の場合の処理を整理したりした結果、DUALSHOCK4のBT接続もできるようになりました。
写真に示したようにSTM32H7B3I-DKだけでなくSTM32F769I-DISCOにも移植しているので、動作確認の組み合わせが増えてしまって、まだ確認しきれていないところが。。。
写真でも見えますが、Bluetooth接続した場合には上図のようにBluetoothのアイコンボタンを表示するようにしました。このボタンを押すことによりBT接続を切断することができます。コントローラ側からも接続の切断はできるのですが、PSボタンを10秒押し続けねばならず面倒くさいので画面タッチで切断した方が便利です。
BTstackからのHID接続の切断は hid_host_disconnect() によって行えるのですが、この関数ではHID接続で使用していたL2CAPチャネルはクローズしてくれるのですが、HCLレイヤのACL接続はまだ残ったままになっています。そのため、gap_disconnect() によりこれをクローズしてやる必要がありました。
接続を切断しないままSTM32側をリセットしてしまうと、コントローラ側ではリセットされたことがわからずにいます。そのため、何かボタンを操作してから10秒以上経過しないとコントローラ側の電源が切れないらしく、その間コントローラからSTM32側へのPSボタン押下によるBT接続の再開操作が機能しないようです。
リセット動作に関しては、STM32H7B3I-DKを使った場合にソフトウェアリセットを掛けると、USBドングルのUSBエニュメレーションがうまくできないという問題がありました。どうやらUSBホストからUSBリセットをかけただけではBluetooth USBドングル(おそらくはCSRチップを使用?)が完全にリセットできず、一度ドングルに供給する5Vを落としてやる必要があるようです。
このリセット問題、同じUSB PHY(USB3320C)を使っているSTM32F769I-DISCOボードでは発生しないので疑問に思い両者の回路図を比較したところ、F769I-DISCOボードではPHYのRESETB信号がMCUのNRSTに接続されているのに対し、STM32H7B3I-DKボードではジャンパーを実装しないとプルアップ状態になっていることが判明。調べてみるとジャンパーを実装せずとも USB_DriveVbus() を呼ぶことでソフトウェアで VBUSを落とせることがわかったので、これを使って対処することにしました。
現在、わたしが主に使っているPCはMacBook Pro, 13-inch, 2018モデルです。購入から4年以上が経過し、かなりバッテリーがヘタってきていたのですが、昨年末からはいよいよバッテリーステータス表示に"修理推奨”という表示が現れるようになっていました。もともとそろそろ買い替えを意識していたので、新しい14インチM2 MacBook Proの発表を待っていました。しかしM２Pro/Maxであることは魅力ではあるものの、予想以上に値段が高かったので買い替えを躊躇。バッテリーを交換してもう少しIntelチップの2018モデルを使い続けることにしました。
3月1日からはバッテリーの交換費用も値上げされるということだったので、木曜の午後2時にApple新宿のGenius Barに予約を入れてMBPを持ち込み。その場では症状の確認と、その他の問題点がないかを調べるダイアグを実施してもらい、修理交換を依頼。その場で交換してもらえるかと思ったら、修理サポートセンターに送るとのこと。修理完了後は店頭受け取りだけでなく、自宅まで直接送ることもできるとのことだったので、そのように依頼。費用は税込 23,800円でした。
修理期間としては、概ね１週間程度ということだったのですが、本日(土曜)の昼前に自宅で受け取ることができました。木曜に受け付けて、金曜の朝には修理センターに到着。午前中に検査を実施後、午後3時頃には修理が完了したというメールが届きました。配送にはヤマトの宅急便の伝票が切られたのですが、配達日時が指定されていないので、自分でヤマトに電話して配達日時を指定しろという指示がありました。伝票番号から調べると厚木法人営業支店預かりになっていたので、修理センターもおそらくは厚木にあるのでしょう。電話して、本日午前中の配達を依頼して、無事手元に戻ってきました。
バッテリーの値段だけを考えれば、23,800円は高いように感じられますが、4年以上使って数個のキートップが剥げて白濁化していたキーボードも交換されて綺麗になって返ってきたので、十分に満足できるサービスでした。
