ARMマイコン

IoV：Internet of VehiclesやV2X：Vehicles-to-Everything通信により、車載半導体チップとソフトウェア需要が指数関数的に増加、ユーザの自動車選択基準が、エンジンなどのメカから車載ソフトウェアへ移行しつつある、という記事がEE Timesに記載されました。

これらIoV状況が、IoTへ与える影響について考えてみました。

IoVとIoT

車のカタログから、エンジン特性や足回りのメカ説明が消え、スマホ連動性や運転支援など車載ソフトウェアによるサービスの説明に変ったのはここ数年です。記事によると、車の新しいユーザ選択基準になりつつあるカーエレクトロニクスが、半導体業界にとってはスマホ以来の最大チャンスだそうです。

また、「CASE」で車載半導体はどう変わるのか（2021年9月15日、EE Times Japan）でも、自動運転と電動化が今後の車載半導体動向を左右すると結論付けています。
※CASE：Connected（通信機能）、Autonomous（自動運転）、Shared＆Services（共有化/サービス化）、Electric（電動化）

年々向上するユーザのソフトウェア指向を満たす車載IoV業界、COVID-19の影響で停滞気味の民生IoT業界とは雲泥の差です。

車載半導体需要予測は初めの記事数値を参照して頂くとして、両記事のポイントは、ソフトウェア差別化や付加価値追加には、カスタムチップまたは、IP（Intellectual Property）などの組込みハードウェアが効果的という点です。これらIPには、セキュリティやエッジAIなどIoTへ流用できるものが数多くあります。

従って、IoVは、結果としてIoTも牽引すると思います。

但し、世界的半導体不足が続く状況では、優先度、調達コスト、多くの数量が確実に見込めるIoVが優勢、IoTはこの影響で、しばらくチップ供給不足や停滞が続くでしょう。

停滞気味のIoT側開発者として今できることは、IoV同様、IoTソフトウェア差別化に備えることだと思います。

IoT MCUのTrustZone、SOTB

IoTの観点から、IoTソフトウェア差別化や付加価値追加のための組込みIPと言えば、ARM TrustZone内蔵Cortex-M33コア、ルネサスの新製造プロセスSOTB：Silicon On Thin Buried Oxideなどが相当します。

例えば、TrustZoneが、高いセキュリティ効果を発揮するのはご存知の通りですし、SOTB製Cortex-M0+搭載ルネサスREファミリは、超低スタンバイ電流により太陽光発電環境などのエナジーハーベストでも電池交換不要を実現するなどです。

SOTBは、超低消費電力動作と高速動作を両立する革新的製造プロセスです。全てのルネサスMCUへ採用すれば強力な差別化技術になると思いますが、今のところ出し惜しみなのか（！？）戦略的なのか、REファミリにのみ採用中です。

一見、ASSP：Application Specific Standard Produceのようですが、これら差別化技術は、汎用MCUに採用された時に最も効果を発揮します。

従来のエッジMCUでの単純なアナログデジタル変換に加え、セキュリティや超低電力動作などのIoT化に伴う付加機能がIoT MCUには必須です。IoT付加機能内蔵MCUが、汎用IoT MCUになります。

IoT開発者は、これらIoT付加技術を今のうちに習得しておくことが必要です。

IoVとIoTの最も大きな差は、車載と民生半導体の電源仕様でしょう。IoVは、EV（Electric Vehicle）のモータ高出力要求に伴いバッテリーが12V供給から48Vへ高電圧化しつつあり、万一の耐圧やフェイルセーフが求められます。IoTは、低電圧（≦3.3V）電源で低圧化しつつあります。

RA/REテンプレート構想

残念ながらSOTB製REファミリ評価ボードは、まだ値段が高く、個人レベルでは手が出しにくい状況です。そこで、SOTBプロセスではありませんが、REファミリとソフトウェア互換性があると思われるCortex-M33コア搭載ルネサスRAファミリを、弊社テンプレート対象にと考えています。

RAファミリは、TrustZoneでIoTセキュリティへ対応しています。また、9月22日発売のRAファミリRA4E1グループの評価ボード：RA4E1 Fast Prototype Boardは、20米ドル台と低価格です。ルネサス独自コアではないため、コンパイラFlash容量制限もありません。

RL78/G1xテンプレートから新しいルネサスMCUをテンプレート対象に出来なかった理由の1つが、この容量制限です。ARMコア他社同様、GNUまたはARM Compiler V6が、e2 studioでRAファミリ開発に無償で使えます。

今のところRAテンプレートは、REへも使えると考えています。ARMコア差は、CMSIS：Cortex Microcontroller System Interface Standard やHAL：Hardware Abstraction Layerで吸収できるハズだからです。

ADC、SW、LED、UART（VCOM）などのIoT MCU基本動作をRA/REテンプレート共通部分でサポートし、TrustZoneや超低電力動作などRA/RE特徴を活かす部分は、共通部分へ特徴サンプルコードを追加する方法で実現できれば嬉しいと考えています。構想段階ですが、詳細は今後投稿します。

低価格（4000円以下）、個人での入手性も良い32ビットARM Cortex-M4コア評価ボードのRTOS状況を示します。超低価格で最近話題の32ビット独自Xtensa LX6ディアルコアESP32も加えました。

Vendor	NXP	STマイクロ	Cypress	Espressif Systems
RTOS	FreeRTOS Azure RTOS	CMSIS-RTOS	FreeRTOS Mbed OS	FreeRTOS
Eva. Board	LPCXpresso54114	NUCLEO-G474RE	CY8CPROTO-063-BLE	ESP32-DevKitC
Series	LPC54110	STM32G4	PSoC 6	ESP32
Core	Cortex-M4/150MHz	Cortex-M4/170MHz	Cortex-M4/150MHz Cortex-M0+/100MHz	Xtensa LX6/240MHz Xtensa LX6/240MHz
Flash	256KB	512KB	1024KB	480KB
RAM	192KB	96KB	288KB	520KB
弊社対応	テンプレート販売中	テンプレート開発中	テンプレート検討中	未着手

※8月31日、Cypress PSoC 6のRTOSへ、MbedOSを追加しました。

主流FreeRTOS

どのベンダも、FreeRTOSが使えます。NXPは、Azure接続用のAzure RTOSも選択できますが、現状はCortex-M33コアが対応します。ディアルコア採用CypressのRTOS動作はM4側で、M0+は、ベアメタル動作のBLE通信を担います。STマイクロのCMSIS-RTOSは、現状FreeRTOSをラップ関数で変換したもので実質は、FreeRTOSです（コチラの関連投稿3章を参照してください）。

同じくディアルコアのEspressifは、どちらもRTOS動作可能ですが、片方がメインアプリケーション、もう片方が通信処理を担当するのが標準的な使い方です。

価格が上がりますがルネサス独自32ビットコアRX65N Cloud Kitは、FreeRTOSとAzure RTOSの選択が可能です。但し、無償版コンパイラは容量制限があり、高価な有償版を使わなければ開発できないため、個人向けとは言えません。

※無償版でも容量分割と書込みエリア指定など無理やり開発するトリッキーな方法があるそうです。

クラウドサービスシェア1位のAWS（Amazon Web Services）接続用FreeRTOSが主流であること、通信関連は、ディアルコア化し分離処理する傾向があることが解ります。

ディアルコア

ディアルコアで通信関連を分離する方式は、接続クラウドや接続規格に応じて通信ライブラリやプロトコルを変えれば、メイン処理側へ影響を及ぼさないメリットがあります。

例えば、STマイクロのCortex-M4/M0+ディアルコアMCU：STM32WBは、通信処理を担うM0+コアにBLEやZigBee、OpenThreadのバイナリコードをSTが無償提供し、これらを入れ替えることでマルチプロトコルの無線通信に対応するMCUです。

メイン処理を担うM4コアは、ユーザインタフェースやセンサ対応の処理に加え、セキュティ機能、上位通信アプリケーション処理を行います。

通信処理は、クラウド接続用とセンサや末端デバイス接続用に大別できます。

STM32WBやCY8CPROTO-063-BLEが採用した末端接続用のBLE通信処理を担うディアルコアのCortex-M0+には、敢えてRTOSを使う必要は無く、むしろベアメタル動作の方が応答性や低消費電力性も良さそうです。

一方、クラウド接続用の通信処理は、暗号化処理などの高度なセキュティ実装や、アプリケーションの移植性・生産性を上げるため、Cortex-M4クラスのコア能力とRTOSが必要です。

デュアルコアPSoC 6のFreeRTOS LED点滅

デュアルコアPSoC 6対応FreeRTOSテンプレートは、現在検討中です。手始めに表中のCY8CPROTO-063-BLEのメイン処理Cortex-M4コアへ、FreeRTOSを使ってLED点滅を行います。

と言っても、少し高価なCY8CKIT-062-BLEを使ったFreeRTOS LED点滅プログラムは、コチラの動画で紹介済みですので、詳細は動画をご覧ください。本稿は、CY8CPROTO-063-BLEと動画の差分を示します。

CY8CPROTO-063-BLE のCortex-M4とM0+のmain_cm4.c、main_cm0p.cとFreeRTOSConfig.hが下図です。

日本語コメント追記部分が、オリジナル動画と異なる箇所です。

RED LEDは、P6[3]ポートへ割付けました。M0+が起動後、main_cm0p.cのL18でM4システムを起動していることが判ります。これらの変更を加えると、動画利用時のワーニングが消えCY8CPROTO-063-BLE でFreeRTOS LED点滅動作を確認できます。

PSoCの優れた点は、コンポーネント単位でプログラミングができることです（コチラの関連投稿：PSoCプログラミング要点章を参照してください）。

PSoC Creator起動時の上図が示すように、Cypressが想定したアプリケーション開発に必要なコンポーネントの集合体が、MCUデバイスと言い換えれば解り易いでしょう。つまり、評価ボードやMCUデバイスが異なっても、使用コンポーネントが同じなら、本稿のように殆ど同じ制御プログラムが使えます。

PSoC 6 FreeRTOSテンプレートも、単に設定はこうです…ではなく、様々な情報のCY8CPROTO-063-BLE利用時ポイントを中心に、開発・資料化したいと考えています。PSoCプログラミングの特徴やノウハウを説明することで、ご購入者様がテンプレートの応用範囲を広げることができるからです。

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テンプレートには、本稿で示したチャタリング対策済みの応用例を添付します。