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

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

デイビッド・ウォン著、⾼橋 聡 訳、⽇経クロステックの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. ベアメタル

日本開発者の視野

昨年2021年のMCUサプライヤトップ5が、2022年6月21日のTech+記事に示されました。

2021年MCUサプライヤシェア(出展:記事)
2021年MCUサプライヤシェア(出展:記事)

NXP、STマイクロ、Infineon(旧Cypress)など弊社ブログもカバーする欧州3サプライヤが強く、米国マイクロチップ2位、日本ルネサス3位、これら上位5社で82.1%のMCUシェアを独占します。

記事によると、トップ5独占率は、増加中だそうです。

半導体は国家

今年2022年2月に始まったロジアのウクライナ侵略が、半導体ビジネスにどう影響するかのMassa POP Izumida氏の考察が、コチラの記事にあります。

記事を引用すると、“限られた企業のみが先端半導体製品や製造装置を作れ、半導体が戦略物資、国家の運命を左右する”、つまり「半導体は国家なり」です。納得できますね。

日本開発者は多様性

激変する半導体ビジネスで日本人開発者が生き残るには、得意の協調性だけでなく、多様性が必要だと思います。変化しつつある状況を把握し、「個人レベル」で少し先を見据えた行動指針を持つことです。

半導体は国家の著者:Izumida氏が、ARM、RISC-Vのプロセサ潮流を考察しています。MCUの少し先を考えるのにも役立つと思います。もちろん、1指針だけでなく、第2第3の予備指針を持つことも良いでしょう。※本ブログ2021年最後の傾向と対策:日本低下でも、Izumida氏の記事が読めます。

ポイントは、多様性実現へ開発視野を広くしておくことです。

MCU開発中は、視野狭窄に陥りがちです。対策は、開発中に狭まった視野を、意識して自ら時々広げる習慣を持つことです。激変半導体業界でMCU開発者自身のサスティナビリティ(持続可能性)検討は、納期を守ることと同じぐらい重要な事だと思います。

2022ウクライナ侵略影響

ロシアでは、Windows 10とWindows 11ダウンロードが遮断されました。

欧米のウクライナ侵略への報復は、テクノロジーへも及び始めました。Windows以外にも様々な欧米製ツールが、製品開発には必要です。例え半導体を製造できても、その半導体を使う新製品が開発できなければ、本末転倒です。

テクノロジー遮断は、開発者のやる気や元気を無くすのに効果的です。

今回の侵略影響を注視している中国や欧米各国自身も、テクノロジー鎖国化・保守化傾向へバイアスが掛かる気がします。また、より強い開発者育成にも積極的になるでしょう。逆に、1998年以来、約24年ぶりの円安影響を受ける日本企業は、開発者育成などの人的先行投資は、後回し傾向がより強まると思います。

侵略は、極東アジアG7参加国日本が、ビジネスや金融など多くの点で「西側欧米各国とは異質の国であること」を、際立たせる結果を生んでいます。

まとめ

日本国内は、災害級の酷暑です。熱中症対策エアコン、節電対策、コロナ対策マスク、これら3対応が上手くできるでしょうか?

政府やマスコミは、「優先度を付けて」と言います。“優先度”は、各個人で異なります。しかし、日本人は、本来個人主体で決めるべき優先度を、他人と比べ決める傾向が強い民族です。先ず、他人ありきです。日本国内では、これでも良いでしょう。

しかしながら日本開発者は、世界の中で生きていきます。

異質の日本、視野を世界へと広くし、自分で自分を育成していくしか生き残り方法はない状況だと分析します。いかがでしょうか?

日本開発者の英語対策(7月3日追記)

2022年6月29日、経済産業省所管の日本IT国家戦略を技術面・人材面から支援する独立行政法人:情報処理推進機構IPAが、セキュリティエンジニア向け英語教材2点を発行しました。MCU開発者にも役立つ資料ですので紹介します。

英語Reading

セキュリティエンジニアのためのEnglish Reading、これは、英文読解力や英文情報収集力を高めるTips集で、「楽に」「上手く」英文を読む方法が記載されています。

セキュティ英単語集、こちらは、ポイントとなる頻出330英単語の、和訳を示しています。

どちらも形容詞の “セキュリティ” が付いていますが、普通のエンジニア向け資料です(というか、セキュリティ関連のAcronyms:略語集ではありません)。

両資料に目を通しておくと、「あらゆる英文」から効率的、効果的に情報収集が出来そうです!

英語Listening

2022年6月29日、日本ニューズウィークに中学英語をしっかりモノにすれば必ず話せるが掲載されました。英会話の大前提、「大事なことは最初」、「説明や細かいことは後」、が判ります。

英会話の冒頭部分に集中してListeningすれば、おおよその内容が把握できそうです!

日本開発者の英語

日本開発者の英語ハードル
日本開発者の英語ハードル

英語Readingやウェビナー英語Listeningは、日本人開発者最初のハードルです。しかし、ハードルは倒したとしても、早く走れればOKです。上記の資料、記事は、ハードルの倒し方、上手く早く走るテクニックを解りやすく示しています。

日本人開発者の視野を世界へ広くするには、英語ReadingとListeningは必須です。

クラウド環境進歩で、AI自動翻訳なども期待できますが、ピュアな世界情報に触れるには、原文(英語)から直接内容を理解する方が、脳にとっても良いハズです。

残りの英語Writingは、PCやクラウドの自動翻訳をどんどん使っても良さそうです!

あとがき

最初のEnglish Reading資料にあるように、英語情報は、12億人のため、日本語情報の1.2憶人の10倍です。デマや誤報などの内容妥当性にも注意が必要とあります。納得できます。

人口減少の日本と英語圏との知的情報差は、今後さらに広がります😭。

第2言語、技術者スキルとしての英語、必要性は高まるばかりです。少し長めですが貴重な “日本語表記” の資料、是非目を通してください。

好奇心とMCU開発

好奇心とMCU開発
好奇心とMCU開発

何を楽しい、面白いと感じるかは、人それぞれです。しかしながらMCU開発者の方々は、ソフトウェアやハードウエアを、自分で研究開発することに面白さや好奇心を持つ点は共通だと思います。

MCU開発は、地味です。普通の人からは、動作して当然と見られがち、しかし、その開発には努力や苦労も必要です。MCU開発者は、それら努力を他者へ説明はしません。
専門家へのキャリアアップには、避けては通れないからです。

特に日本のMCU開発者は、他者がどのように自分を見るかを気にし、しかも、同調意識も強いので、面白さを感じる感性を忘れ、自信喪失などに陥るかもしれません。

そんな時は、スマホを生んだSteve Jobs氏の、“Stay hungry, stay foolish” を思い出してください。

“Stay hungry, stay foolish”

様々な日本語訳、その意味解説があります。筆者は、Jobsは、他者の視線や動向より自分の好奇心を忘れるな、と言っているように思います。

2007年発表スマートフォン:iPhoneは、“Stay hungry, stay foolish”のJobsだから生み出せた製品です。

COVID-19、ウクライナ危機

終息が見えないCOVID-19やウクライナ危機による新しい世界秩序は、半導体製造/流通、MCU/PCセキュリティなどMCU開発者が関係する事柄にも多大な影響を与えそうです。今後数年間は、環境激変の予感がします。

既成概念やトレンド、これまでの市場予測なども大きく変わる可能性もあります。アンテナ感度を、個人レベルでも上げて対処しましょう。

MCU開発は楽しい?

行動の源は好奇心です。“Stay hungry, stay foolish”、 自分の好奇心は自ら満たし、MCU開発を楽しみましょう。

本稿の目的は、新年度:4月からMCU開発を新に始める方々へのアドバイスと、好奇心に逆らえず、Windows 11要件を満たさないPCをアップグレードした顛末を次週投稿予定という、前振りです😅。

クラウドベースMCU開発(個人編)

クラウドベースMCU開発お役立ちリンク
クラウドベースMCU開発お役立ちリンク

ARMが、2021年10月19日、IoT関連製品の開発期間を平均5年から最大2年間短縮できるクラウドベース開発環境「Arm Total Solution for IoT」発表という記事(EE Times Japan)は、以下の点で興味深いです。

・IoT製品化に平均5年もかかるのか?

・ハードウェア完成を待ちソフトウェア開発着手するのか?

但し、クラウドがMCU開発に効果的で、GitHubなどのクラウドリンクが今後増えることは、疑う余地がありません。そこで、すきま時間に個人レベルで役立つクラウドMCUリンクを3点示します。

すきま時間お役立ちクラウドMCU開発リンク

クリエイティブなMCUハードウェア/ソフトウェア開発中は、集中時間と空間が必要です。COVID-19の影響で、開発場所や通勤環境に変化はあるものの、ちょっとした待ち時間や出先での2~3分程度のすきま時間は相変わらず存在します。

個人レベルのIoT MCU開発支援が目的の弊社は、このような短いすきま時間にスマホやタブレットを使って、MCU情報を収集、閲覧するのに便利なリンクを紹介します。

すきま時間にMCU関連情報を閲覧することにより、集中時間に凝り固まった開発視点を新たな視点に変える、最新情報を収集するなどが目的です。

STマイクロMCU技術ノート

STマイクロMCU技術ノートの一部(PDF内容は濃く全てのMCU開発で役立つTips満載)
STマイクロMCU技術ノートの一部(PDF内容は濃く全てのMCU開発で役立つTips満載)

STマイクロのSTM32/STM8シリーズ別に検索できる日本語MCU開発Tips満載リンクです。ログインが必須ですが、わずか数ページで説明されたダウンロードPDF内容は濃く、STユーザに限らず全てのMCU開発者に役立つTipsが得られます。

EDN Japan Q&Aで学ぶマイコン講座

EDN Japan Q&Aで学ぶマイコン講座の一部
EDN Japan Q&Aで学ぶマイコン講座の一部

EDN JapanのMCU情報リンクです。Q&Aで学ぶマイコン講座は、最初の1ページでMCU初心者、中級者からの質問に対する回答要点が示されています。2ページ以降で回答詳細を説明するスタイルですので、短時間での内容把握に適しています。

Digi-Keyブログ

Digi-Keyブログの一部(日本語タイトルは翻訳された記事を示す)
Digi-Keyブログの一部(日本語タイトルは翻訳された記事を示す)

日本語タイトルで日本語へ翻訳されたブログ記事が判るリンクです。大手サプライヤーの英語ブログですのでMCUだけでなく、幅広いデバイス情報が得られます。すきま時間でも読めるように記事は短く纏まっています。最新MCU情報やハードウェア開発者向け情報が多いのも特徴です。

IoT製品とプロトタイプ開発

EE Timesの2021年10月8日、半導体製品ライフサイクルの長さと製造中止対策の記事に、20年前、1990年代の事業分野別の製品開発リードタイムとライフサイクル変化が示されています。

事業分野別の開発リードタイムと製品のライフサイクル変化(出展:記事)
事業分野別の開発リードタイムと製品のライフサイクル変化(出展:記事)

1998年の値ですが、重電機器を除く製品開発時間(リードタイム)が2.3年以内という数値は、現在でも納得できます(0.5年程度のプロトタイプ開発時間は含んでいない実開発時間だと思います)。

MCUベンダ各社は、10年間のMCU供給保証を毎年更新します。つまり、2021年更新ならば、2031年迄の10年間は販売MCUの供給を保証するということです。

但し、セキュリティが重視されるIoT製品では、最新セキュリティハード/ソフト内蔵IoT MCUによる製品化をエンドユーザは望みます。SoC:System on a Chipによる製造プロセス進化により、IoT関連製品の開発期間は、再開発も含めると1998年よりも更に短くなる可能性もあります。

前章リンク情報を活用し、最新セキュリティ内蔵MCU状況、セキュリティ機能のOTA更新可能性、開発製品がエンドユーザのセキュリティニーズと開発コストを満たすか、などを個人でも常時把握・評価し、万一、開発製品の成功見込みが少なくなった場合には、MCU見直しなども必要でしょう。

IoTセキュリティのライフサイクルは変動的で、かつ、IoT製品の市場獲得に支配的です。短い開発時間中であっても、状況に応じてMCUを変更することは、製品の成功と失敗に直結します。

弊社MCUテンプレートを使ったプロトタイプ開発は、このような激変IoT製品開発のMCU評価に適しています。制御系MCUと被制御系を分離、低コスト、少ない手間でプロトタイプを早期に開発し、プロトタイプ実機によりIoT製品のMCU評価、適正判断ができるからです。

もちろん、最初に示したバーチャルなArm Total Solution for IoTとの併用も有効です。セキュリティ重視IoT製品開発の成功には、IoT MCU選択と開発期間の短さがポイントです。

Cortex-M4評価ボードRTOSまとめ

低価格(4000円以下)、個人での入手性も良い32ビットARM Cortex-M4コア評価ボードのRTOS状況を示します。超低価格で最近話題の32ビット独自Xtensa LX6ディアルコアESP32も加えました。

Vendor NXP STマイクロ Cypress Espressif Systems
RTOS FreeRTOS
Azure RTOS
CMSIS-RTOS FreeRTOS
Mbed OS
FreeRTOS
Eva. Board LPCXpresso54114 NUCLEO-G474RE CY8CPROTO-063-BLE ESP32-DevKitC
Series LPC54110 STM32G4 PSoC 6 ESP32
Core Cortex-M4/150MHz Cortex-M4/170MHz Cortex-M4/150MHz
Cortex-M0+/100MHz
Xtensa LX6/240MHz
Xtensa LX6/240MHz
Flash 256KB 512KB 1024KB 480KB
RAM 192KB 96KB 288KB 520KB
弊社対応 テンプレート販売中 テンプレート開発中 テンプレート検討中 未着手

※8月31日、Cypress PSoC 6のRTOSへ、MbedOSを追加しました。

主流FreeRTOS

どのベンダも、FreeRTOSが使えます。NXPは、Azure接続用のAzure RTOSも選択できますが、現状はCortex-M33コアが対応します。ディアルコア採用CypressのRTOS動作はM4側で、M0+は、ベアメタル動作のBLE通信を担います。STマイクロのCMSIS-RTOSは、現状FreeRTOSをラップ関数で変換したもので実質は、FreeRTOSです(コチラの関連投稿3章を参照してください)。

同じくディアルコアのEspressifは、どちらもRTOS動作可能ですが、片方がメインアプリケーション、もう片方が通信処理を担当するのが標準的な使い方です。

価格が上がりますがルネサス独自32ビットコアRX65N Cloud Kitは、FreeRTOSとAzure RTOSの選択が可能です。但し、無償版コンパイラは容量制限があり、高価な有償版を使わなければ開発できないため、個人向けとは言えません。

※無償版でも容量分割と書込みエリア指定など無理やり開発するトリッキーな方法があるそうです。

クラウドサービスシェア1位のAWS(Amazon Web Services)接続用FreeRTOSが主流であること、通信関連は、ディアルコア化し分離処理する傾向があることが解ります。

ディアルコア

ディアルコアで通信関連を分離する方式は、接続クラウドや接続規格に応じて通信ライブラリやプロトコルを変えれば、メイン処理側へ影響を及ぼさないメリットがあります。

例えば、STマイクロのCortex-M4/M0+ディアルコアMCU:STM32WBは、通信処理を担うM0+コアにBLEやZigBee、OpenThreadのバイナリコードをSTが無償提供し、これらを入れ替えることでマルチプロトコルの無線通信に対応するMCUです。

メイン処理を担うM4コアは、ユーザインタフェースやセンサ対応の処理に加え、セキュティ機能、上位通信アプリケーション処理を行います。

通信処理は、クラウド接続用とセンサや末端デバイス接続用に大別できます。

STM32WBやCY8CPROTO-063-BLEが採用した末端接続用のBLE通信処理を担うディアルコアのCortex-M0+には、敢えてRTOSを使う必要は無く、むしろベアメタル動作の方が応答性や低消費電力性も良さそうです。

一方、クラウド接続用の通信処理は、暗号化処理などの高度なセキュティ実装や、アプリケーションの移植性・生産性を上げるため、Cortex-M4クラスのコア能力とRTOSが必要です。

デュアルコアPSoC 6のFreeRTOS LED点滅

デュアルコアPSoC 6対応FreeRTOSテンプレートは、現在検討中です。手始めに表中のCY8CPROTO-063-BLEのメイン処理Cortex-M4コアへ、FreeRTOSを使ってLED点滅を行います。

と言っても、少し高価なCY8CKIT-062-BLEを使ったFreeRTOS LED点滅プログラムは、コチラの動画で紹介済みですので、詳細は動画をご覧ください。本稿は、CY8CPROTO-063-BLEと動画の差分を示します。

CY8CPROTO-063-BLE のCortex-M4とM0+のmain_cm4.c、main_cm0p.cとFreeRTOSConfig.hが下図です。

PSoC 6 CY8CPROTO-063-BLE FreeRTOS LED点滅のmain_cm4.cとmain_cm0.c
PSoC 6 CY8CPROTO-063-BLE FreeRTOS LED点滅のmain_cm4.cとmain_cm0.c
PSoC 6 CY8CPROTO-063-BLEのFreeRTOSConfig.h
PSoC 6 CY8CPROTO-063-BLEのFreeRTOSConfig.h

日本語コメント追記部分が、オリジナル動画と異なる箇所です。

RED LEDは、P6[3]ポートへ割付けました。M0+が起動後、main_cm0p.cのL18でM4システムを起動していることが判ります。これらの変更を加えると、動画利用時のワーニングが消えCY8CPROTO-063-BLE でFreeRTOS LED点滅動作を確認できます。

PSoCの優れた点は、コンポーネント単位でプログラミングができることです(コチラの関連投稿:PSoCプログラミング要点章を参照してください)。

PSoCコンポーネント単位プログラミング特徴を示すCreator起動時の図
PSoCコンポーネント単位プログラミング特徴を示すCreator起動時の図

PSoC Creator起動時の上図が示すように、Cypressが想定したアプリケーション開発に必要なコンポーネントの集合体が、MCUデバイスと言い換えれば解り易いでしょう。つまり、評価ボードやMCUデバイスが異なっても、使用コンポーネントが同じなら、本稿のように殆ど同じ制御プログラムが使えます。

PSoC 6 FreeRTOSテンプレートも、単に設定はこうです…ではなく、様々な情報のCY8CPROTO-063-BLE利用時ポイントを中心に、開発・資料化したいと考えています。PSoCプログラミングの特徴やノウハウを説明することで、ご購入者様がテンプレートの応用範囲を広げることができるからです。

MCUXpresso IDE 11.4.0 Release

MCUXpresso suite of software and tools
MCUXpresso suite of software and tools

2021年7月15日、NXPの統合開発環境MCUXpresso IDEが、11.3.1から11.4.0へ更新されました。
新たに追加されたAzure RTOS、弊社FreeRTOSアプリケーションテンプレートの新環境での動作確認を示します。

Azure RTOS追加

FreeRTOSに比べ未だ12個と少数ですが、LPCXpresso55S06などCortex-M33コアのAzure RTOS 対応評価ボードとSDK v2.10.0が追加されました。Microsoft AzureのAWS追随が、統合開発環境に現れました(関連投稿:多様化MCU RTOS)。

Azure RTOS Boards
Azure RTOS Boards

これに伴い、IDEのRTOSメニューにAzure RTOSの Message QueuesやSemaphoresなどのViewが追加されました。Azure RTOSデバッグユーザガイトは、MCUXpressoIDE_11.4.0_6224インストールフォルダ内にありますので参照してください。

RTOSメニューに追加のAzure RTOS View
RTOSメニューに追加のAzure RTOS View

FreeRTOSアプリケーションテンプレートの新環境動作確認

Config Toolsもv10.0へ更新されましたので、新IDE更新後、旧11.3.1開発プロジェクトのPinパースペクティブで再度Update Codeのクリックが必要です。Updateクリック後、Develop画面に戻り再ビルドします。(Config Toolsの使い方は、コチラの関連投稿を参照してください)。

MCUXpresso Config ToolsのUpdate Code
MCUXpresso Config ToolsのUpdate Code

再ビルドは正常に終了し、新MCUXpresso IDE 11.4.0とFreeRTOS対応評価ボードLPCXpresso54114で、FreeRTOSアプリケーションテンプレートの動作確認をしました。

FreeRTOSアプリケーションテンプレートと付属資料も、11.4.0対応版へ更新します。

新MCUXpresso IDE 11.4.0で旧プロジェクト動作確認。LPCXpresso54114のSDK更新はなし。
新MCUXpresso IDE 11.4.0で旧プロジェクト動作確認。LPCXpresso54114のSDK更新はなし。

補足1:新旧統合開発環境併存

NXPの統合開発環境は、PC上で新旧環境が同時併存可能です。

環境が併存しますのでストレージ容量は必要です。また、ターゲットボードのSDK改版が無くても再度新IDEへのインストールが必要など手間もかかりますが、新環境構築が安心してできます。但し、新環境下でターゲットプロジェクト開くと、新環境用に変更され旧環境に戻せません。

ターゲットプロジェクトは、新旧環境で別々にすることを忘れないでください。

補足2:STM版CMSIS-RTOSアプリケーションテンプレート構想状況

FreeRTOSやAzure RTOSなど開発者が対応すべきMCU RTOSは、今後増える傾向です。RTOSが変わっても同じ開発アプリケーションを活用・流用できるのがCMSIS-RTOSメリットです。STM版RTOSアプリケーションは、このCMSIS-RTOSを使って構想中で、この状況を示します(詳細は、STM32RTOS開発3注意点(後編)などを参照してください)。

FreeRTOSとCMSIS-RTOSのセマフォAPI比較
FreeRTOSとCMSIS-RTOSのセマフォAPI比較

上側がFreeRTOSセマフォ送受、下側がCMSIS-RTOSセマフォ送受ソースです。どちらも殆ど同じです。

IDEにContent Assist機能(Ctrl+Space表示のAPI候補一覧)があるので、ソース記述は簡単で、基本的なRTOS手段(上記はタスク同期セマフォ)を理解済みなら、FreeRTOSに比べ情報が少ないCMSIS-RTOS開発でも、当初思ったより障壁は低いと感じています。

CMSIS-RTOSメリット/デメリットを比較して、メリットの大きさを感じた今回のNXP IDE更新でした。STM版CMSIS-RTOSアプリケーションテンプレート構想は、近日中に投稿予定です。

半導体・デジタル産業とホノルル便パイロット

経産省が2021年6月4日に発表した「半導体・デジタル産業戦略」について、専門家の評価は悲観的です。

我々IoT MCU開発者は、ホノルル便パイロットを見習い、対応策を持つべきだと思います。

経産省半導体・デジタル戦略の評価

今こそ日本の大手電機各社は半導体技術の重要性に気付くべき、EE Times Japan、2021年6月15日

日本の半導体戦略は“絵に描いた餅”、TechFactory、2021年6月16日

日本の半導体ブームは“偽物”、再生には学校教育の改革が必要だ、EE Times Japan、2021年6月22日

専門家が日本政府や経産省の方針を批判するのは、コロナ対策と同様、当然です。また下記、英)Financial Times評価を紹介した記事からも、専門家評価と同様、概ね懐疑的であることが判ります。

半導体製造業の日本の取組みに対する海外メディア評価、Gigazine、2021年7月6日

この戦略結果として生じる半導体・デジタル産業の市場変化の影響を直接受けるのは、我々IoT MCU開発者です。しかも、結果がでるまでの時間は、ますます短くなっています。この分野が、自動車や次世代通信などを含む「全ての産業の要」だからです。

経産省戦略資料は、コチラからダウンロードできます。概要・概略だけでも相当な量があり、対象がMCU技術者ならまだしも、マネジメントや一般技術者が、本当に要点を把握できるか、筆者でも疑問に感じます。

ホノルル便緊急事態対策

かつて護送船団方式ともいわれた日本産業の舵取りは、成功もありますが失敗も多いです。同調圧力に弱い日本人には、この方式が向いていたのかもしれません。

問題は、舵取りの結果生じる市場変化に、どう対応するかです。

対応策ヒントの1つになるのが下記記事です。

太平洋の真ん中でエンジン停止したらどうなるか、東洋経済、2021年6月27日

パイロットは、太平洋上での緊急事態対応のため、60分毎に東京/ミッドウェー/ホノルルの天候情報を集め、燃料残量や対地速度などの機体状況を確認し、180分以内に着陸できる空港を検討するのです。しかも、この緊急事態は、パイロットが入社し定年退職するまでに一度も経験することの無い0.024%の発生確率でもです。

ホノルル便パイロットの緊急事態対応(出展:記事)
ホノルル便パイロットの緊急事態対応(出展:記事)

この東京~ホノルル便エンジン停止などの緊急事態発生確率に比べると、半導体・デジタル産業の国による舵取り失敗確率は、高いと思います。

我々MCU開発者も、ホノルル便パイロット並みとはいかなくても、せめて開発が一段落付く毎に、最新IoT MCU状況を確認し対応を検討することは重要です。一段落が付いた時は、開発に使ったMCUの利点欠点を把握直後なので、他MCUとの比較も精度良くできるからです。

この検討結果をどのように反映するかは、開発者次第です。

お勧めは、もしもの時の「第2候補IoT MCU案:Plan Bを、開発者個人で持つこと」です。Plan Bは、たとえ同じARM Cortex-Mコア利用であっても、ベンダ毎に手間やAPIが異なるIoT MCU開発に、心理的余裕を与えます。Non ARMコア利用ならなおさらです。

個人でなら、同調圧力に関係なく、自分の開発経験や勘を使ってPlan Bを検討できます。

まとめ

2021年6月経産省が発表した半導体・デジタル産業戦略の専門家評価は、悲観的です。国の舵取りが失敗した例は、過去の電機や半導体企業の衰退が物語っています。巨額投資と市場シェアの両方が必要な半導体・デジタル分野は、既に弱体化した国内企業の巻返しにも期待はできません。

舵取り失敗確率は、現役ホノルル便パイロットが、太平洋上で緊急事態に出会う確率よりも高いでしょう。

最先端デバイスを利用するIoT MCU開発者の対応策の1つは、開発が一段落付く毎に、最新半導体・デジタル市場を確認し、もしもの時の第2 IoT MCU利用案:Plan Bを開発者個人で持つことです。

個人で安価にPlan Bを持つため、評価ボード動作確認済み各種マイコンテンプレートはお役に立てると思います。関連投稿:半導体不足とMCU開発案に、Plan B構成案もあります。

FreeRTOSアプリケーションテンプレート発売

FreeRTOSアプリケーションテンプレート動作中
FreeRTOSアプリケーションテンプレート動作中

ARM Cortex-M4コア動作のFreeRTOSアプリケーションテンプレート第一弾、NXP)LPCXpresso54114対応版(税込2000円)を本日より発売します。概要、要点、FreeRTOSアプリケーションテンプレートとは、に関する説明資料は、コチラから無料ダウンロードできますのでご覧ください。

開発背景

IoT MCUのクラウド接続には、AWSならAmazon FreeRTOS、Microsoft AzureならAzure RTOSなどのRTOSが必要です。クラウド側からは、1つのRTOSライブラリを使って様々なMCUハードウェアを接続するための手段、これがRTOSです。

一方、IoT MCU側からは、接続先サービスに応じたRTOSライブラリ利用に加え、従来のベアメタル開発からRTOS上でのアプリケーション開発へ発展する必要もあります。IoT化に伴うこのような変化に対し、開発者個人が手間なく対応するためのツール、これが弊社FreeRTOSアプリケーションテンプレートです。

MCU RTOS多様化対策のFreeRTOSアプリケーションテンプレート
MCU RTOS多様化対策のFreeRTOSアプリケーションテンプレート

目的

FreeRTOSアプリケーションテンプレートの目的は、「RTOS基礎固め」と「FreeRTOSプロトタイプ開発のスタートプロジェクトとなること」の2点です。

RTOS開発は、ベアメタル開発とは異なります。

RTOS Kernelが、開発した処理(タスクやThread)と他タスクの優先順位により、処理実行/待機を決めます。開発タスク単体の流用性は高まりますが、タスク間同期や通信に、セマフォやQueueなどのRTOS独特の手段が必要です。

IoTにより全てのモノ(MCU)がクラウドへ接続する時代の基盤は、RTOSです。

ベアメタル開発経験者が、このRTOSの早期基礎固め、Kernelと自身で開発したタスクの並列処理を理解するには、個々にRTOS手段を説明するサンプルソフトよりも、具体的なRTOSアプリケーションの方が実践的で役立ちます。

RTOSアプリケーションがあれば、優先順位を変えた時のタスク動作変化や、その他経験に基づいたRTOS実務開発で知りたい事柄を手間なく試し、新たな知見・見識を得られるからです。これらは、サンプルソフトや、説明文から得ることは困難で、実際のRTOSアプリケーションで開発者自身が試行するのがベストです。

そこで、各FreeRTOS手段を説明した弊社MCU RTOS習得ページを理解した次の段階として、最初の図に示したプロトタイプ開発着手に必須となるADC/LCD/SW/LED/VCOM処理を、NXP)LPCXpresso54114(Cortex-M4/150MHz、Flash/256KB、RAM/192KB)とBaseboard、Arduinoプロトタイプシールドに実装し、動作確認済みRTOSプロジェクトが、FreeRTOSアプリケーションテンプレートです。

FreeRTOS Application Template (NXP Version)
FreeRTOS Application Template (NXP Version)

※上記プロジェクトは、クラウド接続は行っておりません。RTOS基礎固めとFreeRTOSプロトタイプ開発に適すことが目的ですので、クラウド接続RTOSライブラリは未実装です。

FreeRTOSを選んだのは、現在MCU RTOSシェア1位だからです(関連投稿はコチラ)。RTOS手段は、各RTOS共通技術であるSemaphoreとQueueの2つを用いております。LPCXpresso54114のFlashやRAM使用量にはまだ十分余裕がありますので、より高度なミューテックスやイベントグループなどの手段を適用するのも容易です。

特徴

本テンプレートには、上記FreeRTOSプロジェクトと同じ動作確認済みのベアメタル開発プロジェクトも添付しております。これは、ベアメタル開発に慣れた方が、FreeRTOSとベアメタルの差分をより明確に理解し、比較や評価をするためです(比較・評価は、ご購入者ご自身で行って頂きます)。

本テンプレート付属説明資料は、主にベアメタル開発者視点から見たFreeRTOSプロジェクトを解説しており、ベアメタルプロジェクトに関する説明は、ソースコードを読めばご理解頂けるとして省略しております。

従って、FreeRTOSアプリケーションテンプレートは、ベアメタル開発経験者を対象といたします。ベアメタル初心者の方は、先ずは各MCUベンダCortex-M0+/M3コア対応の従来マイコンテンプレートをご購入ください。従来テンプレート付属説明資料には、ベアメタル動作の詳しい説明が付いています。

※本テンプレートのベアメタルプロジェクトは、従来テンプレートCortex-M0+/M3コアをCortex-M4コア対応へ発展させたものです。ベアメタルプロトタイプ開発着手時に適すプロジェクトです。

FreeRTOSアプリケーションテンプレートは、ベアメタル開発経験者が、手間なく直にRTOSとベアメタルの差を理解・実感し、かつ、IoT基盤RTOSの効率的な基礎固めができるツールです。

なお、既に従来マイコンテンプレートご購入者様は、50%OFF特典があり、税込1000円にて本FreeRTOSアプリケーションテンプレートをご購入頂けます。弊社での確認ミスを防ぐため、ご購入時に従来テンプレート購入者様である旨、お知らせください。

勿論、従来テンプレートとFreeRTOSアプリケーションテンプレートの同時購入でも、この特典は適用されます。

まとめと今後

ベアメタル開発経験者が、IoT MCUクラウド接続に必要となるRTOSの効率的な基礎固め、FreeRTOSプロトタイプ開発着手プロジェクトとして使えることを目的に、NXP)LPCXpresso54114、Baseboard、Arduinoプロトタイプシールドを使ったFreeRTOSアプリケーションテンプレートを発売しました。

本テンプレートは、Amazon FreeRTOSのHardware Independent FreeRTOS Exampleを原本としています。第1弾はNXP)LPCXpresso54114へ適用しましたが、今後、STマイクロエレクトロニクス)STM32G4やCypress)PSoC 6など他社Cortex-M4コアの対応版も開発予定です。

多様化MCU RTOS対策

IoT MCUクラウド市場は、AWSとMicrosoft Azureがリードしており世界収益の半分以上を占めるという記事に掲載されたのが下図です(EE Times 2021年6月7日、横軸:市場シェア、縦軸:年平均成長率)。Microsoftは徐々にAmazonに迫っており、市場シェア差は、過去1年で2ポイント縮まったそうです。

クラウトプロバイダの市場シェア(出典:記事)
クラウトプロバイダの市場シェア(出典:記事)

多様化MCU RTOS

AWSへの接続にはAmazon FreeRTOS、Microsoft AzureにはAzure RTOSを用います。IoTクラウド接続ウェビナーでは、どのMCUベンダでも先行しているAmazon FreeRTOSを使った接続例が主流です。しかし、最近は、Azure RTOS利用の接続資料やウェビナーも見られます。AWSとMicrosoft Azureの差が縮まりつつある証左でしょう。

また、第3勢力として急成長中のGoogleクラウド接続にはARM mbed OSが使われます。IoT MCUに実装するRTOSは多様化してきました。

IoT MCU RTOSとPCブラウザ

IoT MCU RTOSとPCブラウザ比較
IoT MCU RTOSとPCブラウザ比較

この状況は、PCブラウザが現状、複数共存しているのに似ています。

機能的には同じブラウザですが、表示/印刷/広告などの使い勝手が少しずつ異なるため、必要に応じて複数ブラウザを使い分ける方も多いでしょう。記憶容量の大きいPCでは、ブラウザ併用・共存も簡単です。

しかし、限られた容量しか持たないMCUの場合は、複数RTOSの中からMCU搭載RTOSは1つに絞られると思います。

例えば、AmazonやMicrosoft、Google各社の強み(販売/文書/広告)や特徴を活かし、IoT機器制御サービスやAI活用サービスなど魅力的クラウドサービスを各社各様で提供し、その価格、顧客との結びつきの強さなどがサービス選択の決め手となるでしょう。

いずれにせよ顧客が、利用するクラウドサービスを決め、その接続手段として各社RTOS接続ライブラリの使用、加えてRTOS環境での上層MCUソフトウェア開発を行うことになります。

問題は、RTOS環境のMCUソフトウェア開発手法がベアメタルと異なること、各社RTOS仕様が少しずつ異なることです。

多様化RTOS対策

仮に、Cortex-M4/M0+ディアルコアMCUで、クラウド通信処理全てを、Cortex-M0+コア側のRTOSライブラリで行い、通信とアプリケーションが完全分離された構成であれば、問題は解決します。接続サービス毎にRTOS通信ライブラリを変えさえすれば、対応できるからです。

BluetoothやThreadなど複数無線通信規格から1つを選んで処理するなど、この構成に近いベアメタルソフトウェア対応のMCUが既にあります。

しかし、主流ウェビナーで用いられる高性能Cortex-M4シングルコアを使って、クラウド通信とアプリケーションの両方を処理する場合には、接続先のクラウドに応じて「FreeRTOS/Azure RTOS/Mbed OSなど様々なRTOS環境の上層アプリケーション開発」になります。

RTOSの目的は、MCUハードウェア隠蔽と開発ソフトウェア流用性向上なのに、複数RTOS存在で開発アプリケーションが異なるとは、皮肉な結果です。

最初の図は、IoT MCU開発者が、今後急増するクラウド接続IoT MCU開発に、これら複数RTOSを効率的に習得し、かつ、顧客が選ぶ1個のRTOSアプリケーションを早期に開発できるスキルを獲得しなければならない現状や将来を示しているとも言えます。

こういう状況での常套手段は、共通部分と個別部分の分離、共通部分からの段階的習得です。

どのRTOSでもSemaphoreやQueueは、ほぼ共通の基本機能です。先ずは、この2機能をしっかり把握し、より高度なミューテックスやイベントグループなどRTOS毎に特徴があり機能も異なる対象へ発展するのが効率的でしょう。

※RTOSは、複数タスク(AzureはThread)を、優先順位に応じてリアルタイムに実行/待機/状態保存復帰の切替えを行います。タスク間同期手段がSemaphore、データ送受手段がQueueで、この2つはどのRTOSでも共通の基本機能です。

まとめ

IoT MCUクラウド市場シェアから、クラウド接続IoT MCU RTOSもPCブラウザ同様、様々な仕様併存の可能性があります。

顧客が選ぶRTOSに柔軟対応し、そのRTOS上層の様々なRTOSアプリケーションを早期開発するには、先ず、各RTOS共通機能のSemaphoreとQueueを把握し、より高度でRTOS毎に異なる個別機能へ発展する習得アプローチが効率的です。

6Eリリース予定の弊社FreeRTOSアプリケーションテンプレート(税込2000円)は、主流のAmazon FreeRTOSを用い、NXP)LPCXpresso54114(Cortex-M4/150MHz、Flash/256KB、RAM/192KB)にて動作確認済みです。

添付するRTOSプロジェクトは、各RTOS共通機能SemaphoreとQueueを利用しており、上記習得アプローチを満たすツールとして、また、全ての物をつなげる主役IoT MCU RTOS基礎固めに最適です。

FreeRTOSユーザタスクの作り方

ベアメタルサンプルソフトを活用したFreeRTOSユーザタスクの作り方を示します。先に結論を言うと、ベアメタルサンプルソフト無限ループ内に、RTOS待ち処理を挿入するだけでFreeRTOSタスク開発ができます。

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

RTOS環境のユーザタスク開発

IoT MCUをAWSやAzureなどのクラウドへ接続する時には、FreeRTOSやAzure RTOSなどのRTOSが必須です。クラウド接続用のRTOSタスク集が入ったライブラリを利用するからです。もちろん、このライブラリ内のタスク開発は必要ありません。

問題は、このIoT MCU RTOS環境で、ユーザタスクをどのように開発するかです。

RTOSの目的は、タスク独立性とリアルタイムなタスク並列多重、MCUハードウェア隠蔽です。ベアメタル開発経験者にとっては、ソフトウェア動作環境が著しく異なることが解ります。

RTOS開発障壁を下げるアプローチ

そこで、ベアメタル開発経験者は、先ずこのRTOS環境の理解に努めます。

セマフォやミューテックス、QueueなどRTOS特有の手段を理解します。弊社も各種FreeRTOS機能を説明しましたし、ウェビナー等でも同様です。但し、このアプローチAは、「RTOSの手段」理解が最初に来ますので、障壁が高いと感じる方も多いでしょう。筆者はそうでした。

そこで、お勧めするのは、RTOS手段をざっと読んだら、今度は逆に「RTOSの目的」からRTOS環境で、複数ユーザタスクを並列多重するアプローチBです。

複数ユーザタクスを、どうすればRTOSへ組込むかを検討するこの逆アプローチBは、Aよりもベアメタル開発経験者向きで、しかもRTOS手段は後回しですので障壁が低く感じられます。

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

2個のベアメタル処理をタスク化し、RTOSで並列多重処理する例で考えます。

・処理#1:緑LEDを、1秒毎にトグル点灯
・処理#2:赤LEDを、SW押下げでトグル点灯

ベアメタル開発経験者なら、どちらの処理も簡単に開発できます。処理概要は、最初図1の左側になります。

違いは判断内容で、処理#1が1秒経過、処理#2がSW割込みです。もちろん、両処理を並列に多重するのは、ベアメタル開発では工夫が必要です。処理#1と#2は、別々のプロジェクト、例えば2個のサンプルプロジェクトとして提供されるのが一般的です。

両処理をタスク化して組込むRTOSには、LPCXpresso54114のSDK付属generic_freertosプロジェクトを用います。“generic”が示すように、ハードウェアに依存しない汎用的なFreeRTOSプロジェクトです(generic_freertosの詳細は、コチラの関連投稿を参照してください)。

RTOSへ組込んだ時のタスク処理概要が、図1の右側です。ベアメタルとの違いは、タスク#1は、遅延処理vTaskDelayを無限ループに加えること、タスク#2は、割込みISRからの同期セマフォ受信を無限ループに加えることだけです。

両処理へ追加したのは、どちらも「RTOS処理待ち」です。この処理待ちを、RTOSが解除/待ちに切替えることで、複数タスクが並列に動作します。

RTOSは、複数タスクを処理待ち状態にし、処理待ちタスクの中から優先順位に応じて1個のタスクを実行状態に割当てます。RTOS(Kernel)自身が、順位判断や実行タスクの切替え、タスク実行状態の保存/リカバリのためスタックプッシュ/ポップ処理を行い、それらの処理間隔がTICK_RATEです。

リアルタイムでタスクを切替えるには、高速なKernel動作(AWSによると25MHz以上)と短期間のTICK_RATE(通常1ms)が必要で、タスク数に応じてスタック使用量(AWS RAM 64KB以上)は急増します。
※数値で示したAWS FreeRTOS必須条件の詳細は、コチラのハードウェア最小仕様要件を参照してください。

要するに、RTOSへユーザタスクを追加するには、ベアメタルでユーザ処理を開発し、その無限ループ内にRTOS処理待ちを加えさえすれば、RTOSユーザタスクになります。

ベアメタル開発経験者がデバッグし慣れた処理がそのままRTOSユーザタスク開発にも使え、RTOS処理待ちは、generic_freertosに実装済みのセマフォとQueueのRTOS手段だけでも、リアルタイムタスク並列多重のRTOSアプリケーション開発ができます。

まとめ

本稿は、IoT MCU RTOS環境でユーザタスクを開発し、FreeRTOSへ実装する方法として、ユーザ処理をベアメタルで開発し、無限ループ内へRTOS処理待ちを加えタスク化する方法を説明しました。

RTOS処理待ちは、セマフォとQueueのRTOS手段を理解していれば、プロトタイプ段階のFreeRTOSアプリケーションとしては十分です。ユーザ処理を自主開発する代わりに、ベンダ提供のベアメタルサンプルソフトを活用すれば、豊富なサンプル処理のFreeRTOSタスク化も簡単です。

タスク化処理を組込むRTOSには、NXP)LPCXpresso54114 SDK付属のgeneric_freertosプロジェクトを使います。このプロジェクトは、ハードウェア非依存の汎用FreeRTOSプロジェクトで、セマフォとQueueを実装済みです。そこで、これら2つのRTOS手段を手始めに理解すれば、RTOS開発障壁も低くなります。

あとがき

本稿で示したユーザタスク追加方法により開発したNXP)LPCXpresso54114(Cortex-M4/150MHz、Flash/256KB、RAM/192KB)で動作確認済みのFreeRTOSアプリケーションテンプレートは、6Eにリリース予定です(ADC入力とLCD出力、VCOM入出力処理も追加済み)。

FreeRTOS Application Template (NXP Version)
FreeRTOS Application Template (NXP Version)

このテンプレートには、FreeRTOSプロジェクトに加え、同じアプリケーション動作のベアメタルプロジェクトも添付します。ベアメタル処理に処理多重の工夫を加えた弊社Cortex-M0+/M3コア向けBaseboardテンプレートを、Cortex-M4コアへも適用したベアメタルプロジェクトです。

FreeRTOS開発とベアメタル開発の、Flash/RAM使用量差、開発難易度、消費電力差などCortex-M4コアMCU開発で実務上知りたい事柄を直接比較・評価することが可能です。また、どちらのプロジェクトも、基本的アプリケーションのテンプレート(=スタートプロジェクト)としても活用でき、プロトタイプ開発に最適です(FreeRTOS/ベアメタルの2プロジェクト+説明資料、税込2000円)。

また、STマイクロエレクトロニクス)STM32G4(Cortex-M4/170MHz、Flash/512KB、RAM/96KB)対応版も開発を予定しています。

FreeRTOSアプリケーションテンプレートを使ったプロトタイプ開発の次の段階としては、セマフォやQueue以外のミューテックスやイベントグループなどのより高度なRTOS手段の利用や、高速でRAM使用量も少ないタスク通知手段などのチューニング開発へとステップアップすることです。