NXP LPC111xテンプレートV2改版

ARMコア制御の入門マイコンとして適しているNXP LPC1114/5マイコンのテンプレートを改版しました。

このLPC111xテンプレートV2は、従来テンプレートの必須機能のみを実装したTiny(小さな)テンプレートの適用、最新開発環境MCUXpresso IDE(v10.1.1_606)での動作確認が改版目的です。

近日中に旧LPC111xテンプレートご購入者様で、無料アップグレード対象者様には、お知らせとLPC111xテンプレートV2の無償配布を行います。暫くお待ちください。

LPC1114とLPC1115の違い

NXP LPC111xテンプレートの対象マイコンは、ARM Cortex-M0コア50MHz動作のLPC1114(ROM/RAM=32KB/8KB)とLPC1115(ROM/RAM=64KB/8KB)です。

以前の投稿で紹介したNXPマイコンの推薦開発環境をLPC1114/5でフィルタしたものが下図です。

LPC1114 and LPC1115 Recommended Software
LPC1114 and LPC1115 Recommended Software

※赤線は、評価ボード搭載マイコン、青線は、単体購入可能マイコン

NXPのLPC1100シリーズは、LPC1110/11/12/13/14/15の6種の型番と、同じ型番でも低消費電力の技術進化によりLPC1100/1100L/1100XLの3つの世代があるので複雑です(通常→L→XLでより低消費電力)。

但し本ブログは、個人でも入手性が良く低価格、良い評価ボードもあるマイコンが対象です。このふるいにかけると、フィルタの下線を付けたLPC1114/302、消費電力LPC1100L搭載のNXP評価ボードLPCXpresso1114(秋月電子2000円)、デバイス単体では、DIP28ピンパッケージLPC1114/102、消費電力LPC1100L(400円)とSOP28ピンパッケージLPC1114/102、消費電力LPC1100L(190円)の3種類がそれぞれ秋月電子より購入できるので対象となります。
※LPC1114/102は、どちらもRAM=4KBで評価ボード搭載のLPC1114/302の8KBの半分に注意

LPC1115は、LPC1114のROMを2倍の64KBにし、電力消費を第3世代に進化させたマイコンです。NXP評価ボードのLPCXpresso1115には、LPC1115/303、消費電力LPC1100XLが搭載されています。
※型番/xxxの最後の数字が消費電力を示し、1が通常、2がL、3がXLを意味します。

LPCXpresso1115の入手性はあまり良くありません。しかし、開発環境MCUXpresso IDEでAvailable boardsに現れる評価ボードはLPCXpresso1115とLPCXpresso11C24のみで、LPCXpresso1114はありません。

MCUXpresso IDE Available Boards
MCUXpresso IDE Available Boards

従って、入手性が良いLPCXpresso1114評価ボードで新プロジェクトを作るには、評価ボードからでなく、Preinstalled MCUsからLPC1114/302を選択する必要があります。

LPCXpresso1114のMCUXpresso新規プロジェクト作成方法

Select LPC1114/302
Select LPC1114/302

Preinstalled MCUsから評価ボード搭載のLPC1114/302選択後>Next>LPCOpen – C Project>Project name追記と進み、Import…をクリックします。

Click Import...
Click Import…

ArchiveでLPCOpenからlpcopen_v2_00a_lpcxpresso_nxp_lpcxpresso_11c24.zipを選択しNextをクリックします。

Import lpcopen_v2_00a_lpcxpresso_nxp_lpcxpresso_11c24.zip
Import lpcopen_v2_00a_lpcxpresso_nxp_lpcxpresso_11c24.zip

使用ライブラリにlpc_chip_11cxx_libとnxp_lpcxpresso_11c24_board_libを選択後、ダイアログに従っていけば評価ボードLPCXpresso1114/302上に新プロジェクトが作成できます。

LPCXpresso1114とLPCXpresso1115評価ボードの回路図は全く同じです。違いは、搭載ターゲットマイコンのみでIO割付も同じ、PLC-Linkと呼ぶ評価ボード付属デバッガも同じです。またImportして使用するライブラリも同じです。

ならば、Available boards のLPCXpresso1115を選択して新プロジェクトを作成し、LPC1114評価ボードへダウンロードも可能だと思われるかもしれません。しかし、これはデバッガ接続時にエラーが発生します。

MCUXpressoの右下にターゲットマイコンNXP LPC1114/302が示されており、これ以外へはデバッガ接続ができない仕組みになっています。

Target NXP LPC1114/302
Target NXP LPC1114/302

このため、同一ソースコード、使用ライブラリも同じであっても、ターゲット毎にプロジェクト作成が必要です。逆に、LPC1114評価ボードで動作確認したソースコードでライブラリも同じなら、ターゲットさえ変えれば、LPC1115評価ボードでも動作すると言えます。違いは、ROM容量のみだからです。

評価ボード搭載のLPC1115/303とLPC1114/302の機能差はROM容量以外にもありますが、LPC111xテンプレートの応用例は、この差が生じる機能は使用しておりません。

従って、テンプレート応用例のシンプルテンプレート/Baseboardテンプレートを、LPC1114評価ボード、LPC1115評価ボードそれぞれに提供します。LPC111xテンプレートProject Explorerの様子が下図です。

LPC111xTemplate Project Explorer
LPC111xTemplate Project Explorer

LPC1100シリーズの位置づけと開発環境の良さ

NXP ARMコアエントリレベルのLPCマイコンラインナップを、LPC Cortex-M microcontrollers — Discover the differenceより抜粋しました。

LPC1100 Series (Source:LPC Cortex-M microcontrollers — Discover the difference)
LPC1100 Series (Source:LPC Cortex-M microcontrollers — Discover the difference)

LPC1100シリーズは、最も基本的で適用範囲も広いCortex-M0コアマイコンです。電力効率は、LPC800シリーズのCortex-M0+に及びませんが、低電力技術の進化でCortex-M0+に近い低電力動作も可能です。Cortex-M0とM0+の機能差は、コチラの投稿も参照してください。

また、LPCOpenライブラリもLPC8xxに比べ安定(≒バグ無し)しています。DIPやSOPパッケージの入手が容易で低価格、手実装も可能です。LPCXpresso1114/5評価ボードとLPC111xテンプレートを使えば、ARM Cortex-M0マイコンの早期習得とプロトタイピング開発ができると思います。

評価ボードの半分は、切り離して単体デバッガとしても使えます。デバッガとターゲットの接続は、ARMコア標準のSWDインタフェースなので、LPCマイコン以外の他社ARMコアにも使うことができます。100mAまでの電力供給と、実質4本の接続でデバッグとオブジェクトダウンロードが可能です。

LPC111xテンプレートV2のまとめ

改版したNXP LPC111xマイコンテンプレートV2構成を示します。

テンプレート名 対象マイコン(ベンダ/コア) テンプレート応用例 評価ボード:動作確認ハードウェア
LPC111xテンプレートV2(LPCOpen v2.00a利用) LPC1114(NXP/Cortex-M0) ・シンプルテンプレート
・Baseboardテンプレート
LPCXpresso1114(LPC1114/302)
+ Baseboard
LPC1115(NXP/Cortex-M0) ・シンプルテンプレート
・Baseboardテンプレート
LPCXpresso1115(LPC1115/303)
+ Baseboard

ARM Cortex-M0コアのLPC1114/302(ROM/RAM=32KB/8KB)実装のLPCXpresso1114評価ボードは、低価格で入手性良く、開発環境MCUXpressoも他社EclipseベースIDEと比べ使い勝手良く、ライブラリも安定しています。また、評価ボードとBaseboardを接続すれば、色々な周辺回路制御も手軽に学べます。

今回の改版でテンプレート本体は、より解り易く、利用し易くなりました。テンプレートを使うと、複数のサンプルソフトをそのまま流用した並列処理が簡単に実現できます。

テンプレートの特徴や仕様は、LPC111xテンプレートサイトを、使い方などはサイトのテンプレート関連情報を参照してください。

ARMコア制御の入門用として適しているLPC111xテンプレートとLPC1114評価ボードは、Cortex-M0の習得、プロトタイピング開発のお勧めキットです。

ルネサスのNXP分析と狙う車載半導体市場

EE Times Japan、2107年12月26日にルネサスCEO、呉 文精(くれ ぶんせい)氏のインタビュー記事が掲載されています。

この中で、ルネサスが、競合NXPをどのように評価分析しているか、車載半導体のどの市場を攻めていくかを語っています。前回投稿で述べたように、車載MCUの開発動向は、弊社が扱う家庭や個人向けIoT MCUにも強い影響を与えます。記事の中から、この車載MCU開発動向に関する部分を抜粋します。

ルネサスのNXP評価分析

  • ルネサスがIntersilを買収した理由は、アナログ半導体の利益率の良さ。NXPは、もともと車載MCUに強いFreescaleを買収したので、最近のNXP車載MCU新製品は、ルネサスの脅威であり過小評価はできない。
  • QualcommによるNXP買収は、国境を越えた合併なので社風、社員の相性問題あり。ビジネスモデルもNXPとQualcommで異なる。シナジー効果を早期発揮するのは困難で、短期的にはルネサス有利。

ルネサスは、Intersilのアナログ回路を手に入れました。この結果、RL78/G11やRL78/L1Aのように、汎用MCUへアナログ回路を実装し、他社差別化の動きを加速すると思います(アナログ強化については、2017年8月3日投稿のRL78ファミリのロードマップも参照)。

ルネサスは量産車の車載半導体を狙う

  • NVIDIAやIntelは、ハイエンド(超高性能、大電力使用、高価)GPUからのアプローチ。ルネサスは、車のボリュームゾーン(量産車)に適用できる低消費電力で、低価格、 機敏な計算能力を持つMCUからのアプローチ。
    ルネサスは、量産車に載る半導体市場を狙う。

以上2項目について記事を抜粋しました。ルネサス(+Intersil)が思い描く車載半導体ビジネスが良く判る記事です。

車載メモリ

車載MCUの高性能化は必須です。もう1つの車載半導体のトピックは、メモリだと思います。

この場合のメモリとは、従来のEEPROMに相当する電源OFFでもMCU必須パラメタなどを保持できる不揮発性メモリを含みます。ルネサスの車載メモリ動向(この場合はフラッシュROMですが)は、2017年12月11日投稿で記載しています。

例えば、走行距離などは、バッテリーを外しても保持する必要があり、高信頼で不揮発データ蓄積の要求は、EV→自動運転レベルが高度になればなるほど高まります。

Cypressは、FRAM(強誘電体メモリ)という新しい技術を車載、IoT両方に提唱しています。SRAMと同様に重ね書き可能で短いアクセス時間、書換え回数も多くデータ保持期間100年(リテンション)という長さが特徴です。

FRAMと他メモリの比較(AN706-00053-1v0-J.pdfより)
FRAMと他メモリの比較(AN706-00053-1v0-J.pdfより)

FRAMの詳細は、chip1stopのCypressインタビュー記事で解ります。

*  *  *

低価格、高性能、大容量メモリのMCUは、IoT MCUの要件でもあります。EVや自動運転の技術開発は急速で、しかも車載半導体は、大量生産が期待出来るので、MCUベンダ間の競争は激化しています。車載半導体でデファクトスタンダード技術になると、IoTへもそのまま使われることは、十分あり得ます。

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

現役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シールドを参考にする。
  • マイコン電源は、評価ボードのパターン、実装部品も含めてまねる。
  • 開発製品版の未使用(空き)端子処理は悩ましいが、ソフトはデフォルト、ハードはソルダーブリッジ経由で接地。

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

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つだと言えます。

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

RTOSへの備え:最終回、FreeRTOSサンプルソフト

FreeRTOSの要点を第1回~第3回でなるべく簡潔に解説してきました。簡潔にし過ぎて部分的には不正確な記述もあります。

しかし、正確さに拘って記述すると分(文)量が増え、参考書の和訳になりかねません。ポイントとなる点をざっと掴んで、開発環境で試し、参考書やマニュアルなどで開発者自ら考える、これにより新しい技術を本当に身に付けることができます。私は、これを食物の消化に例えます。

これには、出だしでつまずかず、多少間違えてもスムースに学習を進めること(=先ずは食べること)が大切です。食べたものの消化には、時間が掛かります。後で振り返ると、内容や詳細が解るということはよくあります。

開発者への「開発スピードを上げよ」というプレッシャーは、益々強まります。この状況で技術を身に付けるには、効率的に頭の中の整理、これこそが消化、が必須です。

最良の解説書は、「サンプルソフト+評価ボード」

ソフト開発は、つまるところ、ソースコード+評価ボードによる開発環境に勝る解説書は無いと思います。ソースコードを読み理解するのに最低限必要な知識と、実際のマイコンで使えるFreeRTOSサンプルソフトを示す、これが今回のRTOS関連記事の目的です。

そこで、第3回のタスク間データ通知、同期、排他制御の自作サンプルソースや、NXPオリジナルのLチカサンプルに、より解りやすい日本語コメントを付加した第1回のLチカサンプルソースを弊社サイトのRTOSページで公開します。

このサンプルソフトを使えば、より具体的に、日本語コメント付きソースコードを参照しながらRTOS習得や理解ができます。評価ボードで動作が即確認できますので、出だしのつまずき回避にも有効です。

FreeRTOSのAPIは、多くのパラメタを含みます。パラメタを変えた時に、どのように動作が変わるかをサンプルソースに修正を加え、評価ホードで試すことができます。これは、結構重要です。食べ方を自分で変えて消化することに相当するからです。また、このパラメタ変化を事細かに記述する術は(多分)ありません。

しかし実際の開発では、この事細かな事柄を知っていないと、トラブルやバグ回避ができません。このことが「サンプルソフト+評価ボード」が最上の解説書とする理由です。

FreeRTOSサンプルソフト

FreeRTOSサンプルソフトは、NXP製LPCXpresso824-MAXで動作します。RTOSへの備え:第1回に予定していたLPCXpresso812/812-MAX、LPCXpresso1114/5の動作確認結果が下表です。

FreeRTOSサンプルソフト動作確認状況
FreeRTOSサンプルソフト動作確認状況

LPCXpresso824-MAXで動作するソースを使い、IO割付と使用LPCOpenライブラリのみを変更し、他評価ボードへ適用しました。LPCXpresso812は824-MAXと同様に動作しますが、LPCXpresso1114/5は、Lチカ以外の動作確認ができません。また、LPCXpresso824-MAXもMutexは、希望の動作をしません。代用として2個のセマフォを使って疑似的に実現しました(Mutex2)。MutexとLPCXpresso1114/5の動作NG原因は不明です。原因が判明しましたら、弊社サイトへ記載します。

以上のように出来が良くありませんので、LPCXpresso824-MAXのFreeRTOSサンプルソフトのみをサイトで公開いたしました。

当初目的の全ボードでのFreeRTOS動作確認は出来ていませんが、これも、(かなり無理があることは承知の上で)評価ボード検証のあかしと考えることにします(Orz)。

※動作しない原因がお判りの方は、info@happytech.jpへまで教えていただけると助かります。

PSoC 6続報

MONOist組み込み開発ニュースに、PSoC 6と他社製品との性能、消費電力の比較が掲載されています(出典:「業界最小」の消費電力でセキュリティも、サイプレスがIoT向け「PSoC」を投入)。

PSoC 6の目標

「ある程度のシステム制御ができる性能+低消費電力+セキュリティ、これらの同時実現」というPSoC 6の目標のために採用された40nmプロセス技術とデュアルARMコアにより、PSoC 6の他社比、優れた性能が解ります。

PSoC 6 Comparison Table1
PSoC 6 Comparison Table1(記事より)
PSoC 6 Comparison Table 2
PSoC 6 Comparison Table 2(記事より)

青字が性能同等、または、より優れた項目を示しています。PSoC 4でも採用中の高性能CapSenseやアナログコンポーネント、多くのGPIO数、そして100MHz動作のCortex-M0+、ピーク時257DMIPSなど、弊社ブログ対象の従来MCUの性能枠を大きく超えるものです。

1MB ROM、288KB RAM、8KB キャッシュの意味

ディアルコアで、1MB ROM、288KB RAM、8KB キャッシュものリソースを持つPSoC 6制御には、RTOSが必要になると思います。MCU開発も、よいよOS必須時代になるのでしょうか?

PSoC Creator News and InformationにNew FreeRTOS on PSoC 4 port が掲載されています(PSoC Creator 4.0のStart Pageからもアクセス可能)。弊社マイコンテンプレートで使ったCY8CKIT-042 評価ボードへも適用できそうです。ARMコアなので、mbed OS 5も気にはなりますが、FreeRTOSですので、RTOSへの備え記事が、理解に有効に活用できるでしょう。

弊社自作FreeRTOSサンプルソフト状況

RTOSへの備え記事は、LPCXpresso 824-MAXを使ってFreeRTOSサンプルソフトを自作しています(Lチカ、Q-通信、セマフォ同期、ミューティックス排他制御の4種)。

この自作サンプルを横展開してLPCXpresso 812/812-MAX、LPCXpresso 1114/5へ適用する予定でした。しかし、LPCXpresso 824-MAXで動作するサンプル(勿論GPIOとLPCOpenライブラリのみ変更)が、Lチカを除いて他の評価ボードでは動作確認ができないのが現状です。

原因が(僅か数十行の)自作サンプルにあるのか、それとも、それ以外かの見極めも、結構大変です。FreeRTOSもv9では、スタティックなセマフォ、ミューティックス割付ができるなど改良が進んでいるのでデバッグには良さそうですが、現状のv8は未だ非対応です。

LPCXpresso 824-MAX版だけでもFreeRTOSサンプルソフトを無償リリースするか、それとも、当初の予定どおり全評価ボード対応として問題解決後リリースするか3月末を目途に検討中です。

RTOSへの備え:第3回、タスク間データ通知、同期、排他制御

各タクスが独立=バラバラで動作する場合には、第2回に示したスケジューラーのRunningの切り替えのみでもRTOSを使ったマルチタスクとしては十分機能します。実際、LPCXpresso付属のfreertos_blinkyサンプルソフトを理解するには、第2回までの説明で十分です。

しかし、あるタクスの結果を待って別タクスが動作するような場合には、結果の待ちや通知、タクス間の同期が必要です。今回は、RTOSがどのようにこれらタクス間のデータ通知、同期を行っているかを解説します。

これらの技術を習得すれば、殆ど(7割以上)のソフト開発をFreeRTOSでカバーできるようになります。つまり、ここがRTOS習得の山場と言っても良いでしょう。少し量が多いのですが、ご勘弁を…。

初めに、状態遷移図のSuspendedによるタスク間の待ちや同期を行う仕組みを説明し、次に具体的な方法を説明します。

Suspendedの役目

第2回で示した状態遷移図のSuspendedが、タスクの待ちを実現します。

タスクAとタスクB間の通知や同期には、タスク実行中に別タスクの結果を待つことが必要となります。タスクAに待ちが発生した時は、vTaskSuspened()のAPIを使ってSuspendedへ移行し、タスクBの結果を受け取ると、RTOSがvTaskResume()のAPIを使ってタスクAをReadyへ戻します。Suspended中も第2回で示したBlocked同様、MCU能力を消費しませんので、待ち期間中も他のタスクがRunningすることができます。

以上がSuspendedによるタスクの待ちや同期を行う仕組みの簡単な説明です。Blockedと似ていることが解ると思います。違いは、BlockedがRunningからのみ遷移するのに対し、どの状態からでもSuspendedへ遷移できる点です。次にRTOSでの具体的な方法を示します。

FreeRTOSのタスク間データ通信、同期、排他制御の方法

RTOSを使わない通常ソフトの場合は、ユーザが定義するメモリ経由で、変数や結果の通知をユーザ自身が行います。また、割込みにより同期が可能です。弊社マイコンテンプレートもこの方法を使っています。

FreeRTOSを使うソフト開発の場合は、
タスク間のデータ通信は、           Queues:キュー、
タスク間の同期は、                      Semaphore:セマフォ、
タスク間の排他制御は、               Mutex(=mutual exclusion):ミューティックス、
を使います。

Queues:キューによるタスク間データ通信

FreeRTOSは、Operating SystemですのでMCU資源のユーザによる直接アクセスを嫌います。メモリなどの直接表現ではなく、論理的にメモリを繋げたQueues:キューという手段で、通信という方法によりタスク間データ送受信を行います。FreeRTOSのタスク間通信Queues:キューは、FIFO:First In First Outとして使います。

FreeRTOS Task Communication
FreeRTOS Task Communication

タスクAからタスクBへキュー経由でデータ通信する例です。受信タスクBは、xQueueReceive()でキューからのデータを受信します。このキューにデータが無い時のみSuspendedへ移行します。Suspended中は、キューデータ有無をRTOSが監視し、データが生じた時はタスクBのxQueueReceive()以降の処理が実行されます。

つまりタスクBは、xQueseReceive()の記述のみでデータ受信処理が実現できます。データ有無による待ち制御は全てRTOS側で行いますので、タスクBは受信処理のみの簡単記述ができます。

キューにより送受信タスクの処理は完全に分離されますが、処理結果のデータは、FIFOなので順序が保たれて通信されます。

Semaphore:セマフォによる同期

FreeRTOSのSemaphore:セマフォは、バイナリセマフォです。割込みによる同期を図示します。

FreeRTOS Semaphore
FreeRTOS Semaphore

割込み処理は、割込みハンドラーと割込みサービスルーティン:ISRの2つで構成します。割込み発生時、優先順位に応じてMCUハードウエアが自動的にCallするのが割込みハンドラー、実際の割込み処理を記述する部分がISRです。※図では、Interrupt!がハンドラー、TaskがISRです。

FreeRTOSの割込み同期は、ISRで割込み発生をxSemaphoreTake()で待ちます。割込み発生時、ハンドラーで割込みフラグクリアなどの処理後、xSemaphoreGiveFromISR()で動作許可(図赤丸)を与えます。この動作許可によりISRのxSemaphoreTake()以降の割り込み処理が実行されます。これが割込み同期の実現方法です。

ISR処理後、動作許可は消えます。再びハンドラーが動作許可を生成するまでISRはSuspendedになります。

Mutex:ミューティックスによる排他制御

FreeRTOSのMutex:ミューティックス排他制御を図示します。

FreeRTOS Mutex
FreeRTOS Mutex

ミューティックスの場合は、セマフォと異なり初めから動作許可(図赤丸)があります。この動作許可を初めにTakeしたタスクAのみが共有リソースへアクセスできます。タスクAのアクセス中は、動作許可がないタスクBはxSemaphoreTake()でSuspendedになります。タスクAのアクセス終了後、動作許可をxSemaphoreGive()で放棄するので、今度はタスクBが共有リソースへアクセスできます。これが排他制御の実現方法です。

つまり、動作の許可を示すバイナリセマフォを同期で使う時はセマフォ、排他制御で使う時はミューティックスと呼ぶだけで、使用するAPIは、どちらもxSemaphoreGive()とxSemaphoreTake()です。
違いは、セマフォ同期のvSemaphoreCreateBinary()では、初期値:動作許可が無いこと、ミューティックス排他制御のxSemaphoreCreateMutex()では、初期値:動作許可が有ることです。

まとめ

FreeRTOSのタスク間データ通信、同期、排他制御の方法を示しました。これら待ちの制御は、スケジューラーのタスク管理Suspendedが重要な役割を果たします。

データ通信は、Queue:キュー作成後、このキューへタスクからデータSend/Receiveという通信で実現します。同期と排他制御は、Semaphore:セマフォ作成後、このセマフォへタスクから動作許可Give/Takeにより実現します。

タスク側の記述は、データのキューSend/Receive、セマフォの動作許可Give/Takeという単純なFreeRTOSのAPIのみで良く、関係タスクの状況に応じて即Runningにするか、あるいはSuspended→Ready→Runningにするかの面倒な制御は、全てRTOS側が行います。従って、ユーザタスクは、必要処理の簡単記述ができます。

今回登場したFreeRTOSのAPIが以下です。

キューデータ通信:          xQueueCreate()、xQueueSend()、xQueueReceive()
セマフォ同期:                  xSemaphoreCreateBinary()、xSemaphoreGiveFromISR()、xSemaphoreTake()
ミューティックス排他制御:xSemaphoreCreateMutex()、xSemaphoreGive()、xSemaphoreTake()

上記と、第2回で示したFreeRTOSのAPIとを加えても20個弱のAPIでFreeRTOSが使えます。これらのAPIとFreeRTOSスケジューラーを理解していれば、FreeRTOS以外でも慌てずにRTOSソフト開発に着手できると思います。

最終回の次回は、ソースコード+評価ボードの開発環境に勝る解説書はない、という話をする予定です。