評価ボードから読む最新マイコン技術動向

最新マイコンの評価ボードから、IoT向けMCU技術動向を考察します。参考にしたのは2017年後半開発の下記2種評価ボードです。

つい最近、2ボードはWebinarで解説されており充実内容でした。興味がある方は、上記リンクから探せばOn Demandでも見られると思います。英語ですが非常に参考になります。

CY8CKIT-062-BLE
CY8CKIT-062-BLE

私は、「ベンダ製評価ボードは、ハード/ソフト両方の早期開発レファレンスとすべきだ」と何度か説明してきました。この認識に基づき最新評価ボードから今後のIoT MCU技術動向を抽出したのが下記です。

リッチ表示、タッチパッド、大容量ストレージ、IoT無線通信、FreeRTOS

IoTマイコンには、以下5項目が現状MCU技術に加わると思います。

IoT MCU技術動向(2017年11月)
追加技術 概要
リッチ表示出力 2×16文字程度のLCD表示から、128×160ドットカラーTFTディスプレイなどよりリッチ表示が可能な出力。
タッチパッド入力 従来タクトスイッチから、タッチパッドなどのより柔軟なユーザインタフェース入力。
大容量ストレージ 小容量EEPROM or RAMから、ロギングデータ等の保存も可能なSDカードなどの大容量ストレージ。
IoT無線通信 UART/SCIから、IoTプロトコルに応じた間欠動作で低電力志向の無線通信。
FreeRTOS ベアメタル開発から、複雑なリアルタイム処理実現のためのRTOS開発。

※IoT通信は様々なプロトコルが乱立状態ですが、BLE/Thread両方サポートに集約されそうな気配です。
※RTOSもCMSIS_RTOS/mbed OS 5/FreeRTOSと様々ですが、FreeRTOS利用例が多いです。

5項目全てが追加される訳ではなく、現状MCUにIoT通信処理のみを追加したコスト重視IoT MCUと、全て追加した高機能IoT MCUの2タイプに分かれそうです。

2タイプのIoTエンド端末

IoT MCUで開発するデバイスを、ここではIoTエンド端末と呼びます。端末の方がイメージし易いからです。コスト重視IoT MCUは、低価格IoTエンド端末へ、高機能IoT MCUは、IoTの申し子となる高機能IoTエンド端末へ搭載されます。

IoT端末の多くはこの低価格タイプになると思います。

ADCなど従来MCUのアナログ入力にセンサを接続し、IoT通信でクラウドへセンサデータを定期的に送信します。低電力処理重視のためリッチ表示などは不要で、数年~10年程度はバッテリー動作可能です。

IoT通信機能は現状未実装ですが、ルネサスエレクトロニクスのOktoberfestコースターなどが実例です。通信機能搭載で、店員のスマホから飲み物の有無や温度が解るなどの使い方が想定できます。

Oktoberfestコースター
Oktoberfestコースター

つまり、IoTクラウドの5感センシング(視覚、聴覚、触覚、味覚、嗅覚)が主機能で、クラウド処理結果やユーザへのアクション指示は、スマホなどの別端末が行うのがこのタイプです。

*  *  *

高機能IoTエンド端末は、低価格端末機能に加え、リッチ表示ディスプレイでユーザに端末やクラウド解析結果なども表示可能で、ユーザが状況に応じて判断するためのタッチパッド入力なども備わっています。

端末データをローカルなSDカードなどのストレージへ蓄積し、一括してクラウド送信することや、ディスプレイ表示を状況に応じて変更するための画像データをローカル保存することもなどもできます。

IoT普及時の高機能端末がこれで、言わば簡易スマホ機能も備えた端末と言えます。最新評価ボードは、このタイプの開発レファレンスに使えるように設計されています。

実時間で複雑な並列動作が要求されるので、RTOS(FreeRTOS)が用いられます。

NXPのSwiss Army Knife Multi toolなどが実例です。

Swiss Army Knife Multi tool Block Diagram
Swiss Army Knife Multi tool Block Diagram

まとめ

最新MCU評価ボードから、現状MCUへの技術追加(強化)5項目を抽出しました。追加項目により低価格IoT MCUと高機能IoT MCUの2つに分け、IoTエンド端末イメージを示しました。

現状MCUにIoT無線通信を追加した低価格IoTエンド端末は、IoTセンサとして機能し通信プロトコルが確定すれば、現状技術でも実現性は高そうです。

簡易スマホ機能も備えた高機能IoTエンド端末は、新技術(IoT無線通信、FreeRTOS)や、従来MCUであまり使われなかったリッチ表示出力、パッチパッド入力、大容量ストレージ技術が強化されそうです。

リッチ表示出力や大容量ストレージには、高速大容量向きのSerial Peripheral Interface:SPIバス接続が有力です。センサ接続には、従来同様低速なInter Integrated Circuit:I2Cバスを使い続けるでしょう。

タッチパッド入力は、ベンダ提供の独自ライブラリを利用する形態になります。ベンダ毎にセンス能力やウエット耐性などに性能差が生じる可能性があります。

IoT通信処理とRTOSは、様々な仕様が混在中ですが、BLEとThread両用、FreeRTOSに収束しそうな気配があります。

マイコンデータシートの見かた(その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は、残念ながら更新されていません

RL78ファミリのロードマップ

最新RL78 MCUファミリのカタログから、ルネサスRL78 MCUの開発ロードマップを抜粋しました。今後のRL78 MCUの方向性として、アナログ、センサ対応力強化が見えてきます。

RL78ロードマップと周辺回路の強化ポイント

RL78ロードマップ
RL78ロードマップ(カタログP2より)

ページ2ロードマップの赤字コメントは、ルネサスがその製品特徴を一言で表したキーワードです。緑色新製品MCUの赤字記載で目立つのは、アナログ強化とセンサです(ここでは、前提条件として無償版開発環境CS+で開発できるMCUでフィルタリングするので、ROM64KB以上の製品は除外します)。

さらに、このアナログ強化とセンサの詳細内容をカタログ記載の各MCUから読むと、S1/S2/S3コアへ、周辺回路PGA:Programmable Gain Amplifierとコンパレータ、ADC/DACを強化した製品であることが判ります。汎用製品でも、よりIoT向けのMCUへ変化しつつあることが、同ページのRL78応用分野からも解ります。

ARM Cortex-M系に勝るRL78の高品質サンプルソフト

ARM Cortex-M系が全盛な低価格MCUの市場で、唯一独自16ビットS1/S2/S3コアでライバルと争っているRL78。この市場で生き残るには、価格や開発環境の良さに加えて、実際の開発がラク、手軽になることです。

前回、RL78開発者の方々へ少し悲観的な記事を書きましたが、RL78 MCUは、使えるサンプルソフトが豊富で解説が親切、理解しやすいことも特徴です。サンプルソフトの良さ悪さは、アプリケーションの早期開発(=プロトタイピング)には重要な要素です。プロトタイピングには、ルネサスの高品質サンプルソフトと、弊社RL78/G1xテンプレートを活用してください。

開発環境CS+のサンプルソフトは、付属のスマートブラウザーを使うと、検索が簡単です。

CS+スマートブラウザーによるサンプルソフト検索
CS+スマートブラウザーによるサンプルソフト検索

残念ながら、サンプルソフトの質は、評価しにくい項目なので、MCU選定時の項目からは除外されがちです。本ブログでは、RL78サンプルソフトの質が優れた特徴をもっとアピールしていきたいと考えています。

*  *  *

PS:LPC81x/82x共通化を目指したLPC8xxテンプレートV3の開発は、7Eを予定していましたが、LPCOpenライブラリv3.01付属サンプルソフトに複数の不具合があるため、一時停止としました。これら不具合解消後、再開します。

LPC8xxのGPIO制御とデバッグTips

NXP ARM Cortex-M0+マイコンLPCXpresso8xxのLPCOpenライブラリが、v3.01へ更新され、v2.x版から持ち越された多くのバグが修正されたようでした(結論から言うと、LPC81xにはバグが残っています。LPCXpresso8xxのLPCOpenライブラリv3.01は、前回の記事を参照してください)。

今回は、マイコン制御で最も基本となるGPIO制御を、MCUXpressoのサンプルソフトperiph_gpioと最新LPCOpenライブラリv3.01を使って解説し、さらにデバッグTipsを示します。

サンプルソフトperiph_gpioのGPIO API

LPCOpen v3.01のGPIO API数は、GPIO機能初期化、GPIOピン単位制御、GPIOポート単位制御の3種類で35個あります。全部使う必要はありませんので、最も基本的なGPIO APIを抜粋し使っているのがperiph_gpioで下記7個です。

periph_gpioのGPIO API一覧(その1)
GPIO API 概要
1 Chip_GPIO_Init(LPC_GPIO_PORT); GPIO機能初期化(=クロック供給)
2 Chip_GPIO_SetPinDIROutput(LPC_GPIO_PORT, 0, ledBits[i]); ピン(入)出力方向設定
3 Chip_GPIO_GetPinState(LPC_GPIO_PORT, 0, ledBits[LEDNumber]); ピン入力値取得
4 Chip_GPIO_SetPinState(LPC_GPIO_PORT, 0, ledBits[i], true); ピン出力値設定
5 Chip_GPIO_SetPinToggle(LPC_GPIO_PORT, 0, ledBits[LEDNumber]); ピン出力値反転

LPCXpresso8xxは、Portは0しかありませんので、「LPC_GPIO_PORT, 0,」は決まり文句、最後のパラメタは、GPIO0_xyzのGPIO論理ポート番号を示します。物理ピン番号ではない点に注意してください。

periph_gpioのGPIO API一覧(その2)
GPIO API 概要
6 Chip_GPIO_SetPortMask(LPC_GPIO_PORT, 0, ~PORT_MASK); ポートマスクレジスタ設定
7 Chip_GPIO_SetMaskedPortValue(LPC_GPIO_PORT, 0, count); ポート出力値設定(マスクレジスタ経由)

ポート単位のGPIO APIは、複数の出力ピン出力を同時に設定するもので、バス出力時に便利です。これら7個のGPIO APIのみを習得していれば、基本的なGPIO制御ができます。

評価ボード実行結果

LPC81xは、LPCXpresso812、LPC82xは、LPCXpresso824-MAXの評価ボードで実行した結果が下図です。

periph_gpio実行のデバッグ画面
periph_gpio実行のデバッグ画面(赤色がLPC824、青色がLPC812)

LPC81xとLPC82xでは、同じソースでも、ポート出力値が異なります。期待値は、LPCXpresso824-MAXでしか得られません。つまり、LPC81xにはGPIO APIのポート制御にバグがあることが判ります。

デバッグTips

ここで、デバッグのTipsを解説します。

MCUXpressoのローカル変数は、Quick Start ViewのVariablesタブで、周辺回路状況は、Workspace ViewのPeripherals+タブで表示可能です。適当な場所にブレークポイントを設定しF8クリックで、ブレークポイントまで実行します。評価ボード実行結果は、この操作で得られたものです。

現行版MCUXpressoは、デバッグでよく使うファンクションキーのツールチップが一部表示されません。
F8(実行)と、F5(ステップ実行)、F6(ステップオーバー:関数に入って処理「後」停止)、F7(ステップリターン:関数に入った状態で処理「後」停止)を覚えておくとデバッグ効率が良くなります。

LPCOpenライブラリv3.01のLPC81xポート制御、バグ回避方策

LPC812とLPC824はGPIOレジスタ構成が異なります。後で開発されたLPC824の方が、より制御し易いレジスタを備えています(ハードウエアマニュアルより抜粋)。

LPC824とLPC812のGPIOレジスタ比較
LPC824とLPC812のGPIOレジスタ比較

バグがあったLPC81xのポート出力値設定の代替として、他のGPIO API利用または、直接ハードレジスタ操作などを試しましたが、LPCOpen v3.01では、代替方法が見つかりません。思うにLPC81xライブラリの結構深い場所にバグがある可能性があります。

そこで、LPC81x動作には、旧LPCOpenライブラリv2.15を、LPC82x動作には、最新LPCOpenライブラリv3.01を使ってLPC82xテンプレート開発をすることに方針変更しました。当初目標のLPC8xxテンプレート、つまりLPC82xとLPC81xの両方を同じテンプレートソースで実現することは、残念ながら諦めました。

MCUXpressoでの旧LPCOpenライブラリv2.15の使い方

MCUXpressoは、このようなバグの場合に備えて旧LPCOpenライブラリ群も備えています(C:\nxp\MCUXpressoIDE_10.0.2_411\ide\Examplesフォルダ参照)。最新版MCUXpresso IDE v10.0.2_411でもLPCOpenライブラリv3.01が同封されていないのも、本稿で示したバグが理由かもしれません。

旧LPCXpressoプロジェクトをMCUXpressoで開こうとすると、下記ワーニングが出力されます。

Older Workspace Version Warning
Older Workspace Version Warning

旧LPCXpressoとMCUXpresso両方を使い続ける方は、LPCXpressoプロジェクトをコピーして別名のプロジェクトを作成した後に、MCUXpressoで開くと良いでしょう。

LPC81xテンプレートV2.1は、テンプレートプロジェクト内にLPCOpenライブラリv2.15を装着していますので、そのままMCUXpressoで開いても問題なく動作します。

*  *  *

LPCOpenライブラリv3.01を使った新しいLPC82xテンプレートV3の開発は、7E目標で進行中ですが、上記のようなLPCOpenライブラリv3.01バグがあり、予定より難航しています。ちなみにUart関連は、LPCOpenライブラリv3.01でかなり改善されました。

また、MCUXpressoは、Ctrl+スペースキーによる入力補完機能も実装されており、使い勝手は向上しています。旧LPCXpressoを使う必要性は低いと思います。

LPC8xxテンプレートV3完成は、今しばらくお待ちください。

NXP LPC8xx LPCOpenライブラリ更新

NXPのLPX8xxのLPCOpenライブラリが、1年7か月ぶりに更新されv3.01になりました。リリースノートを見ると、多くのバグが修正され、積み残しバグ(Carried Forward)も(現時点では)無くなりました。

なお、7月11日発表のMCUXpresso IDE v10.0.2 [Build 411]に、この最新LPCOpenライブラリv3.01は、未だ同胞されていません。 是非LPCOpenサイトから手動でダウンロードしてください。

v2.15積み残しGPIO APIバグ解消

本ブログ2015年9月記事のGPIO APIバグも解消されました。
このGPIO APIバグは、2年以上前のv2.15から積み残されたものです。GPIO APIは、マイコンAPIのなかで最も重要かつ頻繁に使うものだけに、手動で修正し利用されていた方も多いと思いますが、やっと解決されました。

LPC111xのLPCOpenライブラリは未更新

LPC1100シリーズのLPCOpenライブラリ更新状況がコチラです。残念ながら、弊社LPC111xテンプレートで使用中のLPCOpenライブラリLPC11C24は、v2.00a(2013/09/13)のままです。但し、LPC111xテンプレート動作には特に問題ありません。

LPC82xテンプレート開発再開

LPC8xx LPCOpenライブラリが更新され、GPIO APIバグも無くなりましたので、前述の2015年9月記事で一時停止中であったLPC82xテンプレートの開発を再開します。

開発環境は、旧LPCXpressoを変更し、最新のMCUXpressoとします。リリースは、7月末を予定しております。
勿論、既存LPC81xテンプレートも最新LPCOpenライブラリv3.01を使って再開発し、まとめてLPC81x、LPC82x両方に対応したLPC8xxテンプレートとします。

また、Cortex-M系マイコンのコードテクニックとして有名な、ループ構文には、カウントダウンの方が高速でコードサイズも小さいことをテンプレートへ取り入れた改良も加える予定です。
※上記コードテクニックは、ARMコンパイラバージョン6.6ソフトウエア開発ガイド 7章を参照してください。

*  *  *

LPCOpenライブラリの更新は、NXPの 各種Cortex-Mマイコンへの力の入れ具合を反映したものと思います。

最新マイコンのLPC54xxxのLPCOpen版数は、v3.03.000やv3.00c.001で、LPC8xxよりも更新日も早いのは当然ですが、LPC8xxが、例えばLPC13xxなどの既存他シリーズよりも早くLPCOpen v3.xxへ更新されたのは、反映結果でしょう。これは、2016年12月記事の2017NXPロードマップとも符合します。

既存マイコンの置換え市場を狙った、小ピンでスイッチマトリクスを持つ32ビットLPC8xxマイコンの優位性を示す指標の1つだと言えます。

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

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

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

Performance of Cortex-M
Performance of Cortex-M

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

NXP LPC84x発表、2017/3Qより供給予定

6月27日、NXP LPC8xxロードマップ2017掲載のLPC84xが発表されました。

LPC84xは、従来のLPC8xx(小ピン+スイッチマトリクス)に、新たな特徴が追加されました。

・高速アクセス初期設定メモリ(FAIM)により、電源オン時クロック低周波数モード起動が可能でスタートアップ消費電流を最小化
・GPIOポートの設定構成による即時起動が可能で、MOSFETなどの付属デバイスによる潜在的な終端問題を解消

データシート6章のブロック図を示します。

LPC84x Block Diagram
LPC84x Block Diagram(データシートより)

スタートアップ消費電流の最小化を実現するのが、FIAM:Fast Initialization Memoryでこれを使うことで1.5MHzブートが可能です。起動を繰り返してもバッテリー消費が抑えられ、より長い期間の動作が期待できます。

また、容量式タッチセンシングやライブラリーによる自動キャリブレーションなどのアプリケーション向きの機能も追加されています。

LPC8xx MCU Lineup
LPC8xx MCU Lineup(ファクトシートより)

2017/3Q(7~9月)に評価ボードLPCXpresso845-MAXとともに供給開始の予定だそうです。

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

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へエクスポート(下図)すればデバッグ可能との記載はありますが、今のところ私は成功していません。

mbed Export to IDE
mbedの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を使うのが良さそうだと思いました。