FreeRTOSサンプルコード(4)

2020年2月14日2020年2月21日 WithHappy

タスク数=2のMCUXpresso54114評価ボードSDK付属FreeRTOSサンプルコードの後半2プロジェクト、MutexとSemaphoreを説明します（前半は、前稿参照）。

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

FreeRTOSプロジェクト：タスク数＝2（後半）
Project	Tasks	heap_	Additional FreeRTOS APIs	Additional Comments
freertos_mutex	2	4	xSemaphoreCreateMutex xSemaphoreGive	並列動作の共有リソース同期/競合制御。taskYIELDは要注意！ Mutexのセマフォ作成は、　　 xSemaphoreCreateMutex。 Semaphoreのセマフォ作成は、xSemaphoreCreateBinary。
freertos_sem	1+3	4	xSemaphoreGive

※Freertos_semはタスク数4個。実質はproducer_taskとconsumer_taskの2個。

FreeRTOS Project：freertos_mutex

RTOSソフトウェアのメリットは、複数タスクが「完全に並列動作」することです。ただし、副作用として、共有リソースのアクセス競合が生じます。サンプルコードの場合はIDE Console出力で、その他にUARTやIOポートなど多くの共有リソースがMCUにはあります。

この共有リソースへのセクセス競合を防ぐ手段がミューテックスです。共有リソース使用前に他タスクの使用/未使用を検出し、未使用時のみ利用、利用後は、使用権を戻す操作（xSemaphoreGive）をします。

仮にミューテックス機能が無ければ、英字と数字が混ざった出力になり、使い物になりません。
並列動作のRTOSに、Mutexは必須機能です。

注意点は、Consoleへ部分出力後のtaskYIELDです。

F3クリックで調べましたがtaskYIELDの理由は、筆者には不明です。だだし、コメントを読むとFreeRTOSインプリメント依存部分なので、そのまま弄らない方が良さそうです。共有リソース利用中には、taskYIELDが必要と覚えておけば（とりあえず）良いとします。
※本調査の目的は、ベアメタルCortex-M4テンプレート開発へのRTOS機能応用であって、FreeRTOS自身ではないので、この程度で留めていきます👍。

共有リソース使用検出APIは、xSemaphoreTakeです。前稿freertos_ticklessプロジェクトの割込みISRと処理タスク同期に用いたAPIと同一です。差分は、セマフォ自体の作り方が異なります。ミューテックスの場合は、xSemaphoreCreateMutex、セマフォの場合は、xSemaphoreCreateBinaryです。

違いは、初期値です。ミューテックスは、初期値が使用可能（pdTRUE）になりますが、セマフォは、初期値が使用不可です。どちらも、並列動作タスク間の同期/競合制御として、同じAPI：xSemaphoreTakeを使っているということです。

FreeRTOS Project：freertos_sem

前稿freertos_ticklessで示したISRと処理タスクのセマフォ同期とは別の使用例が、freertos_ semプロジェクトです。同期というより、むしろ排他制御にセマフォを使った例です。

このプロジェクトは、これまでのサンプルコードで最も多い４タスク：1（producer_task）+3（consumer_task）を生成し、2個のセマフォ（xSemaphore_producerとxSemaphore_consumer）を使い、1個のアイテムを4タスク間で利用する例です（Doc>freertos_sem_example.txtによるとランデブーモデル同期と言うようです）。

1個の（共有）アイテムは、元々produser_taskが持っており、cunsumer_taskへその使用権を与えます（L119:xSemaphoreGive→xSemaphore_consumer）。

並列動作中の3個cumsumer_taskのどれかがこの使用権を取得します（L143:xSemaphoreTaka←xSemaphore_consumer）。使用後は、produser_taskへ使用権を返却します（L141:xSemaphoreGige→xSemaphore_producer）。

produser_taskは、cunsumer_taskの使用権返却を待っており（L121: xSemaphoreTaka←xSemaphore_producer）、返却後、再び最初に戻ってcunsumer_taskへ使用権を与えます。

cunsumer専用セマフォがxSemaphore_consumer、producer専用セマフォがxSemaphore_producerで、それぞれを図示したようにやり取りしながら4タスクが動作します。

ベアメタル風に、ランデブーモデル同期：synchronized in bilateral rendezvous modelを解説すると上記のようになります。

ソースコード上では、どのcumsumer_taskが共有アイテムを獲得するかは不明ですが、評価ボード実行結果は、常にConsumer 0→1→2→0･･･の順番でした。3個のcumsumer_taskプライオリティが同一の時は、生成順に1個のアイテム共有ができるようです。

FreeRTOSサンプルコード：タスク数＝2（後半）の調査結果

FreeRTOSタスク並列動作副作用の共有リソースアクセス競合回避手段に、ミューテックスがある
MCUXpresso54114 のFreeRTOS共有リソース利用途中には、taskYIELDが必要
初期値（pdTRUE）の有無が、ミューテックス作成とセマフォ作成で異なる
バイナリセマフォの排他制御利用例に、ランデブーモデル同期がある
メモリ使用法は、heap_4を利用

FreeRTOSデバイス依存開発ノウハウ

筆者のOS：Operating System利用アプリケーションソフト開発経験は、Windows PCのみです。Windows OSは、リアルタイム性はありません。そのおかげで、PCアプリケーションソフト開発時に、他タスクへの影響、プライオリティなどは考慮せずに比較的簡単に開発ができました。

ミューテックスやセマフォを利用した覚えもありません。もちろんファイルなどの共有リソースには、それなりのアクセス手順があり、それに従って開発すれば特に問題はありません。

一方MCUでOS利用の場合は、リアルタイム性は無視できません。限られたMCU能力を上手く利用するためのデバイス依存開発ノウハウが、メモリ使用法：heap_4やtaskYIELDだと思います。

これらノウハウは、ソースコード上では解りにくい代物です。また、文章記述できる量も限られます。

これには、評価ボード上でソースコードのパラメタを変えた時の挙動変化を開発者自身がつかんで習得する方法が効率的です。LPCXpresso54114（Cortex-M4/M0+ 100MHz、256KB Flash、192KB RAM）評価ボードは、入手性もよく低価格（約3400円）です。無償LPCXpresso IDEとともにご利用いただければ、本稿やFreeRTOSがより解り易くなります。

PS：FreeRTOSの最新版V10.3.0が2020年2月7日に公開されました。詳細は、リリースノートをご覧ください。

FreeRTOSサンプルコード(3)

2020年2月7日2020年2月14日 WithHappy

タスク数=1の前稿FreeRTOSサンプルコード(2)に続き、本稿は、タスク数=2のMCUXpresso54114評価ボードSDK付属FreeRTOSサンプルコードの前半3プロジェクトを説明します。

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

FreeRTOSプロジェクト：タスク数＝2（前半）
Project	Tasks	heap_	Additional FreeRTOS APIs	Additional Comments
freertos_tickless	2	4	vTaskDelay xTaskGetTickCount xSemaphoreCreateBinary xSemaphoreGiveFromISR xSemaphoreTake	FreeRTOS低電力動作とSW_taskの2タスク並列動作説明。 Tickless_taskは、vTaskDelay、前稿hello_taskは、vTaskSuspend。 SW_taskは、Tickless_taskに何ら影響を与えない。
freertos_i2c	2	4	xSemaphoreCreateBinary xSemaphoreGiveFromISR xSemaphoreTake	master_taskとslave_taskの2タスク構成。正常動作結果は、Console窓出力。DoC>readme.txtでも結果が判る。
freertos_spi	2	4	xSemaphoreCreateBinary xSemaphoreGiveFromISR xSemaphoreTake	同上

タスク数=2のサンプルコードは、上記以外にもFreeRTOS特徴のミューテックスとセマフォ利用例がありますが、これらは次回説明します。

FreeRTOS Project：freertos_ tickles

前稿説明のhello_taskは、Console窓に文字を１回出力し、「待ち状態」になりました。
hello_task とよく似たTickless_taskは、文字の代わりにxTaskGetTickCountで得た数字を１回出力し、vTaskDelayで5秒間の「停止状態（＝低電力動作：Sleep）」になります。

低電力動作からの復帰Eventで、Tickless_taskは停止状態から実行可能状態へ移行し、スケジューラによって再実行されます。停止時間5秒間のtick回数がConsole窓に出力されます。
※FreeRTOSタスクの状態遷移図は、マイコンRTOS習得2017の第２部を参照。

このプロジェクトは、Tickless_task が、SW_task動作に全く影響を受けないFreeRTOSの特徴を説明しています。

つまり、Tickless_taskと、SW_taskは、それぞれ別々にあたかも自分のタスクがMCUを占有するように記述されており、かつその通り並列動作します。これがFreeRTOS利用ソフトウェア開発の最大メリットです。タスク開発は、ベアメタルソフトウェア開発に比べ簡単に、かつ流用性も大きくなるでしょう。

※SW3プッシュは、ソフトウェア、ハードウェアで何もチャタリッグ防止策をしていない処理の検証にも使えます。試しにSW3を長く押してチャタリッグが発生することを確かめてください。チャタリッグ防止策の必要性が解ります。

FreeRTOS Project：freertos_ i2cとfreertos_ spi

freertos_ i2cとfreertos_spiプロジェクトは、どちらもMCU内蔵I2C、またはSPIを使った外部デバイスとの通信サンプルコードです。どちらもmaster_taskとslave_taskの2タスクから構成されています。

main.cでslave_taskのみをタスク登録し、slave_task内でmaster_taskを登録しています。このように、FreeRTOSスケジューラ起動後でも、任意の場所で新たなタスク登録が可能です。

動作は、最初master_taskでデータ送信し、それをslave_taskで受信、次にslave_taskがデータ送信し、それをmaster_taskで受信し、両タスクとも正常終了します。

この動作シナリオは、slave_taskに記述されており、master_taskのデータ送信開始は、slave_taskのmaster_task登録の結果、並列実行されます。slave_taskのデータ受信と送信完了は、i2c_slave_callbackからのセマフォを使って判断しています。

評価ボード実装Arduinoコネクタ上の配線で、送受信データをループバック接続しますので、評価ボード1台のみで両タクス動作結果が、IDEのConsole窓に出力されます。

MCUXpresso54114評価ボードをお持ちでない方は、両プロジェクトのDoc>readme.txtのRunning the demoにConsole窓出力と同じ結果があるので解ります。

I2C/SPI通信対象のデバイスは、従来からの外付けEEPROMに加え、最近ではIoTセキュティデバイスなどがあります。

IoTセキュティデバイスは例えば、NXPのEdgeLookやMicrochipのCryptoAuthenticationファミリなどがあり、IoT MCUのクラウド接続には、これらデバイス利用が必須になりそうです。

I2C通信のIoTセキュリティデバイス接続例（出典：NXP SE050データシート）

FreeRTOSサンプルコード：タスク数＝2（前半）の調査結果

FreeRTOS低電力動作（Sleep）は、vTaskDelay（msec）で低電力動作開始と復帰
タスク数が2と少ないので、タスク並列動作が解り易く、プライオリティ設定とその意味も理解容易
I2C/SPI割込みISRとのタスク同期に、バイナリセマフォ利用
割込みcallback関数でセマフォをgive → 割込み処理タスクでセマフォをtake → セマフォ消滅
IoT MCUは、セキュティデバイスとのI2C接続可能性大
メモリ使用法は、heap_4を利用

セマフォ（Semaphore）同期は、マイコンRTOS習得2017の第3部：Semaphoreによるタスク同期の章に、図入り解説していますのでご参照ください。

FreeRTOSサンプルソースコードは、MCUXpresso IDEのみでも御覧頂けます。是非、PCへインストールし本稿をご参照ください。

FreeRTOSサンプルコード(1)

2020年1月24日2020年1月31日 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

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

Task List：タスク毎のプライオリティ、スタック使用量、動作時間表示
Queue List：アクティブキュー、セマフォ、ミューテックス利用時のリソース表示
Timer List：RTOSタイマー表示
Heap Usage：ヒープ使用量、メモリブロック割当て表示

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

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

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

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を目途にテンプレート完成の予定です。

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

2019年11月1日2021年2月15日 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日2021年12月4日 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ソフトウェアでは論外なため、開発者負担は増すばかりです😫。