マイコン工作実験日記

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

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

2018-12-09 16:41:09 | Weblog
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)の値を、生成直後に調べてみると。。


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

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

STM32CubeMX v5

2018-11-22 10:51:01 | Weblog



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

2018-10-28 14:59:39 | Weblog
しばらく前に、訳あって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の内容が更新されて直っているのでしょうか?
コメント (2)

NUMWORKS

2018-09-16 18:18:23 | Weblog
ネットを徘徊していて、NUMWORKSというフランスの電卓メーカーを知りました。どうやら1年ほど前に製品を発表していたようで、電卓好きな人たちの間ではTIの関数電卓のようにグラフ表示もできる電卓として話題になっていたようです。また、MicroPythonが搭載されていることでも注目されていたようです。


日本向けへの直販はやっていないようなので、米国アマゾンで購入するとか、輸入業者経由で買うとかしないとならないようなのですが、シュミレータが用意されており実物が無くても動かすことができるのが、洒落ています。 このページで表示される電卓画像上のボタンを押して操作してみることができるのです。

そしてさらにすごいのは、中身のハードウェアやソフトウェアまで公開されており、リソースページからは回路図やBOMリスト、SDKのダウンロードをすることができます。メインのマイコンはSTM32F412ですし、使用しているLCDはコントローラにST7789を使用した16ビットパラレル接続のもののようです。その気になれば自分で互換ハードウェアを作れるだけの情報が全て揃っていますし、ソフトのソースはgithubから入手できます。まぁ、このオシャレなデザインが大きな魅力なんで、ハードは買って、ファームを入れ替えたりして遊ぶのが楽しそうです。

STM32のBOOT0ピンは、USBのVBUS端子に接続されています。そのため、PCとUSBケーブルをつないで電源を入れれば、STM32の内蔵DFUブートローダが起動され、ファームウェアの書き換えが可能です。ファーム書き換えにはなんの改造も必要ありません。てか、こんなことまで、ちゃんとWebページで丁寧に説明してくれているのが偉い!!
コメント

Device ID

2018-08-16 11:00:23 | Weblog
先日、STM32CubeMXがアップデートされたのと時期を同じくして、STM32CubeProgrammerも更新されていました。USB経由だとSTM32F7とつながらない問題も修正されたようなので、これを機会に以前から気になっていた問題を調べて見ることにしました。




上図は、Nucleo-F767 をDFUでブートして、STM32CubeProgrammerと接続した状態です。USBで接続した後、Device Descriptorや Config DescriptorからSerial NumberやらFirmware Versionやらの情報を引き出していることがわかります。ところが、Device ID (0x0451)をどうやって調べているのかが不明でした。Device Descriptorにも Config Descriptorにも該当する情報は含まれていません。もしかして隠しDescriptorが存在しており、それをアクセスして取得しているのではないかとも想像して、Wiresharkを使ってUSBパケットをキャプチャして調べてみたのですが、やはりそのような情報を取得している様子はありませんでした。一体、どうやってDevice IDを取得しているのか?

Device IDはレジスタを読みだして取得することができます。Enumeration時のDescrptorの読み出しではなく、DFUのプロトコルを使って取得しているのかもしれないと思い調べてみましたが、やはりそのような形跡はありません。STM32の UART BootloaderプロトコルではGet IDというコマンドが用意されており、このコマンドを用いることでDevice IDが取得できるようになっているのですが、DFUのプロトコルにはそのようなコマンドは用意されていないのです。

なぜ、Device IDの取得方法にこだわっているのかというと、それは自分でDFUローダを作った場合にもSTM32CubeProgrammerを使いたいと思ったからです。実際に、CubeMXを使ってUSB DFUを使用するプロジェクトを作成して動かしてみると、次の図に示すようにDevice IDが不明であるためにSTM32CubeProgrammerが使用できないのです。




このように、CubeMXで作成したUSB DFUが、そのままではCubeProgrammerでは動作しない訳で、ツール群としての整合性が取れていないではありませんか。Device IDさえ取得できればCubeProgrammerでの書き込みが行えるはずなのに。。。。

いろいろと調べてみましたが、結論としてはUSBのenumeration手順やDFUプロトコルではDevice ID情報を取得していないということがわかりました。それでは、CubeProgrammerはどうやって、Device IDを知ることができるのか? 直接情報を取得していないからには、他の情報からDevice IDを推定しているとしか思えません。

そこで思い当たったのが、DFUのInterface中に存在するDescriptorです。



DFUブートした時には、上図の上半分のようにFlashの構成だけでなく、Option ByteやOTP Memoryの領域の情報もAlt Interfaceとして表現されています。それに対して、CubeMXで機械的に生成しただけのDFUコードでは、Flash構成を表現するAlt Interfaceしか現れていないのです。もしかすると、CubeProgrammerはこれらの Alt Interfaceが表現するフラッシュメモリの構成からDevice IDを推定しているのかもしれません。

推測を確かめるために、DFUのスタックを改造して複数のAlt Interfaceをサポートできるようにして、Option Bytesを表現するAlt InterfaceのDescriptorを追加。もちろん、該当部分のFlashの読み出しもできるようにコードを追加してやりました。すると....




予想した通り、CubeProgrammer はFlashとOption Bytesの構成方法からDevice IDを推定しているようです。これで自作のDFU Loaderを使った場合でもCubeProgrammerでの書き込みが行えるようになりました。

コメント