STマイクロエレクトロニクス（以下STM）の統合開発環境：STM32CubeIDEが、v1.1.0に更新され、前投稿：その1では、従来SW4STM32プロジェクトをSTM32CubeIDEインポート時の日本語文字化け対策と、最新STM32MCU開発環境を示しました。
その2では、最新開発環境での文字化けと、開発環境更新リスク、ファームウェア更新へのリスク対応案について示します。
最新開発環境の文字化け
2019年11月時点のSTM32MCU最新開発環境と、IDEのみ従来のSW4STM32を使ったソフトウェア開発環境が下図です。
その1で示したSW4STM32プロジェクトインポート時のSTM32CubeIDEソースコード文字化けは、Shift-JISからUTF-8への手動エンコード変換で解決しました。
今回指摘する問題は、最新環境であってもSTM32CubeMX（以下、CubeMX）でコード再生成すると、STM32CubeIDE（以下、CubeIDE）ソースコードに日本語文字化けが発生することです。
このCubeMX起因の文字化けは、新規CubeIDEプロジェクト作成でも発生します。つまり、CubeIDEでプロジェクトを新規作成しmain.cへ日本語コメントを入力、次に生成済みCubeMXプロジェクトファイルを開き初期化コードを生成、CubeIDEへ戻ってmain.cを見ると日本語コメントに文字化けが発生します。
※スタンドアロン版、プラグイン版両方のCubeMXを試し、また、表示フォントもいろいろ変更しましたが、文字化けが発生します。対策がお判りの方は、教えてください😌。
もちろん、英語でコメント記入すれば問題はありません。日本語コメントの場合のみです。
一方、従来IDEのSW4STM32へCubeMX出力の場合には、文字化け無しです。ソースコードへ日本語コメントを追記する筆者のような方は、文字化け発生が解消されるまでは、SW4STM32とCubeIDE併用が良いかもしれません。
開発環境更新リスク
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テンプレートを使って、最新開発環境への移設実例、トラブル対応を示します。