IoT MCUコア次世代像

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入門オンライン講座

総務省総務省が、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へお寄せください。


MCU開発者の将来像

現状のMCU開発経験が、将来どのように活かされるかの参考になる記事が、日経XTECH:「技術的負債」の処方箋に記載されました。記事を筆者なりに解釈したのが、下記です。

  • 現状:MCU開発者は、C/C++言語でMCUを動かす
  • 将来:MCU開発者はCTOとなり、日本語/英語で人/組織を動かす
  • MCUソフトウェア開発スキルは、経営、組織マネジメントへ活かせる

CTO:Chief Technical/Technology Officer

CTOとは、ビジネス幹部のポジションで、会社における技術的な役割に焦点をあてたもの。研究開発ディレクターの立場を拡張したものとして、アメリカでは1980年代に登場(Wikipediaより)。日本ではまだ馴染みが少なく、また記事にもあるようにソフトウェア開発経験を持つCTOも少ないです。

日本企業のCTOには、ソフトウェア開発経験が必須で、今後その比重は増すと思います。

Technical/Technologyに対する相対地位の日米の差は、依然かなりあります。例えば、日本企業のAI危機感が足りない?という記事にも表れています。80年代から言われたことですが、現在でもこの日米差は、あまり変わっておらず、依然として日本ではTechnical/Technology軽視傾向があります。

自動運転レベル3

その日本でもTechnical/Technologyの相対的重要さに気が付く環境がスグそこに来ました。自動運転レベル3搭載車発売です。

下記ラベルを貼った自動運行対応車を多く目にし、同じラベルでも搭載Technical/Technologyによる車の違いが目に見えるようになれば、誰でもTechnical/Technologyの重要さを認識すると思います。また、ソフトウェアアップデートやセキュリティ対策により、製品ソフトウェアの更新も重要と認識されるでしょう。

自動運転を示すラベルと搭載装置(出展:レベル3搭載車発売記事)
自動運転を示すラベルと搭載装置(出展:レベル3搭載車発売記事)

※自動車ソフトウェアのOTAアップデートは、関連投稿:5G、Wi-Fi6、NXP、STMの2章などを参照してください。

日本車と言っても、自動車はグローバル市場へ向けた製品です。Technical/Technologyの相対地位が高いグローバルな基準で製品化された結果が、その実力差やシェアとなって現れます。

この日本車に対し、殆どの日本製品のグローバル地位は、低下しつつあります。日本でのTechnical/Technology軽視の証左だと思います。

MCU開発者の将来像

本ブログ読者は、MCUソフトウェア/ハードウェア開発に携わる方が殆どです。ハードウェア担当でも、TP(テストプログラム)を自作するなど、ソフトウェアなしの製品開発は今やあり得ません。この開発作業は、最初の記事にあるように、泥臭く、地道な所作の繰返しです。

しかし、その繰返しで習得するMCUを開発するスキルは、将来必ず経営、組織マネジメントへも活かせます。対象がMCUから人や組織へ、使う言語が、C/C++言語から日本語/英語へ変わるだけです(もちろん、MCUより人の方が複雑怪奇ですが…😅)。

※C++は、C言語をオブジェクト指向プログラミングへ拡張した新言語。Cに比べ、MCU間移植性や拡張性に富む。C/C++ともに英語ベースのため、欧米人の意志伝達/思考との親和性は高い。

※英語キーワード理解があいまいだと、Technical/Technologyの基礎習得にぐらつきが生じる(関連投稿:MCUセキュリティ話題の5章)。英語リーディング能力もMCU開発者に必須。英語が読めると、ソフトウェア開発スキルや思考方法もグローバル開発者レベルに近づく。

現状日本のTechnical/Technology軽視環境は、IoT普及や自動運行対応車が増えるにつれて、いずれグローバルレベルへ変わります。その時は、CTOまたはその補佐役には、ソフトウェア開発経験は必須です。

MCU開発者の皆さんは、将来CTOを目指し開発製品の市場獲得ができるよう、今のソフトウェア開発スキルを磨いてください。

LibreOffice Fresh更新とDraw使い方のコツ

2020年10月29日、無償でWindows/Mac/Linux全てのPCに使えるLibreOffice Fresh(最新版)がv7.0.3に更新されました(Still(安定版)はv6.4.7)。LibreOffice Drawを使った、実践的で簡単・短時間作図方法を、本ブログのカテゴリ図を例に説明します。

LibreOffice Draw作成のカテゴリ関係図
LibreOffice Draw作成のカテゴリ関係図

文章を読んでもらうには、読者の目を引付ける図が必要です。問題は、この図を簡単・短時間で作図できるか?です。この実現のため、Draw作図のコツを説明します。作成した図は、Word/Excel/PowerPoint などのOfficeツールへの挿入も簡単です。Draw応用範囲は広いと言えます。

Draw(Visio)とImpress(PowerPoint)

LibreOffice Drawは図形描画ツール、Impressはプレゼンツールです。これらに相当するOfficeツールが、VisioとPowerPointです。プレゼンツールのImpressやPowerPointは、1スライド3分、数行の文章記述がプレゼン中の基本です。従って、その描画能力もこれに準じた簡易なものです。

一方DrawやVisioは、図形専用のためより細かく高度な描画が可能です。

Drawで作成した図は、Officeツールへも挿入ができます。Draw相当のOffice Visioは、Word/Excel/PowerPointとは別パッケージで、しかも高価です。つまり、Drawが使えると、「WordなどのOfficeへも広範囲に適用できる高度な無償図形描画ツールを得た」ことになります。

Drawの基本的使い方は、関連投稿:LibreOfficeの使い方(総集編)をご覧頂くか、または、カテゴリのLibreOfficeをクリックすると、LibreOffice関連投稿だけが選抜されますので参照してください。

本稿では、基本的使い方の次の段階、実践的で簡単・短時間のDraw作図方法を示します。

LibreOffice Draw簡単・短時間作図方法

具体例が無いと解りにくいので、本ブログのカテゴリ関係図を例に作図します。

本ブログは、MCU:マイコン開発に関する投稿が主、このMCU開発の土台であるPC:パソコンと、MCU開発の比較対象としてMPU/SBC:IoTプロセサに関する投稿が従の関係です。文章で書くと簡単ですが、このカテゴリ関係を図示したのが最初の図です。

作図の流れ

最初にDraw作図の流れを示し、簡単・短時間で作図するポイントやコツを示します。これ以降は、ギャラリーのダイアグラムを例に説明します。

  1. 図のイメージを持つ(大まかで良い)
  2. ギャラリーからイメージに近いダイアグラムを選択し、作図ページへ配置
  3. 配置ダイアグラムを、イメージに合わせ修正し、最後に基本図形で修飾

(1)描きたい図を大まかにイメージすること、(2)そのイメージに近いダイアグラムを右側ギャラリーから選び、(3)そのダイアグラムを修正後、左側基本図形で細かい修飾を加えるなどのイメージ具体化をすること、の3段階です。つまり、イメージ主体で作図することです。

※ギャラリーと基本図形の位置は、LibreOffice標準ツールバーのデフォルト位置で説明します。

ポイント:ギャラリー利用

イメージに近いギャラリーパーツを選択すること、これが簡単・短時間Draw作図最初のポイントです。

ギャラリーのダイアグラムパーツ
ギャラリーのダイアグラムパーツ

基本図形は、図形同士の関係や、注釈を加える時に便利なパーツを集めたものです。ギャラリーは、利用頻度が高く半分完成したパーツを集めたもので、ダイアグラムやフローチャートなど多くの既成パーツがあります。

このダイアグラムの中にイメージに近いパーツがあるハズです。無ければ基本図形を使って0から作図することも可能ですが、手間暇がかかります。イメージがあれば、パーツ選択は早く簡単です。

ギャラリーパーツ修正のコツ

よりイメージに近いパーツへ修正するコツは、ページにダイアグラム配置後、直に左クリックすることです。ギャラリーパーツ修正メニューが表示されます。

この修正とは、ギャラリーパーツの「形を保持したまま」各種変更を加えることです。

ギャラリーパーツ配置後、左クリックで現れる修正メニュー
ギャラリーパーツ配置後、左クリックで現れる修正メニュー

領域(R)や線(I)選択で、ダイアグラム配色や境界線の色が変更できます。グループ解除(U)とグループに入る(E)は、1つのダイアグラムを構成しているパーツが複数ある時に、それぞれ別々に修正する時に使います。

図形変形加工のコツ

ダイアグラムそのものの形を加工するコツは、標準ツールバーの、変形ボタンをクリックすることです。

ギャラリーパーツの変形加工時に使う標準ツールバー変形ボタン
ギャラリーパーツの変形加工時に使う標準ツールバー変形ボタン

ダイアグラムは、半分完成のパーツです。大小サイズ変更は簡単ですが、半完成の形そのものの変更には、標準ツールバーにある「変形ボタン」をクリックします。カーソルが「⇋」など通常カーソルから変わり変形モードになったことが解ります。

変形モードには、ダイアグラムを傾斜させる、ゆがめるなどの選択肢があります。文章での説明は難しいので(アプリケーション付属ヘルプを読んでも、役立たないのと同じ現象が懸念されますので😅)、実際に一度試してください。

ダイアグラムの形そのものを、簡単に変えられることが解ります。

まとめ

LibreOffice Draw作図のポイント、コツを説明しました。動画があれば別ですが、文章や図だけでの説明は、なかなか難しく解り難かったと思います。しかし、くどい説明より、後は操作の慣れの問題です。

実際にLibreOffice Drawを使いながら本稿を読んで頂ければ、直に解り、操作にも慣れます。

思い描くイメージをすばやく具体化するには、作図途中でイメージと関係ない余分な操作は無い方が効果的です。そこで、ギャラリーからイメージに近い図を選び、これを修正・加工するイメージ主体Draw作図方法を示しました。

Drawで作成した図は、WordやPowerPointへもコピー&ペーストで簡単に挿入でき、繊細で高度な図も描写できます。本稿で示した簡単・短時間で作図するポイントやコツを使って、是非Drawをご活用ください。


Windows 10 20H2更新方法

年2回のWindows 10大型更新、Windows 10最新バージョン20H2がリリースされました。Windows Updateを待たずにユーザ主体で最新のWindows 10大型更新を実行する方法と、そのメリット/デメリットを示します。

まとめ

準備 MediaCreationTool20H2.exeダウンロード 0.5時間
※Pro/64bitは8GBでOK
USB/DVDインストールメディア作成
旧Windows 10バックアップ(更新失敗リカバリ対策) ※環境依存で省略
更新 旧Windows 10起動状態で作成USBのsetup.exe実行 1~3時間(PC依存)
※この間クリック1回
新Windows 10へ引き継ぐもの選択後インストールクリック
新Windows 10の大型更新自動完了

旧Windows 10バージョン2004のアプリケーションとユーザデータの両方を保持したまま、新Windows 10バージョン20H2を上書きインストールする方法です。メリットとデメリットが以下です。

メリット いつ始まるか判らない新Windows 10大型更新をユーザ主体で開始
タイミングの良いバックアップを取るので、良いところからリカバリ
アプリとユーザデータ両方保持で、新Windows 10でも即開発継続
USBは複数PC更新に使え、新Windows 10トラブル回復ツールにもなる
デメリット レジストリはデフォルト値へ戻る。ユーザ変更時は再設定が必要。

Windows 10上書きインストール準備

Windows 10大型更新がリリースされると、同時にMicrosoft公式ツール:MediaCreationTool20H2も発表されます。

MediaCreationTool20H2は、Windows 10新規/再インストールに必要な全ファイルをUSBやDVDへ保存するツールです。Windows ProとHome、64ビット版と32ビット版の各バージョンを保存できますが、Windows Pro/64ビット版のみなら8GB容量のUSBで十分です。

MediaCreationツールでUSBメディア作成の様子
MediaCreationツールでUSBメディア作成の様子

ツールダウンロードとUSBメディア作成時間は、ダウンロードリンク速度に依存しますが、約30分です。

作成したUSBは、複数PCの大型更新に使えます。また、Windows 10起動トラブル、例えばスタートアップ修復やコマンドプロンプト処理などの回復ツールとしても動作します。

MediaCreationツールで作成したUSBメディアの大型更新と回復の2用途
MediaCreationツールで作成したUSBメディアの大型更新と回復の2用途

以上がWindows 10上書きインストール開始前の最低限の準備です。

但し、今回に限らずWindows 10の大型更新には、多くの不具合報告があります。使用中のPCが大型更新で不具合に遭遇しても、不具合前へリカバリできるシステムバックアップも、更新前のユーザ側準備としては必須です。

バックアップツールは、有償/無償含め様々です。バックアップだけでなく、リカバリができる確認もお勧めします。リカバリ本番で失敗する例は、世の中にたくさんあります。バックアップ所要時間は、使うツールやご利用環境に依存しますので、省略しています。

バックアップのもう1つの重要事項は、タイミングです。開発が一段落したなど、バックアップに適し、ユーザや開発者が安心しているタイミングがあります。ユーザの都合が良いタイミングでバックアップを確実にとり、かつ、Windows 10大型更新を迎えれば、たとえトラブルにあっても冷静に対処できます。

Windows 10上書きインストール更新

Windows 10上書きインストールの最重要事項は、旧Windows 10起動状態で作成したUSB/DVDのsetup.exeを実行することです。以下、Windows Pro/64ビット版USBを例に説明します。

旧Windows 10起動後に準備で作成したUSBを装着し、setup.exeをクリックします。すると、最新の更新プログラムダウンロードが始まり、インストール準備完了へ画面が変わります。

Windows 10上書きインストール更新の様子
Windows 10上書きインストール更新の様子

「個人用ファイルとアプリを引き継ぐ」がデフォルトになっています。これが、旧Windows 10アプリケーションとユーザデータの両方を保持のまま、新Windows 10を上書きインストールする設定です。

引き継ぐもの変更をクリックすると、アプリ、または、個人用ファイルのみ、どちらもなしなども選択可能です。どちらもなしの場合が、クリーンインストールに相当します。

上書きインストール中、このインストール準備完了画面のインストールのみがクリック個所です。インストールクリック後は、何の操作も不要です。PCが勝手に何回か再起動し、新Windows 10バージョン20H2の初期画面が表示され大型更新完了です。

Windows10 20H2のバージョン情報
Windows10 20H2のバージョン情報

更新開始から完了までの所要時間は、PC(ネットワーク速度やPC性能)に依存します。おおよそ1時間から3時間程度です。この間のクリックは1回だけです。クリック後は読書や運動などでもして気楽に新Windows 10初期画面を待てば良いでしょう。

Windows 10上書きインストールメリット/デメリット

Windows 10上書きインストールの最大メリットは、ユーザ主体でWindows 10大型更新を開始できること、同時に、更新失敗に備えたシステムバックアップが取れることです。

どちらもWindows任せ、つまりWindows Updateで自動開始にすると、ユーザや開発者が不安定な時や思わぬタイミングで更新を開始し、バックアップを忘れる、適切なバックアップが取れないなど、本来なら起こるはずが無いユーザ起因のトラブルにも遭遇する可能性がでてきます。

新Windows 10バージョン20H2は、旧Windows 10バージョン2002の小変更版と言われます。小変更なら尚更早く更新完了し、Windows 10最新バージョン20H2による安定したPC運用を望みたいと筆者は思います。但しMicrosoftは、Windows 10バージョン20H2のUpdate配布を遅らせるとの2020/10/23情報もあります。

Windows 10のライフサイクルは、わずか1.5年です。この間半年毎に2回大型更新があり、たとえ各回の更新を延期しても、1.5年後には必ず大型更新が必須です(ライフサイクルは、関連投稿:WindowsとLinux Mintの大型更新比較を参照してください)。

Windows 10起因の大型更新トラブル遭遇確率は、ユーザ主体開始でも自動開始でも大差ないと思います。むしろユーザ主体上書きインストールの方が、ユーザ起因トラブルがない分、トータルの大型更新トラブル確率は低くなるかもしれません。

※本稿は、大型更新トラブルの原因を、Windows 10起因とユーザ起因、これら2つに分けて考えています。

上書きインストールのデメリットは、上書きなのでWindows 10レジストリがデフォルト値に戻ることです。デフォルト値は、MicrosoftがWindows 10運用上、最も安全と考える値です。しかし例えば、ネットワークのパスワード保護共有を有効→無効にユーザが変更している場合などは、再設定が必要です。

ご利用中のPCで、メリット/デメリットを天秤にかけ、本方法適用をご自身でご判断ください。

なお弊社は、本稿のWindows 10上書きインストール更新方法で、メインPC/ノートPC/バックアップPC:3台のWindows 10バージョン1909→2002→20H2の過去3回の大型更新を、運よく(?)成功した実績があります。

IoT MCU汎用Baseboardの汎用性

・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ソフトウェア開発をするためのソフトウェア担当者向けツールという位置づけです。製品化にあたっては、ハードウェア担当者も安心するようにバス・スイッチの利用をお勧めします。

IoT MCU汎用Baseboard

弊社が考えるIoT MCU向き汎用Baseboardを示します。要件は、(1)IoT MCU向き、(2)低価格、(3)入手性の良さです。

Arduino UNOプロトタイプシールド ブレッドボード付き(¥480)と、従来から使ってきたBaseboardを併用した汎用Baseboardの特徴、FRDM-KL25Zを使った3.3V MCUと5V LCDのCMOSデバイス直結適用例を示します。

図1 Arduino UNO プロトタイプ シールド ブレッドボード 付き
図1 Arduino UNO プロトタイプ シールド ブレッドボード 付き

NXP IoT Module Baseboard

“IoT Baseboard”で検索すると、NXPのIoT Module Baseboard($160)が現れます。これは、右下にLPC54018(Cortex-M4/180MHz)をAdd-onし、EthernetやSD Card等の機能追加を行う「専用」Baseboardです。Baseboardに加え、ArduinoコネクタでもLPC54108へ機能追加できることが判ります。

図2 IoT Module Baseboard(UM11079に加筆)
図2 IoT Module Baseboard(UM11079に加筆)

LPC54018専用Baseboardで$160と高価ですが、Arduinoシールドが追加できる点が重要です。つまり、IoT Module Baseboardで基本機能追加、開発用途に応じた機能追加はArduinoシールドやPmodで行うという2通りの機能追加方式です。

Arduinoシールドで、様々なプロトタイピング開発に対応できる訳です。

Arduinoシールド

多くのMCU評価ボードは、上記LPC54018専用Baseboardと同様、Arduinoコネクタで機能追加が可能です。安価で豊富な種類のArduinoセンサシールドが販売中であることがその理由です。

弊社IoT MCU汎用Baseboardも、Arduinoシールドで機能追加できることをポイントと考えました。FRDM-KL25Zを例に説明します。

FRDM-KL25Zは、Arduinoコネクタが未実装ですのでコネクタを追加したのが図3です。Arduinoコネクタは、複数シールドをスタッカブルに装着するため、上側がメス、下側がオスの貫通ピンで構成されます。

図3 Arduinoコネクタ追加のFRDM-KL25Z
図3 Arduinoコネクタ追加のFRDM-KL25Z

Arduinoコネクタピン(青色)と、FRDM-KL25Zピン(赤色)の対応表です。例えば、右下のPTA1は、D0に対応するなど、MCU評価ボード開発時は赤色ピン、これがArduinoコネクタ利用時は青色ピンへ変わります。

図4 Arduinoコネクタピン(青色)とFRDM-KL25Zピン(赤色)対応表
図4 Arduinoコネクタピン(青色)とFRDM-KL25Zピン(赤色)対応表

MCU評価ボードにはArduinoピンのシルク印刷はありません。開発するMCU評価ボードのArduinoコネクタ対応表をよく見て、MCU評価ボードピンとArduinoピンマッピングを間違わないように注意する必要があります。

Arduino UNOプロトタイプシールド プレッドボード付き

図1のArduino UNOプロトタイプシールドは、MCUボード上に装着してもFRDM-KL25Zのタッチセンススライダの操作はできます。また、評価ボード上のLED動作は、プロトタイプシールドのスルーホールから目視できます。

さらに、プロトタイプシールドには、評価ボードRESETに並列接続済みリセットボタンと2個のLED、1個のSWが実装されています(図1回路図参照)。

プロトタイプシールドのLEDとSWは、評価ボードとは未接続ですが、付属のブレッドボードを使って配線すれば、LチカなどのMCU動作確認にも便利に使えます。

※Arduino UNOプロトタイプシールド プレッドボード付きの動作は、5章:3.3V MCUと3.3V LCD接続で示します。

IoT MCU汎用Baseboardと適用例

以上のようにArduino UNOプロトタイプシールドは、Arduinoコネクタを持つMCU評価ボードの機能追加や動作テストに便利に出来ています。

そこで、このプロトタイプシールドを、弊社が従来から使ってきた5V動作Baseboardと併用します。

MCU評価ボードへのIoTセンサやセキュリティ機能などはArduinoシールドで追加、LCDやポテンショメータなどの機能は5V動作Baseboardにより追加、この2通り機能追加で「汎用開発」に使えるIoT MCU Baseboardになります。

MCU評価ボードとして3.3V動作FRDM-KL25Zと、Baseboard実装の「5V動作LCD」とをCMOSデバイス直結で接続した適用例を示します(CMOSデバイス直結は、関連投稿を参照してください)。

図5 IoT MCU汎用BaseboardのFRDM-KL25Z適用例
図5 IoT MCU汎用BaseboardのFRDM-KL25Z適用例

※IoTセンサシールド等を追加する場合は、MCU評価ボード(FRDM-KL25Z)の直上、または直下へスタック装着を想定しています。図5は、IoTセンサシールド等を省略した例と考えてください。

3.3V MCUと3.3V LCD接続

プロトタイプシールドを装着したFRDM-KL25Zへ、前章の「5V動作LCD」の代わりに「3.3V動作LCD」を接続した例も示します。FRDM-KL25Zソフトウェアは、どちらも同じものです。

関連投稿では未検証であった3.3V MCU開発ソフトウェア動作確認に、CMOSデバイス直結を利用し5V動作Baseboardが利用できることが、LCD表示が同じであることにより実証できました。

図6 プロトタイプシールド利用の3.3V MCU評価ボードと3.3V LCD接続例
図6 プロトタイプシールド利用の3.3V MCU評価ボードと3.3V LCD接続例

ブレッドボードに実装したのは、LCD表示コントラスト調整用スライド抵抗です。5V系センサ等と3.3V MCU評価ボードをCMOSデバイス直結時に必須となるMCU入力電流保護抵抗は、ブレッドボードへ実装し対応できます。

まとめ

Arduinoプロトタイプシールドと、従来から弊社が使ってきた5V Baseboard併用の、IoT MCU汎用 Baseboardを示しました。IoT関連の機能追加はArduinoシールドで、LCD等の機能追加は5V Baseboardで行い、低価格、入手性が良く、様々なIoT MCUプロトタイピングに使えます。

最低限必要なロジックをプロトタイプシールド付属ブレッドボードへ実装すれば、3.3V系MCU評価ボードと5V系ハードウェアの制御ソフトウェア開発に、CMOSデバイス直結が使えることを実証しました。

本稿で示したFRDM-KL25Z とIoT MCU汎用Baseboardを使ったKinetis Lテンプレートは、年内に発売予定です。ご期待ください。

5G、Wi-Fi6、NXP、STマイクロエレクトロニクス

公衆網の5G、無線LANのWi-Fi6、どちらもIoT MCUに必須となる無線通信技術です。本稿は、5GとWi-Fi6、MCU主要ベンダのNXPとSTマイクロエレクトロニクス2社の無線対応状況を簡単にまとめます。

5GとWi-Fi6

5GやWi-Fi6、Bluetoothは、無線通信技術です。違いは、5GがNTTやau、SBが提供する公衆網サービス、Wi-Fi6やBluetoothは、LANを無線化したプライベート網サービスだということです。

これら公衆網とプライベート網、両方の無線技術やサービスを積極的に活用するデバイスが、毎年新製品が発表されるスマートフォンです。搭載カメラやスマホ操作性だけでなく、5GやWi-Fi6実現のためにスマホプロセッサの性能向上は必須です。

5GやWi-Fi6の市場は急増中です。これら市場に対応するため、スマホは常に最新無線技術、高性能プロセサへと変わらなければならない運命です。開発担当者は大変でしょう。

5G、Wi-Fi6技術牽引はスマホと自動車

自動車業界のADAS:Advanced Driver-Assistance Systems、先進運転支援システムの開発速度もスマホ同様高速です。数年でモデルチェンジする新車に搭載する様々な新しい支援機能が、売上げを左右するからです。

これら新搭載機能にバグはつきものです。例えば、制限速度標識の車載カメラ認識はかなりの精度ですが、一般道で認識速度が110 km/hと表示された経験があります。メータ表示だけなので、車速が自動で上がることはありませんが…、バグです。

一般道で110km/h表示:フェールセーフでなくバグ
一般道で110km/h表示:フェールセーフでなくバグ

このようなバグに対して、2022年7月以降の新車は、スマホのようにOTA:Over-The-Airで車載ソフトウェアのアップデートを行う国際基準が発表されました。サイバーセキュリティ対策や走行安全性にも絡むので、かなりの処理が開発担当者に要求されると思います。

ついに自動車もスマホ同様、ソフトウェアOTA必須になります。インダストリアル業界も、当然ながら自動車業界OTAと同様の仕組みとなるでしょう。

無線技術やセキュリティ、AIなどの先端技術は、一般消費者の旺盛な購買力の対象となるスマホと自動車が牽引することは間違いありません。競争が激しく開発成果も解り易いのですが、開発者担当は最新技術習得の余裕も少なく、実装期限が限られるためセルフマネジメントが大変です。

NXP対応

NXPは、2020年9月に5G無線システム向け製造工場の稼働開始を発表し、2021年初頭までにフル稼働、5Gや次の6G向け無線チップを自社製造できる見通しです。また、NXP本社副社長でもあるNXPジャパン新社長の和島正幸氏の就任も発表されました。

せっかく開発した量産電気自動車(Electric Vehicle)の販売予約中止の原因は、車載バッテリーの供給が追付かないからだそうです。無線システムのかなめ、RFチップ供給が同じ状況になるのを避けるためのNXPの措置だと思います。

STマイクロエレクトロニクス対応

STマイクロエレクトロニクスは、2020年10月7日、無線LANのBluetooth LE 5.2対応Cortex-M0+ベースMCUとその評価ボードを発表しました。Arduinoコネクタ付属で、使い勝手も良さそうな気がします。

STEVAL-IDB011V1 Evaluation Board and Updated BlueNRG Software(出展:STマイクロ)
STEVAL-IDB011V1 Evaluation Board and Updated BlueNRG Software(出展:STマイクロ)

IoT MCUの爆発的な需要増加に対して、MCU主要ベンダのNXPやSTマイクロエレクトロニクスは、着々と準備を進めています。

インダストリアル業界IoT端境期

スマホや自動車業界のように競合他社より少しでも早く最新技術を導入し製品化する動きに対し、インダストリアル業界は、COVID-19の影響でIoT技術導入の端境期のようです。つまり、積極的にIoTを進めるデンソーのようなグループと、暫く様子見をして徐々にIoTを進めるグループの2つに分離しつつあるということです。

インダストリアル業界対応の開発者は、この端境期を逆に利用し、IoT最新技術を学習しつつ、来るべきIoT開発案件をこなす力を備えるチャンスです。

具体的には、自動車やスマホで先行した無線/セキュリティ/AI技術を、効率的にIoT MCUへ流用・応用できる開発力です。または、MCUベンダ提供の無線/セキュリティ/AI最新技術サンプルプロジェクトを理解し、評価ボードを上手く活用できる開発力とも言えます。

インダストリアル業界の顧客出力となるソフトウェア/ハードウェアを、要求期限内に開発成果として提出できるベストエフォート技術、この比重が増すと思います。開発成果の不完全さやセキュリティ追加、変更はOTAで対応します。

Firefox Send終了

クラウドファイル共有サービス: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の使い方

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デバイス直結も、同様に問題なく動作するハズです。