IoT MCUの無線LAN

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内蔵MCUBluetooth 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コア次世代像

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へお寄せください。

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

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を代替として弊社は選びました。

全テンプレート継続販売

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

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

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

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を入れさえすれば、簡単に高信頼インタフェースが実現できる理由です。



MCUの5V耐圧ピン

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

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

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

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

MCU動作電圧

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

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

レベルシフタ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

TI.comの新しい購入機能

米)半導体大手テキサスインスツルメンツのサイト:TI.comに追加された新しい製品購入機能を紹介します。

TIは、アナログICやDSP(Digital Signal Processor) 、本ブログ掲載の低電力動作Cortex-M4マイコンMSP432など多くの半導体デバイスや製品を開発・販売しています。ただ、競合他社と比べると、従来は個人調達に便利な通販のDigiKeyやMouserの取扱いTI製品品揃えが少ない傾向がありました。新しいTi.com購入機能は、これを改善できます。

TI.comの新しい購入機能

DigiKeyやMouserと同じように、TI.comで直接TI製品やデバイスを購入できます。違いは、TI製品のみを扱う点。もちろん価格は多少違いますが、品揃えは豊富です。下図のように、試作から生産に至るまで調達できます。

TI.comの新しい購入機能(出典:myTI newsletter)
TI.comの新しい購入機能(出典:myTI newsletter)

他社MCUベンダサイトのカートは、DigiKeyやMouserなどの外部通販へのリンクが一般的です。TIは、一律配送などのサービスも含めてTI自らが通販を行うという点が他社と異なる新しい機能です。

最大30個までという制限は設けていますが、個人購入や試作レベルの調達なら十分利用できます。通販会社にとっては脅威でしょう。TIは、手数料を通販会社に払うよりも、全製品の通販を自社で行う方法を選択したのだと思います。

MSP432デバイス品揃え豊富、低価格

本ブログ掲載の低電力動作MSP432評価ボード:MSP-EXP432P401R(ARM Cortex-M4F/48MHz、256KB/Flash、64KB/RAM、浮動小数点ユニット、DSPアクセラレーション)も、もちろんTI.comから購入できます。

さらに、評価ボードでの開発後、実機で利用するFlash/RAM容量が異なる様々なMSP432デバイスも購入できます。

評価ボード:MSP-EXP432P401Rは、CCS Cloud IDEやArduino IDEに似たEnergia IDEが使えるなど、他社MCU開発にないユニークなソフトウェア開発環境が特徴です。

CCS DesktopとCCS Cloud、Energia IDE比較(出典:TIサイト)
CCS DesktopとCCS Cloud、Energia IDE比較(出典:TIサイト)

※Energia IDEの詳細は、関連投稿:MSP432オープンプラットフォーム開発環境を参照してください。
※CCS Cloud IDEの使い方は、関連投稿:CCS Cloud IDEを参照してください。

Energia IDEは初めてソフトウェアを開発する方に、CCS Cloud IDEはいつでも何処でも場所を選ばずにブサウザだけでソフトウェアを開発したい方に向いています。

また、パンデミック表明となったCOVID-19収束宣言がWHOからでるまでは当分の間、在宅勤務やMCU開発の自己研鑽時間、または数人でのテレワークMCU開発などの機会も増えるでしょう。これらにもCCS Cloud IDEは、活用できると思います。

評価ボードを使ったプロトタイプ開発は、最終的に実機で使うMCUデバイスの選択が的確にできます。つまり、実機でよりFlash/RAM容量が必要になるか、それともより低価格デバイスで製品や製品改良などにも十分賄えるかなど、製品実装MCUの選択が、プロトタイプ結果に基づいて具体的にできる訳です。

新しいTI.com購入機能は、MSP432デバイスの品揃えが豊富です。プロトタイプ開発の選択結果を反映した実機MCUデバイス調達が、直接Ti.comから低価格で可能です。通販DigiKeyやMouserの代替になりえます。

MCUベンダAPI生成ツール比較

お知らせ

弊社サイト:マイコンRTOS習得を2020年版へ改版しました。前稿までのFreeRTOSサンプルコード(1)~(5)結果を、2017年版へ反映させた結果です。是非、ご覧ください。

MCUベンダAPI生成ツール一覧

FreeRTOSサンプルコード(1)で予告したベンダ毎に異なるAPI生成ツールやその違い、サンプルコードとの関係を説明します。本ブロブ掲載MCUベンダ5社のAPI生成ツール一覧が下表です。

MCUベンダトップシェア5社のMCU API生成ツール一覧
ベンダ API生成ツール ブログ掲載MCU API生成方法
Runesas CS+ RL78/G1x 個別ハードウェア設定
NXP SDK LPC111x/LPC8xx/Kinetis E/LPC5411x MCU設定
STM STM32CubeMX STM32Fx/STM32Gx 個別ハードウェア設定
Cypress PSoC Creator PSoC4/PSoC4 BLE/PSoC4000/PSoC6 個別ハードウェア設定
TI CCS STM432 MCU設定

IDEとは別のAPI生成ツール専用名があり、ツール単独で更新するのが、NXP)SDK、STM)STM32CubeMXです。Runesas)CS+、Cypress)PSoC Creator、TI)CCSは、IDEにAPI生成ツールが組込まれていますので、IDE名称をAPI生成ツール欄に記載しています。
※CS+のAPI生成ツールは、単独でコード生成と呼ぶこともあります。

さて、これらAPI生成ツールには、2種類のAPI生成方法があります。

  • MCU設定:利用MCUを設定し、内蔵ハードウェアAPIを一括生成…NXP)SDK、TI)CCS
  • 個別ハードウェア設定:利用内蔵ハードウェアを個別設定し、APIを生成…Runesas)CS+、STM)STM32CubeMX、Cypress)PSoC Creator

MCU設定タイプのAPI生成ツールは、全内蔵ハードウェアAPIを、ユーザ利用の有無に係わらず一括生成するため、規模が大きく、SDK(Software Development Kit)などパッケージ化してIDEへ提供されます。但し、コンパイル時に利用ハードウェアのみをリンクしてMCUへダウンロードするので、少Flashサイズでも問題はありません。

MCU設定タイプの特徴は、例えば、UART速度設定などのハードウェア動作パラメタは、APIパラメタとしてMCUソースコードにユーザが記述します。

MCU設定タイプのNXP)SDKのUART API例
MCU設定タイプのNXP)SDKのUART API例

一方、個別ハードウェア設定タイプは、UARTなどのハードウェア動作パラメタは、API生成前にGUI(Graphical User Interface)で設定し、設定後にAPIを生成します。このためユーザが、MCUソースコードのAPIに動作パラメタを追記することはありません。

個別ハードウェア設定タイプのSTM32CubeMXのUART API例
個別ハードウェア設定タイプのSTM32CubeMXのUART API例

API生成ツール比較

MCU設定タイプのAPI生成ツールは、使い方がMCU設定のみで簡単です。また、ハードウェア動作パラメタがMCUソースコード内にあるため、動作変更や修正もIDE上で行えますが、人手によるバグ混入の可能性も高まります。

個別ハードウェアタイプAPI生成ツールは、MCUソースコード内のAPI記述が簡素です。生成されたAPI内部に動作パラメタが含まれているからです。但し、ハードウェア動作変更には、IDEから一旦API生成ツールに戻り、APIの再生成が必要です。この場合でも、MCUソースコードは不変ですので、GUI設定にミスが無ければバグ混入は少ないでしょう。

どちらにも、一長一短があります。敢えて分類すると、ソフトウェア開発者向きが、MCU設定タイプ、ハードウェア開発者向きでTP:Test Program応用も容易なのが、個別ハードウェア設定タイプです。

個別ハードウェア設定タイプであっても、Cypress)PSoC Creatorなどは、通常パラメタはBasicタブ、詳細パラメタはAdvanceタブで分け、誰でも設定を容易にしたツールもあります。

MCUソフトウェアは、C言語によるMCU API制御です。MCU API生成ツールの使い勝手が、ソフトウェア生産性の半分程度を占めていると個人的には思います。

サンプルコード/サンプルソフトウェア

各社のサンプルコード/サンプルソフトウェアは、上記API生成ツールのMCUソースコード出力例です。

従って、サンプルコードには、出力例と明示的に判るよう多くのコメントが付加されています。初めてサンプルコードを見る開発者は、注意深くコメントを読んで、そのMCU開発の全体像を理解することが重要です。

全体像が理解済みであれば、より効率的な開発手法、例えば、(推薦はしませんが)個別ハードウェア設定タイプであっても、IDEからAPI生成ツールに戻らずに、直接MCUソースコードでハードウェア動作パラメタを変更するなどのトリッキーな使い方も可能です。

MCU開発とCOVID-19

新型コロナウイルス:COVID-19が世界的に流行しつつあり、工場閉鎖や物流への影響も出始めています。現状は治療薬が無いので、「個人の免疫力と体力」が生死の決め手です。

同時にMCU供給不足/停止など、開発への波及も懸念されます。これに対し「個人で第2のMCU開発力」を持つことが解決策を与えます。

本稿は、MCUベンダトップシェア5社のMCU API生成ツールを比較しました。MCUシェア評価ボード価格や入手性、個人の好みなど、是非ご自分にあった比較項目で、現在利用中のMCUに代わる第2のMCU開発力を持つことをお勧めします。

第2のMCU開発力は、現行と視点が変わり利用中MCUスキルも同時に磨くことができ、様々な開発リスクに耐力(体力)が付きます。短期で効果的な第2のMCU開発力の取得に、弊社マイコンテンプレートがお役に立てると思います。

ARM MCU変化の背景

昨今のARM MCU事情、そして今後の方向性”という記事が、2019年11月22日TechFactoryに掲載されました。詳細は記事を参照して頂き、この中で本ブログ筆者が留意しておきたい箇所を抜粋します。その結果、ARM MCU変化の背景を理解できました。

現在のARM MCUモデル

Cortex-Mコアだけでなく、周辺回路も含めた組み合わせARM MCUモデルが、端的に整理されています。

・メインストリームは、Cortex-M4コアに周辺回路搭載
・ローパワーは、Cortex-M0+に低消費電力周辺回路搭載
・ローコストは、Cortex-M0に周辺回路を絞って搭載

例えば、STマイクロエレクトロニクスの最新STM32G0xシリーズのLPUART搭載は、ローパワーモデルに一致します。各Cortex-Mコアの特徴は、コチラの投稿の5章:Cortex-M0/M0+/M3の特徴などを参照してください。

ARM MCUの新しい方向性

2019年10月時点で記事筆者:大原雄介氏が感じた今後のARM MCU方向性が、下記4項目です。

  1. ハイエンドMCU動作周波数高速化、マルチコア化
  2. RTOS普及
  3. セキュリティ対応
  4. RISC-Vとの競合

以下、各項目で本ブログ筆者が留意しておきたい箇所を抜粋します。

1.ハイエンドMCU動作周波数高速化、マルチコア化

動作周波数高速化は、NXPのi.MX RT 1170のことで、Cortex-M7が1GHzで動作。i.MX RT1170は400 MHz動作のCortex-M4も搭載しているディアルコアMCU。

これらハイエンドMCUの狙いは、性能重視の車載MCU比べ、コスト最重視の産業機器向け高度GUIやHMI:Human Machine Interface用途。従来の簡単な操作パネルから、車載のような本格的なGUIを、現状の製造プロセスで提供するには、動作周波数の高速化やマルチコア化は必然。

2.RTOS普及

普通はベアメタル開発だが、アプリケーション要件でRTOS使用となり、ポーティング例は、Amazon FreeRTOSが多い。マルチコアMCUでは、タスク間同期や通信機能実現には、ベアメタルよりもRTOS利用の方が容易。また、クラウド接続は、RTOS利用が前提となっている。

3.セキュリティ対応

PAS:Platform Security Architectureというセキュリティ要件定義があり、これが実装済みかを認証するPSA Certifiedがある。PAS Certified取得にはTrustZoneを持つATM v8-MコアCortex-M23/33が必須ではなく、Cortex-M0やM4でも取得可能。但し、全MCUで取得するかは未定で、代表的なMCUのみになる可能性あり。

4.RISC-Vとの競合

ARM CMSISからずれるCustom Instruction容認の狙いは、競合するRISC-Vコアへの対抗措置。RISC-V採用製品は、中国では既に大量にあり、2021年あたりに日本でもARMかRISC-Vかの検討が発生するかも?

ARM MCU変化背景

本ブログ対象の産業機器向けMCUの1GHz動作や、ディアルコアMCUの狙いは、ADAS(先進運転支援システム)が引っ張る車載MCU+NVIDIA社などのグラフィックボードで実現しつつある派手なGUIを、10ドル以下のBOM:Bill Of Matrixで実現するのが目的のようです。また、産業機器向のMCUのAIへの対応も気になる点です。これにら向け、各種ツールなども各ベンダから提供されつつあります。

ハイエンドMCU開発でRTOS利用が一般的になれば、下位MCUへもRTOSが利用される場面は多くなると思います。タクス分離したRTOSソフトウェア開発は、タスク自体の開発はベアメタルに比べ簡単で、移植性や再利用性も高いからです。ベアメタル開発は、RAMが少ない低コストMCUのみになるかもしれません。

RTOS MCU開発も、Windowsアプリケーション開発のようにOS知識が(無く!?)少なくても可能になるかもしれません。

MCUベンダのセキュリティ対応は、まだ明確な方針が無さそうです。RTOSと同様、IoTアプリケーション要件がポイントになるでしょう。総務省による2020年4月以降IoT機器アップデート機能義務化予定などもその要件の1つになる可能性があります。

Custom Instructionは、コチラの投稿の5章でベンダ独自のカスタム命令追加の動きとして簡単に紹介しましたが、その理由は不明でした。これが、競合RISC-Vコアへの対抗策とは、記事で初めて知りました。

本ブログ記事範囲を超えた、広い視野でのMCU記事は貴重です。

来年開発予定のベアメタルCortex-M4テンプレートへ、RTOSの同期や通信機能を簡易実装できれば、より役立ち、かつRTOS普及へも対抗できるかもしれないと考えています。クラウド接続IoT MCUは、Amazon FreeRTOSやMbed OS実装かつ専用ライブラリ利用が前提なのは、ひしひしと感じています。