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

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

タッチスライダ動作にはMCU内蔵TSIが必須(出展:Fig1データシート、Fig2ユーザズマニュアル)
タッチスライダ動作にはMCU内蔵TSIが必須(出展:Fig1データシート、Fig2ユーザズマニュアル)

タッチスライダ

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の使い方は、関連投稿を参照してください。

MCUXpresso SDKのTSIサンプルプロジェクト
MCUXpresso SDKのTSIサンプルプロジェクト

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

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にあります。

MCUXpresso SDKのTSIサンプルプロジェクト3方法の動作出力例
MCUXpresso SDKのTSIサンプルプロジェクト3方法の動作出力例

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

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

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

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

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

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

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

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

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

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

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

TSIタッチスライダパッドの2チャネルの使い方
TSIタッチスライダパッドの2チャネルの使い方

※もう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 VCOMの使い方

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

FRDM-KL25ZのUARTとVCOM接続中のTera Term画面
写真1:FRDM-KL25ZのUARTとVCOM接続中のTera Term画面

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も使えます。

MCUXpresso IDEのTerminalによるTera Termの代用
MCUXpresso IDEのTerminalによるTera Termの代用

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


OpenSDA接続トラブル解決方法

ブログ読者様のおかげで、不明だったFRDM評価ボードOpenSDAとMCUXpresso IDE間の接続トラブル解決方法が判明しました。本稿は、このOpenSDA接続トラブル解決方法と、昨今の激しいMCU開発環境変化への開発者対応私案を示します。

OpenSDA v1/v2差

前投稿当日、弊社ブログ読者様からFRDM評価ボードOpenSDA処理トラブル時のJ-Linkハードウェアデバッガによる解決方法と、その根拠となったNXP Communityリンク、さらに、同様のトラブルを抱えた方々向けに、ご提供情報を弊社ブログで共有してくださいとのメールを頂きました。

この場を借りて御礼申し上げます。ありがとうございます。

ご提供情報を基に、FRDM評価ボードOpenSDA v1/v2の差をまとめたのが、下表です。

OpenSDA v1/v2とFRDM評価ボードのまとめ
OpenSDA版数 評価ボード例 開発者 トラブル状況 トラブル解決方法
OpenSDA v1.0 FRDM-KE02Z40M P&E Micro社

(Proprietary)

弊社あり OpenSDA処理MCUをハードウェアデバッガで書換えれば解決の可能性あり
FRDM-KL25Z 弊社なし
OpenSDA v2.0 FRDM-K64F ARM/mbed.org

(Open source)

Community内あり OpenSDA処理MCUをハードウェアデバッガ:SEGGER J-Linkなどで書換えて解決(情報提供者様の解決実績あり)
OpenSDA v2.1以上 FRDM-K22F

OpenSDAにはv1系とv2系があり、v1.0は開発会社:P&E MicroのProprietary製品、v2系はARM/mbed.org開発のオープンソースです。また、新しいFRDM評価ボードの多くはv2.1以上を搭載済みで、v1.0やv2.0は古くからあるFRDM-K64Fなどです(Getting Start with MCUXpresso SDK, Rev.3, 03/2017のTable 1掲載ボードでの比較。この表になぜかFRDM-KE02Z40Mの記載はありません)。

Getting Start with MCUXpresso SDK Rev. 3 03-2017のTable 1
Getting Start with MCUXpresso SDK Rev. 3 03-2017のTable 1

OpenSDA接続トラブル解決方法

OpenSDA v2系のブートローダ更新失敗などにより生じたMCUXpresso IDE接続トラブルは、SEGGER J-Linkなどのハードウェアデバッガを使って、OpenSDA処理MCU:Kinetis K20(Cortex-M4)を、評価ボードのJ-TAGコネクタ経由でユーザが直接再プログラミングすれば解決します。再プログラミング用コードも、オープンソースです(情報提供者様の解決実績もあります)。

しかし残念ながら、弊社トラブル中のFRDM-KE02Z40Mは、OpenSDA v1.0です。OpenSDA 1.0は、処理ソフトウェアがProprietary(非オープンソース)ですので、この処理部分のユーザによる再プログラミングが可能かはCase-by-caseです。

通常Proprietaryソフトウェアは、下記理由で再プログラミングができない場合が多いと思います。

理由:前稿で示したユーザ(筆者)が、Windows 10ストレージサービスを一時停止しなかったブートローダ更新は、MCU側にとってはProprietary処理ソフトウェアの悪意侵害と判断される可能性があります。
侵害と判断された場合には、セキュリティ防御手段としてMCU書込みプロテクトをかけ、再プログラミングはできなくなります。また、Proprietaryなので初めからMCU書換えプロテクト済みの可能性もあります。

※USB経由で行うブートローダ更新と、J-TAG経由のOpenSDA処理MCUソフトウェア書換えは、別物であることに注意してください。

FRDM-KE02Z40M Proprietary OpenSDA v1.0再プログラミングは、トラブル実機で試す必要があります。Proprietaryソフトウェアのため、書換え障壁はオープンソースOpenSDA v2系よりも当然高いと思われます。

J-TAGハードウェアデバッガメリット

評価ボードOpenSDA v1.0再プログラミングに必要となるJ-TAGハードウェアデバッガ価格は、例えばSEGGER J-Linkなら最低€300から、円換算で約¥37,000(2020年7月)からです。

同じ金額で10枚程度の最新MCU評価ボードが購入できるので、個人レベルのJ-TAGハードウェアデバッガ購入は勇気がいります。

J-TAGハードウェアデバッガのメリットは、旧Freescale)Bertrand Deleris氏の組込み向けデバッグ技術の基本(2007年3月:EDN)が良く解ります。マルチコアMCUデバッグや、ハードウェア/ソフトウェアブレークポイント差、セキュリティとDebug/Releaseの関係など参考になりますので、一読をお勧めします。

半導体ライフサイクルとMCU開発者対応私案

半導体製品のライフサイクルと製造中止(EOL)対策(2020年7月、EE Times)によると、多くの半導体製品の平均寿命は、3~5年だそうです。

MCUベンダ各社は、10~15年の安定供給を保証しますが、製品搭載済みMCUの賞味期限は、我々開発者が製品化に1年要したとして、発売後5年程度だと個人的には思います。

※MCU賞味期限≒MCUの差別化特徴を活かした製品が競合他社より優位な期間。IoTセキュリティ、AI機能実装や製造プロセス細分化など今後MCUは激変するハズなので、より短くなると思います。

丁度、新車購入後、2回目の車検(3年+2年=5年)で名目上の減価償却する自動車と同程度です。

COVID-19の影響で少し鈍る可能性もありますが、ADAS(先進運転支援システム)が引っ張る自動車と同様、“MCU製品も5年目安で世代交代を考えるべきだ”と思います。

また、「日本製品」が海外で売れなくなった根本原因(2020年7月、東洋経済オンライン)を読むと、「加点型の完璧主義」の世界基準に対して、日本人の「盆栽のような減点型のミニマムな完璧ものづくり」が日本敗因の1つです。プラス側メリットやそれに費やした見えない労力などは無視する一方、マイナス側の過度な批判は、日本特有かもしれません。

“基準を減点型→加点型へ180度変える努力が日本は必要”になりそうです。

MCU開発環境は、PC OSも含めて常に変化・進化します。そして、それらの環境変化は全て世界基準です。

MCUXpresso IDEは、7月9日にv11.2.0へ、MCUXpresso SDKの多くは、7月19日にv2.8.0へ更新されました。次々に生まれる新MCUや環境変化に対応するためですが、逆にこれら変化・進化に馴染まない従来MCUや減点型対応者も生じます。これらは、徐々に進化と逆らい「ガラパゴス化」している訳です。

MCU開発者は、変化・進化する環境に対して、開発中、または顧客稼働中のMCUが進化に馴染まなくなる兆候・前兆を素早く捉え、最終利用者と協議の上、従来から180度変えた“加点型対応策を取ることが、ワールドワイドなMCU開発者との競争に生き残り、その結果、日本製品も生き残れる方法”だと思います。

ガラパゴス化が全て悪い訳ではありません。しかし、日本MCU開発者がガラパゴス化すれば、その生存確率は確実に下がります。

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

これまでの章内容をまとめます。

  • 壊れたFRDM-KE02Z40のOpenSDA v1.0 Proprietary再プログラミングには、J-TAGハードウェアデバッガ:37,000円が必要で、OpenSDA v2系とは異なるProprietaryソフトウェアのため、書換え可能かはトラブル実機検証が必須。
  • J-TAGハードウェアデバッガは、MCUコア/ベンダに依存しない強力デバッグツール。
  • 激変MCU環境に対して、加点型へ進化しないと日本MCU開発者はガラパゴス化する。

これらから、FRDM-KE02Z40(Cortex-M0+/40MHz、5V Robust)のOpenSDA v1.0 Proprietary再プログラミングはあきらめ、5V耐圧が特徴であるKinetis Eテンプレートv2改版開発は中止、新たにFRDM-KL25Z(Cortex-M0+/48MHz、General Purpose = Main Stream)を用いた汎用Kinetis Lテンプレート開発に着手しようと考えております。

5V耐圧の代案は、一般的になってきたレベルシフタを用いる方法でKinetis Eテンプレートの最終利用者様への対応をお願いいたします(関連投稿:MCUの5V耐圧ピンを参考にしてください)。

5V耐圧を失う代わりに、FRDM-KE02Z40Mでは実装していましたが動作しないTouch pad (Slider)が、FRDM-KL25Zでは動作します。Touch pad (Slider)動作には、MCU内蔵Touch Sense Input:TSIハードウェアが必須です。FRDM-KE02Z40Mは内蔵されていません。TSIライブラリソフトウェアのみでは動作しないことは、2015年開発のKinetis Eテンプレート v1で確認済みです。

新開発の汎用Kinetis Lテンプレートは、このFRDM-KL25Z内蔵TSIハードウェアとライブラリ使いTouch pad (Slider)を、外付けSW入力の代わりに用います。

FRDM-KL25Z Block Diagram(出典:ユーザズマニュアル)
FRDM-KL25Z Block Diagram(出典:ユーザズマニュアル)

※FRDM-KL25Z搭載のMCU:MKL25Z128VLK4 (Cortex-M0+/48MHz、Flash:128KB、RAM:16KB、IOs:66)は最新MCUとは言えませんが、「低価格、入手性良し、汎用性(Main Stream)、応用範囲の広さ、OpenSDAトラブル無し」が、新規汎用テンプレート開発採用にプラスに働きました。

さいごに

多彩な情報満載のCommunityですが、逆に欲しい答え発見までにかなりの時間・労力がかかるのもCommunityです。

ブログ読者様ご提供Communityリンクのおかげで、短期間で効率的に問題解決法を見つけることができ、さらにJ-TAGハードウェアデバッガなどの関連情報収集、現状テンプレート開発見直しもできました。

ここにあらためて心より感謝いたします。ありがとうございました。

MCUXpresso SDKの使い方

NXP MCUXpresso IDEを使ったFRDM-KE02Z40Mテンプレートv2開発にあたり、MCUXpresso SDKベースのMCUソフトウェアの開発方法を示します。

MCUXpresso SDK全般の使い方

MCUXpresso SDKの全般的な使い方は、IDE付属のGetting Started with MCUXpresso SDKコチラの動画で判ります。どちらも初めてSDK:Software Development Kitを使う時には役立ちますが、具体的にSDKを使ってMCUソフトウェア開発をするにはどうすれば良いのかの説明はありません。

「導入説明だけで活用説明がない」典型例です。

MCUXpresso SDK構造

本稿はソフトウェア開発初心者が、一番知りたいハズだと思うSDKの具体的な使い方:活用の説明をします。SDK全般の使い方:導入説明に関しては、上記リンク先を参照してください。

OpenSDA接続問題

現時点では、FRDM-KE02Z40M(Cortex-M0+/40MHz、5V Robust)のOpenSDAとIDEデバッガ間が接続できない問題があり、代わりにFRDM-KL25Z(Cortex-M0+/48MHz、General Purpose)も使います。FRDM-KL25Zには、接続問題はありません。

※FRDM-KE02Z40MのOpenSDA接続問題は、内容とその解決策を次回以降投稿予定です。

SDK Version

Installed SDK Version (2020-07)
Installed SDK Version (2020-07)

投稿時点のSDK_2.x_FRDM-KE02Z40M(Version 2.7.0)とSDK_2.x_FRDM-KL25Z(Version 2.2.0)が上図です。MCUXpresso IDEへインストールされたSDK Versionが異なることには注意が必要です。

Versionが異なると、SDK提供サンプルプロジェクトやその中身が異なることがあるからです。多くの評価ボードの最新SDK Versionは2.7.0ですので、テンプレートもSDK Version 2.7.0を前提とします。

Hello_worldサンプルプロジェクトと新規作成プロジェクト

Hello_worldサンプルプロジェクト(左)と新規作成Templateプロジェクト(右)
Hello_worldサンプルプロジェクト(左)と新規作成Templateプロジェクト(右)

FRDM-KE02Z40Mのhello_worldプロジェクトが上図(左)です。CMSISやboardなど多くのフォルダがあり、その中にcソースファイルと、hヘッダファイルが混在しています。sourceフォルダ内にhello_world.cとmain関数があります。

このsourceフォルダが、ユーザの開発するc/hファイルを格納する場所で、他のboardフォルダなどは当面無視して構いません。New Projectをクリックし新たなプロジェクト(プロジェクト名:Template)を作成すると、この理由が判ります。

上図(右)が新規作成したTemplateプロジェクトです。sourceフォルダ以外は、hello_worldと同じ構造です。sourceフォルダ内のTemplate.c内に、コメント:/* TODO: inset other… */が2か所あることも判ります。この青色TODOコメントのソース位置は、ソースウインド右端の上下スライダに青で明示されています。

青色TODOコメントは、ソースコードのユーザ追記場所を示します。

最初のTODOコメントの下にユーザ追記インクルードファイルを、次のTODOコメントの下にユーザ宣言や定義を追記し、main関数内にユーザ処理を追記すればTemplateプロジェクトが完成します。

※main関数内にユーザ処理を追記するのは当然のことですので、main関数内にあるべき青色TODOコメントは、省略されています。

MCUXpresso SDK活用のMCUソフトウェア開発方法

前章までのSDK構造をまとめます。

  • ユーザが新規に開発(追記)するソース/ヘッダファイルは、全てsourceフォルダ内に配置
  • IDEが生成したsourceフォルダ>プロジェクト名.cのユーザ追記場所は、目印として青色TODOコメントがあり、上下スライダにも明示される
  • sourceフォルダ以外は、IDEがSDK Versionに応じて自動生成するライブラリフォルダ
  • ライブラリフォルダの中身は、ユーザ編集は不要

SDK付属のサンプルプロジェクトは、SDK構造に基づいてNXPが作成した周辺回路の利用例です。
※サンプルプロジェクトでは、青色TODOコメントは全て省略されています。

MCUが異なっても、同じ処理を行う場合は、sourceフォルダ内のユーザ追記処理も同じハズです。例えば、FRDM-KE02Z40MとFRDM-KL25Zのhello_worldプロジェクト>sourceフォルダ>hello_world.cは、全く同じソースコードで実現できています。

MCU差やSDK Version差は、sourceフォルダ以外のSDK構造部分で吸収されます。導入説明:Getting Started with MCUXpresso SDKの図1は、このことを図示したものです。

MCUXpresso SDK Laysers(出典:Getting Started with MCUXpresso SDK, Rev. 10_06_2019)
MCUXpresso SDK Laysers(出典:Getting Started with MCUXpresso SDK)

もちろん、旧SDK Versionで未提供なAPIが、新SDK Versionで新たに提供される場合もあります。ただ基本的なAPIは、新旧SDKで共通に提供済みです。

FRDM-KE02Z40MのSDK VersionとFRDM-KL25ZのSDK Versionは現時点で異なるため、IDEが自動生成するフォルダ数は異なります。しかし、ユーザ開発(追記)処理が、sourceフォルダ内で全て完結するSDK構造は同じです。

これが、hello_worldサンプルプロジェクトのようにFRDM-KE02Z40MとFRDM-KL25Z両方に共通で記述できるユーザ処理(Application Code)がある理由です。

SDK構造に沿ったsourceフォルダへのユーザ処理追記と、基本的API利用により、汎用的で効率的なMCUソフトウェア開発が出来ることがご理解できたと思います。

あとがき

2章で、「具体的にSDKを使ってMCUソフトウェア開発をするにはどうすれば良いのかの説明はない」と書きました。しかし、本稿で示したSDK活用説明は、ソフトウェア開発者は当然知っていること・・・だから説明がないとも言えます😅。

このように組込みMCU関連の資料は、前提とするソフトウェア知識・経験をどの読者も既に持っており、本稿記述の当たり前の活用説明は省略する(≒すっ飛ばす)傾向があります。

弊社マイコンテンプレートは、初心者~中級レベルの開発者を対象としており、提供テンプレートも本稿で示したSDK活用方法で開発します。ご購入者様が、なぜこのようなテンプレートになったのか疑問を持った時、それに答えるため、このすっ飛ばした省略部分を補う説明を本稿ではあえて加えました😌。

マイコンデータシートの見かた(最終回)

現役STマイクロエレクトロニクスの「メーカエンジニアの立場」から記載された、ユーザ質問の多かった事項を中心にマイコンデータシートの見かたを解説する記事(連載3回目)の最終回を紹介します。

全3回の連載記事内容

第1回:凡例、絶対最大定格、一般動作条件、電源電圧立上り/立下り(2017年10月1日投稿済み
第2回:消費電流、低消費電力モードからの復帰時間、発振回路特性(2017年10月29日投稿済み
第3回:フラッシュメモリ特性、ラッチアップ/EMS/EMI/ESD、汎用IO、リセット回路(←今回の投稿)

マイコンデータシートの見かた

3回分割のマイコン個別機能データシートの見かた、最終回ではSPIとADCの記載データ見かたが当初予定に追加されました。SPIは、接続デバイスがASICやFPGAの場合の注意点、ADCは、アナログ回路なので消費電流が大きくなる点に注意すべきだと記載されています。

当然のことですがデータシートは、データ値の羅列です。従って、そのデータ値の意味と解釈の仕方は、例えば記事図9の赤囲みコメントで付記されたようにすべきです。しかし、普通は残念ながら赤囲みコメントは、データシートには付いていません。

サンプル&ホールドタイプのA-Dコンバーターの電気的特性
サンプル&ホールドタイプのA-Dコンバーターの電気的特性(記事、図9より)

従って、この赤囲みコメントが自然に頭に浮かぶような勉強、半導体の基礎知識がマイコンを使うには必要で、その知識を背景にデータ値を読むことを記事は求めています。

連載3回範囲のデータシート見かたまとめ

  • フラッシュメモリは、高温使用時、データ保持年数が短くなる。データシート記載値は、MCU内部書込み/消去時間であり、書込み開始~終了までの作業時間ではない。書き換えビットが増えると消費電流も増える。
  • EMS/EMI/ESDは、MCUを実装した基板や使用環境に依存。データシート記載値は、MCU「単体の能力」。
  • 汎用IOは、電源電圧を下げると端子駆動能力も下がり、立上り/立下り時間が長くなる。しかし、STM32MCUは、駆動能力をレジスタで設定できるので遅くなることを抑えることができる。
  • MCUリセット回路設計時は、フィルタリング信号幅のグレーゾーンを避けることが必須。
  • SPIは、接続デバイスがASICやFPGAの場合、十分なタイミングマージンが必要。
  • ADCは、アナログ回路のバイアス電流のため消費電流が大きくなる。また電流変動で変換誤差が増える。

全て学んだ後の開発着手では遅い!

開発者に求められるのは、「開発したもの」です。

そして、多くの場合、短い期限付きです。問題は、この期限内で、なにがしかの結果、成果を出さなければ、開発者としてはNGなことです。しかし、成果を出すには勉強、知識も必要です。

初心者は、この勉強、知識の入力時間と、成果の出力時間の配分が上手くありません。ベテランになると知識も増えますが、入出力の時間配分が上手く、結局何らかの成果も生みます。特に開発者は、全行程の自己マネジメント(時間配分)にも注意を払う必要があります。

例を挙げると、夏休みの自由課題を何にし、休み中にどのように仕上げるか、です。もし提出物が無ければ、課題に取り組んでいないのと(殆ど)同じです。

残業時間制約も厳しく、開発者にとっての作業環境は厳しくなる一方です。弊社マイコンテンプレートとMCUベンダ評価ボードとの組合せは、開発者が求められる出力を早期に生み出すツールになると思います。

マイコンデータシートの見かた(その2)

現役STマイクロエレクトロニクスの「メーカエンジニアの立場」から記載された、ユーザ質問の多かった事項を中心にマイコンデータシートの見かたを解説する記事(連載2回目)を紹介します。

全3回の連載記事内容

第1回:凡例、絶対最大定格、一般動作条件、電源電圧立上り/立下り(2017年10月1日投稿済み
第2回:消費電流、低消費電力モードからの復帰時間、発振回路特性(← 今回の投稿)
第3回:フラッシュメモリ特性、ラッチアップ/EMS/EMI/ESD、汎用IO、リセット回路

記事タイトル:データシート数値の “裏の条件” とは

先入観を与える前に、記事を読んでください。消費電流、復帰時間、発振回路特性の留意点が記述されています。記事タイトルの “裏の条件” とは何でしょうか?

私は、データシート数値は、理想的動作環境のマイコン単体の最高数値、これが裏の条件と理解しています。
例えば、車の性能を燃費で比較する方は、普通の運転では絶対に達成できないカタログ燃費で車を評価します。マイコンも同じです。データシート数値は、このカタログ燃費相当だと思います。

カタログ燃費(出典:日本自動車工業会)
カタログ燃費(出典:日本自動車工業会)

実際は、この最高数値にマージンを入れて考える必要があります。どの程度のマージンを入れるかが問題で、安全側評価ならデューティ50%、つまり性能半分位が良いと思います。

但し、これもマイコン単体の話で、マイコン:MCUと電源、発信器や必須周辺回路を含めた制御系で考えると、どの程度マージンを入れるかは複雑怪奇になります。

そこで、ベンダ開発の評価ボードを手本とする考え、つまり、10月1日投稿で示した評価ボードをハードウエアテンプレートとして用いる考え方を、私は提案しています。

10月15日記事のように、評価ボードでもWi-Fi起動時電流に電源部品の余裕が(短時間ですが)少ないものもありますが、大方のベンダ評価ボードは、実用に耐えられる厳選部品が実装済みです。そこで、プロトタイピング時には、この評価ボードで制御系を作り、実装部品のマージンが十分かを評価するのです。

マージンが足りない場合には、同じ評価ボードへ、より高性能な部品を載せ替えるなどの対策が簡単にできます。制御される側もこのようなモジュールで開発しておけば、モジュール単位の設計、変更が可能です。

ソフトウエアも同様です。評価ボードを使えば、少なくとも最低限のソフト動作環境は整いますので、プロトタイピングのソフトをなるべく早く開発し、動作マージンを確認しておきましょう。

完成・出荷時には、ソフトへ様々な機能が後追加されるので、プロトタイピング時はハード同様デューティ50%、つまりROM/RAMの残りに50%位は残しておくと安心です。

ソフトウエアのプロトタイピング開発には、弊社マイコンテンプレートが最適です。

連載第2回範囲のデータシートの見かたまとめ

  • 水晶振動子のMCUクロック供給は、発振波形が正弦波に近いため貫通電流が増え消費電流大となる。
  • 未使用GPIO端子は、外来ノイズ対策に10k~100kプルアップorダウンし、電位固定が望ましい。
  • データシート低消費電力復帰時間がクロックサイクル規定の場合はそのまま使え、㎲規定の場合は参考値。
  • 外付け水晶振動子の利用時は、ベンダ推薦部品を使う。
  • 内蔵発振回路の利用時に、MCU温度変化やリフローによる機械的応力による周波数変動が無視できない場合は、周波数トリミングソフトを組込む。
  • PLL動作最低/最高周波数の設定ミスは多いが、マージンがありそのまま動作するので注意。

マイコンデータシートの見かた(その1)

現役STマイクロエレクトロニクスの「メーカエンジニアの立場」から記載された、ユーザ質問の多かった事項を中心にSTM32マイコンデータシートの見かたを解説する記事(連載1回目)を紹介します。

全3回の連載記事内容

予定されている第2回、第3回の解説内容が下記です。

第1回:凡例、絶対最大定格、一般動作条件、電源電圧立上り/立下り(← 今回の記事)
第2回:消費電流、低消費電力モードからの復帰時間、発振回路特性
第3回:フラッシュメモリ特性、ラッチアップ/EMS/EMI/ESD、汎用IO、リセット回路

今回の第1回を読むと、データシートの読み誤り易いポイントが説明されており、興味深いです。ハードウエアに興味がある、または、ハードも自分で設計するソフトウエア開発者は、読むことをお勧めします。

マイコンハード開発を数回経験すると、おおよその感触とデータシートの見る箇所が解ってきます。私も新人の頃は、網羅されたデータシートの、”どこの何を見れば良いかが判らず”困惑したものでした。

ハードウエアテンプレートは評価ボードがお勧め

私は、使用するマイコンの評価ボードを、ハードウエアのテンプレートとして使います。
例えば、STM32F072RB(=NUCLEO STM32F072RB)は、配線パターン(=gerber files)や使用部品リスト(=BOM)もサイトに公開されています。

これらのデータは、「短納期を要求される開発者の立場」なら、網羅的記載のデータシートよりも、効率よく回路設計をする手助けとなります。

データシートを見ることは、間違いなく重要です。

しかし、具体的にハードウエア設計をする時は、評価ボードのような既に設計済みの「ブツ」を参考にしながら、なぜこの部分はこうなっているのか?などの疑問を持ってデータシートを見る方が、効率が良く、しかも、分厚いデータシートのポイントを理解するのにも役立ちます。

アナログとデジタル電源の1点接地や、パスコン実装位置などは、文字で注意書きをいくらされても解り難くいものです。この点、実物は、文字に勝ります。

ソフトウエアテンプレートはマイコンテンプレートがお勧め

ソフトウエア開発は、マイコンテンプレートの宣伝をするな!と思われた、勘のいい読者の方は、コチラのサイトを参照してください。

サンプルソフトは、”メーカ立場での提供ブツですが、”開発者の立場からの実物として、STM32ファミリ、サイプレスPSoC、NXPのLPC8xx/LPC111x/Kinetis、ルネサスRL78/G1xの各種マイコンテンプレートを、ソフトウエア開発者様向けに提供中です。

連載第1回範囲のデータシートの見かたまとめ

第1回記事の範囲で、マイコンハード開発ノウハウをまとめると、以下になります。

  • マイコン外部接続ハード駆動能力は、I2C、USART、数点のLED直接駆動可能端子を除いては極小で基本的には直接駆動はしない。
  • 外部接続ハードの駆動と接続方法は、Baseboard(mbed – Xpresso Baseboard)や、各種Arduinoシールドを参考にする。
  • マイコン電源は、評価ボードのパターン、実装部品も含めてまねる。
  • 開発製品版の未使用(空き)端子処理は悩ましいが、ソフトはデフォルト、ハードはソルダーブリッジ経由で接地。

私は、今後の連載を読んで、未使用(空き)端子処理の見識などを深めたいと思っています。

半導体メーカM&Aと技術シナジー

本ブログでも関心があったFreescaleをNXPが買収し、そのNXPをQualcommが買収するという半導体メーカのM&Aは、終息に向かうようです。Runesasもアナログ、ミックスドシグナル半導体を得意とするIntersil(インターシル)の買収を完了しました。
※QualcommのNXP買収は、未だに決着がついていない買収案件だそうです。

一方で、AtmelとMicrochipに見る、半導体企業M&Aの難しさという記事を読むと、M&A完了後も企業の技術的シナジーが生まれるには時間がかかりそうです。

以前記載しましたが、NXP)LPC8xxのLPCOpenライブラリv3.01の状況を観ると、この記事内容は頷けるものがあります。MCU部門だけを比較すると、実はNXPよりもFreescaleの方が規模は大きく、また、Cortex-M0/M0+ MCUで比較すると、2社で重複する製品があるので、既成製品(LPC8xx、LPC111xやKinetisシリーズ)の将来は、明確には判らないのが現状だと思います。

統合開発環境:IDEは、旧FreescaleのKinetis Design Studio+Processor Expertと旧NXPのLPCXpresso+LPCOpenライブラリが、新NXPではMCUXpresso+SDK+Config Toolsとなり、一見、新しい開発環境に統合されたように見えます。

しかし、買収完了後の新発売MCU開発以外は、個人的には旧開発環境の方がどちらの既成製品開発にも適している気がします。

9月28日現在、LPC8xx用のLPCOpenライブラリv3.01は、残念ながら更新されていません

MCUXpresso概要と当面の開発方法

LPCXpressoとKinetis Design Studioが新しいMCUXpressoへ統合されました。Windows 10 Version 1703で動作確認したMCUXpressoの概要について示します。

MCUXpresso概要

MCUXpressoの概要は、コチラの4分程の英語Videoが良く解ります。ポイント抜粋すると以下になります。

MCUXpressoは、3つのツール:IDE、SDK、CFGから構成され、各機能が下記です。

  • IDE機能:ソースエディト、コンパイル、デバッグ。Eclipse 4.6ベース。ローカルPCで利用。
  • SDK機能:使用デバイスのAPI生成とサンプルソフト提供。クラウドで設定し、結果をIDEにダウンロードして利用。
  • CFG機能:使用ピン、動作周波数など設定。クラウドで設定し、結果をIDEにダウンロードして利用。
MCUXpresso Overview
MCUXpresso Overview

全てが1パッケージのローカルPCで機能した旧IDE(LPCXpressoやKinetis Design Studio)を、MCUXpressoで3ツール構成にしたのは、SDKとCFGをクラウド側で分離提供し、IDEを軽量化することと、CMSIS準拠の開発環境構築が目的だと思います。CMSISはコチラの記事を参照してください。

CMSIS準拠ならMCUハードとソフトの分離が容易になり、開発済みアプリケーション資産を少ない工数で別ハード移植や再利用が可能です。また、CMSIS仕様(CMSIS-COREや-DSPなど)が修正/更新されても、その内容は全てクラウド側のSDKとCFGツールに閉じ込めることができるので、常に最新CMSIS準拠のSDKとCFGを利用したソフト開発が可能です。
ARM Cortex M系のIDEは、今後この分離構成が流行するかもしれません。

注目点は、IDEではコードサイズ制限なし、SDKではFreeRTOS v9提供(LPCXpresso最終版はv8)、CFGでは電力評価やプロジェクトクローナーです。各ツールの概要を以下に示します。

MCUXpresso IDE

MCUXpresso IDE
MCUXpresso IDE

旧LPCXpressoとの差分は、FreeRTOSタブが新設されたこと位です。コードサイズ制限なしで、添付マニュアル類も判り易く、誰にでも使い勝手が良いIDEです。MCU開発は、従来のRTOSを使わないベアメタル開発から、RTOS利用ソフト開発へシフトしつつあり、このMCUXpresso IDEもこの流れに沿った機能が追加されました。

MCUXpresso SDK

MCUXpresso SDK Builder
MCUXpresso SDK Builder

SDK BuilderでBoard、Processor、Kitsなどの対象MCUパラメタを入力し、対応するSDKパッケージをクラウドで作成後、ローカルPCへダウンロードして使います。パッケージの中身は、APIとこのAPIの活用サンプル集です。但し、2017年4月現在は、FreescaleのMCUと2017年に発売されたNXPのLPC54000対応のものしか提供されていません。

その理由は、旧Kinetis Design Studio:KDSのProcessor Expert:PEの代替だからと推測します。MCUXpressoは、KDSのPE機能がSDKとCFGに分離してクラウドへ実装されました。PEをお気に入りだったユーザは、この点に困惑すると思います。

一方旧LPCXpressoのユーザのSDKはというと、これは従来のLPCXpressoに同胞されていたLPCOpenライブラリなどがそのままMCUXpressoにも実装されています。つまり、MCUXpressoは旧LPCOpenライブラリなどが従来同様使えます。

従って、LPC54000開発とKDSユーザ以外は、MCUXpresso SDKを使うことは、今のところありません。

MCUXpresso CFG

MCUXpresso CFG Settings
MCUXpresso CFG Settings

CFGも現状はSDKと同様、FreescaleのSDKとNXPのLPC54000対応のみが提供中です。

MCUXpressoのまとめと当面の開発方法

MCUXpressoは、旧LPCXpressoと旧Kinetis Design Studioを統合した新しいIDEで、現状「フレームワークは出来たものの、完全な移行完了とは言い難い」ものです。以下に特徴を示します。

  • IDEとSDK、CFGの3ツールに分離するフレームワークは、CMSIS準拠ソフト開発に適している。
  • KDSのPE代替機能をSDKとCFGに割振っている。2017年NXP発売のLPC54000開発にも使えるが、既存NXPのMCUはSDK、CFGともに未対応。
  • LPCXpressoとKDSの今後の更新は、期待できない。将来的には、NXP/FreescaleのMCU開発にMCUXpressoを使う必要あり。
  • LPCXpressoユーザは、当面SDKとCFGを使わずにMCUXpresso IDEを旧LPCXpressoと殆ど同じ使用法で使える。
  • KDSユーザは、MCUXpresso IDEとSDK、CFGを使い開発する方法と、当面はMCUXpressoにPEをプラグインし開発する方法の2通りの開発方法が取りえる。但し、PEの更新が期待できないので、将来はMCUXpresso SDK、CFGを使わざるをえない。

当面の目安としては、LPCXpressoユーザならば、既存MCUのSDK、CFGが提供されるまで、KDSユーザならば、PE更新が必要になるまで、でしょう。

もう1つの目安が以下です。Windows 10 1703更新に相当するIDEベースEclipse 4.6(Neon)の次版4.7(Oxygen)への更新は、2017年6月の予定です。IDEベース更新から約半年でこの4.7ベースの最新IDEが各社からリリースされるとすると、2017年末から2018年初め位にはMCUXpressoへの完全移行完了となる可能性があります。

MCUのIDEは開発スピードを左右する部分だけに、仕様変更や更新が定期的に発生する部分と、各社独自の部分を分離し、トータルでパッケージ化すると、以上で示したフレームワークが重要となります。開発者は、フレームワーク要素更新にも注意を払う必要があるでしょう。

NXPの新統合開発環境MCUXpresso

LPCマイコンとKinetisマイコンの2つを同時サポートする新しい統合開発環境(以下IDE)、MCUXpressoが2017年3月リリースに向けて開発中です。

LPCXpressoとKinetis Design StudioをMCUXpressoに一本化

Freescaleを買収したNXPのLPCマイコンにはLPCXpresso、旧FreescaleのKinetisマイコンにはKinetis Design Studio(以下KDS)が、それぞれの開発用IDEとして提供されてきました。どちらもEclipseベースのIDEなので、いつかは一本化されると思っていました。

新しいMCUXpressoのサポートマイコンリストは、コチラからダウンロードできます(ログイン必須)。Product Familyでフィルター操作をすると、下例のようにお使いのMCUの詳しい状況が判ります。

LPC1114/5 Support状況
LPC1114/5 Support状況

本ブログ対象のLPC1114/5とKinetis K/Lは、2017年3月にサポートされる予定です。

MCUXpressoもEclipseベースIDEで、無料版でもコードサイズ制限なしで使えるなど、数々の嬉しい特徴を備えています。LPCXpressoとKDSの最も異なる部分、API生成/提供方法がMCUXpressoでどのようになるかは、今のところ不明です。

IDEのAPI生成/提供方法

マイコンテンプレート使用中IDEのAPI生成/提供方法をまとめました。現状は3種類です。

API生成/提供方法
API生成/提供方法 概要 使用IDE
別ライブラリ IDEに別途APIライブラリを追加し利用 NXP:LPCXpresso(LPCOpen)
API生成ツール IDEで周辺回路を設定しAPI生成 Freescale:KDS

ルネサス:コード生成

SCH生成ツール IDE回路図で周辺回路を設定しAPI生成 Cypress:PSoC Creator

API生成ツールを使う方法は、周辺回路の知識が豊富でないと設定しにくいので、SCH生成ツールのCypress:PSoC方式が、動作イメージが把握し易く使い勝手が良いと個人的には思います。また、シンプルなのは、別ライブラリ提供のNXP:LPCXpresso方式ですが、MCUXpressoがこの方式になる可能性は、KDS統合も考えると少ないと思います。

いずれにしても来年は、この新しいMCUXpressoでNXPとFreescaleのマイコンテンプレートを、6月末を目途に作り直す予定です。興味がある方はすぐに現状マイコンテンプレートを購入されても、ご購入後1年以内のテンプレート更新は無償で行いますのでご安心ください。