カテゴリー: Cortex-M4コア

ATM Cortex-M4コアマイコン関連の情報をまとめています。

IoT MCUコア次世代像

WithHappy

PCのCPUは、IntelとAMDの2社が独占状態でした。しかし、AppleがARMベースの新CPU：M1を発表し、そのコストパフォーマンスは、Intel/AMDの3倍（！）とも言われます（記事：「ソフト技術者もうなるApple「M1」の実力、新アプリに道」や、「Apple M1の実力を新世代のIntel/AMD CPUと比較」など）。

本稿は、これらPC CPUコアの現状から、次世代IoT MCUコアの3層構造と筆者希望的観測を示します。

CPUコア：Apple/Intel/AMD

筆者が学生だった頃は、マシン語のPCソフトウェアもありました。CPUコア性能が低いため、ユーザ要求を満たすアプリケーション開発には、ソフトウェア流用性や開発性を無視したマシン語開発もやむを得ない状況でした。

現在のCPUコア性能は、重たいGUIやネットワーク処理を複数こなしても、ユーザ要求を満たし、かつ流用性も高いC/C++などの高級言語でのアプリケーション開発が普通です。Appleは、この状況でIntel/AMDコストパフォーマンス比3倍のM1 CPUを開発しました。

このM1 CPUを使えば、従来CPUのボトルネックが解消できるために、より優れたGUIや新しいアプリケーションの開発が期待できます。

このM1実現の鍵は、5nmルールの製造技術と新しいCPU設計にあるようです。

MCUコア：ARM/Non ARM

MCUはARMコアとNon ARMコアがありますが、Non ARMコアのコストパフォーマンス比は、M1程ではありません。従って、主流はARM Cortex-M系シングルコア採用MCUで、事実上ARMコア独占状態です。開発言語はC言語でベアメタル開発、製造プロセスも数10nmと、いわば、数10年前のIntel独占CPUコアに近い状況です。

RISC-Vという新しいMCUコアも出てきましたが、まだ少数派でその性能も未知数です。Intel/AMD CPUと比較記事の最後に記載された「競争こそユーザの利益」には、MCU世界はなっていません。

ARMはコア設計図のみ提供し、デバイス実装はMCUベンダが担当します。従って、現状のMCU世界が続く場合には、MCU高速化は製造技術進化とマルチコア化が鍵です。

ARMは、エッジAIに向けたNPUを発表しました。独自MCUコアと付随する開発環境を提供でき、かつコストパフォーマンスがARMコアの数倍を実現できるMCUベンダが無い現状では、ARMの頑張りがIoT MCUを牽引すると思います。

※NVIDIAによるARM買収が、今後のARM動向に及ぼす影響は気になる状況ではあります。

IoT MCUコア

MCUコアとCPUコアの一番の差は、ユーザ要求コストです。これは、同じコアのMCU製品に、内蔵周辺回路やFlash/RAM容量の異なる多くのデバイスをベンダが提供中であることからも解ります。ユーザは、MCUに対して無駄なコストは払いたくないのです。

つまり、MCUデバイスはアプリケーション専用製品、CPUデバイスは超汎用製品、ここが分岐点です。

IoT MCUには、エッジAI、セキュリティ、無線通信（5GやWi-Fi）などのIoT機能追加が必要です。これら機能を並列動作させる手段として、RTOSも期待されています。この状況対応に、MCUコアも高性能化やマルチコア化に進化しつつあります。

セキュリティや無線通信は、予め決まった仕様があり、これら対応の専用ライブラリがベンダより提供されます。但し、セキュリティは、コストに見合った様々なセキュリティレベルがあるのも特徴です。ソフトウェア技術者は、専用ライブラリのMCU実装には神経を使いますが、ライブラリ本体の変更などは求められません。この仕様が決まった部分を「IoT基本機能」と本稿では呼びます。

MCUソフトウェア開発者が注力すべきは、ユーザ要求に応じて開発するIoTアプリケーション部分です。この部分を、「IoT付加機能」と呼び、「IoT基本機能」と分けて考えます。

ユーザのアプリケーション専用MCU製品意識は、IoT MCUでも変わりません。例えば、IoT基本機能の無線機能は不要や、ユーザがコストに応じて取捨選択できるセキュリティレベルなどのIoT MCU製品構成になると思います。一方、IoT付加機能だけを実装するなら、現状のMCUでも実現可能です。

以上のことから、IoT MCUは3層構造になると思います。

IoT MCUコアの3層構造
IoT MCUコアの3層構造
層 機能 追記
Back End IoT MCU IoT基本機能＋付加機能＋分析結果表示 収集データ分析結果ビジュアル表示
IoT MCU IoT基本機能＋付加機能 高性能、マルチコア、RTOS利用
Front End IoT MCU センサデータ収集などのIoT付加機能
最小限セキュリティ対策		 収集データは上層へ有線送信
コスト最重視

最下層は、ユーザ要求アプリケーションを実装し、主にセンサからのデータを収集するFront End IoT MCUです。ここは、現状のARM/Non ARMコアMCUでも実現できIoT付加機能を実装する層です。デバイスコスト最重視なので、最小限のセキュリティ対策と収集データを有線、または無線モジュールなど経由で上位IoT MCUへ送信します。IoT MCUサブセット版になる可能性もあります。

中間層は、高度なセキュリティと市場に応じた無線通信、エッジAI機能などのIoT基本機能がフル実装できる高性能MCUコアやマルチコア、RTOS利用へ進化した層です。IoT付加機能も同時実装可能で、下層の複数Front End IoT MCUが収集したセンサデータを、まとめて上位Back End IoT MCUまたは、インターネット空間へ直接送信できます。製造技術進化とマルチコア化、ARM新コア（Cortex-M23/33/55など）が寄与し、IoT MCUの中心デバイスです。

最上層は、第2層のIoT MCU機能に加え、インターネット空間で収集データを分析・活用した結果をユーザへビジュアル表示する機能を追加した超高性能MCUコア活用層です。自動車のADAS（Advanced Driver-Assistance Systems：先進運転支援システム）のおかげでユーザへのビジュアル表示要求はより高度になります。このユーザ要求を満たす次世代の超高性能IoT MCU（またはMPU）が実現します。

最下層のFront End IoT MCUは、現状のCortex-M0+/M4コアで弊社テンプレート適用のMCUが生き残ってほしい、というのが筆者の希望的観測です。
それにしてもAppleのコスパ3倍M1、凄いです。iPhoneもそうですが、抜きん出た技術と経営能力、Jobs精神、健在ですね。

総務省IoT入門オンライン講座

WithHappy

総務省総務省が、2021年3月24日まで無料IoT入門オンライン講座を開設しています。IoT基礎知識、IoT技術・関連法制度、IoT活用の全3章から成るPDF配布資料（A4/36ページ）付きで各ページ冒頭に2行程度のまとめ表記があります。

※受講方法は、コチラの記事を参照してください。

資料作成日：令和元年10月

COVID-19パンデミック前、令和元年：2019年10月作成資料に沿ったオンライン講座です。関連法の導入時期などに、COVID-19の影響があるかもしれません。

※関連投稿：総務省2020年4月以降IoT機器アップデート機能義務化予定（2019年9月13日）に関する記載は、資料内にはありません。

資料フォーマット

A4縦ページの上方にスライド、下方にテキスト、いわゆるパワーポイントノート形式の配布資料です。タイトル直下、スライド冒頭に2行程度のまとめ表記があり、このまとめでページ内容が解ります。

オンライン講座は、主にスライド部分を使います。配布資料を読めば、講座内容はほぼ取得できると思います。

IoT入門オンライン講座資料の印象点

A4パワーポイントノート形式のIoTオンライン講座配布資料、良くまとまっています。

資料のWeb転載は禁止ですので、本ブログ読者は配布資料を取得済みと考え、筆者がページ毎に印象に残った点をピックアップします。

※タイトル、まとめ表記は、配布資料を基に簡素化しています。

頁 タイトル まとめ表記 印象点
13 IoT構成機器 IoTシステム構成は3要素 データ収集、分析結果表示がIoTデバイス
14 データ収集 センサでデータ収集 8種センサ概要説明
15 IoTデバイス通信 有線と無線の2種 有線/無線のメリット/デメリット分析
17 無線電波周波数 最適な周波数 波長/周波数/呼び名/特徴分析
18 電波法 電波利用法 無線利用時「技適マーク」必須
19 無線通信 距離・速度・消費電力 無線規格特徴一覧、選択に便利
23 セキュリティ 機密性・完全性・可用性 機密性と完全性と可用性維持がセキュリティ
24 セキュリティ対策 リスクと対策 IoT特有性質とリスク分析
25 セキュリティ対策 対策の5指針 5指針と21要点、具体例一覧
26 標準化動向 標準技術メリット 4標準化団体と最新技術動向把握重要
28 IoT進め方 アイデア → 試行錯誤 プロトタイプで試行錯誤 → 導入
29 ビジネス設定 IoT解決課題設定方法 情報整理に3C/SWOT/KPT活用
30 アイデア案出 IoT活用の3段階 アイデア案出方法
31 アイデア優先順位 効果と実現可能性 効果、実現可能性の考慮方法
32 データ留意点 利害関係調整と個人情報保護 具体的留意点説明
33 運用後の対応 想定と対応策 想定具体的トラブル説明

P28のIoTデバイスをプロトタイプで試行錯誤し開発する手法は、弊社マイコンテンプレートを利用すると、「複数デバイスで実証・比較評価できるなどより効率的・実践的」になります。

マイコンテンプレートのMCUデバイスはどれも汎用MCUですが、開発者のナレや接続センサとADCの使い方により差は生じます。さらに、デバイス消費電力も、開発ツールシミュレーションと評価ボードで評価します。最もアイデアに適し開発し易いMCUは、実はプロトタイプ化しなければ判らないと思います。

配布資料は、「IoTデバイスを中心」に基礎から導入後の運用など、IoT全般に関する幅広い内容です。IoTデバイス開発者の頭の中を整理、開発後のデバイス活用・運用などを予見する場合にも役立ちます。

資料にもCOVID-19影響？

スライド利用のプレゼンテーションは、パワーポイント/Impress（LibreOfficeパワーポイント相当）の資料作成が標準です。一方、弊社テンプレート配布資料は、A3 Visio/Draw形式で作成しています。これは、横長PCモニタ表示を前提としているからです（印刷時、70%縮小A4横出力想定）。

COVID-19の影響で、プレゼンテーションも対面からオンラインへ変わりつつあります。配布資料も従来のようにパワーポイント/ Impress形式が良いか、Visio/Draw形式か、モニタも3:4サイズが良いか、9:16かなど、配布資料フォーマットにも今後影響がでるかもしれません。

弊社テンプレート開発、配布資料のご意見、ご要望などは、info@happytech.jpへお寄せください。

IoT MCU汎用Baseboardの汎用性

WithHappy

・IoT MCU汎用Baseboardの特徴
・CMOSデバイス直結を利用し、3.3V動作MCUソフトウェア開発に5V動作ハードウェアを使えること

をFRDM-KL25Z（動作範囲：1.71～3.6V、5V耐圧なし）を例に前稿で示しました。
このIoT MCU汎用Baseboard の汎用性について解りにくいというご指摘がありましたので、説明を加えます。

IoT MCU汎用Baseboard構成パーツ

IoT MCU汎用Baseboardの構成パーツが下図です。

Arduinoコネクタ有りのMCU評価ボードはFRDM-KL25Zを掲載しましたが、Arduinoコネクタを持たない例えば、Cypress）PSoC4000SなどのMCU評価ボードでも接続可能です。これが汎用性をうたった理由です。

様々な追加Arduinoシールドは、Arduinoコネクタでスタック接続、それ以外のパーツ間は、オス－オスコネクタで接続します。

IoT MCU汎用Baseboard構成（色付き領域）
IoT MCU汎用Baseboard構成（色付き領域）

一言で言うと、従来から使ってきた5V Baseboardに、Arduinoプロトタイプシールドを追加した構成です。

IoT MCU汎用Baseboard構成パーツの役割

パーツ名 機能、役割
MCU評価ボード 動作電圧：3.3V/5V動作のMCUソフトウェア開発ボード
外部ハードウェア接続：Arduinoコネクタ/独自コネクタ
追加Arduinoシールド IoT向けセンサなどをMCU評価ボードへ機能付加
Arduinoプロトタイプシールド シールド直上へスタック接続（Arduinoピン名シルクあり）
配線済みMCUリセット、未配線2個LED、1個SW実装済み
MCU評価ボード直上設置で操作性向上
5V Baseboard LCDやポテンショメータなど5V動作ハードウェア搭載
オス－オスコネクタ ボード、各パーツ間接続
Arduinoコネクタ Arduinoシールドスタック接続
CMOSデバイス直結 3.3V MCU出力→5Vハードウェア入力：接続問題なし
5Vハードウェア出力→3.3V MCU入力：5V耐圧無しなら3.3V以下
付属ブレッドボード CMOSデバイス直結時、電流保護抵抗や必須ハードウェア搭載

MCUに5V耐圧が無い時は、MCU入力電流保護抵抗や入力電圧を3.3V以下へ抑える必要があり、これら必須ハードウェア、およびArduinoプロトタイプシールド付属の2個LED、1個SW配線用に、プロトタイプシールド付属ブレッドボードを使います。

IoT MCUは、MCU評価ボード搭載済み機能だけでなく、様々なセンサや付加機能（例えば、構成パーツで示したデータロギングシールドなど）を追加して開発します。これら追加センサや付加機能ハードウェアを、安く早く調達するには、既製Arduinoシールドが適しています。

殆どのMCU評価ボードがArduinoシールドを追加できるように設計されているのはこのためです。Arduinoプロトタイプシールドは、Arduinoピン名がシルク印刷済みです。Arduinoピン名とMCUピン名のマッピングを間違う可能性も低く、リセット追加で制御系の操作性も向上します。

Arduinoコネクタ実装済みのFRDM-KL25Zの場合は、直上、または直下へArduinoシールドをスタック追加します。FRDM-KL25Z追加シールド処理結果を表示するため、プロトタイプシールド経由で5V Baseboard LCDと接続します。

独自コネクタで機能追加するPSoC4000S評価ボードなどに対しても、オス－オスコネクタでArduinoプロトタイプシールドと接続すれば、それ以外の部分は共通です。この時は、プロトタイプシールド直下にArduinoシールドを追加します。

※Arduinoシールドを複数追加する時は、スタック接続します。

様々なMCU評価ボードに対して、表中のMCU評価ボード以外の赤字パーツが汎用的に使え、かつ、Arduinoシールド追加性にも優れていることがお解り頂けたと思います。

IoT MCU汎用Baseboard用途

CMOSデバイス直結は、ハードウェア担当者からは、気持ちが悪いと言われるかもしれません。

この場合は、CMOSデバイス間にバス・スイッチ（SN74CB3T3245）を挿入すれば、パッシブデバイスですので高速性や信頼性、ノイズに対しても安心です。もちろん、動作ソフトウェアは同じものです。詳細は、関連投稿：3.3V MCUと5Vデバイスインタフェースを参照してください。

このIoT MCU汎用Baseboardは、早く、安くIoT MCUソフトウェア開発をするためのソフトウェア担当者向けツールという位置づけです。製品化にあたっては、ハードウェア担当者も安心するようにバス・スイッチの利用をお勧めします。

Firefox Send終了

WithHappy

クラウドファイル共有サービス：Firefox Sendが2020年9月17日終了となりました。弊社テンプレート配布に最適なFirefox Send終了、残念です。代替にGoogle Driveを使いますが、送受双方に手間が1つ増えます。

本稿は、この増えた手間を説明し、セキュリティと利便性が相反することを示します。

Firefox SendからGoogle Driveへクラウドファイル共有サービス変更
Firefox SendからGoogle Driveへクラウドファイル共有サービス変更

Firefox SendとGoogle Drive比較

Firefox Sendは「ファイル共有」専門サービス。共有ファイル保存期間はアップロード後最大7日、または、ダウンロード1回で共有ファイルがオンライン上から自動的に消去されるなど、「ファイル保存」が主目的のGoogle Driveにない使い勝手がありました。

ファイル共有Firefox Sendとファイル保存Google Drive比較
Firefox Send Google Drive
ファイル共有期間 最大7日 設定不可
受信側ダウンロード回数 1回 設定不可
利用料金 無料（最大2.5GB） 無料（最大15GB）
ダウンロード側ログイン 不要 不要
パスワード保護 可能 可能
特徴 ファイル共有に最適 ファイル保存に最適

共有ファイルダウンロードリンクを送信側から受信側へメール通知、受信側がFirefox/Chrome/Edgeなどのモダンブラウザを使って共有ファイルダウンロードに成功しさえすれば、ファイル共有は終了です。ここまでは、Firefox SendとGoogle Drive全く同じです。Firefox Sendは処理完了です。

違いは、Google Driveがファイルの共有期間やダウンロード回数の制限を設けることができない点です。また、受信側が共有ファイルをダウンロードしたことを、送信側が知る手段もありません。

Google Driveでのダウンロード成功後、受信側に成功通知メールをお願いするのは、Firefox Sendでは自動で行われる共有ファイル削除、または、共有停止を送信側が手動にて行うためです。

Firefox Sendに比べ、Google Driveでは送受双方に処理完了までにこの手間が1つ余分に掛かる訳です。

Firefox Send終了理由

Firefox Sendサービス終了の理由は、マルウェア配布手段として悪用されるケースが増え、開発元Mozillaがサービスラインナップ全体コスト、戦略的焦点を見直した結果と発表されています。

高度な暗号化とファイル自動消去のFirefox Send共有サービスは、Firefoxという誰にでも知られた信頼性の高いダウンロードリンククリックだけで簡単にマルウェアをデバイスへ送れます。一般のユーザだけでなく、ハッカーにとっても便利なツールとして悪用されたのでしょう。

無料一時保存ファイルのマルウェア排除を実施することは、無理だとMozillaがあきらめたのだと思います。ただ、次々に生まれるマルウェア排除は、たとえ有料でも困難かもしれませんが…。

セキュリティと利便性の相反例です。また、セキュリティとその対価：費用対効果を考えさせる例でもあります。

企業が自社クローズドサーバーでのみ社員ファイル共有を許可するのは、費用対効果の実現解なのでしょう。
※同様に、IoT MCU開発でもセキュリティ実現解検討が必須です。

Google Drive代替理由

Firefox Send代替にGoogle Driveを選んだ理由は、ファイルの「ダウンロード前や共有前」に、ウィルススキャンが自動的に行われるからです。ウィルス検出時は、警告表示があります。

※ウィルススキャンは圧縮ファイルでも実施されます。但し、パスワード保護を行うとスキャン不可能になりますのでパスワードは設定しません。Firefox Sendでもこれら処理は実施されていたと思いますが…、ハッカーはパスワード保護でスキャンをかわしたのだと思います😥。

無償、セキュリティ、信頼度の高さ、モダンブラウザで利用できる点、これらからGoogle Driveを代替として弊社は選びました。

全テンプレート継続販売

販売中の弊社テンプレートは、戦略的焦点（？？？）から販売継続いたします。販売中止のサイト変更手間と消えるリンク対応などを考慮すると、そのまま継続販売する費用対効果が高いからです。

本ブログでは、その時々に応じてテンプレート販売中止・終了予定なども記載しますが、マイコンテンプレート名が購入サイトに掲載している限り販売は継続いたしますので安心（？）してご購入ください😌。

FRDM-KL25Z GPIOの使い方

WithHappy

5V耐圧GPIOピンが無い3.3V動作FRDM-KL25Zへ、5V LCDをCMOSデバイス直結で接続し、その動作確認ソフトウェアを開発中です（CMOSデバイス直結は、関連投稿：3.3V MCUと5Vデバイスインタフェースを参照してください）。

開発途中、FRDM-KL25Z搭載MCUのKinetis KL25ファミリに、GPIOの拡張とも言える興味深いFGPIO機能、BME機能を見つけたのでFRDM-KL25Z GPIOの使い方に加え解説します。両機能は、Kinetis KL25の高速化に効果があります。

※FGPIO：Fast GPIO、高速処理でGPIO記述ソースコードからの変更容易。
※BME：Bit Manipulation Engineはレジスタ読書きとビット操作が同時可能なMCU内蔵ハードウェア。コードサイズ削減と高速処理が同時に可能。

FRDM-KL25Z GPIOの使い方

FRDM-KL25ZのGPIO API一覧が下記です。MCUXpresso IDEのソースコード上でgpio_と入力し「Ctrl＋スペースキー」を押すと、GPIO_で始まるAPIが一覧表示されます。これが、Content Assist機能です。

MCUXpresso IDEのContent Assistを利用したGPIOの使い方
MCUXpresso IDEのContent Assistを利用したGPIOの使い方

先頭〇がGPIO_API関数、#がdefineで定義したマクロです。GPIO_API本体は、fsl_gpio.hで定義されています。

例えば、GPIO_ClearPinsOutputを選ぶと、残りの変数：GPIO_Type *baseとunit32_t maskを入力すればソースコード上でGPIO_ClearPinsOutput APIの入力完了です。

*baseは、GPIOAやGPIOBなどのポート名、maskは、制御対象ピン以外のマスクです。GPIOBの18番ピンが対象なら、GPIO_ClearPinsOutput(GPIOB, 1<<18)と記述します。

Content Assistの一覧表示リストを見ると、FRDM-KL25ZのGPIO APIに特に変わったAPIはありません。ごく一般的なGPIOの使い方であることが判ります。

GPIOに限らずContent Assistは、APIレファレンスマニュアルを参照するよりAPI選択と変数のソースコード入力が早く便利にできます。もちろん、ユーザが追加定義したマクロでも自動的にリスト表示されます。

FRDM-KL25Z FGPIOの使い方

KL25 Sub-Family Reference Manualの図3-9は、MCUからGPIO Controllerへの経路が、下記2種類あることを示しています。

FGPIOとGPIOアクセスの違い（出展：KL25 Sub-Family Reference Manual）
FGPIOとGPIOアクセスの違い（出展：KL25 Sub-Family Reference Manual）

GPIO：MCUからPeripheral Bridge経由のGPIO Controller制御
FGPIO：MCUからGPIO Controller直接制御（Single-cycle I/Oとも呼ばれる）

特筆すべきは、レジスタ構成がGPIOとFGPIOで全く同じなので、GPIOソースコード記述が、
GPIOB_PTOR = (1<<18);    //  GPIOでFRDM-KL25Zの赤LED：PTB18をトグル
の場合、これをFGPIOへ変える場合は、
FGPIOB_PTOR = (1<<18);  // FGPIOでFRDM-KL25Zの赤LED：PTB18をトグル
とGPIOをFGPIOへ変更すれば済むことです。

※GPIOB_PTOR = (1<<18)は、レジスタ明示記述、同じことをGPIO_APIで記述すれば、GPIO_TogglePinsOutput(GPIOB, 1<<18)となります。どちらもContent Assistが使えます。

但し、2サイクルアクセスGPIOの半分、FGPIOの1サイクルアクセス実効速度を得るには、コンパイラ最適化オプションを、デフォルト最適化なし：None(-O0)から、Optimize (-O1)、または、それ以上にする必要があります。

FRDM-KL25Z BMEの使い方

前章GPIO経路の途中にBMEハードウェアがあります。BMEを使うと、Peripheralsレジスタの読書きとビット操作を同時、つまり、ソースコード記述1個で可能になります。

BMEを使うソースコードは、下記5種類です。

書込み時
・Store Logical AND/OR/XOR (AND/OR/XOR)
・Store Bit Field Insert (BFI)

読込み時
・Load-and-Clear 1 bit (LAC1)
・Load-and-Set 1 bit (LAS1)
・Load Unsigned Bit Filed Extract (UBFX)

アセンブラ記述に似ています。詳細は、KL25 Sub-Family Reference Manualの17章BMEを参照してください。

BMEを使うと、ソースコード記述が減るので、処理時間とコードサイズの両方を軽減でき高速化可能です。

一般的なGPIOソースコードで記述した周辺回路の初期設定や無限ループ内処理をあらためて見直すと、BMEが使える箇所が見つかります。

GPIO、FGPIO、BMEの使い方

最初に1章で示した一般的なGPIO記述でソフトウェアを開発し、最後の高速化手段としてFGPIOやBMEを使うのが良いと思います。理由は、FGPIOは最適化、BMEはソースコード内にレジスタ読書きとビット操作の両方が必要な個所があることが前提だからです。

FGPIOはGPIO記述ソースコードからの変更が容易です。コンパイラデフォルトの最適化なし：None(-O0)でコード変更し、求める高速要件が満たされれば、利用価値は高いでしょう。この場合は、100%の1サイクルアクセス実効速度までは得られませんが、FGPIO高速化ができます。

経験上、最適化利用に筆者は消極的です。様々な副作用もあるからです。

最適化よりも超低消費電力/低コストが特徴のFRDM-KL25Z（Cortex-M0+/48MHz）開発ソフトウェアの再利用が可能で、より高速なFRDM-K64F（Cortex-M4/120MHz）などへMCU変更が可能なら、この方法をお勧めします。

但し、MCU変更ができない時の効果的な高速化手段として、本稿説明のFGPIOとBMEを知っておくことは重要です。

FGPIOやBMEは、低価格で入手性も良いFRDM-KL25Zに初めから実装済みです。Kinetis KL25ファミリMCUの汎用性と高い拡張性を示す良い例だと思います。

旧Freescaleから2013年頃発売と少し古い感もあるMCUですが、十分現役で使えます。

あとがき：3.3V MCUと5V CMOSデバイス直結動作確認完了

STM32G0xテンプレートに使用した3.3V動作MCU：STM32G071RBも5V耐圧GPIOピンは持ちません。しかし、CMOSデバイス直結で5V LCDを駆動し、安定動作を確認しました。

訂正：STM32G071RBには、5V耐圧ピンがあります。お詫びして訂正いたします。

ソフトウェア開発中の3.3V動作FRDM-KL25Zと5V LCDのCMOSデバイス直結も、同様に問題なく動作するハズです。

3.3V MCUと5Vデバイスインタフェース

WithHappy

3.3V動作MCUに、5V動作デバイスを接続するインタフェースとして、

  1. 3.3V MCUの5V耐圧ピンで、5Vデバイス（例えばLCD）と接続
  2. MCUに5V耐圧ピンがない時は、間にレベルシフタを入れる

が弊社投稿：MCUの5V耐圧ピンの要旨でした。本稿は、さらに2つ選択肢を追加し、4インタフェースを評価しました。

4インタフェース特徴と評価結果

3.3V MCUと5Vデバイス接続4インタフェースの特徴と評価結果
インタフェース 特徴 評価
1 MCU 5V耐圧ピン ピン数が足りれば追加コストなく信頼性も高い Good
2 レベルシフタ挿入 I2C/SPI接続でトラブル報告多く信頼性は低い Poor
3 CMOSデバイス直結 開発MCUソフトウェアの動作確認に使える Average
4 バス・スイッチ挿入 高速性・信頼性ともに高くMCU低消費電力動作に理想的 Excellent

レベルシフタ挿入

入手性の良い秋月電子）8ビット双方向レベルシフタ：FXMA108の使用例を調べると、I2C接続時には期待通りの動作をしない情報がネット上に多数あります。原因は、アクティブデバイスFXMA108の双方向判定のようです。

I2C専用レベルシフタ：PCA9306使用例もありますが、MCUポート用途に応じてレベルシフタを使い分けるのは、コスト高を招きます。

CMOSデバイス直結

3.3V MCUと5V動作デバイス直結（出展：5V系・3.3V系信号レベル変換掲載図を加工）
3.3V MCUと5V動作デバイス直結（出展：5V系・3.3V系信号レベル変換掲載図を加工）

コチラの投稿：5V系・3.3V系信号レベル変換を参照すると、3.3V系と5V系の間にレベルシフタなどのアクティブLSIデバイス挿入は不要、5Vデバイス出力から電流制限抵抗を入れれば3.3V MCU入力へ直結、3.3V MCU出力はそのまま5Vデバイス入力へ直結可能です。

直結は、アマチュア電子工作レベルのCMOSデバイス同士の接続でノイズ・マージンは減る、という但し書き付きですが、次章バス・スイッチのアプリケーション回路図と比べても遜色は少ないと思います。

MCU入力側には、5V CMOSセンサ、出力側には、5V LCD等の表示デバイス接続を想定します。このCMOSデバイス直結を利用すると、3.3V動作MCU評価ボードと5Vデバイス間の接続に手間が少なく、開発するMCUソフトウェアの動作確認には好都合です。

もちろん、MCU評価ボードと5Vデバイス間の配線を短くツイストするなどのマージン減少対策は必要です（配線ツイスト効果は、コチラの弊社関連投稿を参照してください）。

バス・スイッチ挿入

SN74CB3T3245の代表的なアプリケーション（出展：SN74CB3T3245データシート）
SN74CB3T3245の代表的なアプリケーション（出展：SN74CB3T3245データシート）

前章の5V系・3.3V系信号レベル変換投稿で推薦されている2.5Vおよび3.3V、8ビットバス・スイッチ（5V耐圧付き）：SN74CB3T3245をインタフェースに使う方法は、伝搬遅延がゼロに近く、双方向パッシブデバイスのためノイズにも強いなど、3.3V低電力動作MCUと5V動作デバイスのインタフェースとして理想的です。

※SN74CB3T3245は、ハードウェア開発で良く用いられるCMOSデバイスの双方向3ステートバッファ：SN74HC245を、より低電圧動作で高速化し5V耐圧も付加した高速CMOSデバイスです。Vcc=2.5Vなら、5V/3.3V入力から2.5V出力へのレベルシフトも可能です。

※付録に、動作電圧が異なるデバイス間の相互接続基礎知識を示しました。

3.3V MCUの5Vデバイス接続インタフェース評価

3.3V動作MCUに、5V動作デバイスを接続する4インタフェースを示しました。

  1. MCUの5V耐圧ピンで接続
  2. MCUと5Vデバイス間に、レベルシフタ挿入
  3. CMOSデバイス同士なら直結可能
  4. MCUと5Vデバイス間に、5V耐圧3V/2.5Vバス・スイッチ挿入

4インタフェース評価は、以下の実績、動作確認に基づいています。

1は、5V耐圧ピンありMCUの弊社テンプレートで、既に多くの動作実績があります。

2のレベルシフタ追加は、I2C接続の不具合情報がネットに多数ありますので、弊社確認は省きます。

3のCMOSデバイス直結は、開発中の3.3V MCU動作5V耐圧ピンなしのFRDM-KL25Zテンプレートソフトウェアで、5V LCDを接続し動作確認します。

4のバス・スイッチ挿入は、TIから数個サンプル入手が以前は簡単にできたのですが、現在は購入が必要です。SN74CB3T3245価格が100円以下と安いだけに送料が無視できず、何かのついでに購入予定です。それまで動作確認は保留します。ただ、データシートを見ると、3.3V MCUと5Vデバイス双方向接続インタフェースには理想的だと思います。

3と4どちらも、確認結果が判明次第、本ブログでお知らせします。

付録：デバイス相互接続の基礎知識

相互接続判定のロジック概要（出展：TIロジック・ガイドP4に加筆）
相互接続判定のロジック概要（出展：TIロジック・ガイドP4に加筆）

TI）ロジック・ガイドから、動作電圧が異なるデバイス間の相互接続判定方法（Judgement）とその結果（Results）を抜粋したのが上図です。

結果は、例えば5V CMOSデバイス同士ならYes＝直結、3.3V LVTTL/2.5V CMOS/1.8V CMOSへはVOHはVIHより高く、VOLはVILより低いので、低圧入力側にVIHトレランス（耐圧）があればYes*＝直結可能を示しています。

表から、5V CMOSデバイスのD（出力）は、全デバイスのR（入力）へ直結、またはVIH 耐圧で直結できるなど、広い適用範囲が判ります。センサの多くが5V CMOSデバイスでも、3.3V動作MCUとの間にSN74CB3T3245を入れさえすれば、簡単に高信頼インタフェースが実現できる理由です。



HTML版マンスリー・アップデートの見かた

WithHappy
図1 PDF版からHTML版へ変わったSTM32マイコン マンスリー・アップデート
図1 PDF版からHTML版へ変わったSTM32マイコン マンスリー・アップデート

STマイクロエレクトロニクスのSTM32マイコン マンスリー・アップデートがPDF版からHTML版に変わって3ヶ月経過しました。新しいHTML版の掲載フォーマットもほぼ固まったと思いますので、両者の比較結果を示します。

PDF版は、紙（Book）の置換えであるため、掲載文書内容と全体との関係、掲載ページも解りやすかったのに対し、ハイパーリンクのHTML版では、モバイルデバイスへ最適化したため、「コンテンツ重視の掲載へ変わった」、これが結論です。HTML版で見逃しがちな全体像との関係を明らかにするため、リンク集を別途作成しました。

※STマイクロエレクトロニクスの日本語MCU技術資料は、弊社ブログ掲載MCUベンダ中、最も優れています。STM以外のMCU開発中の方にも役立つ情報が、リンク集から得られると思います。

HTML版STM32マイコン マンスリー・アップデートの大項目タイトル

PDF版からHTML版へ変わったSTM32マイコン マンスリー・アップデートのタイトル比較
PDF版からHTML版へ変わったSTM32マイコン マンスリー・アップデートのタイトル比較

HTML版とPDF版のSTM32マイコン マンスリー・アップデート大項目タイトル（図1の赤囲いこみ部分）を比較すると、HTML版はPDF版よりも具体的内容を示すタイトルに変わっています。

実は、PDF版も大項目以下の中項目、小項目タイトルは、HTML版と同じでした。PCで読む（見る）ことが前提のPDF版は、一度に読めるページや範囲もスマホに比べ広く、目的記事への移動も簡単なため、更新内容の構造（大項目＞中項目＞小項目）が解りやすい掲載が可能でした。

一方、スマホで読む（見る）ことが前提のHTML版は、構造よりもそのタイトルを一目見ただけで読んでもらえる工夫が必要なうえ、表示はスマホの縦長連続ページのため移動に制約があり、コンテンツ重視のタイトル掲載に変わったのだと思います。

HTML版はコンテンツフィルタリングに適す

移動中やチョットした空き時間にスマホで情報をチェックすることは、COVID-19以前はよくありました。膨大なアップデート情報コンテンツが有用か無用かを瞬時に判断し、後で有用情報のみにアクセスすることで能率は向上します。

これは、コンテンツフィルタリングです。

HTML版は、フィルタリングに適す構成を簡単に作成可能です。要不要判断に最低限必須なタイトルとその概要を掲載し、「詳細はコチラ」でリンク先へジャンプする形式です。

フィルタリング結果をスマホへ上手く覚えさせておけば、より効率的です。

PDF版はスマホで操作しにくい

PDF版の内容の一部切取り（コンテンツ加工）や広範囲なコピー（コンテンツ抽出）は、スマホでは操作しにくく、結局全部保存か、または捨てる結果となります。PCならば、必要情報のみの加工・抽出・保存は簡単なのですが…😥。

つまり、スマホなどのモバイルデバイスとの相性が良いのがHTML版、PCと相性が良いPDF版とは掲載内容表現のしかたが異なる訳です。

従来の月刊PDF版は、その月の変更情報のみを抽出掲載し、しかも全体へもリンク表示するなど、読者（情報の受け手）寄りの手間がかかる編集でした。HTML版は、STマイクロエレクトロニクス（情報の送り手）が強調したいコンテンツに重きを置いた編集となっています。

HTML版の全体像リンク集

在宅勤務の増加に伴い、モバイルとPCの両デバイスを併用して能率を上げたいところですが、現状のHTML版では、難しいと思います。※全体像が判る従来のPDF相当が参照できるリンクが追加されれば別ですが、これには編集に二度手間がかかります。

そこで、月刊HTML版で見逃しがちな全体像との関係を明らかにするリンク集を、お節介ながら作成しました😅。

リンク内容 補足
マンスリー・アップデートバックナンバー HTML版：2020年6月号以降
PDF版：2017年1月号～2020年5月号
日本語MCU技術ノート Cortex-Mコア横断的な周辺回路Tips
日本語MCU開発のヒント
日本語トレーニング資料 Cortex-Mコア毎のセミナープレゼン資料
STM32マイコン開発環境 STM32CubeIDE/MXなどのダウンロードリンク
STM32マイコンファームウェア Cortex-Mコア毎のファームウェアダウンロードリンク
セミナー・イベント・キャンペーン セミナー開催予定/終了、キャンペーン一覧
Q＆Aで学ぶマイコン講座 初心者向けMCU技術解説記事

あとがき

STM32マイコン マンスリー・アップデートに限らず殆どのアップデート情報は、モバイルファーストへ向けた「コンテンツタイトル＋数行の概要＋詳細はコチラ」の形式です。

全体像も見つつHTML版が強調する詳細コンテンツを理解・整理・記憶したい方には、多少効率が落ちるかもしれませんが本稿リンク集が役立つと思います。

繰返しになりますが、STマイクロエレクトロニクスの日本語MCU資料は、他社MCU開発中の方でも参考になる情報満載で、質・量ともに優れています。開発に行き詰まりが生じた時など、ベンダの壁を越えて参照すると、打開策が見つかるかもしれません。

アフターCOVID-19では、MCU開発のしかたも変わりそうです。丁度、ADAS（Advanced Driver Assistance System：先進運転支援システム）で自動車ソフトウェア開発が激変したように、エッジMCU開発も、IoTセキュリティ絡みで、より効率的で複雑な処理をこなせるように変化すると思います。

MCU開発の情報収集と生産性向上、両方にお役に立てば幸いです。

Cortex-M0からCortex-M0+変化

WithHappy

前稿で示した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ラインナップ

WithHappy

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

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のターゲット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起因の生産性低下は、許されないと思います。