独自開発ボードのMCUXpressoプロジェクト作成方法

今回はNXP評価ボード以外の“独自開発マイコンボード”を使って、MCUXpressoの新規プロジェクトを作成する方法を、LPC810を例に示します。

New Project by Available boards
New Project by Available boards

上図NXP評価ボードを使ったMCUXpressoの新規プロジェクト作成は簡単です。現在LPC8xxマイコンには、6種のNXP評価ボードがあり、これらの中から使用ボード選択し、Nextクリックでダイアログに従っていけば新規プロジェクトが作成できます。

Preistalled MCUsプロジェクト作成

New Project by Preinstalled MCUs
New Project by Preinstalled MCUs

一方、LPC810(ROM/RAM=4KB/1KB)で独自開発したマイコンボードへ新規プロジェクトを作成する場合は、Preinstalled MCUsからLPC810を選びます。

Nextクリック>LPCOpen – C Project>Project name追記>Import>BrowseでLPCOpenライブラリをImportします(最新版LPCOpenライブラリはv3.02ですが、ここではMCUXpresso IDE v10.1.1 にプリインスト済みのv2.19を使っています)。

Import LPCOpen Library
Import LPCOpen Library

Importするのは、lpc_chip_8xx (lpc_chip_8xx/)です。lpc_board_nxp_lpcxpresso812は、NXP評価ボード利用時、lpc_chip_8xx関数を利用したマクロ関数です(マクロ関数は後述)。

インポートが完了するとNew Projectダイアログに戻ります。ここでLPCOpen Chip Library Projectのlpc_chip_8xx_libの_lib部分を削除すると、Nextボタンが“有効”になるのでクリックします。ポイントは、_libを削除することです。削除しないと、Nextは無効のままで先に進めません。

Import lpc_chip_8xx
Import lpc_chip_8xx

この後は、デフォルト設定のままでNextを何回かクリックすれば、独自開発ボードでの新規プロジェクトが作成できます。

なおLPC810は、ROM4KB、RAM1KBと極少ですのでデフォルトで使用となっているMTBやCRPは未使用に変更すると良いでしょう。

ちなみに、MTB、CRP未使用でLPC810へ弊社LPC8xxマイコンテンプレートのみを実装した時のメモリ使用量は、ROM70%、RAM2%です(debug configuration時)。これでは、残り部分へユーザ処理を追加するとすぐに容量オーバーになります。

対策は、コンパイラ最適化をデフォルトの“最適化なし(O0)”から“、1段階最適化(O1)”へ変更することです。
Project >Properties>C/C++ Build>Settings>Tool Settings>Optimization>Optimization Levelで最適化レベルが変更できます。O1レベルでも、かなりの使用量空きが確保できます。

Optimize for Debug
Optimize for Debug

但し、最適化には副作用も伴います。変数にvolatile宣言を付記するなどして、ツールが行う勝手な最適化への対策をしましょう。対策の詳細は、コチラなどを参照してください。

マクロ関数

LPCOpen Library Stack
LPCOpen Library Stack

LPCOpenライブラリは、層構成になっています。BOARD layerは、CHIP layerを使って上位の各ExampleへAPIを提供します。例えば、LPC812評価ボード実装済みのLED出力の初期化関数:Board_LED_Init()が、chip layerのChip_GPIO_…()を使っているなどです。

Macro Function
Macro Function

本投稿では、Board_LED_Init()をマクロ関数と呼びます。NXP評価ボードは、NXPから多くのマクロ関数が提供されますが、独自開発ボードでは、これらも必要に応じて自作する必要があります。

また、自動生成ソースコードにインクルードされるファイルも、NXP評価ボードでは無いためboard.hからchip.hに代わっていることにも注意しておきましょう。

MCUXpresso Generated Source
MCUXpresso Generated Source

ベンダ提供評価ボード活用の独自開発ボード

独自開発マイコンボードと、NXP評価ボードのIO割付が同じならば、MCUXpressoの新規プロジェクト作成時に本投稿で示したような神経を使う必要はありません。多くのマクロ関数もそのまま利用できます。独自開発ボードの新規プロジェクト作成でも、NXP評価ボードと全く同じになるからです。

独自にマイコンボードを開発する前に、ベンダ提供の評価ボードIO割付を調査し、独自開発へ適用できるか否かの検討をすることをお勧めします。

ベンダ提供評価ボードは、標準的なIO割付ですが、最も応用範囲が広い割付とも言えます。さらに、上述のようにソフトウェア開発、新規プロジェクト作成に対しても多くのメリットがあるのがその理由です。

NXPとルネサスのMCU開発動向

NXPとルネサス、両社幹部が語ったMCU開発動向記事から、弊社ブログARM Cortex-Mシリーズ、16ビットMCU RL78関連部分をピックアップしました。動向記事は下記です。

NXPのMCU開発動向

記事によると車載MCUは、製品群をS32 Automotive PlatformでARMアーキテクチャ(Cortex-A、Cortex-R、 Cortex-M)に全て統一し、基本的なペリフェラル、メモリインタフェースを共通化、S32デバイス間ならソフトウェアの90%を再利用できるそうです。

同時にS32 MCUは、自動車用機能安全規格である「ASIL-D」に対応し高度セキュリティを担保、また完全なOTA(Over the Air)機能もサポート予定です(OTAはコチラの投稿参照)。

S32製品は、2018年1Qサンプル出荷、2019年から量産予定です。

Common Hardware Architecture Platform (Source: NXP)
Common Hardware Architecture Platform (Source: NXP)

この車載MCU開発動向は、本ブログ対象の家庭や個人向けCortex-MコアMCUへも影響を与えると思います。NXPはFreescale買収後、LPCとKinetisの2つのCortex-Mシリーズ製品を提供中です。

ARM Cortex-M Core Kinetis and LPC
ARM Cortex-M Core Kinetis and LPC

S32製品の強み、ハードウェア共通化、ソフトウェア再利用、セキュリティ確保、OTAは、そのまま現状NXPの 2製品並立Cortex-Mシリーズへも適用される可能性が高いと思います。その方がNXP、新規ユーザ双方にとって開発リソースを集中し易いからです(現行ユーザには多少インパクトがありますが、Cortex-Mコアは同じなので、SDKなどが変わるかも?!しれません…)。

ペリフェラルが共通化されれば、サンプルソフトも同じになるでしょう。ソフトウェア90%再利用は、ライブラリ充実化も見込めます。差分の10%は、Cortex-コア差、セキュリティレベル差、応用範囲などになる可能性があり、期待できそうです。

ルネサスのMCU開発動向

ルネサスは、2018年夏発売予定のRZファミリで、組込みAIによる推論モデル処理能力を10倍、2019年末までに更に10倍、2021年で10倍にし、推論処理能力を1000倍にするそうです。このために動的に再構成可能なプロセサ技術「DRP(Dynamically Reconfigurable Processor)」を汎用MCU製品へ取り込んでいくそうです。

RZファミリ:現状ARM Cortex-A9 400MHz採用の家電、カーオーディオなどが対象のMCU。

Cortex-AコアのRZファミリとRL78の比較(Source: Runesas)
Cortex-AコアのRZファミリとRL78の比較(Source: Runesas)

能力向上したAI推論により、振動などの画像データを扱えるようになり、さらにはそのフレームレートも高められ、例えば、熟練工のノウハウをエンドポイントで自動化できるようになる。1000倍ともなれば、現在はエンドポイントでは難しいとされる学習も行えるようになるそうです。

産業機器分野では、自動化やロボット化の実現に関わる異常検知、予知保全、認知検査などにAI処理能力を適用予定です。

1月14日投稿のルネサスe2 studioのAI利用無償プラグインで開発環境を提供しますが、弊社対象のRL78ファミリでどの様に実現されるかは不明です。

AI処理能力を1000倍化(Source: Runesas)
AI処理能力を1000倍化(Source: Runesas)

正常進化のNXPと差別化のルネサス

NXP、ルネサスともにARMコアMCUの開発動向は似ています。ルネサス幹部が、汎用MCU統括のため、あえて産業分野にフォーカスして語っただけと思います。

差分は、NXPがARMアーキテクチャの正常進化とも言えるソフトウェア資産の共通化を全面に推しているのに対し、ルネサスは、差別化DPR技術で推論機能の1000倍化を目指す点です。
※正常進化の根拠は、コチラの投稿のCMSIS参照

この差別化がガラパゴスになるのか、それとも光る技術になるか、今年夏頃の新製品RZファミリに注目します。

NXPマイコンのNXP推薦開発環境

NXPは、Freescaleを買収しARMコアのマイコンラインアップが増えました。昨年発表の新しい統合開発環境MCUXpressoで増加ラインアップに対応中です(MCUXpressoサポート状況Excel表がコチラ)。

IDE、SDK:Software Development Kit、CFG:Config Toolsの3ツールから構成されるMCUXpressoのサポート状況から、新生NXPのARMマイコン開発環境を考察します。

もっと早く気が付いていれば…

このExcel表を見つけたのは、今年1月中。LPC824の最新LPCOpenライブラリv3.02に、昨年から継続するバグ解消が無いことが理由でした。何か変だと思い、NXPサイト検索で発見したのが同表です。

2017年7E目標のLPC824対応マイコンテンプレート開発前にこの表を見つけていれば、対応が変わっていただけに残念です(orz)。LPC800でフィルタリングしたのが下図です。

LPC8xx Recommended SDK
LPC8xx Recommended SDK (Source: Version 14)

LPC8xxシリーズは、LPCOpenライブラリはAvailableなものの、NXPはCode BundleがRecommended SDK:推薦Software Development Kitです。推薦環境以外でテンプレート開発したことになります。

Change Logページを見てもいつCode Bundleへ変わったか不明です。しかし、LPC8xxテンプレートV1開発時の2014年5月10日時点では、「LPCOpenがLPC812のSDK」でした(Legacyフォルダはあっても、Code Bundleなどありませんでした)。

LPC8xxシリーズは、IDEのみMCUXpresso IDEでSDK、CFGの計画はありません。つまり、NXP推薦Code BundleかLPCOpenを使いソフト開発が必要です。

Code BundleとLPC8xx

Code Bundleは、C:\nxp\MCUXpressoIDE_10.1.1_606\ide\Examples\CodeBundlesにあります。特徴は、ハードレジスタを直接アクセスするLegacyスタイルなので、従来の8/16ビットマイコン開発者に馴染み易く、これらマイコン置換え狙いのLPC8xxには、このスタイルの方が歓迎される可能性があります。

但し、LPC81x、82x/83x、84xとハードレジスタが微妙に変化していますので制御ソフトも変化します。LPCOpenのようにAPIでハード差を吸収する思想は少ない(無い)ようです。

気になる点が2つあります。最初は、サンプルソフトのヘッダーが簡素なことです。

ベンダ提供のサンプルソフトヘッダーは、細かな注意点などが30行程度記載されているのが普通です(左:Code Bundle、右:LPCOpen)。

Sample Software Hader
Sample Software Hader

Code BundleのHeaderは弊社マイコンテンプレートと同様簡素(上図は9行)で、間に合わせで開発した感があります。また、ソース内コメントも数人のエキスパート:上級者で分担してサンプルソフトを作成したように感じました。

Code Bundleの全サンプルソフトを動作テストした訳ではありませんが、LPCOpenのようなバグは(今のところ)ありません。SDKとしてLegacyスタイルに慣れた8/16ビットマイコンユーザが使うのは問題なさそうです。

2点目は、NXP推薦開発環境でCode Bundleなのが、LPC8xxシリーズのみの点です。

他のARMマイコンは、LPCOpenかまたはMCUXpresso SDKが大半です。旧NXPマイコンは、LPCOpenまたはMCUXpresso SDK、旧FreescaleマイコンはMCUXpresso SDKが主流です。

LPC8xxシリーズのみ今後もCode Bundleにするのか、または、他の旧NXPマイコン同様LPCOpenになるのかは、ハッキリ言って判りません。

LPC8xxマイコンテンプレートの対処

現在LPCOpenライブラリを使いLPC812のみ対応中のLPC8xxマイコンテンプレートV2.1を今後どうするかの案としては、

  1. LPC812、LPC824ともにLPCOpenライブラリバグ解消を待って改版
  2. LPC812、LPC824ともにCode Bundleを使い改版
  3. LPC812は現状LPCOpen維持、LPC824は、Code Bundleを使い改版(中途半端)

いずれにするか、検討中です。決定には、もう少し時間が必要だと思っています。

ミスリード(Mislead)のお詫び

これまで弊社は、LPC8xxシリーズのSDKはLPCOpenと思い投稿してきました。この投稿で、読者の方に誤った開発方向へ導いた場合には、お詫び申し上げます。申し訳ございません。

LPC8xxテンプレートをご購入頂いた方のテンプレート本体は、C言語のみでライブラリは使っておりませんし、マイコンにも依存しません。ご購入者様は、他マイコンも含めて流用/活用はご自由です。

LPCOpenで開発された関数を、Code Bundleへ変えたとしても、テンプレート本体はそのまま使えます。

あとがき

Code Bundleは、ハードレジスタをユーザ開発ソフトで直接いじる20世紀マイコン開発スタイルです。21世紀の現在は、ハードウェアに薄皮を被せAPI経由で開発するスタイルに変わりました。メリットは、ハードが変わってもユーザ開発ソフト側変更が少なく、マイグレーションに有利です。

ARMコアのマイコンは、全てこの21世紀スタイル:ARMスタイルです。ARMがCMSISなどを発表しているのは、ARMコアに依存しないユーザ開発ソフトを、資産として活用することが目的です(CMSISはこちらの投稿を参照)。

マイコンRTOSがWindowsのようにハードアクセスを全面禁止にすることはあり得ませんので、20世紀スタイルでRTOS化しても問題ありません。が、スイッチマトリクスが気に入っているLPC8xxシリーズだけが20世紀スタイルを使い続けるとは思えません。つまり、Code Bundleは、NXPサポート体制が整うまでの暫定措置だと思います。

この混乱の原因が、QUALCOMMによるNXP買収に絡んでないことを祈っています。

QUALCOMMのNXP買収、EUで一歩前進

2018年1月19日、米QUALCOMMの蘭NXPセミコンダクター買収計画がEU(欧州連合)当局で承認の記事が日経電子版に掲載されました。残るのは、中国の独占禁止法当局の承認だけです。遅れていた買収成立が一歩前進しました。

QUALCOMMのNXP買収
QUALCOMMのNXP買収

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

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

半導体メーカ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は、残念ながら更新されていません

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