SPI/I2Cバスの特徴と最新表示デバイス

2017年11月19日2017年11月20日 WithHappy

IoT MCUは、従来の2×16文字のLCDから、SPIバス接続でよりリッチな表示ができるものへと変わりつつあると前投稿で述べました。

SPIバスは、従来MCUでも実装しています。ただし、多くの場合I2Cとポート共用で、センサやEEPROMとI2C接続するサンプルソフトが多数派でした。IoT MCUでは、センサ接続とリッチ表示を同時にサポートするので、I2C/SPIポートを2個以上装備するMCUが多くなりました。

本稿は、SPI/I2Cバスの特徴と、SPI接続の最新表示デバイスを示します。

SPIバスとI2Cバスの特徴

SPI（3線式）とI2C（2線式）は、どちらも制御ボード内で使うシリアル通信インタフェースです。少ない線数で複数デバイスを接続できますので、制御ピン数を少なくしたいMCUには適しています。
※SPI：Serial Peripheral Interface
※I2C：Inter-Integrated Circuit

仕様の解説などは、ネット内に数多くありますので省略します。

前投稿のNXP Swiss Army Knife Multi toolのWebinarで示されたSPIとI2Cの特徴に、MCU使用例を加筆したのが下表です。

SPI vs. I2C (Source: NXP Swiss Army Knife Multi tool Webinar)
	SPIバス	I2Cバス
長所	・高速・5V/3.3V デバイス混在可能	・2線でバス接続可能
短所	・デバイス毎にチップセレクト必要・4動作モードがあるためバス接続時面倒	・低速・同一Vddでデバイスプルアップ
使用例	リッチ液晶ディスプレイ, SD/MMCカードなど	EEPROM, 加速度センサ, 気圧センサなど

※NXPは、当初I2Cバスで液晶ディスプレイ接続を試みたが、結局SPIバス接続になったそうです。Webinarだと、アプリケーションノートに記載されないこのような貴重な情報が入手できます。

SPI接続の最新表示デバイス

検討の結果NXPは、128×64ドット1.3“のOLED: Organic LED（有機LED）ディスプレイをMicro SDカードとSPIバス接続しています（前回投稿Swiss Army Knife Multi tool Block図参照）。
※有機LEDは、輝度や視野角、消費電力などの面で優れた特性を持つLEDです。

＊　　＊　　＊

一方CypressのCY8CKIT-062-BLE Webinarでは、264×176ドットのE-INKディスプレイシールドが使われました。E-INKディスプレイは、電源OFFでも表示が残る画期的な表示デバイスです。しかもシールド基板なので、Arduinoコネクタを持つMCU評価ボードへの装着も可能です。

記載インタフェース信号名から、このE-INKディスプレイもSPI接続であることが解ります。

SPI E-INK Display (Source: PSoC® 6 BLE Pioneer Kit Guide, Doc. # 002-17040 Rev. *B, Table 1-3)

CY8CKIT-062-BLEは、このE-INKディスプレイのシールド基板付きで8,600円（Digi Key調べ）で入手可能なのでお得です。

しかし、E-INKディスプレイの制御方法が、PSoC Creatorの専用ライブラリ経由で、PSoC MCUファミリで使うには（多分）問題ありませんが、他社評価ボードでこのシールドを使う時は、専用ライブラリの詳細解析などが必要になると思います。

まとめ

SPIバスとI2Cバスの特徴と、SPI接続の最新表示デバイスを2つ示しました。

MCU評価ボードで使われた有機LEDディスプレイやE-INKディスプレイには、I2Cよりも高速なSPIバスが接続に使われています。

有機LEDディスプレイは、輝度や視野角、消費電力などの面で従来LEDディスプレイよりも優れています。

E-INKディスプレイシールドは、電源OFFでも表示が残りArduinoコネクタを持つ他社評価ボードにも装着可能ですが、Cypress制御ライブラリの解析が必要になります。

そこで、SPIバス接続を使ったArduinoシールド基板で、リッチ表示可能、サンプルソフトなどの情報多数、入手性が良く低価格、という条件で調べたところ、Adafruit（エイダフルート）の1.8“カラーTFTシールド（128×160ドット）、microSDカードスロットとジョイスティック搭載（秋月電子3,680円）を見つけました。

1.8" TFT Shield Schematic — 1.8″ TFT Shield Schematic

TFT コントローラICのST7735Rのデータシートも開示されていますので、OLEDやE-INKシールドよりも使いやすいと思います。

しかも、メニュー表示した画面に、付属ジョイスティックを使ってユーザが処理選択することもできるので、お勧めのSPI接続表示シールド基板です。

マイコンデータシートの見かた（その２）

2017年10月29日2017年12月20日 WithHappy

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

全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動作最低/最高周波数の設定ミスは多いが、マージンがありそのまま動作するので注意。

マイコンデータシートの見かた（その１）

2017年10月1日2017年12月20日 WithHappy

現役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と技術シナジー

2017年9月28日2017年9月29日 WithHappy

本ブログでも関心があった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は、残念ながら更新されていません。

BLEとThreadソフト開発者必見動画

2017年9月17日2017年9月17日 WithHappy

IoT通信規格のBLE 4.2とThread（802.15.4）両方をサポートするNXP）Kinetis KW41Z搭載の評価ボードを使ったBEL4.2とThreadメッシュ接続の開発Video（タイトルが以下Lesson 1～10）を紹介します。

BLEやThreadソフト開発者必見のLessons

内容、質ともに優れたVideoでMCUXpressoとSDKの使い方も良く解ります。特に興味深い内容とその出所が以下です。

Bluetooth ClassicとBluetooth Low Energyの本質的な違い（Lesson 3、3分ごろ）
Bluetooth ClassicとBLE間を接続するBluetooth Smart Ready（Lesson 3、6分ごろ）
BLE接続の具体例（Lesson 3、19分ごろ）
BLE/Thread接続に必要な知識（Lesson 3, 6）
Threadが生まれた背景（Lesson 6、2分ごろ）
Cortex-M0+/48MHz、512MB ROM、128KB RAM、FreeRTOSで実現するBLE/Thread IoT端末（Lesson 5, 9, 10）

BLEやThreadに関する情報は多くありますが、ソフト開発者の立場からは、本Lessonsが最も要領よくポイントをまとめています。

Kinetis KW41Z

Kinetis KW41Zの評価ボードは、以下の2種（Digi-Key価格）です。

Rigado製R41Z-EVAL $59.94
NXP製FRDM-KW41Z $145.00

低価格で有名なFRDM評価ボードですが、さすがに両プロトコル対応のKW41Z搭載ボードとなると$100以上します。Videoで使っているR41Z-EVALは、約$60と安く入手できます。但し、Lesson 10のBLEとThreadメッシュ切り替え接続の動作確認を行うには、同時に3台の評価ボードが必要です。

ThreadのみサポートのKW21、BLEのみのKW31もありますが、無線規格が乱立していて、どれが本命かを見極めるのが困難な現状では、両プロトコルサポートのKW41が安全でしょう。

API for IoT

MCUXpressoとSDKを使って、BLEまたはThread通信機能を持つIoT端末を開発する際に、プロトコルのどの部分の変更/修正が必要で、それがソース上のどこにあるか、全体の開発手順などはVideoを観ると良く解ります。

また、LEDなどのGPIO制御を行うSDKデモソフトとIoT通信の並列処理は、FreeRTOSを使って実現していることも解ります。簡単なIoT端末なら、このデモソフトに、外部センサ値をAD変換し、その変換データをクラウドのサーバーへIoT経由で送信する機能を追加しさえすれば、直ぐに開発できそうです。
※簡単なIoT端末は後述

BLEやThreadは、IoT通信の有力な候補です。しかし、IoTの通信プロトコルが何になるにせよ、IoT通信向けのAPIが決まれば、あまり気にする必要がない、というのが全Lessonを通しての私の感想です。

その理由は、デモソフト実装済みのGPIO制御はそのまま使えますし、FreeRTOSを使っていますので、外部センサ入力を定期的にADCする処理（ADCスレッド）と、ADC変換データをIoT通信APIへ出力する処理（IoT出力スレッド）の2処理を追加開発すれば良いからです。

ADCスレッドは、IoT通信規格には無関係です。一方、IoT出力スレッドは、Uart出力と同様のIoT APIが使える（用意される）と思います。NXP）LPC8xxマイコンのUart APIの例で示すと、Chip_UART_SendBlocking()が、Chip_IoT_SendBlocking()に代わるイメージです。IoT API利用条件が初期設定で満たされれば、ユーザは、通信速度や、通信プロトコルを意識せずにIoT通信を使えるようになると思います。

＊　　＊　　＊

IoT通信規格が不確定な状況で、少しでも早くIoTやRTOSに慣れるには、R41Z-EVALは良い評価ボードです。また、FreeRTOSを使えば、48MHz動作のCortex-M0+、512MB ROM、128KB RAMで簡単なIoT端末が開発できそうな見通しもこれらLessonは、与えてくれました。是非、ご自分でご覧になってください。

簡単なIoT端末のイメージ

データ入力とGPIO出力を行うMCU端末で、IoT無線通信機能を備える。通信セキュリティを確保できるAES-128などの機能も備え、対象機器から取得したデータを安全にクラウド内のサーバーへ送信する。
サーバーは、対象機器データを人工知能を使って予測分析し、結果を端末へ送信する。
端末は、受信結果を基にLEDなどのGPIO出力を行い、オペレータまたはロボットが対象機器メンテナンス作業の手助けをする。

ARM Cortex-M3低価格化への期待

2017年7月5日2017年7月6日 WithHappy

ARM Cortex-M3の設計開始時ライセンス費用がCortex-M0同様、無償化されることが発表されました。

これにより、新たに商品化されるCortex-M3コアを使ったMCU価格が下がる可能性があります。Cortex-M0（ARMv6-M）を100％とする性能比較をみると、Cortex-M3（ARMv7-M）の性能向上比が大きいことが判ります。

RTOSやIoT通信などのMCU環境の変化を考慮すると、コストパフォーマンスに優れたCortex-M3を次期MCU選択肢に、より入れやすくなります。

MCU開発におけるベンダ専用IDEと汎用IDE

2017年5月20日2017年5月29日 WithHappy

ARM Cortex-M系（M0、M0+、M3、M4…）のMCUを開発する時のIDEは、Eclipse IDEベースが一般的です。同じEclipseを使って各ベンダ専用IDEが開発されますので、ウインド構成や操作性（F5やF7の機能など）は同じです。

MCUXpresso IDE Perspective — NXPのMCUXpresso IDE画面（ユーザカイドより）

今回は、MCU開発スピードを左右する、専用IDEと汎用IDEの差と将来性を考察します。

ARM Cortex-M系のIDE

弊社マイコンテンプレートで使用中の専用IDE（ベンダ）が下記です。いずれもコードサイズ制限はありません。

・MCUXpresso（NXP）
・SW4STM32（STM）
・PSoC Creator（Cypress）
・CS+ for CC/CA,CX（Runesas）、64KBコードサイズ制限あり

このうち、CS+ for CC/CA,CXは、ルネサスRL78系MCUなので除外します。今回から、2016年MCUベンダ売上5位のSTM32のマイコンテンプレートも開発しますので、追加しました。

一方、MCUベンダに依存しない汎用IDEで有名なのが、下記です。

・IAR Embedded Workbench for ARM（IAR）　（＝EWARM）、無償版32KBコードサイズ制限
・uVision（Keil）　（＝MDK-ARM）、無償版32KBコードサイズ制限
・mbed（ARM）、コードサイズ制限なし

残念ながら汎用IDE無償版はコードサイズ制限があります。勿論、商用版は制限なしですが1ライセンスあたり数十万円程度もします。

mbed（ARM）は、サイズ制限なしでベンダにも依存しませんが、ブラウザでコンパイルとダウンロード（＝書込み）はできても、デバッグ機能がありませんので、今回は汎用IDEから除外しました。
※IDEへエクスポート（下図）すればデバッグ可能との記載はありますが、今のところ私は成功していません。

汎用IDEのメリットは、ベンダが変わっても同じIDEが使えること、開発したソフトのベンダ間流用障壁が専用IDEよりも低い（可能性がある）こと、技術サポートがあることなどです。

Eclipse IDEのプラグイン機能とCMSIS

オープンソースのEclipse IDEは、プラグインで機能を追加できます。もしベンダ専用機能が、全てプラグインで提供されれば、毎年更新される生のEclipse IDEへ、これらを追加すればIDEが出来上がります。これが一番低価格で良いのですが、Unixならともかく、Windowsでの実現性は低いと思います。

一方、CMSISが普及すると、開発ソフトのベンダ間流用問題はいずれ解決します。従って結局、ベンダ専用IDEで最後まで残る差は、コード生成機能になると思います。

同じCortex-M系MCUであっても、周辺回路はベンダ毎に異なる差別化部分です。コード生成機能は、汎用IDEの弱点でもあります。使いやすコード生成を提供できるMCUベンダが、生き残るでしょう。

一長一短があるChrome、Firefox、IE、Edgeなどのブラウザ同様、Cortex-M系MCU開発は、ベンダ専用IDEを使うのが良さそうだと思いました。

2016年MCUシェア1位はNXP

2017年5月9日2017年5月10日 WithHappy

2016年主要マイコンシェア/販売額の記事がEE Times Japanに記載されました。2016年は、主要MCUベンダの買収が盛んでしたが、買収後で集計されているので、MCUの現状が示されています。

車載半導体はNXPが2015年にルネサスを抜いて1位になっており、2016年のMCUシェア首位とともにNXPの躍進が明確になりました。

NXPの新IDE MCUXpresso

2017年4月時点の最新MCUXpressoIDE_10.0.0_344と、最終LPCXpresso_8.2.2_650の違いは、FreeRTOSタブが追加されたことのみです。残念ながらMCUXpressoのFreeRTOSもv8.0.1のままでした。

FreeRTOS V9はFreeRTOSサイトからダウンロードできます。が、これをMCUXpressoのv8へ手動で上書きインストールして問題なく動作させる自信はありません。FreeRTOS v9がNXPにより提供されるまで待つ方が、トラブルがなく得策と判断しました。
※MCUXpressoは、旧LPCXpressoプロジェクトフォルダがそのまま使えます。
※MCUXpressoに、PE: Processor Expertをアドインし旧Kinetis Design Studio代用とする方法は、調査中です。

マイコンテンプレートラインナップ

弊社マイコンテンプレートラインナップを、2016 MCUラインキング順に並べたのが上表です。おかげさまでテンプレートは、Runesas＞NXP（Freescale含む）＞Cypressの順に売れております。が、MCU順位5のSTM向けテンプレートもあれば、と思いました。

STMの場合、Cortex-M0/M0+を対象コアとすると、STM32F0/L0がテンプレートの対象です。しかし、このクラスのMCUへのRTOS適用によるROM/RAM大容量化や、IoT向けMCUの販売個数の増大などを考慮すると、より高性能なCortex-M3クラスも視野に入れた開発も必要か？と思っています。

CMSIS準拠でソフト開発すると、コア差はCMSISで隠蔽されるので、要求性能に応じたMCU選択が可能でクラス別けの必要もなくなります。また、RTOSでマイコンテンプレート相当が本当に必要か？という懸念もあります。

2016MCUシェアから、ルネサスの順位低下傾向が今後気になるところです。また、マイコンテンプレートについても、これらシェアの動きに合わせて、変わり続ける必要性を実感しました。

MCUXpresso概要と当面の開発方法

2017年4月18日2017年4月18日 WithHappy

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にダウンロードして利用。

全てが1パッケージのローカルPCで機能した旧IDE（LPCXpressoやKinetis Design Studio）を、MCUXpressoで３ツール構成にしたのは、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

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

MCUXpresso SDK

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

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をプラグインし開発する方法の２通りの開発方法が取りえる。但し、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は開発スピードを左右する部分だけに、仕様変更や更新が定期的に発生する部分と、各社独自の部分を分離し、トータルでパッケージ化すると、以上で示したフレームワークが重要となります。開発者は、フレームワーク要素更新にも注意を払う必要があるでしょう。

MCUXpreosso IDEリリース

2017年3月26日 WithHappy

3月22日、NXPより旧LPCXpresso IDEとKinetis Design Studio IDEを統合した新しいMCUXpresso IDEがリリースされました。見た目や操作感は、LPCXpressoに近く、Kinetis Design Studio：KDSユーザには、かなり違和感があるかもしれません。

LPCXpressoやKinetis Design Studioと共存可能

LPCXpresso v8.2.2_650やKinetis Design Studio 3 IDEと、新しいMCUXpresso IDE v10.0.0_344は、Windows 10 PC上に共存可能です。MCUXpresso_IDE_Installation_Guideに詳細が記載されています。

LPCXpressoユーザは、旧プロジェクトの移行方法などもこのガイトに記載されていますので参照してください。

KDSユーザは、Processor Expert: PEが実装されていませんので、Software Development Kit: SDKサイトへアクセスし、Build your SDKで評価ボードまたはMCU毎に構成設定し作成後、APIのダウンロードが必要です。しかし、PEほど使い勝手は良くないでしょう。この方法に慣れるか、または、PEのアドインも可能かもしれません。詳細判明しましたら、本ブログに記載します。

LPCXpresso に近いAPI提供方法

IDEのAPI生成/提供方法で示した3方法では、私の予想に反して最も旧LPCXpressoに近く、オンラインで構成設定→IDEへダウンロードしてのAPI利用となりました。このオンラインSDKをIDEへ直接インストールすることもできますが、FreescaleとNXPの合併で多数のMCUをサポートするので、軽いIDEのために、API提供SDKをIDEから切り離したと思います。

MCUXpressoでは、LPCXpressoで使っていたLPCOpenライブラリも内包されており、そのまま使えます。

両社合併で新IDEも折衷的なものです。旧環境に慣れた開発者には、オンラインSDKに慣れるか悩みどころです。特に今春発売されたMCU以外の開発にはメリットが少ないので、Windows 10 1703を待ってからインストールするのが良いかもしれません。