カテゴリー: stm32CubeMX

TouchGFXとLTDC on (stm32h7x & stm32cubeIDE)に関するメモ

TouchGFX Designer ＋stm32cubeIDEを使ってstm32h743+NHD-3.5-320240MF搭載ボードのプログラムを開発する際の覚書です

TouchGFXの使い方

ある程度日本語に翻訳されたTouchGFXの使い方です。
LTDCだけでなくSPI他のLCDインターフェースを使ったボードに関する内容等、広範囲を対象としているため必要な知識を見つけるのに苦労しますが2021/07時点でもっとも役に立つサイトではないかと思われます。

LTDCの設定とフレームバッファのアドレス

stm32h743でLTDCのフレームバッファとして使えるのはD1領域（0x24000000からの512KB）です

LTDCの設定でFrame Buffer Start Address を RAM_D1領域0x24000000に設定します。

下の設定はなくても構いませんがD1領域に別の変数を置く場合はダミーとして宣言しておけばTouchGFXが使うフレームバッファと干渉を避けることが出来ます。

#define ALIGN_32BYTES_D1(buf)  buf __attribute__ ((section(".RAM_D1"))) __attribute__ ((aligned (32)))

ALIGN_32BYTES_D1(uint16_t framebuffer[320*240]);

なのでフレームバッファを宣言（↑）してからフレームバッファを指定（↓）します

/* USER CODE BEGIN 2 */
// TouchGFX 3.framebuffer in internal RAM
HAL_LTDC_SetAddress(&hltdc, framebuffer, LTDC_LAYER_1);

フレームバッファにプログラムからアクセスするためには絶対アドレスでなく変数宣言した方が都合が良いのですが.iocでは下のように絶対アドレスで指定しなければならないので普通はこの設定アドレスを無視してプログラムの最初でフレームバッファアドレスを再設定すればOKです。

TuchGFXの設定

TouchGFXでは初期化関数が.iocの設定を読み出して使うようになっていてここを0x00000000のままにしておくと生成されたmain.cの最初でプログラムがハングアップするため、ここをRAM-D1アドレスの0x24000000にしておかなければなりません。

 

stm32CubeIDEでmanage embedded software packagesが開けない件

stm32CubeIDEはGUDでハードウェアの設定をして初期化関数が生成できるstm32cubeMXとコンパイラを統合した開発環境です

stm32cubeIDEでライブラリ管理画面が開けない

本来はstm32cubeIDEだけでプログラム開発が出来るはずなのですが、私の環境（Windows10）ではHelp → manage embedded software packages が開けない状況になっているので、ライブラリの管理をする時は面倒ですがstm32cubeMXを起動してそちらで新しいライブラリやパッケージのインストールをしています。

この件についてWebを検索しても似た症例が見つからないので特殊な例なのだと思います。
HALライブラリのバージョンアップが頻繁でライブラリのサイズが大きくなるので（現在43.1GB）SSDのCドライブでなくハードディスクドライブを指定しているせいのような気がします。

その他にstm32cubeIDEから.iocを開くとstm32h7xのクロック設定がおかしくななって動作しなくなり、stm32cubeMXで設定しなおして復旧したという経験もあるのでまだstm32cubeMXは手放せません。

Helpメニューのリンクが切れているだけ？

その後で気が付きました、.iocから開いた画面の上部の↓Software packsからライブラリ管理画面が開けました。
単にHELPメニューのリンクが切れているだけのようです、stm32cubeMXではHELPメニューから開くのに慣れていたのでこちらには気が付きませんでした。

 

STM32CubeIDE事始め

STM32CubEIDEについて

STマイクロエレクトロニクスから、統合開発環境TrueSTUDIOに、MCUの周辺機能を設定して自動的にライブラリを作成するSTM32CubeMXを組み込んだ無償版の開発環境STM32CubeIDEがリリースされました。

STM32CubeMXとTrueSTUDIOを統合して使い勝手をシンプルにしたというコンセプトで、STマイクロとしては今後、推奨開発環境をSTM32CubeIDE一本に絞るということです。
これまで、stm32シリーズのプログラム開発ツールとして有償無償版を含め、いくつかありましたが、今後は無償版のIDEをメーカーが本腰を入れてサポートするとアナウンスしたことは歓迎できます。

俺様開発環境のJDEからSTM32CubeIDEに移る

私はルネサスのH8、SHシリーズを使っていた時代からこれまで、GCCをベースにした自作の統合開発環境JDEを使ってきました。

JDEを作って使い続けてきた理由の一つは無償版の開発環境がなかったことです。
私の会社の顧客には教育・研究開発機関があり、ユーザーがプログラムを開発・変更出来るように開発環境を含めたシステムを提供することがあるため、高価な有償の開発環境を避けたかったことがあります。

もう一つは、私がかつてのVZエディターやDelphiのDOSIDEキーマップにこだわっているということがありました。
このキーマップは Ctrl-Sで左、Ctrl-Dで右、Ctrl-Eで上、Ctrl-Xで下にカーソルが移るDOSの時代に流行ったものです。
マウスを使わずにコードを編集したいということもありますが、このキーマップに慣れていてWindowsの標準キーマップを使うと、うっかりCtrl-Xを押してラインを消去してしまうことが頻発するためです。

STM32CubeIDEはメーカー推奨の無償版開発環境で、最新のEclipseをベースにしていて、キーのカスタマイズが自由に出来るためほぼ不満のない使い勝手となりました。

もう一つの理由として、STM32CubeIDEがOpenOCDをサポートしてくれたことがあります。
これまでMCUボードへの書き込み手段としてJtagKeyをベースにしたFT2232Dを使った書き込みボードをOpenOCDから使っていました。
この書き込みボードはJtagKeyで空いていた9,10番ピンにFT2232Dで使える仮想 COMポートのTx,Rxを割り当てて、プログラム書き込みと同時にUSBシリアル機能が使えるようにしたもので、リアルタイム制御プログラムで欠かせないシリアルモニタ機能をサポートするものです。

STM32CubeMXがリリースされたときにJDEでCubeMXを使うために、JDEにCubeMX が生成するプロジェクトをインポートする機能を追加したりもしましたが、これから発表される可能性のある新機能に対応していくのも面倒なため、この機会にSTM32CubeIDEを本格的に使い始めることにしました。