サイトアイコン IoT MCUのHappyTech

SW4STM32アプリケーションのSTM32CubeIDE移設

SW4STM32で開発した2017年9月発売STM32Fxテンプレートと2019年6月発売STM32G0xテンプレートを、STM32MCU最新統合開発環境STM32CubeIDE v1.1.0へ移設しました。

移設は成功し、STマイクロエレクトロニクス最新統合開発環境:STM32CubeIDE v1.1.0(以下、CubeIDE)、STM32CubeMX v5.4.0(以下、CubeMX)、最新ファームウェアと弊社テンプレートを使って、効率的で最新のSTM32MCUプロトタイプ開発、アプリケーション開発ができます。

本稿は、STM32CubeIDE v1.1.0更新と文字化け対策投稿(その1)、(その2)のその3に相当します。説明が重複する箇所は、リンク先を参照してください。

移設成功結果

G0AdcTemplateのSTM32CubeIDE移設成功結果

STM32Fxテンプレートは「ひと手間」、STM32G0xテンプレートは「そのまま」で最新統合開発環境へ移設でき、評価ボードにてテンプレート動作を確認しました。G0AdcTemplateのCubeIDE移設後と評価ボード動作例です。

既にSTM32Fx/G0xテンプレートご購入者様は、本稿の方法で最新STマイクロエレクトロニクス開発環境へ乗換えることができます。

※現状のCubeMX v5.4.0でコード生成後、CubeIDE v1.1.0の日本語コメントは文字化けしますので注意してください(詳細は、投稿その2参照)。

最新開発環境ファームウェアとアプリケーション開発時ファームウェア

最新開発環境ファームウェアとテンプレート開発時ファームウェア

投稿その2で示したように、MCU開発ソフトウェア(=アプリケーション)に最も影響を与えるのは、ファームウェア更新です。

STM32FxテンプレートのF0用ファームウェアFW_F0は、開発当時のv1.8.0からv1.11.0へ、F1用ファームウェアはv1.4.0からv1.8.0へ、G0用ファームウェアFW_G0はv1.2.0からv1.3.0へそれぞれ更新されています。
※STM32G4テンプレートは、これから開発着手しますので最新のv.1.1.0のままです。

次章3から5章までを使って、STM32F1テンプレート:F1BaseboardTemplateを例に、当時の開発環境から最新開発環境への移設作業、ファームウェア変更、トラブルシューティングを「詳細に説明」します。但し、結果として行う処理は、6章まとめに示す簡単なものです。途中の章は読み飛ばしても構いません。

開発済みMCUアプリケーションを暫くたってから更新、または本稿のようにIDE自体が変わり最新開発環境へ移設することはよくあります。F1BaseboardTemplateをお持ちでない方も、(手前みそですが)次章から5章の内容は参考になると思います。

ファームウェア更新でコンパイルエラー発生:3章

先ず、ファームウェア起因のコンパイルエラーが発生するまでを示します。

1.SW4STM32で開発したF1BaseboardTemplateプロジェクトをCubeIDEへインポートします(インポート方法は、投稿その1-3章参照)。インポートソースコードの日本語コメントに文字化けが発生しますので、その1で示したShift-JISからUTF-8へのエンコード変換で解決します。

2.インポート済みのCubeMXプロジェクトファイルを、CubeIDEプラグイン版CubeMXで開き、Project Managerタブをクリックし、Toolchain/IDEがSTM32CubeIDEであることを確認します。インポートIDE変換が成功していれば、SW4STM32から自動的にSTM32CubeIDEへ変わっているハズです。

SW4STM32プロジェクトインポート後、プラグイン版STM32CubeMXで開いたプロジェクトファイル

ファームウェアは、最新版STM32Cube FW_F1 V1.8.0になっています。そのままProject>Generate Codeをクリックし、コード生成を実行します。

3.CubeIDEへ戻ると、(デフォルトの自動コンパイル設定だと)Lcd.cなど数か所に赤下線のコンパイルエラーが発生します。

ファームウェア起因のコンパイルエラー(赤下線)

例えば、L236のLCD_EN_Pinは、CubeMXでGPIO_PIN_8をUser Label付けしたものです。LCD_EN_Pinへカーソルを持っていき、F3をクリックすると、定義ファイルmain.hのL103へ飛び、User Label付けは問題ないことが判ります。この段階では、コンパイルエラー原因は不明です。

4.コンパイルエラーがファームウェア起因かを確認するため、ファームウェアだけをFW_F1 V1.8.0からF1BaseboardTemplate 開発当時のFW_F1 V1.4.0へ戻します。但し、CubeIDE「プラグイン版CubeMX」は、ファームウェアを旧版へ戻す機能がありません。そこで、「スタンドアロン版CubeMX」を使ってファームウェアをFW_F1 V1.4.0へ戻し、再度コード生成を行うと、コンパイルエラーは発生しません。
※スタンドアロン版CubeMXでファームウェアを元の版数へ戻す方法は、4章で説明します。

以上の作業で、コンパイルエラー原因は、ファームウェア起因であることが判りました。

STM32CubeMXコード生成ファームウェア変更方法:4章

トラブルシューティングの前に、CubeMXでコード生成ファームウェア版数を変える方法を示します。CubeMXは、旧版ファームウェアをRepositoryフォルダへ自動保存し、いつでも旧版へ戻せる準備をしています。

1.スタンドアロン版CubeMXのProject Managerクリックで表示されるダイアログ一番下のUse Default Firmware Locationの☑を外し、BrowseクリックでRepositoryフォルダ内の旧版ファームウェア:STM32Cube_FW_V1.4.0を選択します。

スタンドアロン版STM32CubeMXでファームウェア版数を変える方法

2.そのままCubeMXでコード生成を実行すると、ファームウェア版数のみを変えたソースコードが生成されます。

※CubeIDEプラグイン版CubeMX(2つ前の図)は、Use Default Firmware Location自体有りません。つまり、最新ファームウェアでのみコード生成が可能です。
※CubeMXのGenerate Reportは、コード生成時の各種パラメタをPDF形式で出力する優れた機能です。しかし、肝心のコード生成ファームウェア版数が現状では出力されません。PDF出力へ手動で使用ファームウェア版数を追記することをお勧めします。

トラブルシューティング:5章

3章コンパイルエラー発生後、つまり最新ファームウェアFW_F1 V1.8.0でのコード生成後からトラブルシューティングします。

1.CubeIDEのエラーメッセージは、Symbol ‘LCD_EN_Pin’ could not be resolvedです。main.hで定義済みなので、なぜresolveできないのか不可解です。

2.そこで、Lcd.cの#include関連を見ると、#include “UserDefine.h”はあります。
※弊社テンプレートは、UserDefine.hでツール生成以外の全てのユーザ追加定義を記述し、全ソースファイルへincludeする方式を用いています。
※一方、CubeIDEは、CubeMXで生成するmain.cソースファイル1つへ、全ての制御を記述する方式を用いています。小規模なサンプルプロジェクトなどでは、解り易い方法です。
※但し、規模が大きくなると、ソースファイルを機能毎に分離し、ファイル単位の流用性やメンテナンス性を上げたくなり、弊社は、このファイル分離方法をテンプレートに採用中です。

3.UserDefine.hに、#include “main.h”の1行を追加します。

UserDefine.hへ#include “main.h” 追加

4.Clear Project後、Build Projectでコンパイルエラーは解消し、コンパイル成功します。評価ボード:STM32F103RBでF1BaseboardTemplate の最新開発環境での正常動作確認ができます。

最新ファームウェアは、全てのユーザ追加ソースファイルに、#include “main.h”が必須なことがトラブル原因でした。

最新開発環境への移設まとめ:6章

2017年9月にSW4STM32で開発完了したSTM32Fxテンプレートは、UserDefine.hに、#include “main.h”追記で、2019年11月STM32MCU最新開発環境:STM32CubeIDE v1.1.0、STM32CubeMX v5.4.0、STM32Cube FW_F1 V1.8.0/FW_F0 V1.11.0へ移設できます。

2019年6月にSW4STM32で開発完了したSTM32G0xテンプレートは、なにもせずに、2019年11月最新開発環境:STM32CubeIDE v1.1.0、STM32CubeMX v5.4.0、STM32Cube FW_G0 V1.3.0へ移設できます。
※STM32G0xテンプレートは、初めからUserDefine.hに、#include main.hが追記済みです。

Build Analyzer

SW4STM32からCubeIDEへ移設後、最初に目に付くIDE画面の差分は、ビルド成功時、右下表示のBuild Analyzerだと思います。

STM32CubeIDEのBuild Analyzer

最初の図で示したG0AdcTemplate移設後のCubeIDE Build Analyzerを示します。RAM、FLASH使用率が一目で解ります。その他のIDE画面や操作は、旧SW4STM32と殆ど同じです。

Serial Console

CubeIDEは、Serial Console画面を持っています。従来環境では別途必要であったVirtual COM Port (VCP)用のTera Termなどのツールが不要となり、IDEだけでVCP入出力が確認できます。高まるVCP重要性が最新IDEへ反映されたと思います(関連投稿:STLINK-V3の4章)。

但し、バックグラウンドが、Tera Termの黒からSerial Console画面では白になったため、テンプレートで用いたVCP出力文字色を、デフォルトの白から黒へ変更した方が見易いです。この色変更後のSerial Consoleが下図右側です。

TeraTerm画面とSTM32CubeIDEのSerial Console画面

最新開発環境移設の課題と対策、テンプレート改版予定

現状のCubeIDE v1.1.0は、コード生成後、日本語コメントに文字化けが発生します。また、エディタタブ幅が2のまま変更できません。これら以外にも細かな不具合があります。このままでは、筆者には使いにくいIDEです。一方、Build AnalyzerやSerial Consoleは、とても役立ちます。
CubeIDEプラグイン版CubeMX v5.4.0は、Repository旧ファームウェアへの変更機能が無く、最新ファームウェアのみ利用可能です。

これら移設課題に対して、投稿その1から本稿で対策を示しました。

現状は、従来SW4STM32からCubeIDEへの「IDE移設過渡期」です。筆者は暫く両IDEを併用するつもりです。そして、新環境の使いにくい箇所が解消された時点でCubeIDEへ完全移設し、同時に汎用MCU第2位、シェア20%超のSTM32MCU向けテンプレートとしてSTM32FxテンプレートとSTM32G0xテンプレートを、本稿変更などを加え最新開発環境対応へ全面改版する予定です。

既に弊社テンプレートをお持ちの方や全面改版を待てない方は、まとめ6章の方法で移設可能です。但し、投稿その2で示した多くのリスクがありますのでお勧めはしません、自己責任で行ってください。

なお、新開発のSTM32G4テンプレートは、初めから最新CubeIDE、CubeMXで開発着手します。

*  *  *

STマイクロエレクトロニクスのSTM32CubeIDE v1.1.0改版により、旧SW4STM32開発アプリケーションを新環境へ移設する連続3回の投稿、いかがでしたでしょうか? 詳細説明がリンク先となり、筆者にしては長文投稿でしたので、解りづらかったかもしれません😌。

IoTによりMCU開発環境は、より急ピッチで変わります。最新デバイスと最新API利用が、その時点で最も効率的で優れたMCUアプリケーション開発手段です。環境急変にも柔軟対応できる開発者が求められます。

最新開発環境に上記のような課題が多少あっても、従来SW4STM32開発済みアプリケーションの最新STM32CubeIDE移設は、6章で示した1行追記のみで成功しました。

但し、顧客や管理者の方には、開発環境更新、移設の危うさや開発者の心理的負担、何よりもそれらへの対応時間は、あまり表に出てこない部分、また移設してみて初めて判る部分で理解されづらいものです。

本稿がMCUアプリケーション顧客、管理者、開発者の方々のご参考になれば幸いです。

P.S:2019年11月12日、2か月遅れでWindows 10 1909配布が始まりました。年2回のWindows 10大型更新トラブル話は多数あります。MCU開発環境は、年2回どころか度々更新されます。開発者は、その度にトラブル対処をしているのです👍。ちなみに本稿は、全てWindows 10 1903での結果です。

モバイルバージョンを終了