Office 2010とLibreOffice運用案

1月29日、LibreOffice Fresh(最新版)が6.4.0へ更新されました。Still(安定版)は、6.3.4です。

LibreOffice版数(2020年2月3日現在)
パッケージ 想定ユーザ 2020/1/31版数
Fresh(最新版) 技術マニア、新しいもの好き、パワーユーザ向け 6.4.0
Still(安定版) ビジネス組織、法人企業、慎重なユーザ向け 6.3.4

Fresh(1か月毎更新)は、新しい6.4系へ、Still(3か月毎更新)は、6.3系のバグ取りがすすんでいます。QRコード生成などFresh 6.4の主な追加機能は、コチラの記事が参考になります。

10月13日、Office 2010全サポート終了

2020年10月13日全てのサポートが終了するOffice 2010の代替アプリケーション候補として、LibreOffice 6.4を試用中です。何回かLibreOffice設定や新規文書作成について、無料Writer/Drawテンプレート配布を含む投稿を行ってきました(関連投稿は、カテゴリ:LibreOfficeを選択してください)。

新規Writer/Draw文書作成に関しては、慣れの問題は除いてLibreOfficeを、Office Word/Visio代替として利用することに問題はありません。機能差はありますが、同等の文書が作成可能です。

残る問題は、LibreOfficeがOffice 100%互換アプリではないことです。

もちろん、新旧Office文書をLibreOfficeで読込み/書込みはできます。但し、100%互換ではないので、場合によっては文字や図形の「レイアウト崩れ」が発生します。フォントの違いに起因しているようですが、それ以外にも色々な要因がありそうです。

これは、同じMicrosoftのOfficeアプリケーション、例えばWord 2003と2010でも100%互換は不可能でレイアウト崩れが生じますので、やむを得ないと思います。

そこで本稿は、これらの状況を踏まえたうえで、Office 2010サポート終了後のOffice 2010とLibreOffice運用に関しての私案を示します。

Office 2010とLibreOffice併用私案

  • 新規文書作成は、全てLibreOffice。Office 2010での新規文書作成は、停止。
  • Office 2010サポート終了後も、PCからOffice 2010のアンインストールはせずLibreOfficeと併用。
  • 既存Office 2010文書は、Office 2010で閲覧。
  • 既存Office文書の改版時は、Officeの内容を新規LibreOfficeへコピー&ペーストし新規作成。
  • 文書配布は、PDF化。

私案説明

2020年10月13日サポート終了後のOffice文書運用私案
2020年10月13日サポート終了後のOffice文書運用私案

アプリケーションが異なれば、レイアウト崩れの発生は当然だと諦めます。Office 2016/2019/365でも2010の100%下位互換性は困難で、Office 2010文書レイアウト崩れが発生します。

10月13日以降もPCからOffice 2010をアンインストールしないのは、PC内に「既に存在するOffice文書閲覧」のためのみです。PC外部から「入手したOffice文書は、LibreOfficeで閲覧」し、必要ならLibreOffice形式で保存します。この2つの方法で、更新されないサポート終了後のOffice 2010セキュリティ対策をします。

既存Office文書は、Office 2010での閲覧なのでレイアウト崩れはありません。この文書を改版する時は、LibreOfficeへ内容をコピー&ペーストし、崩れ無しのオリジナルOffice 2010レイアウトを参照しながら、新たにLibreOffice文書を作成します。

ポイントは、「新なOffice 2010文書作成をしない」ことです。

サポート終了後は、Office 2010セキュリティ対策の更新がないので、10月13日以降の将来、Office 2010に発見される可能性があるセキュリティホールに対しては、新規文書作成をしないことで対処します。もちろん、マクロなどは動作させません。
※Office Viewerという手段もありより安全ですが、2010そのものの方が好みです。

Office 2010をアンインストールし、有料Office 2016/2019/365へ更新しても、私案と「Office 2010の将来セキュリティ」に関する万全さは大差なしと思います。また、Office 2016/2019/365でも、頻度は減るでしょうがレイアウト崩れが発生することを考慮すると、無料LibreOfficeの新旧Office文書読込みとOffice形式での書込み能力は、高く評価できます。

私案では、「追加コストなし」で、既存Office 2010文書閲覧、可能な限りのセキュリティ対策、新規LibreOfficeによるPC文書作成を行います。文書の外部配布は、全てPDF化で対処します。

まとめ

Office 2010サポート終了に伴い、代替アプリケーションとしてクロスプラットフォームでオープンソースのLibreOfficeを昨年の8月から約半年間試用してきました。

その結果、LibreOffice文書の標準保存ファイル形式は、オープンドキュメント形式(ODF)で、国際標準規格であること、また、LibreOfficeで、Office 2010と同等の文書作成が可能であることが判りました。

そこで、今後の文書作成は全てLibreOfficeを使い、Office文書の読込みと書込みができるLibreOffice能力を活かし、Office 2010サポート終了後のOffice 2010とLibreOffice併用私案を示しました。使用頻度の低いバックアップPCなどの文書作成環境としては、効果的だと思います。

この私案は、今後発見される可能性があるOffice 2010セキュリティホールに対して脆弱性があるので、試す方は自己責任で使ってください。また、私案に問題などがございましたらメールでお知らせください😌。

中国製STM32互換MCU

1月28日、EE Times Japanに“互換チップが次々と生まれる中国、半導体業界の新たな潮流”という記事が掲載されました。スイス・ジュネーヴ本社のSTマイクロエレクトロニクス(以下STM)のSTM32互換MCUが、中国で製造プロセス縮小、ローコスト化し販売中だそうです。

STM32F030、STM32F103互換MCU

記事記載の互換デバイスは、STM32F030(Cortex-M0、64KB Flash、8KB RAM)と、STM32F103(Cortex-M3、72MHz、128KB Flash、20KB RAM)の2種。どちらもSTM純正180nmプロセス製造MCUを、130nmプロセスで製造しており、ローコスト化、低電力化、動作周波数アップが狙いです。

STM32F103搭載のNucle-F103RB評価ボード
STM32F103搭載のNucle-F103RB評価ボード

さらに、ARM Cortex-Mコア部分のみをオープン仕様RISC-Vコアへ変えた、STM32互換RISC-V MCUもあるそうです(記事、図4参照)。

記事筆者の清水氏(テカナリエ)は、これら中国製互換デバイスを否定するのが目的ではなく、現状の事実、互換製造ができる高い技術力、STM32MCUが汎用MCUデファクトスタンダードであること、中国半導体業界のこの方向性が、ますます加速する可能性があると報告しています。

日本が見習うべきもの

RISC-Vはオープン仕様ですが、Cortex互換MCU販売には、ARMライセンスフィーなど気になる事柄もあります。但し、本ブログ筆者も清水氏と同じく、その背景にある技術力、ビジネスセンスについて見習うべきものが多いと思います。

STM互換MCUは、純正品よりも安く、しかも高性能です。開発環境や評価ボード、開発ソフトウェアはそのまま互換MCUでも動作します。欧州ベンダのSTM互換MCU開発・販売は、米国ベンダ互換よりもハードルが低いでしょう。世界情勢なども反映された成功事例だと思います。

例え安く高性能な部品(BOM:Bill Of Matrix)が提供されても、それを使って開発できる技術者がいなければ製品化はできません。技術者スキルが最も伸びるのは、開発中です。中国技術者は、高性能製品を低価格で、次々と提供できている事実があります。

もちろん失敗事例もたくさんあるハズです。しかし、技術者にとっては、成功失敗を問わずどんな事例でも開発経験はスキルに直結します。

一方、日本の環境は、時短や効率化など見た目の生産性や成功例のみに注目しがちです。ただ、技術者スキルは世界レベルで評価されるので、このままの環境では、先々の日本開発案件は無くなるのではと危惧しています。

例えば自動車は、日本メーカを選択する人はいても、それが日本開発かは問題にしません。むしろ世界各地で開発されています。
※日産の先進自動運転技術(ADAS)は、米国女性技術者が中心で開発されたと、何かで読んだ記憶があります。

5G、6G世代のネット高速化、自動翻訳やAIなどの環境変化で、日本開発に拘るユーザは、減少の一途となるでしょう。

日本技術者は、次世代の自分自身のため、世界で通用するスキルを身に付ける必要があります。

弊社STM32F0/F1に使えるSTM32FxテンプレートSTM32G0xテンプレートその他ベンダのMCUテンプレートは、初心者~中級レベルソフトウェア技術者向きです。初級~中級技術を効率的に習得し、さらに高度なスキル獲得に少しでもお役立てれば幸いです。と、最後は自社広告になってしまいました😌。

FreeRTOSサンプルコード(2)

FreeRTOSデバッグは、ベアメタルソフトウェアデバッグと異なる準備が必要です。

幸いなことに、前稿で示したMCUXpresso54114評価ボードとSDK付属FreeRTOSサンプルコードを使ってMCUXpresso IDEでFreeRTOSデバッグを行う場合は、この準備がサンプルコードやIDEデバッガに予め設定済みです。何もせずに直にデバッグができます。

FreeRTOSデバッグ準備

但し、LPCOpenライブラリFreeRTOSサンプルコードを利用する場合や、FreeRTOSソフトウェアを自作する場合には、この事前準備を知らないとFreeRTOSデバッグができません。
※LPCOpenライブラリと下記MCUXpresso IDE FreeRTOS Debug Guideも前稿参照。

MCUXpresso IDE FreeRTOS Debug Guideの2章に、準備理由や追加設定個所が詳細に記載されています。

  • デバッグリンクサーバー(CMSIS-DAP)のAll-Stopモードへ切り替え ※デフォルトはNon-Stopモード
  • FreeRTOSカーネルソースコード修正 ※SDK付属サンプルコードは修正済み
  • メモリ使用法の設定

上2つは、IDEでFreeRTOS本体動作確認のための設定、メモリ設定は、限られたMCUメモリの活用方法でheap_1~5まで5種類あります。

これらは、ベアメタル開発とは異なるFreeRTOS利用オーバーヘッドで、メモリ使用法は、動作するMCU毎に異なりノウハウが必要になると思います。MCUXpresso54114評価ボードSDK付属FreeRTOSサンプルコードのメモリ使用法は、調査します。

FreeRTOSサンプルコード:タスク数=1

MCUXpresso54114 SDK v2.7.0の11個あるFreeRTOSサンプルコードを、タスク数で並び換えたのが下表です。本稿は、タスク数=1のFreeRTOSプロジェクトを調査します。

FreeRTOSソフトウェア開発は、タスク数が少ない方が理解し易くタスクプライオリティ設定も不要です。この中では、freertos_swtimerが一番簡単、下方につれて複雑なプロジェクトになります。

FreeRTOSプロジェクト:タスク数=1
Project Tasks heap_ Additional FreeRTOS APIs (Bold) Additional Comments
freertos_swtimer 1 4

xTaskCreate
vTaskStartScheduler
xTimerStart

IDE Console出力
ユーザ作成Software Timerデモ

freertos_hello 1 4

xTaskCreate
vTaskStartScheduler
vTaskSuspend

IDE Console出力

freertos_usart 1 4

xTaskCreate
vTaskStartScheduler
vTaskSuspend

Usart 115200bps 8-Non-1送受信
4B受信後エコーバック

※heap_4:断片化を避けるため、隣接する空きブロックを結合。絶対アドレス配置オプション含む。
※FreeRTOS API接頭語x/v:API戻り値型を示し「v」がvoidを、「x」が結果コードまたはハンドルを返す。

サンプルコード利用FreeRTOS APIと、Doc>readme.txtのProject説明へ付け加える内容をAdditional Commentsに記載しました。太字以外のFreeRTOS APIは、マイコンRTOS習得2017で説明済みのため、本稿では省略します。

xTimerStartは、ユーザ作成ソフトウェアタイマの動作開始FreeRTOS APIです。

IDE Consoleは、ソースコード内へマクロ:PRINTFを挿入すると、IDE下段Console窓へ数値や文字列などの入出力が簡単にできる機能です。

FreeRTOS Project:main()

ベアメタルmain()と同様、初期設定+無限ループの構造です。
差分は、タスク登録とスケジューラー起動から成るFreeRTOS初期設定が、評価ボード初期設定後に加わることです。

FreeRTOS Project main()構造(freertos_helloにコメント加筆)
FreeRTOS Project main()構造(freertos_helloにコメント加筆)

FreeRTOS Project:freertos_swtimer

ユーザ作成の1秒ソフトウェアタイマ割込み(SwTimerCallback)を使って、Console窓にTick文字を出力します。タスク登録直後、xTimerStartでユーザタイマをスタートしています。

例えば、ユーザ入力待ちの開始時にxTimerStartし、ユーザ反応が何もない時のタイムアップ処理などに使うと便利です。

FreeRTOS Project:freertos_hello

タイトル出力など1回限りのConsole窓出力に便利です。hello_taskは、出力後、vTaskSuspendで待ち状態になります。タスク正常終了後は、vTaskSuspend処理が一般的なようです。

FreeRTOS Project:freertos_usart

UART0の115200bps 8-Non-1を使ったVirtual COMポート送受信タスクです。受信リングバッファ利用で4B受信後に受信文字をエコーバックします。4Bまとめてのエコーバックは、1B毎よりも効率的です。

例えば、処理途中で割込みなどの他処理が入っても、受信リングバッファ利用で取りこぼしデータがなく、かつ、RTOSが処理中断/再開を行うので、このような記述がFreeRTOSマルチタスク動作に好都合かもしれません。
ベアメタル開発にはないRTOSソフトウェア開発ノウハウの可能性があります。

※筆者自身RTOSは初心者です。本調査結果は、FreeRTOS APIレファレンス等も参照して記述しておりますが、多分に上記のような推測の域があることはご容赦ください。

FreeRTOSサンプルコード:タスク数=1の調査結果

  • FreeRTOS初期設定(タスク登録とスケジューラー起動)が、評価ボード初期設定後に追加
  • PRINTFを活用したFreeRTOSタスク単体デバッグの手本
  • タスク正常終了後は、vTaskSuspend処理
  • UART0利用VCOM送受信タスク(uart_task)は、移植性が高く、流用・応用が容易
  • メモリ使用法は、heap_4を利用

ここで示したFreeRTOSサンプルコードは、MCUXpresso54114評価ボードがあると動作確認が可能ですが、無くてもMCUXpresso IDEをPCへインストールすれば、どなたでもコストがかからず参照頂けます(インストール方法は、関連投稿:NXPマイコン開発環境更新を参照)。

普段NXPマイコンをお使いでない方も、MCUXpresso IDEをインストールしFreeRTOSサンプルコードをご覧ください。不要になった後は、IDEアンインストールも簡単です。

以降のFreeRTOSサンプルコード関連投稿は、お手元に上記開発環境があるものとして説明いたしますので、よろしくお願いいたします。



FreeRTOSサンプルコード(1)

NXPのCortex-M4/M0+ディアルコアLPCXpresso54114のFreeRTOSサンプルコードを数回に分けて調査します。Cortex-M4クラスのMCUは、処理は高速で大容量Flash、RAMを持つので、ベアメタル利用だけでなくRTOS利用ソフトウェア開発にも適します。

ベアメタルCortex-M0/M0+/M3に適用済み弊社テンプレートを、そのままCortex-M4 MCUに使うのは、テンプレートがMCU非依存なので簡単です。ですが、先ずFreeRTOSソフトウェアをよく知り、新開発ベアメタルCortex-M4テンプレートへ応用できる機能があるか判断するのが調査の目的です。

RTOS習得2017

2017年3月にLPCXpresso824-MAX(Cortex-M0+ 30MHz、32KB Flash、8KB RAM)を使ってFreeRTOSのポイントを調査し、結果をマイコンRTOS習得ページにまとめました。

第1部から第3部で、最低限のFreeRTOSと使用APIを解説し、第4部で、最も優れた解説書と筆者が考えるソースコードと評価ボードを使ってFreeRTOS動作解析と習得を行うという内容です。

ただ、自作FreeRTOSサンプルコードの出来が悪く、第4部の動作解析は不十分でした。

そこで、RTOS利用がより現実的なLPCXpresso54114(Cortex-M4/M0+ 100MHz、256KB Flash、192KB RAM)評価ボードとSDK付属FreeRTOSサンプルコードを用いて、不十分だった第4部FreeRTOS動作解析に再挑戦します。平たく言えば、NXP公式FreeRTOSサンプルコードを、不出来な自作コードの代わりに利用します😅。

第1回目は、FreeRTOSサンプルコードの出所、FreeRTOS動作を調べる4ツールを説明します。

LPCXpresso54114 SDK付属FreeRTOSサンプルコード

NXPマイコンの公式サンプルコード取得方法は、3つあります。最も新しいのがSDK:Software Development Kitから、2つ目がLPCOpenライブラリから、3つ目がPE:Processor Expertからの取得です。

NXP社が古くから用いてきたサンプルコード提供方法が、LPCOpenライブラリです。
NXPに買収された旧Freescale社のKinetis MCUなどは、PEと呼ばれるGUIベースAPI生成ツールでサンプルコードを提供していました。同じMCUでも提供方法によりAPIは異なり、サンプルコード互換性はありません。
※ベンダ毎に異なるAPI提供方法やその違い、サンプルコードとの関係は、別投稿で説明する予定です。

Freescale買収後のNXPは、SDKで全MCU(=新旧NXP+買収FreescaleのMCU)のAPIとサンプルコードを提供する方法に統一したようです。その根拠は、最新MCUXpresso IDEユーザインタフェースが、SDKの利用前提でできているからです。

現在も提供中のLPCOpenライブラリ内にあるLPCXpresso54114 FreeRTOSサンプルコードは2個、一方、SDK内のFreeRTOSサンプルコードは11個あります。PE提供はありません。

調査対象としては、FreeRTOSサンプルコード数が最多のSDKが適しています。

LPCXpresso54114 FreeRTOS examples in SDK
LPCXpresso54114 FreeRTOS examples in SDK

FreeRTOS実動作解析ツール

MCUXpresso IDE v11.1.0のHelp>Help Contentsに、MCUXpresso IDE FreeRTOS Debug Guideがあります(PDF文書がMCUXpresso IDEインストールフォルダ内にも有り) 。この中に、FreeRTOSサンプルコードデバッグのみに使えるタスク対応デバッガ4ツール(Task List/Queue List/Timer List/Heap Usage)があります。

MCUXpresso IDE Help ContentsのFreeRTOS Debug GuideのShowing FreeRTOS TAD Views
MCUXpresso IDE Help ContentsのFreeRTOS Debug GuideのShowing FreeRTOS TAD Views
  • Task List:タスク毎のプライオリティ、スタック使用量、動作時間表示
  • Queue List:アクティブキュー、セマフォ、ミューテックス利用時のリソース表示
  • Timer List:RTOSタイマー表示
  • Heap Usage:ヒープ使用量、メモリブロック割当て表示

これらFreeRTOS専用ツールは、FreeRTOSサンプルコードの評価ボード動作後、デバッガ停止中に表示されます。シミュレーションではなく、評価ボードでの「実動作結果」が判ります。開発ソフトウェアだけでなくRTOS使用量が判るので、デバイスにどれ程リソース余裕があるかが判断できます。

RTOSソフトウェアは、ユーザが開発するタスクの単体、結合デバッグに加え、RTOS動作の確認事項が増えます。FreeRTOS実動作解析4ツールは、これらの確認ができます。評価ボードを使ったプロトタイプ開発の重要度は、ベアメタル開発比より大きくなると言えるでしょう。

次回以降、LPCXpresso54114のSDK付属FreeRTOSサンプルコードを、MCUXpresso IDEのFreeRTOS Debug Guideに沿って調査します。

STM32G071RBとAlexaを繋ぐ

1月9日STマイクロエレクトロニクス(以下STM)公式ブログに、STM32G0とAlexa(アレクサ)を接続する開発キット:Alexa Connect Kit(ACK)モジュールが紹介されました。アレクサに話しかけ、STM32G0評価ボードのNucleo-G071RB 経由でスマートホーム制御が簡単に実現できます。

システム構成

STM32G071RBとAlexaを接続するAlexa Connect Kit (ACK)のシステム構成
STM32G071RBとAlexaを接続するAlexa Connect Kit (ACK)のシステム構成

システム構成の公式ブログ掲載が無いので、自作したのが上図右側です(左側出典:STMサイト、Cortex-M7 MCUでアレクサ接続)。

USI MT7697HがACKモジュールで、Nucleo-G071RBとはArduinoコネクタで接続します。スマートスピーカに話しかけると、クラウド内で音声解析→制御コマンド生成を行い、このコマンドがACKへ無線送信され、STM32G0評価ボードNucleo-G071RBへ届き、STM32G071RBがスマートホーム機器などを制御します。

費用とSTM32G0用ACKドライバ、ファームウェア

費用:Nucleo-G071RBが約$10、ACKがUS Amazonで$197、(日本アマゾンで¥38,202)。

STM32G0用ACKドライバ、ファームウェア:公式ブログリンク先は、今日現在、提供されていません。

2018年6月頃は、STM32F7やSTM32H7などの高性能Cortex-M7 MCUでアレクサ接続がSTM公式ブログで投稿されましたが、今回Cortex-M0+のSTM32G0とACKでも簡単に接続可能になりました。

STM32G0特徴

2018年12月新発売のSTM32G0シリーズは、初の90nmプロセス製造MCUで低消費電力と高速動作、従来のSTM32F0 (Cortex-M0)~F1 (Cortex-M3)性能をカバーする新しい汎用MCUです。セキュリティハードウェア内蔵、低価格、64ピンパッケージでも1ペアVDD/VSS給電がSTM32G0の特徴です。
関連投稿:STM新汎用MCU STM32G0守備範囲が広いSTM32G0

STM32マイコンマンスリー・アップデート2020年1月のP4に、「STM32G0 シリーズのラインナップ拡充 STM32G041/ G031/ G030 新登場」記事もあります。筆者も、STM32G0シリーズは、STMの汎用MCUとしてお勧めデバイスです。

LL APIかHAL API、混在?

残念ながら今は未提供ですが、筆者は、ACKドライバとファームウェアのAPIに興味があります。

理由は、STM32G0シリーズの高性能を引き出すには、HAL:Hardware Abstraction Layer APIよりもエキスパート向けLL:Low Layer API利用ソフトウェア開発が適すからです。

HALとLL比較(出典:STM32 Embedded Software Overvire)
HALとLL比較(※説明のため着色しています。出典:STM32 Embedded Software Overvire)

生産性や移植性の高いHAL APIとLL APIの混在利用は、注意が必要です(関連投稿:STM32CubeMXのLow-Layer API利用法 (2)の4章)。

ACKドライバ、ファームウェアが、LL APIかHAL APIのどちらを使っているか、または混在利用かを確認し、ノウハウを取得したかったのですが…😥。

LL API利用STM32G0xテンプレートとHAL API利用STM32Fxテンプレート

弊社は、LL API利用STM32G0x専用テンプレートと、HAL API利用STM32Fx汎用テンプレートの2種類を、それぞれ販売中です(テンプレートは同一、テンプレートを使うAPIのみが異なる)。

STM32汎用MCUラインナップ
STM32汎用MCUラインナップ(出典:STM32 Mainsterm MCUsに加筆)

もちろん、STM32G0でもHAL APIを利用することは可能です(STM32G0x専用テンプレートにもHAL API使用例添付)。LL API利用ソフトウェアは、性能を引き出す代償に対象MCU専用になります。

HAL APIとLL APIの混在は避けた方が無難で、STM32G0はLL API専用でテンプレート化しました。添付資料も、LL APIを中心に解説しています。STM32Fxテンプレート添付資料は、HAL API中心の解説です。

両テンプレートをご購入頂ければ、LL/HAL双方のAPI差が具体的に理解できます。開発するアプリケーション要求性能や発展性に応じて、LL APIかHAL APIかの選択判断も可能になります。
※両テンプレート同時購入時は、2個目テンプレート50%OFF適用で、1500円(税込)です😀。

FYI:日本語コメント文字化け継続

STMマイコン開発環境にソースコード日本語コメントの文字化けが発生中であることを、昨年11月に投稿しました。この文字化け発生のSTM32CubeIDE v1.1.0/CubeMX v5.4.0開発環境が、STM32CubeIDE v1.2.0STM32CubeMX v5.5.0に更新されました。

更新後のSTM32CubeIDE v1.2.0/CubeMX v5.5.0でも、旧版同様に文字化けします。
一方、SW4STM32では、STM32CubeMX v5.5.0更新後も日本語コメント文字が正常表示されます。

他社の最新版EclipseベースIDE、NXPのMCUXpresso IDE v11.1.0や、CypressのPSoC Creator 4.2では、ソースコードText Font変更をしなくても文字化けはありませんので、STM特有問題だと思います。

ワールドワイドでの日本相対位置低下、今年から始まる小学校英語教育…、日本ものつくりは、英語必須になるかもしれません。

NXPマイコン開発環境更新

2019年12月20日、NXPマイコン統合開発環境のMCUXpresso IDE v11.1、SDK v2.7、Config Tools v7.0への更新ニュースが届きました。筆者は、Windows 10 1909トラブル真っ最中でしたので、更新対応が遅れ今日に至ります。本稿は、この最新開発環境更新方法と、Secure Provisioning Toolsを簡単に説明します。

NXPマイコン最新開発環境への更新方法

MCUXpresso IDEやSDKの最新版への更新方法は、前版更新方法の投稿:MCUXpresso IDE v11をLPC845 Breakout boardで試すと同じです。

MCUXpresso 4 Tools
NXPマイコン統合開発環境のMCUXpresso 4 Tools

更新方法をまとめると、

  1. MCUXpresso IDE v11.1をダウンロードしインストール(前版v11.0インストール先/ワークスペースともに別になるので、新旧IDEが共存可能)。旧版は、手動にて削除。アクティベーション手順不要。
  2. SDK Builderで旧SDK v2.6を最新版へ更新(旧SDK構築情報はNXPサイトに保存済みなので、ログインで最新版v2.7へ簡単に再構築できる)。
  3. Config Toolsは、他ツールに比べ改版数が大きい(v7.0)のですが、筆者の対象マイコン(LPCXpresso54114/812MAX/824MAX/845Breakout)では、SDKにCFGが含まれており、単独で更新することはありません。
  4. IDE/SDK/CFGの3ツールに加え、新に4番目のSEC:MCUXpresso Secure Provisioning Tool v1が加わりました。が、このSECツールは、Cortex-M7コアを用いるi.MX RT10xxクロスオーバープロセッサ用です。インストールや更新も、筆者対象マイコンでは不要です。

MCUXpresso IDE v11.1更新内容

IDE起動後、最初に表示されるWelcomeページが変わりました。

MCUXpresso IDE v11.1 Welcome Page
MCUXpresso IDE v11.1 Welcome Page

What’s Newアイコンクリックで詳細な更新内容が分かります。

目立つ更新内容をピックアップすると、ベースIDEのEclipse 4.12.0.v201906 / CDT9.8.1とGCC8-2019q3-updateへの対応に加え、ダークテーマ表示が可能になりました。

ダークテーマ利用は、Window>Preference>General>Appearance>ThemeでMCUXpresso Darkを選択し、Apply and Closeをクリックします。Dark Themeは、日本語コメントが読みづらく筆者の好みではありません。Restore Defaultsクリックで元に戻りますので、試してみてください。

マイコンテンプレートラインナップ

前稿の2020年1月のCypress PSoC 4000S/4100S/4100PSテンプレート発売で、弊社マイコンテンプレートの販売ラインナップは、下図に示すように全部で8種類(黄色)となりました。

マイコンテンプレートラインナップ2020/01
マイコンテンプレートラインナップ2020/01

2020年は、ARM Cortex-M0/M0+/M3コアに加え、Cortex-M4コアもテンプレート守備範囲にしたいと考えています。図の5MCUベンダー中、Eclipse IDEベースの最も標準的で、かつ使い易い開発環境を提供するNXPマイコン開発環境が今回更新されたのは、この構想に好都合でした。

Cortex-M7コアのi.MX RT10xxでは、初めからRTOSや高度セキュリティ対策が必須だと思います。Cortex-M4マイコンも高度なセキュリティは必要だと思いますので、SECツールの対応状況も今後注意します。

PSoC 4000S/4100S/4100PSテンプレート発売

HappyTechサイトへCypress PSoC 4000S/4100S/4100PSテンプレートページを追加しました。
PSoC 4000S/4100S/4100PSマイコンの習得、業界標準のCypress第4世代CapSenseコンポーネントを使ったタッチユーザインタフェース(UI)開発に最適なマイコンテンプレート(1,000円税込)の発売開始です。

PSoC 4000S搭載CY8CKIT-145評価ボードで動作中のCapSenseテンプレート
PSoC 4000S搭載CY8CKIT-145評価ボードで動作中のCapSenseテンプレート

PSoC 4000S/4100S/4100PSテンプレート説明資料、ダウンロード可能

PSoC 4000S/4100S/4100PSテンプレート付属説明資料の最初の3ページが、サイトよりダウンロード可能です。

PSoCプログラミングのポイントであるコンポーネント単位ソフトウェア開発を、Cypress第4世代CapSenseコンポーネントを例に具体的に学べます。

Cypress PSoCマイコンの関連テンプレートは、2016年発売:PSoC 4/PSoC 4 BLE/PRoCテンプレートに続いて第2弾目です。前回テンプレートは、一般的なMCU開発で汎用的に使うコンポーネント:液晶表示やADC、SW、BLEなどを使いテンプレート化しました。

このテンプレートご購入者様からは、どうすれば各コンポーネント情報が得られるか、コンポーネントバージョンアップへの対処方法、開発したソフトウェアの他PSoCデバイスへ移植方法など、PSoCプログラミングに関する多くのご質問やご意見を頂きました。

CapSenseコンポーネントに絞ってテンプレート化

そこで、第2弾のPSoC 4000S/4100S/4100PSテンプレートでは、評価ボードへ追加するコンポーネントをCapSenseコンポーネントのみに絞り、よりPSoCプログラミングの要点を掴み易いようにテンプレート化しました。

つまり、CapSenseコンポーネントを利用したテンプレート応用例のPSoC 4000S評価ボードを、別のPSoCデバイス:PSoC 4100S/4100PS評価ボードへ移植する手法を使って、コンポーネント単位のPSoCソフトウェア開発要点を説明しています。
※既に第1弾のPSoC 4/PSoC 4 BLE/PRoCテンプレートをお持ちの方でも、テンプレート本体以外は被る(内容重複)ことが少なく、別視点からのCypress PSoCプログラミングの特徴をご理解頂けると思います。

第4世代CapSenseコンポーネント

PSoC 4000S/4100S/4100PSファミリ内蔵の第4世代CapSenseコンポーネントは、スマホで普及したタッチユーザインタフェース(UI)の業界標準技術です。本テンプレートでCapSenseコンポーネント利用方法を習得すれば、従来の簡単な操作パネルを、より洗練されたタッチHMI:Human Machine Interfaceで実現し、他社差別化ができます。

PSoC 4000S/4100S/4100PSテンプレートで用いた評価ボードは、トランジスタ技術2019年5月号付録基板も含まれます。トラ技5月号記事は、開発環境PSoC CreatorやPSoCデバイスの特徴は良く分かりますが、記事ソースコードがダウンロードできず、実際に付録基板を簡単には動作させられないのが残念です。

本テンプレートをご利用頂ければ、トラ技付録基板でも基板上のLED点滅動作を利用したシンプルなテンプレート応用例や、CapSense動作がご理解可能です。
※トラ技付録基板に、弊社推薦評価ボード :CY8CKIT-145のCapSenseボード部分(CapSenseテンプレート動作時)とKitProgインタフェース(シンプル/CapSenseテンプレート動作時)を別途配線することで動作します。配線は、下図のようなスルーホール間接続のジャンパーワイヤが簡単です(確かハンズマンで購入しました)。

トラ技2019年5月号付録PSoC 4100S基板で動作中のシンプルテンプレートとスルーホール間接続ジャンパーワイヤ
トラ技2019年5月号付録PSoC 4100S基板で動作中のシンプルテンプレートとスルーホール間接続ジャンパーワイヤ

ブログの関連投稿検索方法

ブログ右上の検索窓に「CapSense」か「PSoC 4000S」入力または、カテゴリでPSoC/PRoCマイコンを選択すれば、PSoC 4000S/4100S/4100PSテンプレートに関するブログの関連投稿が一覧で得られます。テンプレート説明資料と、合わせてご覧いただければ、PSoC 4000S/4100S/4100PS マイコンやCapSenseコンポーネントがより解り易くなると思います。

PSoC 4000S/4100S/4100PSテンプレートのご購入をお待ちしております。

モダンPCとPINコード

本稿が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の最重要機能は、セキュリティだと思います。

OS最重要機能はセキュリティ(出典:Pixabay)
OS最重要機能はセキュリティ(出典:Pixabay)

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トラブル回復録

年末年始の忙しい時に限って自作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クリーンインストール作業時間

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

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

  1. セキュリティソフト、ブラウザ、FFFTP、圧縮解凍などOS必須ツールインストール:1時間
  2. Officeアプリケーションインストールと更新プログラム適用:3時間
  3. ベンダMCU開発ツールインストール:1時間
  4. ユーザデータ復活: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のトラブルや回復方法も調べたいです。

ARM MCU変化の背景

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

現在のARM MCUモデル

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

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

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

ARM MCUの新しい方向性

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

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

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

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

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

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

2.RTOS普及

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

3.セキュリティ対応

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

4.RISC-Vとの競合

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

ARM MCU変化背景

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

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

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

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

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

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

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