FreeRTOSサンプルコード(4)

タスク数=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プロジェクトです。同期というより、むしろ排他制御にセマフォを使った例です。

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

2セマフォで1共有アイテム利用のランデブーモデル同期
2セマフォで1共有アイテム利用のランデブーモデル同期

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)

タスク数=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窓に文字を1回出力し、「待ち状態」になりました。
hello_task とよく似たTickless_taskは、文字の代わりにxTaskGetTickCountで得た数字を1回出力し、vTaskDelayで5秒間の「停止状態(=低電力動作:Sleep)」になります。

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

このプロジェクトは、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データシート)
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)

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)

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

NXPマイコン開発環境更新

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変化の背景

昨今のARM MCU事情、そして今後の方向性”という記事が、2019年11月22日TechFactoryに掲載されました。詳細は記事を参照して頂き、この中で本ブログ筆者が留意しておきたい箇所を抜粋します。その結果、ARM MCU変化の背景を理解できました。

現在のARM MCUモデル

Cortex-Mコアだけでなく、周辺回路も含めた組み合わせARM MCUモデルが、端的に整理されています。

・メインストリームは、Cortex-M4コアに周辺回路搭載
・ローパワーは、Cortex-M0+に低消費電力周辺回路搭載
・ローコストは、Cortex-M0に周辺回路を絞って搭載

例えば、STマイクロエレクトロニクスの最新STM32G0xシリーズのLPUART搭載は、ローパワーモデルに一致します。各Cortex-Mコアの特徴は、コチラの投稿の5章:Cortex-M0/M0+/M3の特徴などを参照してください。

ARM MCUの新しい方向性

2019年10月時点で記事筆者:大原雄介氏が感じた今後のARM MCU方向性が、下記4項目です。

  1. ハイエンドMCU動作周波数高速化、マルチコア化
  2. RTOS普及
  3. セキュリティ対応
  4. RISC-Vとの競合

以下、各項目で本ブログ筆者が留意しておきたい箇所を抜粋します。

1.ハイエンドMCU動作周波数高速化、マルチコア化

動作周波数高速化は、NXPのi.MX RT 1170のことで、Cortex-M7が1GHzで動作。i.MX RT1170は400 MHz動作のCortex-M4も搭載しているディアルコアMCU。

これらハイエンドMCUの狙いは、性能重視の車載MCU比べ、コスト最重視の産業機器向け高度GUIやHMI:Human Machine Interface用途。従来の簡単な操作パネルから、車載のような本格的なGUIを、現状の製造プロセスで提供するには、動作周波数の高速化やマルチコア化は必然。

2.RTOS普及

普通はベアメタル開発だが、アプリケーション要件でRTOS使用となり、ポーティング例は、Amazon FreeRTOSが多い。マルチコアMCUでは、タスク間同期や通信機能実現には、ベアメタルよりもRTOS利用の方が容易。また、クラウド接続は、RTOS利用が前提となっている。

3.セキュリティ対応

PAS:Platform Security Architectureというセキュリティ要件定義があり、これが実装済みかを認証するPSA Certifiedがある。PAS Certified取得にはTrustZoneを持つATM v8-MコアCortex-M23/33が必須ではなく、Cortex-M0やM4でも取得可能。但し、全MCUで取得するかは未定で、代表的なMCUのみになる可能性あり。

4.RISC-Vとの競合

ARM CMSISからずれるCustom Instruction容認の狙いは、競合するRISC-Vコアへの対抗措置。RISC-V採用製品は、中国では既に大量にあり、2021年あたりに日本でもARMかRISC-Vかの検討が発生するかも?

ARM MCU変化背景

本ブログ対象の産業機器向けMCUの1GHz動作や、ディアルコアMCUの狙いは、ADAS(先進運転支援システム)が引っ張る車載MCU+NVIDIA社などのグラフィックボードで実現しつつある派手なGUIを、10ドル以下のBOM:Bill Of Matrixで実現するのが目的のようです。また、産業機器向のMCUのAIへの対応も気になる点です。これにら向け、各種ツールなども各ベンダから提供されつつあります。

ハイエンドMCU開発でRTOS利用が一般的になれば、下位MCUへもRTOSが利用される場面は多くなると思います。タクス分離したRTOSソフトウェア開発は、タスク自体の開発はベアメタルに比べ簡単で、移植性や再利用性も高いからです。ベアメタル開発は、RAMが少ない低コストMCUのみになるかもしれません。

RTOS MCU開発も、Windowsアプリケーション開発のようにOS知識が(無く!?)少なくても可能になるかもしれません。

MCUベンダのセキュリティ対応は、まだ明確な方針が無さそうです。RTOSと同様、IoTアプリケーション要件がポイントになるでしょう。総務省による2020年4月以降IoT機器アップデート機能義務化予定などもその要件の1つになる可能性があります。

Custom Instructionは、コチラの投稿の5章でベンダ独自のカスタム命令追加の動きとして簡単に紹介しましたが、その理由は不明でした。これが、競合RISC-Vコアへの対抗策とは、記事で初めて知りました。

本ブログ記事範囲を超えた、広い視野でのMCU記事は貴重です。

来年開発予定のベアメタルCortex-M4テンプレートへ、RTOSの同期や通信機能を簡易実装できれば、より役立ち、かつRTOS普及へも対抗できるかもしれないと考えています。クラウド接続IoT MCUは、Amazon FreeRTOSやMbed OS実装かつ専用ライブラリ利用が前提なのは、ひしひしと感じています。

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

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

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

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

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

MCUプロトタイプ開発と製品化へのステップ、支援ツール
MCUプロトタイプ開発と製品化へのステップ、支援ツール

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

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

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

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

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

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

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

  1. ステップ05以降の製品開発へも、ステップ01で構築したプロトタイプ環境をそのまま使える
  2. 下位Cortex-M0/M0+/M3ソフトウェアに対して、Cortex-M4プロトタイプ開発資産が流用できる

Cortex-M4の高性能を、プロトタイプ開発マージン(後述)に使うとこれらの違いが生じます。

Cortex-M4コアMCUの特徴

ARM Cortex-M4は、Cortex-M0/M0+/M3とバイナリ互換です。

簡単に言うと、Cortex-Mコア開発元ARM社が推進するCMSISに則って開発したCortex-M4ソースコードやライブラリは、再コンパイルすればCortex-M0/M0+/M3へ流用・活用ができます。
※CMSIS:Cortex Microcontroller Software Interface Standard関連投稿は、コチラの2章などを参照してください。

Cortex-Mxのバイナリ互換性(出典:STM32L0(Cortex-M0+)トレーニング資料)
Cortex-Mxのバイナリ互換性(出典:STM32L0(Cortex-M0+)トレーニング資料)

図から、Cortex-M4バイナリの全ては、下位Cortex-M0/M0+/M3に含まれてはいません。従って、効率的な処理やセキュリティ対策必須の高速演算を行うには、Cortex-M4が最適なのは言うまでもありません。

Cortex-M4を使ったMCUは、Cortex-M0/M0+/M3 MCUに比べ動作クロックが高速で内蔵Flash/RAM容量も大きいため、ベアメタル利用だけでなく、RTOS利用も可能です。

Cortex-M4がプロトタイプ開発に最適な理由:大マージン

Cortex-M4のMCUでプロトタイプ開発すれば、製品化時に必要となる処理や保守点検処理などの実装も「余裕」を持ってできます。
※製品出荷テストプログラム、自動販売機待機中のLEDデモンストレーション点灯などが製品化処理具体例です。

筆者は、このような製品化処理を、おおよそプロトタイプ処理と同程度と見積もります。つまり、製品のFlash/RAM量は、プロトタイプ時の2倍必要になります。

仮に「余裕」がありすぎオーバースペックの場合には、開発したCortex-M4プロトタイプ処理(=開発ソフトウェア資産)を、そのまま下位Cortex-M0/M0+/M3コアMCUへ流用が可能です。

一方、処理が複雑で多い場合には、RTOSで解決できるか否かの評価もCortex-M4プロトタイプなら可能です。更にIoT製品では、セキュリティ関連の(先が見えない)処理や計算量増加にも対応しなければなりません。

安全側評価なら敢えて下位Cortex-Mコアを選ばずに、Cortex-M4をそのまま製品にも使えば、処理増加にも耐えらます。

つまり、プロトタイプ開発には、初めから容量や性能の足かせが無く、製品化移行時の開発リスクも少ない高速高性能・大容量のCortex-M4 MCUが最適なのです。

製品時の処理能力やFlash/RAM量を、Cortex-M4プロトタイプで見積もった後に、製品化にステップアップすれば、適正な製品制御Cortex-Mコアを選択できます。開発ソフトウェア資産の流用性、過負荷耐力、RTOS製品開発評価ができる高性能を兼ね備えたのが、Cortex-M4を使ったプロトタイプ開発です。

問題は、価格です。

各社のCortex-M4評価ボード価格は、Cortex-M0/M0+/M3評価ボードと大差ありません。STM32MCUの評価ボード:Nucleo32シリーズは、Cortex-Mコアが異なっても同額です。プロトタイプ開発マージンを考慮すると、たとえ評価ボードに多少の価格差があったとしても十分納得がいきます。

Cortex-M4デバイス単体価格は、Cortex-M0/M0+/M3よりは高価です。しかし、製品原価全体に占めるCortex-M4デバイス価格比は低いでしょう。IoT製品では、今後増大するセキュリティ対策や計算量増加などを考慮すると、Cortex-M4デバイスを使うメリットは大きいと思います。

Cortex-M4プロトタイプテンプレート開発指針(NXP、STM、Cypress、TI共通)

Cortex-M4の特徴を活かし、下位Cortex-M0/M0+/M3間での開発ソフトウェア資産流用を考慮したCortex-M4プロトタイプテンプレート開発指針です。

  1. Cortex-M0/M0+/M3/M4各コアに用いるテンプレート本体の共通化
  2. プロトタイプ開発ソフトウェア資産流用性を高めるCMSISソフトウェアでの開発
  3. 製品化時ベアメタルかRTOS利用かを評価のため、Cortex-M4最高速動作のプロトタイプ開発

現在CMSISへの対応は、各社足並みが揃っているとは言えません。もしも完全にCMSISへ対応した場合は、異なるベンダ間でも開発アプリケーション互換が実現するからです。ARMコア市場が「攻めに強く、守りに弱い」ゆえんです。そういう状況でも、各社ともCMSISへのソフトウェア対応を進行中です。
※Cortex-M33コアには、CMSISに反して、ベンダ独自のカスタム命令追加の動きも見られます。

本稿で示したCortex-M4プロトタイプテンプレートと異なり、弊社販売中のCortex-M0/M0+/M3テンプレートは、テンプレート利用コアで最適解を与えます。そのため、RTOS利用時や、製品化処理、セキュリティ対策などの処理が増えた時には、元々のコア処理性能や内蔵Flash/RAMに余裕が少ないため、適用デバイスでの製品化に対して、開発を続けにくい状況が発生することもありえます。

この点、Cortex-M4プロトタイプテンプレートなら、プロトタイプで構築した同じ開発環境で、RTOSも含めた製品開発へも余裕を持って対応できます。同時に、プロトタイプ開発資産の流用や活用により、Cortex-M0/M0+/M3ソフトウェア生産性も高めることができます(一石二鳥)。

ARM Cortex-M4テンプレートと開発資産流用性
ARM Cortex-M4テンプレートと開発資産流用性

弊社Cortex-M4プロトタイプテンプレートの発売時期、RTOSへの具体的対応方法などは、未定です。本ブログで各社毎の開発状況をお知らせする予定です。

あとがき:初心者や個人利用は、Cortex-M4テンプレートが最適

ソフトウェア開発初心者にCortex-M4プロトタイプテンプレート利用は、難しい(=階段を上るのが困難)と考える方がいるかもしれません。筆者は、全く逆、むしろ初心者、個人利用に最適だと思います。

理由は、Cortex-M0/M0+/M3/M4と上位になるほどコア設計が新しく、処理性能も上がるからです。初心者が、あまり上手くないコード記述をしても、コア性能が高いため問題なく処理できてしまいます。詳細は、ARM Communityの“An overview of the ARM Cortex-M processor family and comparison”などが参考になります。

ごく簡単に言うと、自動車エンジンが、Cortex-Mコアに相当すると考えてください。

小排気量なCortex-M0より、大排気量のCortex-M4の方が、楽に運転でき、しかも、運転に最低限必要なハンドルやアクセル、ブレーキ操作は全く同じです。車(=評価ボード)の価格が同じなら、殆どの方が、余裕のある大排気量のCortex-M4を選択するでしょう。

しかも、Cortex-M4評価ボード操作の技(=開発ソフトウェア資産)は、Cortex-M0/M0+/M3へも流用できます。経済的に厳しい個人利用のプロトタイプ開発環境としては、流用範囲の広いCortex-M4 MCUテンプレートが最適と言えます。

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

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

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

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

IoT MCUセキュリティ

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

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

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

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

サイバー攻撃対策

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

  1. ウイルス感染
  2. 通信傍受
  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機器アップデート機能義務化」が、具体的にどのようになるかは不明です。ただ、無線機器の技適規制などを考えると、技術ハードルは、かなりの高さになることが予想できます。

サイバー攻撃対策のIoT MCUセキュリティ
サイバー攻撃対策のIoT MCUセキュリティ

ディアルコアや超高性能汎用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機器を実現するアプローチです。

ARM Cortex-M4とM0+アプリケーションコード互換

NXP MCUXpresso SDK利用を利用すると、LPC845 Breakout board用に開発した1秒赤LED点滅アプリケーションコードが、そのままFRDM-KL25Zへ流用できることを前回投稿で示しました。ただ、どちらも同じARM Cortex-M0+コアのMCU評価ボードなので、読者インパクトは少なかったかもしれません。

そこで、LPC845 Breakout board(Cortex-M0+/30MHzコア)のLED点滅アプリケーションコードが、そのままCortex-M4/100MHzコアのLPCXpreosso54114へ流用できることを示します。異なるARMコア間でのアプリケーションコード互換の話です。

ARMコアバイナリ互換

Cortex-Mxのバイナリ互換性(出典:STM32L0(Cortex-M0+)トレーニング資料)
Cortex-Mxのバイナリ互換性(出典:STM32L0(Cortex-M0+)トレーニング資料)

ARMコアのバイナリ上位互換を示す図です(関連投稿:Cortex-M0/M0+/M3比較とコア選択の2章)。このバイナリコード包含関係は、Cortex-M0バイナリコードならCortex-M4でも動作することを示しています。

但し、この包含関係を理解していても、Cortex-M0バイナリコードをそのままCortex-M4へ流用する開発者はいないと思います。

ARMコアアプリケーションコード互換

Cortex-Mxのアプリケーションコード互換性
Cortex-Mxのアプリケーションコード互換性

MCUXpresso IDEのARMコアアプリケーションコード互換を示す図です。左がLPC845 Breakout board(Cortex-M0+/30MHzコア)の1秒赤LED点滅アプリケーションコード、右がCortex-M4/100MHzコアのLPCXpreosso54114の1秒赤LED点滅アプリケーションコードです。

コード差は、L59:LPCXpreosso54114評価ボード動作クロック設定:48MHz動作のみです。例えば、96MHzなどの他の動作周波数へ設定することも可能です。コード上で動作周波数を明示的に表示するために異なりましたが、機能的には両者同じコードと言えます(L59をマクロで書き換えれば、同一コード記述もできます)。

図下のInstalled SDK Versionが、どちらも2019-06-14で一致していることも重要です。Versionが異なると、例えばGPIOのAPIが異なることがあるからです。各SDKリリースノートでAPI差の有無確認ができます。※LPCXpreosso54114 SDKのMCUXpresso IDE設定方法は、コチラの投稿の5/6章を参考にしてください。

1秒赤LED点滅という簡単なアプリケーションですが、Cortex-M0+とCortex-M4の異なるARMコア間でコード互換性があることが解ります。

動作周波数の隠蔽とIO割付

評価ボード動作周波数が異なれば、無限ループ回転速度も異なります。従って、互換性を持たせるコード内に、無限ループ内の回転数でLED点滅させるような処理記述はできません。コードに時間要素は組込めないのです。

1秒点滅の場合は、L77:SysTick_DelayTicks()でループ回転数をカウントし、1秒遅延を処理しています。これにより、GPIO_PortToggle()が時間要素なしとなり、異なる動作周波数のARMコアでもアプリケーションコード移植性を実現しています。

SysTick_DelayTick()と1ms割込みによりカウントダウンする処理コードが下記です。ここも、割込みを利用することでコード移植性を実現しています。

動作周波数隠蔽によるARMコアアプリケーションコード移植性の実現
動作周波数隠蔽によるARMコアアプリケーションコード移植性の実現

左のLPC845 Breakout boardと、右のLPCXpreosso54114のコード差は、L16:赤LEDのIO割付のみです。評価ボード毎に異なるIO割付となるのは、やむを得ないでしょう。L12からL16のDefinition箇所を、別ファイル(例えばIODefine.hやUserDefine.h)として抽出すれば、同一コード記述も可能です。

ARMコアアプリケーションコード互換メリット

以上のように、ARMコアアプリケーションコード互換を目的にした記述や工夫も必要です。しかし、一旦互換コードを開発しておけば、開発資産として他のARMコア利用時にも使えます。その結果、開発速度/効率が高まります。

IoT MCUは、センサ入力やLED出力などのメイン処理以外にも、日々変化するセキュリティ処理への対応は、必須です。メイン処理が出来上がった後での、セキュリティ処理追加という手順です。

セキュリティ対策は、セキュリティライブラリ等の使用だけでなく、いつどのようにライブラリを活用するか、その時のMCU負荷がメイン処理へ及ぼす影響等、検討が必要な事柄が多くあります。

少しでも早くメイン処理を仕上げ、これら検討項目へ時間配分することがIoT MCU開発者には要求されます。この検討時間稼ぎのためにも、ARMコアアプリケーションコードの開発資産化は必須でしょう。

※プロトタイプ開発は、初めから厳しい条件で開発するよりも、最速のCortex-M4で行い、全体完成後Cortex-M0+/M3などへアプリケーションコードを移植するコストダウンアプローチも名案だと思います。

P.S.:2019年9月4日、MCUXpresso IDEがv11.0.1へ更新されました。旧MCUXpresso IDE v11.0.0 [2516]利用中の方は、Help>Check for Updatesではv11.0.1へ更新されません。新にMCUXpresso IDE v11.0.1 [2563]のインストールが必要です。新MCUXpresso IDEインストール方法は、コチラの4章を参照ください。