タグ: ARMマイコン

中国製STM32互換MCU

WithHappy

1月28日、EE Times Japanに“互換チップが次々と生まれる中国、半導体業界の新たな潮流”という記事が掲載されました。スイス・ジュネーヴ本社のSTマイクロエレクトロニクス（以下STM）のSTM32互換MCUが、中国で製造プロセス縮小、ローコスト化し販売中だそうです。

STM32F030、STM32F103互換MCU

記事記載の互換デバイスは、STM32F030（Cortex-M0、64KB Flash、8KB RAM）と、STM32F103（Cortex-M3、７2MHz、128KB Flash、20KB RAM）の2種。どちらもSTM純正180nmプロセス製造MCUを、130nmプロセスで製造しており、ローコスト化、低電力化、動作周波数アップが狙いです。

STM32F103搭載のNucle-F103RB評価ボード
STM32F103搭載のNucle-F103RB評価ボード

さらに、ARM Cortex-Mコア部分のみをオープン仕様RISC-Vコアへ変えた、STM32互換RISC-V MCUもあるそうです（記事、図４参照）。

記事筆者の清水氏（テカナリエ）は、これら中国製互換デバイスを否定するのが目的ではなく、現状の事実、互換製造ができる高い技術力、STM32MCUが汎用MCUデファクトスタンダードであること、中国半導体業界のこの方向性が、ますます加速する可能性があると報告しています。

日本が見習うべきもの

RISC-Vはオープン仕様ですが、Cortex互換MCU販売には、ARMライセンスフィーなど気になる事柄もあります。但し、本ブログ筆者も清水氏と同じく、その背景にある技術力、ビジネスセンスについて見習うべきものが多いと思います。

STM互換MCUは、純正品よりも安く、しかも高性能です。開発環境や評価ボード、開発ソフトウェアはそのまま互換MCUでも動作します。欧州ベンダのSTM互換MCU開発・販売は、米国ベンダ互換よりもハードルが低いでしょう。世界情勢なども反映された成功事例だと思います。

例え安く高性能な部品（BOM：Bill Of Matrix）が提供されても、それを使って開発できる技術者がいなければ製品化はできません。技術者スキルが最も伸びるのは、開発中です。中国技術者は、高性能製品を低価格で、次々と提供できている事実があります。

もちろん失敗事例もたくさんあるハズです。しかし、技術者にとっては、成功失敗を問わずどんな事例でも開発経験はスキルに直結します。

一方、日本の環境は、時短や効率化など見た目の生産性や成功例のみに注目しがちです。ただ、技術者スキルは世界レベルで評価されるので、このままの環境では、先々の日本開発案件は無くなるのではと危惧しています。

例えば自動車は、日本メーカを選択する人はいても、それが日本開発かは問題にしません。むしろ世界各地で開発されています。
※日産の先進自動運転技術（ADAS）は、米国女性技術者が中心で開発されたと、何かで読んだ記憶があります。

5G、6G世代のネット高速化、自動翻訳やAIなどの環境変化で、日本開発に拘るユーザは、減少の一途となるでしょう。

日本技術者は、次世代の自分自身のため、世界で通用するスキルを身に付ける必要があります。

弊社STM32F0/F1に使えるSTM32FxテンプレートやSTM32G0xテンプレート、その他ベンダのMCUテンプレートは、初心者～中級レベルソフトウェア技術者向きです。初級～中級技術を効率的に習得し、さらに高度なスキル獲得に少しでもお役立てれば幸いです。と、最後は自社広告になってしまいました😌。

FreeRTOSサンプルコード(2)

WithHappy

FreeRTOSデバッグは、ベアメタルソフトウェアデバッグと異なる準備が必要です。

幸いなことに、前稿で示したMCUXpresso54114評価ボードとSDK付属FreeRTOSサンプルコードを使ってMCUXpresso IDEでFreeRTOSデバッグを行う場合は、この準備がサンプルコードやIDEデバッガに予め設定済みです。何もせずに直にデバッグができます。

FreeRTOSデバッグ準備

但し、LPCOpenライブラリFreeRTOSサンプルコードを利用する場合や、FreeRTOSソフトウェアを自作する場合には、この事前準備を知らないとFreeRTOSデバッグができません。
※LPCOpenライブラリと下記MCUXpresso IDE FreeRTOS Debug Guideも前稿参照。

MCUXpresso IDE FreeRTOS Debug Guideの2章に、準備理由や追加設定個所が詳細に記載されています。

  • デバッグリンクサーバー（CMSIS-DAP）のAll-Stopモードへ切り替え　※デフォルトはNon-Stopモード
  • FreeRTOSカーネルソースコード修正　※SDK付属サンプルコードは修正済み
  • メモリ使用法の設定

上2つは、IDEでFreeRTOS本体動作確認のための設定、メモリ設定は、限られたMCUメモリの活用方法でheap_1～5まで5種類あります。

これらは、ベアメタル開発とは異なるFreeRTOS利用オーバーヘッドで、メモリ使用法は、動作するMCU毎に異なりノウハウが必要になると思います。MCUXpresso54114評価ボードSDK付属FreeRTOSサンプルコードのメモリ使用法は、調査します。

FreeRTOSサンプルコード：タスク数＝1

MCUXpresso54114 SDK v2.7.0の11個あるFreeRTOSサンプルコードを、タスク数で並び換えたのが下表です。本稿は、タスク数＝1のFreeRTOSプロジェクトを調査します。

FreeRTOSソフトウェア開発は、タスク数が少ない方が理解し易くタスクプライオリティ設定も不要です。この中では、freertos_swtimerが一番簡単、下方につれて複雑なプロジェクトになります。

FreeRTOSプロジェクト：タスク数＝1
Project Tasks heap_ Additional FreeRTOS APIs (Bold) Additional Comments
freertos_swtimer 1 4

xTaskCreate
vTaskStartScheduler
xTimerStart

IDE Console出力
ユーザ作成Software Timerデモ
freertos_hello 1 4

xTaskCreate
vTaskStartScheduler
vTaskSuspend

IDE Console出力
freertos_usart 1 4

xTaskCreate
vTaskStartScheduler
vTaskSuspend

Usart 115200bps 8-Non-1送受信
4B受信後エコーバック

※heap_4：断片化を避けるため、隣接する空きブロックを結合。絶対アドレス配置オプション含む。
※FreeRTOS API接頭語x/v：API戻り値型を示し「v」がvoidを、「x」が結果コードまたはハンドルを返す。

サンプルコード利用FreeRTOS APIと、Doc>readme.txtのProject説明へ付け加える内容をAdditional Commentsに記載しました。太字以外のFreeRTOS APIは、マイコンRTOS習得2017で説明済みのため、本稿では省略します。

xTimerStartは、ユーザ作成ソフトウェアタイマの動作開始FreeRTOS APIです。

IDE Consoleは、ソースコード内へマクロ：PRINTFを挿入すると、IDE下段Console窓へ数値や文字列などの入出力が簡単にできる機能です。

FreeRTOS Project：main()

ベアメタルmain()と同様、初期設定＋無限ループの構造です。
差分は、タスク登録とスケジューラー起動から成るFreeRTOS初期設定が、評価ボード初期設定後に加わることです。

FreeRTOS Project main()構造（freertos_helloにコメント加筆）
FreeRTOS Project main()構造（freertos_helloにコメント加筆）

FreeRTOS Project：freertos_swtimer

ユーザ作成の1秒ソフトウェアタイマ割込み（SwTimerCallback）を使って、Console窓にTick文字を出力します。タスク登録直後、xTimerStartでユーザタイマをスタートしています。

例えば、ユーザ入力待ちの開始時にxTimerStartし、ユーザ反応が何もない時のタイムアップ処理などに使うと便利です。

FreeRTOS Project：freertos_hello

タイトル出力など1回限りのConsole窓出力に便利です。hello_taskは、出力後、vTaskSuspendで待ち状態になります。タスク正常終了後は、vTaskSuspend処理が一般的なようです。

FreeRTOS Project：freertos_usart

UART0の115200bps 8-Non-1を使ったVirtual COMポート送受信タスクです。受信リングバッファ利用で4B受信後に受信文字をエコーバックします。4Bまとめてのエコーバックは、1B毎よりも効率的です。

例えば、処理途中で割込みなどの他処理が入っても、受信リングバッファ利用で取りこぼしデータがなく、かつ、RTOSが処理中断/再開を行うので、このような記述がFreeRTOSマルチタスク動作に好都合かもしれません。
ベアメタル開発にはないRTOSソフトウェア開発ノウハウの可能性があります。

※筆者自身RTOSは初心者です。本調査結果は、FreeRTOS APIレファレンス等も参照して記述しておりますが、多分に上記のような推測の域があることはご容赦ください。

FreeRTOSサンプルコード：タスク数＝1の調査結果

  • FreeRTOS初期設定（タスク登録とスケジューラー起動）が、評価ボード初期設定後に追加
  • PRINTFを活用したFreeRTOSタスク単体デバッグの手本
  • タスク正常終了後は、vTaskSuspend処理
  • UART0利用VCOM送受信タスク（uart_task）は、移植性が高く、流用・応用が容易
  • メモリ使用法は、heap_4を利用

ここで示したFreeRTOSサンプルコードは、MCUXpresso54114評価ボードがあると動作確認が可能ですが、無くてもMCUXpresso IDEをPCへインストールすれば、どなたでもコストがかからず参照頂けます（インストール方法は、関連投稿：NXPマイコン開発環境更新を参照）。

普段NXPマイコンをお使いでない方も、MCUXpresso IDEをインストールしFreeRTOSサンプルコードをご覧ください。不要になった後は、IDEアンインストールも簡単です。

以降のFreeRTOSサンプルコード関連投稿は、お手元に上記開発環境があるものとして説明いたしますので、よろしくお願いいたします。



FreeRTOSサンプルコード(1)

WithHappy

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に沿って調査します。

STM32G071RBとAlexaを繋ぐ

WithHappy

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ピンパッケージでも１ペア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.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マイコン開発環境更新

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 4 Tools
NXPマイコン統合開発環境のMCUXpresso 4 Tools

更新方法をまとめると、

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

MCUXpresso IDE v11.1更新内容

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

MCUXpresso IDE v11.1 Welcome Page
MCUXpresso IDE v11.1 Welcome Page

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/01
マイコンテンプレートラインナップ2020/01

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

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

ARM MCU変化の背景

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項目です。

  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やＭ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

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の信号伝達ができる訳です。

信号とGNDの4組Twisted pairを束ねノイズ対策をするLANケーブル
信号とGNDの4組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

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で説明します。

スマートアプリケーション分野MCU使用例（出典：Cypressサイト）
スマートアプリケーション分野MCU使用例（出典：Cypressサイト）

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 4ファミリ一覧図（出典：PSoC 4 Brochure）
PSoC 4ファミリ一覧図（出典：PSoC 4 Brochure）

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

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

ファミリ毎に用意される評価ボード（出典：PSoC 4 Brochure）
ファミリ毎に用意される評価ボード（出典：PSoC 4 Brochure）

評価ボード搭載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の特徴を一覧で示します（縦長の図がウェブでは上手く表示できます）。

CapSenseテンプレート対象3MCUファミリ比較
CapSenseテンプレート対象3MCUファミリ比較

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テンプレート評価ボード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移設

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

移設成功結果

G0AdcTemplateのSTM32CubeIDE移設成功結果
G0AdcTemplateのSTM32CubeIDE移設成功結果

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

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

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

最新開発環境ファームウェアとアプリケーション開発時ファームウェア

最新開発環境ファームウェアとテンプレート開発時ファームウェア
最新開発環境ファームウェアとテンプレート開発時ファームウェア

投稿その2で示したように、MCU開発ソフトウェア（＝アプリケーション）に最も影響を与えるのは、ファームウェア更新です。

STM32FxテンプレートのF0用ファームウェアFW_F0は、開発当時のv1.8.0からv1.11.0へ、F1用ファームウェアはv1.4.0からv1.8.0へ、G0用ファームウェアFW_G0はv1.2.0からv1.3.0へそれぞれ更新されています。
※STM32G4テンプレートは、これから開発着手しますので最新のv.1.1.0のままです。

次章3から5章までを使って、STM32F1テンプレート：F1BaseboardTemplateを例に、当時の開発環境から最新開発環境への移設作業、ファームウェア変更、トラブルシューティングを「詳細に説明」します。但し、結果として行う処理は、6章まとめに示す簡単なものです。途中の章は読み飛ばしても構いません。

開発済みMCUアプリケーションを暫くたってから更新、または本稿のようにIDE自体が変わり最新開発環境へ移設することはよくあります。F1BaseboardTemplateをお持ちでない方も、（手前みそですが）次章から5章の内容は参考になると思います。

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

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

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

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

SW4STM32プロジェクトインポート後、プラグイン版STM32CubeMXで開いたプロジェクトファイル
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を選択します。

スタンドアロン版STM32CubeMXでファームウェア版数を変える方法
スタンドアロン版STM32CubeMXでファームウェア版数を変える方法

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

STM32CubeIDEのBuild Analyzer
STM32CubeIDEの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画面
TeraTerm画面とSTM32CubeIDEのSerial Console画面

最新開発環境移設の課題と対策、テンプレート改版予定

現状のCubeIDE v1.1.0は、コード生成後、日本語コメントに文字化けが発生します。また、エディタタブ幅が2のまま変更できません。これら以外にも細かな不具合があります。このままでは、筆者には使いにくいIDEです。一方、Build AnalyzerやSerial Consoleは、とても役立ちます。
CubeIDEプラグイン版CubeMX v5.4.0は、Repository旧ファームウェアへの変更機能が無く、最新ファームウェアのみ利用可能です。

これら移設課題に対して、投稿その1から本稿で対策を示しました。

現状は、従来SW4STM32からCubeIDEへの「IDE移設過渡期」です。筆者は暫く両IDEを併用するつもりです。そして、新環境の使いにくい箇所が解消された時点でCubeIDEへ完全移設し、同時に汎用MCU第2位、シェア20％超のSTM32MCU向けテンプレートとしてSTM32FxテンプレートとSTM32G0xテンプレートを、本稿変更などを加え最新開発環境対応へ全面改版する予定です。

既に弊社テンプレートをお持ちの方や全面改版を待てない方は、まとめ6章の方法で移設可能です。但し、投稿その2で示した多くのリスクがありますのでお勧めはしません、自己責任で行ってください。

なお、新開発のSTM32G4テンプレートは、初めから最新CubeIDE、CubeMXで開発着手します。

＊　　＊　　＊

STマイクロエレクトロニクスのSTM32CubeIDE v1.1.0改版により、旧SW4STM32開発アプリケーションを新環境へ移設する連続3回の投稿、いかがでしたでしょうか？　詳細説明がリンク先となり、筆者にしては長文投稿でしたので、解りづらかったかもしれません😌。

IoTによりMCU開発環境は、より急ピッチで変わります。最新デバイスと最新API利用が、その時点で最も効率的で優れたMCUアプリケーション開発手段です。環境急変にも柔軟対応できる開発者が求められます。

最新開発環境に上記のような課題が多少あっても、従来SW4STM32開発済みアプリケーションの最新STM32CubeIDE移設は、6章で示した１行追記のみで成功しました。

但し、顧客や管理者の方には、開発環境更新、移設の危うさや開発者の心理的負担、何よりもそれらへの対応時間は、あまり表に出てこない部分、また移設してみて初めて判る部分で理解されづらいものです。

本稿がMCUアプリケーション顧客、管理者、開発者の方々のご参考になれば幸いです。

P.S：2019年11月12日、2か月遅れでWindows 10 1909配布が始まりました。年2回のWindows 10大型更新トラブル話は多数あります。MCU開発環境は、年2回どころか度々更新されます。開発者は、その度にトラブル対処をしているのです👍。ちなみに本稿は、全てWindows 10 1903での結果です。

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

WithHappy

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テンプレート付きの方が売れるのでやむを得ない状況です😥。

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