ARMマイコン

STM32MCUでRTOS開発を行う時の3注意点、前編のSTM32CubeMX、HALに続き、本稿後編でCMSIS-RTOS関連を示します。

※木曜からの東京オリンピック4連休のため、通常金曜を本日水曜日に先行して投稿します。

前編は、STM32RTOS開発実例として、NUCLEO-G474RE FreeRTOS_QueuesサンプルプロジェクトのSTM32CubeMX（以下CubeMX）コード出力を使い、HALタイムベース変更の必要性を示しました。後編は、前編と同じ実例を使ってCMSIS-RTOSの注意点を示します。

FreeRTOS_Queues STM32CubeMXファイルのTasks and Queues

NUCLEO-G474RE FreeRTOS_QueuesサンプルプロジェクトのCubeMX構成ファイル：FreeRTOS_Queues.icoを開き、Middleware>FREERTOSのTasks and Queuesタブをクリックしたのが下図です。

2つのタスク：MessageQueuePro（Ｑプロデューサ：送信タスク）とMessageQueueCon（Ｑコンシューマ：受信タスク）と、1つのQ：osQueue（深さ1：ワード）を、CubeMXで自動生成するパラメタが設定済みです。関連投稿：NXP版FreeRTOSのQueueデータ送受信と同じです。

全て黒文字パラメタですので、変更も可能ですが、このままソースコードを自動生成（Alt＋K）してください。

CMSIS-RTOS APIからFreeRTOS API変換（wrapper）

main.cのL125に、osQueueを生成するAPI：osMessageCreateが自動生成済みです。また、L134とL138に、MessageQueueProとMessageQueueConのタスク（Thread）を生成するAPI:osThreadCreateも自動生成済みなのが判ります。

ここで、API先頭にosが付くのは、CMSIS-RTOSのAPIだからです（L145のosKernelStartも同様）。詳細は、次章で説明します。

さて、L125のosMessageCreateへカーソル移動し、F3をクリックすると、cmsis-os.cのL1040へジャンプし、CMSIS-RTOS APIのosMessageCreateの中身が見えます。その中身が、L1055のxQueueCreateで、これはFreeRTOSのAPIです。

つまり、CubeMXが自動生成したのは、CMSIS-RTOS APIですが、その実体は、FreeRTOS APIであることが判ります。
この例のように、CubeMXが生成したCMSIS-RTOS APIは、cmsis_os.cで全てFreeRTOS APIへ変換されます。

CMSIS-RTOS

CMSIS-RTOSは、Cortex-Mコア開発元ARM社が定めたRTOS APIの規格です。
※CMSIS：Cortex Microcontroller Software Interface Standard

Cortex-Mコアには、FreeRTOS/Azure RTOS/mbed OSなど様々なRTOSが使えます。下層のRTOSが変わるとAPIも変わりますが、そのAPIを変換し、上層アプリケーションへ共通なRTOS APIを提供する、これにより、

1. RTOSが異なっても、同じ開発アプリケーションが使えること
2. Cortex-Mコアが異なっても、開発アプリケーション移植を容易にすること

これらがCMSIS-RTOSの目的です。

これをラップ（wrap＝…を包む）と呼ぶことがあります。ラップ関数（wrapper）とは、下層API差を隠蔽し、上層アプリケーションへ同一APIを提供する関数のことです。STM32RTOS開発でのCubeMXの役目の1つは、使用するRTOSに応じたwrapperを提供することです。

現在、STM32RTOS開発のCubeMXがラップしているのは、FreeRTOSだけです。今後、FreeRTOSがAzure RTOSなどへ変わっても、開発アプリケーションをそのまま活用するために、今の時点からCMSIS-RTOS APIを使っている訳です。

Cortex-M0/M0+/M3/M4/M7コア向けの共通RTOS APIがCMSIS V1、Cortex-A5/A7/A9と全Cortex-Mコア向けの共通RTOS APIがCMSIS V2です。STM32RTOS開発では、CMSIS V1を用います。

CMSIS-RTOS とFreeRTOSのAPI

UM1722にCMSIS-RTOS APIとFreeRTOS APIの一覧が示されています。抜粋したのが下表です。

接頭語にx/vなどが付くのがFreeRTOS API、osが付くのがCMSIS-RTOS APIです。

CubeMXが生成するコードは、常にCMSIS-RTOS APIですが、実体はFreeRTOS APIです。FreeRTOSが別のRTOSへ変わっても、CMSIS-RTOS APIは同じです。CMSIS-RTOS APIとFreeRTOS APIのwrapper分のオーバーヘッドは生じますが、下層RTOSに依存しない点は、先進的で優れています。

なおUM1722 Rev3には、単にAPI列記とwrapper、RTOSサンプルプロジェクトの簡単な説明が記載されているだけです。

まとめ

STM32MCUでRTOS開発を行う時の3注意点（前編：STM32CubeMX、HAL）に続き、本稿後編で3つ目のCMSIS-RTOSを示しました。

STM32RTOS開発のSTM32CubeMXが扱うRTOSは、現在FreeRTOSだけです。FreeRTOSが別のRTOSへ変わっても、CubeMXは、開発アプリケーション流用性を高めるためにFreeRTOS APIの代わりにRTOS共通CMSIS-RTOS APIを出力します。

CMSIS-RTOS APIには、Cortex-M0/M0+/M3/M4/M7コア間で開発アプリケーション移植性が高いCMSIS V1を使います。

CMSIS-RTOS API変換オーバーヘッドがありますが、流用性、移植性に優れたRTOSアプリケーション開発ができる点は、優れています。

あとがき

残念ながらCMSIS-RTOS情報は、シェア1位AWSのFreeRTOSに比べ少なく、この少ない情報を使ってSTM32RTOS開発を行うのは、大変です。
※2位がAzureのAzure RTOS、3位がGCP（Google Cloud Platform）のmbed OS。関連投稿はコチラ。

例えば、最初の図：CubeMXのTasks and QueuesのGUI設定パラメタが多いにもかかわらず、UM1722サンプルプロジェクト説明が少ない点などです。

RTOSは、複数タスク（CMSIS-RTOSではThread）間の優先順位差とRTOS自身の動作により、開発タスク処理状態が変わります。ベアメタル視点に加え、RTOS視点でのタスク開発と経験が求められます。QueueなどRTOS単独手段理解が目的のサンプルプロジェクトだけでは、RTOS開発経験は積めません。

弊社はこれらの対策として、効率的なRTOS基礎固め、STM32RTOSアプリケーションのプロトタイプ開発早期着手を目的としたSTM版RTOSアプリケーションテンプレート（仮名）を検討中です。その構想は、固まり次第、別稿にて示す予定です。

なお、NXP版FreeRTOSアプリケーションテンプレートは、コチラで販売中です。

経産省が2021年6月4日に発表した「半導体・デジタル産業戦略」について、専門家の評価は悲観的です。

我々IoT MCU開発者は、ホノルル便パイロットを見習い、対応策を持つべきだと思います。

経産省半導体・デジタル戦略の評価

今こそ日本の大手電機各社は半導体技術の重要性に気付くべき、EE Times Japan、2021年6月15日

日本の半導体戦略は“絵に描いた餅”、TechFactory、2021年6月16日

日本の半導体ブームは“偽物”、再生には学校教育の改革が必要だ、EE Times Japan、2021年6月22日

専門家が日本政府や経産省の方針を批判するのは、コロナ対策と同様、当然です。また下記、英）Financial Times評価を紹介した記事からも、専門家評価と同様、概ね懐疑的であることが判ります。

半導体製造業の日本の取組みに対する海外メディア評価、Gigazine、2021年7月6日

この戦略結果として生じる半導体・デジタル産業の市場変化の影響を直接受けるのは、我々IoT MCU開発者です。しかも、結果がでるまでの時間は、ますます短くなっています。この分野が、自動車や次世代通信などを含む「全ての産業の要」だからです。

経産省戦略資料は、コチラからダウンロードできます。概要・概略だけでも相当な量があり、対象がMCU技術者ならまだしも、マネジメントや一般技術者が、本当に要点を把握できるか、筆者でも疑問に感じます。

ホノルル便緊急事態対策

かつて護送船団方式ともいわれた日本産業の舵取りは、成功もありますが失敗も多いです。同調圧力に弱い日本人には、この方式が向いていたのかもしれません。

問題は、舵取りの結果生じる市場変化に、どう対応するかです。

対応策ヒントの1つになるのが下記記事です。

太平洋の真ん中でエンジン停止したらどうなるか、東洋経済、2021年6月27日

パイロットは、太平洋上での緊急事態対応のため、60分毎に東京/ミッドウェー/ホノルルの天候情報を集め、燃料残量や対地速度などの機体状況を確認し、180分以内に着陸できる空港を検討するのです。しかも、この緊急事態は、パイロットが入社し定年退職するまでに一度も経験することの無い0.024%の発生確率でもです。

この東京～ホノルル便エンジン停止などの緊急事態発生確率に比べると、半導体・デジタル産業の国による舵取り失敗確率は、高いと思います。

我々MCU開発者も、ホノルル便パイロット並みとはいかなくても、せめて開発が一段落付く毎に、最新IoT MCU状況を確認し対応を検討することは重要です。一段落が付いた時は、開発に使ったMCUの利点欠点を把握直後なので、他MCUとの比較も精度良くできるからです。

この検討結果をどのように反映するかは、開発者次第です。

お勧めは、もしもの時の「第2候補IoT MCU案：Plan Bを、開発者個人で持つこと」です。Plan Bは、たとえ同じARM Cortex-Ｍコア利用であっても、ベンダ毎に手間やAPIが異なるIoT MCU開発に、心理的余裕を与えます。Non ARMコア利用ならなおさらです。

個人でなら、同調圧力に関係なく、自分の開発経験や勘を使ってPlan Bを検討できます。

まとめ

2021年6月経産省が発表した半導体・デジタル産業戦略の専門家評価は、悲観的です。国の舵取りが失敗した例は、過去の電機や半導体企業の衰退が物語っています。巨額投資と市場シェアの両方が必要な半導体・デジタル分野は、既に弱体化した国内企業の巻返しにも期待はできません。

舵取り失敗確率は、現役ホノルル便パイロットが、太平洋上で緊急事態に出会う確率よりも高いでしょう。

最先端デバイスを利用するIoT MCU開発者の対応策の１つは、開発が一段落付く毎に、最新半導体・デジタル市場を確認し、もしもの時の第2 IoT MCU利用案：Plan Bを開発者個人で持つことです。

個人で安価にPlan Bを持つため、評価ボード動作確認済み各種マイコンテンプレートはお役に立てると思います。関連投稿：半導体不足とMCU開発案に、Plan B構成案もあります。

STマイクロエレクトロニクス）STM32MCUを使ってRTOS開発時のSTM32CubeMX、HAL、CMSIS RTOSの3注意点について示します。前編が、STM32CubeMXとHALについてです。CMSIS RTOSは、別途後編で示します。

STM32CubeMXとHAL の注意点を解説した後、サンプルプロジェクトで実例を示すという順番で説明します。

ソースコード生成ツール：STM32CubeMX

STマイクロのソースコード生成ツール：STM32CubeMX（以下CubeMX）は、MCU内蔵周辺回路の初期設定やAPIを、GUIベースで自動生成する非常に便利なツールです。

※MCUベンダのAPI生成ツールを比較した関連投稿は、コチラをご覧ください。

CubeMX生成APIは、ハードウェアを抽象化し、STM32MCU間で最大限の高いソフトウェア移植性を狙ったHAL （Hardware Abstraction Layer）と、よりハードウェアに近くHALよりも高速・軽量なエキスパート向けLL（Low-layer）の2種類から選択可能です。

一般的に、HAL APIが好まれます。というのは、このLL APIを利用し開発した2019年6月発売のSTM32G0xテンプレートV1の売上げはゼロでした。対策に、LL APIからHAL APIに変更し再開発した2020年6月発売のSTM32G0xテンプレートV2は、人気があるからです。

これらCubeMXの各種GUI設定や選択APIは、CubeMXファイル（.ico）に構成ファイルとして纏められます。

STM32MCU新規プロジェクト開発時に、この既成CubeMXファイル（.ico）を利用すると、ゼロから着手するのに比べ、効率的かつ間違いなく周辺回路や初期設定ができるため、利用価値の高いファイルです。

特に、ベアメタル比、さらに多くのCubeMX設定が必要となるRTOS開発では、既成CubeMXファイルを再利用するメリットがより高まります。同時に、生成コードの意味も理解しておく必要があります。

HALタイムベース

HALには、他ベンダにない便利なAPI：HAL_Delayがあります。

例えば、10msの待ち処理を行う場合、他ベンダなら、MCUコア速度に応じて適当にループ回数を調整したループ処理で10ms相当の遅延を自作します。しかし、HAL APIならば、HAL_Delay(10)の記述だけで、MCUコア速度に依存しない正確な10ms遅延が実現できます。

これは、HAL自身が、MCU内蔵タイマ：SysTickの利用を前提に設計されているからです。遅延処理を例に説明しましたが、STM32のHAL APIsは、SysTickと強く結びついています。

もちろん、HAL APIをベアメタル開発で利用する場合は、この結びつきに何ら問題はありません。

RTOSタイムベース

FreeRTOSも、タスク（スレッド）状態遷移タイムベースに、SysTickを使います。

これは、FreeRTOSだけでなく他のRTOSでも同じです。SysTickは、その名称が示すようにMCUシステムレベルのタイムベース専用タイマです。

従って、STM32MCUでRTOS開発を行い、かつHAL APIを利用する場合には、RTOS側でSysTickを使うのが、名称に基づいた本来の使い方です。

HALタイムベース変更

そこで、STM32RTOS開発でHAL利用の場合は、HALのタイムベースを、デフォルト使用のSysTickから別のタイマへ変更する必要が生じます。この変更に伴う手動設定も当然必要となります。

＊　　＊　　＊

ここまでが、STM32RTOS開発におけるSTM32CubeMXとHALに関する注意点です。
これらの注意点が解っていると、次章で示すRTOSサンプルプロジェクトのCubeMXファイルの意味と生成コードが理解できます。

STM32RTOS開発実例

STM32RTOS開発実例に、評価ボード：NUCLEO-G474RE（Cortex-M4/170MHz、Flash/512KB、RAM/96KB）でRTOS開発する場合を示します。

NUCLEO-G071RB（Cortex-M0+/64MHz、Flash/128KB、RAM/32KB）でRTOS開発する時でも同様です。しかも、RTOSサンプルプロジェクトは、STM32G071RBの方が（発売が古いためか？）多いので、NUCLEO-G071RBをお持ちの方は、是非ご自身で試してみてください。

FreeRTOS Example Selector

STM32CubeIDEのFile>STM32 Projectで、新規プロジェクト作成パネルを表示します（最新情報更新のため、表示に少し時間がかかる場合があります）。Example Selectorタブを選択、Middleware>FreeRTOSにチェックを入れ、NUCLEO-G474REのFreeRTOS_Queuesを選択したのが下図です。

右上欄、Noteの内容が、前半までに示した注意点のことです。参照先UM1722 Rev3は、CMSIS RTOSとFreeRTOSの関係があるのみです。このCMSIS RTOSについては、別途後編で説明します。

Nextをクリックし、FreeRTOS_Queuesサンプルプロジェクトを新規作成します。

さて、FreeRTOS Examples Listが318アイテム（STM32CubeIDE v1.6.1時）もあるので、Exportをクリックし、出力されたExcelファイルをBoardでフィルタリング、NUCLEO-G071RBとNUCLEO-G474REを抽出したのが下図です。

緑に色付けしたNUCLEO-G071RBの方が、FreeRTOSサンプルプロジェクト数が多いことが判ります。開発予定のSTM版FreeRTOSアプリケーションテンプレートは、Cortex-M4コアが対象ですので、本稿ではNUCLEO-G474REのFreeRTOS_Queuesを実例として使いました。

FreeRTOS_QueuesのSTM32CubeMXファイル

FreeRTOS_QueuesサンプルプロジェクトのCubeMX構成ファイル：FreeRTOS_Queues.icoが下図です。グレー文字は変更不可、黒文字は変更可能を示します。

TIM6がグレーなのは、HALタイムベース変更先がTIM6だからです。Kernel settings CPU CLOCK HZのSystemCoreClockがグレーなのは、RTOSタイムベースがSysTickだからです。つまり、本来の名称に基づいたSysTickがRTOS側で使われ、HALの新タイムベースにTIM6が割当済みであることが解ります。

FreeRTOS APIは、変更不可のグレーCMSIS V1です。ここは、後編で説明します。

デフォルトDisabledのUSE IDEL HOOKを、Enabledに変更し、ソースコード自動生成のGenerate Code（Alt+K）を実行してください。

HALタイムベースTIM6変更結果

app_freertos.cのL62に、Hook関数：vApplicationIdleHoolのひな型が自動生成済みです。ここへWFIを追記すれば、FreeRTOSアイドル時に低電力動作ができます。コチラのNXP版関連投稿Step5: FreeRTOS低電力動作追記と同じです。

main.cのL289は、TIM6満了時動作です。HAL_IncTick()が自動生成済みです。ベアメタル開発のSysTickからTIM6へHALタイムベースが変更されたことが解ります。

そのTIM6は、stm32g4xx_hal_timebase_tim.cで、1MHz＝1ms満了に初期設定済みです。

つまり、STM32RTOS開発でHAL利用時に必要となる変更が、「全てCubeMXで自動生成済み」なのが解ります。

※上図は、USE_TICK_HOOKもEnabledへ変更した例です。Disabledへ戻すなどして、CubeMX自動生成ファイルが変化することを確かめてください。

この実例のように、CubeMX付属RTOSサンプルプロジェクトのCubeMXファイル（*.ico）を再利用すれば、周辺回路や初期設定ミスを防ぎ、RTOS新規アプリケーション開発が容易になることが解ります。

まとめ

STM32MCUでRTOS開発を行う時の3注意点、STM32CubeMX、HAL、CMSIS RTOSのうち、前編としてSTM32CubeMX、HALの2注意点とサンプルプロジェクトを使ってその実例を示しました。

RTOS開発では、既成STM32CubeMXファイル再利用価値が高まること、HALタイムベース変更の必要性がご理解頂けたと思います。3つ目のCMSIS RTOS関連は後編で示します。

あとがき

ベアメタル開発経験者であっても、STM32RTOS開発時、CubeMXのNoteを読むだけで、ベアメタル開発では何の問題も無かったHAL タイムベース変更理由が解り、その結果生じるCubeMXファイルや自動生成ソースコードの中身が理解できる方は、少ないと思います。本稿は、この変更理由と生成コードに説明を加えました。

STM32CubeMXは、STM32MCU開発に必須で強力なAPI生成ツールです。が、時々、説明不足を感じます。問題は、どのレベル読者を相手にするかです。エキスパートなら説明不要ですが、初心者ならゼロから説明しても解らないかもしれません。文章による組込み技術説明が、難しいのが根本原因でしょう😂。

そんな組込み開発ですが、文章だけでなく、「実際に評価ボードと手足を使って慣れてくると、案外すんなり簡単に理解、習得できる方が多いのも組込み開発」です。

販売中のNXP版FreeRTOSアプリケーションテンプレートにも、本稿同様、詳しいFreeRTOS解説を付けています（一部ダウンロード可能）。FreeRTOS開発を手軽に試せ、習得を支援するツールです。

ARM Cortex-M4コア動作のFreeRTOSアプリケーションテンプレート第一弾、NXP）LPCXpresso54114対応版（税込2000円）を本日より発売します。概要、要点、FreeRTOSアプリケーションテンプレートとは、に関する説明資料は、コチラから無料ダウンロードできますのでご覧ください。

開発背景

IoT MCUのクラウド接続には、AWSならAmazon FreeRTOS、Microsoft AzureならAzure RTOSなどのRTOSが必要です。クラウド側からは、1つのRTOSライブラリを使って様々なMCUハードウェアを接続するための手段、これがRTOSです。

一方、IoT MCU側からは、接続先サービスに応じたRTOSライブラリ利用に加え、従来のベアメタル開発からRTOS上でのアプリケーション開発へ発展する必要もあります。IoT化に伴うこのような変化に対し、開発者個人が手間なく対応するためのツール、これが弊社FreeRTOSアプリケーションテンプレートです。

目的

FreeRTOSアプリケーションテンプレートの目的は、「RTOS基礎固め」と「FreeRTOSプロトタイプ開発のスタートプロジェクトとなること」の2点です。

RTOS開発は、ベアメタル開発とは異なります。

RTOS Kernelが、開発した処理（タスクやThread）と他タスクの優先順位により、処理実行/待機を決めます。開発タスク単体の流用性は高まりますが、タスク間同期や通信に、セマフォやQueueなどのRTOS独特の手段が必要です。

IoTにより全てのモノ（MCU）がクラウドへ接続する時代の基盤は、RTOSです。

ベアメタル開発経験者が、このRTOSの早期基礎固め、Kernelと自身で開発したタスクの並列処理を理解するには、個々にRTOS手段を説明するサンプルソフトよりも、具体的なRTOSアプリケーションの方が実践的で役立ちます。

RTOSアプリケーションがあれば、優先順位を変えた時のタスク動作変化や、その他経験に基づいたRTOS実務開発で知りたい事柄を手間なく試し、新たな知見・見識を得られるからです。これらは、サンプルソフトや、説明文から得ることは困難で、実際のRTOSアプリケーションで開発者自身が試行するのがベストです。

そこで、各FreeRTOS手段を説明した弊社MCU RTOS習得ページを理解した次の段階として、最初の図に示したプロトタイプ開発着手に必須となるADC/LCD/SW/LED/VCOM処理を、NXP）LPCXpresso54114（Cortex-M4/150MHz、Flash/256KB、RAM/192KB）とBaseboard、Arduinoプロトタイプシールドに実装し、動作確認済みRTOSプロジェクトが、FreeRTOSアプリケーションテンプレートです。

※上記プロジェクトは、クラウド接続は行っておりません。RTOS基礎固めとFreeRTOSプロトタイプ開発に適すことが目的ですので、クラウド接続RTOSライブラリは未実装です。

FreeRTOSを選んだのは、現在MCU RTOSシェア1位だからです（関連投稿はコチラ）。RTOS手段は、各RTOS共通技術であるSemaphoreとQueueの2つを用いております。LPCXpresso54114のFlashやRAM使用量にはまだ十分余裕がありますので、より高度なミューテックスやイベントグループなどの手段を適用するのも容易です。

特徴

本テンプレートには、上記FreeRTOSプロジェクトと同じ動作確認済みのベアメタル開発プロジェクトも添付しております。これは、ベアメタル開発に慣れた方が、FreeRTOSとベアメタルの差分をより明確に理解し、比較や評価をするためです（比較・評価は、ご購入者ご自身で行って頂きます）。

本テンプレート付属説明資料は、主にベアメタル開発者視点から見たFreeRTOSプロジェクトを解説しており、ベアメタルプロジェクトに関する説明は、ソースコードを読めばご理解頂けるとして省略しております。

従って、FreeRTOSアプリケーションテンプレートは、ベアメタル開発経験者を対象といたします。ベアメタル初心者の方は、先ずは各MCUベンダCortex-M0+/M3コア対応の従来マイコンテンプレートをご購入ください。従来テンプレート付属説明資料には、ベアメタル動作の詳しい説明が付いています。

※本テンプレートのベアメタルプロジェクトは、従来テンプレートCortex-M0+/M3コアをCortex-M4コア対応へ発展させたものです。ベアメタルプロトタイプ開発着手時に適すプロジェクトです。

FreeRTOSアプリケーションテンプレートは、ベアメタル開発経験者が、手間なく直にRTOSとベアメタルの差を理解・実感し、かつ、IoT基盤RTOSの効率的な基礎固めができるツールです。

なお、既に従来マイコンテンプレートご購入者様は、50％OFF特典があり、税込1000円にて本FreeRTOSアプリケーションテンプレートをご購入頂けます。弊社での確認ミスを防ぐため、ご購入時に従来テンプレート購入者様である旨、お知らせください。

勿論、従来テンプレートとFreeRTOSアプリケーションテンプレートの同時購入でも、この特典は適用されます。

まとめと今後

ベアメタル開発経験者が、IoT MCUクラウド接続に必要となるRTOSの効率的な基礎固め、FreeRTOSプロトタイプ開発着手プロジェクトとして使えることを目的に、NXP）LPCXpresso54114、Baseboard、Arduinoプロトタイプシールドを使ったFreeRTOSアプリケーションテンプレートを発売しました。

本テンプレートは、Amazon FreeRTOSのHardware Independent FreeRTOS Exampleを原本としています。第1弾はNXP）LPCXpresso54114へ適用しましたが、今後、STマイクロエレクトロニクス）STM32G4やCypress)PSoC 6など他社Cortex-M4コアの対応版も開発予定です。

STマイクロエレクトロニクス2021年2月25日発表の先端性能と超低消費電力動作両立のSTM32U5を紹介し、STのIoT MCU開発動向をセキュリティ、MCUコア、製造プロセスの観点から分析しました。

先端性能と超低消費電力動作のSTM32U5

公式ブログから抜粋したSTM32U5のベンチマークです。従来の超低消費電力MCU：STM32L0～L4+シリーズと、Cortex-M33コア搭載STM32L5、今回発表のSTM32U5をメモリサイズとパフォーマンスで比較しています。

STM32U5は、従来Cortex-M0+/M3/M4比、Cortex-M33搭載により後述のセキュリティ先端性能と、従来Cortex-M33搭載STM32L5比、230DMIPS/160MHzと大幅向上した超低消費電力動作の両立が判ります。STM32U5の詳細はリンク先を参照ください。

本稿はこの最新STM32U5情報を基に、STのIoT MCU開発動向を、セキュリティ、MCUコア、製造プロセスの3つの観点から分析します。

セキュリティ

昨年10月27日ウェビナー資料：ARM TrustZone対応マイコンによるIoTセキュリティのP17に示されたSTM32マイコンセキュリティ機能一覧です。セキュリティ先端性能のTrustZoneは、Cortex-M33コアに実装されています。

関連投稿：Cortex-M33とCortex-M0+/M4の差分

今回の超低消費電力STM32U5発表前なのでSTM32L5のみ掲載されていますが、STM32U5もL5と同じセキュリティ機能です。STM32WLは、後述するワイヤレス（LoRaWAN対応）機能強化MCUです。

この表から、後述する最新メインストリーム（汎用）STM32G0/G4も、STM32U5/L5と同じセキュリティ機能を実装済みで、STM32U5との差分はTrustZone、PKA、RSSなど一部であることも判ります。

STM32U5のSTM32L5比大幅に動作周波数向上と低消費電力化が進んだ背景は、セキュリティ機能に対するより高い処理能力と40nm製造プロセスにあることが2月25日発表内容から判ります。

STM32ファミリMCUコア

STM32ファミリMCUコアは、ハイパフォーマンス/メインストリーム（汎用）/超低消費電力/ワイヤレスの4つにカテゴライズされます。前章のSTM32WLがワイヤレス、STM32U5/L5は超低消費電力です（STM32U5は加筆）。

STM32WLとSTM32WBの詳細は、コチラの関連投稿をご覧ください。

STM32U5と同様、従来の120nmから70nmへ製造プロセスを微細化して性能向上した最新メインストリームが、STM32G0/G4です。

新しいSTM32G0/G4は、従来汎用STM32F0/F1/F3とソフトウェア互換性があり、設計年が新しいにも係わらずデバイス価格は同程度です。従来メインストリームのより高い処理能力と低電力動作の顧客ニーズが反映された結果が、最新メインストリームSTM32G0/G4と言えるでしょう。

製造プロセス

製造プロセスの微細化は、そのままの設計でも動作周波数向上と低電力消費、デバイス価格低減に大きく寄与します。そこで、微細化時には、急変するIoT顧客ニーズを満たす機能や性能を従来デバイスへ盛込んで新デバイスを再設計します。STM32U5やSTM32G0/G4がその例です。

MCU開発者は、従来デバイスで開発するよりも製造プロセスを微細化した最新デバイスで対応する方が、より簡単に顧客ニーズを満たせる訳です。

関連投稿：開発者向けMCU生産技術の現状

まとめ

セキュリティ、MCUコア、製造プロセスのそれぞれを進化させた最新のIoT MCUデバイスが、次々に発表されます。開発者には、使い慣れた従来デバイスに拘らず、顧客ニーズを反映した最新デバイスでの開発をお勧めします。

また、短時間で最新デバイスを活用し製品化する方法として、最新メインストリーム（汎用）デバイスSTM32G0/G4を使ったプロトタイプ開発もお勧めします。

前章までで示したように最新メインストリームSTM32G0/G4は、他カテゴリデバイスの機能・性能を広くカバーしています。メインストリームプロトタイプ開発資産は、そのまま最新の他カテゴリデバイスへも流用できます。

従って、他カテゴリデバイスの特徴部分（セキュリティ、超低消費電力動作やワイヤレス）のみに注力した差分開発ができ、結果として短期製品化ができる訳です。

ちなみに、プロトタイプ開発に適したSTM32G0テンプレートは、コチラで販売中、FreeRTOS対応のSTM32G4アプリケーションテンプレートは、6E目標に開発中です。

あとがき：文字伝達

ソフトウェア開発者ならソースコード、ハードウェア開発者なら回路図が、最も直接的・正確に技術内容を使える手段です。文字は、記述者の理解を変換して伝える間接的手段です。両者に違い（文字化ノイズ）が生じるのは、やむを得ないと思います。

“報ステのTSMCのニュースに頭の抱えてしまった”、“TSMCは日本で何をしようとしているのか“からも分かるように、マスメディアは文字や画像で情報を伝えます。受けての我々開発者は、これらノイズを含むと思われるマスメディア情報を、自分の頭で分析・処理し、理解する必要があります。

と言うわけで本稿も、筆者が文字化ノイズを付けて分析した例です……、という言い訳でした😅。

COVID-19パンデミックの2020年も残すところ2週間になりました。2020年の金曜ブログ投稿は本日が最後、次回は2021年1月8日（金）とし休暇に入ります。

※既存マイコンテンプレートは、年中無休、24時間販売中です、いつでもご購入お持ちしております。

2020マイコンテンプレート案件総括

1. 🔴：Cortex-M4コア利用のマイコンテンプレート開発（2020年内）
2. 🟡：FRDM-KL25ZとIoT汎用Baseboard利用のKinetis Lテンプレート発売（12月）
3. 🟢：IoT MCU向け汎用Baseboard開発（10月）
4. 🟢：STM32FxテンプレートV2発売（5月）
5. 🟢：STM32G0xテンプレートV2発売（5月）

1のCortex-M4テンプレート開発は、STM32G4のRoot of Trustと、NXP LPCXpresso54114のRTOSサンプル解説で、Cortex-M4テンプレート化には程遠い状況です（赤ステータス）。

2のKinetis Lテンプレート（FRDM-KL25Z、Cortex-M0+/48MHz、Flash:128KB、RAM:16KB）は、添付説明資料作成が未着手です（黄ステータス）。

3のArduinoプロトタイプシールド追加、IoT MCU汎用Baseboardは完成しました（緑ステータス）。

4と5のSTM32FxテンプレートとSTM32G0xテンプレート発売までは、ほぼ順調に進みました（緑ステータス）。

対策としてブログ休暇中に、2のKinetis Lテンプレート完成と、これに伴うHappyTechサイト変更を目標にします。
１のCortex-M4テンプレート開発は、2021年内へ持越します。

ブログ記事高度検索機能（1月8日までの期間限定）

休暇中、ブログ更新はありません。そこで、読者の気になった過去の記事検索が、より高度にできる下記Googleカスタム検索機能を、1月8日までの期間限定で追加します。

上記検索は、WordPressのオリジナル検索（右上のSearch…窓）よりも、記事キーワード検索が高度にできます。少しでもキーワードが閃きましたら、入力してご活用ください。

あとがき

激変の2020年、テンプレート関連以外にも予定どおりに進まなかった案件や、新に発生した問題・課題も多数あります。例年より少し長めの休暇中、これらにも対処したいと考えております。今年のような環境変化に対し、柔軟に対応できる心身へ変えたいです（ヨガが良いかも？ 3日坊主確実ですが…😅）。

本年も、弊社ブログ、HappyTechサイトをご覧いただき、ありがとうございました。
今後も、引き続きよろしくお願いいたします。よいお年をお迎えください。

5V耐圧GPIOピンが無い3.3V動作FRDM-KL25Zへ、5V LCDをCMOSデバイス直結で接続し、その動作確認ソフトウェアを開発中です（CMOSデバイス直結は、関連投稿：3.3V MCUと5Vデバイスインタフェースを参照してください）。

開発途中、FRDM-KL25Z搭載MCUのKinetis KL25ファミリに、GPIOの拡張とも言える興味深いFGPIO機能、BME機能を見つけたのでFRDM-KL25Z GPIOの使い方に加え解説します。両機能は、Kinetis KL25の高速化に効果があります。

※FGPIO：Fast GPIO、高速処理でGPIO記述ソースコードからの変更容易。
※BME：Bit Manipulation Engineはレジスタ読書きとビット操作が同時可能なMCU内蔵ハードウェア。コードサイズ削減と高速処理が同時に可能。

FRDM-KL25Z GPIOの使い方

FRDM-KL25ZのGPIO API一覧が下記です。MCUXpresso IDEのソースコード上でgpio_と入力し「Ctrl＋スペースキー」を押すと、GPIO_で始まるAPIが一覧表示されます。これが、Content Assist機能です。

先頭〇がGPIO_API関数、#がdefineで定義したマクロです。GPIO_API本体は、fsl_gpio.hで定義されています。

例えば、GPIO_ClearPinsOutputを選ぶと、残りの変数：GPIO_Type *baseとunit32_t maskを入力すればソースコード上でGPIO_ClearPinsOutput APIの入力完了です。

*baseは、GPIOAやGPIOBなどのポート名、maskは、制御対象ピン以外のマスクです。GPIOBの18番ピンが対象なら、GPIO_ClearPinsOutput(GPIOB, 1<<18)と記述します。

Content Assistの一覧表示リストを見ると、FRDM-KL25ZのGPIO APIに特に変わったAPIはありません。ごく一般的なGPIOの使い方であることが判ります。

GPIOに限らずContent Assistは、APIレファレンスマニュアルを参照するよりAPI選択と変数のソースコード入力が早く便利にできます。もちろん、ユーザが追加定義したマクロでも自動的にリスト表示されます。

FRDM-KL25Z FGPIOの使い方

KL25 Sub-Family Reference Manualの図3-9は、MCUからGPIO Controllerへの経路が、下記2種類あることを示しています。

GPIO：MCUからPeripheral Bridge経由のGPIO Controller制御
FGPIO：MCUからGPIO Controller直接制御（Single-cycle I/Oとも呼ばれる）

特筆すべきは、レジスタ構成がGPIOとFGPIOで全く同じなので、GPIOソースコード記述が、
GPIOB_PTOR = (1<<18);    //  GPIOでFRDM-KL25Zの赤LED：PTB18をトグル
の場合、これをFGPIOへ変える場合は、
FGPIOB_PTOR = (1<<18);  // FGPIOでFRDM-KL25Zの赤LED：PTB18をトグル
とGPIOをFGPIOへ変更すれば済むことです。

※GPIOB_PTOR = (1<<18)は、レジスタ明示記述、同じことをGPIO_APIで記述すれば、GPIO_TogglePinsOutput(GPIOB, 1<<18)となります。どちらもContent Assistが使えます。

但し、2サイクルアクセスGPIOの半分、FGPIOの1サイクルアクセス実効速度を得るには、コンパイラ最適化オプションを、デフォルト最適化なし：None(-O0)から、Optimize (-O1)、または、それ以上にする必要があります。

FRDM-KL25Z BMEの使い方

前章GPIO経路の途中にBMEハードウェアがあります。BMEを使うと、Peripheralsレジスタの読書きとビット操作を同時、つまり、ソースコード記述1個で可能になります。

BMEを使うソースコードは、下記5種類です。

書込み時
・Store Logical AND/OR/XOR (AND/OR/XOR)
・Store Bit Field Insert (BFI)

読込み時
・Load-and-Clear 1 bit (LAC1)
・Load-and-Set 1 bit (LAS1)
・Load Unsigned Bit Filed Extract (UBFX)

アセンブラ記述に似ています。詳細は、KL25 Sub-Family Reference Manualの17章BMEを参照してください。

BMEを使うと、ソースコード記述が減るので、処理時間とコードサイズの両方を軽減でき高速化可能です。

一般的なGPIOソースコードで記述した周辺回路の初期設定や無限ループ内処理をあらためて見直すと、BMEが使える箇所が見つかります。

GPIO、FGPIO、BMEの使い方

最初に1章で示した一般的なGPIO記述でソフトウェアを開発し、最後の高速化手段としてFGPIOやBMEを使うのが良いと思います。理由は、FGPIOは最適化、BMEはソースコード内にレジスタ読書きとビット操作の両方が必要な個所があることが前提だからです。

FGPIOはGPIO記述ソースコードからの変更が容易です。コンパイラデフォルトの最適化なし：None(-O0)でコード変更し、求める高速要件が満たされれば、利用価値は高いでしょう。この場合は、100%の1サイクルアクセス実効速度までは得られませんが、FGPIO高速化ができます。

経験上、最適化利用に筆者は消極的です。様々な副作用もあるからです。

最適化よりも超低消費電力/低コストが特徴のFRDM-KL25Z（Cortex-M0+/48MHz）開発ソフトウェアの再利用が可能で、より高速なFRDM-K64F（Cortex-M4/120MHz）などへMCU変更が可能なら、この方法をお勧めします。

但し、MCU変更ができない時の効果的な高速化手段として、本稿説明のFGPIOとBMEを知っておくことは重要です。

FGPIOやBMEは、低価格で入手性も良いFRDM-KL25Zに初めから実装済みです。Kinetis KL25ファミリMCUの汎用性と高い拡張性を示す良い例だと思います。

旧Freescaleから2013年頃発売と少し古い感もあるMCUですが、十分現役で使えます。

あとがき：3.3V MCUと5V CMOSデバイス直結動作確認完了

STM32G0xテンプレートに使用した3.3V動作MCU：STM32G071RBも5V耐圧GPIOピンは持ちません。しかし、CMOSデバイス直結で5V LCDを駆動し、安定動作を確認しました。

訂正：STM32G071RBには、5V耐圧ピンがあります。お詫びして訂正いたします。

ソフトウェア開発中の3.3V動作FRDM-KL25Zと5V LCDのCMOSデバイス直結も、同様に問題なく動作するハズです。

FRDM-KL25Z評価ボードのタッチスライダ（Capacitive Touch Slider）の使い方を説明します。

タッチスライダ

CypressのPSoC 4000S/4100S/4100PSテンプレートでも使用中の指によるタッチユーザインタフェースは、MCU入力手段として人気があります。

NXPの多くのFRDM評価ボードにもFigure2のようにCapacitive Touch Sliderが実装済みですが、これをタッチスライダとして動作させるには、MCU内蔵TSIハードウェアと、これを制御するTSIライブラリの両方が必須です。
※TSI：Touch Sensor Input。

例えば、FRDM-KE02Z40Mでは、TSIハードウェアがMCU非内蔵なためタッチスライダは動作しません。

MCUXpresso SDKのTSI：Touch Sensor Inputサンプルプロジェクト

MCUXpresso SDKのTSIサンプルプロジェクトは、driver_examples>tsi_v4>normalにあります。MCUXpresso SDKの使い方は、関連投稿を参照してください。

以降は、サンプルプロジェクトのソースコードを横目で見ながら本稿を読んで頂くと良く分かると思います。が、ソースコードが無い場合には、まとめ章へスキップしてください。

tsi_v4_normal.cを見ると、このサンプルプロジェクトは、MCU内蔵TSIハードウェアをキャリブレーション（L127）後、下記3つの方法でTSIを制御しているサンプルであることが解ります。
※キャリブレーションとは、測定系ハードウェアの測定精度を上げる処理で、ADCなどでも必要です。

1. （L136）SOFTWARE TRIIGER SACN USING POLLING METHOD
2. （L159）SOFTWARE TRIIGER SACN USING INTERRUPT METHOD
3. （L178）HARDWARE TRIIGER SACN

1や2でもTSIソフトウェアライブラリ単独制御ではなく、TSIハードウェア/ライブラリ両方が必須であることに注意してください。3も同様です。

サンプルプロジェクトでは、1～3の方法を順に処理し、各方法の最後にPRINTFで取得値xxxxをConsoleへ出力します。その出力例がreadme.txtにあります。

3番目のハードウェア割込み方法設定後、無限ループへ入ります。

このサンプルプロジェクトソースコードは、本来は3サンプルプロジェクトに分離すべきものを、１つにまとめた書き方をしています。つまり、TSIソフトウェアポーリングプロジェクト、TSIソフトウェア割込みプロジェクト、TSIハードウェア割込みプロジェクトを１つにまとめています（ので、少々解りにくいかもしれません）。

TSIソフトウェアポーリングプロジェクト

そこで、TSIソフトウェアポーリングプロジェクトのみを抽出します。

先ずは、ソフトウェアポーリング処理後、他の2方法を飛ばして無限ループへジャンプさせます。例えば、L157のTSI_ClearStatusFlags()の後にgoto LOOP;を追加し、無限ループの前に飛び先ラベルLOOP:を加えます。すると、ポーリング方法のみの処理結果がConsoleへ正常出力されます。

つまり、ソフトウェアポーリングのみで、1回TSI制御ができることが確認できました。

組込み処理は、初期設定と無限ループ内の繰返し処理の2つに分けて考えるのが常套手段です。そこで、ソフトウェアポーリングの方法も、初期設定と繰返し処理の２つへ分けます。

L101～L143がソフトウェアポーリングの初期設定、L143～L157が繰返し処理です（※L143がダブっているのは間違いではありません）。この繰返し処理先頭L143に無限ループに付加したラベルLOOP:を移動し、無限ループ化します（無限ループに加えたラベルは削除してください）。

動作させ、TSIソフトウェアポーリングプロジェクトのみの抽出と連続ポーリング処理が完成です。

他の2方法、TSIソフトウェア割込みプロジェクトや、TSIハードウェア割込みプロジェクトのみを抽出する場合も同様です。3プロジェクトに分離すると、各方法の理解がより深まります。

※FRDM-KL25Zは、TSI channel 9と10の両方を使っています。両チャネルを使うメリットは、2つあります。1つは、その取得値変化から、指がスライダの左右どちらへ移動したかが解ることです。抽出プロジェクトで、その取得値変化の様子を実際に試してください。

※もう1つのメリットは、タッチ感度が上がることです。上図のように、各チャネルカバー範囲は相補的ですので、片チャネルでタッチ検出するよりも両チャネル検出の方が、より高感度になります。

FRDM-KL25Z タッチスライダの使い方

前章までで、FRDM-KL25ZタッチスライダのSDKサンプルプロジェクト3制御方法を解説しました。

本章は、もっと実用的なタッチスライダの使い方を説明します。

前章のTSIソフトウェアポーリング方法で、TSIチャネル9のみを使い、タッチスライダを物理スイッチの代わりに動作させる使い方です。

この動作は、オリジナルサンプルプロジェクトのTSIハードウェア割込み方法で、タッチスライダを指で触るとLEDがトグル点滅、つまり、スライダではなくタッチパッドとして動作するのと同様です。物理スイッチではないので、経年変化が少ないことが特徴です。

FRDM-KL25Z の性能を100%使ったTSIサンプルプロジェクトでは、タッチスライダ動作も十分可能です。

しかし、FRDM-KL25ZでTSI処理以外にも様々な処理を行う場合は、このタッチパッド的使い方が実用的だと筆者は思います。オリジナルサンプルプロジェクトも、この事を暗に示しているのかもしれません。

FRDM-KL25Z タッチスライダの初期設定

初期設定は、抽出したTSIソフトウェアポーリングプロジェクトの初期設定からチャネル10設定分を削除します。

FRDM-KL25Z タッチスライダの無限ループ内処理

抽出プロジェクトは、無限ループ内でチャネル9と10を「連続計測」しConsole出力しました。実用的な処理では、タッチスライダ処理以外の様々な他の処理を1個のMCUで行うため、この計測処理は（他の様々な処理が間に挟まるため）「離散的」になります。

離散計測処理を行う際の注意点は、チャタリング対策です。

指によるタッチであっても、本当にタッチしたのか、または、たまたま触っただけなのかをソフトウェア側で判断する必要があり、これをチャタリング対策（＝入力ノイズ対策）と言います。

例えば、複数回の離散タッチ検出ならば本当のタッチ、1回のみのタッチ検出ならば、触っただけのノイズでタッチと判断しない等です。

まとめ

FRDM-KL25Z評価ボード付属タッチスライダ制御を、MCUXpresso SDK TSIサンプルプロジェクトのソフトウェアポーリング、ソフトウェア割込み、ハードウェア割込みの3方法から解説し、タッチスライダを物理スイッチの代わりに動作させるタッチパッド的な使い方を説明しました。

3方法をまとめたオリジナルサンプルプロジェクトを、方法別に分離プロジェクト化し、初期設定と無限ループ内処理の2つに分け、ループ内処理のソフトウェアチャタリング対策を説明しました。

開発中のKinetis Lテンプレートには、本稿で示したチャタリング対策済みの応用例を添付します。

FRDM-KL25ZのUARTとPC を、USB経由のVCOM：Virtual COM port接続する方法を説明します。

VCOM：Virtual COM port

MCU評価ボードとPC間は、USBで接続されており、このUSB経由でターゲットMCUのプログラミングやデバッグを行います。前稿説明のJ-TAGハードウェアデバッガの代わりが、評価ボード付属デバッガで、FRDM-KL25Zの場合は、OpenSDAと呼びます。

本ブログ掲載の評価ボード付属デバッガが下表です。ベンダ毎に付属デバッガの呼び名は異なりますが、どれも機能的には同じです（Renesasは、別途E2 Lite/E2ハードウェアデバッガで機能提供します）。

ベンダ毎に呼び名が異なる評価ボード付属デバッガ

ベンダ	評価ボード付属デバッガ	評価ボード例	MCU – PC間通信
NXP	OpenSDA/CMSIS-DAP	FRDM-KL25Z/LPCXpresso54114	UART
STM	ST-Link	STM32G071RB	UART
Cypress	KitProg	CY8CKIT-145	UARTとI2C
TI	XDS110-ET	MSP-EXP432P401R LaunchPad	UART
Renesas	なし（E2 Lite/E2必須）	BlueBoard-RL78G13-64	UART

評価ボード付属デバッガには、ターゲットMCUのプログラミング/デバッグ機能に加え、MCUのUARTとPCのUSB間を橋渡し（＝接続）する機能があります。これをVCOM：Virtual COM port接続といい、Tera Termなどのシリアル通信ソフトウェアをPCにインストールすれば、いとも簡単にMCUの UART通信ソフトウェア送受信の動作確認ができます。

※Tera Termの代わりにMCUXpresso IDEプリインストールのSerial Terminalも使えます。

UART：Universal Asynchronous Receiver/Transmitter

UARTは、最重要MCU周辺回路です。

古くから装置組込み済みMCUの再プログラミング手段としてUARTは利用されてきました。最新IoT MCUでも、セキュア・ブート、セキュア・ファームウェア更新に使える手段はUARTのみです（関連投稿：STM32G0/G4のRoot of Trustなどを参照してください）。

さらに、MCUXpresso SDKの評価ボード新規プロジェクト作成時でも、最初からActiveな周辺回路はUART0だけです（※UARTの“0”に注意してください）。ボード実装済みのLEDさえ初期値はInactiveです。つまり、UARTを動作させないMCUは無いと言えるでしょう。

UARTソフトウェアの動作確認には、送・受信機能を持つため通信相手が必要で、VCOM接続によりPCが通信相手になるため、最重要周辺回路：UARTソフトウェアの動作確認ができる訳です。

FRDM-KL25ZのVCOM接続方法

前置きが長くなりました。本章から評価ボード：FRDM-KL25Z をOpenSDA経由でVCOM接続する方法を説明します。

結論から言うと、FRDM-KL25ZのVCOM接続には評価ボードに2配線追加が必要です。2配線を追加しTera Termを使ったUART送受信中の画面が写真1です。

• J1-2とJ2-20配線・・・・・・・UART0_TX：PTA1とUART1_TX：PTE0接続
• J1-1とJ2-18配線・・・・・・・UART0_RX：PTA2とUART1_RX：PTE1接続

FRDM-KL25Z関連資料は不親切で、この必須配線が分かりにくいので順を追って説明します。が、配線さえ追加すれば、全てのSDK UARTサンプルプロジェクトが正常動作しますので、急ぐ方は、まとめ章へスキップしてください。

MCUXpresso SDK UARTサンプルプロジェクトと回路図

FRDM-KL25ZのMCUXpresso SDK UARTサンプルプロジェクトは、どれもUART0ではなくUART1を使った処理例です。readme.txtには、“USB to Com Converter：USB2COM”をJ2-20/18と配線せよと記載されています。もちろん、別途USB to Com Converterを用意し、このとおり接続すればサンプル動作確認ができるでしょう。

しかし、OpenSDAにUSB to Com Converter と同じVCOM機能が備わっているのにこれを使わない手はありません。

そこで、FRDM-KL25Z回路図Rev.EのSheet 3を見ると、OpenSDAとMCUはUART0で接続済みで、R5とR6でUART1とも並列接続済みなのが判ります。本来ならUSB to Com Converterが無くてもそのままUART1サンプルプロジェクトが動作するハズです。

試しに、サンプルプロジェクトのUART1をUART0へ変更すると、コンパイル時に妙なワーニングが発生しますが、VCOM接続でUART0が動作します（UART0からUART1への変更にはMCUXpresso Config Toolsの使い方を参照してください）。つまり、UART0とOpenSDAは、回路図どおり接続済みな訳です。

R5とR6は実装されていますが、この代わり追加したのが2配線です。

その結果、UART1で全てのサンプルプロジェクトが正常動作します。また、UART0で発生した妙なワーニングもありません。

つまり、SDK付属UART1サンプルプロジェクトの正常動作には、J1-2とJ2-20、J1-1とJ2-18の2配線が必要です。この時UART0は、並列接続を避けるためInactiveにします。

※サンプルプロジェクトは、元々UART0がInactiveです。新規プロジェクト作成の時は、デフォルトActiveなUART0をInactive、UART1をActiveへ変更すると、サンプルプロジェクトがそのまま流用できます。

※評価ボード回路図最新版がRev.Eです。FRDM-KL25Z評価ボード裏側にシールが貼ってあり、回路図版数Rev.Eと一致、R5とR6も実装済みですが正常動作には追加配線が必要でした。回路図と実評価ボードの版数には、留意してください。

まとめ、新開発汎用Kinetis Lテンプレート

UARTとVCOM接続の重要性を示し、FRDM-KL25Z評価ボードで、VCOM接続を使ってMCUXpresso SDK UART1サンプルプロジェクトを正常動作させるには、評価ボードへ2配線を追加する使い方、各種注意点を説明しました。

このFRDM-KL25Z（Cortex-M0+/48MHz、General Purpose = Main Stream）を使って開発中の汎用Kinetis Lテンプレートは、新規プロジェクト作成時のデフォルトActiveなUART0をUART1へ変更済みで、本稿で示したような開発つまずきを回避する各種情報なども添付します。

写真1は、最も簡単なテンプレート応用例のVCOM動作で、評価ボードの赤/緑/青LEDやタッチスライダ、低消費電力動作のKinetis Lソフトウェアを簡単に開発できるテンプレートです。

3.3V動作新Baseboard

Cortex-M0+のKinetis Lは1.71Ｖから3.6 V動作で、従来弊社が扱ってきた5V Baseboard接続への5V耐圧端子が残念ながらありません。100MHzクラスで3.3V動作のCortex-M4テンプレート開発なども考慮すると、3.3V/1.8V動作用の新しいBaseboardを探し、テンプレート応用例に適用させたいと考えております。

Kinetis E（Cortex-M0+/40MHz、5V Robust）テンプレートv2開発障害となっている評価ボード：FRDM-KE02Z40MのOpenSDAとMCUXpresso IDEデバッガ間の接続問題は、残念ながら未解決です。今回は、このOpenSDA問題を簡単に整理します。また、Linuxによる第2のMCU開発環境構築の新設カテゴリも示します。

Kinetis OpenSDA

Figure 1は、MCUXpresso IDEとKineties MCU間のブロック図です。旧Freescaleは、Kinetis Design Studio：KDSというFreescale製IDEとKinetis MCU評価マイコンボード間の接続は、OpenSDAというインタフェースで接続していました。

このOpenSDAは、KDS直接接続だけでなく、PC（Windows 7）との接続時、File System（USBメモリ）として動作し、クラウド開発環境：mbed開発にも利用できる2種類のプログラミング機能を持ちます。

現在問題発生中のFRDM-KE02Z40MのOpenSDAも、Windows 7当時は問題なく動作していました。その結果、Kinetis Eテンプレートv1発売ができました。

MCUXpresso IDE接続問題（Windows 10）

Freescaleを買収したNXPは、自社LPCと新旧Freescale Kinetis両マイコンに新しい統合開発環境：MCUXpresso IDEを用意しました。このMCUXpresso IDEの評価ボード接続インタフェース一覧（一部抜粋）が下図です。

簡単に説明すると、MCUXpresso IDEは、NXP純正評価ボードEVKやLPCXpresso54xxx接続インタフェース：CMSIS-DAPと、新旧FRDM評価ボード接続インタフェース：OpenSDA v1系/v2系とmbedの3種類全てをサポートします。

接続問題が発生するのは、OpenSDAの一部です（表内にFRDM-KE02Z40Mが無いのは不安ですが、記載漏れだと思います）。FRDM-KL25Z（Cortex-M0+/48MHz、General Purpose）のOpenSDAは、MCUXpresso IDEと問題なく接続できています。

接続問題解決には、Figure 1のMSB Bootloaderを、MCUXpresso IDE対応済みの最新版へUpdateすることが必要です。

MSB Bootloader更新注意点（Windows 10）

MSB Bootloader更新方法は、評価ボードのリセットボタンを押しながらPC（Windows 10）とUSB接続し、エクスプローラーに現れるBootloaderフォルダへ、最新版：BOOTUPDATEAPP_Pemicro_v118.SDAをドラッグ＆ドロップするだけです（FRDM-KE02Z40Mの最新Bootloaderは、コチラから取得できます）。

この操作後、再度評価ボードとPCを接続すると、今度はエクスプローラーに通常モードのFRDM-KE02Z40Mフォルダが現れ、更新完了となるハズです。ところが、筆者の評価ボードは、Bootloaderモードから通常モードへ復帰しません。

従って、MCUXpresso IDEとFRDM-KE02Z40MをUSB接続しても、IDEは評価ボード無しに認識します。

簡単に説明しましたが、実際はWindows 10でのBootloader 更新時、「Windows 7では不要であったストレージサービスの一時停止が必須」です（詳細は、コチラのNXP情報のStep 2を参照してください）。

調べると、Windows 8以降に一般的なユーザには知らせずに追加したWindows PCのUSBメモリへの隠しフォルダ書込み機能（これが上記一時停止するストレージサービス）が、諸悪の根源のようです。

FRDM評価ボードOpenSDA接続問題整理と対策（Windows 10）

以上を整理し、対策をまとめます。

・旧Freescale製FRDM評価ボードが、新しいNXP MCUXpresso IDEと接続できない原因は、評価ボードOpenSDAのMSB Bootloaderにあり、対策は、MCUXpresso IDE対応版Bootloaderへの更新を、Windows 10ストレージサービスを停止させた状態で行うことが必要。

旧Freescale製（つまりWindow 7対応）のまま入手したFRDM評価ボードは、FRDM-KE02Z40M以外でもIDE接続問題が発生することがありますので、上記まとめを参考に対策してください。

このまとめと対策にたどり着く前に、Windows 10でストレージサービスを停止せずにFRDM-KE02Z40MのOpenSDA MSB Bootloader更新を何度か繰返しました。評価ボードが、Bootloaderモードから通常モードへ復帰しない理由は、これかもしれません😥。

筆者は、Windows 7時代からFRDM評価ボードを活用してきました。まさか、Bootloaderモード時にWindows 10ではサービス一時停止が必須だとは思いもしませんでした。しかも、このサービスは隠しフォルダ対応なので、通常ではWindows 7と同様にBootloader更新が正常終了したように見えます。

事前に調査しなかった筆者が悪いのですが、旧Freescale評価ボード記載Windows 7対応マニュアル通りに対処すれば、筆者と同じトラブルに出会う人は多いハズです。

また、OpenSDAユーザズガイドにも上記トラブルからの復帰方法の記載はありません。ネット検索か、NXP communityが解決手段でしょう😥。解決方法が見つかれば、本ブログでお知らせします。

エンドユーザを無視したかのようなWindows 10の度重なる変更に起因するトラブルは、今後も増える可能性があると思います。次章は、その対策です。

Windows MCU開発者向けLinuxカテゴリ新設

筆者は、昨年からLinux MintでのMCUXpresso IDE開発環境もWindows 10のバックアップ用に構築しています。このLinux環境でも、残念ながら今回のトラブル回復はできていません。

今回はLinux/Windows両方NGでしたが、Windows以外の第2のMCU開発環境があると、何かと便利です。

そこで、本ブログで、Windows MCU開発に慣れた開発者が、簡単にLinuxを使うための情報も発信したいと思います。このための新設カテゴリが、PC：パソコン＞Linuxです。
※親カテゴリPC：パソコンへ、LibreOfficeとWindowsも移設しました。

Windows 10、Linuxともに単なるPC OSです。Linux上でMCU開発アプリケーション、本ブログではNXP MCUXpresso IDEやSTM STM32CubeIDEを利用するために、最低限必要な情報に絞って説明する予定です。

Linux情報量もまたWindows同様多いのですが、Windowsに慣れたMCU開発者としては、当面不要な情報も多く、Windowsの代わりにLinuxを短期間で効率的に活用するMCU開発環境構築が目標・目的です。今回のようなWindows PCでのトラブル発生時、Linux PCへ移ってMCU開発を停止することなく継続するのが狙いです。

Linuxのシステム動作要件は下記で、Windows 10よりも低いので、古いPCでも快適に動作します。ただし新しいOS利用なら「64ビットCPUは必須」ですが…😅。32ビットPC OSの新規開発は、終了しました。

• 1GB RAM (2GB recommended for a comfortable usage)
• 15GB of disk space (20GB recommended)
• 1024×768 resolution

COVID-19の影響で、市場に中古PCが安価で数多く出回っていますので、これら活用も一案かと思います。