カテゴリー: MCU：マイコン

マイコンやIoT関連の情報、Tipsなどを記載します。

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

MCUセキュリティ話題

WithHappy

MCU開発中、進捗が詰まることはだれでもあります。そんな時にスタックした気分を変えるMCUセキュリティ関連話題を投稿します。

MCU開発には集中力が必要ですが、その持続は、精々数時間です。人のスタック深さは有限ですので、開発を経過時間で区切るのが1つ、別方法として集中気分を切替て開発詰まりを乗切る時の話題を示します。

気分転換が目的ですので、硬い話ではありません😁。

セキュリティ更新終了

Microsoftが、Office 2010は今年2020年10月13日、Windows 10バージョン1903は2020年12月8日にサポートを終了します。これらソフトウェアご利用中の方は、新ソフトウェアへの入替が必要です。

サポート終了とは、「セキュリティ更新プログラム配布終了」のことです。ソフトウェア自体がPCで使えなくなる訳ではありません。しかし、ハッカーなどによる新たなサイバー攻撃を防ぐ手段が無くなりますので、安全・安心な利用ができなくなります。

ところで、安全・安心の根拠、セキュリティ、セーフティ、セキュア…などの日本語は、あいまいに使われます。しかし、英語の「SecurityとSafetyは別物」です。

オンラインセミナー：STマイクロエレクトロニクスのTrustZone対応マイコンによるIoTセキュリティによると、

  • Security：外部からの危害（攻撃や改竄）から、MCU内部が保護されている状態
  • Safety：MCU誤動作や故障などが原因で、MCU外部へ衝突や爆発などの危害を与えない状態

英語でのSecurityとSafetyの使い分けは、対象がMCU内部ならSecurity、MCU外部ならSafetyと、明確な区別があります。

MCUセキュリティ関連資料を英語で読むときは、対象は単語で解ります。日本語訳資料を読むときは、対象がMCU内部か外部かを区別して理解する必要があります。

IoT機器侵入調査

総務省、IoT機器に侵入を試みる際のIDとパスワードの組み合わせを、従来の100通りから600通りに増やし、侵入できたIoT機器所有ユーザへ対策を呼び掛けた。2020年9月11日、ITmedia。

つまり、ハッカーの代わりに総務省）国立研究開発法人情報通信研究機構（NICT）が、NOTICE：National Operation Towards IoT Clean Environmentに参加しているISP 62社のIPアドレスに対して、疑似攻撃をしかけ、問題があったIPアドレスユーザへ注意を促した、ということです。

過去のサイバー攻撃にあったIDとパスワードにたまたまなっていた場合、たとえ厳重な管理であっても安全でない（!Security）訳です。IoT機器のアクセス方式、「IDとパスワード」には、限界があるかもしれません。

多要素承認

金融庁、銀行・決済各社に本人確認の徹底を要請。2020年9月16日、ITmedia。

ハッカーによるドコモ口座の不正利用が、多要素認証で防げるのかについてのセキュリティ専門家解説は、筆者には正直言って判りません。

多要素認証とは、セキュリティ情報アクセス時、スマホなどの本人しか持たないモバイルデバイスへ送った認証コードなどを使ってログインする仕組みです。「パスワードレスログイン」とも言われます。

海外ドラマでは、スマホの乗っ取りも簡単です。モバイルデバイスの2要素認証コード入力で十分なのでしょうか？　スマホを持たない人は、決済サービスを利用できない、またはさらに生体認証が必要なのでしょうか？

この多要素認証をMCUへ実装する場合、どうすれば良いのでしょうか？

暗号化脆弱性

TLS 1.2とそれ以前に脆弱性、2020年9月16日、マイナビニュース。

ブラウザ経由でクレジットカード番号を送る時、通信データを暗号化し盗聴を防ぐしくみが、TLS：Transport Layer Securityです。このTLS 1.2に脆弱性が見つかり、TLS 1.3を使うなどの対策が示されています。

MCUで以前は問題無かった暗号化技術にこのような対策を実施するには、組込み済みソフトウェア、またはハードウェアの一部更新が必要です。

暗号化部品が壊れた、または脆弱性発見時、対象部品のみ交換できるMCU機器があれば良いのですが…。

デジタル後進国

“デジタル後進国”で検索すると、「日本はデジタル、IT後進国」だという記事概要が多く見つかります。

セキュリティ用語の区別もあいまいなままの日本です。先進国開発済みのMCUセキュリティ技術を、理解不足のまま流用しても当面は良いのでしょうが…、セキュリティとあいまい性、本質的に相反する気がします。
ハッカーの攻撃は、あいまい性で生じるMCUセキュリティのすきまを狙うのですから。

MCUセキュリティに関しては、何事にもあいまい性が好まれ日本不得意な「明確さ」、これが必須だと思います。

＊　　＊　　＊

MCU開発時、スタック気分を変える時に役立つMCUセキュリティ関連話題を5つ投稿しました。

IDとパスワードで保護するMCUセキュリティ
IDとパスワードで保護するMCUセキュリティ

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開発の情報収集と生産性向上、両方にお役に立てば幸いです。

Linux Mintお勧め理由

WithHappy

PCへインストールするLinuxには、様々なディストリビューションがあります。ディストリビューションとは、Linux 本体とLibreOfficeなどの標準搭載アプリケーションを1パッケージにまとめ、利用者がLinuxインストールとその活用を即座にできるようにした配布形態のことです。

本稿は、これらディストリビューションの中で、筆者がLinux Mint 20 MATEエディション（64ビット）をWindows MCU開発環境トラブル発生時、代替に使えるLinuxディストリビューションとしてお勧めする理由を示します。

Linuxディストリビューション

2020年7月発表のWebサイト向けLinuxディストリビューションシェアを見ると、UbuntuやDebianなどがメジャーなディストリビューションであることが判ります。

様々なLinuxディストリビューション、特にUbuntuやDebian、Raspberry Pi用のRaspbianと本稿のLinux Mint概要は、コチラの情報が参考になります。用途、安定性/情報量/デザイン性などでディストリビューションを評価した結果が示されています。

Linux Mintとメジャーディストリビューションの差

UbuntuとLinux Mintの関係を、まとめました。

  • Ubuntuベースの派生形として、様々なデスクトップPCディストリビューション（Linux Mint）がある
  • Ubuntuは定期的にアップグレートされるが、主にセキュリティ修正のみでアプリケーションの大幅更新をしない5年長期サポート版：LTS版（最新は2020年4月リリース：Ubuntu Desktop 20.04）もあり、このLTS版に準ずる派生ディストリビューション（Linux Mint 20.x）がある
  • Ubuntuアプリケーションリポジトリ（公式アプリケーション保存庫）をそのまま使える派生ディストリビューション（Linux Mint）がある

MCU開発者の方は、EclipseベースIDE（EclipseベースIDE≒Ubuntu）なら、どれもほぼ同じユーザインタフェースで、同じプラグインが使えるのと同様と言えばご理解頂けると思います。

Ubuntuが最もシェアが高いのは、派生ディストリビューションのベースだからです。また、MCUベンダのLinux版IDEなどの説明書も、トップシェアUbuntu利用を前提に提供されます。

Linux Mintは、Ubuntu派生ディストリビューションの1つで、Linux特有のコマンド操作やリポジトリもUbuntuと同じです。また、UbuntuよりもWindowsやMacの操作に近いGUIを持ち、万一の際のシステムバックアップツール（TimeShift）も標準搭載済みです。

つまり、「Windows/Macユーザが、Linux Mintインストール後、Linux本体のカスタマイズは不要で、即MCU開発アプリケーションが利用できる点」が、Linux Mintをお勧めする最大の理由です。

※MCU開発アプリケーション（例えばNXPのMCUXpresso IDE、STMのSTM32CubeIDE）は、非搭載ですので、別途インストールは必要です。

Linux MintとメジャーディストリビューションUbuntuの主な差は、GUI、少し遅れるリリース時期と考えて頂ければ良いと思います。

Linux Mintの3エディション

Windows Home/Proと同様、Linux Mintにも、3種類のエディションがあります。

GUI処理の軽い方から、Xfce/MATE/Cinnamonエディションと呼ばれます。少し古い版ですが、Linux Mint 17 ユーザズガイドによると、どのエディションを使えば良いかわからない時は、METAエディションを使ってください、とあります。

筆者は3種類とも試しましたが、処理の軽さとメニューの解りやすさ、使いやすさからMETAエディションをお勧めします。

GUIは、好みの問題がありますので、3エディションをインストールして試すと良いでしょう。クリーンインストール所要時間は、せいぜい30分程度です。インストール方法は、まとめに記載しております。

まとめ：お勧めLinux MCU開発環境Linux Mint 20 MATEエディション（64ビット）

最新Ubuntu Desktop 20.04ベースで、Windows MCU開発環境トラブル発生時、代替に使えるLinuxディストリビューションとして、Linux Mint 20 METAエディション（64ビット）をお勧めする理由を示しました。

多発するWindows起因のトラブル発生時、Windows MCU開発に慣れた開発者が、MCU開発を中断することなくLinux環境で継続するには、Windows操作に近いGUI、LTS版のOS安定性、Linux特有コマンドへの情報量多さなどが必要で、これらを満たすのがLinux Mintです。

Linux Mint 20 METAエディション（64ビット）のPCインストール方法は、ユーザズガイドにも記載されていますが、コチラなどを参考にすると素早くインストールができます。

Linux Mint 20と旧版Mintシェアは、Mint公式ブログのMonthly News – July 2020によると、投稿時点では、32ビットPCにも対応した前版Mint 19.xのほうが高いのですが、いずれ逆転すると思います。全ての32ビットOS新規開発は、完了しました。

Mint 20標準搭載のLibreOfficeは、安定性重視のStill版v6.4.5です。カスタマイズ不要と書きましたが、Fresh版v7.0.0へ変更したい方は、コチラに方法が記載されています。



FRDM-KL25Z タッチスライダの使い方

WithHappy

FRDM-KL25Z評価ボードのタッチスライダ（Capacitive Touch Slider）の使い方を説明します。

タッチスライダ動作にはのMCU内蔵TSIが必須（出展：Fig1データシート、Fi2ユーザズマニュアル）
タッチスライダ動作にはのMCU内蔵TSIが必須（出展：Fig1データシート、Fi2ユーザズマニュアル）

タッチスライダ

CypressのPSoC 4000S/4100S/4100PSテンプレートでも使用中の指によるタッチユーザインタフェースは、MCU入力手段として人気があります。

NXPの多くのFRDM評価ボードにもFigure2のようにCapacitive Touch Sliderが実装済みですが、これをタッチスライダとして動作させるには、MCU内蔵TSIハードウェアと、これを制御するTSIライブラリの両方が必須です。
※TSI：Touch Sensor Input。

例えば、FRDM-KE02Z40Mでは、TSIハードウェアがMCU非内蔵なためタッチスライダは動作しません。

MCUXpresso SDKのTSI：Touch Sensor Inputサンプルプロジェクト

MCUXpresso SDKのTSIサンプルプロジェクトは、driver_examples>tsi_v4>normalにあります。MCUXpresso SDKの使い方は、関連投稿を参照してください。

MCUXpresso SDKのTSIサンプルプロジェクト
MCUXpresso SDKのTSIサンプルプロジェクト

以降は、サンプルプロジェクトのソースコードを横目で見ながら本稿を読んで頂くと良く分かると思います。が、ソースコードが無い場合には、まとめ章へスキップしてください。

tsi_v4_normal.cを見ると、このサンプルプロジェクトは、MCU内蔵TSIハードウェアをキャリブレーション（L127）後、下記3つの方法でTSIを制御しているサンプルであることが解ります。
※キャリブレーションとは、測定系ハードウェアの測定精度を上げる処理で、ADCなどでも必要です。

  1. （L136）SOFTWARE TRIIGER SACN USING POLLING METHOD
  2. （L159）SOFTWARE TRIIGER SACN USING INTERRUPT METHOD
  3. （L178）HARDWARE TRIIGER SACN

1や2でもTSIソフトウェアライブラリ単独制御ではなく、TSIハードウェア/ライブラリ両方が必須であることに注意してください。3も同様です。

サンプルプロジェクトでは、1～3の方法を順に処理し、各方法の最後にPRINTFで取得値xxxxをConsoleへ出力します。その出力例がreadme.txtにあります。

MCUXpresso SDKのTSIサンプルプロジェクト3方法の動作出力例
MCUXpresso SDKのTSIサンプルプロジェクト3方法の動作出力例

3番目のハードウェア割込み方法設定後、無限ループへ入ります。

このサンプルプロジェクトソースコードは、本来は3サンプルプロジェクトに分離すべきものを、１つにまとめた書き方をしています。つまり、TSIソフトウェアポーリングプロジェクト、TSIソフトウェア割込みプロジェクト、TSIハードウェア割込みプロジェクトを１つにまとめています（ので、少々解りにくいかもしれません）。

TSIソフトウェアポーリングプロジェクト

そこで、TSIソフトウェアポーリングプロジェクトのみを抽出します。

先ずは、ソフトウェアポーリング処理後、他の2方法を飛ばして無限ループへジャンプさせます。例えば、L157のTSI_ClearStatusFlags()の後にgoto LOOP;を追加し、無限ループの前に飛び先ラベルLOOP:を加えます。すると、ポーリング方法のみの処理結果がConsoleへ正常出力されます。

つまり、ソフトウェアポーリングのみで、1回TSI制御ができることが確認できました。

組込み処理は、初期設定と無限ループ内の繰返し処理の2つに分けて考えるのが常套手段です。そこで、ソフトウェアポーリングの方法も、初期設定と繰返し処理の２つへ分けます。

L101～L143がソフトウェアポーリングの初期設定、L143～L157が繰返し処理です（※L143がダブっているのは間違いではありません）。この繰返し処理先頭L143に無限ループに付加したラベルLOOP:を移動し、無限ループ化します（無限ループに加えたラベルは削除してください）。

動作させ、TSIソフトウェアポーリングプロジェクトのみの抽出と連続ポーリング処理が完成です。

他の2方法、TSIソフトウェア割込みプロジェクトや、TSIハードウェア割込みプロジェクトのみを抽出する場合も同様です。3プロジェクトに分離すると、各方法の理解がより深まります。

※FRDM-KL25Zは、TSI channel 9と10の両方を使っています。両チャネルを使うメリットは、2つあります。1つは、その取得値変化から、指がスライダの左右どちらへ移動したかが解ることです。抽出プロジェクトで、その取得値変化の様子を実際に試してください。

TSIタッチスライダパッドの2チャネルの使い方
TSIタッチスライダパッドの2チャネルの使い方

※もう1つのメリットは、タッチ感度が上がることです。上図のように、各チャネルカバー範囲は相補的ですので、片チャネルでタッチ検出するよりも両チャネル検出の方が、より高感度になります。

FRDM-KL25Z タッチスライダの使い方

前章までで、FRDM-KL25ZタッチスライダのSDKサンプルプロジェクト3制御方法を解説しました。

本章は、もっと実用的なタッチスライダの使い方を説明します。

前章のTSIソフトウェアポーリング方法で、TSIチャネル9のみを使い、タッチスライダを物理スイッチの代わりに動作させる使い方です。

この動作は、オリジナルサンプルプロジェクトのTSIハードウェア割込み方法で、タッチスライダを指で触るとLEDがトグル点滅、つまり、スライダではなくタッチパッドとして動作するのと同様です。物理スイッチではないので、経年変化が少ないことが特徴です。

FRDM-KL25Z の性能を100%使ったTSIサンプルプロジェクトでは、タッチスライダ動作も十分可能です。

しかし、FRDM-KL25ZでTSI処理以外にも様々な処理を行う場合は、このタッチパッド的使い方が実用的だと筆者は思います。オリジナルサンプルプロジェクトも、この事を暗に示しているのかもしれません。

FRDM-KL25Z タッチスライダの初期設定

初期設定は、抽出したTSIソフトウェアポーリングプロジェクトの初期設定からチャネル10設定分を削除します。

FRDM-KL25Z タッチスライダの無限ループ内処理

抽出プロジェクトは、無限ループ内でチャネル9と10を「連続計測」しConsole出力しました。実用的な処理では、タッチスライダ処理以外の様々な他の処理を1個のMCUで行うため、この計測処理は（他の様々な処理が間に挟まるため）「離散的」になります。

離散計測処理を行う際の注意点は、チャタリング対策です。

指によるタッチであっても、本当にタッチしたのか、または、たまたま触っただけなのかをソフトウェア側で判断する必要があり、これをチャタリング対策（＝入力ノイズ対策）と言います。

例えば、複数回の離散タッチ検出ならば本当のタッチ、1回のみのタッチ検出ならば、触っただけのノイズでタッチと判断しない等です。

まとめ

FRDM-KL25Z評価ボード付属タッチスライダ制御を、MCUXpresso SDK TSIサンプルプロジェクトのソフトウェアポーリング、ソフトウェア割込み、ハードウェア割込みの3方法から解説し、タッチスライダを物理スイッチの代わりに動作させるタッチパッド的な使い方を説明しました。

3方法をまとめたオリジナルサンプルプロジェクトを、方法別に分離プロジェクト化し、初期設定と無限ループ内処理の2つに分け、ループ内処理のソフトウェアチャタリング対策を説明しました。

開発中のKinetis Lテンプレートには、本稿で示したチャタリング対策済みの応用例を添付します。

FRDM-KL25Z VCOMの使い方

WithHappy

FRDM-KL25ZのUARTとPC を、USB経由のVCOM：Virtual COM port接続する方法を説明します。

FRDM-KL25ZのUARTとVCOM接続中のTera Term画面
FRDM-KL25ZのUARTとVCOM接続中のTera Term画面

VCOM：Virtual COM port

MCU評価ボードとPC間は、USBで接続されており、このUSB経由でターゲットMCUのプログラミングやデバッグを行います。前稿説明のJ-TAGハードウェアデバッガの代わりが、評価ボード付属デバッガで、FRDM-KL25Zの場合は、OpenSDAと呼びます。

本ブログ掲載の評価ボード付属デバッガが下表です。ベンダ毎に付属デバッガの呼び名は異なりますが、どれも機能的には同じです（Renesasは、別途E2 Lite/E2ハードウェアデバッガで機能提供します）。

ベンダ毎に呼び名が異なる評価ボード付属デバッガ
ベンダ 評価ボード付属デバッガ 評価ボード例 MCU – PC間通信
NXP OpenSDA/CMSIS-DAP FRDM-KL25Z/LPCXpresso54114 UART
STM ST-Link STM32G071RB UART
Cypress KitProg CY8CKIT-145 UARTとI2C
TI XDS110-ET MSP-EXP432P401R LaunchPad UART
Renesas なし（E2 Lite/E2必須） BlueBoard-RL78G13-64 UART

評価ボード付属デバッガには、ターゲットMCUのプログラミング/デバッグ機能に加え、MCUのUARTとPCのUSB間を橋渡し（＝接続）する機能があります。これをVCOM：Virtual COM port接続といい、Tera Termなどのシリアル通信ソフトウェアをPCにインストールすれば、いとも簡単にMCUの UART通信ソフトウェア送受信の動作確認ができます。

※Tera Termの代わりにMCUXpresso IDEプリインストールのSerial Terminalも使えます。

MCUXpresso IDEのTerminalによるTera Termの代用
MCUXpresso IDEのTerminalによるTera Termの代用

UART：Universal Asynchronous Receiver/Transmitter

UARTは、最重要MCU周辺回路です。

古くから装置組込み済みMCUの再プログラミング手段としてUARTは利用されてきました。最新IoT MCUでも、セキュア・ブート、セキュア・ファームウェア更新に使える手段はUARTのみです（関連投稿：STM32G0/G4のRoot of Trustなどを参照してください）。

さらに、MCUXpresso SDKの評価ボード新規プロジェクト作成時でも、最初からActiveな周辺回路はUART0だけです（※UARTの“0”に注意してください）。ボード実装済みのLEDさえ初期値はInactiveです。つまり、UARTを動作させないMCUは無いと言えるでしょう。

UARTソフトウェアの動作確認には、送・受信機能を持つため通信相手が必要で、VCOM接続によりPCが通信相手になるため、最重要周辺回路：UARTソフトウェアの動作確認ができる訳です。

FRDM-KL25ZのVCOM接続方法

前置きが長くなりました。本章から評価ボード：FRDM-KL25Z をOpenSDA経由でVCOM接続する方法を説明します。

結論から言うと、FRDM-KL25ZのVCOM接続には評価ボードに2配線追加が必要です。2配線を追加しTera Termを使ったUART送受信中の画面が写真1です。

  • J1-2とJ2-20配線・・・・・・・UART0_TX：PTA1とUART1_TX：PTE0接続
  • J1-1とJ2-18配線・・・・・・・UART0_RX：PTA2とUART1_RX：PTE1接続

FRDM-KL25Z関連資料は不親切で、この必須配線が分かりにくいので順を追って説明します。が、配線さえ追加すれば、全てのSDK UARTサンプルプロジェクトが正常動作しますので、急ぐ方は、まとめ章へスキップしてください。

MCUXpresso SDK UARTサンプルプロジェクトと回路図

FRDM-KL25ZのMCUXpresso SDK UARTサンプルプロジェクトは、どれもUART0ではなくUART1を使った処理例です。readme.txtには、“USB to Com Converter：USB2COM”をJ2-20/18と配線せよと記載されています。もちろん、別途USB to Com Converterを用意し、このとおり接続すればサンプル動作確認ができるでしょう。

しかし、OpenSDAにUSB to Com Converter と同じVCOM機能が備わっているのにこれを使わない手はありません。

そこで、FRDM-KL25Z回路図Rev.EのSheet 3を見ると、OpenSDAとMCUはUART0で接続済みで、R5とR6でUART1とも並列接続済みなのが判ります。本来ならUSB to Com Converterが無くてもそのままUART1サンプルプロジェクトが動作するハズです。

試しに、サンプルプロジェクトのUART1をUART0へ変更すると、コンパイル時に妙なワーニングが発生しますが、VCOM接続でUART0が動作します（UART0からUART1への変更にはMCUXpresso Config Toolsの使い方を参照してください）。つまり、UART0とOpenSDAは、回路図どおり接続済みな訳です。

R5とR6は実装されていますが、この代わり追加したのが2配線です。

その結果、UART1で全てのサンプルプロジェクトが正常動作します。また、UART0で発生した妙なワーニングもありません。

つまり、SDK付属UART1サンプルプロジェクトの正常動作には、J1-2とJ2-20、J1-1とJ2-18の2配線が必要です。この時UART0は、並列接続を避けるためInactiveにします。

※サンプルプロジェクトは、元々UART0がInactiveです。新規プロジェクト作成の時は、デフォルトActiveなUART0をInactive、UART1をActiveへ変更すると、サンプルプロジェクトがそのまま流用できます。

※評価ボード回路図最新版がRev.Eです。FRDM-KL25Z評価ボード裏側にシールが貼ってあり、回路図版数Rev.Eと一致、R5とR6も実装済みですが正常動作には追加配線が必要でした。回路図と実評価ボードの版数には、留意してください。

まとめ、新開発汎用Kinetis Lテンプレート

UARTとVCOM接続の重要性を示し、FRDM-KL25Z評価ボードで、VCOM接続を使ってMCUXpresso SDK UART1サンプルプロジェクトを正常動作させるには、評価ボードへ2配線を追加する使い方、各種注意点を説明しました。

このFRDM-KL25Z（Cortex-M0+/48MHz、General Purpose = Main Stream）を使って開発中の汎用Kinetis Lテンプレートは、新規プロジェクト作成時のデフォルトActiveなUART0をUART1へ変更済みで、本稿で示したような開発つまずきを回避する各種情報なども添付します。

写真1は、最も簡単なテンプレート応用例のVCOM動作で、評価ボードの赤/緑/青LEDやタッチスライダ、低消費電力動作のKinetis Lソフトウェアを簡単に開発できるテンプレートです。

3.3V動作新Baseboard

Cortex-M0+のKinetis Lは1.71Ｖから3.6 V動作で、従来弊社が扱ってきた5V Baseboard接続への5V耐圧端子が残念ながらありません。100MHzクラスで3.3V動作のCortex-M4テンプレート開発なども考慮すると、3.3V/1.8V動作用の新しいBaseboardを探し、テンプレート応用例に適用させたいと考えております。

OpenSDA接続トラブル解決方法

WithHappy

ブログ読者様のおかげで、不明だったFRDM評価ボードOpenSDAとMCUXpresso IDE間の接続トラブル解決方法が判明しました。本稿は、このOpenSDA接続トラブル解決方法と、昨今の激しいMCU開発環境変化への開発者対応私案を示します。

OpenSDA v1/v2差

前投稿当日、弊社ブログ読者様からFRDM評価ボードOpenSDA処理トラブル時のJ-Linkハードウェアデバッガによる解決方法と、その根拠となったNXP Communityリンク、さらに、同様のトラブルを抱えた方々向けに、ご提供情報を弊社ブログで共有してくださいとのメールを頂きました。

この場を借りて御礼申し上げます。ありがとうございます。

ご提供情報を基に、FRDM評価ボードOpenSDA v1/v2の差をまとめたのが、下表です。

OpenSDA v1/v2とFRDM評価ボードのまとめ
OpenSDA版数 評価ボード例 開発者 トラブル状況 トラブル解決方法
OpenSDA v1.0 FRDM-KE02Z40M P&E Micro社

(Proprietary)

 弊社あり OpenSDA処理MCUをハードウェアデバッガで書換えれば解決の可能性あり
FRDM-KL25Z 弊社なし
OpenSDA v2.0 FRDM-K64F ARM/mbed.org

(Open source)

 Community内あり OpenSDA処理MCUをハードウェアデバッガ:SEGGER J-Linkなどで書換えて解決（情報提供者様の解決実績あり）
OpenSDA v2.1以上 FRDM-K22F

OpenSDAにはv1系とv2系があり、v1.0は開発会社：P&E MicroのProprietary製品、v2系はARM/mbed.org開発のオープンソースです。また、新しいFRDM評価ボードの多くはv2.1以上を搭載済みで、v1.0やv2.0は古くからあるFRDM-K64Fなどです（Getting Start with MCUXpresso SDK, Rev.3, 03/2017のTable 1掲載ボードでの比較。この表になぜかFRDM-KE02Z40Mの記載はありません）。

Getting Start with MCUXpresso SDK Rev. 3 03-2017のTable 1
Getting Start with MCUXpresso SDK Rev. 3 03-2017のTable 1

OpenSDA接続トラブル解決方法

OpenSDA v2系のブートローダ更新失敗などにより生じたMCUXpresso IDE接続トラブルは、SEGGER J-Linkなどのハードウェアデバッガを使って、OpenSDA処理MCU：Kinetis K20（Cortex-M4）を、評価ボードのJ-TAGコネクタ経由でユーザが直接再プログラミングすれば解決します。再プログラミング用コードも、オープンソースです（情報提供者様の解決実績もあります）。

しかし残念ながら、弊社トラブル中のFRDM-KE02Z40Mは、OpenSDA v1.0です。OpenSDA 1.0は、処理ソフトウェアがProprietary（非オープンソース）ですので、この処理部分のユーザによる再プログラミングが可能かはCase-by-caseです。

通常Proprietaryソフトウェアは、下記理由で再プログラミングができない場合が多いと思います。

理由：前稿で示したユーザ（筆者）が、Windows 10ストレージサービスを一時停止しなかったブートローダ更新は、MCU側にとってはProprietary処理ソフトウェアの悪意侵害と判断される可能性があります。
侵害と判断された場合には、セキュリティ防御手段としてMCU書込みプロテクトをかけ、再プログラミングはできなくなります。また、Proprietaryなので初めからMCU書換えプロテクト済みの可能性もあります。

※USB経由で行うブートローダ更新と、J-TAG経由のOpenSDA処理MCUソフトウェア書換えは、別物であることに注意してください。

FRDM-KE02Z40M Proprietary OpenSDA v1.0再プログラミングは、トラブル実機で試す必要があります。Proprietaryソフトウェアのため、書換え障壁はオープンソースOpenSDA v2系よりも当然高いと思われます。

J-TAGハードウェアデバッガメリット

評価ボードOpenSDA v1.0再プログラミングに必要となるJ-TAGハードウェアデバッガ価格は、例えばSEGGER J-Linkなら最低€300から、円換算で約￥37,000（2020年7月）からです。

同じ金額で10枚程度の最新MCU評価ボードが購入できるので、個人レベルのJ-TAGハードウェアデバッガ購入は勇気がいります。

J-TAGハードウェアデバッガのメリットは、旧Freescale）Bertrand Deleris氏の組込み向けデバッグ技術の基本（2007年3月：EDN）が良く解ります。マルチコアMCUデバッグや、ハードウェア/ソフトウェアブレークポイント差、セキュリティとDebug/Releaseの関係など参考になりますので、一読をお勧めします。

半導体ライフサイクルとMCU開発者対応私案

半導体製品のライフサイクルと製造中止（EOL）対策（2020年7月、EE Times）によると、多くの半導体製品の平均寿命は、3～5年だそうです。

MCUベンダ各社は、10～15年の安定供給を保証しますが、製品搭載済みMCUの賞味期限は、我々開発者が製品化に1年要したとして、発売後5年程度だと個人的には思います。

※MCU賞味期限≒MCUの差別化特徴を活かした製品が競合他社より優位な期間。IoTセキュリティ、AI機能実装や製造プロセス細分化など今後MCUは激変するハズなので、より短くなると思います。

丁度、新車購入後、2回目の車検（3年＋2年＝5年）で名目上の減価償却する自動車と同程度です。

COVID-19の影響で少し鈍る可能性もありますが、ADAS（先進運転支援システム）が引っ張る自動車と同様、“MCU製品も5年目安で世代交代を考えるべきだ”と思います。

また、「日本製品」が海外で売れなくなった根本原因（2020年7月、東洋経済オンライン）を読むと、「加点型の完璧主義」の世界基準に対して、日本人の「盆栽のような減点型のミニマムな完璧ものづくり」が日本敗因の1つです。プラス側メリットやそれに費やした見えない労力などは無視する一方、マイナス側の過度な批判は、日本特有かもしれません。

“基準を減点型→加点型へ180度変える努力が日本は必要”になりそうです。

MCU開発環境は、PC OSも含めて常に変化・進化します。そして、それらの環境変化は全て世界基準です。

MCUXpresso IDEは、7月9日にv11.2.0へ、MCUXpresso SDKの多くは、7月19日にv2.8.0へ更新されました。次々に生まれる新MCUや環境変化に対応するためですが、逆にこれら変化・進化に馴染まない従来MCUや減点型対応者も生じます。これらは、徐々に進化と逆らい「ガラパゴス化」している訳です。

MCU開発者は、変化・進化する環境に対して、開発中、または顧客稼働中のMCUが進化に馴染まなくなる兆候・前兆を素早く捉え、最終利用者と協議の上、従来から180度変えた“加点型対応策を取ることが、ワールドワイドなMCU開発者との競争に生き残り、その結果、日本製品も生き残れる方法”だと思います。

ガラパゴス化が全て悪い訳ではありません。しかし、日本MCU開発者がガラパゴス化すれば、その生存確率は確実に下がります。

まとめ、新開発汎用Kinetis Lテンプレート

これまでの章内容をまとめます。

  • 壊れたFRDM-KE02Z40のOpenSDA v1.0 Proprietary再プログラミングには、J-TAGハードウェアデバッガ：37,000円が必要で、OpenSDA v2系とは異なるProprietaryソフトウェアのため、書換え可能かはトラブル実機検証が必須。
  • J-TAGハードウェアデバッガは、MCUコア/ベンダに依存しない強力デバッグツール。
  • 激変MCU環境に対して、加点型へ進化しないと日本MCU開発者はガラパゴス化する。

これらから、FRDM-KE02Z40（Cortex-M0+/40MHz、5V Robust）のOpenSDA v1.0 Proprietary再プログラミングはあきらめ、5V耐圧が特徴であるKinetis Eテンプレートv2改版開発は中止、新たにFRDM-KL25Z（Cortex-M0+/48MHz、General Purpose = Main Stream）を用いた汎用Kinetis Lテンプレート開発に着手しようと考えております。

5V耐圧の代案は、一般的になってきたレベルシフタを用いる方法でKinetis Eテンプレートの最終利用者様への対応をお願いいたします（関連投稿：MCUの5V耐圧ピンを参考にしてください）。

5V耐圧を失う代わりに、FRDM-KE02Z40Mでは実装していましたが動作しないTouch pad (Slider)が、FRDM-KL25Zでは動作します。Touch pad (Slider)動作には、MCU内蔵Touch Sense Input：TSIハードウェアが必須です。FRDM-KE02Z40Mは内蔵されていません。TSIライブラリソフトウェアのみでは動作しないことは、2015年開発のKinetis Eテンプレート v1で確認済みです。

新開発の汎用Kinetis Lテンプレートは、このFRDM-KL25Z内蔵TSIハードウェアとライブラリ使いTouch pad (Slider)を、外付けSW入力の代わりに用います。

FRDM-KL25Z Block Diagram（出典：ユーザズマニュアル）
FRDM-KL25Z Block Diagram（出典：ユーザズマニュアル）

※FRDM-KL25Z搭載のMCU：MKL25Z128VLK4 （Cortex-M0+/48MHz、Flash:128KB、RAM:16KB、66:IOs）は最新MCUとは言えませんが、「低価格、入手性良し、汎用性（Main Stream）、応用範囲の広さ、OpenSDAトラブル無し」が、新規汎用テンプレート開発採用にプラスに働きました。

さいごに

多彩な情報満載のCommunityですが、逆に欲しい答え発見までにかなりの時間・労力がかかるのもCommunityです。

ブログ読者様ご提供Communityリンクのおかげで、短期間で効率的に問題解決法を見つけることができ、さらにJ-TAGハードウェアデバッガなどの関連情報収集、現状テンプレート開発見直しもできました。

ここにあらためて心より感謝いたします。ありがとうございました。