ESP-WROOM-32と評価ボードESP32-DevKitC

トランジスタ技術2017年11月号特集のWi-FiとBLE4.2両方搭載のIoTマイコン:ESP-WROOM-32(秋月電子550円)とその評価ボード:ESP32-DevKitC(秋月電子1480円)の記事をまとめます。

ESP32-DevKitC and ESPWROOM-32
ESP32-DevKitC and ESPWROOM-32

無線通信Wi-FiとBluetooth 4.2搭載で単価550円のマイコン

Wi-Fiは、802.11b/g/nの2.4GHzのみ、通信中の消費電流実測値は、起動時800mA、定常時200mAなのでマイコン電源にある程度の余裕が必要です。評価ボードは、1A出力のNCP1117(ONセミコンダクタ)を使っていますが、50%デューティで考えると、もう少し余裕が必要かもしれません。Bluetoothは、BLE4.2です。アンテナも内蔵です。

Tensilica製80MHz~240MHz動作32ビットディアル(!)コア、ROM: 448KB、RAM: 520KB、NXP)LPC8xxシリーズのスイッチマトリクス相当のGPIO_matrixを実装しており、デジタル周辺回路入出力を34本あるGPIOへ割り付け可能です。AD/DAなどのアナログ周辺回路は、ピン固定です。

製造は中国Espressif Systems社、従業員数約120人のファブレスメーカで、2016年米ガードナーが「IoT産業における最もクールな企業」に選出しました。Cortex-M系コアでありませんが、確かに機能/価格:コスパは凄いです。マイコン単体、評価ボードどちらも秋月電子からの入手性が良いので、人気が出るかもしれません。

プログラミングはArduino IDEとCLIのESP-IDFの2種

評価ボードESP32-DevKitCのプログラミングは、Arduino IDEのスケッチベースと、コマンド ライン インターフェース:CLIを使うEspressif Systems社提供ESP-IDF(IoT Development Framework)の2通りがあります。イーサネット、BLE4.2やI2Sを使う場合は、ESP-IDFでの開発が必要です。

評価ボードは、前述の1A電源とUSBシリアル変換デバイスのみ実装ですので、LEDやSWなどをブレッドボードなどで追加し、開発プログラムの動作確認をします。記事4章では、I2C接続で2種類の加速度センサー、1000円台で購入できるMMA8451Q(NXP)、または、20ビット高分解能のADXL355(アナデバ)を使い、簡易IoT地震計を開発しています。I2C経由の加速度データ取得方法は、他のマイコン制御時にも参考になります。

ディアルコア超高性能マイコンですので、評価ボードに1.8インチのSPIカラー液晶モジュール:M-Z18SPI-2PB(aitendo、950円)を接続し、動画を再生しているのが5章です。7章は、AD/DAを使って、今はやりのスマートスピーカーを開発しています。

11月号は、10ドルコンピュータのラズベリーパイZero Wを使った記事も記載されていますが、本ブログはマイコンが対象ですので割愛します。

マイコン開発のポイントは、ライブラリ活用/流用

コマンドラインインターフェース:CLIを使ったソフト開発は、慣れが必要です。しかし、これは慣れの問題です。例えArduino IDEでも、初めての人には戸惑う部分もあるでしょう。Arduino IDEが隠して(見えなくして)いる部分が他に比べて多いので、比較的簡単に慣れるようになるだけの話です。

慣れた後はどちらの開発環境も、豊富なライブラリや、サンプル・プログラム、サンプルソフトを使ってソフト開発をします。個人が1からソフトを全部開発するのではなく、既にあるソフト資産を活用/流用する、これが全てのマイコン共通の現代的なマイコンソフト開発方法です。

これはソフトウエアに限ったことではありません。ハードウエア開発でも、評価ボードやArduinoソケットは、1種のライブラリとも言えます。ソフト、ハードともに使える資産は活用し、これで得た(得をした)開発時間は、独自性を活かす部分に使います。

ライブラリ活用/流用には、ライブラリを使う側の骨格:スケルトンを理解していることが前提条件です。記事P48のArduinoスケッチの書き方で言えば、図Aのsetup()やloop()関数のようにマクロ的にソフト構造を捉えた後に、ミクロな問題へと詳細化することです。

骨格:スケルトンを理解していれば、後は必要な機能をライブラリの中から選び、必要に応じてライブラリを修正し、骨格に付け加えれば、動くモノが完成します(完成度で言えば65~79%:良判定)。

マイコン開発はこの動くものから、完成・出荷段階(完成度80%以上:優判定)にするのに結構な手間と時間が掛かります。

従って、ライブラリを上手く使ってなるべく早い段階で良段階へ到達し、ここからは腰を落ち着けて80%以上の完成度になるように開発時間の配分をしましょう。
また、骨格理解や習得にも十分な時間を割きましょう。

弊社マイコンテンプレートは、様々なサンプルソフトを流用/活用した早期ソフト完成、いわゆるプロトタイピング開発に役立ちます。是非ご活用ください。

マイコンIDE習得のポイント

Windows 10 Home Update制御

販売中のマイコンテンプレート説明資料は、テンプレートについて重点的に説明しています。しかし、ご購入者様から頂く質問には、テンプレート動作環境、つまりマイコンIDEに関するものも多くあります。
今回は、このマイコンIDE使い方のコツ、ポイントを説明します。

Windows 10発売を機に、皆さんは今新しいOSの機能や利用方法を習得中だと思います。マイコンIDEと、このWindows 10を関連付け解説を試みます。

マイコンIDEは、OSと考えるべし

Windows 10、旧Windows 7や8と比べると、新ハードウエアやネットワーク、セキュリティ対応に機能満載です。多くの設定項目がありますが、最初はデフォルト設定で動かすのが良いでしょう。慣れてくれば、設定をいろいろに変えて、自分好みにカスタマイズもできます。

マイコンIDEも同じです。IDEは、多くのマイコン機種、使用言語、デバッグ方法に対応できるよう多くの選択肢:プロパティを持ちます。ユーザマニュアルにも、多くのページを使ってプロパティの説明があります。しかし、IDEを使う時に、これら多くのプロパティを、全部知るのは無理ですし不要です。

Windowsと同じく最初はデフォルトで使用し、徐々にカスタマイズするのがIDEやOSなどの環境ソフトの使い方です。

初心者にとって、デフォルト設定でIDEが使えればありがたいのですが、多くのIDEは、中級~上級者へも対応する、いわば「初心者と中級者以上の二兎を追う方式」のため、多少のカスタム設定が必須です。
このカスタム設定が最も少ないのが、IDEベンダ提供の標準評価ボードを使ったマイコン開発時です。弊社テンプレートが、この評価ボードで動作確認しているのもこのためです。

  • マイコンIDEのプロパティ設定が多いのは、しょうがない。
  • カスタムプロパティ設定の少ないIDE+標準評価ボードが、マイコン初心者には適す。

マイコンIDEの使い方ポイント

使用するマイコン、開発言語(C/C++ または アセンブラなど)、IDE(コンパイラやデバッガなどの開発環境)は選定済みとします。この時のIDE設定手順が下記です。3段階から構成されます。

マイコンIDE設定手順
マイコンIDE設定手順

IDEへ使用マイコンとデバッガなどの環境ツール設定が、最初の段階です。ここでは、Rapid Application Development: RADツールを使用するか否かなども選択肢になります。MCU:マイコン本体クロック設定と周辺回路の設定が、次の第2段階です。最後が、IDEが出力したスケルトンソースへ、ユーザソースを追加し、ビルド&ボードデバッグを繰り返し行い、アプリケーションを完成させます。

ポイント1:IDE生成スケルトン理解

直ぐにユーザソースを追記したい気持ちは解ります。しかし、使用するRADツールに応じてIDEが生成するスケルトンが異なることがよくあります。例えば、FreescaleのKinetis Design Studioの場合、RADツールにProcessor Expertを選ぶ場合と、Kinetis Software Development Kitを選ぶ場合とでは、スケルトンが異なります。ルネサスのCS+でも、コード生成の有無でスケルトンは全く異なります。

先ず、IDEが生成する「スケルトン動作を把握することが最重要」です。このために、RAD選択肢を変えることも必要でしょう。殆どのIDEの場合、第2段階のMCUクロックは、デフォルトで安全動作周波数に設定済みです。従って、周辺回路なしでも生成されたスケルトンコードでボードデバッグができます。

スケルトン動作把握とは、「マイコン電源投入後、順番にどの処理を行い、main()を呼出しているか、次に、割込み処理の記述はどこで行っているかを知ること」です。

main()呼出しまでの処理(スタートアップ処理)は、MCU動作クロックを変更する場合などを除けば、大体把握できればOKです。また、マイコン機種による違いも少ないです。

一方、割込み処理記述は、使用マイコンやIDEにより様々です。経験的に、IDEと標準評価ボードの組合せで用いる記述方法が、解りやすさや柔軟性に優れます。素直に、この方法でユーザ処理を追加することをお勧めします。

  • IDE生成スケルトンは、使用RADツールにより異なる。
  • 生成スケルトンの動作を把握することが最重要。

ポイント2:デバッガ接続

最初は、MCUクロックはデフォルト設定、周辺回路なし、スケルトンコードのみでビルドします。このビルドは、IDE生成分のみですので100%成功するハズです。

問題は、デバッガ接続です。

IDEがサポートするデバッガは、通常4~6種類もあります。デバッガに応じてさらに詳細設定が必要ですので大変です。ここは、ユーザマニュアルの「対応デバッガ部分のみ」を注意深く読んで、設定する必要があります。ユーザマニュアルが分厚いのは、このように対応種類が多いためです。使用するデバッガのみに絞って読めば、恐れるに足りません。

IDEとデバッガを接続後、ビルド出力をボードへダウンロードし、デバッガで動作確認します。何もユーザ処理を追加していない時の動作、例えばスタートアップ処理後のRAMクリア状態などが確認できます。

ユーザ処理は追加していませんが、これでIDEの処理全体を一通り試すことができます。

  • IDEとデバッガ接続は、ユーザマニュアルの対応部分を拾い読み。
  • 最初のビルドは、スケルトンコードのみでデバッガ接続しIDE全体処理を体験。

ポイント3:サンプルソフトAPI利用例を活用

スケルトンは、骨組みです。この骨組みに、ユーザ処理を追記すれば、アプリケーションが完成します。

骨組みには、IDEが使用周辺回路に応じてライブラリを生成します。このライブラリへのインタフェースがAPIです。IDEの役割は、APIの中身を作ることです。

ユーザソースは、このAPIの使用順序を記述するのみと考えても良いです。少し前までは、このライブラリもユーザが開発していました。しかし最近は、ライブラリはベンダが提供します。ベンダ提供ライブラリを使えば、ユーザソースは、API使用順序のみですので、移植性やメインテナンスも楽です。

APIの使用法は、これも分厚いAPIレファンスマニュアルに記述されています。しかし、真面目にこれを読む前にサンプルソフトを参照します。典型的な周辺回路APIの使い方、これがサンプルソフトです。サンプルに出てくるAPIのみをレファレンスマニュアルでチェックすれば十分です。サンプルソフトの選び方は、コチラを参照ください。

  • IDEは、スケルトンと、使用周辺回路に応じたAPIを生成。
  • サンプルソフトを参照し、典型的なAPIの使い方を学ぶ。

まとめ

多くのプロパティがあり、付属マニュアルも厚いので取っ付きにくいマイコンIDEですが、ここで示した方法を用いれば、早く効果的にIDEを習得できます。

具体的な話が少ないので、皆様のお叱りを受けそうですが、少しでもご参考になれば幸いです。

* * *

Windowsには、様々なTipsがあります。各マイコンIDEのTipsも少なからずありますが、ここでは個々のIDEによる違いは無視して説明しました。実は、IDEで差が生じるのはRADです。RADに対しては、初心者の方は、少し力を入れてマニュアルを読む必要があるかもしれません。
但し、これも必要な周辺回路の箇所のみを拾読みすれば、事足ります。分厚いマニュアルは、読む箇所を間違わないように、拾読みで対処しましょう。

Windows 10 Home UpdateコントールTips

マイコンIDEで具体例が無かった代わりのTipsです。
Windows 10 HomeでOS Updateをユーザが制御できない問題に対し、フリーソフト: Winaero Tweakerが役立つかもしれません。Technical Preview対応ですが、製品版にも使えそうです。

Windows 10 Home Update Control
Windows 10 Home Update Control

LPC8xx用LPCOpen v2.15へ1年3か月ぶりに更新

LPC8xxテンプレートに使用中の、NXP LPC8xx用LPCOpenライブラリが、v2.01(2013/10/04リリース)からv2.15(2015/01/08リリース)へバージョンアップされました。変更箇所(原文)を抜粋します。

Changes

  • Fixed system clock frequency calculation function
  • Fixed IAR/Keil build warnings
  • Added support to run from IRC without using PLL
  • Keil Projects updated to Keil uVision v5.xx
  • IAR Projects updated to IAR version 7.xx
  • Updated ADC and ACMP examples [Directly connects to POT in EA Base board]
  • Examples updated, so that it won’t depend on EA Motor control board
  • Glitch Filter APIs updated
  • Board library UART Fractional generator configuration updated
  • Fixed low power mode API Chip_PMU_SleepState()
  • readme files updated
  • Updated SCT Examples
  • Fixed a stack overwrite problem in IAP code
  • PININT interrupt names made consistent

LPC8xxテンプレート改版予定

これに伴って、LPC8xxテンプレートも、この新しいLPCOpenライブラリを使い、近いうちに改版予定です。先ずは、NXPのLPCOpenライブラリ改版速報をお知らせしました。

ちなみに、LPC111xテンプレートのLPCLPC11xx用のLPCOpenライブラリは、2015/01/10現在v2.00a(2013/09/13リリース)のまま不変です。

データフラッシュライブラリ Type04 V1.05 リリースノートのリビジョンアップ

2014年12月16日のRunesas Toolニュースで、弊社RL78/G1xテンプレート使用中のデータフラッシュライブラリType04リビジョンアップのお知らせがきましたので、解説します。

データフラッシュライブラリ本体変更なし

変更箇所は、ユーザーズマニュアルとリリースノートの部分で、「ライブラリ本体は変更なし」です。従って、「RL78/G1xテンプレートも変更なし」です。

QB-R5F100LE-TBのサンプルプログラム添付

ユーザマニュアルにも変更があるようですが、重要なのは、リリースノート8章のRL78/G13 QB-R5F100LE-TB ボードのサンプルプログラムです。

この8章に、簡潔にデータフラッシュライブラリのCS+での使い方と、リンク・ディレクティブ設定が書かれています。ライブラリ使用をご検討の方は、先ずこれを読んで、理解不足箇所をユーザーズマニュアルで補足すればポイント理解が早まると思います。

データフラッシュライブラリ理解は進むが…

添付サンプルプログラムは、CS+のプロジェクトファイルではありません。リリースノート記述がCS+対応なだけに、個人的には、不親切で残念な気がします。ストレージ容量削減のためでしょうか? データフラッシュライブラリを使うレベルの技術者なら、Cソースとリンクディレクティブファイルのみで十分と判断したためでしょうか? 疑問です。

これらファイルをCS+のプロジェクトへ組込む時の留意点は、リリースノート記載の高速オンチップ・オシレータを32MHzへ設定する以外にも多々あると思いますが、これらをいちいち細かく説明すると説明が長くなります。最も効率的な方法が、実際のCS+のプロジェクトを提供する事だと思います。せっかくのサンプルが、何らかの問題で動作しなければ徒労に終わるからです(「何らかの問題」は、マイコン開発では頻繁に発生します)。

弊社テンプレートファイルは、対象マイコンの標準的な無償開発環境と評価ボードで動作します。RL78/G1xテンプレートでは、CS+プロジェクトでQB-R5F100LE-TBを含む4種類の評価ボードをサポートしており、そのままボードにダウンロードすれば動作確認ができます。このテンプレートへ、リリースノート添付サンプルを組込むと、CS+設定不足やミスなどを避けて確認ができると思います。

弊社テンプレートは、このようにお手元にあるサンプルプログラムをそのまま流用/組込み可能なことも特徴の1つです。テンプレートの活用方法として、この組込み容易性にも留意して頂けると嬉しいです。

サンプルプログラム説明の重要性

動作プログラムは、いろいろなパラメタが設定済みで、その結果、動作するものです。パラメタ設定がデフォルトなら問題なしですが、変更した箇所は、だれもが判るような工夫、解説は必要と考えます。どの程度説明するかが悩ましいトコロですが、弊社テンプレート説明資料は、極力この方針で作成しております。ご購入者様のご質問や、お問い合わせ内容などは、テンプレート改版時に反映させますので、お気軽にcustomerservice@happytech.jpへお問い合わせください。

LPC81x開発・習得にはLPCOpenライブラリが適す

LPC81x開発・習得にあたり、LPCOpenライブラリと従来ライブラリ(LPCCloseと呼ぶ)を比較し、LPCOpenがアプリ開発・習得に適すことを示します。

LPCCloseライブラリの UARTサンプルソフト

UARTサンプルソフト
UARTサンプルソフト

従来ライブラリ:LPCCloseのUARTサンプルソフト、“uarttest.c”の最初の部分を抜粋しました。前記事に示したライブラリ利用の為に、コア制御に”LPC8xx.h”、周辺回路制御に、”lpc8xx_clkconfig.h”と“lpc8xx_uart.h”のヘッダファイルをインクルードした後に、サンプルソースを記述しています。このUARTサンプルは、UART初期設定後、PCへ”Hello world!”とUART送信し、PCからのUART受信文字をエコーバックします。動作中のデバッガ画面とターミナル画面を示します。

システム動作クロック12MHzのUART通信
システム動作クロック12MHzのUART通信

システム動作クロック変更

全てのLPCCloseサンプルソフトは、システム動作クロック(SystemCoreClock)をLPC81x内蔵RCオシレータ12MHzで動作させています。この速度を変えるには、以前の記事に書いたクロックパラメタ算出ツールが便利です。前の記事は、LPCOpenライブラリでの例でしたので、LPCCloseライブラリで24MHzに変える例を示します。

クロックパラメタ算出ツール
クロックパラメタ算出ツール

このツールから、クロック速度を24MHzへ変えるには、SYSPLLCTRL:0x41を0x23へ、MAINCLKSEL:0x0を0x3へ、SYSAHBCLKDIV:0x1を0x2への3変更で良いことが判ります。これらは、CMSIS_CORE_LPC8xxフォルダの”system_LPC8xx.c”に記述されています。

システム動作クロック変更箇所
システム動作クロック変更箇所

これらパラメタを変更し、デバッガプローブ機能でクロックが24MHzに変わったことを確認後、UART通信を行うと、ターミナル側に文字化けが発生します。変更箇所はパラメタのみです。つまり、LPCCloseライブラリのUARTサンプルは、残念ながら24MHzでは正常動作しないことが判ります。

システム動作クロック24MHzのUART通信(文字化け)
システム動作クロック24MHzのUART通信(文字化け)

但し、gpioなどの他ライブラリはどの速度でも問題なく動作します。従来ライブラリUARTに何らかの原因があることは確かです。この原因追究は、スキルアップに繋がります。しかし、「ライブラリが提供するAPIを活用したアプリ開発・習得からは、かなりの回り道」となります。

LPCOpenライブラリのUART動作

一方、LPCOpenライブラリは、システムクロックが12MHz、24MHz、30MHzでもUARTは正常動作します。前記事のLPCOpenとLPCCloseライブラリの使い易さ比較でLPCOpenの方が圧倒的に簡単であることも考慮すると、LPC81xの開発に、敢えて「従来ライブラリLPCCloseを使う意味・理由はない」と思います。

残念なのは、開発環境LPCXpressoの付属サンプルソフトが、従来ライブラリLPCCloseであることです。慣れない環境で初心者がLPC81xを検証する時は、サンプルと評価ボードを使います。今回示したシステム動作速度を変えた時、サンプルが正常動作しない問題は、開発や理解に大きな障壁となります。もし、従来ライブラリの代わりに、LPCOpenライブラリのサンプルが初めから付属していれば、この問題は回避できます。

LPCOpenライブラリとLPCOpenテンプレートの薦め

最新版のLPCOpenライブラリのリンクはココです。LPC81xアプリ開発・習得には是非、このLPCOpenサンプルソフトを使うことをお勧めします。

また、「LPCOpenライブラリを使い、そのまま実務にも使えるLPC8xxテンプレート」を活用頂ければ、より効率的にアプリ開発・技術取得が期待できます(LPC8xxテンプレートはコチラを参照ください)。

LPC81xのLPCOpenと従来ライブラリの使い易さ比較

LPC81xソフト開発時に利用するLPC81xライブラリで、ソース記述がどのように変わるかを示します。

利用ライブラリ選定

LPCXpressoは、新プロジェクト作成時、プロジェクトウイザードで2つのライブラリ、LPCOpenまたはLPCClose:従来ライブラリのどちらかを選定する必要があります(各ライブラリは、コチラを参照)。

LPCOpenまたはLPCClose選択
LPCOpenまたはLPCClose選択

その結果、プロジェクトに追加されるライブラリファイルとその制御対象が下表です。LPC81xには、これら選定ライブラリの他にROMライブラリもあります(LPCOpenとROMライブラリが、それぞれ機能補完していることは、コチラを参照)。

選定ライブラリ コア制御 周辺回路制御
LPCOpen lpc_chip_81x_lib nxp_lpcxpresso_812_board_lib
LPCClose CMSIS_CORE_LPC81x lpc800_driver_lib

 

ライブラリの使用宣言

ライブラリ選定後、プログラムソース記述時は、#include “ライブラリヘッダファイル”で使用宣言が必要です。LPCOpen選定の場合は、#include “board.h”のみで、コア制御と全ての周回路制御、さらにROMライブラリも「同時」に使えます。

一方、LPCCloseの場合は、コア制御に#include ” LPC8xx.h “、周辺回路は、制御対象に応じて#include “lpc8xx_制御対象.h”の宣言が「個別」に必要です。また、ROMライブラリ利用の場合は、ROMテーブルやROMライブラリ物理位置の宣言などを「別途追加」する必要があります(詳しくは、LPCユーザマニュアルUM10601のLPC81x Boot ROMセクション参照)。

ROMライブラリ追加宣言(一部抜粋)
ROMライブラリ追加宣言(一部抜粋)

使い易さ比較

つまり、LPCOpenなら#include “board.h”のみ、LPCCloseなら#include ” LPC8xx.h”の他に#include “lpc8xx_gpio.h”、#include “lpc8xx_mrt.h”・・・や、ROMライブラリ追加宣言などのインクルードが、肝心の「ソース記述前」に必要となります。

LPCOpenのboard.hを診てみると、色々なヘッダファイルが、孫引きでインクルードされるのが判ります。プログラミングでは、LPCOpenライブラリ利用の方が、記述が簡単です。結果としてバグ減少が期待できます。LPC8xxテンプレートに関して、LPCOpen版が先に販売開始され、LPCClose版が後になっているのは、この理由もあります。

LPC8xxテンプレートLPCClose版の対策

開発中のLPC8xxテンプレートLPCClose版は、煩雑な記述を避けるため、LPCOpen版と同様、1つのヘッダファイルインクルード追記でLPCCloseライブラリが利用できるように工夫します。

LPC8xx使用ライブラリとプログラムサイズ

LPC8xxには、2種類ライブラリがあることは以前記載しました。さらにROMにもI2CやUARTなどのライブラリがあるので全部で3種類ですが、今回は、最初の2種類、LPCOpenライブラリと従来ライブラリ(LPCCloseと呼ぶ)で、どの程度Flashプログラムサイズが変わるかを示します。

新規Cプロジェクトサイズ

LPCXpressoでLPC820新規Cプロジェクト作成直後のDebugビルドでのプログラムサイズが下記です。コンパイル最適化などは行っていません。つまり、ブート処理のみ行い、何もしないCプログラムです。

プログラムサイズ CRP有効 CRP無効
LPCOpenライブラリ使用 1952バイト 1540バイト
LPCCloseライブラリ使用 1140バイト 728バイト

※LPCXpresso_7.1.1_125で実施。2014/05/25現在、最新版は、LPCXpresso_7.2.0_153。

CRP: Code Read Protectionとは、Flashプログラムの読取りに制限やプロテクトをかける機能で、この機能を有効にすると約400バイト必要になることが判ります。製品出荷時には必要になる機能でしょう。

何もしないプログラムのFLASH専有率

CRP有無と使用ライブラリで4つの組合せを示しました。LPC8xxデバイスのFlash容量に対するこれらの占有率を示します。

何もしないプログラムのFLASH専有率(%)  専有率
LPCOpen CRP有効 48% 24% 12%
CRP無効 38% 19% 9%
LPCClose CRP有効 28% 14% 7%
CRP無効 18% 9% 4%

 

8ピンのLPC810はFlash容量が4Kバイトですので、LPCOpenライブラリでCRP有効にすると1952/4096=48%のサイズを「何もしないプログラム」で専有します。Cortex-M0+マイコンは、同一処理では他マイコンよりも小さいコードを生成しますが、それでも少ない残り量です。追加開発する処理量にもよりますが、30%以下を一応の目安とすると、LPC810にはLPCCloseライブラリを使う方が良さそうです。

一方、LPC810以外は、LPCOpenライブラリが使えそうです。LPCOpenライブラリは、評価ボード別やマイコン別の層構成になっていますので、LPCCloseに比べオーバーヘッドがある分、サイズが大きくなります。しかし個人的には、標準Cライブラリに近く洗練された感じがして好きなライブラリです。また、オープンな場で、使い方やバグ情報があるのも良い点です。勿論、層構成ですので、別マイコンやボードへの移植性も高いです。今後は、このLPCOpenライブラリが主流になると思います。

LPC8xxテンプレートをLPCOpenライブラリで開発したのは、このような経緯がありました。