NXP LPC8xxテンプレートV2.5改版

小ROM/RAM向けに従来マイコンテンプレートの必須機能のみを実装したTiny(小さな)テンプレートは、テンプレート本体処理が解り易いと好評です。ルネサスRL78/G10やSTM32Fxテンプレートには既に適用済みで、販売各マイコンテンプレートの改版を機に、順次この好評なTinyテンプレートへ変更したいと考えています。

LPC8xxテンプレートV2.5は、Tinyテンプレートの適用、対象マイコンの追加、シールドテンプレートの開発予告、この3つを目的に改版しました。

RL78/G10(ROM/RAM=4KB/512B または 2KB/256B)とLPC810(ROM/RAM=4KB/1KB)

小ROM/RAMで本ブログ対象のマイコンは、ルネサスRL78/G10とNXPのLPC810です。
※RL78/G10へ適用済みのTinyテンプレートは、コチラの投稿を参照してください。

16ビットのルネサスS1コアRL78/G10と違い、LPC810は僅か8ピンDIPパッケージですが、中身は32ビットARM Cortex-M0+コアですので、RL78/G1xのように500B以下でテンプレート実装はできません。

テンプレート本体は同じ単純なC言語ですが、機能させるための必須ライブラリ量が、ルネサス独自開発S1コアとARM Cortex-M0+コアでは大きく異なるからです。

そこで、LPC810テンプレートに限り前回投稿のコンパイラ最適化を“最適化なし(O0)”から“1段階最適化(O1)”へ変更したところLPCOpenライブラリv2.15利用debug configuration時、ROM=2460B、RAM=12Bに収めることができました(テンプレート応用例としてWDT:ウオッチドックタイマ制御は実装)。

LPC810 Template by LPCOpen v2.15 (Optimize -O1)
LPC810 Template by LPCOpen v2.15 (Optimize -O1)

残りのROM1.6KB、RAM1KBへユーザ処理を追加すればアプリケーション開発が可能です。この残り量でも、最適化(O1)の結果、結構なユーザ処理を記述できます。

LPC810は、入手性の良いNXP評価ボードがありません。そこでLPC810テンプレートのみは、上記1段最適化でコンパイル成功したLPC810テンプレートプロジェクトを提供します。LPC810独自開発ボードへの実装方法は、前回投稿を参照してください。

LPCOpenライブラリv2.15採用理由

LPC8xxテンプレートV2.5では、LPCOpenライブラリv2.15(2015/01/08)を用いました。主な採用理由は、2つです。勿論これ以外の開発環境は、最新版MCUXpresso IDE(v10.1.1_606)、Windows 10(1709)です。

  1. LPCOpenライブラリv2.15の方が、同じソースコードでもコンパイル出力が小さい
  2. 原因不明のリンカーエラーが発生する時がある

先に示したLPC810ソースコードでLPCOpenライブラリのみv2.19に変更した最適化結果が、ROM=3024B、RAM=16Bです。

LPC810 Template by LPCOpen v2.19 (Optimize -O1)
LPC810 Template by LPCOpen v2.19 (Optimize -O1)

また、v2.19では、v2.15でコンパイル成功するソースコードでも、下記原因不明のリンカーエラーが発生することがあります。

LPCOpen v2.19 Linker Error
LPCOpen v2.19 Linker Error

LPCOpenライブラリv2.19起因のこの1/2の現象は、同じソースコードでv2.15と比較しないと判明しません。

LPC8xxマイコン開発でつまずいている開発者の方は、是非LPCOpenライブラリv2.15で確かめてください。※LPCOpenライブラリは、v3系が最新版ですが、v2.9からのバグは継続していると思います。

LPC824(ROM/RAM=32KB/8KB)テンプレート応用例はシンプルテンプレート

LPC824は、十分なROM/RAM=32KB/8KBがありますので、MCUXpressoデフォルトの“コンパイラ最適化なし(O0)”でテンプレート実装ができます。

テンプレート応用例として、NXPのLPCXpresso824-MAX評価ボード実装の3色LEDとユーザSWで動作するシンプルテンプレートを提供します。Baseboardテンプレートは、LPCOpenライブラリバグのため、今回は提供を見合わせます。
※LPC824のLPCOpenライブラリバグに関してはコチラの投稿を参照してください。

LPCXpresso824-MAXは、Arduinoシールドコネクタを実装しています。ここへ今後のマイコン開発で必要性が高いSPIインタフェースのシールドを使ったテンプレート応用例の方が、Baseboardで応用例を示すより実用的だと考えています。これが、今回LPC824をシンプルテンプレートのみで見切り発車的に発売するもう1つの理由です。シールドテンプレートは、次版で提供予定です。

NXP LPC8xxマイコンテンプレートV2.5のまとめ

V2.5改版のLPC8xxマイコンテンプレート構成一覧を示します。

テンプレート名 対象マイコン(ベンダ/コア) テンプレート応用例 評価ボード:動作確認ハードウェア
LPC8xxテンプレートV2.5
(LPCOpen v2.15利用)
LPC810(NXP/Cortex-M0+) WDT実装(1段最適化プロジェクト) なし(テンプレートプロジェクト提供)
LPC812(NXP/Cortex-M0+) シンプルテンプレート
Baseboardテンプレート
LPCXpresso812
+ Baseboard
LPC824(NXP/Cortex-M0+) シンプルテンプレート
(シールドテンプレート※次版予定)
LPCXpresso824-MAX
(+SPIシールドテンプレート※次版予定)

前版V2.1と比べると、以下の特徴があります。※V2.2~2.4は、欠番です。念のため…。

  • 対象マイコンにLPC810とLPC824が加わり、LPC8xxテンプレートらしくなった(テンプレート本体はLPC8xxで共通)
  • テンプレート本体処理が解り易く、ご購入者様の応用や変更が容易となった
  • LPC824はテンプレート応用例がシンプルテンプレートのみだが、LPCXpresso824-MAX評価ボード単独で全ての動作確認可能
  • 今後LPCXpresso824-MAXのようなArduinoシールドコネクタ付き評価ボードは、SPIインタフェースシールドで機能拡張予定(従来はBaseboard機能拡張)

あとがき

マイコン内蔵周辺回路とGPIOをマトリクススイッチで接続するLPC8xxシリーズマイコンの狙いは、8/16ビットマイコンのARM32ビット置換え市場です。

そのためか、または前述のLPCOpenライブラリバグのためかは不明ですが、LPCOpenライブラリ利用よりもレジスタ直接アクセス方式のCode Bundleライブラリ利用がNXP推薦(SDK)です。

テンプレート本体は、利用ライブラリに依存しないC言語開発ですので、どのライブラリを利用しても適用可能です。しかし弊社は、他のCortex-Mシリーズコアと同様、LPC8xxシリーズもLPCOpenライブラリ利用が本来の開発姿だと思いLPCOpenライブラリのバグが取れるのを昨年から待っていました。

今回LPC8xxテンプレートV2.5への改版に際し、このバグ解消を待つよりも、LPC810とLPC824への対象マイコンを増やすこと、高速なSPIインタフェース利用テンプレートの開発予告の方が重要だと判断しました。

ベンダ提供のマイコン評価ボードは、Arduinoシールドコネクタ付きが一般的になりました。弊社も従来のBaseboard応用例よりも、SPIシールドを利用したテンプレート応用例の提供へ移行します。SPIインタフェースの重要性はマイコン技術動向(SPI/I2C)コチラの投稿を参照ください。

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

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

NXP LPC8xxの2017年ロードマップ

ARM Cortex-M0+で8/16ビットマイコン置換え市場を狙ったNXP LPC8xxの2017年ロードマップが公開されました。LPC1700の後継機LPC54000のロードマップと共に下記に示します。

LPC8xx Roadmap
LPC8xx Roadmap(サイトより抜粋)

※LPC1700とLPC54000は本ブログ対象外ですので、説明は割愛します。

2017年のLPC8xx

現在LPC8xxシリーズラインアップが下記です。

LPC8xx Series Lineup
LPC8xx Series Lineup

ピン数が少なくても多様なIOを構成できるスイッチマトリクスを持つCortex-M0+マイコンです(スイッチマトリクスについては、過去のLPC8xxブログ記事などを参照してください)。

ロードマップを見ると、ROMを増やす方向のLPC84xと、動作速度を下げる方向のLPC80xが2017年に発表されます(他のLPC8xxシリーズは、1.8V-3.6Vで30MHz動作)。速度低下に伴って、動作電圧も下がるかは不明です。

NXPは、QUALCOMMに買収されましたが、2017年ロードマップにLPC8xxが示されたことは、スイッチマトリクスが好きな私にとって好材料です。

掲載サイトには、2017年3月リリース予定のMCUXpressoのことも掲載されていますが、特に新しい情報はありませんでした。

Cortex-M0/M0+/M23

11月10日の記事記載のように、IoTデバイス向けに「セキュリティ強化のCortex-M23」と、従来「8/16ビットマイコン置換えのCortex-M0/M0+」の2つにCortex-M系の低コストマイコンも使い分けが必要な気がします。

IoTデバイスは、今のところ無線通信方式に決めてが見つかりません。そこで、適用市場が明確なCortex-M0+の新製品を先行して投入するのがNXPの作戦ではないでしょうか?

米Qualcomm、NXPを300億ドルで買収か?

2015年、Freescaleを買収したNXPを、スマートフォンで有名なクアルコムが300億ドル以上で買収するかもしれないというニュースが飛び込んできました。

記事によると、買収目的は、スマホ市場の成長が停滞しつつあるので、組込と車載市場へ参入することで、買収が成立すれば、半導体業界史上、最大規模のM&Aになるそうです。

クアルコム製品でスマホによく用いられているSnapdragonを使ったシングルボードコンピュータ:SBCは、チップワンストップのコチラで参照できます。

個人的観測ですが、このところNXPに限らずマイコンベンダーの新製品開発が鈍っている気がします。IoT無線規格の見極めや、Eclipse Neon対応かなと思ってきましたが、業界再編の可能性も影響しているかもしれません。

新生NXPマイコンラインアップ

NXPがFreescaleを買収後、新生NXPのARMコアMCU製品ラインアップが一目で解る図を見つけたので掲載します。
出典は、組込みシステム向けコンテンツ・プロバイダ)インスケイプ様のマガジンVOLUME.13:「さらなる高みへ。新生NXPのマイコン戦略に迫る MCU約1,100ラインアップ。シナジー効果の最大化へ」です。

NXP+FreescaleのARM Cortex MCUラインアップ

NXPサイトは、NXPのLPCマイコンと旧FreescaleのKinetisマイコンがそれぞれ別ページで示されるので、経営統合後のARM Cortex MCU製品ラインアップが分かりにくいのが現状です。

既存ユーザにはページ分離記載で問題ないでしょうが、以前記載した今後を予想するには、下図が解りやすいと思います。

NXP ARM Cortex MCU Lineup
NXP ARM Cortex MCU Lineup(記事より抜粋)

左側の汎用MCUでは、Cortex-M0/M0+でLPC800、LPC1100/1200とKinetis Lシリーズが競合しています。IDEも、それぞれのMCU対応にLPCXpressoとKinetis Design Studioの2種を提供中です。
一方、右側の特定用途MCUでは、Kinetisシリーズにより製品補完がされたことが解ります。

出典記事に、各MCUの詳しい特徴が解りやすく記載されております。

統合により、NXPは、ARMコア提供数は(恐らく)世界最大で、MCUコアのデファクトスタンダードCortex MCUのリーダーです。今後の動向が気になります。

CortexーM0/M0+対応マイコンテンプレート

弊社は、コスト重視で8/16ビット市場の置換えを狙う32ビットMCUコアCortex-M0/M0+を使ったLPC8xx、LPC111x、Kinetis Eに対してマイコンテンプレートを販売中です。動向によっては、このラインアップも変わるかもしれません。

※Kinetis Lシリーズは、Kinetis Eとソフト、ピン互換性があります。Kinteis EテンプレートのLシリーズへの適用は、弊社へお問合せください。

NXPとCypress動向

NXPは2015年にFreescale、Cypressは2014年にSpansionを買収しました。買収後のNXPとCypressのマイコンラインアップがどう変わるかが気になります。
日経テクノロジーOnlineで両社のマイコン新製品と今後の開発動向に関する記事がありましたので、要点をリストアップしました。

NXP: LPCとKinetisを徐々に統合

“新生NXP初のマイコン、旧NXP系で低消費電力がウリモノ” 2016/02/24より

  • NXPのマイコンシェア、車載MCUは世界第2位、車載を除くMCUは世界第1位
  • LPCマイコンと(旧Freescale)Kinetisマイコンは、徐々に統合(Geoff Lee氏談)
  • 新製品は、NXP系のLPC54000シリーズ(Cortex-M4FでコプロセサにCortex-M0+搭載可)

弊社マイコンテンプレートで使った、NXPのLPC8xx/LPC111xと旧FreescaleのKinties Eも現在NXPから全て供給中ですが、統合される可能性があることが解ります。

Cypress: PSoC 4へCortex-M0+コアを採用

“FMマイコンもPSoCも同じツールで開発、Cypressがアルファ版をデモ” 2016/02/29より

  • 新製品PSoC 4 Sは旧Spansionライセンス取得のCortex-M0+を採用。今後新開発PSoC 4もM0+を使う
  • PSoC 4 S搭載の第4世代CapSenceは、第3世代比、雑音耐性向上と低電力化
  • PSoC 4 S Pioneer Kit ($49)、PSoC 4 S Prototyping Kit ($10)発売
  • PSoC CreatorでFM0+マイコン(旧Spansion)も開発できるよう強化中

Cortex-M0+とM0を比較すれば、M0+が優れているので、新開発のPSoC 4系にM0+を採用するのは理解できます。
数あるマイコンIDEの中で私が最も使いやすいと評価するPSoC Creatorですが、PSoC 4とFM0+はアーキテクチャが異なり、さらにPSoC 4系にM0+が採用されれば、ますますFM0+を使う機会は減ると思います。
通常のマイコンソフト開発では、M0+とM0を区別することも少ないので、Creator強化は静観したいと思います。

LPCXpressoにTerminate, Build and Debugボタン追加

Terminate, Build and Debug Button
Terminate, Build and Debug Button

LPCXpressoが7.7.2 (build 379)に更新され、Terminate, Build and Debugボタンが新たに追加されました。

デバッグ中にソース修正を加えた場合、一旦デバッガ接続を切り離した:Terminateボタン後、Buildボタン→Debugボタンを押していた従来方法が、このボタン1個でできるように改善されました。

マイコンテンプレート活用のアプリケーション開発(後半)

マイコンテンプレートを使ったアプリケーションの開発方法(後半)は、手順4:サンプルソフトのテンプレートへの組込みとデバッグ、複数サンプルが同時に動くしくみを解説します。

アプリケーション開発手順(再掲)

アプリケーション完成までの手順1~3の詳細は、(前半)に記述済みです。

  1. 対象動作の明確化
  2. サンプルソフト獲得
  3. サンプルソフトを初期設定とループ処理の2つに分けて解読し、部品化
  4. 部品のサンプルソフトをテンプレートへ組込み、デバッグ

サンプルソフトとテンプレートの構造

サンプルソフトを組込んだテンプレート構造
サンプルソフトを組込んだテンプレート構造

ルネサスのRL78/G13アプリケーションノート:R01AN0451JJ0301をサンプルソフトにした例で説明します。サンプルソフトは、初期設定とループ処理から成ります。hdwinit()が初期設定、main()がループ処理です。このアプリノートでは、無限ループ内でスイッチ入力:P0と、LED出力:P1を同時に行っています。詳細は、R01AN0451JJ0301を参照して下さい。

サンプルソフトのループ処理
サンプルソフトのループ処理

このサンプルをテンプレートへ組込んだテンプレート構造が右側です。テンプレートでは、スイッチ入力処理と、LED出力処理は、別々に起動します。このテンプレート構造から、これら以外の別サンプルN処理や、割込み起動のサンプルX/Y処理が追加可能なことが判ります。例えば、ブザ音の発生処理などをここへ追加すると、簡単に処理の追加ができます。
つまり、テンプレートは、「複数処理を起動する仕組みを、初めから持っている」のです。ここがサンプルソフトと最も異なる点です。
スイッチ入力とLED出力を分離したのは、スイッチの入力スキャンタイミングを、チャタリング対応で簡単に変更することが目的です(補足参照)。

テンプレートに付属している「シンプルテンプレート」が、このスイッチ入力とLED出力を組込んだテンプレートに相当します。また、更に、LCD表示やI2C入出力などの、組込みマイコンに必要となる処理をほぼ全て加え、完成形の形にしたのが、「メニュードリブンテンプレート」です。

マイコンテンプレートの仕組み

  • サンプル初期設定は、丸ごとそのままテンプレート初期設定へ流用 → 複数サンプルの初期設定は、挿入順にそのまま実行
  • 時分割で複数の無限ループ生成 → サンプルの起動関数追加により、複数処理を実行
  • サンプル割込み処理は、そのままテンプレート割込み処理へ流用 → 複数の割込み処理時は、割込み優先順位に注意
  • 関数の引数は、インタフェースRAM経由 → 関数入出力確認がRAMでできるので、単体/結合デバッグ、処理の部品化が容易

インタフェースRAMのメリットは明らかです。例を示します。上記テンプレートに、スイッチに応じてブザ音発生処理を追加するとします。

スイッチ入力処理で、スイッチ入力結果をRAMへ出力します。ブザ音発生処理は、このRAMを参照し、音を発生させます。RAMインタフェースを使えば、どちらの処理もRAMで動作が分離され、そのRAM値により処理が正しく動作しているかが解ります。RAM値は、デバッガで変更やモニタもできますので、処理単体デバッグが簡単です。仮に、片方の処理が未完成であっても、RAM設定/モニタで結合デバッグもできます。

ブザ音処理の追加前と後で、スイッチ入力処理には影響が無いことも判ります。つまり、処理の部品化も可能です。

割込み処理は、優先順位に注意が必要です。テンプレートは、時分割ループ生成のために、SysTickタイマと呼ばれるタイマを使います(その名が示すように、システムのチックタック動作タイマ)。SysTickタイマの割込み優先順位は高く、サンプルで割込み処理が使われても、このSysTickタイマよりは低い優先順位です。

注意が必要なのは、複数サンプルの割込み処理をテンプレートへ追加する場合です。割込みには、デフォルト優先順位があります。このデフォルト順位で処理できるか、変更が必要かの検討が必要です。
デフォルト順位でOKなら、そのままテンプレートへ流用します。変更する場合は、マイコンに依存しますので、データシートを参照して順位を変更してください。

RL78/G1xタイマの検討優先順位設定に関しては、過去のブログ記事を参照してください。

アプリケーション開発手順4のまとめ

  • サンプルソフト初期化関数は、そのまま丸ごとテンプレート初期設定へ挿入
  • サンプルソフトのループ処理は、サンプル起動関数を適切なテンプレート時分割ループへ挿入
  • サンプルソフトの割込み処理は、割込み優先順位に注意し、テンプレートの割込み処理へ挿入
  • 関数間は、部品化のため、RAMインタフェースを使い、単体/結合デバッグを行う

テンプレートですから、部品化した関数の挿入でアプリが完成します。また、部品の再利用を容易にするため、部品単位でファイル化します。複数の割込み処理は、優先順位に注意し、必要なら設定を変更します。関数間は、RAMで切り離し、関数単位でのデバッグを容易にします。

テンプレートを使うと、開発者毎に異なるアプリ開発手法が統一でき、また、処理がファイル単位で部品化できますので、流用性や可読性も良くなります。

マイコンテンプレート販売中

前半、後半と長い説明になりましたが、マイコンテンプレートを使ったアプリケーション開発手順を示しました。シンプルテンプレート、メニュードリブンテンプレートが付属した、4種類のマイコンテンプレートを、各1000円(税込)で販売中です。

IoT向き省電力マイコンのLPC824は、2015/04Eに加わる予定です。

テンプレート名
(MCUコア)
対応マイコン
(ベンダ)
評価ボード:動作確認ハードウエア ブログタグ
RL78/G1xテンプレート v3.1
(RL78-S2/S3
RL78/G13
RL78/G14
(Runesas)
・BB-RL78G13-64(推薦ボード)
・G13スタータキット
・G14スタータキット
・QB-R5F100LE-TB
・QB-R5F104LE-TB
RL78/G13
RL78/G14
LPC8xxテンプレート v2.1
(Cortex-M0+
LPC812
LPC824
(NXP)
・LPCXpressoLPC812 + Baseboard
・LPCXpresso824-MAX + Baseboard
LPC812
LPC824
LPC111xテンプレート v1.1
(Cortex-M0
LPC1114
LPC1115
(NXP)
LPCXpressoLPC1114 + Baseboard LPC1114
Kinetis Eテンプレート v1.1
(Cortex-M0+
Kinetis E
(Freescale)
FRDM-KE02Z40M Kinetis E

 

テンプレートソースをご覧になれば、文書で示したものよりも、より直接的にテンプレートの処理内容がご理解いただけると思います。
また、テンプレート本体とサンプルソフト流用部分のソース間には、5行以上のスペースを入れ、視覚的にもテンプレートと流用部分の切れ目が判る工夫をしています。
サンプルソフト流用部分は、オリジナルの英語コメントですが、テンプレート本体は、日本語コメントで(冗長に?)説明を加えています

概要と仕様の説明資料は、マイコンテンプレートサイトから無料ダウンロードもできます。

テンプレートは、処理が何もない時は、Sleepする消費電力低減機能や、WDT:ウオッチドックタイマ処理、テンプレート本体の暴走監視機能など、アプリとして最低限必要な機能も実装済みです。

零から始めるアプリ開発に比べ、実務に直結した弊社マイコンテンプレートを活用して頂ければ、マイコンの習得と、可読性、流用性に優れたアプリケーションの早期開発ができます。是非、ご検討ください。

 

補足:スイッチ入力処理のチャタリング対応

サンプルソフト:R01AN0451JJ0301は、スイッチ入力処理にチャタリング対応がありません。マイコンの入力処理には、チャタリングに対するノイズ対策は必須です。ソフトウエア対策として、複数回スキャンし、入力が同値の時に、値を確定する方法が一般的です。弊社シンプル/メニュードリブンテンプレートは、この方法を採用しております。

この処理には、何回一致を判定するか、スキャンタイミングはどの程度か、の2パラメタがあり、使用スイッチに応じてこのパラメタを決める必要があります。弊社では、2回一致、10msタイミングで、タクトスイッチ入力処理を行っています。

テンプレートでご利用の実際のスイッチに応じて、これらパラメタ、特に回数のパラメタを変更すると効果が高いと思います。

マイコンテンプレート活用のアプリケーション開発(前半)

マイコンのアプリケーション開発方法として、マイコンテンプレートを使った方法を前後2回に分けて示します。
テンプレートを使えば、マイコン習得と可読性、流用性に優れたアプリが素早く開発でき、開発者毎に異なる開発手法も統一できます。
前半は、アプリケーション開発手順1~3を解説し、次回、後半で手順4を解説します。

アプリケーション開発手順

動くアプリ完成までの手順を示します。

  1. 対象動作、「何を、どうするか」を明らかにする。この段階では、細かいことを気にする必要はありません。例えば、スイッチをスキャンする程度で十分です。
  2. サンプルソフトを探す。メジャーなマイコンは、必ず多くのサンプルソフトをベンダがサイト公開しています。この中から対象動作のサンプルを探します。
  3. サンプルソフトを読む。サンプルソフトは、「初期設定処理」、次に「ループ処理」の2構成で記載されるものが殆どです。たまに、メニュードリブン形式もありますが、これは、弊社メニュードリブンテンプレートと同様、処理抜出を容易にすることを目的にしたものです。
  4. サンプルソフトの必要部分をテンプレートへ組込み、デバッグ。

以上で、アプリが完成します。

マイコンの場合、組込み後、チューニングが必要な場合もありますが、アプリ完成後の処理ですし、アプリにも依存しますので、先ずは、動くアプリ完成までの手順を示しました。

RAD: Rapid Application Developmentツールを使う場合は、2のサンプルソフトをサイトから探す代わりにRADツールを使ってサンプルソフトを生成すると考えれば良く、同じ手順となります。

サンプルソフトベースの部品化

対象動作は、スイッチ入力処理、LED出力処理などできるだけ細かく分割し、部品化することがポイントです。
最後に、これら部品を組み合わせて1つのアプリケーションにします。部品毎にサンプルソフトを見つけ、デバッグすれば、バグもこの部品内に閉じ込めることができます。また、部品単位の流用性も高まります。

サンプルソフトを組合せてアプリケーション開発
サンプルソフトを組合せてアプリケーション開発

上級者との差が出る箇所と対策

手順1~3で重要なことは、「対象動作の明確化」と、「サンプルソフトの分離読解」です。分離解読とは、初期設定とループ処理を明確に分離して解読することで、処理内容は、大体把握すれば十分です(後述サンプルソフトの読み方参照)。

上級者は、多くのサンプルソフトを経験しているので、的確に対象動作を絞り込め、分離解読が、早く深い点が違います。さらに、上級者は、個人的なテンプレートを既に持っているので、サンプルの流用、組込みとデバッグが効率よくできます。

弊社マイコンテンプレートを活用すると、

  • サンプルソフトの組込みが簡単な、テンプレート獲得
  • 処理単体/結合デバッグが簡単で部品化も容易な、RAMを使った処理インタフェースの獲得

ができますので、上級者との差分を誰でも補えます。

サンプルソフトの選出

何回かサンプルソフトを読むと、より明確な対象動作が選べるようになります。逆に、サンプルソフトが見当たらない時は、絞り込みが不完全、または対象が間違っていると言えます。初めに全てのサンプルソフトをざっと眺めた後で、アプリをイメージするのも良い方法です。

但し、スイッチ入力処理は、注意が必要です。スイッチには、チャタリング対策が必須です。この対策は2つあり、1つがハードウエア、もう1つがソフトウエアの対策です。両者併用もあります。
個人的には、ハード対策の有無に関係なく、ソフト対策は必要と考えます。弊社シンプルテンプレートでチャタリング対策済みのスイッチ入力処理を添付しているのは、この理由からです。
チャタリングは、使用するスイッチでタイミングが異なりますので、対策済みサンプルをベンダは提供しにくいと思います。チャタリングに関しては、以前のブログ記事や、ネット検索すると、多くの情報がありますので、そちらも参照して下さい。

サンプルソフトの読み方

サンプルソフトは、「木を見て森を見ず」にならないように、細かいことは気(木?)にせずに、初期設定とループ処理の2つに分けて読みます。

初期設定は、コメントに注意し、周辺回路の使用方法が開発するアプリと同じがどうかを見極めます。同じなら、丸ごとそのままテンプレートへ流用します。異なる場合は、データシートなどで変更箇所を特定し、実際にサンプルに変更を加え、結果が正しく動作することを確認しておきます。

ループ処理は、無限ループで処理するものと、割込みで処理するものに大別できます。割込み処理は、基本的にそのままテンプレートへ流用します。
無限ループ処理は、何をトリガにアプリを起動しているかが解れば十分です。多くの場合、フラグポーリングやカウンタなどです。この起動トリガで関数化し、テンプレートへ組込みます。

テンプレートの狙い:複数サンプルソフト流用

よほどの上級者やツワモノを除けば、アプリ開発は、サンプルソフトの流用が王道です。敢えてリスクをおかしてサンプルソフト以外の方法でマイコンを動かす必要はないからです。ベンダサンプルは、典型的動作ですので、先のスイッチ処理の例外を除くと、流用可能なものが多いのも理由です。

但し、サンンプソフトは、1個の周辺回路の動作説明が主なので、実際のアプリで必要となる複数の周辺回路を組合せる記述はありません。これが、開発者毎に手法が異なる原因です。弊社テンプレートは、これに対して1つの解を提供します。

弊社マイコンテンプレートは、サンプル処理の流用が簡単で、複数サンプル処理を組込むのも容易です。従って、サンプルを活かした動くアプリの早期開発ができます。また、本テンプレートを用いれば、開発者毎で異なる開発手法を統一でき、可読性や流用性も高まります。次回、後半で詳細を説明します。

アプリケーション開発手順1~3のまとめ

  • 細かい単位の対象動作サンプルソフトを見つけ、初期設定とループ処理の2つに分けて読む
  • サンプルソフトを部品と見なし、複数部品の組合せでアプリケーションを開発
  • サンプルソフト獲得方法は、ベンダサイト、RADツールがある

次回は、手順4の部品化したサンプルソフトのテンプレートへの組込みとデバッグ、複数サンプルが同時に動くしくみを説明します。

 

補足:チューニングとマイコン性能

アプリケーション開発で最も厄介なのは、実はチューニングです。

アプリに最適なマイコンを選定していれば、一部アセンブラ化などのチューニングなしで動くアプリができます。しかし、この選定失敗、もしくは、選定マイコンが古いのにアプリ追加などで、性能を絞り出す場合などの、最後の手段としてチューニングもありえます。
但し、苦労してチューニングしても、トラブルフリーの経験がないので、絶対に避けるべきだと思います。結局、高性能マイコンへの置換えという結果になります。

では、マイコン性能はどの程度が正解でしょうか? マイコンでシステムを制御する場合、通常アプリ以外の処理ソフト、例えば、ハード/ソフトの出荷時のセルフテストや、入力が一定時間ない時のデモンストレーション表示なども必要です(自動販売機などでおなじみですね)。ここでは、これらソフトを「システム運用ソフト」と呼びます。

これらシステム運用ソフトは、通常アプリ動作中には、並列処理をしませんので、消費するのはROM/RAMです。ソフト開発者は、ROM/RAM量を見積もる時に、これら通常動作には現れないシステム運用ソフトも考慮する必要があります。経験では、通常アプリと同程度、つまりトータル2倍のROM/RAMは必要と思います。

また、必要となるマイコン性能は、通常アプリと、上の例で示したようなシステム運用ソフトの両方で考慮すべきです。処理能力に十分な余裕がないと、再現性のない取れにくいバグ発生のリスクも高まります。この処理能力も、2倍程度の余裕が必要だと思います。

ハードウエア設計の「ディレーティング50%」と同様、2倍の余裕がマイコン設計には必要と思います。