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付録の章に、これら詳細が記載されています。

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

FreeRTOSサンプルコード(1)

NXPのCortex-M4/M0+ディアルコアLPCXpresso54114のFreeRTOSサンプルコードを数回に分けて調査します。Cortex-M4クラスのMCUは、処理は高速で大容量Flash、RAMを持つので、ベアメタル利用だけでなくRTOS利用ソフトウェア開発にも適します。

ベアメタルCortex-M0/M0+/M3に適用済み弊社テンプレートを、そのままCortex-M4 MCUに使うのは、テンプレートがMCU非依存なので簡単です。ですが、先ずFreeRTOSソフトウェアをよく知り、新開発ベアメタルCortex-M4テンプレートへ応用できる機能があるか判断するのが調査の目的です。

RTOS習得2017

2017年3月にLPCXpresso824-MAX(Cortex-M0+ 30MHz、32KB Flash、8KB RAM)を使ってFreeRTOSのポイントを調査し、結果をマイコンRTOS習得ページにまとめました。

第1部から第3部で、最低限のFreeRTOSと使用APIを解説し、第4部で、最も優れた解説書と筆者が考えるソースコードと評価ボードを使ってFreeRTOS動作解析と習得を行うという内容です。

ただ、自作FreeRTOSサンプルコードの出来が悪く、第4部の動作解析は不十分でした。

そこで、RTOS利用がより現実的なLPCXpresso54114(Cortex-M4/M0+ 100MHz、256KB Flash、192KB RAM)評価ボードとSDK付属FreeRTOSサンプルコードを用いて、不十分だった第4部FreeRTOS動作解析に再挑戦します。平たく言えば、NXP公式FreeRTOSサンプルコードを、不出来な自作コードの代わりに利用します😅。

第1回目は、FreeRTOSサンプルコードの出所、FreeRTOS動作を調べる4ツールを説明します。

LPCXpresso54114 SDK付属FreeRTOSサンプルコード

NXPマイコンの公式サンプルコード取得方法は、3つあります。最も新しいのがSDK:Software Development Kitから、2つ目がLPCOpenライブラリから、3つ目がPE:Processor Expertからの取得です。

NXP社が古くから用いてきたサンプルコード提供方法が、LPCOpenライブラリです。
NXPに買収された旧Freescale社のKinetis MCUなどは、PEと呼ばれるGUIベースAPI生成ツールでサンプルコードを提供していました。同じMCUでも提供方法によりAPIは異なり、サンプルコード互換性はありません。
※ベンダ毎に異なるAPI提供方法やその違い、サンプルコードとの関係は、別投稿で説明する予定です。

Freescale買収後のNXPは、SDKで全MCU(=新旧NXP+買収FreescaleのMCU)のAPIとサンプルコードを提供する方法に統一したようです。その根拠は、最新MCUXpresso IDEユーザインタフェースが、SDKの利用前提でできているからです。

現在も提供中のLPCOpenライブラリ内にあるLPCXpresso54114 FreeRTOSサンプルコードは2個、一方、SDK内のFreeRTOSサンプルコードは11個あります。PE提供はありません。

調査対象としては、FreeRTOSサンプルコード数が最多のSDKが適しています。

LPCXpresso54114 FreeRTOS examples in SDK
LPCXpresso54114 FreeRTOS examples in SDK

FreeRTOS実動作解析ツール

MCUXpresso IDE v11.1.0のHelp>Help Contentsに、MCUXpresso IDE FreeRTOS Debug Guideがあります(PDF文書がMCUXpresso IDEインストールフォルダ内にも有り) 。この中に、FreeRTOSサンプルコードデバッグのみに使えるタスク対応デバッガ4ツール(Task List/Queue List/Timer List/Heap Usage)があります。

MCUXpresso IDE Help ContentsのFreeRTOS Debug GuideのShowing FreeRTOS TAD Views
MCUXpresso IDE Help ContentsのFreeRTOS Debug GuideのShowing FreeRTOS TAD Views
  • Task List:タスク毎のプライオリティ、スタック使用量、動作時間表示
  • Queue List:アクティブキュー、セマフォ、ミューテックス利用時のリソース表示
  • Timer List:RTOSタイマー表示
  • Heap Usage:ヒープ使用量、メモリブロック割当て表示

これらFreeRTOS専用ツールは、FreeRTOSサンプルコードの評価ボード動作後、デバッガ停止中に表示されます。シミュレーションではなく、評価ボードでの「実動作結果」が判ります。開発ソフトウェアだけでなくRTOS使用量が判るので、デバイスにどれ程リソース余裕があるかが判断できます。

RTOSソフトウェアは、ユーザが開発するタスクの単体、結合デバッグに加え、RTOS動作の確認事項が増えます。FreeRTOS実動作解析4ツールは、これらの確認ができます。評価ボードを使ったプロトタイプ開発の重要度は、ベアメタル開発比より大きくなると言えるでしょう。

次回以降、LPCXpresso54114のSDK付属FreeRTOSサンプルコードを、MCUXpresso IDEのFreeRTOS Debug Guideに沿って調査します。

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

ルネサスARM Cortex-Mコアマイコン:RAファミリ発表

2019年10月8日、ルネサスエレクトロニクス(以下ルネサス)が、ARM Cortex-M4/M23搭載のRAファミリを発表しました。ARMコアMCU市場へ、遅ればせながら(!?)参入したRAファミリの特徴、競合他社と比較評価しました。

Runesas RAファミリ(出典:ルネサス)
Runesas RAファミリに加筆(出典:ルネサス)

RAファミリの特徴

「攻めやすく、守りにくい」、これがARMコアMCU市場だと思います。先行する競合他社は、NXP、STM、Cypress、TIなどです。

後発ルネサスが選択したARMコアは、Cortex-Mコア最高性能のCortex-M4と、低消費電力+セキュリティ重視のCortex-M23/M33(M4はRA8でマルチコア化、M33予定)です。

同じARMコアの先行他社へ攻め込むには、他社比魅力的な内蔵周辺回路が必要です。上図の静電容量タッチセンサ、アナログなどがこれに相当するはずです。Cypress特許の静電容量タッチセンサ:CapSenseとの性能比較が楽しみです。
※CapSenseの特徴は、コチラの投稿などを参照してください。

RAファミリのターゲット市場は、産業機器、ビルオートメーション、セキュリティ、メータ、家電などで、車載を除く次世代IoTエッジデバイスです。

RAファミリの市場(出典:RAファミリパンフレット)
RAファミリの市場(出典:RAファミリパンフレット)

セキュリティニーズが高いIoTエッジMCUでは、Cortex-M3クラスでも性能不足が懸念されます。シングルコアなら最低でもCortex-M4、セキュリティ強化Cortex-M23/33のRAファミリのコア選択は、理解できます。

RAファミリとRunesas Synergyの違い

ルネサスは、これまでRunesas Synergy™としてARMコアMCUを販売してきました。このRunesas SynergyとRAファミリの違いが、10月8日MONOistの“ルネサスがArmマイコンで本気出す、「RAファミリ」を発売”記事に説明されています。

筆者は、Runesas Synergy™は、ルネサスがアプリケーション開発を手伝う形式で、個人レベルでの開発には金額的に手を出しにくいMCU、一方、RAファミリは、競合他社と同様CMSIS:Cortex Microcontroller Software Interface Standardに則った形式でユーザがアプリケーション開発できるMCUと理解しています。
※CMSIS:Cortex Microcontroller Software Interface Standardは、コチラの2章などを参照してください。

これで弊社も、競合他社と同じ土俵でルネサスARMコアMCUを使える可能性がでてきました。

RAファミリの開発環境

RAファミリの開発環境(出典:RAファミリパンフレット)
RAファミリの開発環境(出典:RAファミリパンフレット)

RAファミリパンフレットによると、IDEは、e2 studio(CS+はありません)、エミュレータは、Segger J-Linkまたは、E2エミュレータ Liteです。

例えば、Cortex-M4/48MHz/Flash:256KB/RAM:32KBの評価ボード:EK-RA4M1の概要が下記です。

EK-RA4M1 MCU 評価キット
EK-RA4M1 MCU 評価キット

Mouserで¥4,539で購入可能です。他社同様オンボードエミュレータですが、Arduinoコネクタを持っていません。価格も、後発なのに他社比、高い気がします😥。

RAファミリと競合他社比較

Cortex-Mコア、内蔵周辺回路、開発環境、評価ボード、日本語技術資料の5点から、ルネサスRAファミリを、競合他社ARMコアMCUと3段階(A/B/C)評価しました。

Cortex-Mコア=A、内蔵周辺回路=A、開発環境=B、評価ボード=C、日本語技術資料=C → 総合評価=B

総合評価Bは、普通レベルということです。個別評価結果が下記です。

Cortex-M4とM23/33コア選択や、タッチセンサ等の内蔵周辺回路は、後発なので当然ルネサスの市場調査結果によるものと思われ、A評価としました。IoTエッジMCUでは、これらコアや周辺回路が必須だと筆者も思います。
※コアと周辺回路は、現在、弊社注力中のCortex-M4コアテンプレート開発とCypress)PSoC 4 CapSenseテンプレート(開発中)に傾向が一致しています。

開発環境は、多機能すぎるe2 studioなのでBです(A評価は、NXP)MCUXpressoTI)CCS Cloud)。

評価ボードは、Arduinoコネクタなしで高価なためCです(A評価は、NXP)LPCXpressoやSTM)Nucleo32)。

日本企業のルネサスですが、RAファミリ動画などは英語です。重要技術資料も英語が多く、日本語資料はC評価です(A評価は、STM)。
※ソフトウェア開発者が、日本語資料にこだわること自体、時代錯誤、時代遅れかもしれません。しかし、イタリア+フランス企業のSTM日本語翻訳資料は、内容、和訳ともに優秀です。ルネサス技術資料は、これらと比べると低評価と言わざるを得ません。

総合評価Bですので、評価ボード:EK-RA4M1入手は、ペンディングとします。ルネサスRAマイコンを、本ブログへ追加した場合、ブログカテゴリと目標とする生産物は、下図になります。

また、2番目に示したターゲット市場図から、従来MCU とIoTエッジMCUとの境界が、Cortex-M3コアの可能性が見えてきました。この境界も追加しました。

ブログカテゴリと生産物(従来MCUとIoT MCU境界追加)
ブログカテゴリと生産物(従来MCUとIoT MCU境界追加)

筆者は、従来MCUは、IoTエッジのさらに外側、つまりIoT MCUのフロントエンドで機能し、Cortex-M4ソフトウェアの一部流用や活用により生産性が高く、しかも、エッジのカスタムニーズへも柔軟に対応するMCUへ発展すると思います。ARM Cortex-Mxコア間は、ソフトウェア流用が可能です(次回、詳細説明予定)。

ルネサスは、インターシルやIDT買収でMCUアナログフロントエンドを強化したはずです。しかし、新発売RAファミリに、これら買収技術は見当たらず、期待のSynergy効果も具体的には不明です(内蔵周辺回路の静電容量タッチセンサ、アナログに見えると期待)。

残念ながら現時点では、筆者には、RAファミリが魅力的なARMコアIoTエッジ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章を参照ください。

ARM Cortex-M4ベンダと評価ボード(選択失敗談)

本稿は、模索中のCortex-M4評価ボード選択の失敗談です。

初心者・中級者のMCU習得・開発を支援するのが本ブロブの目標です。手段として、個人でも入手性の良い低価格MCU評価ボードを使い、効率良く具体的にポイントを把握できる記事作成を心掛けています。

先日のIoT市場を狙うデュアルコアMCUで、本ブログでこれまで取り上げてきたMCUコア以外にARM Cortex-M4開発経験がIoT要件になる可能性を示しました。そこで、新たにCortex-M4カテゴリをブログに加えたいと考えているのですが、今日現在、適当な評価ボードや開発環境が見つかっておりません。

ARM Cortex-M4カテゴリ

Cortex-M4カテゴリは、急増するIoT開発に対する個人レベルでの先行準備的な位置付けです。

ARM Cortex-M0/M0+/M3コアやルネサスS1/S2/S3コア習得が初級レベルの方は、開発障壁が少し高いかもしれません。なぜなら、Cortex-M4コアの知識ベースはCortex-M0/M0+/M3だからです。この高さ軽減のため、過去のブログ関連投稿をリンク付けします。

中級レベルの方は、Cortex-M4の高いMCU能力を、Cortexコア間のアプリケーション移植やRTOS活用への発展、IoTで高度化するセキュリティ機能の実装などに意識してCortex-M4カテゴリ記事をご覧頂ければ役立つと思います。

32ビットMCUベンダシェアと本ブログカテゴリ

2018年の32ビットMCUベンダシェアが、6月7日投稿InfineonのCypress買収で示されています(下図右側)。

買収成立時の自動車と32ビットMCUシェア(出典:EE Times記事)
買収成立時の自動車と32ビットMCUシェア(出典:EE Times記事)

上位5ベンダ(Runesas、NXP、STM、Cypress、TI)と、本ブログカテゴリとの関係が下表です。

例えば、NXPのLPCマイコンでCortex-M0+記事であれば、MCUカテゴリはLPCマイコン、32ビットコアカテゴリはCortex-M0+などとカテゴリが重複する場合もあります。ただ、本ブログのカテゴリ記事数(n)がベンダシェアや、Cortexコアの人気傾向を示しており、32ビットMCUベンダシェアともほぼ一致します。

2018年MCU上位5ベンダと本ブログカテゴリの関係
MCUベンダ(シェア順) MCUカテゴリ 32ビットコアカテゴリ
Runesas RL78マイコン なし
NXP LPCマイコン/Kinetisマイコン Cortex-M0/M0+/M3/M23マイコン
STM STM32マイコン Cortex-M0/M0+/M3マイコン
Cypress PSoC/PRoCマイコン Cortex-M0/M0+マイコン
Texas Instruments なし なし

※Cypress+Infineonは買収成立と仮定

ルネサスMCUは16ビットコア(S1/S2/S3)のみ掲載中です。理由は、同社32ビットコアMCU開発環境が、コンパイラ1ライセンス当たり10万円程度と高価で、個人レベルでのライセンス購入が困難なため、本ブログ対象外としたからです。

MCUベンダシェアとカテゴリとを俯瞰すると、Texas Instrument(以下TI)とCortex-M4カテゴリがないことが解ります。※32ビットMCUコアでNon ARM系のRunesasを除くと、事実上Cortexコアのみで、その中で記載が無いメジャーMCUコアがCortex-M4です。

そこで、TIのARM Cortex-M4Fマイコン、MSP432の評価ボードを調査しました。

ARM Cortex-M4F搭載MSP432評価ボード

MSP-EXP432P401R LaunchPad Kitとブロック図
MSP-EXP432P401R LaunchPad Kitとブロック図

低消費電力MSP432P401R(ARM Cortex-M4F、48MHz、浮動小数点ユニット、DSPアクセラレーション、256KB/Flash、64KB/RAM)搭載の評価ボード:SimpleLink™ LaunchPad™です(TIは評価ボードをローンチパッドと呼びます)。Digi-KeyMouser秋月電子(秋月電子は在庫限りRev 1.0 (Black)、2100円)で低価格購入可能です。

他社ARM MCU評価ボードで一般的に用いられるArduinoコネクタ増設ではなく、BoosterPack(ブースタパック)と呼ぶTI独自拡張コネクタでBLEやWi-Fi機能を追加します。また、SimpleLink AcademyトレーニングというWebベースの教材などもあります。

MSP432評価ボード単体では、情報量の多さ、価格ともに魅力的です。Cortex-M4クラスの評価ボードでも、Cortex-M0/M0+/M3プラスアルファの低価格で入手できるのには驚きました。プロトタイプ開発は全てCortex-M4で行い、製品時Cortex-M0/M0+/M3を選択する方法もありだと思います。Cortex-M4とM4Fの違いは、本稿PS:パート2動画で解ります。

MSP432P401Rの開発環境は、TI純正無償Code Composer Studio(CCS)です。但し、無償版CCSはMSP432利用時32KBコードサイズ制限付きです。当面32KBでも十分ですが、制限解除には有償版(サブスクリプション)が必要です。

低価格評価ボードがあるのに開発環境に個人での使用に障害がある事象は、Runesas 32ビットMCUと同じです。

以上から本ブログのCortex-M4カテゴリに、TI:MSP-EXP432P401R LaunchPad を使うのは、有償開発環境の点から断念しました(NXP/STM/Cypressは、無償版でもコードサイズ制限無しです)。

まとめ

2018年32ビットMCUベンダシェアから本ブログ記事を俯瞰した結果、Cortex-M4カテゴリとベンダのTexas Instrumentが欠けていることが解り、ARM Cortex-M4F搭載のTI)MSP432P401R評価ボードMSP-EXP432P401R LaunchPad導入を検討しましたが、無償CCSコードサイズ制限のため採用を見合わせました。

勤めている企業の取引の関係でベンダや開発に使うMCUは、既に決まっていることが多いです。しかし、開発者個人レベルでは、ポケットマネーの範囲内で、ベンダもMCU選択も自由です。

ARM Cortex-M4 MCU開発経験はIoT普及期には必須になる可能性があります。普及期への先行準備、また、仕事以外のMCUを手掛けることによる視野拡大、リスク回避手段に適当なCortex-M4評価ボードを選択し、Cortex-M4カテゴリ投稿を計画しています。初回は、Cortex-M4評価ボード選択の失敗談となりました。

PS:TIサイトに下記MSP432日本語版トレーニング動画(要ログイン)があります。ARM Cortex-M4Fを使ったMSP432の全体像が効率的に把握できます。

タイトル 所要時間
パート 1 : MSP432 概要 09:24
パート 2 : ARM Cortex-M4F コア 08:12
パート 3 : 電源システム 05:25
パート 4 : クロック・システム、メモリ 07:53
パート 5 : デジタル・ペリフェラルとアナログ・ペリフェラル 10:07
パート 6 : セキュリティ 05:15
パート 7 : ソフトウェア 07:29
パート 8 : MSP430 から MSP432 05:06

STLINK-V3とは

2019年7月23日STM公式ブログでSTLINK-V3デバッグ/プローブが発表されました。

STLINK-V3は、従来からのST-LINK/V2-1の性能向上と機能追加をしたSTM32/STM8マイコン用の新しいデバッグ/プログラミングインタフェースです。

左側の最新STM32G474(Cortex-M4、512KB Flash)評価ボードはSTLINK-V3、LL API専用テンプレートで使った右側STM32G071(Cortex-M0+、128KB Flash)評価ボードはST-LINK/V2-1インタフェースを使っています。

STLINK-V3とST-LINK/V2-1
STLINK-V3とST-LINK/V2-1を使う評価ボード例

両インタフェースの主な相違点、いつどのような時にSTLINK-V3を使うのかを説明します。

STLINK-V3/SET、STLINK-V3/MINI

STLINK-V3デバッガ/プログラマは、3種類のボードから構成されます。

STLINK-V3SET基本ボード:MB1441と機能拡張ボード:MB1440、これらボードを収納するケース、基板むき出しのSTLINK-V3MINIです。STLINK-V3MINIは3Dプリンタレファレンスファイルを使ってユーザ独自ケースが作成可能です。

STLINK-V3SETは、MB1441とMB1440、ケース込みで$35、STLINK-V3MINIは、$9.75で販売中です。

STLINK-V3SETとSTLINK-MINI(出典:STM公式ブログ)
STLINK-V3SETとSTLINK-MINI(出典:STM公式ブログ)

STLINK-V3とST-LINK/V2-1の主な相違点

STLINK-V3とST-LINK/V2-1の主な相違点
仕様 STLINK-V3 ST-LINK/V2-1
USBスピード 480 Mbps(理論値) 12M bps
Drag & Dropブログラミング 可能 可能
Single Wire Debug(SWD サポート サポート
JTAG サポート なし
Bridge SPI サポート(MB1440) なし
Bridge I2C サポート(MB1440) なし
Bridge CAN サポート(MB1440) なし
Bridge GPIOs サポート(MB1440) なし
STDC14 サポート(VCP付き) なし

※VCP:Virtual COM Port

PC接続のUSB速度が最大480Mbpsと高速となり、STM32G474のような512KBもの大容量Flashでも高速に書込みが可能です。

また、機能拡張ボード:MB1440では、従来からあるUARTブリッジ機能に加え、SPI/I2C/CAN/GPIOのブリッジ機能も使え、PC上で各インタフェースのデバッグ等に活かせます。

STLINK-V3ターゲット接続インタフェース:STDC14

これらSTLINK-V3SET/MINIボードの基本機能(SWD、JTAG、Virtual COM Port)とターゲットMCUボードを繋ぐ仕様がSTDC14です(ハーフピッチ14ピンケーブル)。

STDC14 (STM32 JTAG/SWD and Virtual COM Port)
STDC14 (STM32 JTAG/SWD and Virtual COM Port)

STDC14コネクタをターゲットMCUボードに実装しておけば、STLINK-V3SETかSTLINK-V3MINIを使ってターゲットMCUのデバッグやプログラミングがST-LINK/V2-1よりも高速、効率的にできます。

VCP:Virtual COM Port

従来のST-LINK/V2-1でもVirtual COM Portは使えました。例えば、STM32G071評価ボードでは、ST-LINK/V2-1のVCP機能を使ってSTM32G071RBのLPUART1とPCとを接続し、評価ボードに追加配線なしでSTM32G071RB動作確認や操作ができています。

ST-LINK/V2-1のVCP利用例
ST-LINK/V2-1のVCPを利用し評価ボードとPC接続した例

PC上でTera Termなどのターミナルソフトを使えば簡単手軽にターゲットMCU動作確認ができるVCPが、新しいSTLINK-V3接続インタフェースSTDC14に含まれるので、VCPの重要性は益々高まると思います。