STマイクロエレクトロニクスの統合開発環境：STM32CubeIDEがv1.3.0に更新されました（2月28日、更新自動通知メールにて把握）。デフォルト設定のWindows版STM32CubeIDEは、エディタで追記した日本語コメントに文字化けが発生します。これは、昨年投稿したSTM32CubeIDE v1.1.0やv1.2.0と同じで、最新版でも解決されません。

そこで、対策にデフォルト設定を2か所変え、日本語文字化け解決を確認しました。また、Linux Debian版STM32CubeIDEとSW4STM32は、最新環境でもデフォルトで文字化けが無いことも確認しました。

Windows版STM32CubeIDE日本語文字化け発生箇所

2019年4月新登場STマイクロエレクトロニクス統合開発環境：STM32CubeIDE-Winの日本語コメント文字化けは、

SW4STM32プロジェクトのSTM32CubeIDEインポート後
プラグイン版STM32CubeMXでのコード再生成時

に、エディタでソースコードに追記した日本語コメントに文字化けが発生します。
※Windows版は、Windows 10 Pro 1909の話です。

STM32CubeIDE-Win v1.3.0日本語文字化け対策

数回のメジャー更新を経て登場後約1年のv1.3.0でも、この文字化けはデフォルトのままでは未解決です。そこで、ネット検索したところ、コチラの対策を得ました。

STM32CubeIDEのデフォルト設定を、2か所変更します。

フォント設定を、デフォルトConsolasからメイリオなどの日本語文字セットへ変更（ワークスペース毎）
Text file encoding設定を、デフォルトUTF-8からShift-JISへ変更（プロジェクト毎）

※1は、STM32CubeIDEのWindowタブ＞Preferenceダイアログ検索窓へ”font”入力＞Colors and Font選択>C/C++選択＞Editor選択＞C/C++ Editor Text Fontを選択し、Edit…クリックで左図表示
※2は、プロジェクト選択＞Propertiesクリックで右図表示

右図のようにプルダウンメニューにShift-JIS選択肢が無い時は、Shift-JISと直接入力し、Apply and Closeをクリックします。

1はワークスペース毎、2はプロジェクト毎に設定が必要です。

これら2か所の変更で、SW4STM32プロジェクトインポート後とSTM32CubeMXコード再生成時、どちらもエディタ追記日本語コメント文字化けは解決できました。

以上で、従来のSW4STM32から新しいSTM32CubeIDEへ、日本語コメント文字化け無しにSTM32MCU開発環境を移行できます。

STM32CubeIDE特徴

STM32CubeIDEは、コード生成ツール：STM32CubeMX、開発デバイスファームウェア（弊社ならFW_F0/F1/G0/G4）全てを1パッケージ化し、全て最新版のみを提供する特徴があります。投稿時のSTM32CubeIDE v1.3.0が下図です。

簡単に言うと、開発ソフトウェアが全てSTM32CubeIDEへプラグインされた形式です。

STM32CubeIDE起動時、またはCheck for Updatesにより、IDEを含めた各プラグイン更新を確認し、常に最新開発環境となります（悪名高いWindows Updateに似ているような…😅）。

これは、プラグイン版STM32CubeMX v5.6.0に、旧ファームウェア選択機能が無いことからも解ります。

最新ファームウェアを使うSTM32CubeMXプラグイン版（左）とファームウェア選択可能なスタンドアロン版（右）

例えば、顧客先で稼働中ソフトウェアへ変更を加えるなど旧ファームウェアのまま開発希望の場合は、スタンドアロン版STM32CubeMX v5.6.0を使えば、右図のように旧ファームウェア選択も可能です（関連投稿：v1.2.0の開発環境更新リスク、ファームウェア更新リスク回避策の章に背景説明があります）。

純正STM32Cubeツール

STM32MCUソフトウェア開発に使えるIDEは、下図中央のようにIAR：Embedded Workbench、ARM：Keil、AC6：SW4STM32、etc.などサードパーティ製も数多くあります。しかし、純正STM32CubeツールのSTM32CubeIDEが、STマイクロエレクトロニクス一押しの統合開発環境だと思います。

STM32 Software Development Tools（出典：STMサイトに加筆）

もちろん、従来からあるSW4STM32もまだ現役（Active）です。ST Communityには、今も多くのSW4STM32事例があります。

そこで、Windows版STM32CubeIDE以外の、SW4STM32とLinux Debian版STM32CubeIDEの現状を調べました。

STM32CubeIDE-DEB

64ビット版のみですが、STM32CubeIDE v1.3.0のLinux Debian版インストーラが、Windows版STM32CubeIDEと同じ純正ソフトウェア入手サイトにあります。

筆者は、DebianよりもMintが好きなので、STM32CubeIDE-DEBをLinux Mint 19.3 MATE (64-bit)へインストールし、デフォルト設定でも日本語文字化け無し、評価ボードで正常動作することを確認しました。

Mintへのインストール方法が下記です。途中で長いライセンス同意を求められます。

chmod +x st-stm32cubeide_1.3.0….sh
sudo ./st-stm32cubeide_1.3.0….sh、または、sudo bash st-stm32cubeide_1.3.0….sh
※NXP：MCUXpresso IDE v11.1.0のInstallation Guide, Appendix A – Linux Installationを参考にしました。

STM32CubeMXやデバイスファームウェアは、Windows版と同様全てプラグインです。Linux版SW4STM32既成プロジェクトが手元に無いのでインポートは試せませんが、問題無いと思います。

リリースノート：RN0114のLinux動作テスト環境にMintは有りません。自己責任でNXP：MCUXpresso IDE v11.1.0 Linux版ともども、Mint上でSTM32CubeIDE-DEBが正常動作したことをお知らせします。

SW4STM32とスタンドアロン版STM32CubeMX v5.6.0

SW4STM32とスタンドアロン版STM32CubeMX v5.6.0で開発環境を構築する場合は、デフォルトでも日本語文字化けは発生しません。従来環境に慣れた方は、SW4STM32もそのまま使えると思います。

お知らせ：STM32FxテンプレートとSTM32G0xテンプレート改版予定

STM32CubeIDE-Win v1.3.0に加えた本稿2か所変更が、次版以降のSTM32CubeIDEにも必要かは判りません。ただ、いまさらShift-JIS設定？という気はします。WindowsでShift-JIS継続利用の弊害は、コチラの記事がよく解ります。

しかし、懸案であった日本語コメント文字化けが解決、新登場後1年経過しv1.3.0となったこのタイミングで、従来SW4STM32から新しいSTM32CubeIDEへ開発環境を乗換えるのもチャンスだと思います。SW4STM32更新頻度が減ったことや、他の純正STM32Cubeツールとの相性良さも期待できるからです。

そこで、SW4STM32で開発・販売したSTM32FxテンプレートとSTM32G0xテンプレートを、STM32CubeIDE-Winを使って再開発に着手し、新にVersion 2として販売する予定です。進行状況などは、本ブログでお知らせします。

STマイクロエレクトロニクス（以下STM）の統合開発環境：STM32CubeIDEが、v1.1.0に更新され、前投稿：その1では、従来SW4STM32プロジェクトをSTM32CubeIDEインポート時の日本語文字化け対策と、最新STM32MCU開発環境を示しました。

その2では、最新開発環境での文字化けと、開発環境更新リスク、ファームウェア更新へのリスク対応案について示します。

開発環境更新リスク

MCU開発ソフトウェア（＝アプリケーション）への影響が一番大きいのは、ファームウェア：FW_F0/F1/G0/G4更新です。統合開発環境：CubeIDEやコード生成ツール：CubeMXの更新は、操作性や見た目へ変化を与えますが、アプリケーションそのものへの影響は、少ないです。

MCUアプリケーション開発は、STM32MCUに限らずベンダ提供API：Application Programming Interfaceのユーザ開発アプリケーションによる操作です。ファームウェア更新は、このベンダ提供APIのバグ取りや、新デバイス追加に関連するものが一般的です。開発済みユーザアプリケーションの場合は、デバイスは変わらないので、ファームウェア更新による影響があるのは使用中APIです。

従って、開発したアプリケーションの使用APIが変わらなければ、ファームウェア更新は問題ないハズです。

ところが、稀にファームウェア更新により正常に動作していたAPIにも影響が生じトラブルが発生することがあります。ファームウェア更新には、このリスクがあることも知っておきましょう。
※このリスク対策としてCubeMXは、旧版ファームウェアをRepositoryフォルダへ保存し、いつでも旧版へ戻せる準備をしています。

ベンダAPI、つまりファームウェア互換性には期待しない方が無難です。

理由は、最新ベンダMCU製造プロセス（＝ハードウェア）、WindowsなどのパソコンOS、ベースのEclipse IDE、ARM CMSISなどのアプリケーション下層の更新、などなど様々なバージョンアップの組合せ結果が、ベンダAPI更新や刷新となるからです。

ベンダAPI互換が、既存ユーザにとっては理想です。しかし、元々非力なMCU能力を、従来API互換へ使うよりも、むしろファームウェア更新時点で、MCU能力を最も引き出すAPIへ使い、新規ユーザへアピールしたいとベンダが判断してもやむを得ないと思います。
※高性能MPU/GPUでさえAPI互換が無いことがあります。APIとは、そういうものだと割切って、例えAPIが変わっても柔軟に対応できるソフトウェア開発者が求められるのかもしれません。

ファームウェア更新リリースノートに、このAPI互換性の詳細説明を求めるのは、多分無理です。既存ユーザは、開発環境、特にファームウェア更新に関しては、慎重に対処すべきだと思います。

MCUアプリケーションは、開発完了時の開発環境依存度が非常に高いソフトウェアです。

最新デバイスと、最新APIの組合せが、その時点で最も効率的で優れたMCUアプリケーション開発手段と言えます。
※ルネサスのCS+には、アプリケーション開発完了時の開発環境を、一括圧縮保存する便利機能があります。Eclipse IDEにもプラグインで同様の機能を追加できると思います。

ファームウェア更新リスク回避策

筆者が考えるMCUアプリケーション開発に対するファームウェア更新リスクの回避策が、下記です。

ユーザ開発アプリケーションが顧客システムで稼働中、しかもバグなどの問題が無い場合は、あえて前章リクスがあるファームウェア更新はしない
アプリケーション開発が進行中の場合は、旧版ファームウェアで開発継続し、完成後に最新版を試す
開発済みアプリケーションへ機能追加の場合は、開発時ファームウェアで機能追加し、完成後に最新版を試す
新にアプリケーション開発を始める場合は、APIバグ可能性のより少ない最新ファームウェア開発環境で着手

開発完了から時間が経ったアプリケーション改版時には、開発当時のファームウェア更新への対策時間も加味しスケジュールを作成することをお勧めします。さもないと、肝心のアプリケーション改版前の段階でつまずいてしまいます。

※弊社販売中テンプレートは、テンプレート応用例として、評価ボード実装済みSWやLEDを制御するシンプルテンプレートと、Baseboardで各種機能を追加したBaseboardテンプレートの2つを添付しています。このうちBaseboardテンプレートは機能豊富な代償として、上記ファームウェア更新リスクに出会うことが稀にあります😫。テンプレートなので、本当は原理を解っていただくシンプルテンプレートのみを添付したいのですが、Baseboardテンプレート付きの方が売れるのでやむを得ない状況です😥。

投稿その１、その２と前振りが長くなりました。次回、汎用MCUシェア第2位の販売中STM32FxテンプレートやSTM32G0xテンプレートを使って、最新開発環境への移設実例、トラブル対応を示します。

タグ: ファームウェア

STM32CubeIDE更新、文字化け解決