モダンPCとPINコード

2019年12月27日2020年1月16日 WithHappy

本稿が2019年最後の投稿です。

前稿Windows 10 2PCトラブルにもめげず、2020年1月6日発売のCypress PSoC CapSenseテンプレートに向けて急ピッチで開発を進めてます。本稿は、Windows 10トラブルで気になったモダンPCと、公開鍵暗号方式PINコードを紹介します。

モダンPC

創造性と生産性を上げるのがモダンPCで、Windows 10とOffice 365がその要素のようです。

Windows 7サポート終了2020年1月14日を前に、MicrosoftはモダンPCへの移行を呼びかけています（Windows 7稼働予測グラフ有り）。今でもネットカフェで稼働中の多くのWindows 7 PCは、果たして安定性・メンテナンス性に問題あるモダンPCへ移行するのでしょうか？

Windows 7並みの信頼性が無ければ、宣伝文句は良くてもPCのOSとしては、どうかな？と個人的には思います。
2023年までのWindows 7有償再延長サポートも選択肢としてあるので、7を使い続け、開発者よりも一般エンドユーザを重視する次期Windows Xに期待する声も少なくないかもしれません。

筆者は最新OSの最重要機能は、セキュリティだと思います。

Windows 10付属セキュリティツールだけで安心しているエンドユーザが、どれ程いるかは解りません。しかし、多くのネットカフェが設定するWindows 7＋市販セキュリティソフトとのOSセキュリティ能力差が、どれ程あるかも不明です。

2020年以降のWindows 7稼働予測と、モダンPCへの移行状況が、Microsoftの思惑通りになるか気になります。

PINコード

Windows 10インストールで新たに要求されるPIN（Personal Identification Number）コードは、個人識別番号のことです。普通、数字4桁です。

PINコードは、IDとパスワードの代わりに登場してきたセキュリティ用語で、筆者の理解では、PINコードが公開鍵暗号方式、パスワードは秘密鍵暗号方式です。PINコードとパスワードの解り易い違いは、コチラのP1図です。

通信中の鍵が公開鍵なので、秘密鍵パスワードよりも安全で、公開鍵とペアの秘密鍵は、デバイス（Windows 10/MCUなど）内部保存、開発コストや運用コストが低く、強固なセキュリティが実現できるそうです。ペア秘密鍵がデバイス内なので、なりすまし対策にもなります。

PIN、FIDO（ファイドと読む）で検索すると様々な情報が得られます。iPhoneは少し違うようですが、AndroidスマホではPINコードが標準になりつつあるようです。

筆者のWindows 10は、前投稿トラブル回復直後のため、テンプレート開発以外は、今のところあまり手出し（調査）したくない心境です。簡単、安心、低コスト、セキュリティ強固なPINコードなら、MCUへも実装できるかもしれません。

…以上のように今年最後の本稿は、あいまいな推量となりました。
安心してPCが使えるまでは、最高プライオリティ：CapSenseテンプレート開発を優先したいからです。すいません😌。

本年も本ブログをご覧いただき、まことにありがとうございました。
皆さま、よいお年をお迎えください（Ladies and gentlemen, I wish you a happy New Year）。

Windows 10 1909トラブル回復録

2019年12月20日2019年12月27日 WithHappy

年末年始の忙しい時に限って自作Windows PCにトラブルが発生するのは、日頃の行い、またはマーフィーの法則？

Backup PC（Windows 10 1903）のWindows 10 1909アップデートトラブルに続き、Main PC（Windows 10 1909）にもWindows起動トラブルが発生しました。Backup PCトラブルは、暫く様子見でも良いと考えていましたが、Main PC起動トラブルは、即回復が必要です。

Windows 10トラブル内容

Backup PCは、Windows 10 1903から1909への更新プログラムインストールに失敗するトラブルです（0x800F0922）。1903からの新機能追加も少ない1909への更新は、Backup PCのため急ぐ必要はありません。この更新失敗トラブルは少なくないようで、ネットに多くのトラブル対策があります。更新プログラム直接インストール、クリーンブードも既に試しましたが回復しません。

Main PCは、突然起動NGになりました。きっかけは、複数アプリケーション更新と更新履歴消去です。Boot起因ですので、自動修復やコマンドプロンプト手動修復も試しましたが回復しません。唯一の救いは、1909更新成功直後のシステムバックアップがあることです。

トラブル回復策

Main PCは、11月14日の1909更新直後のシステムリカバリで回復しました。但し、今回の起動トラブル発生までの約1か月間のユーザデータ更新とアプリケーションソフト更新が必要で、このために半日がつぶれます。また、Backup PCは、その症状から「最後の切り札」：1909クリーンインストールが必要かな？と感じていました。

そこで、Main PCでつぶれる半日で並列にBackup PCをクリーンインストールしようと決心した訳です。Main PCのアプリケーション更新時、Backup PCへのインストール必須アプリケーションも明確になります。退屈な回復作業ですが、PCの前から離れる訳にもいきません。2PC同時に回復することで、効率向上も狙えるかなと考えました。

トラブル回復作業と時間

ネットに溢れる回復作業内容よりも、作業に要した時間を示します。

もちろんPC性能やネットワーク環境で分単位精度は変わるでしょう。半年毎に繰返されるWindows 10更新トラブル対応の目安と考えてください。作業時間は、2PC回復トータルで丸1日程度です。が、精神的ダメージはかなりあります。Windows10更新トラブルがこのまま続くなら、Mac PCへの乗換を検討する程のダメージです。

Backup PC Windows 10 1909クリーンインストール作業時間

Windows 1909クリーンインストール：10分（Microsoftアカウントに加え、新たにPINコード入力要求）
クリーンインストール後のセットアップ：5分（OSセキュリティ内容などを設定）
セットアップ後の更新プログラム適用：40分

最新Windows 10 1909クリーンインストール自体は、上記1時間程で完了します。これなら、毎回クリーンインストールしても良いと思える程簡単です。が、この後のアプリケーションインストール、ユーザデータ復活に時間が掛かります。

セキュリティソフト、ブラウザ、FFFTP、圧縮解凍などOS必須ツールインストール：1時間
Officeアプリケーションインストールと更新プログラム適用：3時間
ベンダMCU開発ツールインストール：1時間
ユーザデータ復活：1時間（クラウドストレージ経由ではなく回復Main PCより直接コピー）

合計で7時間～8時間（＝丸一日）は、モニタ前で待たされます。並列で行ったMain PC回復作業も、システムリカバリと1か月間のユーザデータ復活で3時間程度です。Office（2010）アプリケーションインストールと更新は、LibreOfficeに比べ時間が掛かります。新しいOffice 2019/2016でも、同様に時間が掛かると思います。

※アプリケーションとユーザデータを引継いだままWindows 10 1909上書きインストールも可能です。しかし、Backup PCは、この上書きインストール（1.5時間）も失敗しました。更新プログラム直接インストール、クリーンブードと同様、「最後の切り札」より前の回復手段は、経験上あてになりません😫。

いろいろある回復手段を試して消費する合計時間と、「最後の切り札」で一発回復する上記8時間のどちらを選ぶかは、トラブル種類と回復作業内容・処理時間、個人の性格に依存します。本稿が参考になれば幸いです。

ビジネスPC要件

今回のトラブルで、筆者のWindows PCには、Mac PCへの乗換を妨げる利用アプリケーションは無いことが明確になりました。利用アプリケーション全てMac OS対応、または同等アプリケーションが有ります。

ビスネスPCのOSは？ — 信頼性重視ビスネスPCのOSはWindows、Mac、Unixのどれが良いか？

Mac PCの方が高性能なのでWindows PCより高価です。従って、このMac PC対Windows PC差額を払う分だけの信頼性が得られるか、費用対効果が乗換課題です（もちろん、経済的余裕と自作PCの楽しさが消えるのもありますが…）。

Backup PC、Main PCともに自作Windows PCですが、今回のようなOS起因トラブル無しで何年も動作し続けたPCです。ネットを見ると、Backup PCと同じ更新トラブルは、2019年最新WindowsノートPCでも発生しているようです。

以前のOS、特にWindows 7に比べ世間を騒がせるWindows 10更新トラブルは、Windows 10完成度・信頼性が低いとエンドユーザに感じさせるだけでなく、Microsoftの狙いは、OS更新毎に毎回Windowsをクリーンインストールさせ、アプリケーション本体は、Office 365のようにクラウド提供することが目的なのでは、という疑いを生じさせます。
OSクリーンインストールが短時間で簡単に終わり、OfficeアプリケーションのローカルPCインストールと更新にやたら時間が掛かることが根拠です。

ビジネスで使うPCは、Mac PC（Unixも含む）への乗換を考えるべき時期かもしれません。今後、Mac PC/OSのトラブルや回復方法も調べたいです。

LibreOffice最新版6.2.5へ更新

2019年7月9日2019年7月12日 WithHappy

LibreOffice版数（2019年7月9日現在）
パッケージ	想定ユーザ	2019/7/4版数
最新版（stable）	技術マニア、新しいもの好き、パワーユーザ向け	6.2.4 → 6.2.5
安定版（stable）	ビジネス組織、法人企業、慎重なユーザ向け	6.1.6（変更なし）

2019年7月4日、パワーユーザ向け新機能を盛り込んだLibreOffice最新版が、6.2.5へマイナー更新されました。安定版は、6.1.6のままです。マイナー更新方法や無料テンプレートなどは、リンク先投稿を参照してください。

マイナー更新間隔とメジャー更新予測

マイナー更新実績、下線はメジャー更新予測
パッケージ	更新月日（版数）
最新版	2019/04/19 (6.2.3) → 2019/05/22 (6.2.4) → 2019/07/04 (6.2.5) → 2019/08 (6.3)?
安定版	2019/02/07 (6.1.5) → 2019/05/09 (6.1.6) → 2019/08 (6.2)?

現在LibreOffice提供中のダウンロード版数は、6.2.5と6.2.4、それと6.1.6です（全て日本語版）。安定版は6.1系のまま、最新版は6.2系で更新中です。

最新版の更新間隔は、おおよそ1か月、安定版は3か月です。最新版は、次回6.3系へのメジャー更新が8月に予定されており、このタイミングで安定版も6.2系へメジャー更新すると思います。

LibreOffice 6.1系と6.2系の差は、こちらの投稿のノートブックバー章を参照してください。

LibreOffice 6.2系の個人評価

筆者は、今年2月からノートブックバーが採用されたLibreOffice最新版6.2系を代々使い続けています。バグにも遭遇せず便利にDraw/WriterをWindows 10 1903で使用中です。

6.3系でどのような機能が追加されるかは分りませんが、個人的にはMicrosoft Office代替としてLibreOfficeはお勧めです。

LibreOffice6.2系とMicrosoft Office 2019/365との機能比較は、こちらの投稿の比較表を参照してください。

ユーザ目線Windows 10 1903更新方法

2019年6月3日2019年6月7日 WithHappy

Windows 10サポート期限は、年2回の大型更新後、1年と半年です。つまり、1809なら2019年末まで。2020年1月14日のWindows 7に比べ超短期です。Windows 10ユーザは、大型更新1903 May Update（19H1）への対応は必須なのです。

前回の1809更新トラブルをまぬかれた筆者を含むラッキーなWin10ユーザが、今回の1903更新をどのように乗り切るかについて私案を示します。

3つの1903更新方法

Microsoftは、前回1809更新一斉配布→トラブル頻発の反省から、今回1903は、段階的配布に変えたそうです。それでも、前回同様、1903も重大な更新トラブルの記事、情報が多くあります。

関連投稿：LibreOffice最新版6.2.4更新のWindows 10 May Update章

この段階的配布により、いつ始まるか判らない自分のPCの1903更新への対応法は、3つあります。

主体的に1903更新開始：例えば開発が一段落したなどユーザの都合が良い時に、ユーザ自身で1903更新を開始
受動的に1903更新受付：1903更新開始は、PCにお任せ、ユーザもそれに従う。多くの記事で推薦。
受動的に1903更新受付、更新延長の場合あり：1903更新の開始は、PCにお任せ。但し、ユーザの都合が悪い場合は、一時的に1903更新を延長

1：主体的に1903更新開始

1903段階的配布の目的は、徐々に明らかになる更新トラブルに対する策を、Microsoftが通常のUpdateで大型更新前に実施し、トラブル発生頻度を少なくすることです。多くの記事が、1903更新をひたすら待てというのは、Microsoftのこの意図を汲んだ結果です。

従って、主体的に1903更新の開始をする時は、更新トラブルの覚悟が必要です。方法は、「何回か更新プログラムのチェック」を押すことです。これにより主体的更新をMicrosoftが検知し更新が始まります。

ユーザメリットは、当然事前にシステムバックアップをしており、万一のトラブルが発生しても自己責任なので精神的に安定して回復できることです。トラブル発生時には回復し、2または3の選択肢となります。

2：受動的に1903更新受付

朗報です。1903からは、Homeユーザでも最大35日の大型更新延長が可能になったそうです。この機能は、次の大型更新後にその効果が明らかになるでしょう。

しかし、現行の1809 Windows Homeユーザには、大型更新延長機能がありません。例えユーザ都合が悪くても、開始した1903更新を受入れる以外に手はありません。

段階的配布で自分のPCの順番が来るのを待ち、トラブルが無い1903更新完了を祈りましょう。

3：受動的に1903更新受付、更新延長の場合あり

1809 Windows Pro以上のユーザが取りえる現在最も大型更新のトラブルリクスが少ない可能性がある方法です。

大型更新を延長する方法は、「更新開始前」に、Windows Updateの下記詳細オプションを設定します。

大型更新の延長設定（1809 ProのWindows Update詳細オプションデフォルト状態）

赤枠、これは更新インストールの制御であって、更新プログラムはPCへダウンロードされます。一方、橙枠の一時停止は、更新プログラムも再度ダウンロードする必要があります。どちらも、自分のPCに段階的配布順番が回ってきたのは同じですが、橙枠は、再び更新プログラムの配布を待たねばなりません。

いずれも、PCの通知アイコンや、いつもと違う大型更新プログラムダウンロード中の挙動にユーザが気づく必要があります。忙しくてこの挙動に気が付かずにいると、何らかのトラブルが発生する可能性もあります。

その理由は、上記更新延長機能を確かめた記事、情報が見当たらないからです。これらユーザに嬉しい機能はあっても、本当に機能するかは確かめようがありません。

1903大型更新リスクとまとめ

対応案	更新トラブル発生確率	トラブル時のユーザ精神安定度
1. 主体的に1903更新開始	＋＋＋	＋＋＋
2. 受動的に1903更新受付	＋	＋
3. 受動的に1903更新受付＋延長	＋＋	＋＋

色々な記事、情報が言うように、受動的に1903更新開始を待つのが大型更新トラブル回避としては、得策なようです。次回、秋の大型更新よりも前までに1903更新完了を待てる方は、リスクが少ない2の対応が良いでしょう。

ちなみに、1903更新でユーザが得られる新機能として筆者が良いなと思うのは、マウスポインタの大きさが大きくなるくらいですが…。

但し、ベンダ純正PCであっても事前にあらゆる組合せに対するトラブル回避策を施すことは不可能です。例えば、自作組込みPCや後付けパーツを組み込んだ純正PCなどに対しては、2や3の対応でもトラブル発生の可能性は、1と大差なしと言えるかもしれません。

更新開始を待ったのに運悪く2や3の対策でも更新トラブルになった時、回復できるバックアップがどの時点のものかが重要です。最悪イニシャルに回復するしかない場合、インストールしたアプリケーションやそれまでのユーザデータは無になります。時間的、精神的にも、かなりの負担です。

更新開始タイミングが主体的な1の対応のみが、最悪イニシャルを避ける策でしょう。

結局、頻繁なシステムとユーザデータバックアップのみが、大型更新トラブル回避策だと筆者は思います。更新開始を主体的にするか、受動的にするのかは、トラブル発生時の精神的な影響に差を生むのみだと思います。

1903 May Updateをどのように乗り切るかについて私案を示しました。筆者自身、どの策にするか未定ですが、ご参考になれば幸いです。

LibreOffice更新

2018年11月10日2018年12月1日 WithHappy

2020年10月サポート終了のOffice 2010代替アプリケーションとして評価中のLibreOffice。このLibreOfficeは、十分に使えると結論しました。本稿は、LibreOfficeの更新を示します。

関連投稿：カテゴリー：LibreOffice参照

LibreOffice更新

LibreOfficeの更新は、MicrosoftのOfficeやWindowsの更新方法とは異なります。

2018年11月5日のLibreOfficeマイナー更新で、セキュリティ更新や不具合修正後の版数が下表です。

LibreOffice版数（2018/11/10現在）
パッケージ	想定ユーザ	2018/11/5版数
最新版（stable）	技術マニア、新しいもの好き、パワーユーザ	6.1.3.2
安定版（stable）	ビジネス組織、法人企業、慎重なユーザ	6.0.7

最新版とは、文字通り最新機能を盛り込んだstable＝安定リリース版、安定版は、機能更新を最小限にし、より安定志向のstable＝安定リリース版です。どちらも64ビット版（x64）と32ビット版（x86）がありますので、合計4種類のパッケージがコチラから無償ダウンロードできます。

全てstableであり、WindowsのFast/Slowリングのように不具合を含む可能性があるリリース版ではないので安心です。

メジャー/マイナー更新

注意が必要なのは、既にLibreOfficeをインストール済みでも、ヘルプ（H）＞更新のチェック（C）でチェックされるのが、メジャー更新時だけという点です。11月5日更新は、マイナー更新ですので、更新チェックしても下記のように「LibreOfficeは最新版です」と表示されるだけです。

マイナー更新を確認するには、ヘルプ（H）＞LibreOfficeについて（A）で表示されるダイアログでウェブブサイト（W）をクリックし、LibreOfficeサイトでのバージョン版数の目視確認が必要です。

このマイナー更新の確認→手動更新が手間と感じるか、または、OfficeやWindowsのように勝手に自動更新される方が良いと感じるかは、意見の分かれるところです。

LibreOfficeや本ブログ読者がMCU開発で使う統合開発環境（IDE）の更新方法は、更新の確認後、その更新をインストールするか否かは、ユーザ自身が決定します。一方、OfficeやWindowsの更新方法は、更新インストールが自動です。

万一、自動でインストールした更新版に不具合がある場合には、更新前の貴重な既存開発データが壊れる可能性があります。IDE更新を自動にしない理由は、この重大リスクを避けるためです。
※Windows 10 1809では、Documentsデータが壊れる不具合が発生し、更新一時停止の経緯があるのは周知の事実です。

不具合更新＞セキュリティ更新＞機能更新

重要度に応じた更新方法が必要です。

重要度が高いセキュリティや不具合の更新は、ユーザへの更新通知と「自動更新インストールでも良い」と思います。しかし、重要度が低い機能更新や新機能追加は、「ユーザ自身が更新可否を判断」すべきです。

重要度判定が困難な場合やユーザに依存する場合には、安全側対策としてLibreOfficeやMCU IDEのように「ユーザの主体性に任せる方が良い」と私は思います。

Office、Windows 10 1809更新

コチラの記事によると、Officeのリボンが、Windows 10 1809更新に伴って、機能は変わらずに見た目が変わったそうです。
※弊社Office 2010リボンは変化なしなので、2010以降のOfficeのことだと思います。

Windows 10 1809に伴って変更されたOfficeリボン（出典：記事）

見た目の変更で生産性がどれ程上がるかは不明ですが、ユーザへの告知不足では、混乱のみが生じるでしょう。OfficeやWindows 10 1809は、機能的に過飽和状態なので見た目を変えたがる傾向にあります。

例えば、1809新機能のスマホ同期は、同様の無償アプリケーションが既にあり、わざわざ新機能を使わなくても十分です。WSL（Windows Subsystem for Linux）のように機能有効/無効のスイッチがあれば、それでも良いのですが、スイッチが無い場合には、新機能追加はトラブルの原因です。

Windows 10 1809のDocumentsデータ消失の発生率は、0.01％だそうです。もし、セキュリティ更新と新機能追加を分離して配布していたら、今秋から今も続く1809トラブルは発生したのでしょうか？

技術者、開発者、研究者の更新

最後に、アップデート：更新繋がりで、興味深い記事を見つけたので紹介します。我々も、自ら更新が必要かもしれません。

Windows 10更新中断、μT-Kernal、IoTマイコン

2018年10月9日2018年10月15日 WithHappy

Windows 10 1809更新によりユーザファイルが消失するトラブルが発生しています。このためMicrosoftは、Windows 10 1809への更新を一時中断しました。

Windows 10更新でマイドキュメントフォルダ消失！

消失フォルダは、よりによってC:\User\[user name]\Documentsだそうです。マイコンIDEのプロジェクトファイルをマイドキュメントフォルダへ設定している方（私がそうです）は、1809更新を待った方が良いかもしれません。

幸い私の3台のPCは、全て問題なく1809更新に成功し、Documentsフォルダも無事でした。

よく言われる最悪を避けるには、個人データのバックアップです。しかし、Windows機能更新時に、最も守るべきユーザデータを壊す/消すという不具合は、OSとしては許されません。Fast/Slow リングで検証できなかったのでしょうか？

μT-Kernal

OSと言えば、マイコン向けのリアルタイムOS：μT-Kernalの解説がトランジスタ技術2018年10月号の組込みOS入門という別冊にあり、第2章～第6章にリアルタイムOS（RTOS）の説明があります。

また、トロンフォーラムへの登録が必要ですがルネサスRL78/G14向けにポーティングしたμT-Kernalを無料でダウンロードできます。

※μT-Kernalは、ITRONベースに2003年公開の32ビットマイコン向けオープン・ソースRTOS。

本ブログではこれまでRTOSとしてFreeRTOSを紹介してきました。μT-Kernalと比較するとより理解が進むと思います。

IoTマイコンとRTOS

IoTマイコンにRTOSを使うと、今回のWindows 10のようなトラブルを招く可能性が生じます。ただIoT通信手段が何になるにせよ、高度なセキュリティや公共リソース利用のための通信処理をマイコンで行うには、RTOSが必要になると思います。

この状況ならいっそのことIoTマイコンには、Cortex-M4（または同等クラス）とCortex－M0/M0+マルチコアを導入し、Cortex-M4でIoT関連処理、Cortex－M0/M0+で従来のMCU処理に2分割、さらにIoT関連処理はMCUベンダーが全て無償提供してくれればIoT MCUの爆発的普及が進むと思います。

つまり、Cortex-M4のIoT関連処理がWindows 10に相当する訳です。これならIoT通信手段やセキュリティが変わってもCortex-M4部分のソフトウェアをOTA（Over The Air）で変えれば対応できます。我々開発者は、本来のマイコン処理に集中できます。
理想的な空想ですがね…。

関連投稿：OTAについてIoT端末の脆弱性対応はOTA：Over The Air更新が必須の章参照

Windows 10 1809更新とマイコンIDE

2018年10月4日2018年10月9日 WithHappy

Windows 10のRed Stone最後の大型更新RS5 、Windows 10バージョン1809配布が始まりました。

1809更新2方法

Windows Updateで更新

Windows Update更新プログラムのチェックで1809への更新が開始されます。
但し、これは運が良ければの話で、PCの更新準備が整っていても「最新の状態です」が表示され更新を待たされる場合があります。

手動で更新

Windows 10 October 2018 Updateの今すぐアップデートをクリックし、アップデートツールをダウンロードすると、手動で1809更新開始ができます。

1809更新時間と操作

どちらの方法でも、1809プログラムのダウンロードとインストールに1時間、その後、再起動して新しいWindows 10 1809の自動設定に1時間、合計約2時間程度かかります（PCや通信リンク速度によって異なりますので目安です）。

ダウンロードとインストール中は、通常のPC操作やソフトウェア開発は可能です。再起動は、自動的に始まります。
つまり、何らかの操作を行っている場合は、再起動前に終了しなければなりません。

新Windows 10自動設定中は、PC操作はできませんし、操作不要で設定完了します。
つまり、再起動したら1時間は待つしかありません。

Windows 10 1809の各社マイコンIDE動作

ブログ掲載中マイコンIDE（ルネサス：CS+、NXP：LPCXpresso、Cypress：PSoC Creator、STM：SW4STM32）は、私のWindows 10 1809では正常に動作しました。

MCU開発環境トラブル顛末（1803クリーンインストール後）

2018年7月31日2018年10月16日 WithHappy

MCU開発環境のWindows 10 Pro Version 1803クリーンインストールに至った経緯を前稿で示しました。今回は、クリーンインストール後に改善された点、変わらなかった点、新しく気が付いた点などを記載します。

クリーンインストールで改善された点

クリーンインストール前は、110GB程度の使用量であったCシステムドライブが、同じアプリをインストールした後でも80GB程度で済みました。
この30GBの差がどうして生じたのかは、解りません。OSやアプリを使っているうちに溜まるゴミがあるとしても、30GBは大きすぎます。

差分の原因は不明ですが、意を決してクリーンインストールしたお陰（ほうび）として考えています。

クリーンインストール前後で変わらなかった点

OneDrive同期のOffice 2010サムネイル表示は、Excelのみ非表示が続いています。

もしかしたらOffice 2013以降であれば、正常にサムネイル表示されるのでは？と考えています。Office 2010延長サポートは2020年10月13日、つまりあと2年で終了します。Microsoftとしては、なるべく上位バージョンへの移行をユーザへ進めたいでしょうからその施策の1つではとの（うがった）考えからです。

私は、Office 2010の代替として、無償LibreOfficeを試用検討中です。

LibreOffice文書サムネイルは、OneDriveフォルダ内でも問題なく表示されます。

Office Word文書右とLibreOffice Writer文書左のサムネイル比較 — Office Word文書（左）とLibreOffice Writer文書（右）のサムネイル比較

また、使用頻度が高いOffice Visio2010代替にDrawを使えるのもLibreOfficeのメリットです。さらに、Office文書はLibreOfficeでも編集できます。検討途中ですが今のことろLibreOfficeバージョン:6.0.5.2 (x64)に不満はありません。

クリーンインストールで新しく気が付いた点

起動不能の主因は、前投稿の前兆トラブル4「月1弱の起動失敗」であったと考えています。

しかし、この起動失敗時メッセージがBIOS関連であったため、現在のUEFI全盛環境では、たまには起こる事象だろうと安易に考えていました。また、BIOSからUEFIへいつか変更したいとも正直考えていましたので、きっかけ（トリガ）を待っていたとも言えます。

但し、BIOSからUEFIへの変更に対して、以前から使っていたTodoBackup Freeシステムバックアップでは対応できなかった可能性に気が付きました。TodoBackupは、Windows標準のバックアップソフトやシステムの復元機能よりも、個人的には信頼性が高いと評価しています。しかし、BIOSからUEFI変更時は注意が必要です。

TodoBackupで実行するタスクは、代々Cドライブ単独のシステムバックアップを行っていました。最新TodoBackup V11は、このシステムバックアップと、SSDやHDD丸ごとディスク単位のバックアップが別々のタスクで用意されています。

起動不能時に表示されたBCD関連のリカバリには、Cドライブ単独のシステムバックアップだけでは元々不可能だったのです。従って、今後はディスク単位バックアップを実行し、同様の起動不能に備えます。

また、初めてOneDriveを使うユーザには問題ない設定ダイアログが、既にOneDriveを利用中で今回のようなクリーンインストール後、再度ローカルPCと同期させる場合には注意が必要です。

サムネイル非表示問題のためにGoogle Drive同期へと1709で変更したOneDrive。クリーンインストールを機に、より使い勝手が良いOneDrive同期へ戻したところ、再同期ダイアログに設定ミスが生じやすいこと、ネット速度が遅い場合は、同期するファイルが多いだけに同期完了までに時間がかかることを実感しました。

OneDrive「再」同期の手順のまとめ

既にネットワークのOneDrive保存済みのPC同期ファイルと非同期ファイルがある場合、これらとクリーンインストールしたPCのファイルを同期させる時に、手順を間違うとPC内に全く同じファイルが同時存在したり、誤ってネットワーク内のOneDriveファイルを削除する場合があります。

これを回避するには、OneDriveを最初に起動した時に表示される「フォルダの選択」ダイアログで「非同期ファイルの☑を外す」必要があります。

デフォルトは、ネットワーク内の全OneDriveファイルをローカルPCへ同期する設定になっています。安易にデフォルトのままOKをクリックすると、全OneDriveファイルのダウンロードが始まります。

このOneDriveファイルは、ローカルPCのOneDriveフォルダに保存されますので、暫くすると、ローカルPCのOneDriveフォルダが、多くのネットワーク保存ファイルで溢れた状態になります。

そもそもOneDriveは、アーカイブスや普段あまりローカルで使わないファイル、また、これらに加えデスクトップ、マイドキュメント、ピクチャなど他PCとネットワーク共有すると役立つフォルダを保存する場所です。

デフォルトのままでは、全OneDriveファイルがローカルPCのOneDriveフォルダに保存されます。この状態で、アーカイブスや不要ファイルを削除すると、同時にOneDrive側も削除されてしまいます。幸い、OneDriveにもごみ箱があり、間違って削除しても復活させることができますが、手間です。

つまり、ネットワークOneDriveとローカルPCのOneDriveの制御を切り離すのが、最初に設定する「フォルダの選択」なのです。OneDriveも改版される度に設定ダイアログも変更され、従来から利用中のユーザには解りにくいことがあるので注意が必要です。

さらに、自動保存で設定できるドキュメント、ピクチャの保存先をOneDriveへ変更する場合には、事前に変更するローカルPCフォルダの場所を、OneDrive内へ移動しておくことも必要です。

私の場合は、マイドキュメントは依然として続くOfficeサムネイル非表示問題でOneDrive同期を使いません。従って、ピクチャフォルダのみをOneDriveへ移動しました。デスクトップは自動保存先の設定のみで同期します。

このように、設定順序や自動保存フォルダにより設定が異なることが現状OneDrive利用時の問題点であり注意点です。完成度は低いと言えるでしょうが、年2回の大幅更新で今後改善されるかもしれません。
※MCU開発と一番の違いは、このリリース完成度だと思います。

Windowsクリーンインストールや、OneDrive同期の方法を記載したサイトは数多くあります。
しかし、これらは新規クリーンインストールや初めてOneDriveを利用するユーザ向けなので、既存PCにトラブルが発生し、やむを得ずクリーンインストールする場合や、既存OneDriveユーザが再設定する場合とは異なる場合もあることに注意しましょう。

さらに付け加えると、Windowsクリーンインストール自体は、気を付けるのはライセンス再認証ぐらいで、アプリのカスタマイズ復活に比べ、手間も時間も数時間で済みます。
OSやユーザアプリインストール、各種カスタマイズ量が少ないなら、（クリーンインストールで半日から数日は完全に潰れますが）気軽にクリーンインストールしてもよい気もしました。

Windowsやアプリのカスタマイズ復活が未だ完全ではありませんが、MCU開発環境メインPCは復活しました。

MCU開発環境トラブル顛末

2018年7月21日 WithHappy

突然起動不能に陥った自作メインWindows 10 PC。MCU開発環境は、このPC上に構築されており、メインPCとバックアップPCとのデータ同期も完全では無かったため、実行中であったMCU開発も完全に停止、開発途中部分もすっかり消えてしまいました。

本稿は、トラブルの前兆からWindows 10 クリーンインストールまでの顛末を示し、個人的には同様のトラブルへの備え、また、MCU開発者の方々には、休憩時の笑いネタになればと思い掲載します。

Windows 7から代々更新のWindows 10 Proと前兆トラブル

メイン開発環境に使ってきたWindows 10 Pro 64ビットは、Windows 7→Windows 8→Windows10と無料アップグレードを繰返し乗り切ってきた強者です。この間、マザーボードやHDDからSSDへのストレージ変更などの自作PCのハードウェアも更新し、2017年秋の1709前までは安定して動作しておりました。

マザーボードは、UEFI仕様ですが、Windows 7時代の旧ボード設定をそのまま引継いだため、レガシーBIOSモードで起動させていました。

1709更新後、以下のような細かいトラブルが発生していました。

OneDrive同期しているマイドキュメントのOffice2010サムネイルが表示されない。
エクスプローラー表示（Ctrl+Shift+2）時に、大きい縮小版と小さい縮小版が混在する。
バックアップのノートPC：Windows 10 Homeが、ホームグループ参加に失敗する時がある。
月1回弱、起動に失敗するが、PCリセットボタン押下げで正常に起動する。

1と2のトラブルは、加齢のため文字よりも図形表示を好むようになり、サムネイル表示やフォルダアイコンも、内容が即解るものを多用するようになった結果で、これらトラブルはPC利用上とても気になっていました。しかし、これらのトラブル対策はネット上には見当たりませんでした。

サムネイル表示やフォルダアイコンの例 — 大小縮小版が混在表示されるサムネイルの例（左）。内容が一目で解るフォルダアイコン例（右）。

3は、メインPCとバックアップPCのデータ同期の妨げになり憂慮していましたが、1803でホームグループ廃止となるので、1803更新後に対策をとる予定でした。また、4の原因は不明でしたが、リセットボタンで解決するし、頻度も低いので、様子見をしていました。

Version 1803更新後の対策と効果

ホームグループ機能が消えた1803では、簡単接続のホームグループよりも面倒なものの、ネットワークと共有センターの設定を見直し、メインPCとバックアップPCの接続トラブルは解決しました。

また、マイドキュメントのサムネイル非表示は、OneDrive同期からGoogleのバックアップと同期に変更し解決しました。PC起動失敗も1803更新後は、一度も発生せず安心しておりました。つまり、1803更新以降は、2のトラブル以外は解決し、安定動作をしていました。

突然の起動不能とWindows 10クリーンインストール

メインPCのモニタに突然BCD関連のエラーメッセージが表示され、PCリセットボタン押下げ後も起動しなくなったのは、7月9日です。対策に、Windows 10の自動修復やスタートアップ修復、コマンドプロンプトでbootrecコマンドなど考え付く対策を何度か実行しましたが、残念ながら起動不能となりました。

起動不能直前のバックアップを取っていたので、SSDの寿命ではと思い新SSD調達後、新SSDへリカバリしましたが、旧SSDと同じく全く起動しません。旧SSDをCrystalDiskInfoで調べたところ、ハードウェアには問題なしでした（調達前にチェックすべきでした、この間に費やした時間：1W）。

この時点でメインPCのリカバリを諦め、1803クリーンインストールで回復させる方法に心を切り替えました。ついでにマザーボードをレガシーBIOSから、UEFI起動へ遅ればせながら変更を決意しました。

さて、Windows 7以来久しぶりのクリーンインストール。ネット上に様々な情報がありますが、14インチノートPCの16対9横長モニタで検索し情報を読むのは、24インチ3対2のメインPCに比べ劣ることを実感しました（小さく細かいモニタ文字は読みにくい、やはりモニタは大きい方が良いです）。

読みにくさを我慢して見つけた情報を基に1803のクリーンインストールをしましたが、これがMicrosoftアカウントを使ってのインストールでした。
Microsoftアカウントインストールの場合、面倒なPIN入力やユーザフォルダ名の勝手な設定、自動起動するOneDriveに悩まされます。Windows 7時代は、ローカルアカウントインストールが主流だったことをこの時思い出しました（この失敗に気が付くまで：0.5W）。

そこで、再度ローカルアカウントでの1803クリーンインストールを行い、とりあえずWindowsとOffice2010、ブラウザ、セキュリティソフト、バックアップソフト（Todo Backup Free）、同期ソフト（FreeFileSync）のインストールを完了した時点で、クリーンインストール直後の初期バックアップを取りました。また、リカバリをテストし、動作確認しました（再インスト：0.5W）。

勿論、UEFIで正常に起動します。Windowsライセンス認証も問題ありません。

MCUアプリインストール前にカスタマイズ復元するが…

私は、WindowsやOfficeはカスタマイズして使います。クリーンインストール直後の状態は、使いづらいのです。そこで、バックアップのノートPCを参考にしながらカスタマイズも復元しつつあります。

メールアドレスに紐づけされているChromeやFirefoxブラウザのカスタマイズは、簡単に復元できますが、Microsoft製品のカスタマイズ復元は手動で行うので面倒です（多分Apple iOSなら簡単にできるのかも？）。

Microsoft もSaaSやPaaSをうたうなら、個人情報収集よりも先ず提供ソフトの設定などをクラウド保存し、ブラウザ同様Microsoft アカウントでローカルPCに復元してほしいと思います。

個人レベルでの各種セキュリティ対策を行うのも困難になりつつあり昨今、MCUに限らず全ての開発のベースとなるWindowsと、出来ればOfficeアプリは、クラウド側で安全にサービスを提供してほしいと思うのは私だけでしょうか？

現在クラウドで提供されているWord/Excel/PowerPointサービスは、低機能すぎて、使いものになりません。Office365なら機能十分で、カスタマイズ復活なども可能なのでしょうか？

※Windows 10 IoT Core Servicesは、この要望に近いOSサービスかもしれません。

MCUソフト開発環境もmbedなどは、開発環境が全てクラウド側で用意されていて、ローカルでは、高度なデバッグを除いてブラウザのみで開発ができます。今回のようなトラブルが発生しても、開発を中断せずに続けられます。

未だWindowsとOfficeのカスタマイズ復元中です。これらを復元するため、先ずWordでトラブル顛末記を作成しました（カスタマイズに要する時間：推定1W～2W）。

トラブルから得た教訓

・Windowsクリーンインストールは、ローカルアカウントにて行うべし。
・モニタは大きいものが必須。次期ノートPCは、携帯性を犠牲にしても17インチモニタにすべし（1キロ13インチなんてとんでもない！）
・各種カスタマイズ復元ソフトを探すべし。

MCUXpresso概要と当面の開発方法

2017年4月18日2017年4月18日 WithHappy

LPCXpressoとKinetis Design Studioが新しいMCUXpressoへ統合されました。Windows 10 Version 1703で動作確認したMCUXpressoの概要について示します。

MCUXpresso概要

MCUXpressoの概要は、コチラの4分程の英語Videoが良く解ります。ポイント抜粋すると以下になります。

MCUXpressoは、3つのツール：IDE、SDK、CFGから構成され、各機能が下記です。

IDE機能：ソースエディト、コンパイル、デバッグ。Eclipse 4.6ベース。ローカルPCで利用。
SDK機能：使用デバイスのAPI生成とサンプルソフト提供。クラウドで設定し、結果をIDEにダウンロードして利用。
CFG機能：使用ピン、動作周波数など設定。クラウドで設定し、結果をIDEにダウンロードして利用。

全てが1パッケージのローカルPCで機能した旧IDE（LPCXpressoやKinetis Design Studio）を、MCUXpressoで３ツール構成にしたのは、SDKとCFGをクラウド側で分離提供し、IDEを軽量化することと、CMSIS準拠の開発環境構築が目的だと思います。CMSISはコチラの記事を参照してください。

CMSIS準拠ならMCUハードとソフトの分離が容易になり、開発済みアプリケーション資産を少ない工数で別ハード移植や再利用が可能です。また、CMSIS仕様（CMSIS-COREや-DSPなど）が修正/更新されても、その内容は全てクラウド側のSDKとCFGツールに閉じ込めることができるので、常に最新CMSIS準拠のSDKとCFGを利用したソフト開発が可能です。
ARM Cortex M系のIDEは、今後この分離構成が流行するかもしれません。

注目点は、IDEではコードサイズ制限なし、SDKではFreeRTOS v9提供（LPCXpresso最終版はv8）、CFGでは電力評価やプロジェクトクローナーです。各ツールの概要を以下に示します。

MCUXpresso IDE

旧LPCXpressoとの差分は、FreeRTOSタブが新設されたこと位です。コードサイズ制限なしで、添付マニュアル類も判り易く、誰にでも使い勝手が良いIDEです。MCU開発は、従来のRTOSを使わないベアメタル開発から、RTOS利用ソフト開発へシフトしつつあり、このMCUXpresso IDEもこの流れに沿った機能が追加されました。

MCUXpresso SDK

SDK BuilderでBoard、Processor、Kitsなどの対象MCUパラメタを入力し、対応するSDKパッケージをクラウドで作成後、ローカルPCへダウンロードして使います。パッケージの中身は、APIとこのAPIの活用サンプル集です。但し、2017年4月現在は、FreescaleのMCUと2017年に発売されたNXPのLPC54000対応のものしか提供されていません。

その理由は、旧Kinetis Design Studio：KDSのProcessor Expert：PEの代替だからと推測します。MCUXpressoは、KDSのPE機能がSDKとCFGに分離してクラウドへ実装されました。PEをお気に入りだったユーザは、この点に困惑すると思います。

一方旧LPCXpressoのユーザのSDKはというと、これは従来のLPCXpressoに同胞されていたLPCOpenライブラリなどがそのままMCUXpressoにも実装されています。つまり、MCUXpressoは旧LPCOpenライブラリなどが従来同様使えます。

従って、LPC54000開発とKDSユーザ以外は、MCUXpresso SDKを使うことは、今のところありません。

MCUXpresso CFG

CFGも現状はSDKと同様、FreescaleのSDKとNXPのLPC54000対応のみが提供中です。

MCUXpressoのまとめと当面の開発方法

MCUXpressoは、旧LPCXpressoと旧Kinetis Design Studioを統合した新しいIDEで、現状「フレームワークは出来たものの、完全な移行完了とは言い難い」ものです。以下に特徴を示します。

IDEとSDK、CFGの3ツールに分離するフレームワークは、CMSIS準拠ソフト開発に適している。
KDSのPE代替機能をSDKとCFGに割振っている。2017年NXP発売のLPC54000開発にも使えるが、既存NXPのMCUはSDK、CFGともに未対応。
LPCXpressoとKDSの今後の更新は、期待できない。将来的には、NXP/FreescaleのMCU開発にMCUXpressoを使う必要あり。
LPCXpressoユーザは、当面SDKとCFGを使わずにMCUXpresso IDEを旧LPCXpressoと殆ど同じ使用法で使える。
KDSユーザは、MCUXpresso IDEとSDK、CFGを使い開発する方法と、当面はMCUXpressoにPEをプラグインし開発する方法の２通りの開発方法が取りえる。但し、PEの更新が期待できないので、将来はMCUXpresso SDK、CFGを使わざるをえない。

当面の目安としては、LPCXpressoユーザならば、既存MCUのSDK、CFGが提供されるまで、KDSユーザならば、PE更新が必要になるまで、でしょう。

もう1つの目安が以下です。Windows 10 1703更新に相当するIDEベースEclipse 4.6（Neon）の次版4.7（Oxygen）への更新は、2017年6月の予定です。IDEベース更新から約半年でこの4.7ベースの最新IDEが各社からリリースされるとすると、2017年末から2018年初め位にはMCUXpressoへの完全移行完了となる可能性があります。

MCUのIDEは開発スピードを左右する部分だけに、仕様変更や更新が定期的に発生する部分と、各社独自の部分を分離し、トータルでパッケージ化すると、以上で示したフレームワークが重要となります。開発者は、フレームワーク要素更新にも注意を払う必要があるでしょう。