DualSense Input Demo

DualSenseの動作を確認するために、LVGLを使ってボタンやセンサーの動きを表示する簡単なデモを作ってみました。



ボタン機能については、押された時に該当する位置に赤丸を表示。アナログスティックは、動きに応じて青線を表示しています。トリガーは、引き方に応じて赤マルサイズを変更。最後に、DualSense全体を前後、左右に傾けて、DualSenseの姿勢状態を右側の円形表示部分を変化させています。

Linuxのドライバーコードでは、アダプティブトリガの機能については、サポートされていないのでトリガがスカスカのままだったのですが、このサイトの情報を見つけて、USB経由でトリガの強さもHIDのOutput Reportで変更できることがわかりました。やはり、ちょっと手応えが無いとダメですね。

このデモを動かしている程度では、ほとんどUSBのエラーは発生しません。複数のボタンを同時に操作しながら全体を動かしたりして、画面変化量を増やすと時折TXERR が発生するようです。どうも、SDRAMへの書き込みが頻繁に発生するとエラーが発生しやすくなるような気がします。

RP2040 Doom

すごいです。まさか、ピコで動かすとは。

ここで説明されているように、かなり苦労しているようですが、音楽や効果音、テキストモード画面までサポートしており、機能的な出来上がりは完璧です。

なるほど、音楽部分はOPL2のエミュレーションソフトを使っているのですね。こういうのがあるとは知りませんでした。わたしも試してみようかな。

 

TI 84 Python電卓の中身

TIが出しているPython機能を持った電卓では、Python機能の実態としてATSAMD21E18が使われているという分解レポート。SAMD21は 3:50秒あたりで大写しになっています。

このチップAdafruitのQT Pyで使われているのと同一のM0 MCUなんですね。TIの電卓のクセしてMicrochip(ATMEL)のチップ使って、しかもUART接続で使っているという実態が明らかにされています。電卓も生き残りのための新鮮味を出すために必死というところでしょうか。

Nucleo-H7A3ZI

ここ何年か、諸般の事情であまりというか、ほとんど工作実験ができないでいたのですが、色々とひと段落ついたこともあり、ボチボチと活動を再開しています。しかしながら、コロナの影響もありマイコンや電子部品はことごとく入手困難となってしまったご時世です。幸いなことに、昨年夏頃には Nucleo-H7A3ZIは何の問題もなく購入できたので、こいつをベースに作業を進めています。

STM32H7A3ZIはRAM容量が大きいことが一番の特徴です。フラッシュも2MBあるので、基本的なフォントデータをフラッシュに内蔵することもでき、GUIソフトを使うにも十分な容量があります。そこで、何年か前に購入したまま積み残したままになっていたLCDボードをつないでの製作を始めていました。当初、思い描いていた機能の８割がたはほぼ実装できたので、次回以降の記事で製作物の概要の説明を書いていこうと思います。

 

ついに1GHz

もうかなり長い間、工作ができておらず、記事も書いていないのですが、今回はこの発表を読んだので、紹介だけしておきます。

NXPがRTシリーズでSTM32H7の400MHzを超えて600MHzを達成したかと思ったら、今年はついに1GHzだそうです。いやはや、マイコンでもついに1GHzを迎えるとは感慨深いものがあります。

STM32H7の方は、シリコンリビジョンがVになって、400MHzから480MHzに高速化されています。ちなみに、STM32H7ではシリコンのリビジョンが Y --> X --> V という具合にアルファベット逆順になっているのがおかしなところ。Yは色々とシリコンバグがあって、注意が必要。

Express Logic

今頃になってMicrosoftが Express Logic を買収したことを知りました。FreeRTOSの時は各種メディアで取り上げられたけど、ThreadXはそれほどの知名度が無いということ？

Express Logic は ThredX というRTOSやTCP/IPスタックを提供しているわけですが、これらのソフトウェアはTIや Cypressの Wi-Fiモジュールなんかでも採用されているのですが、将来的にこれらの製品に対する供給を止めることはないんでしょうか？ちょっと気になります。

STM32H750 Discovery Kit

ここのところ、諸般の事情によりちっともブログ更新ができていません。実際のところ仕事でしかマイコンに触れていないのが悲しいところです。

そのため、STが大量にYouTubeにアップしている動画も、満足に見ている余裕がありません。STM32MP1でのLinuxサポートのように、プレスでの発表がある前に、動画でチラ見せしているみたいなので要注意なんですが。先週投稿されたこの動画もそのひとつです。最初は、一般公開されていたと思うのですが、いつの間にか限定公開になっているようです。一応、限定公開なので、画像を直接出すのは遠慮して、URLだけ書いておくことにします。

https://www.youtube.com/embed/OSwmE0WiehQ

STM32H750 Discoveryなんてまだ未発表なんですが、どうやら近日中にTouchGFX対応もされるようです。このままちゃんと製品として発売されることを期待したいところですが、STM32H750ってMCUのチップ自体が輸出規制がかかっているのか、Mouserや Digikey では日本向けに出荷してくれないのが気になります。

動的割り当てと静的割り当て

FreeRTOSではたしかv9.0.0からだったと記憶していますが、RTOS資源をメモリ上に静的に割り当てることが可能になっています。従来からと同じようにヒープ領域上に動的に割り当てることもできますので、ユーザは必要に応じて、動的割り当てと静的割り当てを使い分けることができます。STM32Cubeを使っていると、FreeRTOS APIをCMSIS RTOS API v1(もどき)でラップしたインタフェース(cmsis_os.h>が提供されており、STM32CubeMX上でも動的割り当てと静的割り当てを使い分けることが可能です。

STM32CubeMXにおける、実際の割り当ての方法をSemaphoreを例に見てみると...

まず、Config parametersにおいて、メモリ割り当て方法を指定します。Dynamic/Staticを指定すれば、どちらも使うことができます。



割り当て方法としてDynamic/Staticが指定されていれば、Semaphoreを用意する際に、割り当て方法としてどちらを使うかを選択することができます。



Semaphoreの作成の仕方が異なるだけで、使い方は同じosSmaphoreWait/osSemaphoreReleaseで操作できるので、動的割り当てを使っていた従来のコードは容易に静的割り当てに変更することができます。というか、できるハズだったんです。

ところが、実際には静的割り当てに変えた途端に、それまで動いていたコードが動かなくなりました。なんだか初っ端から動かない。どうやらセマフォの初期値がおかしいらしい。上記の例で動的に割り当てたセマフォ(myBinarySem01)と静的に割り当てたセマフォ(myBinarySem02)の値を、生成直後に調べてみると。。


動的に生成した場合の初期値は１なのに、静的に生成した場合の初期値はゼロになってしまっています。CMSIS RTOSv1のAPI定義としては、１になるべきところです。

と、言うわけで相変わらず STM32CubeのCMIS_OS APIは油断できません。見事に地雷を踏んでしまいました。

STM32CubeMX v5

STM32CubeMXがv5にバージョンアップ。プレスも出したし、YouTubeに動画もアップという力の入れように、ちょっとビックリ。見かけが大きく変わって、STM32CubeProgrammerとの統一感が生まれたものの、さらに巨大化して起動が遅くなった感じがします。中身としては、TouchGFXの提供が始まったことが興味深いです。買収の成果の恩恵を享受したいところなんですが、ちょっとハードルもあるかも。個人的には TouchGFX Designerって Windowsでしか動かないので、それだけで挑戦する意欲が低下。

TouchGFXの実質的なサポートはSTM32Cubeパッケージに依存するわけですが、どうやらターゲットCPUはSTM32F4とSTM32F7の一部のデバイスに限られるようです。STM32H7に関しては新しいバージョンのCubeH7が提供されていないこともあって、未サポートの様子。それとも、DSIホストをサポートするデバイスしかサポートされないのだろうか？

CubeMXのリリースに伴って、CubeF4, CubeF7などはアップデートが出ているのに、CubeH7はv1.3のまま。Cubeライブラリの更新状況が、デバイスによってかなり違うので、中身も色々と細かい違いが生じてしまっているようです。例えば、FreeRTOSのバージョンもバラバラ。STemWinのバージョンもL4, F4, F7は新しくなったけど、H7は古いまま。もう少し待てば CubeH7も新しいバージョンが出るのかもしれません。

TouchGFXについては、ちょっとそそられるものの Discoveryとか買わないとすぐには使えなさそうなのも、障壁ですね。ここは、Discoveryボードのお土産付きのハンズオンセミナーとかを開催して欲しいものです。

STM32H743のUSB Serial Number

しばらく前に、訳あってNucleo-H743を購入。ぼちぼちとH7を使いはじめています。そろそろ新しいRevision Xになっているかと思っていたのですが、手元に届いたのは運悪くRevision Yでした。シリコンバグで困るようなことになったら、買い直すことになるかも。

このボードはNucleo144なので、USB FSポート用のマイクロUSBコネクタが付いているます。そのため、BOOT0をHにしてやるだけで、ブートローダのUSB DFUを動かすことができます。



STM32CubeProgを使ってログ表示を見ていたら、ちょっと気になる内容を見つけました。USBのデバイス ディスクリプタの内容のダンプが含まれているのですが、
Serial Numberの値がやけにキリのいい値になっています。普通デバイス固有の番号になるはずなので、こんなキリのいい数になるはずは無いのですが。。。

そこで、デバイス固有の96bitのIDを保持しているはずの領域の内容をダンプしてみると。。



全然違う値が入っているじゃないですか。

それじゃぁ、表示されたUSB Serial Numberはいったい、どこから出てきた数字なのでしょう。「もしかして、デバイス固有のIDではなくて、デバイスの種別を表しているDEVICE_ID情報を表示しているのではないか？」と考えて、その領域の内容を見てみると。。



想像どおりでした。間違ってDEVICE_IDの内容を表示しています。つまり、STM32H743のUSB DFUは、どのチップでも同じシリアル番号を返すことになりますね。もしかすると新しい Revision XのシリコンではSystem ROMの内容が更新されて直っているのでしょうか？