STM32G071RBとAlexaを繋ぐ

2020年1月17日2020年1月17日 WithHappy

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

システム構成

システム構成のブログ掲載が無いので、自作したのが上図右側です（左側出典：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年末発売のSTM32G0シリーズは、初の90nmプロセス製造MCUで低消費電力と高速動作、従来のSTM32F0 (Cortex-M0)～F1 (Cortex-M3)性能をカバーする新汎用MCUです。セキュリティハードウェア内蔵、低価格、64ピンパッケージでも１ペアVDD/VSS給電がSTM32G0の特徴です。
関連投稿：STM新汎用MCU STM32G0、守備範囲が広いSTM32G0

「STM32G0 シリーズのラインナップ拡充 STM32G041/ G031/ G030 新登場」記事が、STM32マイコンマンスリー・アップデート2020年1月のP4にもあります。

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 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かの選択判断も可能になります。

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

STMマイコン開発環境にソースコード日本語コメントの文字化けが発生中であることを、昨年11月に投稿しました。この文字化け発生のSTM32CubeIDE v1.1.0/CubeMX v5.4.0開発環境が、STM32CubeIDE v1.2.0とSTM32CubeMX 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特有問題だと思います。

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

NXPマイコン開発環境更新

2020年1月10日2020年1月18日 WithHappy

2019年12月20日、NXPマイコン統合開発環境のMCUXpresso IDE v11.1、SDK v2.7、Config Tools v7.0への更新ニュースが届きました。筆者は、Windows 10 1909トラブル真っ最中でしたので、更新対応が遅れ今日に至ります。本稿は、この最新開発環境更新方法と、Secure Provisioning Toolsを簡単に説明します。

NXPマイコン最新開発環境への更新方法

MCUXpresso IDEやSDKの最新版への更新方法は、前版更新方法の投稿：MCUXpresso IDE v11をLPC845 Breakout boardで試すと同じです。

更新方法をまとめると、

MCUXpresso IDE v11.1をダウンロードしインストール（前版v11.0インストール先/ワークスペースともに別になるので、新旧IDEが共存可能）。旧版は、手動にて削除。アクティベーション手順不要。
SDK Builderで旧SDK v2.6を最新版へ更新（旧SDK構築情報はNXPサイトに保存済みなので、ログインで最新版v2.7へ簡単に再構築できる）。
Config Toolsは、他ツールに比べ改版数が大きい（v7.0）のですが、筆者の対象マイコン（LPCXpresso54114/812MAX/824MAX/845Breakout）では、SDKにCFGが含まれており、単独で更新することはありません。
IDE/SDK/CFGの3ツールに加え、新に4番目のSEC：MCUXpresso Secure Provisioning Tool v1が加わりました。が、このSECツールは、Cortex-M7コアを用いるi.MX RT10xxクロスオーバープロセッサ用です。インストールや更新も、筆者対象マイコンでは不要です。

MCUXpresso IDE v11.1更新内容

IDE起動後、最初に表示されるWelcomeページが変わりました。

What’s Newアイコンクリックで詳細な更新内容が分かります。

目立つ更新内容をピックアップすると、ベースIDEのEclipse 4.12.0.v201906 / CDT9.8.1とGCC8-2019q3-updateへの対応に加え、ダークテーマ表示が可能になりました。

ダークテーマ利用は、Window>Preference>General>Appearance>ThemeでMCUXpresso Darkを選択し、Apply and Closeをクリックします。Dark Themeは、日本語コメントが読みづらく筆者の好みではありません。Restore Defaultsクリックで元に戻りますので、試してみてください。

マイコンテンプレートラインナップ

前稿の2020年1月のCypress PSoC 4000S/4100S/4100PSテンプレート発売で、弊社マイコンテンプレートの販売ラインナップは、下図に示すように全部で8種類（黄色）となりました。

2020年は、ARM Cortex-M0/M0+/M3コアに加え、Cortex-M4コアもテンプレート守備範囲にしたいと考えています。図の5MCUベンダー中、Eclipse IDEベースの最も標準的で、かつ使い易い開発環境を提供するNXPマイコン開発環境が今回更新されたのは、この構想に好都合でした。

Cortex-M7コアのi.MX RT10xxでは、初めからRTOSや高度セキュリティ対策が必須だと思います。Cortex-M4マイコンも高度なセキュリティは必要だと思いますので、SECツールの対応状況も今後注意します。

ARM MCU変化の背景

2019年12月13日2019年12月20日 WithHappy

“昨今の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項目です。

ハイエンドMCU動作周波数高速化、マルチコア化
RTOS普及
セキュリティ対応
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やＭ4でも取得可能。但し、全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実装かつ専用ライブラリ利用が前提なのは、ひしひしと感じています。

MCUプロトタイプ開発のEMS対策とWDT

2019年12月6日2020年1月12日 WithHappy

ノイズや静電気によるMCU誤動作に関する興味深い記事がEDN Japanに連載されました。

どのノイズ対策が最も効果的か？ EMS対策を比較【準備編】、2019年10月30日
最も効果的なノイズ対策判明！ EMS対策を比較【実験編】、2019年11月29日

EMS：（ElectroMagnetic Susceptibility：電磁耐性）とは、ノイズが多い環境でも製品が正常に動作する能力です。

MCUプロトタイプ開発時にも利用すべきEMS対策が掲載されていますので、本稿でまとめます。また、ノイズや静電気によるMCU誤動作を防ぐ手段としてWDT：Watch Dog Timerも説明します。

実験方法と評価結果

記事は、インパルスノイズシュミレータで生成したノイズを、EMS対策有り/無しのMCU実験ボードに加え、LED点滅動作の異常を目視確認し、その時点のノイズレベルでEMS対策効果を評価します。

評価結果が、11月29日記事の図5に示されています。

結果から、費用対効果が最も高いEMS対策は、MCU実験ボードの入力線をなるべく短く撚線にすることです。EMS対策用のコンデンサやチョークコイルは、仕様やパーツ選定で効果が左右されると注意しています。

MCUプロトタイプ開発時のお勧めEMS対策

MCUプロトタイプ開発は、ベンダ提供のMCU評価ボードに、各種センサ・SWなどの入力、LCD・LEDなどの出力を追加し、制御ソフトウェアを開発します。入出力の追加は、Arduinoなどのコネクタ経由と配線の場合があります。言わばバラック建て評価システムなので、ノイズや静電気に対して敏感です。

このMCUプロトタイプ開発時のお勧めEMS対策が下記です。

1．配線で接続する場合は、特に入力信号/GNDのペア線を、手でねじり撚線化（Twisted pair）だけで高いEMS効果があります。

身近な例はLANケーブルで、色付き信号線と白色GNDの4組Twisted pairが束ねられています。このTwisted pairのおかげで、様々な外来ノイズを防ぎLANの信号伝達ができる訳です。

2．センサからのアナログ入力信号には、ソフトウェアによる平均化でノイズ対策ができます。

アナログ信号には、ノイズが含まれています。MCU内蔵ADCでアナログ信号をデジタル化、複数回のADC平均値を計算すればノイズ成分はキャンセルできます。平均回数やADC周期を検討する時、入力アナログ信号が撚線と平行線では、2倍以上（図5の2.54倍より）のノイズ差が生じるので重要なファクターです。従って、撚線で検討しましょう。
平均回数やADC周期は、パラメタ設定できるソフトウェア作りがお勧めです。

3．SWからの入力には、チャタリング対策が必須です。数ミリ秒周期でSW入力をスキャンし、複数回の入力一致でSW値とするなどをお勧めします。
※弊社販売中のMCUテンプレートには、上記ADCとSWのEMS対策を組込み済みです。

4．EMS対策のコンデンサやチョークコイルなどの受動部品パーツ選定には、ベンダ評価ボードの部品表（BOM：Bill Of Matrix）が役立ちます。BOMには、動作実績と信頼性がある部品メーカー名、型番、仕様が記載されています。

ベンダMCU評価ボードは、開発ノウハウ満載でMCUハードウェア開発の手本（＝ソフトウェアで言えばサンプルコード）です。

特に、新発売MCUをプロトタイプ開発に使う場合や、MCU電源入力ピンとコンデンサの物理配置は、BOM利用に加え、部品配置やパターン設計も、MCU評価ボードを参考書として活用することをお勧めします。
※PCB設計に役立つ評価ボードデザイン資料は、ベンダサイトに公開されています。

MCU誤動作防止の最終手段WDT

EMS対策は、誤動作の予防対策です。EMS対策をしても残念ながら発生するノイズや静電気によるMCU誤動作は、システムレベルで防ぐ必要があります。その手段が、MCU内蔵WDTです。

WDTは、ソフトウェアで起動とリセットのみが可能な、いわば時限爆弾です。WDTを一旦起動すると、ソフトウェアで定期的にリセットしない限りハードウェアがシステムリセットを発生します。従って、ソフトウェアも再起動になります。

時限爆弾を爆発（＝システムリセット）させないためには、ソフトウェアは、WDTをリセットし続ける必要があります。つまり、定期的なWDTリセットが、ソフトウェアの正常動作状態なのです。

ノイズや静電気でMCU動作停止、または処理位置が異常になった時は、この定期WDTリセットが無くなるため、時限爆弾が爆発、少なくとも異常状態継続からは復帰できます。

このようにWDTはMCU誤動作を防ぐ最後の安全対策です。重要機能ですので、プロトタイプ開発でもWDTを実装し、動作確認も行いましょう。

※デバッグ中でもWDTは動作します。デバッグ時にWDT起動を止めるのを忘れると、ブレークポイントで停止後、システムリセットが発生するのでデバッグになりません。注意しましょう！

マイコン選択方法2019

2019年11月22日2019年11月29日 WithHappy

MCU：マイコンは、種類が多くどれを自分の開発や製品に使うのが最適か？分りにくいと言われます。この問いに対する回答を示します。具体例として今年5月トランジスタ技術で紹介されたCypress PSoC 4シリーズのMCUを選択します。他ベンダでも同様です。

MCU選択とスマホ選択の差

毎年新機種が発表されるスマートフォン。特にAndroidスマホは、電話の基本機能は同じでも、カメラなどの付加機能やサービス、価格帯が広く、選択に迷います。それでも、何年かスマホを使っていると、どの機能が自分に必須かが分かってくるのと懐具合との兼ね合い、また、古い機種は数年でカタログから消えるので、スマホ選択幅は収束します。

ところが、MCUの場合は、発表後10年以上販売継続されます。スマホとの一番の差です。
古い選択肢も残ったまま新製品が追加され、選択幅が時間とともに広がるのがMCU選択を困難にする要因の1つです。

そこで、広い選択幅からMCUを選ぶ方法を、4段階で示します。

第1段階：適用製品による大枠選択

MCUベンダは、適用製品に合わせてMCUを大分類します。車載とインダストリアル分野では使用温度や内蔵周辺回路などの要件が異なるからです。そこで、第1段階は、この適用製品でMCUを選択します。

例えば、NXPやSTマイクロエレクトロニクストップサイトの“アプリケーションタブ”がこの大枠を示します。
ルネサスエレクトロニクスやCypressの場合は、“ソリューションタブ”です。

ここまでは、多くの方がご存じと思います。分かりにくくなるのは、ココカラです。

第2段階：MCU名称による中枠選択

同じインダストリアル分野のMCUでも、シリーズやファミリなど細かく名称が分かれています。名称が異なるには訳があるので、その理由を理解するのが、第2段階です。この段階では、ベンダ間の買収や合併などの歴史も知っている方が良いです。ポイントは、選択の決め手となる最新カタログの取得です。

Cypressのスマートアプリケーション分野のMCUで説明します。

PSoC 6/4/FM4などの複数MCUから構成されるスマート洗濯機です。PSoC X（X=4,6）は、元々のCypress MCUの名称で、FM4は、2014年に合併した米Spansion（実はSpansionに買収された富士通セミコンダクター）のMCU名称です。

Cypressは、Spansion合併でARM Cortex-M0+ライセンスを取得し、Cortex-M0利用のPSoC 4に適用、その結果生まれた新製品がPSoC 4Sです。PSoC 4Sは、特許取得済み静電容量式第4世代タッチセンサCapSense内蔵のPSoC 4000ファミリへと発展しました。

PSoC 4サイトトップページへ行き製品タブを見ると、さらに細かくPSoC 4000/4100/4200/4700とファミリが分類されており付加機能も異なります。この中枠の段階で製品セレクターガイドなどへ行くとMCU選択に迷ってしまします。他のベンダでも同様です。

この中枠MCU選択の重要資料：Brochureをダウンロードします。Brochureとは、製品パンフレット、カタログのことで、ほぼ毎年更新されます。

どのベンダでも、この中枠MCUを対象とした製品カタログがあります。この最新カタログを見つけるのがMCU選択での最重要事項です。

第3段階：最新カタログと評価ボードによる開発MCU選択

製品カタログには、ベンダがアピールしたい最新MCU情報が詳しく掲載されます。継続販売中の古いMCUや歴史は（紙面の都合上）無視されます。但し、これで新旧MCUを選択のふるいにかけることができます。

世間の話題にはなりにくいMCUの発展速度も、スマホやPC並みに早いのです。最新MCUは、低電力動作や処理効率に優れ、市場ニーズに即した開発が期待できます。

製品カタログには、中枠に相当するMCUファミリ一名称や概略を示す一覧図が掲載されます。

PSoC 4の場合は、下図です。ファミリ名の差（＝意味）をこの図から理解すれば、開発MCU選択は、殆ど（？！）最終段階です。

殆どとは、例えば、エントリーレベル灰色の四角：PSoC 4000SファミリにもFlashやROM、内蔵周辺回路数により多くのMCUがあります。つまり、開発に適すMCUを各四角の中から選択する必要がある訳です。

これには、ファミリ毎にベンダが用意する評価ボード搭載MCUが適します。カタログにも評価ボードが記載されています。

評価ボード搭載MCUは、ファミリ内で最も標準的かつ応用範囲が広く、しかもサンプルコードが付いていますので、MCUを直に動作させることができます。低価格で入手性が良いのも特徴です。開発着手のMCUとしては最適です。

第4段階：プロトタイプ開発による製品MCU選択

評価ボードのMCUを基準にプロトタイプ開発を行い、製品化時のMCU選択をします。

プロトタイプMCUでFlash/RAM不足が懸念されならより大容量MCU、性能不足や周辺回路数不足が懸念されるならより高性能MCUを製品MCUとして選択するなどです。プロトタイプ開発により、製品MCU評価が高精度でできます。

以上の4段階で開発や製品に適すMCU選択ができます。プロトタイプ開発結果をどう活かすかで最適な製品MCU選択ができます。

Cypress PSoC 4 MCU選択具体例

弊社開発中のCapSenseテンプレートに用いるCypress PSoC 4 MCUを、上記の方法で選択した結果を示します。

CapSense は、PSoC 4000ファミリの他社差別化機能の1つです。そこで、このCapSenseを活かすプロトタイプ開発テンプレートを目指します。

CapSenseテンプレートに用いる3ファミリMCU：PSoC 4000S、PSoC 4100S、PSoC 4100PSの特徴を一覧で示します（縦長の図がウェブでは上手く表示できます）。

PSoC 4000S評価ボード：CY8CKIT-145-40XX PSoC 4000S CapSense Prototyping Kit搭載MCUは、CY8C4045AZI-S413（48ピン）です（下図左）。

PSoC 4100S評価ボード：CY8CKIT-041-41XX PSoC 4100S CapSense Pioneer Kit搭載MCUは、CY8C4146AZI-S433（48ピン）です。トラ技5月号付録PSoC 4100S基板実装のCY8C4146LQI-S433（40ピン）も同じファミリですが、ピン数のみが違います（下図中央）。

PSoC 4100PS評価ボード：CY8CKIT-147 Prototyping Kit搭載MCUは、CY8C4145LQI-PS433（48ピン）です（下図右）。

Cypressの３ファミリ評価ボードは、どれも48ピンで揃っているので、比較しやすいでのすが、弊社は、予算の都合上、PSoC 4100Sファミリは、トラ技付録PSoC 4100S基板実装MCU（40ピン）を用います。

CapSenseテンプレート評価ボードMCU（PSoC 4000S評価ボード、トラ技5月付録PSoC 4100S基板、PSoC 4100PS評価ボード）

CapSenseで最重要なタッチUIハードウェアは、PSoC 4000S評価ボードのCapSense基板を、PSoC4100S/4100PS各基板と接続してテンプレート動作確認をします。PSoC 4000S → PSoC 4100SでFlash/RAM容量増加、PSoC 4000S → PSoC 4100PSでアナログフロントエンド強化などへ発展します。

※CapSenseテンプレート完成は、計画当初は2019Q3でした。しかし、PSoC 4100PS評価ボードは、トラ技懸賞品をあてにしており、運よく当選し11月Ｍに当選品が入手できました。2019Eを目途にテンプレート完成の予定です。

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

2019年11月15日2019年11月23日 WithHappy

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に相当します。説明が重複する箇所は、リンク先を参照してください。

移設成功結果

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

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

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

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

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

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

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

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

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

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

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

４．コンパイルエラーがファームウェア起因かを確認するため、ファームウェアだけを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フォルダへ自動保存し、いつでも旧版へ戻せる準備をしています。

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

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

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

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

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

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

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

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

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

４．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だと思います。

最初の図で示した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画面

2019年11月1日2019年11月2日 WithHappy

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

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

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

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

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

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

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

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

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

ステップ05以降の製品開発へも、ステップ01で構築したプロトタイプ環境をそのまま使える
下位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-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プロトタイプテンプレート開発指針です。

Cortex-M0/M0+/M3/M4各コアに用いるテンプレート本体の共通化
プロトタイプ開発ソフトウェア資産流用性を高めるCMSISソフトウェアでの開発
製品化時ベアメタルか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ソフトウェア生産性も高めることができます（一石二鳥）。

弊社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月18日2019年11月1日 WithHappy

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エッジデバイスです。

セキュリティニーズが高い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ファミリパンフレットによると、IDEは、e2 studio（CS+はありません）、エミュレータは、Segger J-Linkまたは、E2エミュレータ Liteです。

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

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

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

残念ながら現時点では、筆者には、RAファミリが魅力的なARMコアIoTエッジMCUとは思えません。今後に期待します。

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

2019年10月11日2019年10月18日 WithHappy

“シェア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事業方針が会見内容です。

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

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

STM32MCUシェア続伸要因

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

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

演算性能の強化（STM32MP1/STM32H7）、より高度なAI実現（STM32CubeMXのAI機能拡張パッケージ）、多様な接続技術への対応（STM32WB）、セキュリティ強化（STM32Trust）の４点がインダストリアル分野MCUのニーズとその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のソフトウェア更新

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

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

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

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