LPC8xx アーカイブ - 7ページ目 (8ページ中)

マイコンテンプレートの骨格

2014年7月18日2014年10月11日 WithHappy

Wordには、名刺、カレンダー、パンフレットなどアプリ毎のテンプレートが用意されています。マイコンテンプレート開発時に悩むのが、どのようなアプリを意識してテンプレートを作るかです。できるだけオールマイティなテンプレートが目標です。

今回は、弊社マイコンテンプレートの骨格について説明します。

テンプレートの骨格

弊社マイコンテンプレートは、

（１）無償IDEのプログラムサイズ

（２）時分割の処理起動

（３）RAMでの関数間パラメタ渡し

（４）UARTメニュードリブン

の4つの骨格を持ちます。

（１）無償IDEのプログラムサイズ：弊社テンプレートは、IDE無償版で開発できるプログラムサイズを対象とします。これは、この程度が個人や少人数で開発/デバッグできる限界と考えるからです。これ以上大きくなると、開発/デバッグが指数的に困難となり、開発を収束させるために、例えばリアルタイムOSなどの別手段が必要になります。

最近は、無償版でも256KB程度の十分大きなサイズも開発できるようになりました。これは、IDEツールが高機能になり、API関数の自動生成や、既存ライブラリを簡単に使えるためです。これらIDE生成関数は、バグなしの完成品ですが、個人でカスタムメイドできるサイズは、今も昔もあまり変わらないと思います。経験的に無償IDEで開発できるサイズがこの上限サイズです。

（２）時分割の処理起動：マイコンは、CPUと周辺回路が「ハード的に並列動作」します。従ってCPUソフトを、周辺回路起動と処理完了確認の2つで関数化すると、複数の周辺回路を簡単に並列動作させることができます。起動から処理完了までの処理時間は、周辺回路毎に予想できますので、その間に別処理、例えばSleepをすれば電力効率もアップします。これらの処理を時分割で起動するのが弊社テンプレートです。

（３）RAMでの関数間パラメタ渡し：カスタムメイド関数のパラメタは、内蔵RAMを使って外部と入出力します。これで関数単体デバッグが簡単になります。RAM値をデバッガで確認/修正すれば、関数動作が把握できるからです。さらに、関数の中身が未完成の時でも、入出力値をRAMに設定しさえすれば、結合デバッグができるメリットもあります。

（４）UARTメニュードリブン：シリアルポートUARTを持たないマイコンはありません。Wi-FiやBluetoothモジュールをこのUARTへ接続すれば、ワイヤレス制御もできます。シリアル-USB変換ケーブルでマイコンとPCを接続し、メニュー形式で処理を選択するメニュードリブンをテンプレートに採用する理由は、2つあります。１つが、この「UARTが必ずあり、応用範囲が広い点」です。

もう1つが、メニュードリブンで開発すると「処理の移植が容易な点」です。テンプレート利用者は、メニューで示された処理のうち、必要な処理のみを簡単にテンプレートソースから見つけることができます。所望処理がUART受信コマンド解析関数から始まるからです。

そして、発見した関数（または関連関数）を、丸ごとご自身のソースへコピーすれば、動作させることができます。テンプレートは、多くの場合、この処理単位でファイル化していますので、ファイルを丸ごとコピーしさえすれば、必要な処理をテンプレートから抜き出すことも可能です。

評価ボードで実動作確認

入手性が良く低価格な評価ボードで、これらの骨格をもつテンプレートをボードへ実装し、動作確認を行い、詳細な説明資料付きで販売します。説明資料付きのテンプレートと評価ボードの組合せは、効率的に対象マイコンを習得でき、新規アプリ開発と評価に役立ちます。

販売テンプレートと開発テンプレート

現在、2種のテンプレートを販売中で、2種を年末までに開発、発売予定です。開発経過などを本ブログに記載しますので、ご参照ください。価格は、各1000円（税込）/１コピーです。

テンプレート名	ベンダ	マイコン	動作確認評価ボード
RL78/G1xテンプレート Ver3	ルネサス	RL78/G1x (32MHz)	・RL78/G13 Stick ・RL78/G14 Stick ・QB-R5F100LE-TB ・QB-R5F104LE-TB ・BB-RL78G13-64 （弊社推薦ボード）
LPC8xxテンプレート	NXP	LPC81x Cortex-M0+ (30MHz)	・LPCXpresso LPC812 + mX-BaseBoard
LPC1114テンプレート	NXP	LPC1114/5 Cortex-M0 (50MHz)	・LPCXpresso LPC1114 + mX-BaseBoard
Kinetis/Eテンプレート（開発中）	freescale	Kinetis Eシリーズ Cortex-M0+ (40MHz)	・FRDM-KE02Z40M + mX-BaseBoard

ARMコア利用メリットの評価

2014年7月15日2014年10月29日 WithHappy

ARM Cortex-M0+コア利用のLPC8xxテンプレート発売で開発が一段落したので、Cortex-Mマイコンの現状を俯瞰して、今後の開発方針を検討します。

ARM Cortex-Mシリーズマイコンの特徴

ARM Cortex-M機種	一言で表すと…
Cortex-M0+	超低消費電力ハイパフォーマンスマイコン
Cortex-M0	低消費電力マイコン
Cortex-M1	FPGA組込み用マイコン
Cortex-M3	汎用マイコン
Cortex-M4	デジタル信号制御アプリケーション用マイコン

8/16ビットキラーマイコンのCortex-M0+

M0は、8/16ビットマイコンより高性能、高エネルギー効率、高密度コードを目指して開発された32ビットコア。M0+は、M0よりさらに電力効率を最適化したコア。どちらも8/16ビットマイコンの価格レベルで32ビット性能を提供中。M0+の性能は、0.93 DMIPS/MHzで、M0の0.9 DMIPS/MHzより高性能。M0+は、M0命令セットと互換性あり。ARM Cortex-M開発ツールは、Eclipseベースとすることで、ベンダが異なっても開発環境を統一。ARM提供のCMSISを使うと、Mシリーズコアとベンダハードの差を隠ぺいすることができ、ソフト流用性も高まる。

世界定番ARMマイコンの最初のテンプレート開発にCortex-M0+を選んだ理由が、上記です。

これらCortex-Mシリーズの特徴は、ベンダやマイコン機種が変わると、一から開発環境構築やその習得、コアハードの熟知が必要だった従来マイコン開発に比べ、ベンダ/機種横断的に経験や既存資産を活かしたソフト開発が期待でき、利用者側メリットが大きいことを示しています。ARM社の狙いもココでしょう。

そこで、この「ARMコア利用メリット」を実際に試すことを今後の方針とします。

NXPのCortex-M0+テンプレート → NXPのCortex-M0テンプレートへ移植

発売中のCortex-M0+/LPC8xxテンプレートは、ARMコアベンダとしては老舗のオランダ）NXPのCortex-M0+マイコンLPC820を使ったテンプレートソフトです（写真参照）。NXPは、多くのMシリーズ製品を提供中です。そこで、このM0+テンプレートをM0機種へ移植することで、「同じベンダでCortex-M0+からM0への変更時のARMコア利用メリット」を検証します。

NXPのCortex-M0+テンプレート → フリースケールのCortex-M0+へ移植

ARMコアマイコンベンダとしては後発の米）freescaleのCortex-Mマイコンは、2014年7月現在、後発ゆえに特徴がきわ立つM0+とM4の2機種を提供中です。そこで、Cortex-M0+/LPC8xxテンプレートを、フリースケール製M0+マイコンへ移植することで、「異なるベンダでCortex-M0+ソフト移植時のARMコア利用メリット」を検証します。

どちらの検証も、いろいろなマイコンを開発してきた自身の経験と比較し、「ARMコア利用メリットを享受できるか否かの主観評価」になりますが、ARM社の狙いが絵にかいた餅なのか、本当に役立つのかの参考になると思います。

なお、別途販売中のルネサスRL78/G1xテンプレートは、コチラを参照して下さい。

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

2014年6月28日2015年8月15日 WithHappy

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

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

従来ライブラリ：LPCCloseのUARTサンプルソフト、“uarttest.c”の最初の部分を抜粋しました。前記事に示したライブラリ利用の為に、コア制御に”LPC8xx.h”、周辺回路制御に、”lpc8xx_clkconfig.h”と“lpc8xx_uart.h”のヘッダファイルをインクルードした後に、サンプルソースを記述しています。このUARTサンプルは、UART初期設定後、PCへ”Hello world!”とUART送信し、PCからの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では正常動作しないことが判ります。

但し、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と従来ライブラリの使い易さ比較

2014年6月17日2015年8月15日 WithHappy

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

利用ライブラリ選定

LPCXpressoは、新プロジェクト作成時、プロジェクトウイザードで2つのライブラリ、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セクション参照）。

使い易さ比較

つまり、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ライブラリが利用できるように工夫します。

LPCXpresso_7.2.0_153リリース

2014年5月26日2015年8月15日 WithHappy

2014年5月20日、最新版LPCXpresso_7.2.0_153がリリースされました。販売中のLPC8xxテンプレートもこの最新版で動作確認済みです。

新旧LPCXpresso比較

このLPCXpresso_7.2.0_153では、新規プロジェクトをウイザードで作成した時に、メイン関数を生成するファイル名が、これまでのmain.cからproject.cへ変更になりました。例を示します。

SimpleTemplateプロジェクトを新規作成の場合	main()の場所
旧LPCXpresso生成ファイル	main.cファイル内にmain()あり
LPCXpresso_7.2.0_153生成ファイル	SimpleTemplate.cファイル内にmain()あり

但し、旧LPCXpressoで作成済みプロジェクトを、main.cファイル名のまま最新版でコンパイルしても問題なく動作します。そのため、旧版で作成した販売中テンプレートは、SimpleTemplateもMenuDrivenTemplateも「main.cのまま」にします。

これには、ユーザ追加ファイル名をPascal形式記述にすると、LPCXpresso生成ファイルは全て小文字表記となり、「一目で、LPCXpresso作成したのか自作かを見分けられる」というメリットもあります。左：旧LPCPressoの場合で説明すると、”Launcher.c”、”Led.c”、”Sw.c”、”Userdefine.h”がユーザ追加ファイル、それ以外が自動生成ファイルということが一目で判ります。

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

2014年5月23日2015年8月15日 WithHappy

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%
LPCOpen	CRP無効	38%	19%	9%
LPCClose	CRP有効	28%	14%	7%
LPCClose	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ライブラリで開発したのは、このような経緯がありました。

LPC8xxテンプレート（LPCOpen＋ROMライブラリ版）発売

2014年5月18日2015年8月15日 WithHappy

LPC8xxテンプレート（LPCOpen＋ROMライブラリ版）を￥1000（税込）で販売します。テンプレート概要と仕様は下記です。

テンプレートは、LED出力とSW入力のみを組込んだ「シンプルテンプレート」と、組込み必要機能をほぼ全て盛込んだ「メニュードリブンテンプレート」の2つをセットにし、もくじ内容のPDF資料添付で￥1000です。

購入ご希望の方は、メール（宛先:info@happytech.jp)にてお知らせください。銀行振込口座を返信いたしますので、税込代金￥1000円を振込でください。入金確認後、全解説ページとテンプレートプロジェクトをメールにてお送りします。後は、ご自由にテンプレートへ変更や修正を加えて頂いて、LPC8xxの習得、本来のアプリ開発に役立てて頂ければ幸いです。

「シンプルテンプレート」は、LPCXpressoプロジェクトファイルで、LED出力とSW入力のみの機能をプログラム済みで、LPCXpressoLPC820評価ボード単独での動作が可能です。

「メニュードリブンテンプレート」は、LPC820評価ボードにBaseBoardを接続し、I2C EEPROM、LCD、UARTなどの組込みマイコンに必要な機能をほぼ全て実装したテンプレートです。PC接続のメニュードリブン方式で作成したため、関数単位で移植性が高いソフトです（もくじP1動作中の写真、P5ファイル一覧、P10ハードウエア構成などを参照）。

テンプレートは、NPX/ARM社提供のLPCOpenライブラリ（V2.01）とマイコンROMライブラリを使っています。LPC8xxには、上記の他に、従来版ライブラリもありますが、本テンプレートは使っていません（もくじP8に詳細記載）。従来版ライブラリ使用のテンプレートも、近日中に開発、別売（予価￥1000）予定です。従来版ライブラリのテンプレートをご希望の方は、しばらくお待ちください。

Cortex M0+マイコンのLPC8xxは、8/16ビットマイコンの置換えを狙った、従来品より高性能な割込み専用回路や低消費電力、低価格が売りの、世界定番ARM32ビットマイコンです。本テンプレートと確実に動作する市販評価ボードを使えば、LPC8xx習得、早期アプリ開発や評価に最適な環境が得られます。

このテンプレート対象者は、初級～中級のソフト開発者です。上級者は、これに似たテンプレートを既に持っているからです。本来は、上級者がテクニックを含む自分のテンプレートを初級～中級者へ教え、教えられた側でさらに、テンプレートに修正を加えれば、技術継承も容易です。しかし、この継承は、習得済みの者にとっては、オーバーヘッドで、未習得の者にとっては、理解困難な面が多いものです。販売テンプレートには、詳細な資料が付いていますので、だれにでもその内容が理解できます。また、テンプレートソースには、「判りにくい英語ではなく、日本語コメント」を豊富につけていますので可読性も高いと思います。

PS:ルネサスのRL78/G1xマイコンのテンプレートもコチラで販売中です。

LPC820 vs. RL78/G13 割込みコントローラ比較

2014年4月26日2015年8月15日 WithHappy

NVICとRL78/G1xの割込みコントローラ比較

LPC820やCortex M0/M0+マイコンは、割込み処理性能を強化した新しいNVIC: Nested Vectored Interrupt Controllerを持っています。RL78/G1xは、4バンク構成の従来型割込みコントローラです。NVICは、これまでソフトで行っていた割込み処理を、殆どNVICハードで行います。頻繁な割込みに対する効率化（テール・チェイン）などにより、割込み応答時間が均一になり、高速処理が可能です。

CPU	LPC820	RL78/G13、RL78/G14
割込み回路	NVIC: Nested Vectored Interrupt Controller	Interrupt Controller
レジスタバンク	なし	4バンク（RB0/1/2/3)
レジスタ待避場所	スタック	バンクバンク使用時はスタック
PUSH/POP動作	ハード：NVIC処理（ソフト比、応答時間が均一で高速）	ソフト処理
多重割込み受付	デフォルト許可	デフォルト禁止（受付はソフトでEI設定要）
テール・チェイン機能	あり	なし
割込み優先レベル	4（高0/1/2/3低）、デフォルトレベル0	4（高0/1/2/3低）、デフォルトレベル3
ISR記述	規定ISR名でCソース記述（オーバーライド可能）	__interruptを付加し、規定ISR名記述（オーバーライド不可）

割込み起因のバグは、再現性が低く、デバッグが厄介なものです。定量的な評価はできませんが、NVICの謳い文句やこの比較表以上に、割込み処理に対して、有効になると思います。

I2C接続EEPROMの使用シナリオ

2014年4月7日2015年8月15日 WithHappy

前回の記事で問題にしたLPC8xxテンプレートI2CのAPIは、「LPCOpen」と「内蔵ROM」両方を使うことに致しました。UARTはLPCOpneを使うとデバイス最高速度30MHzで動作しますので、これでLPC8xxテンプレート開発を続けます。

さて、I2CのAPIを使ってテンプレートにどのような使用例を追加すべきかを検討しました。接続デバイスは、「I2Cインタフェースで最も利用が多いEEPROM、動作は、ページライト/シーケンシャルリード、保持データは、マイコン再起動時に必須となるデータ、例えば、電源断時のスイッチ状態」などとします。

これは、RL78/G1xテンプレートのデータフラッシュ使用例と同じです。RL78/G1xは、4KBのデータフラッシュを内蔵しており、様々な使い方ができます。私は、このデータフラッシュにEEPROM的な使い方を想定し、RL78/G1xテンプレートに実装しました。

LPC8xxには内臓データフラッシュはありませんが、IAP: In-Application Programmingという64バイトのページ（ページについては後で示す）を持つROM書込み/消去の機能があります。これを使うと、EEPROMの代用ができます。が、ROM自体をプログラムで書換えるのは、少し抵抗があります。従って、LPC8xxテンプレートにはIAPを実装しない予定です。代わりに、応用範囲の広いI2CにEEPROMを実装します。

I2C接続のEEPROM仕様

I2C接続の代表的なEEPROM仕様を示します。容量が大きくなると、ページデータ数が16、32、64、128バイトへ増えます。ページとは、纏めてライトする時の単位です。EEPROM書込み保障回数は、10万～100万回ですので、1バイト毎にライトする代わりに、ページ単位にデータを纏めてライトすると、ライト回数を減らせます。しかしその分、ページライト後に待ち時間も発生します。

リードは、最後にライトしたアドレスのデータを読む、カレントアドレスリードが基本です。任意アドレスリードは、ライトデータを0にしたダミーライトを行い、カレントアドレスを再設定した後で通常リードをします。カレントアドレスから、最大アドレスまでのシーケンシャルリードが可能です。

EEPROM使用シナリオ

これらリード/ライト方法や仕様を俯瞰すると、EEPROMに保存するデータは、ページ単位が適していることが判ります。また、使い方は、マイコン起動時、最後にEEPROMにページライトしたデータをリードしマイコン運用、これらデータ更新時に、更新データを一塊のページ単位でEEPROMへライトし、再起動に備えるなどを想定します。そこで、このシナリオでLPC8xxテンプレートに実装します。

API利用マイコンプログラミング

2014年4月1日2015年8月15日 WithHappy

3種類のAPIライブラリ

LPC8xxマイコンプログラミングのAPIライブラリは3種類あります。以前記事のLPCOpenとLPCClose、加えてLPC8xx内蔵ROMでI2CやUARTのAPIを提供中なので3種類です。

API提供ライブラリ	状況（2014年3月現在）
LPCOpen：Lpc_chip_8xx_lib	I2C関連のi2c_8xx.cは、clock enable/disableのみ、他は未実装（V2.01版）
LPCClose：Lpc800_driver_lib	全API提供中（2012/12/18版）
内蔵ROM	UARTは、デバイス最高動作速度の30MHzで動作せず

2014年3月現在の各ライブラリ状況を示します。個人的に、LPC8xxテンプレートには、「LPCOpen」を使いたいと考えてきました。しかし、最大動作速度30MHzでのテンプレートには、「LPCClose」を使わざるを得ないようです。少ピンLPC8xxの活用には、I2Cインタフェースが重要ですが、LPCOpenライブラリI2C関連は未完成だからです。

私の推測ですが、ROM APIでLPCOpenのi2c_8xx.c未完成部分の代用ができますので、i2c_8xx.cはこのままの状態で落ち着く可能性があります。この場合の問題は、LPC8xx最高速度30MHzでROM APIが動作しない点です。

解決策は2つ。１つは、テンプレート30MHz動作をあきらめ、ROM APIが動作する最高速度24MHzに変更すること、もう1つがLPCOpenの代わりにLPCCloseを使うこと、です。世界標準のLPC8xxは、まだ新しいマイコンなので、状況が変わるまでしばらくは我慢も必要です。

API利用のマイコンプログラミング

開発中のLPC8xxテンプレートは、LPCOpenからLPCCloseへ使用API変更の可能性が出てきました。2つのライブラリを同時に使用することも考えましたが、ソースが煩雑になりますし、気持ちも悪いので止めます。

そこで、使用ライブラリの変更やライブラリ自身のバージョンアップに耐えられるプラグラミングについて検討します。その結果、2つの方法でAPI関数にアクセスします。

API利用方法	説明	使用例	API変更時
直接型	ユーザソースからAPI関数を直接コール	クロック設定など	エディタ一括変更
間接型	ユーザ前処理関数内でAPI関数をコール	I2C、UARTなど	前処理関数内のみ

「直接型」は、ユーザソースにAPI関数をそのまま記述する、本来なら一般的な方法です。これに対して、「間接型」は、APIコールの前に何らかの関連処理や前処理が必要な場合で、この処理を1か所に纏めユーザ関数化します。つまり、利用側のユーザソース→纏めたユーザ関数→API関数の順番にアクセスします。今回のような使用APIの種類変更時には、この関連処理を纏めたユーザ関数内のみの変更で済みます。直接型の変更は、エディタの一括変更などで対策します。

例を示します。I2Cマスタ送信API関数は、データの中身は無視して、送信バイト数分を、I2Cバスに送信します。一方、API利用側は、EEPROMとセンサデバイスなどでは、リード/ライトアドレス長が2バイト/1バイトと異なるので、それぞれ別のデータフォーマットを持ちます。そこで、このデバイス毎のデータとAPIフォーマット変換を前処理にして関数化します。I2C送信は、全てこの前処理関数を経由してI2Cマスタ送信APIを利用します。その結果、API変更の対策は、前処理関数内に閉じ込められます。

この方針でAPIを利用すれば、使用APIの変更やAPIバージョンアップに対しても、ユーザソースの変更箇所を集中させ、かつ、簡単に変更できます。