Cortex-M0からCortex-M0+変化

前稿で示したNXP MCUラインナップ図には、ARM Cortex-M0/M0+両方のコアが掲載中でした。しかし、最新版MCUXpresso IDEのコア選択ダイアログには、Cortex-M0選択肢がありません。

MCUXpresso IDEのコア選択ダイアログ
MCUXpresso IDEのコア選択ダイアログ

そこで、Cortex-M0+とCortex-M0の違いを調べた結果、新規MCU開発にNXPのCortex-M0コアを使う必然性は低いという結論に達しました。本稿は、その根拠を示します。

ARM Cortex-M0+とCortex-M0の差

弊社関連投稿:Cortex-M0/M0+/M3比較とコア選択や、ARMコア利用メリットの評価ARM MCU変化の背景をまとめ、ARMコアの発表年順に示したのが下表です。※M4の発表年は間違っているかもしれませんが、市場に出回ったCortex-Mxコアの順番は下表で正しいハズです😌。

ARM Cortex-Mx性能、発表年
Cortex-Mコア 性能 (MIPS @ MHz) ARM発表年 MCUモデル
Cortex-M3 1.25 2004 旧メインストリーム
Cortex-M0 0.9 2009 ローコスト
Cortex-M0+ 0.95 2011 ローパワー
Cortex-M4 1.25 2012頃 デジタル信号処理新メインストリーム

要するに、Cortex-M0+やCortex-M4は、Cortex-M0やCortex-M3をベースに市場ニーズに即した変更を加えた新しいARMコアだと言うことです。本稿では、特にCortex-M0+とM0の違いに注目します。

Cortex-M0+には、表の差以外にも高速IOアクセス、高速パイプライン、低消費動作モードなどCortex-M0には無い数々の特徴がありますが、Cortex-M0よりも高性能(0.9→0.95MIPS@MHz)で、シリコンチップ高速化にも好都合です。

つまり、新規開発にCortex-M0+の代わりに敢えてCortex-M0コアを用いる理由は、見当たらない訳です。

NXPの新しい統合開発環境MCUXpresso IDEのSDKのコア選択肢に、Cortex-M0が無いのは、上記が理由だと思います。※ローコストに関しては、コア単体の相対評価はできても、使用数量でかなり変動するためMCUコスト絶対評価を難しくしています。

NXP MCUXpresso SDK対応評価ボード数

最新MCUXpresso IDE v11.1.1のSDKで対応中の評価ボード数を一覧にしました。例えば、Cortex-M33コアなら下図のように7個です。

MCUXpresso SDK対応評価ボード数(Cortex-M33の場合)
MCUXpresso SDK対応評価ボード数(Cortex-M33の場合)
MCUXpresso SDK対応評価ボード数比較(2020-07)
MCUXpresso SDK対応評価ボード数比較(2020-07)

評価ボードは、プロトタイプ開発には必須で、その評価ボードで動作するSDK(Software Development Kit)があればソフトウェア開発効率は向上します。Cortex-Mxコア間のソフトウェア移植性は高く、同じコアのソフトウェアであれば、異なる評価ボードへの移植もさらに容易です。

つまり、評価ボード数が多いCortex-M0+やCortex-M4が、現在最もCortex-Mxコアソフトウェア開発効率が高いことを示しています。また、Cortex-M3コア選択肢がない理由も、Cortex-M0コアがない理由と同じと推測します。

本当の並列処理が要求されるマルチコア開発なら、Cortex-M0+とM4のペア、または、IoTセキュリティを強化したCortex-M33コアx2であることも判ります。※Cortex-M33は、2016年ARM発表のセキュリティ強化コアです。

新規ARM Cortex-Mxソフトウェア開発は、Cortex-M0+コアまたはCortex-M4コア利用に収束してきたと思います。
※Cortex-M33コアは、従来コアに無いIoT向けセキュアゾーンなどが新規機能追加されていますので除外しています。

弊社テンプレート開発方針

前稿のNXP MCUラインナップからCortex-M0とCortex-M3を除き、現状SDK提供中のARM Cortex-Mxコアラインナップをまとめると下図になります。※Cortex-M33は未掲載です。

Software Development Kit開発から見たNXP MCUラインナップ
Software Development Kit開発から見たNXP MCUラインナップ

弊社もCortex-M0+、Cortex-M4、Cortex-M33コア向けのテンプレート開発を進める方針です。


STM32G0/G4のRoot of Trust(2)

STM32G0/G4シリーズRoot of Trust実現の第2回目は、初めにRoot of Trustを実現するセキュア・ブートの説明にトライし、直にセキュア・ブートとセキュア・ファームウェア更新を実装するSTM32G4テンプレート開発環境の構築方法を示します。

セキュア・ブート説明をこまごま続けるよりも、具体的なRoot of Trust実現開発環境を示す方が、実務的(短絡的?)だからです。

セキュア・ブート

第1回紹介の日本語版UM2262、P1概要:セキュア・ブート説明を抜粋したのが以下です。

‘セキュア・ブート(信頼の起点となるサービス)は、システムリセット後に必ず実行される改変不可のコードで、無効なコードや悪意のあるコードを実行しないために、実行前に毎回STM32の静的保護を確認し、STM32実行時保護を有効化してから、ユーザアプリケーションコードの認証および整合性を検証します。’

英語直訳で難解です(各単語の事前理解が必要なセキュリティ関連説明は、殆どがこんな感じですが…)。

ただ、下線部:「必ず実行される改変不可のコード」なので、理解不足や多少間違って解釈しても、セキュア・ブートコードを実装すれば、それで十分かもしれません😅。

セキュア・ブート解釈

図1.セキュアブートの信頼の起点(出典:UM2262)
図1.セキュアブートの信頼の起点(出典:UM2262)

要は、ユーザが開発したアプリケーション実行前に、MCUが勝手に行うブート処理のセキュリティを高度にしたものがセキュア・ブート(SB)だと解釈します。

従来のブート処理は、リセット後、MCU内蔵クロック発振器の安定化待ちやRAM領域初期化などの処理を何の疑いもなく実行し、その後、ユーザ開発アプリケーションを起動していました。

セキュア・ブート処理は、前章のセキュア・ブート処理を行い(図1.①)、その結果をUM2262:9章の表6. 起動時エラーメッセージ(下表)で示すように認証し②、「エラーなし。成功。」時のみ、③ユーザ開発アプリケーションを起動します。

表6. セキュア・ブート起動時のエラーメッセージ(出典:UM2262)
表6. セキュア・ブート起動時のエラーメッセージ(出典:UM2262)

パソコンで例えると、従来ブートがBIOS起動、セキュア・ブートがUEFI起動に相当すると考えれば良いのかもしれません。

X-CUBE-SBSFUはHAL API補完

Root of Trust実現で使うSTM32Cube拡張パッケージ:X-CUBE-SBSFUは、STM32MCU間の移植性を重視しているためHAL(Hardware Abstraction Layer)ベースです。

弊社発売中のSTM32G0xテンプレート(Version1)は、高速性を活かすエキスパート向けLL(Low layer)APIが「主」、HAL APIは「従」としてSW4STM32で開発しました。しかし、STM32G0でのRoot of Trust実現には、HALベースのソフトウェア開発が適しています。

LL/HAL混在利用は、関連投稿:STM32CubeMXのLow-Layer API利用法 (2)の4章で示した注意が必要です。X-CUBE-SBSFUは、アプリケーション起動前のHAL利用で、起動後のユーザアプリケーションのLL利用の場合は、問題ないかもしれません。この点は、今後明らかにしていきます。

いずれにせよSTM32G0xテンプレートは、IDEをSW4STM32から新しいSTM32CubeIDEへ移設すると同時に、Root of Trust実現に向けHAL APIも「主」とし、STM32CubeIDEで「再開発」してVersion 2に改版する予定です。

セキュリティ関連の説明はここまでにして、STM32G4シリーズでRoot of Trust実現の具体的方法に移ります。

Root of Trust実現STM32G4テンプレート開発環境

Root of Trust実現にセキュア・ブート(SB)機能とセキュア・ファームウェア更新(SFU)機能を実装する汎用STM32G4シリーズのテンプレート開発環境は、以下とします。

  • 統合開発環境:STM32CubeIDE v1.3.0、2020/02/26
  • STM32Cube拡張パッケージ:X-CUBE-SBSFU v2.3.0、2020/01/17
  • STM32G4評価ボード:NUCLEO-G474RE(Cortex-M4/170MHz、Flash/512KB、RAM/128KB)

この環境で実現するセキュリティ機能が、UM2262の6.1概要に記載されたものです。これら機能理解に不明確な部分もありますが、内容把握済み、これら機能実現ためX-CUBE-SBSFUを使うと割切ります。開発環境を使っているうちに、(多分)理解度が上がるでしょう😅。

なおUM2262日本語版は、英語版Rev5からの翻訳なのでサポートIDEにSW4STM32はありますが、新しいSTM32CubeIDEがありません。しかし、最新英語版UM2262 Rev6に、STM32CubeIDEが追加されましたので本ブログでもSTM32CubeIDEを使います。

また、セキュリティ機能をテストするNUCLEO-G474RE用サンプルアプリケーションもX-CUBE-SBSFUに添付されていますので、これを以降の説明に使います。

UM2262では、STM32CubeIDEを使ったRoot of Trust開発環境の構築手順が判りにくいので、以下に説明を加えます。

構築手順1:STM32CubeIDEへのRoot of Trust SW4STM32プロジェクトインポート

X-CUBE-SBSFU v2.3.0には、SW4STM32プロジェクトが添付されていますが、未だSTM32CubeIDEプロジェクトの添付はありません。

そこで、STM32CubeIDEのInformation CenterからImport SWSTM32 projectをクリックし、X-CUBE-SBSFU添付SW4STM32プロジェクトを変換(Import)し、STM32CubeIDEプロジェクトを新規作成します。

STM32CubeIDEのSW4STM32プロジェクトインポート
STM32CubeIDEのSW4STM32プロジェクトインポート

STM32G4評価ボード:NUCLEO-G474REのSW4STM32プロジェクト6個を、STM32CubeIDEへインポートする時のダイアログです。

Finishクリックで、プロジェクト毎に下図2回の同意を求められますので、OKをクリックします。

STM32CubeIDE Projects Converter
STM32CubeIDE Projects Converter

構築手順2:Root of Trustサンプルアプリケーションのコンパイル

インポートした6個のプロジェクトは、シングルファームウェアイメージ:NUCLEO-G474RE_1_Imageとデュアルファームウェアイメージ:NUCLEO-G474RE_2_Imageの2種類のサンプルアプリケーションです。

2種類のRoot of Trustサンプルアプリケーション
2種類のRoot of Trustサンプルアプリケーション

シングル/デュアルファームウェアイメージの違いは、次章で説明します。

このサンプルアプリケーションは、それぞれ図15のように、_SECoreBin、_SBSFU、_UserAppの順番でプロジェクトをコンパイルする必要があります。図示のように前段コンパイル生成出力を、次段コンパイル入力に使うからです。

図15. アプリケーションのコンパイルステップ(出典:UM2262)
図15. アプリケーションのコンパイルステップ(出典:UM2262)

この順番を守ってコンパイルした時のみ_UserAppの出力オブジェクトが生成されます。

Windowsセキュリティソフト(Avastなど)によっては、コンパイル途中でワーニングを出力することがありますが、暫く待つとコンパイルを継続します。

シングルファームウェアイメージとデュアルファームウェアイメージ

図15は、SBSFU処理後のFlashメモリ配置を示しています。

図15の右側黄色部分:アクティブなイメージ領域だけをSFU処理で使うサンプルアプリケーションが、シングルファームウェアイメージです。右側黄色部分の上側、イメージのダウンロード/バックアップ領域に、図2のネットワーク(②通信チャネル)経由の新しいファームウェアを一旦入れるのが、デュアルファームウェアイメージです。

図2.セキュアファームウェア更新プロセス(出典:UM2262)
図2.セキュアファームウェア更新プロセス(出典:UM2262)

デュアルファームウェアイメージは、SFU処理中に電源断で中断しても、電源復帰後にSFU継続が可能です。また、アクティブなイメージ領域で動作中アプリケーションと並行してダウンロードが可能です。

シングルファームウェアイメージは、新しいファームウェアを、アクティブなイメージ領域上へ直接更新します。

デュアルファームウェアイメージは、フェールセーフな分、Flash容量はシングル比、倍必要になります。一方、シングルファームウェアイメージは、ユーザが使えるFlash容量が大きいので、デュアルよりも大きなアプリケーション開発ができます。

※ここで使ったセキュリティ用語:ファームウェアイメージとは、STM32CubeIDEのコード生成ツールSTM32CubeMXがデバイス毎に用いるファームウェア(弊社ならFW_F0/F1/G0/G4)とは別物です。図15の黄色部分を示します。

*  *  *

以上で、STM32CubeIDEを使ったRoot of Trust実現のセキュア・ブート(SB)、セキュア・ファームウェア更新(SFU)機能を持つSTM32G4テンプレート開発環境の構築と、SBSFUに使うシングル/デュアルファームウェアイメージの2種サンプルアプリケーションを説明しました。

次回、このSTM32G4テンプレート開発環境とデュアルファームウェアイメージのサンプルアプリケーションを使って、Root of Trust実現の動作説明を予定しています。

STM32G0/G4のRoot of Trust(2)まとめ

  • 信頼の起点:セキュア・ブート(SB)は、リセット後に必ず実行される改変不可能コード。
  • SB処理後、エラーなし認証時のみ、ユーザアプリケーション起動。
  • STM32Cube拡張パッケージ:X-CUBE-SBSFUは、HAL API補完。
  • STM32CubeIDEでRoot of Trust実現のセキュア・ブート(SB)、セキュア・ファームウェア更新(SFU)機能実装STM32G4テンプレート開発環境と構築手順説明。
  • SBSFUアプリケーションのデュアルファームウェアイメージとシングルファームウェアイメージの特徴説明。

SB、SFU実現には、暗号化や図1/2/15掲載の鍵、セキュアエンジンなど、本稿で説明を省いた(すっ飛ばした)様々なセキュリティ処理が必要です。UM2262付録の章に、これら詳細が記載されています。

本質的なセキュリティ理解には、これら各処理の理解積重ねが必要だと思います。付録の章を一読しておくと、今後いろいろな場面で役立ちます。

STM32G071RBとAlexaを繋ぐ

1月9日STマイクロエレクトロニクス(以下STM)公式ブログに、STM32G0とAlexa(アレクサ)を接続する開発キット:Alexa Connect Kit(ACK)モジュールが紹介されました。アレクサに話しかけ、STM32G0評価ボードのNucleo-G071RB 経由でスマートホーム制御が簡単に実現できます。

システム構成

STM32G071RBとAlexaを接続するAlexa Connect Kit (ACK)のシステム構成
STM32G071RBとAlexaを接続するAlexa Connect Kit (ACK)のシステム構成

システム構成の公式ブログ掲載が無いので、自作したのが上図右側です(左側出典:STMサイト、Cortex-M7 MCUでアレクサ接続)。

USI MT7697HがACKモジュールで、Nucleo-G071RBとはArduinoコネクタで接続します。スマートスピーカに話しかけると、クラウド内で音声解析→制御コマンド生成を行い、このコマンドがACKへ無線送信され、STM32G0評価ボードNucleo-G071RBへ届き、STM32G071RBがスマートホーム機器などを制御します。

費用とSTM32G0用ACKドライバ、ファームウェア

費用:Nucleo-G071RBが約$10、ACKがUS Amazonで$197、(日本アマゾンで¥38,202)。

STM32G0用ACKドライバ、ファームウェア:公式ブログリンク先は、今日現在、提供されていません。

2018年6月頃は、STM32F7やSTM32H7などの高性能Cortex-M7 MCUでアレクサ接続がSTM公式ブログで投稿されましたが、今回Cortex-M0+のSTM32G0とACKでも簡単に接続可能になりました。

STM32G0特徴

2018年12月新発売のSTM32G0シリーズは、初の90nmプロセス製造MCUで低消費電力と高速動作、従来のSTM32F0 (Cortex-M0)~F1 (Cortex-M3)性能をカバーする新しい汎用MCUです。セキュリティハードウェア内蔵、低価格、64ピンパッケージでも1ペアVDD/VSS給電がSTM32G0の特徴です。
関連投稿:STM新汎用MCU STM32G0守備範囲が広いSTM32G0

STM32マイコンマンスリー・アップデート2020年1月のP4に、「STM32G0 シリーズのラインナップ拡充 STM32G041/ G031/ G030 新登場」記事もあります。筆者も、STM32G0シリーズは、STMの汎用MCUとしてお勧めデバイスです。

LL APIかHAL API、混在?

残念ながら今は未提供ですが、筆者は、ACKドライバとファームウェアのAPIに興味があります。

理由は、STM32G0シリーズの高性能を引き出すには、HAL:Hardware Abstraction Layer APIよりもエキスパート向けLL:Low Layer API利用ソフトウェア開発が適すからです。

HALとLL比較(出典:STM32 Embedded Software Overvire)
HALとLL比較(※説明のため着色しています。出典:STM32 Embedded Software Overvire)

生産性や移植性の高いHAL APIとLL APIの混在利用は、注意が必要です(関連投稿:STM32CubeMXのLow-Layer API利用法 (2)の4章)。

ACKドライバ、ファームウェアが、LL APIかHAL APIのどちらを使っているか、または混在利用かを確認し、ノウハウを取得したかったのですが…😥。

LL API利用STM32G0xテンプレートとHAL API利用STM32Fxテンプレート

弊社は、LL API利用STM32G0x専用テンプレートと、HAL API利用STM32Fx汎用テンプレートの2種類を、それぞれ販売中です(テンプレートは同一、テンプレートを使うAPIのみが異なる)。

STM32汎用MCUラインナップ
STM32汎用MCUラインナップ(出典:STM32 Mainsterm MCUsに加筆)

もちろん、STM32G0でもHAL APIを利用することは可能です(STM32G0x専用テンプレートにもHAL API使用例添付)。LL API利用ソフトウェアは、性能を引き出す代償に対象MCU専用になります。

HAL APIとLL APIの混在は避けた方が無難で、STM32G0はLL API専用でテンプレート化しました。添付資料も、LL APIを中心に解説しています。STM32Fxテンプレート添付資料は、HAL API中心の解説です。

両テンプレートをご購入頂ければ、LL/HAL双方のAPI差が具体的に理解できます。開発するアプリケーション要求性能や発展性に応じて、LL APIかHAL APIかの選択判断も可能になります。
※両テンプレート同時購入時は、2個目テンプレート50%OFF適用で、1500円(税込)です😀。

FYI:日本語コメント文字化け継続

STMマイコン開発環境にソースコード日本語コメントの文字化けが発生中であることを、昨年11月に投稿しました。この文字化け発生のSTM32CubeIDE v1.1.0/CubeMX v5.4.0開発環境が、STM32CubeIDE v1.2.0STM32CubeMX v5.5.0に更新されました。

更新後のSTM32CubeIDE v1.2.0/CubeMX v5.5.0でも、旧版同様に文字化けします。
一方、SW4STM32では、STM32CubeMX v5.5.0更新後も日本語コメント文字が正常表示されます。

他社の最新版EclipseベースIDE、NXPのMCUXpresso IDE v11.1.0や、CypressのPSoC Creator 4.2では、ソースコードText Font変更をしなくても文字化けはありませんので、STM特有問題だと思います。

ワールドワイドでの日本相対位置低下、今年から始まる小学校英語教育…、日本ものつくりは、英語必須になるかもしれません。

ARM MCU変化の背景

昨今のARM MCU事情、そして今後の方向性”という記事が、2019年11月22日TechFactoryに掲載されました。詳細は記事を参照して頂き、この中で本ブログ筆者が留意しておきたい箇所を抜粋します。その結果、ARM MCU変化の背景を理解できました。

現在のARM MCUモデル

Cortex-Mコアだけでなく、周辺回路も含めた組み合わせARM MCUモデルが、端的に整理されています。

・メインストリームは、Cortex-M4コアに周辺回路搭載
・ローパワーは、Cortex-M0+に低消費電力周辺回路搭載
・ローコストは、Cortex-M0に周辺回路を絞って搭載

例えば、STマイクロエレクトロニクスの最新STM32G0xシリーズのLPUART搭載は、ローパワーモデルに一致します。各Cortex-Mコアの特徴は、コチラの投稿の5章:Cortex-M0/M0+/M3の特徴などを参照してください。

ARM MCUの新しい方向性

2019年10月時点で記事筆者:大原雄介氏が感じた今後のARM MCU方向性が、下記4項目です。

  1. ハイエンドMCU動作周波数高速化、マルチコア化
  2. RTOS普及
  3. セキュリティ対応
  4. RISC-Vとの競合

以下、各項目で本ブログ筆者が留意しておきたい箇所を抜粋します。

1.ハイエンドMCU動作周波数高速化、マルチコア化

動作周波数高速化は、NXPのi.MX RT 1170のことで、Cortex-M7が1GHzで動作。i.MX RT1170は400 MHz動作のCortex-M4も搭載しているディアルコアMCU。

これらハイエンドMCUの狙いは、性能重視の車載MCU比べ、コスト最重視の産業機器向け高度GUIやHMI:Human Machine Interface用途。従来の簡単な操作パネルから、車載のような本格的なGUIを、現状の製造プロセスで提供するには、動作周波数の高速化やマルチコア化は必然。

2.RTOS普及

普通はベアメタル開発だが、アプリケーション要件でRTOS使用となり、ポーティング例は、Amazon FreeRTOSが多い。マルチコアMCUでは、タスク間同期や通信機能実現には、ベアメタルよりもRTOS利用の方が容易。また、クラウド接続は、RTOS利用が前提となっている。

3.セキュリティ対応

PAS:Platform Security Architectureというセキュリティ要件定義があり、これが実装済みかを認証するPSA Certifiedがある。PAS Certified取得にはTrustZoneを持つATM v8-MコアCortex-M23/33が必須ではなく、Cortex-M0やM4でも取得可能。但し、全MCUで取得するかは未定で、代表的なMCUのみになる可能性あり。

4.RISC-Vとの競合

ARM CMSISからずれるCustom Instruction容認の狙いは、競合するRISC-Vコアへの対抗措置。RISC-V採用製品は、中国では既に大量にあり、2021年あたりに日本でもARMかRISC-Vかの検討が発生するかも?

ARM MCU変化背景

本ブログ対象の産業機器向けMCUの1GHz動作や、ディアルコアMCUの狙いは、ADAS(先進運転支援システム)が引っ張る車載MCU+NVIDIA社などのグラフィックボードで実現しつつある派手なGUIを、10ドル以下のBOM:Bill Of Matrixで実現するのが目的のようです。また、産業機器向のMCUのAIへの対応も気になる点です。これにら向け、各種ツールなども各ベンダから提供されつつあります。

ハイエンドMCU開発でRTOS利用が一般的になれば、下位MCUへもRTOSが利用される場面は多くなると思います。タクス分離したRTOSソフトウェア開発は、タスク自体の開発はベアメタルに比べ簡単で、移植性や再利用性も高いからです。ベアメタル開発は、RAMが少ない低コストMCUのみになるかもしれません。

RTOS MCU開発も、Windowsアプリケーション開発のようにOS知識が(無く!?)少なくても可能になるかもしれません。

MCUベンダのセキュリティ対応は、まだ明確な方針が無さそうです。RTOSと同様、IoTアプリケーション要件がポイントになるでしょう。総務省による2020年4月以降IoT機器アップデート機能義務化予定などもその要件の1つになる可能性があります。

Custom Instructionは、コチラの投稿の5章でベンダ独自のカスタム命令追加の動きとして簡単に紹介しましたが、その理由は不明でした。これが、競合RISC-Vコアへの対抗策とは、記事で初めて知りました。

本ブログ記事範囲を超えた、広い視野でのMCU記事は貴重です。

来年開発予定のベアメタルCortex-M4テンプレートへ、RTOSの同期や通信機能を簡易実装できれば、より役立ち、かつRTOS普及へも対抗できるかもしれないと考えています。クラウド接続IoT MCUは、Amazon FreeRTOSやMbed OS実装かつ専用ライブラリ利用が前提なのは、ひしひしと感じています。

STM32CubeIDE v1.1.0更新と文字化け対策(その2)

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

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

最新開発環境の文字化け

2019年11月時点のSTM32MCU最新開発環境と、IDEのみ従来のSW4STM32を使ったソフトウェア開発環境が下図です。

STM32MCU最新開発環境
STM32MCU最新開発環境

その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アプリケーション開発に対するファームウェア更新リスクの回避策が、下記です。

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

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

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

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

ARM Cortex-M4プロトタイプテンプレート構想

弊社は、ARM Cortex-M4コア使用のLPC5410x(NXP)、STM32G4(STM)、PSoC 6(Cypress)、MSP432(TI)各社のMCUテンプレート開発を目指しています。本稿は、各社共通のCortex-M4プロトタイプテンプレート開発指針を示します。

MCUプロトタイプ開発ステップ

MCUプロトタイプ開発と製品化へのステップ、支援ツール
MCUプロトタイプ開発と製品化へのステップ、支援ツール

プロトタイプからMCU製品開発へのステップが上図です。

  1. IDEと評価ボードを準備、利用MCUの開発環境構築
  2. サンプルプロジェクトを利用し、MCUや内蔵周辺回路の特徴・使い方を具体的に理解
  3. 製品処理に近いサンプルプロジェクトなどを活用し、評価ボード上でプロトタイプ開発
  4. プロトタイプへ保守点検などの製品化処理を追加、製品時ベアメタルかRTOS利用かを評価
  5. ステップ04評価結果でA:ベアメタル製品開発、または、B:RTOS製品開発へ発展

更に製品化へは様々なステップも必要ですが、プロトタイプ開発に絞るとこのステップになります。

Cortex-M4プロトタイプテンプレート

弊社Cortex-M4プロトタイプテンプレートは、ステップを効率的に上るための開発支援ツールです。

販売中の弊社テンプレートと同様、複数サンプルプロジェクトや開発した処理を、RTOSを使わずに時分割で起動するマルチタスク機能を備えています。
※時分割起動マルチタスク機能:ステップ03と04の課題は、複数サンプルプロジェクトや製品化に必要となる様々な処理を、どうやって1つに組込むか(?)ということです。RTOSを利用すれば解決します。しかし、RTOS利用のためだけに別途知識や理解が必要で、RTOS活用までの階段差が非常に高いという欠点があります。弊社テンプレートは、時分割で複数処理を起動し、初心者でも仕組みが理解できる低い階段差でマルチタスク機能を実現します。詳細は、コチラなどをご覧ください。

販売中の従来テンプレートとCortex-M4プロトタイプテンプレートの違いが、以下です。

  1. ステップ05以降の製品開発へも、ステップ01で構築したプロトタイプ環境をそのまま使える
  2. 下位Cortex-M0/M0+/M3ソフトウェアに対して、Cortex-M4プロトタイプ開発資産が流用できる

Cortex-M4の高性能を、プロトタイプ開発マージン(後述)に使うとこれらの違いが生じます。

Cortex-M4コアMCUの特徴

ARM Cortex-M4は、Cortex-M0/M0+/M3とバイナリ互換です。

簡単に言うと、Cortex-Mコア開発元ARM社が推進するCMSISに則って開発したCortex-M4ソースコードやライブラリは、再コンパイルすればCortex-M0/M0+/M3へ流用・活用ができます。
※CMSIS:Cortex Microcontroller Software Interface Standard関連投稿は、コチラの2章などを参照してください。

Cortex-Mxのバイナリ互換性(出典:STM32L0(Cortex-M0+)トレーニング資料)
Cortex-Mxのバイナリ互換性(出典:STM32L0(Cortex-M0+)トレーニング資料)

図から、Cortex-M4バイナリの全ては、下位Cortex-M0/M0+/M3に含まれてはいません。従って、効率的な処理やセキュリティ対策必須の高速演算を行うには、Cortex-M4が最適なのは言うまでもありません。

Cortex-M4を使ったMCUは、Cortex-M0/M0+/M3 MCUに比べ動作クロックが高速で内蔵Flash/RAM容量も大きいため、ベアメタル利用だけでなく、RTOS利用も可能です。

Cortex-M4がプロトタイプ開発に最適な理由:大マージン

Cortex-M4のMCUでプロトタイプ開発すれば、製品化時に必要となる処理や保守点検処理などの実装も「余裕」を持ってできます。
※製品出荷テストプログラム、自動販売機待機中のLEDデモンストレーション点灯などが製品化処理具体例です。

筆者は、このような製品化処理を、おおよそプロトタイプ処理と同程度と見積もります。つまり、製品のFlash/RAM量は、プロトタイプ時の2倍必要になります。

仮に「余裕」がありすぎオーバースペックの場合には、開発したCortex-M4プロトタイプ処理(=開発ソフトウェア資産)を、そのまま下位Cortex-M0/M0+/M3コアMCUへ流用が可能です。

一方、処理が複雑で多い場合には、RTOSで解決できるか否かの評価もCortex-M4プロトタイプなら可能です。更にIoT製品では、セキュリティ関連の(先が見えない)処理や計算量増加にも対応しなければなりません。

安全側評価なら敢えて下位Cortex-Mコアを選ばずに、Cortex-M4をそのまま製品にも使えば、処理増加にも耐えらます。

つまり、プロトタイプ開発には、初めから容量や性能の足かせが無く、製品化移行時の開発リスクも少ない高速高性能・大容量のCortex-M4 MCUが最適なのです。

製品時の処理能力やFlash/RAM量を、Cortex-M4プロトタイプで見積もった後に、製品化にステップアップすれば、適正な製品制御Cortex-Mコアを選択できます。開発ソフトウェア資産の流用性、過負荷耐力、RTOS製品開発評価ができる高性能を兼ね備えたのが、Cortex-M4を使ったプロトタイプ開発です。

問題は、価格です。

各社のCortex-M4評価ボード価格は、Cortex-M0/M0+/M3評価ボードと大差ありません。STM32MCUの評価ボード:Nucleo32シリーズは、Cortex-Mコアが異なっても同額です。プロトタイプ開発マージンを考慮すると、たとえ評価ボードに多少の価格差があったとしても十分納得がいきます。

Cortex-M4デバイス単体価格は、Cortex-M0/M0+/M3よりは高価です。しかし、製品原価全体に占めるCortex-M4デバイス価格比は低いでしょう。IoT製品では、今後増大するセキュリティ対策や計算量増加などを考慮すると、Cortex-M4デバイスを使うメリットは大きいと思います。

Cortex-M4プロトタイプテンプレート開発指針(NXP、STM、Cypress、TI共通)

Cortex-M4の特徴を活かし、下位Cortex-M0/M0+/M3間での開発ソフトウェア資産流用を考慮したCortex-M4プロトタイプテンプレート開発指針です。

  1. Cortex-M0/M0+/M3/M4各コアに用いるテンプレート本体の共通化
  2. プロトタイプ開発ソフトウェア資産流用性を高めるCMSISソフトウェアでの開発
  3. 製品化時ベアメタルかRTOS利用かを評価のため、Cortex-M4最高速動作のプロトタイプ開発

現在CMSISへの対応は、各社足並みが揃っているとは言えません。もしも完全にCMSISへ対応した場合は、異なるベンダ間でも開発アプリケーション互換が実現するからです。ARMコア市場が「攻めに強く、守りに弱い」ゆえんです。そういう状況でも、各社ともCMSISへのソフトウェア対応を進行中です。
※Cortex-M33コアには、CMSISに反して、ベンダ独自のカスタム命令追加の動きも見られます。

本稿で示したCortex-M4プロトタイプテンプレートと異なり、弊社販売中のCortex-M0/M0+/M3テンプレートは、テンプレート利用コアで最適解を与えます。そのため、RTOS利用時や、製品化処理、セキュリティ対策などの処理が増えた時には、元々のコア処理性能や内蔵Flash/RAMに余裕が少ないため、適用デバイスでの製品化に対して、開発を続けにくい状況が発生することもありえます。

この点、Cortex-M4プロトタイプテンプレートなら、プロトタイプで構築した同じ開発環境で、RTOSも含めた製品開発へも余裕を持って対応できます。同時に、プロトタイプ開発資産の流用や活用により、Cortex-M0/M0+/M3ソフトウェア生産性も高めることができます(一石二鳥)。

ATM Cortex-M4テンプレートと開発資産流用性
ATM Cortex-M4テンプレートと開発資産流用性

弊社Cortex-M4プロトタイプテンプレートの発売時期、RTOSへの具体的対応方法などは、未定です。本ブログで各社毎の開発状況をお知らせする予定です。

あとがき:初心者や個人利用は、Cortex-M4テンプレートが最適

ソフトウェア開発初心者にCortex-M4プロトタイプテンプレート利用は、難しい(=階段を上るのが困難)と考える方がいるかもしれません。筆者は、全く逆、むしろ初心者、個人利用に最適だと思います。

理由は、Cortex-M0/M0+/M3/M4と上位になるほどコア設計が新しく、処理性能も上がるからです。初心者が、あまり上手くないコード記述をしても、コア性能が高いため問題なく処理できてしまいます。詳細は、ARM Communityの“An overview of the ARM Cortex-M processor family and comparison”などが参考になります。

ごく簡単に言うと、自動車エンジンが、Cortex-Mコアに相当すると考えてください。

小排気量なCortex-M0より、大排気量のCortex-M4の方が、楽に運転でき、しかも、運転に最低限必要なハンドルやアクセル、ブレーキ操作は全く同じです。車(=評価ボード)の価格が同じなら、殆どの方が、余裕のある大排気量のCortex-M4を選択するでしょう。

しかも、Cortex-M4評価ボード操作の技(=開発ソフトウェア資産)は、Cortex-M0/M0+/M3へも流用できます。経済的に厳しい個人利用のプロトタイプ開発環境としては、流用範囲の広いCortex-M4 MCUテンプレートが最適と言えます。

弊社Cortex-M4プロトタイプテンプレートは、つまずき易い階段を、楽に効率的に上るための開発支援ツールです。ご期待ください。

汎用MCUシェア20%超、第2位はSTM32MCU

シェア2位に躍り出たSTの汎用マイコン事業戦略”が、EE Times Japanに掲載されました。本稿は、この記事を要約し、記事記載のMCU 4ニーズの1つ、セキュリティ強化マイコン:STM32H7の暗号鍵利用によるソフトウェア更新方法(ST公式ブログ10月8日投稿)を示します。

STM32MCUは、汎用MCU世界市場シェア20%超の第2位へ

2019年9月、東京都内でSTマイクロエレクトロニクス(以下STM)による記者会見が開かれ、そのレポートがEE Times Japan記事内容です。ARM Cortex-Mコア採用のSTM32MCUが、2018年には汎用MCU世界市場シェア20%を超え第2位になった要因分析、今後のSTM汎用MCU事業方針が会見内容です。

汎用STM32MCUの世界シェア推移(出典:STM)
汎用STM32MCUの世界シェア推移(出典:STM)

車載用を除くMCUが汎用MCUです。本ブログも、この汎用MCUを対象としており、上図推移は重要なデータです。

以下、マイクロコントローラ&デジタルICグループマイクロコントローラ製品事業部グローバル・マーケティング・ディレクタ)Daniel Colonna氏の記者会見談話を中心に記事要約を示します。

STM32MCUシェア続伸要因

STM競合他社は買収や統合で成長しているが、STMは独自でシェア2位を実現。要因は、民生機器だけに集中せず、産業機器などのインダストリアル分野(=マスマーケット)に主眼を置き製品開発を行ってきたこと。マスマーケットターゲット事業方針は今後も変えず、シェア30%を目指す。

インダストリアル分野の4MCUニーズとSTM対応

演算性能の強化(STM32MP1/STM32H7)、より高度なAI実現(STM32CubeMXのAI機能拡張パッケージ)、多様な接続技術への対応(STM32WB)、セキュリティ強化(STM32Trust)の4点がインダストリアル分野MCUのニーズとそのSTMの対応(カッコ内)。

インダストリアル分野汎用MCUの4ニーズ(出典:STM)
インダストリアル分野汎用MCUの4ニーズ(出典:STM)

より広範囲なマスマーケット獲得策

モノクロからカラーLEDへ置換え(TouchGFX)、8ビットなどから32ビットMCUへ置換え(STM32G0シリーズ)で、より広範囲マスマーケットでのSTM32MCU浸透を図る。

以上が記者会見記事の要約です。

汎用MCU第2位となったSTM32MCU評価ボードは、入手性が良く安価です。コードサイズ制限なしの無償開発環境(STM32CubeIDE /SW4STM32/STM32CubeMX)も使い勝手に優れています。また、厳選された日本語技術資料も活用でき、初級/中級レベルのMCU開発者に最適だと筆者も思います。

この特徴を持つSTM32MCUに対して、弊社はSTM32G0x専用テンプレートSTM32Fx汎用テンプレートを販売中です。今後は、STM32G4テンプレートも開発を予定しています。

これまでNon ARM汎用MCU1位であったRunesasも、ARMコア他社対応か(?)ついに2019年10月8日、Cortex-MコアMCU販売を開始しました。これについては、別途投稿します。

セキュリティ強化STM32H7のソフトウェア更新

インダストリアル分野4MCUニーズのうち、演算性能とセキュリティ強化を満たすのが、STM32H7(Cortex-M7/480MHz、Cortex-M4/240MHzのデュアルコア)です。筆者個人は、MCUというよりむしろMPUに属す気がします。STMも、STM32MCU(下記右)に対して、STM32マイクロプロセッサ(下記左)と区別しています。但し、名称は違っても、そこに用いる技術は同一のはずです。

STM32MCUとSTM32マイクロプロセッサ(出典:STM)
STM32MCUとSTM32マイクロプロセッサ(出典:STM)

丁度最初に示した10月8日のSTM公式ブログに、セキュリティ強化STM32H7のファームウェア書換え手順図を見つけました。関連投稿:総務省:2020年4月以降IoT機器アップデート機能義務化予定の2章で示した3種サイバー攻撃へのウイルス感染対策です。

STM32H7ソフトウェア更新時のSFI、HSM(出典:STM)
STM32H7ソフトウェア更新時のSFI、HSM(出典:STM)

ハードウェア暗号化エンジンを持つSTM32H7は、図右上のSFI:Secure Firmware Installで暗号化、STM32G0やSTM32G4等は、図右下のSMI:Secure Module Installで暗号化し、更新ソフトウェアを準備します。どちらも、セキュリティ認証情報を含むHSM:ST Hardware Secure Module smart cardで鍵を受渡し復号化、ソフトウェア書換えを行います。

我々が開発するMCUソフトウェアの更新頻度は、PCに比べれば低いはずです。しかし、その頻度は、ウイルスの数に比例しますので、サイバー攻撃が増えればその度にこの書換えで対応することを考えると憂鬱になります。
※書換え失敗やワクチン投入による通常処理への配慮も必要で、Windows 10のようにユーザ任せの無責任な対応はMCUソフトウェアでは論外なため、開発者負担は増すばかりです😫。

ARM Cortex-M4とM0+アプリケーションコード互換

NXP MCUXpresso SDK利用を利用すると、LPC845 Breakout board用に開発した1秒赤LED点滅アプリケーションコードが、そのままFRDM-KL25Zへ流用できることを前回投稿で示しました。ただ、どちらも同じARM Cortex-M0+コアのMCU評価ボードなので、読者インパクトは少なかったかもしれません。

そこで、LPC845 Breakout board(Cortex-M0+/30MHzコア)のLED点滅アプリケーションコードが、そのままCortex-M4/100MHzコアのLPCXpreosso54114へ流用できることを示します。異なるARMコア間でのアプリケーションコード互換の話です。

ARMコアバイナリ互換

Cortex-Mxのバイナリ互換性(出典:STM32L0(Cortex-M0+)トレーニング資料)
Cortex-Mxのバイナリ互換性(出典:STM32L0(Cortex-M0+)トレーニング資料)

ARMコアのバイナリ上位互換を示す図です(関連投稿:Cortex-M0/M0+/M3比較とコア選択の2章)。このバイナリコード包含関係は、Cortex-M0バイナリコードならCortex-M4でも動作することを示しています。

但し、この包含関係を理解していても、Cortex-M0バイナリコードをそのままCortex-M4へ流用する開発者はいないと思います。

ARMコアアプリケーションコード互換

Cortex-Mxのアプリケーションコード互換性
Cortex-Mxのアプリケーションコード互換性

MCUXpresso IDEのARMコアアプリケーションコード互換を示す図です。左がLPC845 Breakout board(Cortex-M0+/30MHzコア)の1秒赤LED点滅アプリケーションコード、右がCortex-M4/100MHzコアのLPCXpreosso54114の1秒赤LED点滅アプリケーションコードです。

コード差は、L59:LPCXpreosso54114評価ボード動作クロック設定:48MHz動作のみです。例えば、96MHzなどの他の動作周波数へ設定することも可能です。コード上で動作周波数を明示的に表示するために異なりましたが、機能的には両者同じコードと言えます(L59をマクロで書き換えれば、同一コード記述もできます)。

図下のInstalled SDK Versionが、どちらも2019-06-14で一致していることも重要です。Versionが異なると、例えばGPIOのAPIが異なることがあるからです。各SDKリリースノートでAPI差の有無確認ができます。※LPCXpreosso54114 SDKのMCUXpresso IDE設定方法は、コチラの投稿の5/6章を参考にしてください。

1秒赤LED点滅という簡単なアプリケーションですが、Cortex-M0+とCortex-M4の異なるARMコア間でコード互換性があることが解ります。

動作周波数の隠蔽とIO割付

評価ボード動作周波数が異なれば、無限ループ回転速度も異なります。従って、互換性を持たせるコード内に、無限ループ内の回転数でLED点滅させるような処理記述はできません。コードに時間要素は組込めないのです。

1秒点滅の場合は、L77:SysTick_DelayTicks()でループ回転数をカウントし、1秒遅延を処理しています。これにより、GPIO_PortToggle()が時間要素なしとなり、異なる動作周波数のARMコアでもアプリケーションコード移植性を実現しています。

SysTick_DelayTick()と1ms割込みによりカウントダウンする処理コードが下記です。ここも、割込みを利用することでコード移植性を実現しています。

動作周波数隠蔽によるARMコアアプリケーションコード移植性の実現
動作周波数隠蔽によるARMコアアプリケーションコード移植性の実現

左のLPC845 Breakout boardと、右のLPCXpreosso54114のコード差は、L16:赤LEDのIO割付のみです。評価ボード毎に異なるIO割付となるのは、やむを得ないでしょう。L12からL16のDefinition箇所を、別ファイル(例えばIODefine.hやUserDefine.h)として抽出すれば、同一コード記述も可能です。

ARMコアアプリケーションコード互換メリット

以上のように、ARMコアアプリケーションコード互換を目的にした記述や工夫も必要です。しかし、一旦互換コードを開発しておけば、開発資産として他のARMコア利用時にも使えます。その結果、開発速度/効率が高まります。

IoT MCUは、センサ入力やLED出力などのメイン処理以外にも、日々変化するセキュリティ処理への対応は、必須です。メイン処理が出来上がった後での、セキュリティ処理追加という手順です。

セキュリティ対策は、セキュリティライブラリ等の使用だけでなく、いつどのようにライブラリを活用するか、その時のMCU負荷がメイン処理へ及ぼす影響等、検討が必要な事柄が多くあります。

少しでも早くメイン処理を仕上げ、これら検討項目へ時間配分することがIoT MCU開発者には要求されます。この検討時間稼ぎのためにも、ARMコアアプリケーションコードの開発資産化は必須でしょう。

※プロトタイプ開発は、初めから厳しい条件で開発するよりも、最速のCortex-M4で行い、全体完成後Cortex-M0+/M3などへアプリケーションコードを移植するコストダウンアプローチも名案だと思います。

P.S.:2019年9月4日、MCUXpresso IDEがv11.0.1へ更新されました。旧MCUXpresso IDE v11.0.0 [2516]利用中の方は、Help>Check for Updatesではv11.0.1へ更新されません。新にMCUXpresso IDE v11.0.1 [2563]のインストールが必要です。新MCUXpresso IDEインストール方法は、コチラの4章を参照ください。

NXP MCUXpresso SDKから見るARMコアMCU開発動向

NXP最新IDE:MCUXpresso v11が、SDK:Software Development Kitを使ってMCUソフトウェア開発をすることは、前回投稿で示しました。MCUXpresso SDKがサポートする評価ボード一覧が、SDKユーザガイド最新版:Rev.10、06/2019付録Bにあり、旧Freescale評価ボード:FRDMが多いですが、NXPの新しい評価ボードも追加されつつあります。

オランダ)NXPが、米)Freescaleを買収完了したのは2015年12月です。

本稿は、旧FreescaleとNXP MCU両対応のMCUXpresso SDKから、ARMコアMCU開発動向を調査し対策を示しました。

MCUXpresso SDK

MCUXpresso SDK Laysers(出典:Getting Started with MCUXpresso SDK, Rev. 10_06_2019)
MCUXpresso SDK Laysers(出典:Getting Started with MCUXpresso SDK, Rev. 10_06_2019)

ユーザガイド記載のMCUXpresso SDK層構成です。ユーザが開発するのはApplication Code。このApplication Code以外は、評価ボード:MCU Hardwareと、SDKで提供されます。色付き部分:Middleware、Board Support、FreeRTOS、Peripheral Drivers、CMSIS-CORE…がSDKの中身です。

もちろんMCU性能に応じて、初めからFreeRTOSやMiddlewareが無いSDKもあります。例えば、前回のLPC845 Breakout board SDKリリースノートを見ると、Board Support(前回投稿BSPのこと)とPeripheral Drivers(Author: Freescale)、CMSIS-CORE(Author: ARM)だけが提供中です。

CMSIS:セムシイス

CMSIS:Cortex Microcontroller Software Interface Standardは、リリースノートでAuthor: ARMが示すようにMCUコア開発元ARM作成の規格で、MCUハードウェアを上位層から隠蔽します(関連投稿:mbed OS 5.4.0のLチカ動作、LPCXpresso824-MAXで確認の3章)。

Peripheral DriversやBoard Supportは、 このCMSIS層のおかげでMCUハードウェアに依存しないAPIを、ユーザ開発Application Codeへ提供できる訳です。例えば、下記旧Freescale評価ボード:FRDM-KL25Z用SDKのboard.h記述:赤LED初期設定とトグルマクロ関数は、前回投稿で示したLPC845 Breakout boardと同じです。

FRDM-KL25Z用SDK_SDK_2.2_FRDM-KL25Zのboard.h
FRDM-KL25Z用SDK_SDK_2.2_FRDM-KL25Zのboard.h

従って、LPC845 Breakout boardで開発したアプリケーションコードを、そのままFRDM-KL25Zへも流用できます。

つまり、「SDK利用によりARMコアアプリケーションコードが汎用化」したのです。

同一アプリケーションコードでFreescaleとNXP評価ボード動作の意味

旧FreescaleとNXPのMCU評価ボードが同じアプリケーションコードで動作するのは、どちらもARMコアMCUでCMSIS層付きSDKなので、開発ユーザから見れば当然です。

しかし、従来は同じARMコアであってもApplication CodeはMCUベンダ毎に異なり、ベンダが異なれば常に1から開発していました。NXPでさえ、SDKを使った今回の同一コード動作に、Freescaleを買収後、約3.5年かかっています。
※Freescale 旧IDE:Kinetis Design Studioや、NXP 旧IDE:MCUXpresso IDE v11以前に慣れた開発者は、CMSIS付きSDKの新IDE:MCUXpresso IDE v11に違和感があるかもしれません。というのは、新IDEは、どちらの旧IDEとも異なるからです。

もちろんCMSIS利用はメリットだけでなく、デメリットもあるハズです。例えば、他社と差別化するベンダ独自Peripheral性能を極限まで引出すには、直接Hardwareを制御した方がより効率的です。STマイクロエレクトロニクスのSTM32G0x MCUのLL:Low Layer APIなどにその動向が見られます(関連投稿:STM32G0x専用Edge MCUテンプレート開発)。

しかし、CMSIS利用SDKを使ったアプリケーションコード開発は、ARMコア間のアプリケーションコードやベンダ間をも跨ぐ移植性、開発速度の速さ、ソースコード可読性などの点からユーザメリット大と言えます。
※ベンダを跨ぐ移植性とは、FreescaleとNXPのMCUで同一アプリケーションが動作することを意味します。FreescaleはNXPに買収されたので、実はベンダを跨いでいませんが、CMSIS層があればアプリケーションコード移植可能な実例と思ってください。

ARM MCUコアソフトウェアの開発動向と対策

現在MCUコアは、多数派のARMコアベンダと、少数派のNon ARMコアベンダの2グループに分かれています。

多数派ARMコアベンダは、NXPのMCUXpresso SDKに見られるようにCMSIS層利用アプリケーションコード開発、既存アプリケーション資産流用、差別化Peripheral開発に力点を置くと思います。目的は、より早く、より簡単な環境提供によるソフトウェア開発効率/速度の向上です。

我々ユーザは、この環境変化に応じたアプリケーションコード汎用化手法と、もう一方の差別化機能の性能発揮手法を臨機応変、かつ、それらを混同せず、時には組み合わせて開発する必要があると思います。

P.S.:弊社テンプレートで言えば、アプリケーションコード汎用化手法が、STM32Fxテンプレート他の汎用テンプレート、一方の差別化機能の性能発揮手法が、STM32G0x専用テンプレートです。

MCUXpresso IDE v11をLPC845 Breakout boardで試す

まとめ

NXPのMCUXpresso IDE v11.0.0 [Build 2516] [2019-06-05]を使い、LPC845の評価ボードLPC845 Breakout boardの動作を確認し、サンプルプロジェクト赤LED点滅を緑LEDへ簡単に変更できる、SDK:Software Development Kitメリットを示しました。

LPCOpenライブラリなどを使った旧IDEに比べ、SDKを使うMCUXpresso IDE v11は、より早く簡単にソフトウェア開発が可能です。また、IDE更新とSDK更新が別々なため、常に最新ドライバ、BSP:Board Support Packageでの開発ができます。これもSDKメリットの1つです。

SDKは、ソフトウェア開発速度を上げる専用ライブラリ集です。MCUXpresso IDE v11のSDKを習得し、効率的なソフトウェア開発に慣れる必要があります。
これには、実際に評価ボード専用SDKを作成し、サンプルプロジェクトへ変更/修正を加え、SDKメリットを実感するのが早道です。本稿で用いたLPC845 Breakout boardは、SDK習得に好適です。

LPC8xxをアップグレートしたLPC845(64KB Flash、16KB RAM)評価ボード:LPC845 Breakout boardは、タッチパッド+デバッガ付きで低価格(¥697)、少サイズ(65x18mm)です。このサイズならそのまま装置へ実装も容易です。現場での短時間制御系アップデートや修理交換などに応用できます。

LPC845 Breakout board

LPC845 Breakout board
LPC845 Breakout board(出典:LPC84X MCU TECHNICAL OVERVIEWへ加筆)

LPC8xxシリーズは、アップグレートしたLPC84xとコストダウンしたLPC80xの2方向へ発展しました(関連投稿:NFCを使うLPC8N04のOTA)。LPC845評価ボード:LPC845 Breakout board (Cortex-M0+/30MHz)を入手しましたので、最新のLPCXpresso IDE v11を使って動作確認します。

LPCXpresso IDE v11.0.0 [2019-06-05]

最新LPCXpresso IDEは、v11.0.0 [2019-06-05]です。旧IDEからSDK:Software Develipment Kit追加、Pin設定方法が変わりました。既に旧IDEを使い慣れた方は、SDK活用の新LPCXpresso IDE v11に少し驚きを感じると思います。

LPCXpresso IDE v11ダウンロードとインストール

LPCXpresso IDE v11のダウンロードとインストールは、普通のPCアプリケーションと同じです。旧IDEではインストール後、アクティベーション手順が必要でしたが、v11は不要です。

また、デフォルトではプログラム/workspace共に専用フォルダ:MCUXpressoIDE_11.0.0_2516へ展開されます。つまり、旧IDEと共存します。ストレージ使用量は多くなりますが、共存するので安心して新旧IDEを試すことができます。

インストール後、Help>Check for Updatesを実行しIDEの更新有無を確認します。

また、最初のMCUXpresso IDE v11起動時にセキュリティソフトが警告を出すことがあります。お使いのセキュリティソフトに応じて対応してください(筆者Windows 10 Pro 1903のAvastは警告を出しましたので、例外追加で対応しました)。

LPCXprsso IDE v11インストール起動画面
LPCXprsso IDE v11インストール後、最初の起動画面

SDK Builder

SDKは、周辺回路ドライバ、サンプルプロジェクト、評価ボードサポートパッケージ:BSPなどを含む開発支援ツールです(SDKユーザガイドはコチラ)。インストールしたMCUXpresso IDEとは別に、ネット上のSDK BuilderでLPC845 Breakout board専用SDKを作成します(要ログイン)。

SDK BuilderのSelect Development Boardをクリックし、LPC845BREKOUTを選択します。後は、Build MCUXpresso SDKをクリックすると、作成したSDKの圧縮ファイル:SDK_2.6.0_LPC845BREAKOUT.zipがダウンロードされます(2.6.0は版数)。
※評価ボードによっては、Amazon-FreeRTOS、Azure IoTなどのミドルウェアもSDKへ追加可能です。

SDK設定

ダウンロードしたSDK圧縮ファイルを、LPCXpresso IDEのInstalled SDKsビューへドラッグ&ドロップするだけでSDK設定は完了です。

LPC845 Breakout boardの赤LED点滅動作

SDKにはLPC845 Breakout boardの赤LED点滅させる、いわゆるLチカサンプルプロジェクトがあります。このLチカソフトで評価ボードの動作確認をします。

IDEのQuickstart Panelビュー、Import SDK example(s)…をクリックします。Lpc845breakoutを選択後Nextをクリックします。Examplesのdemo_appsを開くとled_blinkyが現れます。これがLチカサンプルです。

Led_blinkyに☑を入れFinishをクリックすると、workspace内にlpc845breakouty_led_blinkyプロジェクトが展開されます。

LPC845 Breakout boardのLED点滅サンプルプロジェクトのインポート
LPC845 Breakout boardのLED点滅サンプルプロジェクトのインポート

何も変更せずに、Quickstart PanelビューのBuildをクリックするとコンパイルが成功します。評価ボードをPCと接続しDebugのクリックでCMSIS-DAPプローブを自動認識し、デバッグモード画面へ変わります。

後は実行などで赤LEDが1秒毎に点滅する動作が確認できます。

SDKサンプルプロジェクトそのものの動作確認は、以上のように簡単です。SDKのメリットは、プロジェクト変更や機能追加が簡単にできることです。例を次に示します。

LPC845 Breakout boardの赤→緑LED点滅の変更

赤LEDへの制御を緑LEDへ変更するには、IDEをDevelop画面からPin画面へ切替えます。切替は、Open Pinsクリック、またはIDE右上のデバイスアイコンのクリックどちらでもOKです。

LED_LED点滅からGREEN_LED点滅変更のPin画面
LED_LED点滅からGREEN_LED点滅変更のPin画面

Pin画面は、プロジェクト使用中のピン名、周辺回路などがハイライト表示されます。

lpc845breakouty_led_blinkyプロジェクトの場合は、PIO1_2とGPIOで、IdentifierにLED_REDとあります。Identifireは、ソースコード中で使えるマクロです。LED_GREENやLED_BLUEが既にあるのも解ります。このように評価ボード実装済みのハードウエアが、あらかじめSDKで定義済みです。

赤LED→緑LED変更は、Pin11のLED_GREENに☑を入れ、表示されるPIO1_0選択肢からデフォルトのGPIO,PIO_1_0を選びます。次にUpdate CodeをクリックすればPin画面の変更がソースコードへ反映されます。

LED_RED点滅からLED_GREEN点滅へのピン変更
LED_RED点滅からLED_GREEN点滅へのピン変更

ソースコード表示のDevelop画面へ切替えるには、右上のDevelopアイコンをクリックし、L16をコメントアウト、代わりにL17の追記で赤→緑LED点滅への変更完了です。ビルドして緑LED点滅動作を確認してください。

LED_RED点滅からLED_GREEN点滅へのソースコード変更
LED_RED点滅からLED_GREEN点滅へのソースコード変更

このようにサンプルプロジェクトの変更は、SDKに評価ボード実装ハードウエアが定義済みなので、ボード回路図を確認せずにすぐにできます(回路図を確認すれば万全ですが…😅)。

さて、緑LED点滅動作が確認できた後にソースコードへ下記3か所の変更を加えてください。

BSPを使った赤LEDの点滅
BSPを使った赤LEDの点滅

これは、board.hで定義済みのBSPを使った赤LED点滅へのソースコード変更です。追記したLED_RED_INIT(0)とLED_RED_TOGGLE()は、board.hに記述があります。L80:GPIO_PortToggle()よりもL81:LED_RED_TOGGLE()の方が、ソースコード可読性が高いことが解ります。

BSPは、評価ボードで使用頻度が高い関数やマクロを定義します。BSP活用でソースコード可読性が高まりケアレスミスも減ります。BSPは、SDK作成時に生成されます。

LPC845 Breakout boardのSDK活用例を示しました。SDKメリットも実感できたと思います。

LPCOpenライブラリを使ったLPC8xxテンプレートも、新しいSDK対応へUpgradeする必要があるかもしれません。SDKは、新しい評価ボードから対応中なので、残念ながら少し待つ必要があるかもしれませんが…😅。