IoT MCU開発お役立ち情報満載
マイコンやIoT関連の情報、Tipsなどを記載します。
STマイクロエレクトロニクス（以下STM）の「日本語マイコン関連情報」、STM32マイコン マンスリー・アップデートを紹介します。
無料の登録制です。
その他、開発に役立つ情報が、丁寧に整理されています。
特に、1最後の”今月のコラムと技術解説”は、A4：1ページに纏まっていて、チョットした空き時間に目を通しておくと、後々役立つ情報になると思います。
また、2と3のMCU資料更新や新規追加、IDE更新情報は、リンク一覧で当該場所が判る優れたハイパーテキストです。
STM32開発者に限らずARM Cortex-M開発者なら一読の価値がある月刊誌でお勧めです。
米）市場調査会社IC InsightsのMCU市場予測記事、“マイコン市場、IoTを追い風に安定成長”が、EE Times Japanに掲載されました（2018年9月19日）。
2022年までの5年間世界MCU市場は、販売額は年平均成長率7.2％続伸、出荷数は年平均成長率11.1％続伸、平均価格は年平均成長率3.5%下落と予測しています。センサー普及やIoT台頭で安定成長の見込みとの結論です。
我々MCU開発者は、ますます忙しくなるでしょう (^^♪。
2018年販売額は、前年比11％増加で過去最高186億米ドルと見込み、2019年は9％増で204億米ドルと予測。
今後５年間、年平均成長率7.2％で続伸し、2022年は239憶米ドルと予測。
2018年出荷数は、前年比18％増加の306億個の見込み。
今後5年間、年平均成長率11.1％で続伸し、2022年は438億個と予測。
2017年に過去最低に落ち込み、2018年も同じペースで下落するが、過去5年間の年間下落率は、その前の10年間に比べ緩やかになったと分析。
2017年から2022年は、年平均成長率3.5%で下落と予測。
※1$以下のMCU平均価格内訳を知りたいところです。下記、過去関連投稿内容ともほぼ合致しています。
関連投稿：2018年IoT市場予測
関連投稿：IoTマイコン市場規模予測
2018年9月11日、ルネサスエレクトロニクス（ルネサス）が米）Integrated Device Technology（IDT）を買収すると発表しました。
約67億ドル買収完了見込みの2019年前半には、IDTはルネサス完全子会社になります。
・補完性が高い製品獲得によるソリューション提供力の強化
・事業成長機会の拡大
ルネサスは、RFや各種アナログ・ミックスドシグナル機能を持つIDT製品を獲得し、これらをマイコンやパワーマネジメントICと組み合わせ、アナログフロントエンドを強化、これによりIoTや産業、自動車分野の事業領域拡大を狙うと発表しました。
2017年2月に32億1900万ドルで買収したアナログ半導体メーカの米）Inersilと今回のIDTとの事業重複は無く、ルネサス＋IDT＋Intersilでエンドポイントのインテリジェンスを抑え勝つ（＝優勝を狙う）とルネサス）社長兼CEOの呉文精氏はコメントしています。
System on a chip（SoC）でルネサスMCUに強力なアナログ機能が実装される可能性が高まったと思います。
同様の動向として、アナログフロントエンドに計算機能を備えたインテリジェントADCを使いAD変換結果に含まれるノイズを除去、MCU処理電力を低減するADCCデバイスをMicrochipが発表しました。
2018年9月19日水曜14時～15時に、「センサノードの低コスト設定：ADCC」と題して日本語Webinarsが予定されています。登録は必要ですが、どなたでも無料で視聴できオンライン質問にも回答してくれるそうです。興味ある方は、参加してはいかがでしょう。
Qualcomm による約470億ドルNXPセミコンダクターズ（NXP）買収は、断念という結果になりました。“NXP買収を断念したQualcommの誤算（前・後編）”によると、半導体業界はこの騒動からいろいろな教訓を学ぶべきだそうです。
また、同記事でNXP CEOのRick Clemmer氏は、
「QualcommとNXPの合併により、さらなるスマート化に向けたセキュアな接続を実現するというわれわれのビジョンに必要な、あらゆる技術を統合できる。これによって、最先端のコンピューティングやユビキタス接続を、セキュリティや、マイクロコントローラなどの高性能ミックスドシグナルソリューションと組み合わせることが可能になる。両社が協業することで、さらに完成度の高いソリューションを提供できるようになるだろう。特に、自動車やコンシューマー、産業用IoT、デバイスレベルのセキュリティなどの分野において、リーダー的地位をさらに強化し、幅広い顧客基盤との間で既に構築している強固な協業関係を、さらに拡大していくことが可能になる」
と語っています。
上記は、買収を免れたNXPにとっては実現しなかった訳です。コメント内容は、ルネサスのIDT買収狙いと重なる部分が多く、IDT買収がルネサスにとって重要であることの証拠と言えると思います。
企業買収は、巨大な初期投資が必要な半導体業界での生き残りと主要技術確保のための戦略です。
ルネサスとNXPのIoT、産業、自動車分野のMCU競争は、ますます激しくなるでしょう。
MCU統合開発環境は、後方互換が重要です。数年前に開発したプロジェクトを改良・改版する際には、最新の開発環境（IDE）でも開発当時と同じ動作が求められるからです。
ベンダー各社もこの点に留意してIDE改版を行っているハズです。ただ、リリースノートにも具体的な互換性説明などは見当たりません。そこで、MCU最新IDEの後方互換性を検証します。
本稿は、ルネサスエレクトロニクス（以下、ルネサス）の最新IDE：CS+に、弊社2015年開発のRL78/G1xテンプレートプロジェクトを適用し、発生するメッセージなどを示し、開発当時と同じ動作をするかを確認します。もちろん、これはあくまでも一例にすぎませんが、開発中にIDE更新に遭遇した際などの安心材料になれば幸いです。
2018年9月最新ルネサスIDE CS+は、Ver.: V7.00.00（2018/07/20リリース）です。CS+は、業界標準のEclipseベースIDEではなくルネサス独自開発のIDEです。
好都合なことにWindows 10 1803をクリーンインストールしたので、まっさらなWindows 10へ最新CS+をインストールした条件で検証ができます（1803クリーンインストール顛末はコチラを参照）。
CS+ダウンロードサイトでカテゴリ：無償評価版を選び、分割ダウンロードか一括、CS+ for CCかCS+ for CA,CX のどれかのパッケージをダウンロード後、実行すれば必要なツール全てがWindowsへインストールされます。
関連投稿：CS+ for CCとCS+ for CA,CXの違い
以下CS+ for CCの例で示しますが、CS+ for CA,CXでも同じです。
CS+ for CCを起動し、既存のプロジェクトを開くでRL78/G1xテンプレートプロジェクトのCC-RLを選択すると、最初に警告メッセージが表示され、出力パネルにその内容、プロジェクト開発当時と新しいCS+での「プロジェクトの差分情報」が表示されます。
※“プロジェクト差分情報”は、新規CS+をインストールした時だけでなく、プロジェクト開発中にCS+更新に遭遇した際にも表示されます。
黒字の “デバイス・ファイルが更新……”は、CS+がサポートするMCUデバイスが増えたために発生します。あまり気にする必要はありません。
青字の “プロジェクト差分情報”は、新しいCS+を用いた結果、既存プロジェクトに生じた差分、影響のことです。
例えば、CS+のCC-RLコンパイラが改良・改版され、開発当時のコンパイル・オプションには無かった [間接参照を１バイト単位で行う] 選択肢が発生し、これに関しては、「いいえ」を選択したことなどが解ります。
これらの選択は、基本的に既存プロジェクトに影響が無い（少ない）方をデフォルトとしてCS+が選びます。このデフォルト選択が、CS+の後方互換を実現している鍵です。
そのままビルド（B）＞ビルド・プロジェクト（B）を実行すると、サブプロジェクトを含め全プロジェクトがリビルドされます。出力パネル青字は警告：Warring、赤字はエラー：Errorを示します。
出力パネルに赤字が出るのは問題ですが、青字内容に問題がなければ、新規CS+でもプロジェクトが正常にビルドできたことを示します。
そこで、ターゲット評価ボードへビルド出力をダウンロード、既存プロジェクト開発当時の動作確認ができ、最新CS+で後方互換が検証できました。
ルネサスCS+には、プロジェクトと開発ツールをパックして保存する便利な機能があります。
この開発ツールとは、使用中の統合開発環境のことで、文字通りプロジェクトとCS+、デバイス・ファイル情報などのプロジェクト開発時の環境を丸ごとそのまま保存し、復元もできます。
但し、当然OS：Windowsまでは保存しなので、年2回の大規模OS更新やWindows 7サービス終了などには開発者自ら対応する必要があります。
IDEの後方互換は、開発者にとっては当然のことです。ただし、改良・改版された最新コンパイラ性能を、既存プロジェクトで最大限引き出しているかは疑問を持つ方もいるでしょう。個人的には、この点について以下のように考えます。
例えば、弊社マイコンテンプレートは、１つを除いて全て上記方針で開発しています。除いた1点とは、NXPのLPC8xxテンプレートのLPC810（ROM 4KB/RAM 1KB）の小ROMデバイスの1段最適化のみです。テンプレート（ひな形）の性質上、いろいろなプロジェクトへの適応性が高いのもこの方針の理由です。また、デフォルト設定と最小限設定なので、結果的に最新統合開発環境への後方互換も取りやすいと言えます。
経験上、コンパイル・オプションを操作して開発したトリッキーなプロジェクトは、設計段階（MCU選択やプログラム構成）の失敗だと考えています。個人的には、デフォルト設定で十分余裕（50％程度）がある設計がお勧めです。これを確かめるためにも、プロトタイプ開発は重要だというのが私の考えです。
MCU統合開発環境（IDE）とWindows環境の年間メジャー更新スケジュールは下図です（2018年7月9日投稿の再掲）。
プロジェクト開発中にこれら更新に遭遇することは少なくないでしょう。本稿は、ルネサスCS+を例に最新IDEの後方互換性を確認しました。EclipseベースのIDEでも同様です。まとめると、
ことを示しました。
最新ARM Cortex-Mマイコン：MCU製品からその動向を調査します。前稿ルネサスエレクトロニクス（以下ルネサス）RL78ファミリの汎用MCU変遷に続き、ARM Cortex-MコアMCU編という位置づけです。最後に両者を比較し、IoT MCUを特徴付ける3要素についての私見を示します。
本ブログ掲載中のベンダ各社とMCUです。
ルネサス以外は、全てARM Cortex-Mコアを用いています。これらをARMコア製品、一方ルネサスはNon ARMコア製品と呼ばれます。現在のMCUは殆どがARMコア製品です。
各社ともIoT向けのMCU新製品を発売中です。その中からNXPセミコンダクターズ（以下NXP）のLPC51U68 MCU（2018年3月発売）をピックアップし特徴を抽出します。
LPC51U68は、8/16ビット置換えを狙う低消費電力Cortex-M0+コアを最大100MHz動作まで高め、USB2.0、256KB ROM、96KB RAM実装、12bit 5Mspsと高機能ADC内蔵のMCUです。
32ビットCortex-M0/M0+コア本来の目的は、既存8/16ビットMCUの置換えです。従ってこれまでは、既存MCU（例えばルネサスS1/S2/S3コア）速度と同等の30～50MHzがCortex-M0/M0+コア動作速度でした。しかし、NXPはより低速で低消費電力な8MHzや15MHzのコア速度の新製品を発表しました。
関連投稿：8MHz Cortex-M0+コア採用のLPC8N04
関連投稿：15MHz Cortex-Ｍ0+コア採用のLPC80x
つまり、既存MCU置換えだけでなく、よりアプリケーションに適したコア速度採用のARMコア製品の一環として開発されたのが紹介した100MHz動作のLPC51U68です。
ARMコア製品は、8/16ビット置換えから、IoTアプリケーション市場開拓への展開も始めたと言えるでしょう。
従来MCUもUSB接続でプログラムダウンロードやデバッグはできます。これらに加えLPC51U68のUSBは、USB 2.0ホスト機能もライブラリで提供します。PC同様、USBキーボードやデータロガー用に簡単に大容量USBメモリがMCUに接続できるので、HMI（Human Machine Interface）に優れたIoTデバイスが開発できます。
ADCもE-meterなどにも使いやすいような高機能版が用いられています。
ROM/RAM容量が増えるのは、これらIoT向け周辺回路を制御・活用するために必要で、副次的なものと言えるでしょう。
評価ボードLPCXpresso51U68 (OM40005) Development Board価格も￥3,518（DigiKey調べ）であることから、これだけ機能が増えても、従来ARMコア製品と同レベルで入手できると思われます。
NXP）LPC51U68だけでなく、競合他社Cortex-M0/M0+/M3新製品についても同様の傾向が見られます。最新Cortex-Mマイコンの動向をまとめたのが下記です。
一方、前稿Non ARMコア製品のルネサスMCU動向をまとめると、
どちらも、無線通信やセキュリティの要求が高いIoT MCUに対して、従来の汎用MCU製品のままでは対応しにくく、より具体的なIoTアプリケーションへ向けた機能拡張を行い、セミASSP的なIoT MCU製品となっています。
※セミASSP：汎用MCUをベースに、特定アプリケーション向けに調整したMCU。汎用MCU開発に慣れた開発者が、特定アプリ開発に臨む時、ASSPに比べ馴染みやすく開発障壁が低い。
ARMコア製品が柔軟性や拡張性に富み、一方で、Non ARMコア製品のルネサスもIoT向きに汎用MCUを調整しています。いずれにしても汎用MCUは、よりアプリケーション向きのMCUへ変化しつつあります。
IoT MCUは、以下3要素から構成されると考えると理解が容易になります。
先ず、どのようなアプリケーションにMCUを使うかで「IoTアプリケーション対応周辺回路」が実装されます。例えば、USBホスト機能が必要なアプリであれば、NXP）LPC51U68などです。
次に、そのアプリケーション周辺回路制御に十分な動作周波数や性能をもつ「MCUコア」が決まります。
最後に、「汎用周辺回路：タイマーやGPIO、UART、I2C回路」の実装数がアプリケーションに対して十分か調べます。
多くのアプリケーションに広く対応できる汎用MCUの汎用周辺回路のみで開発できるアプリケーションであれば、実績が多い汎用MCUを選び、IoTに必要となる無線やセキュリティ機能を外付け部品で構成すると良いと思います。
より具体的なIoTアプリケーションに対応する場合は、IoTアプリケーション対応周辺回路を持つ各社の新製品MCU（セミASSP MCU）を選び、開発するのが良いと思います。
「IoTアプリケーション対応高機能周辺回路」とは、文字通りアプリに応じた開発や応用、最適化が必要です。各社はこのIoTアプリケーション対応周辺回路に対して、ライブラリやアプリケーションノートを提供しますので、開発はそれらを応用、流用するとリスクが低くなります。
一方、「MCUコア」と「汎用周辺回路：タイマーやGPIO、UART、I2C回路、一般的なADC」は、既存の開発ソフトウェアやハードウェアがほとんどそのまま使える可能性が高い部分です。
IoT MCUを早期開発するには、この既存ソフトウェアやハードウェアを流用し、より多くの時間をIoTアプリケーション開発へ配分する方法が適します。弊社マイコンテンプレートは、この汎用開発部分に役立ちます。ご活用ください。
汎用MCUの定義が変わりつつあります。ルネサスエレクトロニクス（以下、ルネサス）のRL78ファミリから、最近の汎用MCUの変わりつつある現状を考察します。
2018年6月版の最新RL78ファミリMCUカタログから抜粋したRL78ファミリのロードマップです。
赤囲みのRL78/G1xが汎用MCU製品を示します。2014年以後は、For小型システムやForモータシステムなど、一見するとASSP：application-specific standard product、特定用途向けMCUのような製品が汎用MCUの中にあります。
これは、RL78/G1Fのコンセプトを見るとその理由が理解できます（出典：ローエンドマイコンで実現できる 高機能なブラシレスDCモータ制御）
つまり、汎用MCU RL78/G14を、モータシステム向きに周辺機能拡張や使い勝手を向上させたのがRL78/G1Fなのです。あくまで汎用MCUがベースで、それを特定用途、この場合はモータ制御向けに調整したのです。
このメリットは、開発者、ルネサス双方にあります。開発者にとっては、使い慣れた汎用MCUの延長上に特定用途向けMCUがあるので馴染みやすく開発障壁が低くなること、ルネサスにとっては、新規ASSPを開発するよりも低コスト、低リスクなことです。
RL78ファミリのMCUには、S1/S2/S3という3種類のコアがあります。数字が大きくなると高性能になります。
関連投稿：RL78 S1/S2/S3コアの分類
ルネサスの汎用MCUとは、これらS1/S2/S3コアを使ったMCU製品を指します。また、RL78/G1FのようにS3コアMCUのRL78/G14をベースとし、特定用途向け機能を付加したものも汎用MCUです。
※弊社は、S1/S2/S3コアの各汎用MCUに対してRL78/G1xテンプレートを販売中です。
この特定用途名が、ルネサスが考えるIoT時代にふさわしい汎用MCUと言えます。「汎用」という従来の広く漠然とした用途よりも、より「具体的な用途・応用に適す汎用MCU製品」としてRL78/G1FやRL78/G11があるのです。
このIoT時代の特定用途向けMCU開発でも、弊社RL78/G1xテンプレートが使えます。ベースが「汎用中の汎用」RL78/G10（S1コア）、RL78/G13（S2コア）、RL78/G14（S3コア）だからです。
例えば、RL78/G1Fのアプリケーションノートやサンプルコードは、具体的でほとんどそのまま開発製品へ適用できます。しかし、用途が限定されているだけに、逆に簡単な機能追加が難しい場合もあります。そんな時に、テンプレートが提供するサンプルコードを活かしつつ処理を追加できる機能を使うと便利です。
ここでは、ルネサス汎用MCUについて考察しましたが、NXPセミコンダクターズやSTマイクロエレクトロニクス、Cypressセミコンダクターなどの他社MCUベンダも同様です。汎用MCUの定義は、より具体的な用途・応用名が付いたIoT MCUへ変わりつつあります。しかし、基本の汎用MCUを習得していれば、より応用し発展できます。基本が重要だということです。
IoTでは、MCU開発はより複雑で高度になります。また、製品完成度の要求もさらに高まります。基本要素や技術を、（たとえブラックボックス的だとしても）積み上げられる、基礎・基本を習得した開発者のみが生き残ると思います。開発者個人で基礎を習得するために、是非弊社マイコンテンプレートをご活用ください。
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 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保存済みの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は復活しました。
突然起動不能に陥った自作メインWindows 10 PC。MCU開発環境は、このPC上に構築されており、メインPCとバックアップPCとのデータ同期も完全では無かったため、実行中であったMCU開発も完全に停止、開発途中部分もすっかり消えてしまいました。
本稿は、トラブルの前兆からWindows 10 クリーンインストールまでの顛末を示し、個人的には同様のトラブルへの備え、また、MCU開発者の方々には、休憩時の笑いネタになればと思い掲載します。
メイン開発環境に使ってきたWindows 10 Pro 64ビットは、Windows 7→Windows 8→Windows10と無料アップグレードを繰返し乗り切ってきた強者です。この間、マザーボードやHDDからSSDへのストレージ変更などの自作PCのハードウェアも更新し、2017年秋の1709前までは安定して動作しておりました。
マザーボードは、UEFI仕様ですが、Windows 7時代の旧ボード設定をそのまま引継いだため、レガシーBIOSモードで起動させていました。
1709更新後、以下のような細かいトラブルが発生していました。
1と2のトラブルは、加齢のため文字よりも図形表示を好むようになり、サムネイル表示やフォルダアイコンも、内容が即解るものを多用するようになった結果で、これらトラブルはPC利用上とても気になっていました。しかし、これらのトラブル対策はネット上には見当たりませんでした。
3は、メインPCとバックアップPCのデータ同期の妨げになり憂慮していましたが、1803でホームグループ廃止となるので、1803更新後に対策をとる予定でした。また、4の原因は不明でしたが、リセットボタンで解決するし、頻度も低いので、様子見をしていました。
ホームグループ機能が消えた1803では、簡単接続のホームグループよりも面倒なものの、ネットワークと共有センターの設定を見直し、メインPCとバックアップPCの接続トラブルは解決しました。
また、マイドキュメントのサムネイル非表示は、OneDrive同期からGoogleのバックアップと同期に変更し解決しました。PC起動失敗も1803更新後は、一度も発生せず安心しておりました。つまり、1803更新以降は、2のトラブル以外は解決し、安定動作をしていました。
メイン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ライセンス認証も問題ありません。
私は、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インチなんてとんでもない！）
・各種カスタマイズ復元ソフトを探すべし。
開発環境、特にマイコンソフトウェアの統合開発環境（IDE）は、Eclipseベースが主流です。Eclipseは、年1回6月にメジャー更新され、2018年はPhoton（光子）がリリースされました。本投稿は、開発環境の更新時期と留意点、対策などを示します。
主要開発環境の、メジャー更新時期を一覧にしました。1開発期間が3カ月～6カ月とすると、なにがしかの更新に出会うことは確実です。期間中は開発者なら、できれば環境更新などのトラブルの種を避けたいのが願いですが、現状は難しい状況です。
これらの各種更新による色々なトラブルを避ける最も簡単な方法は、更新を一時的にせよ停止/延期することです。Windows更新を停止/延期するには、コチラに方法が示されています。
EclipseベースのIDEやルネサスCS+の場合には、更新通知があっても、開発者が許可しない限り自動的に更新しないので、Windowsに比べ安心です。但し、開発中の案件が直面しているバグや問題が、更新で解決される場合もありますので、直面問題が開発環境起因かどうかの判断が重要です。
また、Windowsは、SSD/HDDの故障などにより、いとも簡単に起動不能になります。これら更新トラブルや起動不能に対処するには、メイン開発環境とは別に、もう1つ別のバックアップ開発環境があるのが理想的です。
但し、この場合でも、メイン開発環境とバックアップ開発環境のデータ同期に注意を払わないと、折角のバックアップ環境もムダになります。
※弊社開発環境もWindows起動不能に陥り、自動修復やbootrecコマンドで「全く楽しくない修復」を試みていますが、未だ解決していません。
EclipseベースIDEで日本語化を望む場合には、Pleiades（プレアデス）というプラグインが使える可能性があります。個人的には、開発時に使うコマンドやボタンはF5やF8など決まっているので、英語版でも問題は無いと思っていますが、気になる方は、バックアップ環境で試すのも一案でしょう。
