emWin(STemWin)を動かす -- その2

前回の記事にも書きましたが、emWinはSTM32 Cubeパッケージの中にMiddlewareとして含まれてはいるものの、次の画面に示すようにCubeMXの構成画面からはアクセスできないというのが、ちょっと取っつきにくい要素のひとつになっているのではないでしょうか。そして、どうしても調査のためには1,000ページを超える分量のあるemWinのマニュアルに目を通さねばならないのが、敷居を高くしている要因でしょうか。



CubeMXはSTemWinに関する情報は何も提供してくれないので、自分で必要なファイルやライブラリパスをプロジェクトに登録してやる必要があります。それらのファイルは、CubeMXからライブラリパッケージをダウンロードしてインストールした場合には、 STM32　Cubeのレポジトリディレクトリの配下にインストールされています。わたしは Mac OSを使用していますので、~/STM32Cube/Repositryの配下に入っており、CubeL4のVersion 1.10.0 の場合は次のようになっています。Windowsの場合には、C:¥STM32 とかC:¥STM32Cubeとかを探してみてください。



STemWinのディレクトリの下にemWinが一式入っていますので、これらのファイルを必要に応じて参照のためのPATHを切ったり、ファイルをプロジェクト内にコピーして使うことになります。簡単に主要ディレクトリに含まれている内容を説明しておきます。

• Config -- ターゲットで使用するために、設定やコードを追加する必要のあるファイルが入っています。自分のプロジェクトにコピーして使います。
  
• Lib -- emWinのライブラリが入っています。リンク時にパスとライブラリ名を指定してやります。ビルド環境に合わせて、Keil, IAR, GCCの３種類のコンパイラでコンパイルされたライブラリが用意されており、それぞれのライブラリはさらにOSの有無、ARGB対応の有無によって個別のファイルが用意されています。ファイル名にotのサフィックスが付いているファイルはコンパイル時に実行時間重視の最適化を施してあるファイルのようです。
  
• OS -- ターゲットのOS環境に適合させるためのサンプルファイルが入っています。サンプルとして、OS 無しの場合(GUI_X.c)と FreeRTOSを使用する場合 (GUI_X_OS.c)の２種類が用意されています。これらの環境でemWinを使用するのであれば、そのまま利用可能です。
  
• Software -- emWinアプリケーションを作成する際に使用できるツールが入っています。Windows環境用のバイナリです。
  
• inc -- emWinアプリが参照するヘッダーファイルが入っています。ビルド時にパスを指定してやります。
  

結局のところ、Config のディレクトリにあるファイルさえ、適切に変更、コードを追加してやればemWinを動かすことができます。ただし、上記のディレクトリにはemWinの本体がらみのファイルがあるだけで、サンプルのアプリは含まれていません。それらのサンプルは、パッケージのProjectサンプルとして提供されています。



前回の記事で示した画像はこれらのデモの一部になります。デモは何種類か用意されていますが、内容によって使用する資源(RAM, Flashのサイズ）が異なるので、外付けRAMの無いNucleo環境では実行可能なデモの種類や数は限られるようです。

emWin(STemWin)を動かす -- その1

STM32L452REにSPIでつなげたLCDですが、今回は表示のためにSTemWinを使ってみることにしました。STemWinはSEGGERが提供しているemWinをSTM32専用にあらかじめコンパイルしたライブラリとして提供されるGUIソフトウェアになります。CubeF1, CubeF3, CubeF4, CubeF7, CubeL4とかをダウンロードすると、そのパッケージの中に含まれているミドルウェアなのですが、CubeMXの画面からコンフィグすることはできないので、意外と知らずにいる人も多いのではないかと思われます。そこで、この後、何度かに渡ってSTemWinを動かすまでの手順について、記事を書いていこうかと思います。かく言うわたしも、ようやくとサンプルのデモ表示を動かすところまでこぎつけた段階で、タッチパネルとのインタフェース部分はまだできていないような状態です。

emWinは元々はSEGGERがソースコードの形態でライセンスするソフトウェアなのですが、このページの説明によれば、STだけでなく、Microchip, NXP, Silabs Cypressといった主要マイコンベンダに、そのベンダのマイコンで使用することを条件としてライブラリ形式で提供しているようです。

STM32Cubeの場合、LCDを持った評価ボード用のサンプルプロジェクトがパッケージの中に含まれていますので、そのコードを参考にしてemWinを動かすことができます。これらの評価ボードではいずれもLTDC/DSIを使ったRGB接続もしくは、FMCを使った16ビットパラレル接続でLCDをつなげており、そのためのサンプルコードが示されています。しかしながら、インタフェースの仕様を調べてみると、SPI接続でもemWinを動かすことができることがわかったので、今回はこれを試してみることにしました。

メモリの制約もあり、すべてのデモサンプルを動かすことはできませんが、いくつかのデモを動かすことができたので、その画像を以下に示しておきます。







実際にSPI LCDに表示するまでのステップの説明については、次回の記事で書くことにします。

RとH

10代工学が新たなビデオを公開していたので、早速確認。ロボットアームとの組み合わせとは面白い。こんなスマートスピーカーだったらすぐに買っちゃうけど、モータ音が気にならないか？

３階建て

購入した3.2インチLCDをB基板を使ってNucleoに重ね載せ。下の基板にはBM20基板と、SPIフラッシュ、ミニUSBコネクタしか載っていないので、全てまとめれば１枚の基板にまとめられるのですが、作り直すのも面倒なので３階建てで実験を進めることにします。実はこの3.2インチのLCDよりも3.5インチのLCDの方が値段も安くて解像度も高かったのですが、こちらだとB基板のサイズにより近いのが気に入りました。

3.2" LCD

注文しておいた3.2インチのLCDが先週末に到着。現在、Nucleo-L452とつなぐための準備中です。



今回、購入したのはBuyDisplay.com のこちらのディスプレイです。タッチパネル(抵抗皮膜方式 or 静電容量方式)、 電源電圧 (5V or 3.3V)、インタフェース(8bit, 16bit, SPI)を選択できるのですが、Nucleoとつなぐために3.3V, SPI 4wireを選択しています。そしてタッチパネルは静電容量方式です。いやー、静電容量方式のタッチパネルを使ってみたかったんですよねー。



裏側はSDカードやSPIフラッシュが搭載できるというよくある構成です。フォントについては、自分で用意したQuad SPI Flashを使う予定ですので、このスペースを使うつもりはありません。

フレキケーブルの右上部分に載っているのは、タッチパネルコントローラのFT6236のようです。こちらはI2Cでマイコンとつなげます。

DFUが安定して動くようになった

前記事ではDFUでの書き込みができるようになったものの、読み出しの調子が極めて悪い状態でした。

USB送信がうまくできていないようだったので、USBのクロック設定を確認してみたものの問題なさそうでした。STM32L452ではHSI48という内蔵RC発振器を持っており、こいつを使うことで水晶を実装しなくてもUSBを使うことができます。念のために、48MHzのクロック弦をMSIに変更してみたりもしましたが、症状は変わりません。

クロック精度に問題がなさそうなので、クロック速度の方を見直すことにしました。これまでは消費電力を抑えることも考えSystem Clockを16MHz で動かしていましたが、これを80MHz に変更。すると、あっさりと読み出しが何の問題もなく、正常に終了するようになりました。

DFUでの読み書きが正常にできるようになったので、これで安心してSPIフラッシュをフォントの格納に使えそうです。表示装置として注文しておいたLCDも、もうしばらくすると届きそうです。次は、その接続作業に取り掛かることにします。

USB DFUを動かす

STM32でUSB DFUを動かすには、CubeMXでコード生成をするだけではダメでUSBのI/Oとファームウェア格納領域に対するI/Oとをインタフェースするコードを補ってやる必要があります。CubeMXでは、その部分のコードをusbd_dfu_if.c というファイルとしてスケルトンとして用意してくれます。　今回は、Quad SPIフラッシュをファーム格納領域として使用しますので、フラッシュの消去、書き込み、読み出しのコードをこのファイルに追加してやります。

さて、実際にインタフェースを調べてみると、BSPで用意されているドライバととても簡単につなげられることがわかりました。usbd_dfu_if.c の関数と、Quad SPIのBSPのドライバとを１対１で対応させることができます。

• MEM_If_Init_FS() --> BSP_QSPI_Init()を呼ぶ
  
• MEM_If_Erase_FS() --> BSP_QSPI_Erase_Block()を呼ぶ
  
• MEM_If_Write_FS() --> BSP_QSPI_Write()を呼ぶ
  
• MEM_If_Read_FS() --> BSP_QSPI_Read()を呼ぶ
  
• MEM_If_GetStatus_FS() --> Erase, Programに必要なウェイト時間を返す
  

と、いうようにコードを追加してやるだけ。簡単すぎるのと、BSPの関数がポーリング待ちするのが気になり、こんなんで動くのか？ と心配ではありますが、ひとまず試してみることに。

SPIフラッシュは8MB分の容量がありますので、動作試験のために /dev/randomを使って8MB分のランダムデータを用意してやります。そして、そのデータをdfu-utilを使ってSPIフラッシュの領域に書き込んでやります。



64KBのブロック毎に消去をしてから、64KB分のデータを書き込むという動作を繰り返していきます。消去とプログラムの終了待ちをするために随分と時間がかかりましたが、書き込みは無事終了。

続いて読み出しをしてみると、途中でエラーが発生してしまいました。

気を取り直して、再度実行。



今度は無事に読み出しが終了しました。cmpで比較しても書いた通りのデータが読み出せています。

何度か動かしてみましたが、５割以上の確率で読み出し途中でエラーが発生してしまうようです。エラーから察するにQSPIの読み出しではなく、USBの転送でエラーが発生しているようです。QSPIの読み出しでポーリングしているのが原因になっているのかもしれませんが。。。