MCUXpresso SDKの使い方

NXP MCUXpresso IDEを使ったFRDM-KE02Z40Mテンプレートv2開発にあたり、MCUXpresso SDKベースのMCUソフトウェアの開発方法を示します。

MCUXpresso SDK全般の使い方

MCUXpresso SDKの全般的な使い方は、IDE付属のGetting Started with MCUXpresso SDKコチラの動画で判ります。どちらも初めてSDK:Software Development Kitを使う時には役立ちますが、具体的にSDKを使ってMCUソフトウェア開発をするにはどうすれば良いのかの説明はありません。

「導入説明だけで活用説明がない」典型例です。

MCUXpresso SDK構造

本稿はソフトウェア開発初心者が、一番知りたいハズだと思うSDKの具体的な使い方:活用の説明をします。SDK全般の使い方:導入説明に関しては、上記リンク先を参照してください。

OpenSDA接続問題

現時点では、FRDM-KE02Z40M(Cortex-M0+/40MHz、5V Robust)のOpenSDAとIDEデバッガ間が接続できない問題があり、代わりにFRDM-KL25Z(Cortex-M0+/48MHz、General Purpose)も使います。FRDM-KL25Zには、接続問題はありません。

※FRDM-KE02Z40MのOpenSDA接続問題は、内容とその解決策を次回以降投稿予定です。

SDK Version

Installed SDK Version (2020-07)
Installed SDK Version (2020-07)

投稿時点のSDK_2.x_FRDM-KE02Z40M(Version 2.7.0)とSDK_2.x_FRDM-KL25Z(Version 2.2.0)が上図です。MCUXpresso IDEへインストールされたSDK Versionが異なることには注意が必要です。

Versionが異なると、SDK提供サンプルプロジェクトやその中身が異なることがあるからです。多くの評価ボードの最新SDK Versionは2.7.0ですので、テンプレートもSDK Version 2.7.0を前提とします。

Hello_worldサンプルプロジェクトと新規作成プロジェクト

Hello_worldサンプルプロジェクト(左)と新規作成Templateプロジェクト(右)
Hello_worldサンプルプロジェクト(左)と新規作成Templateプロジェクト(右)

FRDM-KE02Z40Mのhello_worldプロジェクトが上図(左)です。CMSISやboardなど多くのフォルダがあり、その中にcソースファイルと、hヘッダファイルが混在しています。sourceフォルダ内にhello_world.cとmain関数があります。

このsourceフォルダが、ユーザの開発するc/hファイルを格納する場所で、他のboardフォルダなどは当面無視して構いません。New Projectをクリックし新たなプロジェクト(プロジェクト名:Template)を作成すると、この理由が判ります。

上図(右)が新規作成したTemplateプロジェクトです。sourceフォルダ以外は、hello_worldと同じ構造です。sourceフォルダ内のTemplate.c内に、コメント:/* TODO: inset other… */が2か所あることも判ります。この青色TODOコメントのソース位置は、ソースウインド右端の上下スライダに青で明示されています。

青色TODOコメントは、ソースコードのユーザ追記場所を示します。

最初のTODOコメントの下にユーザ追記インクルードファイルを、次のTODOコメントの下にユーザ宣言や定義を追記し、main関数内にユーザ処理を追記すればTemplateプロジェクトが完成します。

※main関数内にユーザ処理を追記するのは当然のことですので、main関数内にあるべき青色TODOコメントは、省略されています。

MCUXpresso SDK活用のMCUソフトウェア開発方法

前章までのSDK構造をまとめます。

  • ユーザが新規に開発(追記)するソース/ヘッダファイルは、全てsourceフォルダ内に配置
  • IDEが生成したsourceフォルダ>プロジェクト名.cのユーザ追記場所は、目印として青色TODOコメントがあり、上下スライダにも明示される
  • sourceフォルダ以外は、IDEがSDK Versionに応じて自動生成するライブラリフォルダ
  • ライブラリフォルダの中身は、ユーザ編集は不要

SDK付属のサンプルプロジェクトは、SDK構造に基づいてNXPが作成した周辺回路の利用例です。
※サンプルプロジェクトでは、青色TODOコメントは全て省略されています。

MCUが異なっても、同じ処理を行う場合は、sourceフォルダ内のユーザ追記処理も同じハズです。例えば、FRDM-KE02Z40MとFRDM-KL25Zのhello_worldプロジェクト>sourceフォルダ>hello_world.cは、全く同じソースコードで実現できています。

MCU差やSDK Version差は、sourceフォルダ以外のSDK構造部分で吸収されます。導入説明:Getting Started with MCUXpresso SDKの図1は、このことを図示したものです。

MCUXpresso SDK Laysers(出典:Getting Started with MCUXpresso SDK, Rev. 10_06_2019)
MCUXpresso SDK Laysers(出典:Getting Started with MCUXpresso SDK)

もちろん、旧SDK Versionで未提供なAPIが、新SDK Versionで新たに提供される場合もあります。ただ基本的なAPIは、新旧SDKで共通に提供済みです。

FRDM-KE02Z40MのSDK VersionとFRDM-KL25ZのSDK Versionは現時点で異なるため、IDEが自動生成するフォルダ数は異なります。しかし、ユーザ開発(追記)処理が、sourceフォルダ内で全て完結するSDK構造は同じです。

これが、hello_worldサンプルプロジェクトのようにFRDM-KE02Z40MとFRDM-KL25Z両方に共通で記述できるユーザ処理(Application Code)がある理由です。

SDK構造に沿ったsourceフォルダへのユーザ処理追記と、基本的API利用により、汎用的で効率的なMCUソフトウェア開発が出来ることがご理解できたと思います。

あとがき

2章で、「具体的にSDKを使ってMCUソフトウェア開発をするにはどうすれば良いのかの説明はない」と書きました。しかし、本稿で示したSDK活用説明は、ソフトウェア開発者は当然知っていること・・・だから説明がないとも言えます😅。

このように組込みMCU関連の資料は、前提とするソフトウェア知識・経験をどの読者も既に持っており、本稿記述の当たり前の活用説明は省略する(≒すっ飛ばす)傾向があります。

弊社マイコンテンプレートは、初心者~中級レベルの開発者を対象としており、提供テンプレートも本稿で示したSDK活用方法で開発します。ご購入者様が、なぜこのようなテンプレートになったのか疑問を持った時、それに答えるため、このすっ飛ばした省略部分を補う説明を本稿ではあえて加えました😌。



Cortex-M0からCortex-M0+変化

前稿で示したNXP MCUラインナップ図には、ARM Cortex-M0/M0+両方のコアが掲載中でした。しかし、最新版MCUXpresso IDEのコア選択ダイアログには、Cortex-M0選択肢がありません。

MCUXpresso IDEのコア選択ダイアログ
MCUXpresso IDEのコア選択ダイアログ

そこで、Cortex-M0+とCortex-M0の違いを調べた結果、新規MCU開発にNXPのCortex-M0コアを使う必然性は低いという結論に達しました。本稿は、その根拠を示します。

ARM Cortex-M0+とCortex-M0の差

弊社関連投稿:Cortex-M0/M0+/M3比較とコア選択や、ARMコア利用メリットの評価ARM MCU変化の背景をまとめ、ARMコアの発表年順に示したのが下表です。※M4の発表年は間違っているかもしれませんが、市場に出回ったCortex-Mxコアの順番は下表で正しいハズです😌。

ARM Cortex-Mx性能、発表年
Cortex-Mコア 性能 (MIPS @ MHz) ARM発表年 MCUモデル
Cortex-M3 1.25 2004 旧メインストリーム
Cortex-M0 0.9 2009 ローコスト
Cortex-M0+ 0.95 2011 ローパワー
Cortex-M4 1.25 2012頃 デジタル信号処理新メインストリーム

要するに、Cortex-M0+やCortex-M4は、Cortex-M0やCortex-M3をベースに市場ニーズに即した変更を加えた新しいARMコアだと言うことです。本稿では、特にCortex-M0+とM0の違いに注目します。

Cortex-M0+には、表の差以外にも高速IOアクセス、高速パイプライン、低消費動作モードなどCortex-M0には無い数々の特徴がありますが、Cortex-M0よりも高性能(0.9→0.95MIPS@MHz)で、シリコンチップ高速化にも好都合です。

つまり、新規開発にCortex-M0+の代わりに敢えてCortex-M0コアを用いる理由は、見当たらない訳です。

NXPの新しい統合開発環境MCUXpresso IDEのSDKのコア選択肢に、Cortex-M0が無いのは、上記が理由だと思います。※ローコストに関しては、コア単体の相対評価はできても、使用数量でかなり変動するためMCUコスト絶対評価を難しくしています。

NXP MCUXpresso SDK対応評価ボード数

最新MCUXpresso IDE v11.1.1のSDKで対応中の評価ボード数を一覧にしました。例えば、Cortex-M33コアなら下図のように7個です。

MCUXpresso SDK対応評価ボード数(Cortex-M33の場合)
MCUXpresso SDK対応評価ボード数(Cortex-M33の場合)
MCUXpresso SDK対応評価ボード数比較(2020-07)
MCUXpresso SDK対応評価ボード数比較(2020-07)

評価ボードは、プロトタイプ開発には必須で、その評価ボードで動作するSDK(Software Development Kit)があればソフトウェア開発効率は向上します。Cortex-Mxコア間のソフトウェア移植性は高く、同じコアのソフトウェアであれば、異なる評価ボードへの移植もさらに容易です。

つまり、評価ボード数が多いCortex-M0+やCortex-M4が、現在最もCortex-Mxコアソフトウェア開発効率が高いことを示しています。また、Cortex-M3コア選択肢がない理由も、Cortex-M0コアがない理由と同じと推測します。

本当の並列処理が要求されるマルチコア開発なら、Cortex-M0+とM4のペア、または、IoTセキュリティを強化したCortex-M33コアx2であることも判ります。※Cortex-M33は、2016年ARM発表のセキュリティ強化コアです。

新規ARM Cortex-Mxソフトウェア開発は、Cortex-M0+コアまたはCortex-M4コア利用に収束してきたと思います。
※Cortex-M33コアは、従来コアに無いIoT向けセキュアゾーンなどが新規機能追加されていますので除外しています。

弊社テンプレート開発方針

前稿のNXP MCUラインナップからCortex-M0とCortex-M3を除き、現状SDK提供中のARM Cortex-Mxコアラインナップをまとめると下図になります。※Cortex-M33は未掲載です。

Software Development Kit開発から見たNXP MCUラインナップ
Software Development Kit開発から見たNXP MCUラインナップ

弊社もCortex-M0+、Cortex-M4、Cortex-M33コア向けのテンプレート開発を進める方針です。

NXP MCUラインナップ

NXPは、今から約4年前の2015年12月末にFreeSacleを買収し、FreeSacleのKinetisマイコン(750品種)とNXPのLPCマイコン(350品種)は、NXP 1社から供給されるようになりました。また、別々であった統合開発環境も、新しいMCUXpresso IDEが両MCU対応となり、SDK:Software Development Kitを使ってMCUソフトウェアを開発する方法に統一されました。

本稿は、NXPのCortex-MコアMCU:LPC/Kinetisのラインナップと、新しいMCUXpresso IDE、SDK対応状況をまとめました。

NXP MCUラインナップ

NXP MCUラインナップ(出典:LPC MICROCONTROLLERS 2017-01-04)
NXP MCUラインナップ(出典:LPC MICROCONTROLLERS 2017-01-04)

上図から、おおむね青色のLPCが汎用MCU、橙色のKenitesが特定アプリケーション用途MCUに分類できそうです。

この特定用途とは、例えばKinetis Eシリーズならば、昨今3.3V以下で動作するMCUコアが多いなか、白物家電や産業用途向けに、過酷な電気ノイズ環境下でも高い信頼性と堅牢性(Robust)を維持できる5V動作Cortex-M0+コアMCUを指します(NXPサイトにはCortex-M4コア版もあります)。

Kinetis Eシリーズのコア動作電圧は、2.7~5Vです。関連投稿:MCUの5V耐圧ピンで示したピン毎の5V耐性がMCUコアに備わっており、更に耐ノイズ性も高められているため、タッチパネル操作や多くの5Vデバイス制御に対して使いやすいCortex-M0+/M4シリーズと言えます。

5V動作でタッチパネル付きのKenites KE02 40MHz評価ボード(出典:NXPサイト)
5V動作でタッチパネル付きのKenites KE02 40MHz評価ボード(出典:NXPサイト)

LPC/Kinetis MCUのMCUXpresso IDE、SDK対応

新しくなった統合開発環境MCUXpresso IDEのLPC/ Kenites対応表が、NXP Communityに掲載中です。

この表は毎年更新され、NXPから供給中の全MCU/Application ProcessorのMCUXpresso IDE、SDK対応状況と対応予定まで解るとても役立つ資料です。この表のProduct Familyにフィルタをかけ、Recommended Software欄とMCUXpresso Software and Tools欄を抜粋したのが下表です。

MCUXpresso Supported Devices Table (May 2020より抜粋)
MCUXpresso Supported Devices Table (May 2020より抜粋)

Kenites KE02: 40MHzは、弊社Kinetis Eテンプレートで使ったKinetis Eシリーズマイコンです。2015年のテンプレート開発当時は、旧FreeSacleから供給され、統合開発環境もKinetis Design Studio:KDSとAPI生成ツール:Processor Expertを使いました。現在は、MCUXpresso IDEとSDKへ変わっています。

LPC1100は、古くからあるNXP汎用MCUで、弊社LPC110xテンプレートも提供中です。LPC1100は、MCUXpresso IDEで開発はできますがSDK対応予定は無く(Not Planned)、従来のLPC Open開発が推薦されています。

また、Kinetis KL05: 48MHzは、MCUXpresso IDEとSDK対応予定が無く、旧FreeSacleのKDS開発を推薦しています。

Not Planned 推測

MCUXpresso Software and Tools欄のNot Plannedの意味を考えます。

いずれのMCUも発売後10年~15年程度の安定供給をNXPが保証するため、直ぐにDiscontinueになることはありません。しかし、FreeSacle とNXPの2社統合で当然ながらダブって供給されるMCU品種もある訳で、供給側にとっては1品種へマージしたいでしょう。

この対象は、旧2社それぞれの汎用品種が多く該当すると思われ、その結果が表に現れたと考えます。

つまり、LPC1100やKinetis KL05は、恐らくダブった品種で、新しいMCU開発環境は使わずにそのまま旧開発環境で継続開発ができますが、近い将来Discontinueの可能性が高いと思います。Not Plannedは、これを暗示的に示していると推測します。

もちろん、新発売MCUや生き残った品種は、どれもMCUXpresso IDEとSDKに対応済み(Available)です。最初のMCUラインナップ図を振り返ると、多くのKinetisシリーズは、特殊用途MCU:Application Specific Familiesとして生き残り、Kinetis K/Lシリーズは、汎用MCU:General Purpose Families内で生き残ったのだと思います。

但し、生き残った品種でもデバイスによってはDiscontinueの可能性があり、個別デバイスの確認は、Community掲載表を参照した方が良いでしょう。

弊社マイコンテンプレート対応

主に汎用MCU向けの弊社マイコンテンプレートも、(推測した)NXPと同様の対応にしたいと考えています。つまり、Kinetis Eテンプレートは、最新開発環境MCUXpresso IDEとSDK利用版へ改版、LPC110xテンプレートは、販売中止といたします。

Kinetis E テンプレート改版は、直ぐに着手いたします。Kinetis Eテンプレートご購入者様で購入後1年未満の方は、この改版版を無償提供いたしますのでお待ちください。

LPC110xテンプレートは、1年以上新規ご購入者様がいらっしゃりませんので、無償アップグレード対象者様はございません。既にLPC110xテンプレートご購入者様には、申し訳ございません。別テンプレート50%割引購入特典のご利用をお待ちしております。

Ripple20

前投稿の2~3章で記載した、半導体製品へのサイバー攻撃があり無対策の場合、全製品が使えなくなる実例が発生しそうです。

数億台ものIoT機器や産業制御機器に実装済みのTreck社提供TCP/IPライブラリに「Ripple20」という名の脆弱性(最大値10の危険度評価9~10)が発見され、対策にはライブラリアップデートが必要ですが、できない場合は機器をネットワークから切り離すことが最低限必要になりそうです。
※TCP/IPライブラリは、有線/無線LANプロトコル実装用ソフトウェアライブラリです。

この脆弱性がハッカーに悪用されると、プリンタなどの機器からでも情報が外部流出します。Ripple20は、IoT MCUにセキュア・ファームウェア更新やOTA:Over-The-Air実装を要件とする先例になるかもしれません。

MCUのセキュア・ファームウェア更新は、関連投稿:STM32G0/G4のRoot of Trustをご覧いただくと面倒な更新方法、2面メモリ必要性などがお判り頂けると思います。OTAも関連投稿:Amazon、IoTマイコンへFreeRTOS提供の2章に簡単ですが記載しております。

IoT MCUへ、ソフトウェアだけでなくCortex-Mコアにも更なるセキュリティ対応の影響を与えそうなRipple20です。

NXPの日本市場位置づけと事業戦略

6月5日投稿NXPのFreeMASTERの最後の章で紹介したNXP新CEO)カート・シーヴァーズ(Kurt Sievers)氏へのEE Times Japanインタビュー記事が16日掲載され、NXPの日本市場位置づけと事業戦略が語られました。

  • 日本の自動車関連企業との強固な関係は、一層強める
  • 日本の産業・IoT関連企業との関係は、自動車関連企業と同様、強い関係を構築していく
  • 日本のロボティクス企業とNXPのエッジコンピューティング技術の親和性は良く、ともに成長できる

本ブログの投稿は、MCUソフトウェア開発者向けが多いです。が、今回はNXPビジネスをピックアップします。というのは、多くの開発者が使っているWindows 10の今後を考えるには、Microsoftビジネスを知る必要があるのと同じ理由です。NXPビジネスを知って、MCUの将来を考えます。

以下、2020年5月のNXP semiconductors corporate overview抄訳バージョンを使います。※EE Japan記事もこのNXP資料を使っています。

NXPターゲット4市場

NXPのターゲットは、P8記載のオートモーティブ、インダストリアル&IoT、モバイル、通信インフラストラクチャの4市場です。そして、これらを包括的にサポートする半導体デジタル/アナログ技術である、Sense、Think、Connect、Act全てをNXPは提供中です。

NXPのターゲット4市場(出典:NXP semiconductors corporate overview)
NXPのターゲット4市場(出典:NXP semiconductors corporate overview)
NXPの提供する半導体デジタル/アナログ技術(出典:NXP semiconductors corporate overview)
NXPの提供する半導体デジタル/アナログ技術(出典:NXP semiconductors corporate overview)
NXPの提供するフルシステムソリューション(出典:NXP semiconductors corporate overview)
NXPの提供するフルシステムソリューション(出典:NXP semiconductors corporate overview)

NXPの強み

NXPの強みは、ユーザである我々開発者へ、半導体技術をもれなく提供できることだと筆者は思います。この分野は近い将来、セキュア/セキュリティ無しでは存在しえません。ネットワークで繋がり、セキュリティが弱い箇所が一か所でもあれば、全てが使えなくなる危険性があるからです。

例えインタフェースが確立されていても、技術同士を接続すると、上手く動作しないことはよくあります。※俗に相性問題などとWindowsでは言われます。

全技術を他社より先に提供するNXP同志の技術接続は、競合他社間の技術接続より容易、低リスクであることは明らかです。後追いの競合他社は、差別化の特徴を持たないと生き残れず、この特徴が逆に他社との接続障害になることもあります。

P12に記載されたように技術単独では存在意味が弱く、各技術がセキュアに繋がって初めてソリューションとしての市場価値が生まれます。

EE Japan Times記事によると、AI関連技術は、NXPで独自開発を行うとともにM&Aも検討中のようです。このように、選択と集中、差別化戦略ではなく全ての半導体技術を開発し、ユーザである開発者へ提供できることがNXPの強みだと思います。

エッジコンピューティングMCUの将来

PC → スマホ → MCUへとセキュリティや半導体技術をけん引してきたデバイスは変わりつつあります。

COVID-19パンデミックで経済活動が停止したのは、コロナワクチンが無いからです。半導体製品にサイバー攻撃があった時、対応ワクチンや追加のセキュリティがThink主役のMCUへ必要となります。

これらからMCUは、今後さらなるセキュリティ実装やWiFi-6などの新しい無線LAN規格への対応など、より高性能化、低消費電力化へ進むと思います。NXPは台湾TSMCの5nm製造プロセスを次世代自動車用MCUに使う(2020/6/12)ことを明らかにし、実現へ向けてスタートしています。

NXP日本市場位置づけ、事業戦略、開発者の対策

以上のNXP概要を見たうえで、最初に示した日本市場位置づけ、事業戦略を振り返ると、NXPの提供する広範囲な半導体技術を自動車、産業機器、ロボティクスへ適用していくことがより解ると思います。

我々開発者は、NXP製品の第1次利用者です。MCU開発者は、次々に導入される新しい技術を焦ることなく効率的に習得・活用し、開発製品へ応用しましょう。そして、我々の製品利用者(NXP製品の第2次利用者)へ新しい価値を提供できるよう努めましょう。

EE Japan Times記事に記載はありませんが、残念ながら日本市場の相対的地位は、低下しつつあります。また、パンデミック再来に備え、開発者個人のスキルアップや自己トレーニング重要性も再認識されたと思います。より広く・早い開発技術の習得が、MCU開発者には必要となるでしょう。

Windows 10の将来

市場に溢れるWindows 10情報は、トラブル対策のものが殆どで、MicrosoftのOSビジネス情報は見当たりません。ただ、ここ数年のWindows 10状況は、最終PC利用者の価値を高めるというよりも、Windowsブロガへの記事ネタを増やすことに役立っています。

このWindows現状を、Microsoftがどのように回復するのか知りたいです。ビジネスなので、利益なしの解はありません。しかし、安心してWindows 10が使えないなら、PCのOSは、安定感のあるiOSやLinuxへ変わるかもしれません。

アプリケーションのマルチプラットフォーム化や、WindowsアプリケーションでもiOSやLinux上でそのまま動作する環境も整いつつあります。折しも、32ビットPC OSは、2020年で終焉を迎えようとしています。ハードウェア起因ならまだしも、ソフトウェア、特にOS起因の生産性低下は、許されないと思います。

MCUの5V耐圧ピン

弊社FreeRTOS習得ページで使う評価ボード:LPCXpresso54114(Cortex-M4/100MHz、256KB Flash、192KB RAM)は、FreeRTOSだけでなく、Mbed OSZephyr OSなどオープンソース組込みRTOSにも対応しています。多くの情報がありRTOSを学ぶには適した評価ボードだと思います。

LPCXpresso54114 Board power diagram(出典:UM10973に加筆)
LPCXpresso54114 Board power diagram(出典:UM10973に加筆)

さて、このLPCXpresso54114の電圧ブロック図が上図です。MCUはデフォルト3.3V動作、低電力動作用に1.8Vも選択可能です。一方、Arduinoコネクタへは、常時5Vが供給されます。

本稿は、このMCU動作電圧とArduinoコネクタに接続するセンサなどの動作電圧が異なっても制御できる仕組みを、ソフトウェア開発者向けに説明します。

MCU動作電圧

高速化や低電力化の市場要求に沿うようにMCU動作電圧は、3.3V → 3.0V → 2.4V → 1.8Vと低下しつつあります。同時にMCUに接続するセンサやLCDなどの被制御デバイスも、低電圧化しています。しかし、多くの被制御デバイスは、未だに5V動作が多く、しかも低電圧デバイスに比べ安価です。

例えば、5V動作HD44780コンパチブルLCDは1個500円、同じ仕様で3.3V動作版になると1個550円などです。※弊社マイコンテンプレートに使用中のmbed-Xpresso Baseboardには、5V HD44780コンパチブルLCDが搭載されています。

レベルシフタ

異なる動作電圧デバイス間の最も基本的な接続が、間にレベルシフタを入れる方法です。

TI)TXS0108E:8ビットレベルシフタモジュールの例で示します。低圧A側が1.8V、高圧B側が3.3Vの動作図です。A側のH/L電圧(赤)が、B側のH/L電圧(緑)へ変換されます(双方向なので、B側からA側への変換も可能です)。

8ビットレベルシフタTXS0108Eのアプリケーション動作(出典:TI:TXS0108Eデータシート)
8ビットレベルシフタTXS0108Eのアプリケーション動作(出典:TI:TXS0108Eデータシート)

レベルシフタ利用時には、電圧レベルの変換だけでなく、データレート(スピード)も重要です。十分なデータレートがあれば、1.8VのH/L波形は、そのまま3.3VのH/L波形へ変換されますが、データレートが遅いと波形が崩れ、送り側のH/L信号が受け側へ正確に伝わりません。

例えば、LCD制御は、複数のLCDコマンドをMCUからLCDへ送信して行われます。データレートが遅い場合には、コマンドが正しく伝わらず制御ができなくなります。

MCUの5V耐圧ピン:5V Tolerant MCU Pad

LPCXpresso54114のGPIOピンには、5V耐圧という属性があります。PIO0_0の[2]が5V耐圧を示しています。

LPCLPCXpresso54114の5V耐圧属性(出典:5411xデータシート)
LPCLPCXpresso54114の5V耐圧属性(出典:5411xデータシート)

5V耐圧を簡単に説明すると、「動作電圧が3.3/1.8V MCUのPIO0_0に、5Vデバイスをレベルシフタは使わずに直接接続しても、H/L信号がデバイスへ送受信できる」ということです。または、「PIO0_0に、1ビットの5Vレベルシフタ内蔵」と解釈しても良いと思います。

※ハードウェア担当者からはクレームが来そうな説明ですが、ソフトウェア開発者向けの簡単説明です。クレームの内容は、ソフトウェア担当の同僚へ解説してください😌。

全てのGPIOピンが5V耐圧では無い点には、注意が必要です。但し、ArduinoコネクタのGPIOピンは、5V耐圧を持つものが多いハズです。接続先デバイスが5V動作の可能性があるからです。

また、I2C/SPIバスで接続するデバイスもあります。この場合でも、MCU側のI2C/SPI電圧レベルとデバイス側のI2C/SPI電圧レベルが異なる場合には、レベルシフタが必要です。MCU側I2C/SPIポートに5V耐圧属性がある場合には、GPIO同様直接接続も可能です。

I2Cバスは、SDA/SCLの2本制御(SPIなら3本)でGPIOに比べMCU使用ピン数が少ないメリットがあります。しかし、その代わりに通信速度が400KHzなど高速になるのでデータレートへの注意が必要です。

LPCXpresso54114以外にも5V耐圧ピンを持つMCUは、各社から発売中です。ちなみに、マイコンテンプレート適用のMCUは、6本の5V耐圧GPIOを使ってmbed-Xpresso Baseboard搭載5V LCDを直接制御しています。

mbed-Xpresso Baseboard搭載5V HD44780コンパチLCDの3.3V STM32G071RB直接制御例
mbed-Xpresso Baseboard搭載5V HD44780コンパチLCDの3.3V STM32G071RB直接制御例

5V耐圧MCUデータシート確認方法

MCUのGPIOやI2C/SPIを使って外部センサやLCDなどのデバイスを制御する場合、下記項目を確認する必要があります。

  1. MCU動作電圧と被制御デバイス動作電圧は同じか?
  2. MCU動作電圧と被制御デバイス動作電圧が異なる場合、外付けレベルシフタを用いるか、またはMCU内蔵5V耐圧ピンを用いるか?
  3. MCU内蔵5V耐圧GPIOやI2C/SPIを利用する場合、そのデータレートは、制御に十分高速か?

5V耐圧ピンは、使用するMCU毎に仕様が異なります。MCUデータシートは、英語版なら「tolerant」、日本語版なら「耐圧」で検索すると内容確認が素早くできます👍。

MCU動作電圧と接続デバイス動作電圧が異なっても、MCUのH/L信号が被制御デバイスへ正しく伝わればデバイスを制御できます。

MCU動作電圧に合わせたデバイス選定やレベルシフタ追加ならば話は簡単ですが、トータルコストや将来の拡張性などを検討し、5V耐圧ピンの活用も良いと思います。

NXPのFreeMASTER

FreeMASTERは、NXP組込みMCUのアプリケーションのリアルタイム変数モニタと、モニタデータの可視化ツールです。関連投稿:STマイクロエレクトロニクスのSTM32CubeMoniterとほぼ同じ機能を提供します。

NXP資料FreeMASTER Run-Time Debugging Tool – Overview を使ってFreeMASTERの特徴を示します。

FreeMASTERとIDEデバッガ機能差

FreeMASTERと、開発者が普段使うIDEデバッガとの差が一目で解る図がP13にあります。

FreeMASTERとデバッガの違い(出典:FreeMASTER Run-Time Debugging Tool – Overview)
FreeMASTERとデバッガの違い(出典:FreeMASTER Run-Time Debugging Tool – Overview)

両者の機能境界が、ソースコードのデバッグ機能です。IDE(MCUXpresso IDE)でも変数ロギングやグラフ化機能はありますが、プログラム開発者向けの最低機能に絞ったものです(limited functionality)。

これに対し、FreeMASTERは、msec分解能のグラフ化と、μsec分解能のデータ取得が可能です。更に取得データを利用し、Field-tune parametersやRemote controlなど多くの機能を持つツールです。データの取得は、MCU実装のUARTやUSB、SWD経由です。

FreeMASTERを使うと、外付け制御パネルの代替やGUIアプリケーションとしても活用できます。例えば、下図のようなモータ制御パネルが、PC上でFreeMASTERソフトウェアのみで実現できる訳です。

FreeMASTERを使ったモータ制御パネル例(出典:FreeMASTER Run-Time Debugging Tool – Overview)
FreeMASTERを使ったモータ制御パネル例(出典:FreeMASTER Run-Time Debugging Tool – Overview)

 FreeMASTER構成

Windows PCにおけるFreeMASTER構成がP20です。詳細は、P21~25に示されています。Linux PCでの構成は、P26に示したFreeMASTER Liteが使われます。

FreeMASTER Windows PC構成(出典:FreeMASTER Run-Time Debugging Tool – Overview)
FreeMASTER Windows PC構成(出典:FreeMASTER Run-Time Debugging Tool – Overview)

MCU開発トレンド:ビジュアル化と脱Windows

組込みアプリケーションのビジュアル化は、最近のMCU開発トレンドです。

MCU本体の性能を使わずに変数データを取出し、そのデータを高性能PCとプラグイン機能を利用し、データ可視化やリモート制御を実現します。本稿で紹介したNXPのFreeMASTERやSTのSTM32CubeMoniterがこのトレンドをけん引する技術です。

また、オープンソースLinux PCへのMCU開発環境移行や各社IDEマルチプラットフォーム化、つまり脱Windowsもトレンドの1つです。

上級開発者向けというイメージが強かったLinux PCですが、一般ユーザへも普及し始めました(Wikipediaより)。筆者も昨年から、MCU開発Main-PCのWindows 10とは別に、Backup-PCにLinux Mintを新規インストールし試用中です。

半年間の試用では、OSインストール、大型/定期更新、セキュリティに関してもLinux Mintの方が、Windows 10より安定感があります。

もはや現状のWindows 10では、信頼性があったWindows 7のレベルにはならない気がします。

既存Windows 10に手を加えるよりも、新OSを開発するほうが、早道で、安心してPCを利用したい一般ユーザ要求も同時に満たせるのではないでしょうか? 商業的理由は、セキュリティ対応強化とすれば、内容不明ながら大多数の納得も得られるでしょう。※あくまで、ソフトウェア開発経験者個人の見解です。

NXP新CEO Kurt Sievers氏

2020年5月28日、蘭)NXPのCEOがリチャード・L・クレマー(Richard L. Clemmer)氏から、カート・シーヴァーズ(Kurt Sievers)氏への交代発表がありました。こちらのEE Times記事に新CEOカート・シーヴァーズ氏の経歴や、米中貿易摩擦下でのNXP中国分析などが示されています。

欧州MCUベンダNXPのアフターCOVID-19への布石、さすがに早いです。

STM32G0xテンプレートV2発売

STマイクロエレクトロニクス統合開発環境STM32CubeIDEのHAL APIを利用し開発したSTM32G0xテンプレートVersion2を、6月1日から発売します。

上記弊社サイトよりテンプレート付属説明資料P1~P3が無料ダウンロードできますので、ご検討ください。

STM32G0xテンプレートV2内容

従来よりも高性能で低消費電力動作の新汎用MCU:STM32G0シリーズのアプリケーション開発を、初心者でも簡単に始められ、しかも、処理能力やセキュリティ要求が変化した場合でも、開発資産を活かしたままMCU変更が可能なHAL APIプログラミングに重点を置きました。

そこでVersion2では、LL APIからHALAPI利用アプリケーション開発用テンプレートへの変更、統合開発環境SW4STM32から、STM32CubeIDEへの変更に対応しました。

STM32G0xのもう一つの特徴であるセキュアブート、セキュアファームウェア更新機能を活用する機能は、G0xテンプレートV2以降で対応します。

これらセキュリティ機能は、関連投稿:STM32G0/G4のRoot of Trust(1)~(3)で示したように、IoT MCUでは必須です。これら実装のメインストリーム(=汎用)・マイコンは、現在G0/G4シリーズです。

Root of Trust対応中のSTM32マイコン一覧(出典:FLXCUBESBSFU0819J)
Root of Trust対応中のSTM32マイコン一覧(出典:FLXCUBESBSFU0819J)

汎用性とセキュリティの両方を持つSTM32マイコンをご検討中の方は、先ずはSTM32G0xテンプレートV2で汎用性の部分をマスターできます。

STM32G0xテンプレートV2のご購入、お待ちしております。

Windows 10 May 2020 Update(バージョン2004)対策

5月28日、Windows 10の新バージョン2004の配布が始まりました。残念ながら、早くも複数の大型更新トラブルが発生中です(10件の更新トラブル情報)。

Fast/Slow リングの目的、月一Windows 10 Updateでの多くのトラブル、一般PC利用者への悪影響…等々、このところのMicrosoftは、何か変だと思わずにはいられません。

バージョン2004への更新を暫く避けようと考えている方は、Pro/Homeともに、コチラの方法が参考になります。

STM32マンスリー・アップデートHTML化

STマイクロエレクトロニクスのSTM32マンスリー・アップデートが、6月からスマホ閲覧に好適なHTML配信に変わります。2020年5月号が最後のメール配信でした。HTML配信はブラウザで「絵的」に見るのには確かに適していますが、「字的」な記憶や記録に残りにくい気がするので、個人的には残念です。

そこで、これまでのメール配信版の全マンスリー・アップデートから、5月30日発売のSTM32G0xテンプレートVersion2対象STM32G0シリーズ関連部分を忘れないようピックアップしました。

STM32G0シリーズ特徴

STM32G0シリーズ(出典:マンスリー・アップデート2019年10月)
STM32G0シリーズ(出典:マンスリー・アップデート2019年10月)
Dead Battery機能デフォルト有効(出典:マンスリー・アップデート2019年7月)
Dead Battery機能デフォルト有効(出典:マンスリー・アップデート2019年7月)

※テンプレートで使うNucleo-G071RBは、USB Power Delivery機能(Dead Battery機能)が「デフォルト無効」となっています。

STM32G042/G031/G030新登場(出典:マンスリー・アップデート2020年1月)
STM32G042/G031/G030新登場(出典:マンスリー・アップデート2020年1月)
STM32マイコンでRoot of Trust実現のX-CUBE-SBSFU(出典:マンスリー・アップデート2020年3月)
STM32マイコンでRoot of Trust実現のX-CUBE-SBSFU(出典:マンスリー・アップデート2020年3月)
SBSFU機能(出典:STM32_Security-Introduction)
SBSFU機能(出典:STM32_Security-Introduction)

報告は、A4で1枚以内にまとめろとOJTで学びました。今風に言うと、Twitterのような短文で報告せよということです。記事に、70nm新製造プロセス、64ピンパッケージでも1ペア電源ピン説明が無いのは、少し不満ですが、少ない文字量でSTM32G0特徴をまとめる良い見本になりました。

これは、読者にソフトウェア開発者が多いからでしょうか🤨? 黄色ハイライトは筆者加筆です。

STM32G0xテンプレートV2変更内容

さて、このSTM32G0シリーズ向けSTM32G0xテンプレートV2は、下記3項目がV1からの変更内容です。

  • IoT必須セキュアブート、セキュアFWアップデート実装STM32G0特徴を活用(詳細は、コチラの関連投稿を参照してください。V1は、この特徴を活かしきれていませんでした😂)
  • 高性能専用LL API利用から、汎用HAL API利用アプリケーション開発用テンプレートへ変更
  • SW4STM32統合開発環境から、STM32CubeIDEへ変更

項目2と3をVersion2で対応します。余裕があれば項目1にも対応するかもしれません。

STM32FxテンプレートV2発売

STマイクロエレクトロニクス統合開発環境STM32CubeIDEのHAL APIを利用し開発したSTM32FxテンプレートVersion2を発売します。

上記サイトよりテンプレート説明資料P1~P3が無料ダウンロードできますので、ご検討ください。本稿は、この「ダウンロード以外」の資料項目を簡単に示します。

全ツールビルトインSTM32CubeIDE

STM32CubeIDEは、従来は別ツールとして提供してきたSTM32CubeMXがビルトイン済みです。しかも開発ツール全てが自動的に最新版へ更新します。もちろんHelp>Check for Updatesで手動更新も可能です。

2020年5月15日現在のブログ関連STM32MCUに関係するSTM32CubeIDE状況が下図です。

STM32CubeIDE状況(2020年5月15日現在)
STM32CubeIDE状況(2020年5月15日現在)

STM32FxテンプレートV2は、HAL(Hardware Abstraction Layer)API利用アプリケーション開発用テンプレートですので、MCU性能過不足時、他のSTM32MCUコアへも開発アプリケーションが流用可能で、プロトタイプ開発に最適です。

STM32FxテンプレートV2ダウンロード説明資料以外の概略

以下、単語の頭に付くSTM32は省略して記述します。また、付属説明資料も同様にSTM32を省略記述していますので、ご注意ください。

AN記載CubeMXプロジェクトが読めない時の対策

アプリケーション開発の出発点となるビルトインツール:CubeMXが最新版へ自動更新されるのは、次々に発売される最新STデバイスを直ぐに開発できるメリットがあります。しかし、逆に開発者が参照するアプリケーションノート(AN)記載のCubeMXプロジェクトとの版数差が大きくなるデメリットもあります。

この版数差が大きくなると、AN記載CubeMXプロジェクトが、ビルトインCubeMXで読めない場合があります。特にF0/F1シリーズなど古くから提供されてきたデバイスのANに顕著です。STM32FxテンプレートV2付属説明資料で、この対策を示しています。

CubeIDE新規プロジェクト作成(1)/(2)/(3)の違い

STM32CubeIDEの3新規プロジェクト作成の差
STM32CubeIDEの3新規プロジェクト作成の差

CubeIDEユーザマニュアル:UM2553には、本日時点で新規プロジェクト作成説明は(1)/(3)のみです。未説明の最新版新規プロジェクト作成(1)/(2)/(3)の違いなど、開発をスムースに進める様々なTipsも説明資料に加えています。

CubeMX変更箇所、別資料化

STM32FxテンプレートVersion1では、CubeMX周辺回路の設定をテンプレート説明資料内に記載しておりました。ご購入者様からのご質問も、このCubeMX設定に関するものが多く、このツールの重要性が判ります。

そこでVersion2は、このCubeMX設定をCubeMX変更箇所.pdfとして別資料化し、CubeIDEプロジェクト内に添付しました。CubeMXプロジェクト編集時に、同時参照ができます。

STM32CubeIDEプロジェクト内添付のSTM32CubeMX変更箇所説明資料
STM32CubeIDEプロジェクト内添付のSTM32CubeMX変更箇所説明資料

例えば、ベースボードテンプレートのLCD接続に利用したSTM32F0評価ボード:Nucleo-F072RBのGPIOピン設定方針なども記載しています。CubeMXピン配置は、MCUパッケージで選択しますので、評価ボード利用のCubeMX使用ピン設定時に、下図は便利だと思います。

ベースボードと評価ボード接続時のSTM32CubeMX使用ピン設定方針
ベースボードと評価ボード接続時のSTM32CubeMX使用ピン設定方針

STM32FxテンプレートV2と添付説明資料を使うと、STM32汎用MCU開発をスムースに進められます。

STM32FxテンプレートV2のご購入、お待ちしております。

STM32CubeMX使い方刷新STM32Fx/G0xテンプレートV2発売5/15、5/30

サードパーティ仏)AC6社の統合開発環境SW4STM32で開発したSTM32FxテンプレートとSTM32G0xテンプレートを、新しいSTマイクロエレクトロニクス純正STM32CubeIDE対応のVersion2:V2へ更新し販売開始します(STM32Fxテンプレートは2020/05/15、STM32G0xテンプレートは2020/05/30)。

V2では、V1ご購入者様から頂いたご意見ご感想を反映し、新しいSTM32CubeIDEやビルトインSTM32CubeMX使い方説明に工夫を加え、開発トラブル回避、既存アプリケーション資産活用方法などの新たなTipsも添付解説資料に加えました。

テンプレートと合わせてスムースなSTM32MCUアプリケーション開発にお役に立てると思います。

本稿は、説明を工夫したSTM32CubeIDEビルトインSTM32CubeMX使い方の一部を紹介します。

STM32CubeMX使い方:コツ

※以下、用語の頭に付く「STM32」は省略して記述します。

MCU周辺回路の初期化コードを自動生成するCubeIDEビルトインCubeMXも、以前投稿したスタンドアロンCubeMXの使い方と同じです。

CubeMXはSTM32MCU開発の出発点となるツールですので、十分理解した上で着手したいものです。テンプレートV2では、ビルトインCubeMXが生成するファイルに着目し、説明に以下の「使い方のコツ」と「簡単な順位」を追加しました。

CubeMXは、生成するファイル数が多い上に、使用するMCU周辺回路が増えると、生成コード量も多くなり、初めての方には少し解りにくいツールです。弊社テンプレートV1も、このCubeMXに関する質問を多く頂きました。それでも、コツを知っていれば十分使いこなせます。

そのコツとは、以下2点です。
・チェックが必要な自動生成ファイルは、main.hのみ
・main.cに自動追加される周辺回路ハンドラと、初期化コードが分かれば使える

F1シリーズSTM32F103RBの評価ボード:Nucleo-F103RBに弊社テンプレートを応用した例で説明します。

STM32CubeMX生成のF1BaseboardTemplateファイル構成
STM32CubeMX生成のF1BaseboardTemplateファイル構成

CubeMXが自動生成するファイルが、赤:CubeMX生成欄の9個です。このうち注目すべきは、太字赤☑で表示したmain.hとmain.cです。

main.hは、CubeMXで設定したユーザラベル、評価ボードならばB1[Blue PushButton]やUSART_TX/RX、LD2[GreenLed]などを定義した生成ファイルです(※[ ]内は、自動生成時に削除されますので覚え書きなどに使えます)。

main.hのコメント:Private definesの後にこれらの定義が生成されます。これら定義をチェックしておくと、「CubeMX自動生成コードを読むときに役立ち」ます。

main.cは、CubeMXが生成するメイン処理で、評価ボードのCubeMXデフォルトでコード生成:(Alt+K)した場合には、main.cのコメント:Private variablesの後にUSARTハンドラ:huart2と、コメント:Private function prototypesの後にUSART2の初期化コード:MX_USART2_UART_Init()と、その「初期化コード本体がmain.cソースの後ろの方に自動生成」されます。

その他の7個ファイルは、当面無視しても構いません。CubeMXデフォルトのHAL (Hardware Abstraction Layer)APIを利用し、割込みを使わない限り、ユーザコードには無関係だからです(※7個ファイルを知りたい方は、関連投稿:STM32CubeMX生成ファイルのユーザ処理追記箇所を参照してください)。

CubeMXが周辺回路:USART2初期化コードとそれに使う定義を自動生成済みなので、後は、main.cの無限ループ内の指定区間:USER CODE BEGIN xyz~USER CODE END xyzに、Usart2やLD2を使ったHAL APIユーザコードを追記すれば、アプリケーションが完成します。

追記したユーザコードは、再度CubeMXでコード生成しても、指定区間のまま引き継がれます。

ちなみに、アプリケーションで使用可能なHAL APIは、Ctrl+Spaceでリスト表示されます(Content Assist)。そのリストから使用するHAL APIを選択すれば、効率的なユーザコード追記が可能です。
※Content Assistの賢いところは、「ソースコード記述の周辺回路ハンドラを使ってHAL APIをリスト化」するところです。記述なしハンドラのAPIはリスト化されません。

つまり、CubeMXのPinout & Configurationタブで周辺回路を設定後コード生成しさえすれば、直ぐにユーザコードを追記できるファイルが全て自動的に準備され、これらファイルの指定区間へユーザコードを追記すれば、アプリケーションが完成する、これがCubeMXの使い方です。

このCubeMX使い方理解に最低限必要なファイルが、簡単順位:0のmain.hとmain.cの2個です。CubeMX生成ファイル数は9個ありますが、先ずはこの2個だけを理解していれば十分です。

LD2を点滅させるアプリケーションなどを指定区間へ自作すると、具体的に理解が進みます。

STM32CubeMX使い方:周辺回路のファイル分離

評価ボードのCubeMXプロジェクトファイル(*.ioc)は、デフォルトでB1[Blue PushBotton]とUSART2、LD2[GreenLed]を使っています。これらは、評価ボード実装済み周辺回路です。

これら評価ボード実装済み周辺回路へ、弊社テンプレートを適用したのが、シンプルテンプレートです(表:シンプル追加の欄)。

例えば、B1スイッチ押下げ状態をSW_PUSH、USART送信タイムアウトをUSART2_SEND_TIMEOUTなどソースコードを読みやすくする定義の追加は、CubeMX生成main.hの指定区間へ追記することでもちろん可能です。

しかし、他MCUコアへの移植性や変更のし易さを狙って、あえて別ファイル:UserDefine.hへこれらを記述しています。

同じ狙いで、LD2とB1、USART2のユーザ追記制御部分を、Led.cとSw.c、Usart2.cへファイル分離しています。ファイル分離により、HAL API利用のためMCUコア依存性が無くなり、例えば別コアのF0やG0評価ボードで同じ周辺回路を使う場合は、そのファイルのまま流用可能になります。

これらファイル分離した周辺回路の追記制御部分を、main.cの無限ループと同様に起動するのが、Launcher.cです。

つまり、シンプルテンプレートは、評価ボード実装済み周辺回路に、何も追加せずに弊社テンプレートを適用したシンプルな応用例です。その理解に必要なファイルが、緑:シンプル追加欄の☑で、簡単な順に1~5の番号を付けています。

CubeMXのそのままの使い方で周辺回路を追加すると、生成ファイル数は、赤:9個のままですが生成コード量が増えます。周辺回路の初期設定コード増加は当然ですが、この部分はCubeMX自動生成のためミス発生はありません。

しかし、ユーザコード指定区間へ、追加した周辺回路の制御コードを追記するのは、ユーザ自身です。様々な周辺回路制御が混在し追記量が増えてくると、バグやケアレスミスの元になります。

この対策に、周辺回路毎にファイルを分割し、この分割したファイルへ制御コードを記述するのが、シンプルテンプレートです。1周辺回路の制御コードが1ファイル化されていますので、簡単順位1~5の内容は、どれもとても簡単です。

さらに、ADC制御やLCD制御など、殆どの組込アプリケーションで必要になる周辺回路を追加し、Baseboardと評価ボードを結線、デバッグ済みのアプリケーションがベースボードテンプレートです(橙:ベースボード追加欄の3個)。

ユーザ追加ファイルは、全てMCUコア依存性がありません。CubeMXのHAL APIコード生成を行えば、コアに依存する部分は、CubeMX生成ファイル内に閉じ込められるからです。つまり、ユーザ追加ファイルは、全てのSTM32MCUへ流用できる訳です。

これらシンプルテンプレート、ベースボードテンプレートから新たなSTM32MCUアプリケーション開発を着手すれば、新規にアプリケーションをゼロから開発するよりも初期立上げの手間を省け、さらに機能追加や削除も容易です。

STM32CubeMX使い方:周辺回路プロパティ、既存AN利用法

CubeMXへ追加した周辺回路のプロパティ設定値やその理由、更に、既存アプリケーションノート利用方法など、新しいSTM32CubeIDE開発トラブルを回避し、スムースに開発着手できる様々なTipsをテンプレート添付説明資料へ加えています。

マイコンテンプレートサイトでSTM32Fxテンプレートは2020/05/15、STM32G0xテンプレートは2020/05/30発売開始です。ご購入をお待ちしております。
※STM32Fx/G0xテンプレートV1ご購入後1年以内の方は、後日V2を自動配布致しますのでお待ちください。