カテゴリー: Cortex-M0+コア

世界定番マイコン、ARM Cortex-M0+コアマイコンに関する情報、Tipsなどをまとめています。

2020マイコンテンプレート案件総括

WithHappy

COVID-19パンデミックの2020年も残すところ2週間になりました。2020年の金曜ブログ投稿は本日が最後、次回は2021年1月8日（金）とし休暇に入ります。

※既存マイコンテンプレートは、年中無休、24時間販売中です、いつでもご購入お持ちしております。

2020マイコンテンプレート案件総括

  1. 🔴：Cortex-M4コア利用のマイコンテンプレート開発（2020年内）
  2. 🟡：FRDM-KL25ZとIoT汎用Baseboard利用のKinetis Lテンプレート発売（12月）
  3. 🟢：IoT MCU向け汎用Baseboard開発（10月）
  4. 🟢：STM32FxテンプレートV2発売（5月）
  5. 🟢：STM32G0xテンプレートV2発売（5月）

1のCortex-M4テンプレート開発は、STM32G4のRoot of Trustと、NXP LPCXpresso54114のRTOSサンプル解説で、Cortex-M4テンプレート化には程遠い状況です（赤ステータス）。

2のKinetis Lテンプレート（FRDM-KL25Z、Cortex-M0+/48MHz、Flash:128KB、RAM:16KB）は、添付説明資料作成が未着手です（黄ステータス）。

3のArduinoプロトタイプシールド追加、IoT MCU汎用Baseboardは完成しました（緑ステータス）。

4と5のSTM32FxテンプレートとSTM32G0xテンプレート発売までは、ほぼ順調に進みました（緑ステータス）。

対策としてブログ休暇中に、2のKinetis Lテンプレート完成と、これに伴うHappyTechサイト変更を目標にします。
１のCortex-M4テンプレート開発は、2021年内へ持越します。

ブログ記事高度検索機能（1月8日までの期間限定）

休暇中、ブログ更新はありません。そこで、読者の気になった過去の記事検索が、より高度にできる下記Googleカスタム検索機能を、1月8日までの期間限定で追加します。

上記検索は、WordPressのオリジナル検索（右上のSearch…窓）よりも、記事キーワード検索が高度にできます。少しでもキーワードが閃きましたら、入力してご活用ください。

あとがき

激変の2020年、テンプレート関連以外にも予定どおりに進まなかった案件や、新に発生した問題・課題も多数あります。例年より少し長めの休暇中、これらにも対処したいと考えております。今年のような環境変化に対し、柔軟に対応できる心身へ変えたいです（ヨガが良いかも？ 3日坊主確実ですが…😅）。

本年も、弊社ブログ、HappyTechサイトをご覧いただき、ありがとうございました。
今後も、引き続きよろしくお願いいたします。よいお年をお迎えください。

Cortex-M33とCortex-M0+/M4の差分

WithHappy

STマイクロエレクトロニクスが、STM32マイコン体験実習（セキュリティ編①～⑤）という動画でCortex-M33 TrustZone解説とSTM32L5（Cortex-M33/110MHz、Flash/256/512KB、RAM/256KB）のセキュリティ実習を行っています。

このセキュリティ編①：31min17secから、IoT MCU向けセキュリティ強化Cortex-M33コアのARM TrustZoneマイコンと、通常Cortex-M0+/M4コアマイコンとの差分を抽出しました。TrustZoneマイコン基礎知識の習得が目的です。

Cortex-M33とCortex-M0+/M4差分

セキュリティ編動画①～⑤概要

①P3（動画①、スライドP3を示します）に、動画①～⑤の概要が示されています。動画①でCortex-M33コアの解説、②でSTM32L5開発環境の準備、後半③～⑤でSTM32L5評価ボード：NUCLEO-L552ZE-Q（¥2,303 Mouser）を使ったセキュリティ演習という構成です。

本稿は、動画①から、ARM TrustZone Cortex-M33コアと通常Cortex-M0+/M4コアとの差分を一覧表にしました。

※ARM公式差分情報を知りたい方は、①P48の参考文献が参考になります。

Cortex-M33とCortex-M0+/M4の差分

オンデマンド動画ですので、好きな個所で止める、再生読度を変えるなどが可能です。動画①は、筆者が経験したTrustZone解説の中で最も分かり易い動画です。

特にP36/P37/P39は、4段階に増えたステート処理内容が具体的に判りTrustZoneマイコン特徴理解に役立ちます。
また、P19は、様々なセキュリティレベルと対応STM32MCUのセキュリティ機能差が一目で判る重要な資料です。

頁 要旨（ARM TrustZone Cortex-M33と通常Cortex-M0+/M4差分）
7 ソフトウェア攻撃防御策がTrustZone。物理攻撃対策はセキュアマイコン（≠汎用MCU）が有効。
12 Secure呼出し＝予め決めた手順で内蔵周辺回路（I2C/SPI/RAMなど）へアクセスする技術
Security Isolation＝Secure呼出しを使い通常アクセスと隔離・分離する技術
ARM TrustZone＝Security Isolationを対象MCUで柔軟に構成する技術
16 タンパ＝物理攻撃を検出→検出後バックアップレジスタやSRAM自動消去
JTAGピン無効化→設定後はGPIOなどで運用
WRP（WRite Protection）：数KB単位設定可能
RDP（ReaD Protection）：JTAG読出し禁止→読出検出でプログラム実行停止→PORで解除
Secure Memory＝起動時のみ読出し可能な領域
17 MPU（Memory Protection Unit）：最大16個メモリ領域の読書き、命令実行許可/禁止設定
18 セキュリティは単独では効果が薄く、複数重ね攻撃への敷居を上げ強化（暗号鍵保存例掲載）
19 STM32マイコン内蔵セキュリティ機能差一覧。TrustZone対応はSTM32L5のみ（2020/12時点）
STM32G0/G4(Cortex-M0+/M4)でもSRAM RDP機能などあり
22 TrustZoneは、アドレス空間とバス通信の両方をハードウェア監視しアクセス制御
23 アドレス空間監視＝コア内蔵SAU IDAU、バス通信監視＝TZ(TrustZone) ControllerとAHBバス
24 STM32L5は、内部FlashアクセスにST独自Flashレジスタとオプションバイトで保護
26 TrustZone-aware周辺回路＝DMA1&2/GPIO…などAHB接続回路は個別セキュリティ設定要
上記以外がSecurable周辺回路＝UART/SPI…などでAHB/APBブリッジがアクセス監視
29 従来MCUベアメタル開発は、mainループも割込みハンドラも常に特権モード動作の1段階
30 従来MCUのRTOS開発は、割込みハンドラ/RTOSが特権モード、ユーザタスクは非特権の2段階
32 Secureステート追加TrustZoneは、4段階化→各層の処理配置がTrustZoneソフト設計第一歩
35 Secureソフトと従来ソフトのプロジェクト差一覧
（セキュリティ関連設定はSecureソフトのみ可能でmain関数はあるがmainループなしなど）
36 TrustZoneマイコンベアメタル開発の4段階ステート処理配置例（TrustZoneソフト設計例1）
37 TrustZoneマイコンRTOS開発の4段階ステート処理配置例（TrustZoneソフト設計例2）
38 TrustZoneソフト開発時、Secureソフトと通常ソフトの2プロジェクト作成必要
39 TrustZoneソフトの基本実行フロー（Secureソフトから通常ソフトへの処理内容一覧）
40
41
42		 Secureステートと通常ステートのアドレス空間の見え方差まとめ
44 動画①全体まとめ
45 STM32L5開発時のキーポイント一覧（全18項目）
46 STM32L5開発時のキーポイント演習項目一覧（18項目中9項目を動画③～⑤で演習）
48 おすすめARMv8-M（Cortex-M33コア）TrustZone参考文献一覧

TrustZoneマイコン開発は工数2倍、スキルも必要

動画①は、他ベンダのARM Cortex-M33 TrustZoneマイコン開発でも基礎知識が得られます（※P24のST独自Flashレジスタとオプションバイト保護は除く）。IoT MCU向けセキュリティ強化Cortex-M33コアで導入されたTrustZoneを活用するには、①の理解は最低限必要です。

従来Cortex-M0+/M4に比べ、Cortex-M33シングルコア開発でもSecureと通常（Normal）ソフトウェアの2プロジェクト必要、メモリ空間と周辺回路のセキュリティ設定必要（メモリ分割損も生じると予想）、JTAGピン無効化など、従来のアプリケーション開発とそのデバッグに加え、ソフトウェア攻撃対策TrustZone導入による工数やその動作確認/解除などの手間が余分に必要になります。

このTrustZone導入オーバーヘッドは、少なくないです（セキュリティ編②～⑤でオーバーヘッド工数が判ります。補足章に動画②～⑤リンク添付）。Cortex-M33コア最高速度が110MHzと他コア比高速で、Flash/RAMも大容量なのは、このオーバーヘッドのハードウェア対策だと思います。

TrustZoneマイコンのソフトウェア開発工数は、同じアプリケーションの通常マイコン開発の2倍程度は必要になると思います。また、TrustZone起因のトラブルに対する分析スキルも必須です。

ソフトウェア攻撃に対する防御壁の高さは、言い換えると、ソフトウェア開発のし難さと等価です。セキュリティレベルが上がるにつれ、開発コストも上がります。

全てのIoT MCUがTrustZone対応MCUである必要は無いと思います。コスト重視の場合は、従来Cortex-M0+/M4コアでセキュリティ強化対応（例えば、関連投稿：STM32G0/G4のRoot of Trust(1)～(3)など）でも使える可能性があります（関連投稿：IoT MCUコア次世代像のIoT MCUコアの3層構造最下層のFront End IoT MCUに相当）。

セキュリティは、強固な方が良いのは当然ですが、それ相応の追加コストも生じます。セキュリティ対コストの観点からIoT MCUの選択が必要となるでしょう。

＊　＊　＊

セキュリティ対策は、いわば自動車保険のようなものです。保険代金の負担は、開発者かエンドユーザか、エンドユーザがTrustZone導入オーバーヘッドを理解することは難しいと思いますので悩ましい問題です😅。

Cortex-M33 TrustZoneマイコンは、ソフトウェア開発者が記述した処理を攻撃とマイコンが誤認識（正常認識）した場合は、無視、あるいは最悪、マイコンを使用不能にします。見つけにくい無視された処理が、開発者起因か、あるいはTrustZone起因かを分析できるスキル、これが、通常マイコン開発との最大の差分です。

STM32マイコン体験実習は、TrustZone起因スキルを習得できるよく考えられた教材です。

補足

STM32マイコン体験実習（セキュリティ編②）
STM32マイコン体験実習（セキュリティ編③）
STM32マイコン体験実習（セキュリティ編④）
STM32マイコン体験実習（セキュリティ編⑤）

関連投稿：STM HTML版マンスリー・アップデートの見かた4章の全体像リンク集なども役立ちます。

Cortex-M33コア以外でTrustZone技術を用いたマイコンは、Cortex-M35P、Cortex-M23があります。

IoT MCUの無線LAN

WithHappy

IoTに適した無線LANの条件とは？（TechTarget、2020年11月27日）記事を紹介し、IoT MCU関連のプライベート網無線LAN規格を説明します。

IoT向き無線LAN条件と規格

纏まった良い記事なので、一読をお勧めします。

記事を要約すると、IoT向きの無線LANの選定には、3つの検討ポイントがあります。

  1. 省電力性：バッテリーだけで長時間無線LAN通信ができる
  2. 長距離伝送性：アクセスポイント（AP）から1km以上離れる場合がある
  3. 国より異なる利用周波数の空き状態確認

各ポイントを満たす無線LAN規格として下記3つを挙げ特徴を説明しています。

  • IEEE 802.11ah（別名Wi-Fi HaLow）：Target Wake Time（TWT）により通信タイミングを調整しAP通信競合を防ぐと同時にスケジュールタイムまでスリープし電力消費を抑える
  • IEEE 802.11ba：TWTに加えWake-Up Radio省電力機能を利用しAPからの通信要求に対応
  • IEEE 802.11af： 54MHz～698MHz利用で900MHz～1GHzの802.11ah/802.11baより長距離伝送可能
    ※11afは、テレビ用ホワイトスペースのVHF/UHFバンド（54 MHz～790 MHz）利用なので空き状態により耐ノイズ注意

IoT向き無線LANとBluetooth

無線LANには、2.4GHz利用、数m～10m程度の「近距離無線通信規格」：IEEE 802.15.1（別名Bluetooth）もあります。コイン電池で1年以上動作できるなど超省電力動作ですが、低速です。PCやスマートフォンでは、マウス/キーボード/ヘッドホンなどの周辺機器との接続に使われます。

より高速、より長距離（400m程度）、より高スループットを目指し、Bluetooth v4.2、Bluetooth 5などと規格が変化しています。

IoT MCUへの実装は、Bluetooth 5内蔵MCUやBluetooth 5モジュールとMCUを接続する方法があります。

IoT 向き無線LANとPC/スマホ向き無線LAN

2020年12月時点のPC/スマートフォン無線LAN規格が下表です（出展：NTT西日本公式ホームページ）。

規格 周波数帯 最大通信速度
IEEE 802.11b 2.4GHz 11Mbps
IEEE 802.11g 2.4GHz 54Mbps
­­­­IEEE 802.11a 5GHz 54Mbps
IEEE 802.11n 2.4GHz 600Mbps
5GHz
IEEE 802.11ac 5GHz 6.9Gbps
IEEE 802.11ad（WiGig） 60GHz 6.8Gbps
IEEE 802.11ax 2.4GHz 9.6Gbps
5GHz

IoT向き無線LANと異なるのは、周波数帯がより高周波の2.4GHz/5GHzを利用する点と、新規格11ac/11ad/11ax、従来規格11b/11g/11a/11n、ともにデータ伝送速度が速い点です。スマホのAPは、家庭や店舗に設置された無線LANルータで、高周波利用のため伝送距離は精々100m程度、60GHzの11adでは10m程度です。公衆網5G高速化に伴い新無線LAN規格：11ac/11ad/11axが普及しつつあります。

動画再生などの利用形態も多いPC/スマホ向き無線LANは、「高速大容量化」が求められます。IoTの「長距離省電力」要求とは、異なる無線LAN規格となっています。

まとめ：IoT MCUプライベート網の無線LAN規格

無線LANアクセスポイントからの伝送距離変化
無線LANアクセスポイントからの伝送距離変化

プライベート網無線LAN規格は、APからの伝送距離により、

  1. 「近距離（10m以下）超省電力」規格（周辺機器向き）：Bluetooth（IEEE 802.15.1）
  2. 「短距離（100m程度）高速大容量」規格（PC/スマホ向き）：IEEE 802.11a/11b/11g/11n/11ac/WiGig（11ad）/11ax
  3. 「長距離（1km以上）省電力」規格（IoT向き）：Wi-Fi HaLow （IEEE 802.11ah）/11.af/11.ba

の3種類があります。

IoT MCUには、最新のBluetooth 5や屋外や1km半径の広い敷地内でも使える長距離省電力規格のWi-Fi HaLowが望まれるようです。

但し、普及済みのPC/スマホ向き無線LAN規格が使えると、屋内の既存PC/スマホ無線LANルータをインターネット空間へのAPに利用でき、常時電力供給も可能なため、低コストIoT MCUを実現する方法になりうると思います。


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

IoT MCU汎用Baseboard

WithHappy

弊社が考える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マイクロエレクトロニクス

WithHappy

公衆網の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終了

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