FreeRTOS/Azure RTOSソフトウェア開発手法

ルネサス公式センササンプルコードを使って、ベアメタル処理を起点とするRTOS(FreeRTOS/Azure RTOS)ソフトウェア開発手法を説明します。

筆者にしては、長い投稿です。要旨は、「ベアメタル処理+RTOS処理待ち=RTOS処理」です。

ベアメタル処理とFreeRTOSタスク処理並列多重
ベアメタル処理とFreeRTOSタスク処理並列多重

センササンプルコード

  1. FS2012 Sample application – Sample Code
  2. HS300x Sample application – Sample Code
  3. ZMOD4xxx Sample application – Sample Code

説明に用いたセンササンプルコードが、上記3種類です。ダウンロードには、ルネサスのログインが必要です。同一動作のベアメタル/FreeRTOS/Azure RTOS、3個のe2studioプロジェクトが同胞されています。動作MCUは、ルネサス)RA/RX/RE/RL78ファミリです。

サンプルコードマニュアルだけは、下記からログイン不要でダウンロードできます。本稿は、これらマニュアル情報だけで読める工夫をしました。

  1. FS2012 Sample application
  2. HS300x Sample application
  3. ZMOD4xxx Sample application

FS2012がガスフローセンサ、HS300xが湿度・温度センサ、ZMOD4xxxが高性能ガスセンサです。この順番で、サンプルコードが複雑になります。

そこで、焦点を、一番簡単なFS2012サンプルコード、動作MCUをRA6M4(Cortex-M33/200MHz/1MB Flash/256KB RAM)に絞って説明します。他サンプル/MCUでも同様の結果が得られます。

なお、3サンプルコードは、ベアメタルからRTOS開発へステップアップする時にも適したコードです。

センサとMCU間接続:I2C

PMODインタフェースによるセンサボードとMCU接続
PMODインタフェースによるセンサボードとMCU接続

センサとMCU間は、サンプルコード全てPMOD経由のI2C接続です。従って、I2C接続センサのIoT MCU制御例としても応用可能です。FreeRTOSとAzure RTOS、両方に対応した点が便利です。

PMODとは、米Digilent社規定のオープンインタフェース規格です。図示のように、複数センサボードを、レゴブロックのようにMCUへ追加接続できる特徴があります。

ベアメタルとFreeRTOS/Azure RTOSメモリ量

FS2012サンプルコードマニュアルより抜粋した使用メモリ量比較です。

ベアメタル FreeRTOS Azure RTOS
Flash 1065 bytes 1374 bytes 1342 bytes
RAM 73 bytes 249 bytes 246 bytes

RTOSは、ベアメタル比1.3倍のFlash使用量、3.4倍のRAM使用量です。但し、上表にRTOSタスク/スレッドのスタックメモリ量は含みません。

Flash/RAM使用量が増加しますが、RTOS開発ソフトウェア流用性が高まるメリットがあります。これら増加分は、ベアメタル単体処理からRTOSマルチタスク/スレッド処理のオーバーヘッドに相当すると考えて良いでしょう。

マルチタスク/スレッド以外にも、RTOS開発には、クラウド接続/セキュリティ/OTA(Over The Air)処理などのオーバーヘッドが別途必要です。

これら処理のため、IoT MCUは、ベアメタル比、Flash/RAM量の十分な余裕と高速動作が必要になります。

FS2012センサAPI使用方法

FS2012フローセンサの使用APIとその利用手順です。一般的なセンサでも同様で、特に変わった点はありません。

FS2012 APIと利用手順
FS2012 APIと利用手順

ベアメタル処理フロー

RTOS開発の起点となるベアメタル開発の処理フローです。

FS2012のベアメタル処理フロー
FS2012のベアメタル処理フロー

初期設定で、I2Cとセンサを初期化し、無限ループ内で、センサデータ取得と取得データの演算を繰返します。センサデータの連続取得に409.6ms遅延時間が必要であることも判ります。センサデータ取得完了は、センサ割込みを使って検出しています。

このベアメタル処理フローも、特に変わった点はありません。

RTOS処理フロー

ベアメタルと異なる処理だけを橙色抜粋したFreeRTOS処理フローです。

ベアメタル処理とRTOS処理のフロー差分
ベアメタル処理とRTOS処理のフロー差分

差分は、RTOS遅延:vTaskDealy()/tx_thread_sleep()で409.6msと1msが加わる点、vTaskDelete()/tx_thread_delete()でタスク削除する点です。

また、センサ制御本体は、タスク/スレッド記述へ変更し、セマフォにより別タスク/スレッドとの排他制御を行います。

1ms遅延は、別タスク/スレッド切替えに必要です(関連投稿のコチラ、6章コンテキストスイッチ参照)。FS2012サンプルは、タスク/スレッド数が1個なので切替え不要です。

しかし、例えば、HS300xセンサボードを、FS2012センサボードへレゴブロック様式で追加した時は、FS2012センサとHS300xセンサの2タスク/スレッドを、この1msスリープでRTOSが切替えます。

FS2012センサは、ベアメタル処理フローで示したデータ取得間隔に409.6ms遅延処理が必要です。この遅延中に、HS300xセンサのデータ取得を行えば、両タスク/スレッドの効率的な並列多重ができ、これにセマフォ排他制御を用います。

※RTOS遅延処理は、本稿最後の補足説明参照。RTOSメリットが具体的に判ります。

この切替え処理が、本稿最初の図で示したRTOS処理待ちに相当します。その他のRTOS処理フローは、ベアメタル処理と同じです。

つまり、RTOS処理とは、単体のベアメタル処理へ、RTOS処理待ちを加え、複数のベアメタル処理を並列処理化したものです。

数式的に表すと、「ベアメタル処理+RTOS処理待ち=RTOS処理」です。

RTOS(FreeRTOS/Azure RTOS)ソフトウェア開発手法

IoT MCU開発者スキルの階層構造
IoT MCU開発者スキルの階層構造

ベアメタル処理を、効率的に複数並列動作させるのがRTOSの目的です。

この目的のため、優先制御や排他、同期制御などの多くの機能がRTOSに備わっています。RTOSの対象は、個々のベアメタル処理です。つまり、ベアメタル開発スキルを起点・基盤としてその上層にRTOS機能がある訳です。

RTOS習得時、多くの機能に目移りします。しかし、本稿最初の図に示したように、RTOSは、複数ベアメタル処理(タスク/スレッド)を、優先度や排他・同期条件に応じて切替え並列多重化します。

逆に、ベアメタル側からRTOSを観ると、セマフォ/Queueなど「RTOSによる処理待ち」がベアメタル無限ループ内に入っただけに見えます。「待ち/解除の制御は、RTOS」が行います。待ち処理の種類が、セマフォ/Queue/イベントフラグ……など様々でも、「ベアメタル側からは単なる待ち」です。

筆者が、RTOS開発の起点はベアメタル処理、とした理由が上記です。

つまり、ベアメタル起点RTOSソフトウェア開発手順は、

1:単体ベアメタル処理開発。単体デバッグ後、タスク/スレッド化。
2:タスク/スレッド無限ループ内へ、RTOS処理待ち挿入。
3:複数タスク/スレッド優先度を検討し、RTOS結合デバッグ。

以上で、RTOSソフトウェア開発ができます。

処理自体は、1でデバッグ済みです。2以降は、効率的RTOS処理待ち挿入と、複数タスク/スレッド間の優先度検討が、主なデバッグ内容です。複数タスク/スレッドが想定通り並列動作すれば、第1段階のRTOSソフトウェア開発は完了です。

スタックメモリ調整やより効率的な待ち処理などのチューニングは、3以降で行います。

RTOS待ち処理は、セマフォやQueueの利用頻度が高いため、RTOS習得もセマフォ/Queueを手始めに、より高度な待ち処理機能(イベントフラグなど)へと順次ステップアップしていけば良いでしょう。

ベアメタル開発経験者が感じるRTOS障壁

ベアメタルは、開発者自身が全ての制御を行います。ところが、RTOS開発では、ソースコード内に、自分以外の第3者:RTOSが制御する部分が混在します。ここが、ベアメタル開発経験者の最初のRTOS違和感、RTOS障壁です。

前章の手法は、1でベアメタル処理を完成すれば、2以降は、RTOS処理のデバッグに集中できます。つまり、既に持っているベアメタルスキルと新しいRTOSスキルを分離できます。これで、最初に感じたRTOS障壁は小さくなります。

また、RTOS障壁は、IoT MCUクラウド接続時の通信処理やセキュリティ処理時に、MCUベアメタル開発経験者に大きく見えます。しかし、これらの処理は、決まった手順で当該ライブラリやAPIを順番に利用すれば良く、一度手順を理解すれば、本当のRTOS障壁にはなりません。

クラウド接続やセキュリティ処理サンプルコードを入手し、各API利用手順の理解後は、これら該当処理の丸ごと流用でも十分に役立ちます。

まとめ:RTOSソフトウェア開発手法

IoT MCU RTOSソフトウェア開発の3分野
IoT MCU RTOSソフトウェア開発の3分野

IoT MCUは、クラウド接続のためRTOS開発になります。IoT MCU RTOS開発は、データ収集、クラウド接続、エッジAIやIoTセキュリティなど、大別すると3分野に及びます(関連投稿:世界最大情報通信技術(ICT)サービス輸出国、アイルランドIoT事情)。

本稿は、センササンプルコードを使い、ベアメタルスキル起点・基盤としたデータ収集分野のRTOSソフトウェア開発手法を説明しました。

1:単体ベアメタル処理開発。単体デバッグ後、タスク/スレッド化。
2:タスク/スレッド無限ループ内へ、RTOS処理待ち挿入。
3:複数タスク/スレッド優先度を検討し、RTOS結合デバッグ。

数式的に示すと、「ベアメタル処理+RTOS処理待ち=RTOS処理」です。

クラウド接続とエッジAI/IoTセキュリティ分野は、決まった手順のRTOSライブラリ活用などが主な開発内容です。従って、この分野は、差別化の努力は不要です。

IoT MCU RTOS開発で、他社差別化できるデータ収集RTOSソフトウェア開発の手法を説明しました。

RAベアメタルテンプレート発売中

RAベアメタルテンプレート概要
RAベアメタルテンプレート概要

2022年5月にRAベアメタルテンプレート(1000円税込)を発売しました。本稿説明のRTOS(FreeRTOS/Azure RTOS)ソフトウェア開発には、ベアメタルスキルが必須です。

RAベアメタルテンプレートにより、開発ツール:FSP(Flexible Software Package)やe2studioの使い方、豊富なベアメタルサンプルコードを活用したベアメタル開発スキルが効率的に得られます。ご購入は、コチラから。

RA版RTOSテンプレート(仮名)は、検討中です。

NXP版FreeRTOSテンプレート発売中

NXP版FreeRTOSテンプレートも発売中です。また、本年度中には、ST版Azure RTOSテンプレートも、開発・発売予定です。

弊社ブログは、RTOS関連も多数掲載済みです。ブログ検索窓に、FreeRTOSやAzure RTOSなどのキーワードを入力すると、関連投稿がピックアップされます。

補足説明:RTOS遅延処理

RTOS遅延処理のvTaskDealy(409.6ms)/tx_thread_sleep(409.6ms)は、他タスク/スレッドの処理有無に関わらず409.6msの遅延時間を生成します。これは、ベアメタル開発者にとっては、夢のようなRTOS APIです。

このようにRTOSは、開発ソフトウェアの独立性・流用性を高めるマルチタスク/スレッド動作を実現し、ベアメタルの補完機能を提供します。

つまり、ベアメタル開発中に、他処理の影響を受けるので開発が難しいと思う部分(例えば、上記遅延処理など)があれば、RTOSのAPI中に解が見つかる可能性があります。

あとがき

長い投稿にお付き合いいただき、ありがとうございました。

ベアメタル開発経験者がRTOS習得・開発を目指す時、サンプルコード以外の情報が多すぎ、途中でくじけそうになります。本稿は、サンプルコードとベアメタルスキルを活かしRTOS開発へステップアップする手法を示しました。RTOSでも、基本はベアメタルスキルです。

RTOSサンプルコードが豊富にあれば、必要情報の絞り込み、RTOSスキル向上も容易です。掲載RTOSサンプルコードは、非常に貴重だと思いましたので、RTOSソフトウェア開発手法としてまとめました。

BitLockerトラブル

Windows Update KB5012170の失敗でBitLocker 48桁回復キー入力が必要となります。入力できない場合、PCアクセス不能となるトラブルが発生します。

2022年8月9日リリースのセキュリティ更新プログラム:KB5012170不具合が原因で、Windows 11 21H1、Windows 10 21H1などが対象です。0x800f0922エラー発生時には、ご注意ください。

BitLocker目的

Windows Update失敗でBitLockerトラブル発生
Windows Update失敗でBitLockerトラブル発生

BitLockerは、PCのハードディスク/USBメモリなどのデータを暗号化します。第三者によるデータ不正アクセス検出時、48桁の回復キー入力が無ければ、PCアクセス不能とする機能です。

BitLockerの目的は、ノートPC紛失時などに、内蔵データ流出や不正コピーを防ぐことです。

Win11では、デフォルトでBitLocker有効に設定済みです。BitLockerは、TPMを前提条件としています。BitLockerにより、10%未満の処理オーバーヘッドが生じます。

48桁回復キー入力に間違いがある場合も、PCアクセス不可能となるでしょう。パスワード3回入力失敗時と同じです。48桁キー、間違いなく入力できる自信、ありますか?

セキュリティとセーフティ

セキュリティとセーフティの違い(出展:STマイクロ)
セキュリティとセーフティの違い(出展:STマイクロ)

Security(セキュリティ)もSafety(セーフティ)、日本語ではどちらも「安全」と訳されます。しかし、本質的に両者は異なります。

STマイクロの資料P4に、解りやすい説明がありましたので、抜粋します。英語では両者は区別します。

・セキュリティ:外部からの攻撃・脅威に対し、デバイスやハードウェア侵害/ハッキングの防衛対策
・セーフティ:デバイスやソフトウェア誤動作・故障などへの障害対策

MCU開発者には、タンパ検出がセキュリティ、フェールセーフ設計がセーフティと言えば判り易いと思います。

セキュリティ誤検出

セキュリティの誤検出
セキュリティの誤検出

今回のBitLockerトラブルは、セキュリティ更新プログラム:KB5012170不具合がそもそもの原因です。

しかし、MicrosoftのBitLocker回復ガイドを見ると、この不具合以外にも、回復キー入力モードになる様々なイベントがあることが判ります。

当然の事ながら、各イベントに誤検出のリスクもあります。セキュティには、誤検出が避けられません。たとえ誤検出であっても、回復キー入力がPC正常復帰に必要となります。

10%未満とはいえ、BitLockerによるPC「オーバーヘッド増加」対「誤検出リスク」、これらを天秤にかける必要があるでしょう。

ノートPC以外の個人占有デスクトップPCなら、BitLocker無効でもOKだと思います。PC盗難には無力ですが…。

IoT MCUクラウド接続

IoT MCUをクラウド接続する際にも、デバイスのUUID(Universally Unique Identifier)や、クラウド接続を許可するやたらに長いデバイス証明書、秘密/公開鍵をMCU Flashへ書込み、それらをクラウドへ送信する必要があります。

これは、IoT MCUのクラウド接続手続きで、通常、初回接続時のみ入力すれば完了です。

それでもクラウド側の何らかのトラブル発生時、または、IoT MCUソフトウェア変更時など、鍵の再入力を求められる可能性はあります。

はたして、この再入力は、誰(顧客/開発側)が行うのでしょうか?

量子技術が公開鍵暗号方式を破る?

米国土安全保障省サイバーセキュリティ・インフラストラクチャセキュリティ庁
米国土安全保障省サイバーセキュリティインフラストラクチャセキュリティ庁

CISA(米国土安全保障省サイバーセキュリティインフラセキュリティ庁)は、今後10年間の量子コンピューティング進歩により、現状の公開鍵暗号方式が破られる可能性を指摘しています(2022年8月30日@IT記事)。

2024年に根本対策としての新しい量子暗号規格の発表があるそうです。現状対策は、鍵を長くすることでしょうか?

まとめ:秘密鍵保存と間違わない再入力

現状の公開鍵方式でセキュリティを維持するには、英大文字/小文字/数字/空白文字/記号から成る長い秘密/公開鍵の保存、入力が必要です。量子コンピューティングにより、キー長は、更に増える可能性もあります。

問題は、長い鍵の保存方法、誤検出などの鍵再入力時に間違わずに入力できるかです。コピー&ペーストが使えればOKですが、紙を見ながら入力は、可能だとしてもミスを招きます。

IoT MCUのようにクラウド接続時に最初1回のみ入力するとしても、誰が、どのイベントで、どのように間違いなく入力できる鍵やデバイス証明書などの機密情報保存方法について、顧客、開発側双方で検討しておく必要があります。

また、顧客は、IoT MCUセキュリティオーバーヘッド量(PCは10%未満)を求めると思います。元々非力なIoT MCUのセキュリティ対コストは、重要事項です。開発側も把握したいパラメタです。

関連投稿

・公開鍵と秘密鍵の役割が判る、組込み開発基本のキ(暗号技術の仕組み

・Windows 11非対応PCのBitLocker
弊社Win11 TPM 2.0非対応PCは、BitLocker未使用です。本稿BitLockerトラブルとは無縁でした。ノートPC持出しもCOVID-19で激減、新規購入Win11ノートPC BitLockerも検討中です。持出し時にのみBitLocker設定も可能ですが、ディスク暗号化処理に結構時間が掛かります。

・今秋Win11 22H2は、大型更新

Windows 11 22H2大型更新

現在のWindows 11 21H2 OSビルド番号は、22000。今秋配布予定Win11 22H2の番号は、22621.xxx。22000番から22621番台へと差分が大きいのは、更新内容が新機能追加などを含む大型更新を示します。

OS ビルド番号

Windows 11(左)と10(右)のOSビルド番号
Windows 11(左)と10(右)のOSビルド番号

Windowsは、エディション、バージョン、OSビルド番号で製品型式を示します。例えば、現製品のWin11/10の仕様が上図です。エディションとバージョンが、一般ユーザに馴染みがあります。

OSビルド番号は、開発者向けの型式で、Win11は、22000番台、Win10は、19000番台のビルド番号で両者を区別します。小数点以下は、リビジョン番号です。同一エディション/バージョン内の軽微な不具合修正、改訂を示しますので、本稿は無視します。

さて、今秋配布の製品リリース前プレビュー段階(Release Preview Channel)のWin11/10ビルド番号は、Win11:22621、Win10:19045です。

Win10が、現製品の19044から19045への僅か1増加に対し、Win11は、22000から22621と増分が大きく、多くの機能変更、修正などが現製品に加わったことが判ります。

このビルド番号差から、今秋のWin11 22H2は、「大型更新」と判ります。

Windows 10新規開発停止

Win10は、2025年10月にサポート終了します。過去のWin10ビルド番号変遷を見ると、2020年春の大型更新以降、マイナ更新を3回繰返していることが判ります。

2019年秋 バージョン1909:ビルド18363(2019年以前は省略)
2020年春 バージョン2004:ビルド19041(大型更新:ビルド差分600以上)
2020年秋 バージョン20H2:ビルド19042(マイナ更新:ビルド差分1)
2021年春 バージョン21H1:ビルド19043(マイナ更新)
2021年秋 バージョン21H2:ビルド19044(マイナ更新)

Windows 10のビルド変遷
Windows 10のビルド変遷

これは、Win10が完成済みを意味する訳では無く、次期Win11へMicrosoftが開発を移行した結果だと考えられます。Win10とWin11は、同じOSコアです。最後のWindowsがWin10を撤回し、新しいWin11リリースが2021年秋であることとも符合します。
※ “新しい” と言ってもOSコアはWin10なので、急場凌ぎの感がありますが…。

つまり、ビルド番号変遷によると、Win10へ機能追加などの新規開発は、事実上2020年頃から停止したことが判ります。

そして、今秋のWin10 22H2ビルドも19045です。更新失敗リスクが少ない「マイナ更新」を繰返し、2025年のサポート終了を迎えるのがシナリオのようです。

Windows 12リリース

Microsoftは、3年毎に新Windows開発、2024年頃のWindows 12リリースが見込まれています。

半導体製造技術の進歩により、PCハードウェア、特にノートPC性能向上は著しいものがあります。Intel 12世代モバイルCPUや、AMD 6000番以降のCPUに顕著です。

COVID-19によるリモートアクセス急増やメタバースへの対応だろうと推測します。ハードウェア高性能化に伴い、当然の事ながらPCソフトウェアも、OSコアの抜本的刷新や更なるセキュリティ強化などが求められます。

2019年のCOVID-19は、PCにも多大な影響を与えたと言えるでしょう。

ビジネスPCは、3年更新が理想的と言われます。3年周期の新Windows開発も、今は納得できます。

Windows 11 22H2大型更新

Win10とOSコア共通のWin11開発着手が、COVID-19後の2020年頃だとすると、新Win11リリースに3年弱、今秋のWin11 22H2が初の大型更新です(※9月20日、22H2リリース情報もあり)。

新Win11リリース時22000のビルド番号が、22621になったことからも、多くの機能追加、変更、修正が加わったと推測できます(詳細はWindows 11 22H2新機能参照、日経BP、2022/07/19)。

Windows 11のビルド変遷
Windows 11のビルド変遷

但し、大型更新には、更新失敗やトラブルが付き物です。

MicrosoftによるWin11 22H2配布を待つか、あるいは、ユーザ手動による更新実行か、いずれにしても大型更新直前にOSバックアップを実行し、トラブル事前準備は忘れずに行いましょう!

まとめ:ビルド番号から見るWindowsとCOVID-19

ビルド番号差から今秋Windows 11 22H2が大型更新であること、Windows 10は、2020年頃から新規開発を停止していること、その代替の新Windows 11 21H2開発に約3年を要したと推測しました。

2019年のCOVID-19が、Microsoft Windows 10の最後Windows宣言撤回や2024年Windows 12リリース、3年周期の新Windows開発、ノートPCハードウェアの急激な性能向上などへ影響を与えたと推測しました。

関連投稿

・Win11/10の大型更新に役立つRufus 3.20の使い方は、コチラ
・アップグレード要件未達Win10のWin11アップグレード方法は、コチラ
・要件未達Win11のアップグレード後3か月状況は、コチラ
・ユーザ手動によるWin10大型更新方法は、コチラ

1GHz 64ビットMPU量産開始

1GHz/64ビットMPU:RZ/A3UL評価ボード構成
1GHz/64ビットMPU:RZ/A3UL評価ボード構成

2022年8月ルネサスは、最大動作周波数1GHz 64ビットMPU、RZ/A3ULの量産を始めました。本プログメインカテゴリのMCU(マイコン)では無く、比較対称のMPU(マイクロプロセッサ)のことです。

より高度なHMI(Human Machine Interface)を実現するためRTOS(FreeRTOS/Azure RTOS)採用、RISC-Vコア搭載機RZ/Fiveとも互換性を持たせる作りです。肥大化するソフトウェア資産流用、活用に重点を置いています。

ところで、2022年8月9日ITmediaのPCとは何だったのか記事の最初のページには、PC(CPU)が16→32→64ビットへと変わった41年の歴史が、23回連載記事タイトルからも判ります(詳細は、連載記事参照)。

本稿で言いたいのは、MCU(マイコン)も近い将来GHzクラス高速化へ向かうだろうと言うことです。

MCU → IoT MCU

未だに8/16ビット機も現役のMCUは、CPU程の紆余曲折や派手さはありませんが、着実に高速・大容量化が進行中です。制御規模が小さく、スタンドアロン処理も可能なMCUなので8/16ビット機でも現役です。

しかし、時代はIoT、全ての制御対象がネットワークに繋がります。OTA(Over The Air)によりセキュリティ更新や、制御ソフトウェア変更もIoT MCUでは可能です。これら処理は、セキュリティライブラリや決まった更新手順で実施されます。

つまり、プリミティブなMCU制御から、よりアプリケーション寄り、場合によってはRTOS前提のIoT MCU制御へ変わらざるを得ない状況になりつつあります。自力でこれらを開発する猛者もいるでしょう。しかし、これらは、本来注力すべき開発差別化部分ではありません。

MCUハードウェア/ソフトウェアともに、市場獲得に向けて他社差別化を狙う部分と、IoTクラウド接続達成部分を、コストパフォーマンス高く共立する、これがIoT MCUの要件です。

CPU/MPU製造技術やソフトウェアのMCU転用は、過去、上記要件の解となってきました。大容量Flash内蔵が前提MCUと、外付けRAM前提CPU/MPUのハードウェア差はありますが、その転用速度は、今後更に早まると思います。

高度なHMIを体験すると元に戻れないように、MCU+クラウド→IoT MCUを顧客が体験すると、元のスタンドアロンMCUには戻れません。

ドライバ → 個別API → HAL API → マルチタスク

IoT MCUソフトウェア開発の変遷
IoT MCUソフトウェア開発の変遷

MCUソフトウェアも、40年前のドライバ開発、20年前のMCU個別API開発、10年前からはMCU共通HAL(Hardware Abstraction Layer) API開発へと変わりました。MCUソフトウェア資産化も、もはや夢ではありません。

開発部分がアプリケーション層に近づけば近づくほど、オーバーヘッドは増えます。オーバーヘッド増大や各種セキュリティライブラリなどの有効活用、RTOS利用によるマルチタスク開発には、IoT MCUの64ビット化、GHzクラス高速化も必然だと思います。

ビット幅増大は、各種巨大ライブラリ流用のためです。ここは32ビットでも十分かもしれません。しかし、高速化は、オーバーヘッド対策や、場合によってはMPU同程度の高度HMI処理、クラウドエッジでのAI処理など、IoT MCU機能実現には必須です。

製造業経済規模 → 縮小中の日本

我々開発者は、前章のIoT MCUソフトウェア開発の変遷を見ただけでもかなりの大変さ、自助努力が開発に必要であることを実感できます。

しかし、日本は、世界の先進国とは異なります。大変さや努力に対し報われることが期待できません。

日本が先進国で唯一、製造業の経済規模が縮小している国という記事や、労働者不足が、COVID-19のせいではないという記事を読むと、その理由と現状が判ります。

世界第2位から降下中の日本
世界第2位から降下中の日本

諸外国の真似をせよという気はありません。が、このままでは気が付けば、後進国になりかねないのが、今の日本です。

今こそ、日本開発者「個人」で変化に対応すべきです。少しずつでも、IoT MCUへ準備を始めませんか?

弊社NXP版FreeRTOSテンプレートは、FreeRTOSプロジェクトと同じ動作のベアメタルプロジェクトも添付済みです。アプリケーションレベルでRTOSとベアメタルを比較しながら技術習得が可能です。是非、ご活用ください。また、ST版Azure RTOSテンプレートも本年度中には開発予定です。

最後は、宣伝となってしまいました。すいません。

Rufusの使い方

今秋のWindows 10/11大型更新と、WindowsからLinux Mint乗り換え検討時に、役立つ最新版Rufus 3.20の使い方を説明します。

Rufus目的

Rufus目的
Rufus目的

Rufusは、OSのISOイメージファイルをUSBインストールメディアへ変換するツールです。CD/DVDを持たないPCへのOSインストール時に使います。OSは、Windows以外にもLinux Mint、UbuntuやDebianなどにも対応しています。

特にWindowsのUSBインストールメディア作成時、Windows 11 TPM回避アップグレードだけでなく、Windows 10プライバシー回避更新などにも対応した最新版Rufus 3.20が、2022年8月3日リリースされました。

手動Windows 10/11大型更新とLinux Mintブートメディア作成に対し、Rufusだけで幅広く対応可能です。

RufusとMicrosoft公式Media Creation Toolの違い

今秋、Windows 10 22H2とWindows 11 22H2大型更新が予定されています。どちらも、Windows Updateでユーザトラブル状況を把握しつつMicrosoftが、段階的にユーザへ大型更新版を配布します。

このいつ始まるか判らない大型更新開始をただ待つより、Media Creation Toolを使ったユーザ主体の手動大型更新を、本ブログではお勧めしてきました(詳細は、投稿末補足説明1参照)。

Microsoft公式のMedia Creation Toolは、更新版Windows ISOイメージファイルをダウンロードし、USBインストールメディアを作成するツールです。Win10/11毎に対応Media Creation Toolは異なります。ダウンロード後、USBを作成せず旧Windowsへ直接上書きインストールすることも可能です。

一方Rufusも、Windows ISOイメージファイルからUSBインストールメディア作成は、Media Creation Toolと同じです。違いは、Media Creation Toolでは必須のアップグレート要件確認や、ローカルアカウントでのセットアップ、プライバシー設定をスキップし、旧Windows設定を保持したまま更新版をインストールできる点です。

つまり、Win11非対応PCアップグレード後3ヶ月投稿の課題、現行Win11 21H2から22H2更新へのTPM対策としてもRufusが役立つ可能性大です。

RufusのWindows 11大型更新スキップ

RufusのWindows 11大型更新スキップ内容
RufusのWindows 11大型更新スキップ内容

Rufus 3.20のWin11大型更新時にスキップできる内容が、上図4項目です。

Win11非対応Win10を強制アップグレードした時に用いたRufus 3.18は、一番上のセキュアブートとTPM 2.0回避項目のみでした(強制アップグレード方法は、投稿末補足説明2参照)。

この項目に加えRufus 3.20では、データ収集、ローカルアカウント、PC利用地域設定などをスキップする項目が追加されました。

RufusのWindows 10大型更新スキップ

RufusのWindows 10大型更新スキップ内容
RufusのWindows 10大型更新スキップ内容

Win10対応となったRufus 3.20のWin10大型更新スキップ項目です。

前章と比べると、TPM以外の項目がWin10更新でも可能になったことが判ります。各項目をスキップすると、煩わしい大型更新時の入力手間が省け、更新スピードアップになるかもしれません。

Linux Mintブードメディア作成

Rufusは、Windows以外のUSBインストールメディア(=ブートメディア)作成にも使えます。

RufusをLinux Mint 21ブートメディア作成に使い、作成済みUSBメディアからPCを起動すると、Windows載せ替えPC上でMint動作が試せるLive Bootが可能です。

Live Boot動作中は変更保存ができませんが、快適にLinux Mintが動作するかを実PCで評価できます。

Win11アップグレートができないWin10 PC代替OS候補として、Mintを検討する場合に便利です。

まとめ

Windows 10/11大型更新時、さらに、WindowsからMint乗り換え検討時に便利なUSBインストールメディア(=ブートメディア)作成ツール:Rufusの使い方を説明しました。

RufusをWindows大型更新に使うと、Microsoft公式Media Creation Toolで行われるWindowsアップグレート要件確認や各種設定をスキップした更新が可能です。

RufusをLinux Mintブートメディア作成に使うと、実機でMint操作を試すLive Bootが可能です。

Rufusだけで弊社使用中PCのOS更新/乗り換え検討に対応する幅広さ、Windows大型更新要件回避やローカルアカウント更新などユーザニーズを満たす機能を持っています。

最後に、いずれの場合でも失敗やトラブルは付き物です。最悪の場合でも、リカバリツールなどでトラブル前に回復できる事前準備は忘れないでください。

さいごに:WindowsかMintか

WindowsかMintか
WindowsかMintか

2024年Windows 12登場の噂もある状況で、次期PC OSがWindowsかLinux Mintかを評価しています。Rufusは、この検討中に便利、「今が旬なツール」です。

Win11タスクバー下固定は好みませんが、これ以外はWin10比、結構気に入った新GUIもあります。

次期OSにMintを採用しても、圧倒的大多数のWinユーザに弊社テンプレートを購入してもらうには、テンプレートのWin動作確認は必須でしょう。弊社としては、MintとWin混在環境は避けたいです。

盆休み中に集中検討しますがノートPC新規調達なども考慮すると、最適解はWin11になりそうです。

補足説明1:手動Win10大型更新方法

・Win10 21H2手動大型更新方法は、コチラ

補足説明2:Win11非対応Win10強制アップグレード方法

・TPM 2.0要件未達Win10を強制的にWin11へアップグレードする方法は、コチラ
・強制アップグレードPCの3か月後の状況は、コチラ

補足説明3:Windows代替OSとしてLinux Mintお勧め理由

・Mintはなぜ良いのかは、コチラ

日本とアイルランドのIoT

北海道とアイルランド比較(出展:たび日和、アイルランドの面積ってどのぐらい?)
北海道とアイルランド比較(出展:たび日和、アイルランドの面積ってどのぐらい?)

2022年7月29日ZDNet Japan掲載、アイルランドIoT事情についての記事(前編後編)と、2022年8月1日MONOist掲載、調査結果からみる日本製造業将来と期待の記事を紹介、両国のIoT開発現状を比較します。

アイルランド

北海道 アイルランド共和国
面積 8万3,400㎡km 7万300㎡km
人口 530万人 492万人

日本と同じ島国で、面積、人口が北海道より少し小さいアイルランド共和国は、記事によると世界最大の情報通信技術(ICT)サービス輸出国です。

アイルランド国内総生産(GDP)は、世界トップ10にランク(Wikipedia)されます。

アイルランドIoT事情

ごく簡単に記事要旨をまとめます。

アイルランドは、IoTを「データ収集(Collect)」「接続(Connect)」「変換(Transform)」の3カテゴリに分類、さらに3カテゴリをまたぐ形で事業展開する企業をサポート、IoTサービス進化を現実化する研究施設もある。

「IoTビジネスに最適な国」を目指し、行政や大学などの研究機関を整備、世界各国から有力企業とノウハウを集積した結果、2022年経済成長率5.4%、2023年4.4%と予測される高い経済成長に繋がっている。

日本製造業の将来と期待

MONOist日本読者による製造業の将来と期待についてのアンケート結果が、3枚の図にまとめられています。

要旨を簡単にまとめます。

・先が読めないので予想し準備することは不可能。だから、変化に合わせた柔軟性が重要。
・リアル活動制限のコロナ禍、デジタル環境で様々な業務ができることが判明。
・日本製造業将来が明るい/暗い回答はほぼ同数で25%、残り50%はどちらとも言えない。
・AIやロボット、自動運転などの自動車分野、メタバース/ローコード技術に期待。
・日本モノづくりは、世界的に見ると特殊な立ち位置。

最後を除いては、日本に限らずどの国の企業、技術者でもさほど違わないと思います。違いは、日本の国家指針の無さ・見えなさ、変化に対するスピードの遅さだと思います。

海外比遅れる理由(出展:MONOist 15周年記念アンケートP7)
海外比遅れる理由(出展:MONOist 15周年記念アンケートP7)

まとめ:個人レベルは選択と集中

日本とアイルランドのIoT開発現状を比較しました。

関連分野が広く、しかも、各分野の奥行も深いIoTです。日本の開発者個人にとっては、アイルランドのIoT 3カテゴリ分類は、1つの「指針」になると思います。

例えば、IoTエッジMCU開発者ならば、先ずはデータ収集、次に無線/有線の接続、最後にAI向けのエッジデータ変換というように、アイルランドガテゴリに沿った技術区分と優先順位を付けることができます。

漠然とIoTを捉えるより区分と優先順位があれば、より集中、選択してIoT技術を習得できます。しかも、そのカテゴリ分けは、世界最大のIoTサービス提供実績があるアイルランドカテゴリに基づいているので、「世界的モノづくりへ通用」する可能性も高いです。

ガラバゴス技術の多い日本にいると、自身の技術がはたして世界で通用するかの不安は付きものです。

不安払拭のため、時には開発者個々人が、世界(今回はアイルランド)へと視野を広げ、自身の開発領域へフィードバックをかけ、「選択、集中した技術習得」が効果的なIoTだと思います。

Linux Mintはなぜ良いか

Linux Mint 21 CinnamonのGUI拡大図
Linux Mint 21 CinnamonのGUI拡大図

Windows 11へアップグレードできないWindows 10 PCの代替OSに、Linux Mintがなぜ良いかを説明します。また、後半は、選択肢が非常に多い場合の選択方法を示します。

2年前のLinux Mintお勧め理由

2年前、次の2点からMintをお勧めしました。

Linux MintとUbuntu比較から(2020-08-21)
Linux MintとWin10大型更新比較から(2020-09-04)

Win10大型更新は、年2回から1回へ変わるなど投稿内容と現状が合わないものが出てきました。また、最新版Ubuntu 22.04 LTS情報も多く出てきました。

そこで、2年間のMint使用経験から、Windows代替OSとしてMintをお勧めする理由をまとめます。

理由1:Windows 10スペックで快適動作

Win11アップグレード要件を満たさないWin10 PCを、無理やりWin11 21H2にしても問題なし、但し、次期Win11 22H2大型更新できるかが課題、これが前稿の内容でした。

この課題は、11アップグレード要件未達PCを使い続ける限り避けられません。対処療法は、見つけるつもりです。

根本対策は、WindowsからLinux MintへのOS載せ替えです。Mint要求スペックは、Win10よりもかなり低いです。

・64bitプロセサ
・2GB RAM (4GB recommended for a comfortable usage)
・20GB of disk space (100GB recommended)
・1024×768 resolution (on lower resolutions, press ALT to drag windows with the mouse if they don’t fit in the screen)
※出展:次期Mint大型更新ベータ版:Mint 21 Cinnamon Edition – BETA Release仕様より

つまり、Win10動作PCなら、現行のMint 20.3はもちろん、次期Mint 21でも快適に動作します。

理由2:Windows 10/11に近い操作性

「Windowsユーザが親しみ易いLinuxディストリビューション」、これがLinux Mintを使って得た所感です。具体例を示します。

・USBから手軽にインストールでき、お試し利用も可能(日本語環境も同時インストール)
・LibreOffice安定版(Still)やWindowsペイントなどのアクセサリ相当も同時インストール
・ブラウザは、Firefoxが同時インストール
・Windowsと同じGUI操作、スタートメニューやタスクバー位置(モニタ下、左側)も同じ

つまり、お試しインストール直後から、Windowsと殆ど同じ感覚でPC操作ができます。OS乗換を意識せず、Windows操作経験をそのまま活かしたLinux Mint操作ができるのが最大の特徴です。

LibreOfficeが使えれば、資料作成なども直ぐに開始できます。しかも、Mintをインストールする前に、実機で試せます。「MintがWindowsからの移設」を目的の1つとしているからだと思います。

数多いLinuxディストリビューションのベンチマーク

Linux Mintお勧めの理由
Linux Mintお勧めの理由

Linuxディストリビューションには、Mintの他にもUbuntu、Debianなど多くの種類があります。それぞれに特徴があり、ユーザ数が多く、ネット情報も多いのがUbuntuとDebianです。

但し、UbuntuやDebianは、Linux初心者には「しきい」が高いと思います。例えば、日本語環境やGUIの追加インストールが前提で、使え始める前に多少の手間が掛かります。この追加段階で失敗リスクもあります。

Windowsと同様、失敗などに対応できるOS利用経験があれば、UbuntuやDebianでも問題はありません。Mintは即利用重視、UbuntuやDebianは環境構築重視です。

多くのネット情報は、失敗やトラブル発生時には役立ちます。しかし、OSは安定動作が必然、本来は「トラブル無しの影の存在」のハズです。

マルチプラットフォームアプリケーションが多くなった現在、主役はアプリです。筆者は、MCU開発ツールと資料作成ツールのLibreOfficeが快適に動けば、OSに求めるのは安定性とセキュリティです。

Mintを使っていれば、そのうち不満箇所が出てきます。その時に、UbuntuやDebianの特徴が理解できるハズです。つまり、自分にとってLinuxの何が重要で、何を重視するかがより明確になる訳です。これが、ベンチマーク(水準点、基準)です。

Windowsの好みが個人個人で異なるように、Linuxベンチマークも個人で異なります。

先ずはMintを使ってLinuxベンチマークを持ち、次の段階で、数多いLinuxディストリビューションから要求ベンチマークに合うUbuntu、Debianなどを選べば良いと思います。

まとめ:Linux Mint選択理由

理由1:Windows 10スペックで快適動作
理由2:Windows 10/11に近いGUI操作性

どちらも2年間利用した筆者Linuxベンチマークによる評価です。Mintは、安定指向OSなので、トラブルも無く、大型更新なども成功しています。MCU開発ツールやLibreOfficeも動作します。

Mintには、高機能な方からCinnamonMATEXfceの3種類のGUIがあります(筆者はMATE利用中)。USBお試しインストール(正式名はLive Boot)でお好みのGUIが試せます。掲載図は、英語版GUIの抜粋ですが、雰囲気は判ると思います。

Linux Mint 21 MATE(左)と Xfce(右)のGUI拡大図
Linux Mint 21 MATE(左)と Xfce(右)のGUI拡大図

選択肢が多い時の選択方法

選択肢が多いと選びにくいということもあります。

例えば、Linuxディストリビューションや新しいWindows 11ノートPC選びなどです。ブログ読者から多くのベンダMCUからどれが良いですか、などのご質問を頂くこともあります。※この時は、「高性能汎用MCUをお勧め」しています。

このように選択肢が多い時の対策が、ベンチマーク(基準)設定です。

基準があって、その基準より上か下かを判断すれば、選択肢は、おのずと絞られてきます。問題は、ベンチマークは何かです。同僚や先輩にベンチマークを聞くのも1つの方法です。

重要なことは、ベンチマークの上か下かの判断をご自分で行うことです。

選択肢が多い時の選択方法
選択肢が多い時の選択方法

この判断も他人に任せると、それは他人の選択肢をそのまま利用したことになります。逆に、ベンチマークそのものは、最初は、適当に選んでも良いと思います。

とりあえずベンチマークを設定し、上下判断を行っているうちに、自分にとって本当のベンチマークが明確になってきます。複数ベンチマークでも同様です。

ベンチマークは、判断結果で変わるものです。ベンチマーク設定よりも、上下判断にこだわっていれば、多くの選択肢からご自分に合った選択ができます。

Windows 11非対応PCアップグレード後3ヶ月

Windows 11非対応PCアップグレード後3ヶ月
Windows 11非対応PCアップグレード後3ヶ月

本稿は、Windows 11非対応PCアップグレード後の3ヶ月状況、Win11 GUI変更ツール、次期Windows 12/13情報などをまとめます。

今年の4月15日、Windows 11アップグレート要件を満たさないWin10 PCを、強引にWin11 21H2へアップグレード後、3か月が経過しました。この期間、トラブルも無く安定動作しています。

今秋大型更新Windows 11 22H2の情報も出回ってきました。評判が悪いモニタ下タスクバー固定は、変わりそうにありません。つまり、次期Win 11 22H2もタスクバー右配置は期待できません。

2024年Windows 12

Windows 12開発着手は、コチラで投稿しました。7月15日、Microsoftが、新しいWindowsを3年周期でリリースするかもしれないという情報も入ってきました。つまり、2024年Windows 12リリースの可能性です。

Microsoft は、「最後のWindowsはWindows 10を破棄」しましたので当然の事かもしれません。

Win11は、OSコアがWin10の流用です。メタバースなどの新世代クラウドエッジクライアントOSとして旧Win10コア流用は中途半端、ハードウェアの世代交代が激化する昨今、OSコア進化も必然の気がします。

事実、今年発売のIntel 12世代プロセサは、11世代から大きく性能向上し、新発売のノートPCは、こぞって12世代を採用しています。Microsoftが、プロセサ性能向上分を新コア設計へ適用しWindows 12をリリースしても不思議ではありません。

Windows 11非対応PCアップグレード後3ヶ月状況

Win11アップグレード要件を満たさないPCは、2025年10月14日、Win10サポート終了までがその寿命です。アップグレード非対応PCを、「Win10アプリケーションとデータ維持」の条件で強引にWin11 21H2へアップグレードし、延命可能かの評価が前投稿でした。

前投稿、1週間の評価結果抜粋が、下記です。

・Win10アプリ(MCU開発アプリ含む)は、Win11 21H2でも正常動作
・アップグレード後のWindows Updateは、問題なく動作
・悪評ツールバー下固定など使いにくいGUIは、次期更新22H2で改善期待

3か月経過したPCの状況が、下記です。

・Win10アプリ(MCU開発アプリ含む)更新なども正常動作
・Windows Updateも問題なく動作

Window 11 Update正常動作
Window 11 Update正常動作

つまり、要件未達PCをWin11 21H2に強制アップグレードしても、何ら問題なく運用できています。

残る課題は、このPCが次期Win11 22H2へ更新できるか否かです。これは、今秋結果が判り次第レポートします。なお、本PCは、TPM 2.0が未達要件です。従って、Win11 22H2大型更新時に、TPM足切りがあるかが判明します。

Windows 11 GUIカスタマイズツール

様々なWindows GUIカスタマイズツールがあります。お勧めが下記2ツールで、使用感がかなり改善されます。これらツールを使うと、従来操作性も維持しながら、新しいWin11 GUIへの移行も容易です。

Winaero Tweaker-1.40.0.0 (Win11対応済み)
Open-Shell-Menu(Win11未対応、旧名:クラシックスタートメニュー)

OSは、アプリの動作基盤にすぎません。

タスクバー下固定のような操作性悪化Win11 GUI変更に対し、これらツールが役立ちます。

Winaero Tweaker

Winaero Tweaker v1.40.0.0
Winaero Tweaker v1.40.0.0

Winaero Tweakerは、メニュー表示やタスクバー位置変更ができるツールです。1.40.0.0では、タスクバーのモニタ上変更が可能です。左右はまだNGです。

その他、多くのWin11 GUIカスタマイズが可能ですので重宝します。

Open-Shell-Menu

クラッシックスタートメニュー 4.4.170
クラッシックスタートメニュー 4.4.170

スタートメニューカスタマイズツールが、Open-Shell-Menuです。クラシックスタートメニューからOpen-Shell-Menuへ名称が変わりました。Windows 11未対応ですが、Win11 21H2で動作します。

Windowsボタン+Shiftで、下記Win11オリジナルスタートメニュー操作も可能です。

Windows 11オリジナルスタートメニュー
Windows 11オリジナルスタートメニュー

まとめ

TPM 2.0要件未達Windows 10 PCを、アプリケーションとデータ維持のままWindows 11 21H2へアップグレード後3ヶ月間運用し、各種Win10アプリ正常動作、Windows Updateも問題なく安定動作中です。

Windows 11の使い勝手は、GUIカスタマイズツールを使うと改善できます。

残る課題は、このPCが今秋予定Windows 11大型更新22H2可能か否かです。TPM要件未達のため、大型更新できない可能性は残っています。

OSコア設計とTPM 2.0の古さ

Win10とWin11は、同じOSコアです。Win11でのWin10アプリ動作は、本稿で示したように当然とも言えます。

一方、セキュリティ対策は、終わりが無く、常に新しい攻撃への防御更新が必要です。

COVID-19で急拡大したテレワークなどの新しいPC環境やメタバースに対し、2014年リリースTPM 2.0と、毎年大型更新したとはいえ2015年基本設計のWin10 と同じOSコアのWin11で、セキュリティ上十分かは疑問です。

プロセサ性能向上が著しい今、ハードウェア的なセキュリティは、2014年のTPM 2.0よりも、例えば、PlutonプロセサIntel vProAMD Proなどの最新セキュリティ強化プロセサが登場しています。これらを活かすOSコア刷新版が、2024年Windows 12かもしれません。

Windows MeやVista経験も持つMicrosoftです。Win11アップグレート要件TPM 2.0は破棄、Win11はWin10からのGUI変更、Win12で抜本的OSコアセキュティ刷新へと段階的リリースを行えば、多くの既存Winユーザにも受け入れられるシナリオになると思います。

筆者推測ですが、通常のWindows Updateが問題なく動作することから、Win11の「OSコア深層を変更しない限りTPM非動作」だと思います。TPM動作更新は、手順が複雑な分、Update失敗リスクも高いからです。

今秋Win11 22H2でTPMのため大型更新できない場合は、TPM回避更新ツールなどを探し対応する予定です。

組込み開発 基本のキ:暗号技術の仕組み

組込み開発 基本のキ:暗号技術の仕組み
組込み開発 基本のキ:暗号技術の仕組み

デイビッド・ウォン著、⾼橋 聡 訳、⽇経クロステックの4記事:暗号技術の要旨をまとめました。

組込み開発と暗号技術

暗号技術は、数学が基礎です。暗号を使えば、秘密が守られることを科学的に立証する必要があるからです。しかし、暗号を使う立場の組込み開発者は、数式よりも、暗号の仕組み理解の方が重要です。

仕組み中心の暗号技術解説記事が、下記⽇経クロステック4記事です。組込み開発 基本のキ、暗号仕組み理解に丁度良いと思います。各記事の要旨を抜粋します。

内容 発行日
秘密鍵の仕組み 2022年7月7日
ケルクホフスの原理 2022年7月8日
公開鍵暗号の仕組み 2022年7月12日
RSAデジタル署名 2022年7月13日

秘密鍵の仕組み

誰にでも読める平文を、暗号文へ変換する時に使う鍵が、秘密鍵。暗号文を元の平文へ復号する時も「同じ秘密鍵」を使う。

この送受双方の同じ秘密鍵利用が、対称秘密鍵暗号方式。送受参加者が多いと、鍵が漏洩するなど実用性低下の欠点もあるが、古代より使われてきた。

ケルクホフス原理

暗号/複合時に用いるアルゴリズムは、一般に公開しても良い。例えば、ウェブページ閲覧時のAES(Advanced Encryption Standard:⾼度暗号化標準)など。

公開アルゴリズムのセキュリティを保証する手段が、秘密鍵。

公開鍵暗号の仕組み

送受それぞれ「別の秘密鍵」と、「公開できる鍵」の2種類を使うと、送信側の秘密鍵が受信側で計算可能。これが、「非対称」の公開鍵暗号方式で、対称秘密鍵暗号方式の欠点を解消。

記事の公開図形と秘密鍵の計算例が解りやすい。

但し非対称公開鍵暗号方式は、第3者による公開鍵すり替えが可能なので、信頼性の問題は解決されない。

RSAデジタル署名

信頼性問題を解決するのが、デジタル署名。公開鍵を使って、送信者の署名が本物か偽物が検証可能。RSA以外にもデジタル署名方式あり。

このデジタル署名と非対称公開鍵暗号方式の両方を使うのが、現代の暗号化アルゴリズム全体像。

まとめ:仕組み理解でセキュリティ進化へ順応

暗号技術の仕組み理解でセキュリティ進化へ順応
暗号技術の仕組み理解でセキュリティ進化へ順応

インターネットに接続するIoT MCUには、通信セキュリティ対策は不可欠です。MCU開発側からすれば、当該セキュリティライブラリを、開発ソフトウェア/ハードウェアへ組込めば完了と思いがちです。

しかしながら、セキュリティ対策には、終わりがありません。新攻撃に対し、新たな暗号方式が登場します。MCU開発者が、複雑・高度化する暗号技術へ対応し、セキュリティ進化に追随するには、その仕組み理解は欠かせません。

本稿は、現代暗号化アルゴリズム、非対称公開鍵暗号方式とデジタル署名を説明しました。古代からの暗号技術は、インターネット出現により高度で複雑化しました。要旨の抜粋で判り難い箇所は、元記事も参照してください。

組込み開発 基本のキ:暗号技術の仕組みを理解し、IoT MCUセキュリティ進化へ順応しましょう。

組込み開発 基本のキ 過去投稿

組込み開発 基本のキ:組込み処理
組込み開発 基本のキ:RTOS vs. ベアメタル

Azure RTOS習得(6):低電力動作

STM32G4評価ボードのAzure RTOS低電力動作サンプルコード:Tx_LowPowerは、現在正常に動作しません。原因は、Stop1モード開始/Run復帰処理であることは判りました(下表の青部分)。

そこで、この低電力モード開始/復帰処理を、VCPメッセージ出力へ変更、低電力動作は保留し、Azure RTOS低電力動作プロジェクト作成方法と低電力動作の流れを説明します。

処理名 処理内容:低電力動作

(LD2:評価ボード単体)

優先度 プリエンプション閾値
メインスレッド 1) セマフォ取得を永遠に待つ
2) 取得時LD1 500ms点滅を10回実施
10 10
S1プッシュ割込み セマフォカウンタ=0時、セマフォ放出
Enter_LowPower_Mode Stop1モード開始処理 ➡ VCPメッセージ出力
Exit_LowPower_Mode Runモード復帰処理 ➡ VCPメッセージ出力

まとめ

STM32G4評価ボードのAzure RTOS低電力動作サンプルコード:Tx_LowPowerは、Stop1モード開始/Run復帰に問題があり正常動作しません。

そこで、Stop1モード開始/復帰処理を保留にし、Azure RTOS低電力動作プロジェクト作成方法と低電力動作の流れを説明しました。

Azure RTOSプロジェクトで低電力動作させるには、STM32CubeMXのConfiguration ThreadXタブLow PowerのEnter LowPower SupportとTX_LOW_POWER_TICKNESSをEnableにするだけです。

Enable後、CubeMX生成のApp_ThreadX_LowPower_Enter/Exitの中身:Enter/Exit_LowPower_Modeへ、STM32G4低電力動作7モードの設定/Run復帰処理を記述すれば、Azure RTOS低電力動作ができます。

Tx_LowPower動作

サンプルコード:Tx_LowPower の正常な動作が下記です。

1) S1プッシュでLD1が10回点滅後、Enter_LowPower_Mode実行しStop1停止
2) S1プッシュ割込処理でExit_LowPower_Mode実行しRun復帰

つまり、S1プッシュ毎にLD1が10回点滅し、その後、低電力Stop1モードで待機します。Stop1状態表示はありません。

Stop1モード動作の代わりにVCPメッセージ出力が下記です。S1プッシュでLD1が10回点滅、点滅中はVCPメッセージ出力無しです。違いは、Stop1モード動作有無です。

Stop1モード動作の代わりのVCP出力
Stop1モード動作の代わりのVCP出力

「非」動作対策の保留(NOP)

STM32CubeMXは、プログラムフレームワーク生成に優れています。Enter/Exit_LowPower_Mode内容のみを変更すれば、Stop1以外のStop2モードやSleepモードへの低電力動作変更が簡単にできます。

ちなみに、筆者は、Sleepモードへも挑戦しましたが、正常動作はしませんでした。
※Enter/Exit_LowPower_Mode正常化をご教授頂ける方は、メールを頂けると助かります。

そこで、このEnter/Exit_LowPower_Mode処理は、一旦、保留(NOP)とします。

Tx_LowPowerが正常化した後、改めて保留にしたEnter/Exit_LowPower_Mode処理を入れ替えれば済むからです。現状は、NOPの代わりにVCPメッセージ出力処理を選びました。

この保留対策で、Azure RTOS低電力動作プロジェクト作成方法と低電力動作の流れ理解の段階へ進めます。

Azure RTOS低電力動作プロジェクト作成方法

Azure RTOS Low Powerプロジェクト作成
Azure RTOS Low Powerプロジェクト作成

低電力動作有りと無しのプロジェクト作成差は、CubeMXのConfiguration ThreadXタブのLow Powerを開き、Enter LowPower SupportとTX_LOW_POWER_TICKNESSをEnableにするだけです。

App_ThreadX_LowPower_EnterとApp_ThreadX_LowPower_Exitは、CubeMXが生成する関数名です。この両関数の中身が、我々が開発するEnter/Exit_LowPower_Mode関数です。

つまり、Enter/Exit_LowPower_Mode中身を変えれば、その他の部分はそのままで、様々な低電力動作、例えばSleepやStop2へ対応できる作りになっています。フレームワーク生成に優れるSTM32CubeMXの利点です。

低電力動作の流れ

全てのスレッドが、待機状態になると、App_ThreadX_LowPower_Enterとその中身Enter_LowPower_Modeが実行されます。その結果、例えば、Sleepが低電力動作の場合には、MCUコアSleep+周辺回路動作になります。

割込み発生でApp_TreadX_LowPowerとその中身Exit_LowPower_Modeが実行されRun復帰、最優先スレッドが実行されます。

この低電力動作に関して、公式Azure RTOSサイトに記述は有りません。低電力動作は、個別MCU依存のためでしょう。

STM32G4低電力動作モード

STM32G4の7つの主要低電力モード(出典:STM32G4 - PWR)
STM32G4の7つの主要低電力モード(出典:STM32G4 – PWR)

そこで、STM32G4の低電力動作をまとめました。元資料は、STM32G4 – PWRLPTIMです。

STM32G4は、7種の低電力動作モードをサポートしています。Runウエイクアップ時間が11サイクルと短く、電力低減効果も高いSleepが筆者のお勧めです。

サンプルコードのEnter/Exit_LowPower_Mode処理が複雑なのは、更に効果の高いStop1だからです。

サンプルコード対応

・サンプルコードが無い時は、他の評価ボードから流用。
・サンプルコードに問題ありの時は、当該処理をNOP化、サンプルが示す内容取得。

サンプルコードは、開発TipsやKnow Howの宝庫です。しかし、残念ながら付属説明は、最低限です。説明するとキリが無いからです。そこで、弊社は、ベアメタル開発経験がある方を対象に、少し丁寧に説明を追加したつもりです。

サンプルコードと評価ボードさえあれば、実際にMCU動作が確認ができ、1から10まで記載の分厚いユーザマニュアルを読むよりも、手軽で効率的にMCU開発ができます。

サンプルコードにも、トラブルがあります。STM32G4評価ボード:NUCLEO-G474REを使ったAzure RTOS習得(2)~(5)用のサンプルコード対応をまとめたのが、本章最初の2行です。また、(2)~(5)で使ったサンプルコード名と内容が下表です。

サンプルコード名 サンプル内容(詳細リンク先参照) 備考
AzureRtos0 汎用Azure RTOSプロジェクト作成 NUCLEO-G474RE+Arduinoプロトタイプシールド動作
AzureRtosEventFlag スレッド間イベントフラグ同期 STM32G4サンプル流用動作
AzureRtosQueue スレッド間キューメッセージ送受信 NUCLEO-G0B1RE流用動作
AzureRtosMutexSema ミューティックス/バイナリセマフォ排他制御 STM32G0C1E-EV流用動作
AzureRtosLowPower 低電力動作プロジェクト作成(本稿) STM32G4サンプル非動作

最近のMCU開発は、HAL(Hardware Abstruction Layer)API利用のため、サンプルコード流用が簡単です。個別MCUハードウェアに依存しないためです。

便利なサンプルコードを活用すれば、効率的なMCU開発ができます。更に、複数サンプルコードを流用し、プロトタイプの早期開発が容易な弊社MCUテンプレートを使えば、開発効率は上がります。

STM32G4評価ボードとArduinoプロトタイプシールド、LCDやADC動作のBaseboardを使ったST版Azure RTOSテンプレート(仮名)は、年内開発予定です。NXP版FreeRTOSテンプレートは、コチラで販売中です。

評価ボードへArduinoプロトタイプシールドを追加しスレッド毎にLED点滅中
評価ボードへArduinoプロトタイプシールドを追加しスレッド毎にLED点滅中

Azure RTOSやFreeRTOSは、IoT MCU開発に必要です。ベアメタルLチカ理解に相当するRTOS機能コンポーネントの習得、個人レベルで初めてはいかがでしょう。