Windows,PC:パソコンWindows 10,大型更新

年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回の大型更新を、運よく(?)成功した実績があります。

RL78マイコン,MCU:マイコン,LPCマイコン,Kinetisマイコン,STM32マイコン,PSoC/PRoCマイコン,MSP432マイコン,Cortex-M0+コア,Cortex-M0コア,Cortex-M3コア,Cortex-M23コア,Cortex-M4コアIoTマイコン,プロトタイピング開発,Arduino,PSoC 4000S,FRDM-KL25Z,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ソフトウェア開発をするためのソフトウェア担当者向けツールという位置づけです。製品化にあたっては、ハードウェア担当者も安心するようにバス・スイッチの利用をお勧めします。

MCU:マイコン,Kinetisマイコン,Cortex-M0+コアテンプレート,Cortex-M0+,Arduino Uno,IoTマイコン,Kinetis L,FRDM-KL25Z,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テンプレートは、年内に発売予定です。ご期待ください。

MCU:マイコン,LPCマイコン,Kinetisマイコン,STM32マイコン,Cortex-M0+コアCortex-M0+,IoTマイコン,無線規格,5G,Wi-Fi6,Bluetooth LE 5.2

公衆網の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で対応します。

サイト関連,RL78マイコン,MCU:マイコン,LPCマイコン,Kinetisマイコン,Windows,PC:パソコン,STM32マイコン,PSoC/PRoCマイコン,お知らせ,MSP432マイコン,Cortex-M0+コアテンプレート,IoTマイコン,セキュリティ,Firefox Send,ファイル共有,Google Drive,利便性

クラウドファイル共有サービス: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を代替として弊社は選びました。

全テンプレート継続販売

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

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

MCU:マイコン,Kinetisマイコン,Cortex-M0+コア,Cortex-M4コアARMマイコン,Cortex-M0+,Kinetis L,GPIO,FRDM-KL25Z,5V耐圧,FRDM-K64F,FGPIO,BME

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:マイコン,MPU/SBC:IoT用プロセサ,Windows,PC:パソコンIoTマイコン,セキュリティ,IoT,暗号化,侵入,脆弱性,多要素承認,デジタル後進国

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セキュリティ

MCU:マイコン,LPCマイコン,Kinetisマイコン,STM32マイコン,PSoC/PRoCマイコン,MSP432マイコン,Cortex-M0+コア,Cortex-M0コア,Cortex-M3コア,Cortex-M23コア,Cortex-M4コアIoTマイコン,MCU,マイコンテンプレート,FRDM-KL25Z,5V耐圧,3.3V,5V,接続,インタフェース,CMOS

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



Linux,Windows,PC:パソコンWindows 10,大型更新,Linux Mint,MCU開発,PC OS,アップデートマネジャー,Windows Update

春と秋の年2回大型更新するWindows 10のリリース開始からサポート終了までのライフサイクルは、1.5年です。Windows 10最新バージョン2004へ更新済みの場合、2021年12月14日までは、2回目/3回目の大型更新を延期でき、この間の大型更新トラブルも回避できる可能性があります(COVID-19の影響は除いています)。

一方、Linux Mint 20の大型更新は春の年1回、ライフサイクルは5年です。

本稿は、このPC OSの大型更新を比較し、MCU開発用OSの安定性という観点から、Linux Mintが優位であることを示します(関連投稿:Linux Mintお勧め理由の続編という位置づけです)。

WindowsとLinux Mintの大型更新比較結果

Windows 10(Version 2004) Linux Mint 20(Ubuntu 20.04 LTS)
大型更新回数 年2回 年1回
ライフサイクル 1.5年(2021/12/14まで)

※この間2回の大型更新予定

5年(2025年春まで)

※この間4回の大型更新予定

大型更新方法 Windows Update(手動延期可能) ユーザによるクリーンインストール
大型更新間隔 0.5年 1年
通常更新方法 Windows Update アップデートマネジャー(5章参照)

Windows 大型更新(Windows 10)

2020年2回目の大型更新、Windows 10バージョン20H2の内容が判りました。バージョン20H2も、様々な機能追加・更新の発表があり、大型更新トラブルが少ないことを願っています。一方で、コチラの記事によると、現行バージョン2004では旧バージョンから消えた重要機能も少なくないようです。

※Windowsの機能追加・削除によるMCU開発弊害の例が、関連投稿:FRDM評価ボードOpenSDA接続問題の3章にあります。

Windows 10運用に安定性を求める場合は、1.5年のライフサイクル期間中、大型更新を「手動延期」する方法があります。但し、大型更新毎に変わるメニューやタスクバーなどのPC基本操作が、最新版で無くてもかまわない場合です。職場利用のPCなどは、この運用方法でも良いかもしれません。

個人利用のPCは、大型更新が基本です。Windows Updateは「最新版へ更新」するのがデフォルト設定ですし、巷に溢れるWindows 10情報は、どれも最新版の話題で、ユーザに大型更新バイアスをかけ続けるからです。

但し、プリンタや接続機器も多種多様な個人利用PCの場合、大型更新トラブルの発生確率は、職場利用のPCよりも高くなる傾向があります。

この大型更新トラブル確率が増すにも関らず、デフォルトでは最新版へ更新することが、Windows 10の矛盾点だと思います。

Windows Updateは、OS自身の大型更新と、通常のセキュリティ更新の2機能が混在しています。これは、Windows 10が商用であるがゆえに、より早い競合製品(Apple macOSやLinux)差別化もビジネス的には必要なためか(?)と筆者はあきらめています。

Windows Updateで無理やり大型更新も行うのではなく、ユーザ主体で大型更新が開始できる別ボタン、例えばInstall New Windowsを設ければ、少なくとも大型更新起因のトラブルは回避できると思うのですが…。

Linux Mint大型更新(Linux Mint 20)

Windows と最も異なるのは、Windows Updateに相当するLinux Mintアップデートマネジャーに、OS大型更新機能が無い点です。

Linux Mintのアップデートマネジャーは、稼働中OSの主にセキュリティ関連更新を行います(標準搭載のFirefoxブラウザなどは、このアップデートマネジャーで最新版へ更新されます)。つまり、ユーザが主体的に操作しない限りOS大型更新はできない仕様です。

旧版Mint 19からMint20への更新は、基本的にはOSクリーンインストールで行います。旧Mint 19利用中のユーザ追加アプリケーションやユーザフォルダなどを、新Mint 20へ引き継ぐバップアップツールが標準で用意されています。

また、現行Mint 20と旧Mint 19のOS自体を比較しても、差はデスクトップの色や壁紙程度で、本来のOS部分は、(詳細に見れば別ですが)大差は見当たりません。

Linux Mint 20のリリースノートを読み、大型更新の必要性をユーザが感じなければ、そのままLinux Mint 19を使い続けても最長5年間はセキュリティ更新が受けられます。

MCU開発用PC OS安定性評価

MCU開発用のPC OS として、以下の2点からLinux Mintが優れると評価します。

  • Linux Mint大型更新間隔は、Windows 10の0.5年に比べ1年と長い
  • Linux Mint大型更新は、ユーザが主体的に開始する

MCU開発速度が上がり、MCUソフトウェア/ハードウェア生産性が向上しても、プロジェクト開始から終了まで数か月~1年は要するでしょう。EclipseベースIDEなどのMCU開発ツールも、この間に1回程度は更新がありえます。

これらMCU開発ツールの動作土台となるPCのOSは、少なくてもプロジェクト実行中の1年程度は安定的に、かつ大型更新する場合でもユーザ主体で開始してほしいと願う開発者は、筆者だけではないと思います。

アップデートマネジャーの使い方(Linux Mint 20)

Linux Mintアップデートマネジャーの使い方
Linux Mintアップデートマネジャーの使い方

Linux Mint 20起動時、①アップデートマネジャーを起動しても、「このシステムは最新の状態です」と表示されることがあります。この時は、念のため、②再読込をクリックします。

すると、更新情報を再チェックし、何らかの更新がある場合には、リスト表示されますので、③アップデートインストールをクリックします。

インストール中に「以下のパッケージがインストールされます」と表示される場合は、デフォルトのまま④OKをクリックします。

①~④によりLinux Mint 20へ最新アップデートが適用されます。

※これらの操作はWindows Update「更新プログラムのチェックボタン」を、ユーザ自身で押すことに相当します。

また、ファイアウォールのデフォルトは無効です。「起動する」をクリックし、自宅/会社/パブリック選択後、Statusを変更、有効に変更することをお勧めします。

MCU:マイコン,STM32マイコン,Cortex-M0+コア,Cortex-M0コア,Cortex-M3コア,Cortex-M4コアIoTマイコン,STM32CubeMX,stm32,STM32CubeIDE,マンスリー・アップデート,HTML

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