MCU：マイコンアーカイブ - 17ページ目 (58ページ中)

FRDM評価ボードOpenSDA接続問題整理

2020年7月22日2020年8月7日 WithHappy

Kinetis E（Cortex-M0+/40MHz、5V Robust）テンプレートv2開発障害となっている評価ボード：FRDM-KE02Z40MのOpenSDAとMCUXpresso IDEデバッガ間の接続問題は、残念ながら未解決です。今回は、このOpenSDA問題を簡単に整理します。また、Linuxによる第2のMCU開発環境構築の新設カテゴリも示します。

Kinetis OpenSDA

OpenSDA Block Diagram（出典：OpenSDA Users Guideに加筆）

Figure 1は、MCUXpresso IDEとKineties MCU間のブロック図です。旧Freescaleは、Kinetis Design Studio：KDSというFreescale製IDEとKinetis MCU評価マイコンボード間の接続は、OpenSDAというインタフェースで接続していました。

このOpenSDAは、KDS直接接続だけでなく、PC（Windows 7）との接続時、File System（USBメモリ）として動作し、クラウド開発環境：mbed開発にも利用できる2種類のプログラミング機能を持ちます。

現在問題発生中のFRDM-KE02Z40MのOpenSDAも、Windows 7当時は問題なく動作していました。その結果、Kinetis Eテンプレートv1発売ができました。

MCUXpresso IDE接続問題（Windows 10）

Freescaleを買収したNXPは、自社LPCと新旧Freescale Kinetis両マイコンに新しい統合開発環境：MCUXpresso IDEを用意しました。このMCUXpresso IDEの評価ボード接続インタフェース一覧（一部抜粋）が下図です。

MCUXpresso SDK support platform（出典：Getting Started with MCUXpresso）

簡単に説明すると、MCUXpresso IDEは、NXP純正評価ボードEVKやLPCXpresso54xxx接続インタフェース：CMSIS-DAPと、新旧FRDM評価ボード接続インタフェース：OpenSDA v1系/v2系とmbedの3種類全てをサポートします。

接続問題が発生するのは、OpenSDAの一部です（表内にFRDM-KE02Z40Mが無いのは不安ですが、記載漏れだと思います）。FRDM-KL25Z（Cortex-M0+/48MHz、General Purpose）のOpenSDAは、MCUXpresso IDEと問題なく接続できています。

接続問題解決には、Figure 1のMSB Bootloaderを、MCUXpresso IDE対応済みの最新版へUpdateすることが必要です。

MSB Bootloader更新注意点（Windows 10）

MSB Bootloader更新方法は、評価ボードのリセットボタンを押しながらPC（Windows 10）とUSB接続し、エクスプローラーに現れるBootloaderフォルダへ、最新版：BOOTUPDATEAPP_Pemicro_v118.SDAをドラッグ＆ドロップするだけです（FRDM-KE02Z40Mの最新Bootloaderは、コチラから取得できます）。

この操作後、再度評価ボードとPCを接続すると、今度はエクスプローラーに通常モードのFRDM-KE02Z40Mフォルダが現れ、更新完了となるハズです。ところが、筆者の評価ボードは、Bootloaderモードから通常モードへ復帰しません。

従って、MCUXpresso IDEとFRDM-KE02Z40MをUSB接続しても、IDEは評価ボード無しに認識します。

簡単に説明しましたが、実際はWindows 10でのBootloader 更新時、「Windows 7では不要であったストレージサービスの一時停止が必須」です（詳細は、コチラのNXP情報のStep 2を参照してください）。

調べると、Windows 8以降に一般的なユーザには知らせずに追加したWindows PCのUSBメモリへの隠しフォルダ書込み機能（これが上記一時停止するストレージサービス）が、諸悪の根源のようです。

FRDM評価ボードOpenSDA接続問題整理と対策（Windows 10）

以上を整理し、対策をまとめます。

・旧Freescale製FRDM評価ボードが、新しいNXP MCUXpresso IDEと接続できない原因は、評価ボードOpenSDAのMSB Bootloaderにあり、対策は、MCUXpresso IDE対応版Bootloaderへの更新を、Windows 10ストレージサービスを停止させた状態で行うことが必要。

旧Freescale製（つまりWindow 7対応）のまま入手したFRDM評価ボードは、FRDM-KE02Z40M以外でもIDE接続問題が発生することがありますので、上記まとめを参考に対策してください。

このまとめと対策にたどり着く前に、Windows 10でストレージサービスを停止せずにFRDM-KE02Z40MのOpenSDA MSB Bootloader更新を何度か繰返しました。評価ボードが、Bootloaderモードから通常モードへ復帰しない理由は、これかもしれません😥。

筆者は、Windows 7時代からFRDM評価ボードを活用してきました。まさか、Bootloaderモード時にWindows 10ではサービス一時停止が必須だとは思いもしませんでした。しかも、このサービスは隠しフォルダ対応なので、通常ではWindows 7と同様にBootloader更新が正常終了したように見えます。

事前に調査しなかった筆者が悪いのですが、旧Freescale評価ボード記載Windows 7対応マニュアル通りに対処すれば、筆者と同じトラブルに出会う人は多いハズです。

また、OpenSDAユーザズガイドにも上記トラブルからの復帰方法の記載はありません。ネット検索か、NXP communityが解決手段でしょう😥。解決方法が見つかれば、本ブログでお知らせします。

エンドユーザを無視したかのようなWindows 10の度重なる変更に起因するトラブルは、今後も増える可能性があると思います。次章は、その対策です。

Windows MCU開発者向けLinuxカテゴリ新設

筆者は、昨年からLinux MintでのMCUXpresso IDE開発環境もWindows 10のバックアップ用に構築しています。このLinux環境でも、残念ながら今回のトラブル回復はできていません。

今回はLinux/Windows両方NGでしたが、Windows以外の第2のMCU開発環境があると、何かと便利です。

そこで、本ブログで、Windows MCU開発に慣れた開発者が、簡単にLinuxを使うための情報も発信したいと思います。このための新設カテゴリが、PC：パソコン＞Linuxです。
※親カテゴリPC：パソコンへ、LibreOfficeとWindowsも移設しました。

Windows 10、Linuxともに単なるPC OSです。Linux上でMCU開発アプリケーション、本ブログではNXP MCUXpresso IDEやSTM STM32CubeIDEを利用するために、最低限必要な情報に絞って説明する予定です。

Linux情報量もまたWindows同様多いのですが、Windowsに慣れたMCU開発者としては、当面不要な情報も多く、Windowsの代わりにLinuxを短期間で効率的に活用するMCU開発環境構築が目標・目的です。今回のようなWindows PCでのトラブル発生時、Linux PCへ移ってMCU開発を停止することなく継続するのが狙いです。

MCU Devopments Windows and Linux 2 Routes

Linuxのシステム動作要件は下記で、Windows 10よりも低いので、古いPCでも快適に動作します。ただし新しいOS利用なら「64ビットCPUは必須」ですが…😅。32ビットPC OSの新規開発は、終了しました。

1GB RAM (2GB recommended for a comfortable usage)
15GB of disk space (20GB recommended)
1024×768 resolution

COVID-19の影響で、市場に中古PCが安価で数多く出回っていますので、これら活用も一案かと思います。

MCUXpresso Config Toolsの使い方

2020年7月17日2020年7月31日 WithHappy

前稿に続きMCUXpresso SDKベースのMCUソフトウェア開発に欠かせないMCUXpresso Config Toolsの使い方を説明します。SDKサンプルプログラムに少しでも変更を加える時には、Config Toolsが必要になります。

Config ToolsとSDK

MCUXpresso IDEのSDKサンプルプロジェクトは、そのままコンパイルして評価ボードで即動作可能です。ユーザが変更を加える箇所は、sourceフォルダ内に限られています。sourceフォルダ以外は、ライブラリフォルダです（詳細は、前稿を参照してください）。

Config Toolsは、このSDKライブラリに変更を加えるツールです。

SDKサンプルプロジェクトは、MCU内蔵周辺回路の動作例ですが、逆に言うと、「その周辺回路しか動作させない例」です。低電力動作が必須のMCUでは、しごく当然のこのソフトウェア作法、つまり無用な回路は動作させない方針で開発されています。

ところが、SDKサンプルプロジェクトにユーザが変更を加える場合、サンプルプロジェクトで動作中の回路以外の周辺回路動作を新たに加える時があります。

この時には、MCUXpresso Config Tools>>をクリックし、MCU内蔵の眠っている（＝Inactive）周辺回路の目を覚ます（＝Activate）必要があります。

周辺回路をActivateした結果、サンプルプロジェクトのSDKライブラリに対して、相応の変更をConfig Toolsが自動生成（上書き）します。これが、Config ToolsとSDKの関係です。

Config Toolsの使い方

具体的にFRDM-KL25Z（Cortex-M0+/48MHz、General Purpose）評価ボードのSDKサンプルプロジェクト：gpio_led_outputを例に、Config Toolsの使い方を説明します。このサンプルプロジェクトは、いわゆるLチカサンプルで、評価ボード上の赤LEDを点滅させます。

ここでは、赤LEDの代わりに緑/青LEDを点滅させる変更をユーザが加えると想定します。

※他のサンプルプロジェクトも、殆ど赤LED（BOARD_RED_LED）1個のみを動作させますので、この緑/青LED変更方法は、多くのサンプルプロジェクトにも流用できます。

MCUXpresso SDKのgpio_led_outputソースコード（一部抜粋）

先ずConfig Toolsを使わずにL40とL41のRED_LEDをGREEN_LEDへ変更後、Buildします。その後、DebugでFRDM-KL25Z評価ボードを動作させても緑LEDは点滅しません。もちろん、ブレークポイントをL92に設定して動作は確認済みです。

LEDが点滅しない理由は、評価ボードの緑/青LEDに接続済みのgpioピンが、Inactiveだからです。

対策にMCUXpresso Config Toolsをクリックすると、Develop画面がPins画面へ変わります。

Routed Pinsタブ①に、GPIOB：LED_REDがリストアップされています。このリストは、Activate済みの全ピンを示します。

そこで、Peripheral Signalsタブ②で緑/青LEDのGPIOB、19とGPIOD、1に✅を入れると、リストに両ピンが加わります。Identifierは、LED_GREENとLED_BLUEにします。

MCUXpresso Config ToolsでActivateした緑と青LEDのgpioピン

この状態で、「緑色」のUpdate Codeボタン③をクリックすると、Update Filesダイアログが開き、上書き対象のSDKライブラリが一覧表示されます。この場合は、ライブラリ：board>pin_mux.c/hとboard>clock_config.c/hが上書き更新されます。

ダイアログのOKクリックで最終的にSDKライブラリへ変更が加わり、自動的にDevelop画面に戻ります。上書きされるライブラリのソースコードは、Pins画面上のCode Previewタブ④でも更新前に確認ができます。

戻ったDevelop画面で、RED_LEDをGREENやBLUE_LEDへ変更し、Build を再実行、Debugすると、今度は評価ボードの緑/青LEDが点滅します。

Config Toolsが、緑/青LED接続のgpioピンをActivateしたSDKライブラリに上書き更新したからです。

このようにSDKサンプルプロジェクトは、必須周辺回路とクロックルートのみをActivateした例で、その周辺回路単体でのMCU消費電力も判ります。この時のクロック周波数は、MCU最高動作周波数です。周波数を下げることで消費電力も減らせますが、その分ソフトウェア開発の難易度は上がります。

機能的には似た周辺回路がある場合や、特に電力消費が大きい回路を比較・最適化し、MCUトータル消費を改善する手段としてもサンプルプロジェクトは利用できます。

MCU電力低減方法は、SDK/Config Toolsデフォルトの最高周波数でソフトウェアを開発し、次に周波数を下げるアプローチが適すと言えるでしょう。

Config ToolsのUpdate Code

SDKサンプルプロジェクトに何も変更を加えずに、Config Toolsをクリックしても、Update Codeボタンが「緑色」になる場合があります。Update Codeボタンの灰色は、上書きするSDKライブラリが無いことを示します。この場合は、変更を加えていないので、本来「灰色」のハズです。

これは、元々のSDKライブラリが手動生成、または旧Config Toolsで生成していて、IDE付属の最新Config Toolsの上書き版と（機能的には同じでも）異なる場合があるからです。例えば、ライブラリコメントが変わる場合などが相当します。

気になる方は、SDKサンプルプロジェクトを最初にIDEへImport後、直にConfig Toolsを起動し、Update Codeを一度実行しておけば、次回からユーザ変更が無ければ、灰色でボタン表示されます。

新規プロジェクトのConfig Tools

Config Toolsの使い方に本稿では、SDKサンプルプロジェクトのLチカサンプル点滅LED変更を例にしました。この使い方は、MCUXpresso IDEで新規プロジェクト作成時でも同じです。

新規プロジェクト作成時、初めからMCU内蔵周辺回路のSDKドライバを全て実装したとしても、消費（浪費）されるリソースはFlash/RAM容量のみです。周辺回路やクロックルートのほとんどは、Inactiveが初期値で、ActivateはUART0程度です。

そこで、IDE新規プロジェクト作成後、先ずConfig Toolsで使用予定の周辺回路やクロックルートをActivateし、それらに対応したSDKライブラリをUpdate Codeで上書き更新、最後にユーザ処理を記述するという順番になります。

MCUXpresso IDEソフトウェア開発要点

NXPのMCUXpresso IDEは、SDKベースのMCUソフトウェア開発を行います。

SDKには、多くのサンプルプロジェクトがあり、これらを上手く活用すると、効率的で汎用的なMCUソフトウェア開発が可能です。

SDKサンプルプロジェクトは、対象周辺回路とクロックルートのみを動作させる基本に忠実な作法で開発しているため、ユーザがプロジェクトへ変更を加える時、新たな周辺回路のActivateが必要な場合があります。

Config Toolsは、MCU全内蔵回路とクロックルートを、GUIで簡単にActivate/Inactive変更ができ、その結果として、更新の必要があるSDKサンプルプロジェクトのライブラリを上書き更新します。

NXPのMCUソフトウェア開発は、MCUXpresso IDEに備わったSDKとConfig Tools両方の活用が必須で、前稿と本稿の2回に分けてその使い方を説明しました。

MCUXpresso SDKの使い方

2020年7月10日2020年7月22日 WithHappy

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

投稿時点の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プロジェクト（右）

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+変化

2020年7月3日2020年7月10日 WithHappy

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

そこで、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個です。

評価ボードは、プロトタイプ開発には必須で、その評価ボードで動作する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ラインナップ

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

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ラインナップ

上図から、おおむね青色の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サイト）

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より抜粋）

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の日本市場位置づけと事業戦略

2020年6月19日2022年1月5日 WithHappy

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の提供する半導体デジタル/アナログ技術（出典：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耐圧ピン

2020年6月12日2020年6月19日 WithHappy

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

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データシート）

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

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

MCUの５V耐圧ピン：5V Tolerant MCU Pad

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

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直接制御例

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

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

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

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

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

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

NXPのFreeMASTER

2020年6月5日2020年7月18日 WithHappy

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）

両者の機能境界が、ソースコードのデバッグ機能です。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構成

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

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発売

2020年5月29日2020年6月5日 WithHappy

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）

汎用性とセキュリティの両方を持つ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化

2020年5月22日2020年5月31日 WithHappy

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

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

STM32G0シリーズ特徴

Dead Battery機能デフォルト有効（出典：マンスリー・アップデート2019年7月）

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

STM32G042/G031/G030新登場（出典：マンスリー・アップデート2020年1月）

STM32マイコンでRoot of Trust実現のX-CUBE-SBSFU（出典：マンスリー・アップデート2020年3月）

報告は、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にも対応するかもしれません。