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サンプルコード(2)

2020年1月31日2020年2月1日 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：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)

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起動を止めるのを忘れると、ブレークポイントで停止後、システムリセットが発生するのでデバッグになりません。注意しましょう！

総務省：2020年4月以降IoT機器アップデート機能義務化予定

2019年9月13日2019年9月20日 WithHappy

総務省は、電気通信事業法を改正し、2020年4月以降「IoT機器アップデート機能義務化を予定」しているそうです（日経ビジネス2019年9月6日有料会員限定記事、“モノのインターネットに死角あり狙われるIoT機器”より）。

本稿は、普通のMCU開発者が知るべき最低限のIoT MCUセキュリティ対策をまとめてみたいと思います。

IoT MCUセキュリティ

記事には、“歴史の浅いIoT機器は、開発者とユーザ双方にセキュリティ意識が欠如している“、”開発者は、便利で魅力的な機能搭載を優先し、セキュリティ配慮は2の次”とあります。確かにそうゆう見方はあります。

しかし、サイバー攻撃やセキュリティ関連ニュースが溢れる昨今、開発者/ユーザともに無関心ではないハズです。むしろ、現状のMCU能力では、セキィリティ強化が無理な側面を十分知った上で妥協している（目を瞑っている）のが事実だと思います。

セキィリティ関連記事は、その性質上、英語の省略用語を多用し、漏れがない細かい説明が多いので、全体を把握したい普通のMCU開発者には、解りにくいと筆者は考えています。

そこで、全体把握ができるMCUセキュリティのまとめ作成にトライしたのが次章です。

サイバー攻撃対策

MCUセキュリティ機能は、サイバー攻撃を防ぐための対策です。サイバー攻撃には、以下3種類があります。

ウイルス感染
通信傍受
通信データ改ざん

2）通信傍受対策には、暗号化が効果的です。暗号化処理には、データをやり取りする相手との間に鍵が必要で、共通鍵と公開鍵の2方式があります。共通鍵は、処理負荷が公開鍵に比べ小さく、公開鍵は、鍵を公開する分、処理負荷が大きくなる特徴があります。

3）通信データ改ざん検出には、ハッシュ関数（＝要約関数）を使います。ハッシュ関数に送信データを与えて得た値をハッシュ（＝要約値）と言います。送信データにハッシュを追加し、受信側でハッシュ再計算、送受ハッシュ一致時がデータ改ざん無しと判定します。

2）と3）は、データ通信が発生するIoT MCUセキィリティ機能です。暗号化、ハッシュ関数は、新サイバー攻撃に対し、次々に新しい防御方式が提案される鉾と盾の関係です。MCU外付けセキュリティデバイス（例えばNXPのEdgeLock SE050など）によるハードウエア策もあります。

PCやスマホのようなウイルス対策ソフト導入が困難なMCUでは、1）のウイルス感染対策に、MCUソフトウェアのアップデートで対応します。総務省は、IoT機器にアップデート機能とID、パスワード変更を促す機能を義務付ける予定です。
※開発者自身で溢れるウイルス状況を常時監視し、ソフトウェア対応するかは不明です。

従来のMCUソフトウェアアップデートは、UART経由やIDE接続で行ってきました。しかし、ネットワーク経由（OTA）やアクセス保護のしっかりしたソフトウェア書換えなどを、1）のアップデートは想定しています。

以上、ごく簡単ですが、MCUセキュリティ対策をまとめました。

総務省の「IoT機器アップデート機能義務化」が、具体的にどのようになるかは不明です。ただ、無線機器の技適規制などを考えると、技術ハードルは、かなりの高さになることが予想できます。

ディアルコアや超高性能汎用MCUの背景

簡単にまとめたMCUセキィリティ対策を、IoT機器へ実装するのは、簡単ではありません。

実現アプローチとしては2つあります。

1つ目は、ディアルコアMCU（例えばNXPのLPC54114、関連投稿：ARM Cortex-M4とM0+アプリケーションコード互換）や、超高性能な汎用MCU（例えばSTMのSTM32G4、関連投稿：STM32G0x専用テンプレート発売1章）が各ベンダから発売中です。

これら新世代MCU発売の背景は、従来MCU処理に加え、法制化の可能性もあるセキュリティ処理実装には、MCU処理能力向上が必須なためです。

ワールドワイドにIoT機器は繋がります。日本国内に限った話ではなく、地球規模のIoT MCUセキュリティ実装に対し、ディアルコアや超高性能汎用MCUなどの新世代MCUでIoT機器を実現するアプローチです。

2つ目が、セキュリティ機能が実装し易いMPU（例えばRaspberry Pi 4など）と、各種センサー処理が得意なMCU（旧世代MCUでも可能）のハイブリッド構成でIoT機器を実現するアプローチです。

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

2019年8月30日2020年11月28日 WithHappy

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

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

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

MCUXpresso SDK

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

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

CMSIS：セムシイスまたはシムシス

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2018年IoTトレンドと2019年予想記事をEdge MCU開発者観点で読む

2019年2月18日2019年3月3日 WithHappy

セキュリティ、産業IoT、通信事業者との連携、ウェアラブルデバイスという4テーマで2018年IoTドレンドとその予想結果、2019年のそれらを予想した記事がTechTarget Japanに掲載されています。

本稿はこの記事内容を、マイコン：MCU、特に本ブログ対象Edge MCU開発者の観点から読みたいと思います。

IoTサービス観点からの顧客目線記事

一言でIoTと言っても様々な観点があります。本ブログ読者は、殆どがMCU開発者なので、顧客がどのようなIoT開発を要求し、それに対して自社と顧客双方のビジネス成功をもたらす「ソリューション提供」が最も気にする点だと思います。

一方、要求を出す側の顧客は、記事記載の「IoTサービス」に注意を払います。そのサービス実現手段として、ベンダー動向やMCU開発者自身の意見を聞いてくるかもしれません。そんな時、日頃の技術動向把握結果を具体的に顧客に提示できれば、顧客案件獲得に有効なのは間違いありません。

顧客と開発者のIoT捉え方は異なる。 — 顧客はサービス観点でIoTを捉える。開発者はソリューション提供でIoTを捉える。

そこで、記事の4テーマ毎にEdge MCU開発者の観点、特にEdge MCU最新動向を関連投稿とともに示します。

セキュリティ

Edge MCUセキュリティ強化策として、昨年頃からMCUにセキュリティ機能を内蔵するか、または、MCU外付けに専用セキュリティチップを追加する動きが出始めました。
要するに、IoTではEdge MCUでデジタルデータ暗号化機能実装が必須になりつつあるのです。
関連投稿：守備範囲が広いSTM32G0のアクセス・ライン製品
関連投稿：IoTマイコンとセキュリティの色々なセキュリティ強化方法

産業IoT

産業機器データ収集と分析の重要性は顧客に認識されていますが、IoT導入は記事にあるように初期段階です。Edge MCUも、産業用にも流用できるメリットを示すIoT MCU新製品もありますが、車載用の新製品が多い状況です。
関連投稿：NXP新汎用MCU S32K1

通信事業者との連携

国により大きく異なる通信事業者とそのサービスや連帯を一言で表すことは困難です。ただし、日本国内でのIoTフィールドテストは、今一つ盛り上がりに欠ける感じが個人的にはします。やはり、黒船（海外発のIoT通信デファクトスタンダードとその普及）が必要かな？と思います。

ウェアラブルデバイス

Edge MCUに近距離無線通信（NFC）機能を搭載したり、AI機能（機械学習）を搭載しHuman Activity Recognition：人間活動認識を実現したりする新しいEdge MCI製品が登場しています。
関連投稿：NFCを使うLPC8N04のOTA
関連投稿：MCUのAI機能搭載

2019年2月18日速報：タイムリーなことに、Motor Fan Techという自動車関連の情報誌で、次世代ARM v8.1-Mアークテクチャが、業界最小の組み込みデバイス向けに、強力な信号処理を実現が掲載ました。次世代Cortex-Mプロセサは、機械学習（ML）パフォーマンスを最大15倍、信号処理パフォーマンスを最大5倍向上させるそうです。

IoTサービス例を顧客に示せるEdge MCUテンプレート構想

2018年3月の弊社LPC8xxテンプレートV2.5改版以降、新開発のマイコンテンプレートはありません。その理由は、記事にもあるIoTの急速な普及・変化が無かったことも1つの理由です。

これまでの弊社マイコンテンプレートの目的は、「開発者個人が低価格でMCU開発を習得すること」でした。このため、各ベンダーの汎用MCUとBaseboardを使い、そのMCU基本的動作開発までを1つの到達点としてきました。

2018年後半から新しいIoTトレンドに沿った新Edge MCUが各ベンダーから発売済みです。そこで、マイコンテンプレートも、顧客目線やその観点を取り入れた到達点へステップアップしようと思います。

顧客は単にMCUが動作するだけでなく、何かしらのサービス提供をしているIoT MCUを見たいでしょう。この「IoTサービス例を、開発者個人が、低価格かつ簡単に示せるマイコンテンプレート」が新しいEdge MCUテンプレートの構想です。

この場合の顧客とは、ビジネス顧客に限らず、開発者の上司や同僚、さらに、開発者自身でも良いと思います。開発結果がIoTサービスに関連していれば、誰でもその効果が判り易いハズです。

期待されているIoTサービスならば、開発者もMCU開発がより楽しく、その習得や応用サービスへの発展もより具体的かつアグレッシブになると思います。と言っても、クラウドを含めたIoTサービスを開発・提供するのは、個人レベルでは無理です。
従って、ほんの触り、一部分のIoTサービスになります。それでも、見る側からは、開発内容が解りやすくなります。

もはやMCUが動作するのは、当たり前です。その上で、＋αとしてEdge MCUがIoTで出来るサービス例を示し、さらに、Edge MCU習得も効率的にできるのがEdge MCUテンプレートです。

今後開発するEdge MCUテンプレートは、IoTサービス指向の結果、これまでマイコンテンプレートが持っていた汎用性が少し犠牲になる可能性もあります。ただ、従来の汎用MCUの意味・位置づけもIoTで変わりつつあります。
関連投稿：RL78ファミリから解る汎用MCUの変遷
関連投稿：STM新汎用MCU STM32G0）

MCU基本動作に加え、何らかのIoTサービス提供例を示す工夫をEdge MCUテンプレートへ加えるつもりです。

Arduinoコネクタを持つMCU評価ボードが多い理由

2019年2月4日2019年2月11日 WithHappy

本稿は、Arduinoコネクタを持つMCU評価ボードが多い理由を、少し丁寧に説明します。上図は、Arduinoコネクタレベルでコンパチブル（＝置換え可能）なSTマイクロエレクトロニクス、サイプレス・セミコンダクター、NXPセミコンダクターズ各社のMCU評価ボードを示しています。

Arduinoコネクタ

イタリア発で「オープンソースハードウェア概念」の発端となったArduino（アルデュイーノ、もしくはアルドゥイーノ）。その制御系とArduinoシールドと呼ばれる被制御系ボード間の物理インタフェースがArduinoコネクタ（右下）です。
I2C（SCL/SDA）/ADEF（アナログ基準電位）/DIGITAL（PWM兼用）/ IOREF（IO基準電位）/RESET/POWER/ANALOG INのピン配置が決まっています。

Arduinoコネクタのおかげで、制御系とシールドに分離して開発でき、それぞれをArduinoコネクタで接続すれば、Arduinoボードシステムが完成します。

Wikipediaによると、2013年には制御系とシールド、公式非公式合わせて140万台ものArduinoボードが販売されていて、安価にプロトタイプシステム構築が可能となっています。

Arduinoコネクタを持つMCU評価ボードが多い理由その１：市販安価シールド資産が使える

既にこれだけの数のシールドが販売中ですので、MCU開発にそのまま流用や小変更で使えるシールドもあります。

Arduinoコネクタを持つMCU評価ボードが多い理由その１が、この既製品で安価なシールド資産が使えるからです。使用部品選定やアートワークパターンなども十分に練られた既製品が入手できるのです。しかもこれらは殆どの場合、オープンソースハードウェアなので詳細が開示済みです。

シールドは縦方向に段重ね（スタッカブル）できますので、複数段を重ね機能増加も可能です。

ハードウエア基板を0から動作するレベルにまでもっていくのは、時間もコストも掛かります。市販シールドを利用したプロトタイプ開発が可能なことが、MCU評価ボードにArduinoコネクタを持つ理由です。

Arduinoコネクタを持つMCU評価ボードが多い理由その２：MCU性能評価に使える

シールドを使ってハードウエアが用意されれば、後はソフトウェアです。

図のようにシールドは、複数ベンダーのMCU評価ボードに使えますし、同一ベンダー内の異なるMCUの性能評価にも使えます。

例えば、最も重要な処理に必要なシールドと、その制御ソフトウェアのみをプロトタイプ開発し、MCU性能が重要処理に十分か否かの評価を行います。この評価結果で、コストパフォーマンスに優れたMCU選択が可能となります。

場合によっては、ピンコンパチブル性を利用して他ベンダーのMCU選択も可能です。Cortex-M系MCUはどれも似通ってはいますが、例えば、サイプレスのPSoCシリーズはアナログブロントエンド機能内蔵など、各ベンダーでそれぞれ特徴があります。これらMCU特徴を活かした開発で競合他社との差別化もできます。

MCU評価ボードプロトタイプ開発スピードを上げるマイコンテンプレート

その１もその２もポイントは、プロトタイプ開発のスピードです。効率的に、しかも精度良くプロトタイプ構築し評価するには、MCU製品で使用頻度が高いLCD出力やアナログポテンショメータ入力、LED出力などの単機能シールドを複数使うよりも、これら機能実装済みの汎用Baseboardを使う方が、より低コストにプロトタイプハードウエアの構築ができます。

関連投稿：CY8CKIT-042とCY8CKIT-042-BLEへの機能追加、サンプルソフトが直に試せるマイコン開発環境の章

弊社マイコンテンプレートは、Baseboard動作に必要なソフトウェアをBaseboardテンプレートで提供済みです。開発要件に必要なシールドを見つけ、シールド単体でMCU性能評価を行い、さらにBaseboard実装機能を付加すれば、MCU製品完成形により近いプロトタイプシステムでの評価も可能です。

マイコンテンプレートは、MCU評価ボードプロトタイプ開発の「速さ」をより早めます。

MCU評価ボード、IDE、開発ツール、ベンダーが変わってもテンプレート本体は不変

テンプレート本体、具体的にはアプリケーションのLauncher機能は、MCU評価ボード、IDE、コード生成ツールなどの開発ツール、ベンダー各社には依存しません。つまり、単純なC言語でできています。

従いまして、開発ツールやIDEが時代により変化・更新しても、テンプレート本体は変わりません。ご購入頂いた弊社マイコンテンプレートの付属説明資料は、発売当時の環境をベースに解説しております。しかし、最新版のIDEやコード生成ツールに更新されても、このテンプレート本体は不変ですので、安心してお使いください。

まとめ

Arduinoコネクタを持つMCU評価ボードが多い理由は、市販安価シールド資産を活用し、MCU性能評価へも活用すれば、MCUプロトタイプ開発が効率的かつ容易になるからです。プロトタイプ開発スピードをさらに上げるためマイコンテンプレートが役立つことも示しました。

マイコンは種類が多く、どのベンダーの何を使って開発すれば良いかというご質問を時々頂きます。お好きなベンダーのArduinoコネクタを持つMCU評価ボードを使ってプロトタイプ開発することをお勧めしています。制御系ベンダー差は、Arduinoコネクタで消えます。先ずは着手、あえて言えば被制御系の開発着手が先決です。