マイコンデータシートの見かた（その１）

2017年10月1日2017年12月20日 WithHappy

現役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と技術シナジー

2017年9月28日2017年9月29日 WithHappy

本ブログでも関心があった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は、残念ながら更新されていません。

BLEとThreadソフト開発者必見動画

2017年9月17日2017年9月17日 WithHappy

IoT通信規格のBLE 4.2とThread（802.15.4）両方をサポートするNXP）Kinetis KW41Z搭載の評価ボードを使ったBEL4.2とThreadメッシュ接続の開発Video（タイトルが以下Lesson 1～10）を紹介します。

BLEやThreadソフト開発者必見のLessons

内容、質ともに優れたVideoでMCUXpressoとSDKの使い方も良く解ります。特に興味深い内容とその出所が以下です。

Bluetooth ClassicとBluetooth Low Energyの本質的な違い（Lesson 3、3分ごろ）
Bluetooth ClassicとBLE間を接続するBluetooth Smart Ready（Lesson 3、6分ごろ）
BLE接続の具体例（Lesson 3、19分ごろ）
BLE/Thread接続に必要な知識（Lesson 3, 6）
Threadが生まれた背景（Lesson 6、2分ごろ）
Cortex-M0+/48MHz、512MB ROM、128KB RAM、FreeRTOSで実現するBLE/Thread IoT端末（Lesson 5, 9, 10）

BLEやThreadに関する情報は多くありますが、ソフト開発者の立場からは、本Lessonsが最も要領よくポイントをまとめています。

Kinetis KW41Z

Kinetis KW41Zの評価ボードは、以下の2種（Digi-Key価格）です。

Rigado製R41Z-EVAL $59.94
NXP製FRDM-KW41Z $145.00

低価格で有名なFRDM評価ボードですが、さすがに両プロトコル対応のKW41Z搭載ボードとなると$100以上します。Videoで使っているR41Z-EVALは、約$60と安く入手できます。但し、Lesson 10のBLEとThreadメッシュ切り替え接続の動作確認を行うには、同時に3台の評価ボードが必要です。

ThreadのみサポートのKW21、BLEのみのKW31もありますが、無線規格が乱立していて、どれが本命かを見極めるのが困難な現状では、両プロトコルサポートのKW41が安全でしょう。

API for IoT

MCUXpressoとSDKを使って、BLEまたはThread通信機能を持つIoT端末を開発する際に、プロトコルのどの部分の変更/修正が必要で、それがソース上のどこにあるか、全体の開発手順などはVideoを観ると良く解ります。

また、LEDなどのGPIO制御を行うSDKデモソフトとIoT通信の並列処理は、FreeRTOSを使って実現していることも解ります。簡単なIoT端末なら、このデモソフトに、外部センサ値をAD変換し、その変換データをクラウドのサーバーへIoT経由で送信する機能を追加しさえすれば、直ぐに開発できそうです。
※簡単なIoT端末は後述

BLEやThreadは、IoT通信の有力な候補です。しかし、IoTの通信プロトコルが何になるにせよ、IoT通信向けのAPIが決まれば、あまり気にする必要がない、というのが全Lessonを通しての私の感想です。

その理由は、デモソフト実装済みのGPIO制御はそのまま使えますし、FreeRTOSを使っていますので、外部センサ入力を定期的にADCする処理（ADCスレッド）と、ADC変換データをIoT通信APIへ出力する処理（IoT出力スレッド）の2処理を追加開発すれば良いからです。

ADCスレッドは、IoT通信規格には無関係です。一方、IoT出力スレッドは、Uart出力と同様のIoT APIが使える（用意される）と思います。NXP）LPC8xxマイコンのUart APIの例で示すと、Chip_UART_SendBlocking()が、Chip_IoT_SendBlocking()に代わるイメージです。IoT API利用条件が初期設定で満たされれば、ユーザは、通信速度や、通信プロトコルを意識せずにIoT通信を使えるようになると思います。

＊　　＊　　＊

IoT通信規格が不確定な状況で、少しでも早くIoTやRTOSに慣れるには、R41Z-EVALは良い評価ボードです。また、FreeRTOSを使えば、48MHz動作のCortex-M0+、512MB ROM、128KB RAMで簡単なIoT端末が開発できそうな見通しもこれらLessonは、与えてくれました。是非、ご自分でご覧になってください。

簡単なIoT端末のイメージ

データ入力とGPIO出力を行うMCU端末で、IoT無線通信機能を備える。通信セキュリティを確保できるAES-128などの機能も備え、対象機器から取得したデータを安全にクラウド内のサーバーへ送信する。
サーバーは、対象機器データを人工知能を使って予測分析し、結果を端末へ送信する。
端末は、受信結果を基にLEDなどのGPIO出力を行い、オペレータまたはロボットが対象機器メンテナンス作業の手助けをする。

STM32Fxテンプレート発売

2017年9月1日2017年9月2日 WithHappy

2016年MCUシェア第5位のSTマイクロエレクトロニクス（STMicroelectronics、本社スイス）のSTM32F0：Cortex-M0とSTM32F1：Cortex-M3向けのテンプレートを開発しましたので、販売開始します。従来テンプレートと同額の1000円（税込）です。

STM32Fxテンプレートの特徴

Cortex-M0とCortex-M3両コア動作のテンプレート
移植性、可読性が高いHALドライバを使ったので、他コアへの流用、応用性も高い
カウントダウンループを使ったCortex-M系コードテクニックで開発

従来テンプレートは、ARM Cortex-M0/M0+とルネサスS1/S2/S3コアが対象でした。

つまり、8/16ビットMCUの置換えを狙ったCortex-M0/M0+と、RL78汎用MCUへテンプレートを供給していました。しかし、IoTの通信処理や要求セキュリティを考慮すると、より高性能なMCUも視野に入れた方が良いと感じていました。また、Cortex-M3デバイスの低価格化も期待できます。

初めてCortex-M3のSTM32F103RB：NUCLEO-F103RBへもベアメタルのテンプレートを開発したのは、以上のような背景、理由です。

ST提供のHAL：Hardware Abstraction Layerドライバは、移植性、可読性が高く、Cortex-M0/M3両対応のテンプレートも簡単に開発できました。Cortex-M3よりもさらに高性能なMCUが、ベアメタル開発を行うかは疑問ですが、HALを使ったので適用できると思います。

動作確認評価ボードは、STM32F072RB：Cortex-M0/48MHzとSTM32F103RB：Cortex-M3/64MHzですので、これはあくまで私見、見込みですが…、HALドライバならば問題なく適用できるハズです。

HALドライバ作成にSTM32CubeMXを使うと、異なるコア動作速度（M0：48MHz、M3：64MHz）でも、同じ周辺回路ならば、同じHAL APIが使えます。

今日現在、このSTM32CubeMX周辺回路のGUI設定に関する詳しい資料が見当たりません。そこで、テンプレート添付資料では、テンプレートのSTM32CubeMX設定方法や、SW4STM32開発ヒントやTipsなど開発に役立つ情報を満載しています。初めての方でもSTM32MCUの開発障壁を低く出来ます。

また、本テンプレートをプロトタイピング開発に使って、MCU性能の過不足を評価するのも便利です。ボードレベルでピンコンパチなSTM32 NUCLEO評価ボードですので、評価ボード単位の載せ替え/交換も可能です。

さらに、デクリメントループを使ってループ終了を行っているなど、Cortex-M系のコード作成にも注意を払いました。

＊　　＊　　＊

マイコンテンプレートサイトへ、STM32Fxテンプレートを掲載します（9月2日追記：サイト更新完了しました）。
添付資料のP1～P3、もくじの内容を掲載しております。P1～P3は、資料ダウンロードが可能です。STM32Fxテンプレートをご購入の上、是非、ご活用ください。

STM32CubeMXの使い方Tips

2017年8月19日2017年8月20日 WithHappy

STM32CubeMXは、STM32Fxマイコンのコード生成ツールとして良く出来ています。但し、現状1つ残念なことがあります。HAL：Hardware Abstraction Layerに加え、BSP：Board Support Packagesをドライバとして出力しないことです。そこで、現状のHALドライバのみ出力に対策を加えます。

STM32Fxファームウエア構成

STM32Fxファームウエア構成が上図緑線の個所です。STM32Fxマイコンサンプルソフトは、使用するファームウエアライブラリに応じて、Low Layer examples、Mixed HAL & Low Layer examples、HAL examplesの3種類あります。

各ファームウエアの差や、サンプルソフトの場所は、以前記事で解説しました。ここでは、STM32F0からSTM32F1へのポータビリティが最も高いHALライブラリ（＝ドライバ）を使うサンプルソフト：HAL examplesに的を絞って解説します。

HAL Examples

このサンプルソフトの優れた点は、評価ボード実装済みの青SW（USER Blue）と緑LED（LD2）のみで全てのサンプルソフト動作を確認できることです。SW入力と、LED点滅間隔を変えることで、正常/NG/入力待ちなど様々なサンプルソフトの動作状態を表現します。

この青SWと緑LEDを制御するには、GPIO定義とHALライブラリを組合せた一種のサブルーティンがあると便利です。このサブルーティンが、BPS：Board Support Packagesです。例えば、下記などです。

BSP_LED_On()、BSP_LED_Off()、BPS_LED_Toggle()、BPS_PB_GetState()

BSP_が先頭に付いているので、一目で評価ボード実装済みの青SWや緑LEDを制御していることが判りますし、HALライブラリを使って表現するよりも、可読性もより高まります。BPSの中身は、HAL自身ですので、Drivers層のBSP、HALともに同じ黄緑色で表示しています。

HAL exampleは、これらBSPとHAL両方を使って記述されています。

STM32CubeMX

STM32CubeMXは、最初に使用する評価ボードを選択後、コード生成が行えます。

但し、生成コードに含まれるのは、HALドライバのみです。BSPは、HALサブルーティンですので、自作もできますが、評価ボードを選択するのですから、せめてHALのみか、それともHALとBSPの両方をドライバとして出力するかの選択ができるように改善してほしい、というのが私の希望（最初に言った現状の残念なこと）です。

もしHALとBPSドライバ両方がSTM32CubeMXで出力されると、多くのHAL Examplesを殆どそのまま流用できるメリットが生じます。HAL Examplesは、残念ながらエキスパートの人手で開発したソースですが、これを自動コード生成の出力へ、より簡単に流用できる訳です。

STM32CubeMX出力ファイルへのBSP追加方法

BSPドライバを自動出力しない現状のSTM32CubeMXで、上記希望をかなえる方法は、簡単です。

手動でBSPのstm32f0xx_nucleo.cとstm32f0xx_nucleo.hをSTM32CubeMX生成プロジェクトのSrcとIncフォルダへコピーし、main.cのL43へ、#include “stm32f0xx_nucleo.h”を追記すればOKです。
※stm32f0xx_nucleo.c/hは、\STM32Cube\Repository\STM32Cube_FW_F0_V1.8.0\Driversにあります。

たとえSTM32CubeMXで再コード生成しても、stm32f0xx_nucleo.c/hはそのままですし、追記した部分もそのまま転記されます。この方法で、HAL Examplesの流用性が向上します。

HAL Examplesを読むと、周辺回路の細かい設定内容が解ります。この設定をそのままSTM32CubeMXに用いれば、周辺回路の動作理解が進み、さらに自動コード生成ソースへ、Examplesソースをそのまま流用できるので、評価ボードでの動作確認も容易です。

まとめ

現状のSTM32CubeMXは、BSPドライバを出力しません。対策に、手動でBSPドライバを追加する方法を示しました。これによりエキスパートが開発したサンプルソフトを、より簡単に自動生成ソフトへ組込むことができます。

開発中の弊社STM32Fxテンプレートも、サンプルソフトを流用/活用が使いこなしのポイントです。そこで、このBPSを組込む方法をSTM32Fxテンプレートへも適用し、サンプルソフト流用性向上を図っています。

評価ボードNUCLEO-F072RB/F103RBのピン選択指針

2017年8月8日2017年8月8日 WithHappy

STマイクロエレクトロニクスの評価ボード、NUCLEO-F072RBやNUCLEO-F103RBを使って、ボード外部と接続する際の、ピン選択に関する指針を示します。

評価ボードのピン配置とSTM32CubeMXのピン選択

評価ボードには、外部接続用のピンとしてArduinoピン（ピンク色）と、NUCLEOボード独自のMorphoピン（青色）があり、Morphoピンの一部は、Arduinoピンと共用（赤囲み）です。2つの黄色マークは後述します（評価ボードのユーザマニュアルは、コチラを参照）。

Arduinoピンは、メスコネクタ、一方Morphoピンは、オスコネクタを使っており、ブレッドボードや弊社マイコンテンプレートで使うBaseboardとの接続には、Arduinoピンを使いオスーオス結線が便利です（Baseboardやオスーオス結線のメリットはコチラの記事を参照）。

評価ボードNUCLEO-F072RB （＝STM32F072RB）やNUCLEO-F103RB （＝STM32F103RB）を使う時のコード生成ツールが、STM32CubeMXです（STM32CubeMXはこちらの記事などを参照）。

STM32CubeMXは、MCUパッケージイメージから使用ピンを選択、設定します。色付きピンは、既に評価ボードで使用済みのピン、灰色ピンが未使用ピンです。

例えば、灰色ピンのPB7は、I2C 1＿SDA～GPIO＿EXIT7までの広い範囲で自由に機能を設定可能です。

STM32F072RBとSTM32F103RBは、どちらもLQFP64パッケージでピンコンパチです。緑色のB1 [Blue Push Button] :PC13と、LD2 [Green LED] :PA5の２ピンを評価ボードで使用しますので、前述の評価ボード接続ピンに、既に使用済みという意味で黄色マークを付けました。

長くなりましたが、ここまでが、前置きです。これらの前置きを知ったうえで、STM32CubeMXで自由に設定できる灰色ピンの内どれを使うと、効果的な評価ボード開発ができるのかを明らかにするのが本記事の目的です。

STM32CubeMXのピン選択指針

STM32F072RBやSTM32F103RBのソフト開発の場合、最初にSTM32CubeMXで使用ピンを決め、コード生成をします。もちろん使用ピンは、コード生成後も変更できますが、変更のたびに再コード生成が必要です。再コード生成の手間は、できれば避けたいです。

こんな時、ピン選択の指針があると便利です。

前置き情報から、Arduinoピンを使うと、ブレッドボードやBaseboardとの接続が、オスーオス結線で簡単、市販Arduinoシールドも使えることが判ります。そこで、Morpho ピンで、Arduinoピンと共用しているピンを昇順に抜粋すると、下記になります。

GPIOA：            PA0/PA1/PA2/PA3/PA4/PA5/PA6/PA7/PA8/PA9/PA10
GPIOB：            PB0/PB3/PB4/PB5/PB6/PB8/PB9/PB10
GPIOC：            PC0/PC1/PC7/PC9

GPIOAが多数ですが、Arduinoピン名をみるとA0などのアナログ入力ピンとの共用が多いので、デジタル入出力と思われるD0～D15での共用が多いGPIOBから先に割り当てる方針を立てました。

BaseboardとのLCD接続

この方針でBaseboardのLCDと接続し、LCD出力した例を示します。本方針が、LCD接続では有効であることが判ります。

まとめ

開発中のSTM32Fxマイコンテンプレートは、テンプレート応用例としてシンプル/Baseboardテンプレートの2つを添付します。シンプルテンプレートは、評価ボード単体で動作しますので、使用する外部接続ピンに悩む必要はありません。

Baseboardテンプレートは、評価ボードとBaseboardを接続して動作させますので、効果的な接続方法として、評価ボード外部接続ピンの選択指針を検討しました。

デジタル接続なら、Arduinoピンとのデジタル共用が多いGPIOBから選択し、アナログ接続なら、GPIOAから選択する指針を示し、この指針に基づいてBaseboardのLCDと接続し出力を確認しました。

追記

評価ボードのArduinoとMorphoの共用コネクタ部分の回路図を抜粋したのが下図です。

評価ボード裏面のジャンパー（回路図のSBxxなど）を、工夫（オープン/ショート）すると、ArduinoピンとMorphoピンの共用ピンをさらに変更できることが判ります。よく考えられた評価ボードです。

RL78ファミリのロードマップ

2017年8月3日 WithHappy

最新RL78 MCUファミリのカタログから、ルネサスRL78 MCUの開発ロードマップを抜粋しました。今後のRL78 MCUの方向性として、アナログ、センサ対応力強化が見えてきます。

RL78ロードマップと周辺回路の強化ポイント

ページ２ロードマップの赤字コメントは、ルネサスがその製品特徴を一言で表したキーワードです。緑色新製品MCUの赤字記載で目立つのは、アナログ強化とセンサです（ここでは、前提条件として無償版開発環境CS+で開発できるMCUでフィルタリングするので、ROM64KB以上の製品は除外します）。

さらに、このアナログ強化とセンサの詳細内容をカタログ記載の各MCUから読むと、S1/S2/S3コアへ、周辺回路PGA：Programmable Gain Amplifierとコンパレータ、ADC/DACを強化した製品であることが判ります。汎用製品でも、よりIoT向けのMCUへ変化しつつあることが、同ページのRL78応用分野からも解ります。

ARM Cortex-M系に勝るRL78の高品質サンプルソフト

ARM Cortex-Ｍ系が全盛な低価格MCUの市場で、唯一独自16ビットS1/S2/S3コアでライバルと争っているRL78。この市場で生き残るには、価格や開発環境の良さに加えて、実際の開発がラク、手軽になることです。

前回、RL78開発者の方々へ少し悲観的な記事を書きましたが、RL78 MCUは、使えるサンプルソフトが豊富で解説が親切、理解しやすいことも特徴です。サンプルソフトの良さ悪さは、アプリケーションの早期開発（＝プロトタイピング）には重要な要素です。プロトタイピングには、ルネサスの高品質サンプルソフトと、弊社RL78/G1xテンプレートを活用してください。

開発環境CS+のサンプルソフトは、付属のスマートブラウザーを使うと、検索が簡単です。

残念ながら、サンプルソフトの質は、評価しにくい項目なので、MCU選定時の項目からは除外されがちです。本ブログでは、RL78サンプルソフトの質が優れた特徴をもっとアピールしていきたいと考えています。

＊　　＊　　＊

PS：LPC81x/82x共通化を目指したLPC8xxテンプレートV3の開発は、7Eを予定していましたが、LPCOpenライブラリv3.01付属サンプルソフトに複数の不具合があるため、一時停止としました。これら不具合解消後、再開します。

Runesas RL78開発者に読んでほしい記事

2017年7月26日 WithHappy

Runesas RL78開発者の方々へ読んでほしい記事、「ARMコアの普及：前後編」を紹介します。

記事概要

ARMコア普及の背景、理由、MCUベンダーメリット、開発者メリットなどが解り易く記載されています。

Runesas RL78開発者の方々は、日々忙しい開発スケジュールに追われ、課題解決のために情報収集などを行っていると思います。RL78情報は、日本語資料やかふぇルネによるコニュニティーサポートも充実しているので、日本人開発者にとってRL78は便利です。

但し、別MCUの状況を知ることも大切です。RL78は優れたMCUです。しかし、良いMCUや技術が生き残るかは、全く別問題です。開発者は、現状に拘らず、バックアップ技術も習得しておくことが大切です。

このバックアップ技術の候補を考えるうえで、上記記事は示唆に富んだ方向性を示してくれると思います。

CS+ V6更新後のウイルス対策ソフトAvastとの相性問題

先日RunesasのCS+がV6に更新されました。弊社マイコンテンプレート動作を、この最新CS+で確認しました。

但し、動作確認終了後、約1時間した後に、ウイルス対策ソフトAvast 17.5.2303から下記ワーニングが発生しました。CS+は、既に動作終了しています。

動作終了したCS+が原因だと気が付かずに、うっかり動作を阻止すると、CS+の今後の動作に支障が発生する可能性もありますので、私は、除外リストへCS+の当該処理を加えました（以前も同様のワーニング発生で同じ対処でトラブル回避しました）。

同じようなワーニングが発生した場合には、参考にしてください。

LPC8xxのGPIO制御とデバッグTips

2017年7月22日2017年8月3日 WithHappy

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一覧（その１）
	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一覧（その２）
	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実行のデバッグ画面（赤色が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の方が、より制御し易いレジスタを備えています（ハードウエアマニュアルより抜粋）。

バグがあった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で開こうとすると、下記ワーニングが出力されます。

旧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ライブラリ更新

2017年7月9日2017年7月14日 WithHappy

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