RAアプリケーション開発の骨格

ルネサスRAファミリ評価ボードの動作テストプログラムと、周辺回路サンプルコードから判るRAファミリアプリケーション開発Tipsを示し、このTipsで開発したアプリケーション:App0を公開します。

評価ボードは、RA6E1を用いましたが、他のRAファミリ評価ボードでも同じです。

RAアプリケーションApp0のRTT Viewer出力
RAアプリケーションApp0のRTT Viewer出力

hal_entry.cとuser_main.c分離

RAファミリは、評価ボード毎にサンプルコードが提供されます。例えば、RA6E1の場合は、FPB-RA6E1 Example Project Bundleがそれで、この中にADCやタイマなどの周辺回路サンプルコードがあります。また、評価ボードテストプログラム:TP(quickstart_fpb_ra6e1_ep)も含まれており、他の周辺回路サンプルコード:EP(Exampleプログラム)とは少し違うファイル構造になっています。

違う原因は、EPが、コード判り易さのため、メイン処理をhal_entry.cに集中して記述するのに対し、TPは、様々な評価ボードへも対応するため、いわば汎用アプリケーション構造となっているからです。

簡単に言うと、FSPが生成するメイン処理:hal_entry.cと、ユーザ追記のメイン処理:user_main.cをファイル分離し、ユーザ開発部分の可搬性を上げた構造を持つのがTPです。

開発したMCUアプリケーションに可搬性があると効率的で生産性もあがります。TP同様、RAアプリケーションも、hal_entry.cとuser_main.cを分離した構造で開発する方法をお勧めします。

※FSP(Flexible Software Package)やサンプルコードの詳細は、コチラの関連投稿を参照ください。

SEGGER RTT Viewer利用

TPとEPには、もう1つ違いがあります。それは、EPには、PC入出力マクロが実装済みの点です。

例えば、gpt_fpb_ra6e1_ep(最初のgptが汎用PWMタイマ、fpb_ra6e1が評価ボード、epがExample Programを示す)ならば、タイマ利用例をPCへ出力し、その設定値をPCから入力できます。

対PC通信にはUSB経由Virtual COMポートを利用する評価ボードが多いのに対し、ルネサスRAファミリは、評価ボード実装デバッガのSEGGER RTT Viewerをこの役目に使います。USARTなどのMCU資産を消費しないメリットがあります。

PCでRTT Viewerを使うには、コチラからJ-Link Software and Documentation Packをダウンロードし、PCへインストール後、J-Link RTT Viewer起動で評価ボードとPC通信ができます(最初の図)。

但し、RA6/4などCortex-M33コアファミリ開発の場合は、ビルド後生成されるmapファイルからRTT Control Block Addressを探し、Viewer起動ダイアログへ入力する必要があります。

プログラム変更やFSP版数が変わると、このBlock Addressも変わるので、生成mapファイルAddress値の再入力が必要です。

RAアプリケーション開発時にも、このPC通信マクロが使えるとprintf/scanfの代用になり便利です。FSP生成プロジェクトでPC通信マクロを利用するには、生成プロジェクトのsrcフォルダへ、SEGGER_RTTとcommon_utili.hの両方を手動で追加します。

追加元のSEGGER_RTTとcommon_utili.hは、どのEPのものでも構いません。

App0特徴

以上から、RAアプリケーション開発時は、FSPが生成するオリジナルファイルに

①HAL生成メインhal_entry.cとユーザ追記メインuser_main.cを分離したファイル構造
②srcへSEGGER_RTTとcommon_utility.hの手動追加

を行うと、ユーザ開発ソースコードのRAファミリ間での可搬性が高く、PC通信も容易なアプリケーションの骨格(Skelton)が完成します。

この方法で開発したアプリケーション:App0を示します。タイトルをPCへ出力するだけのアプリケーション骨格です。この骨格に、開発ソースコードを肉付けしていけば、肉付けソースコードのRAファミリ間可搬性が高く、デバッグ効率も高いアプリケーション開発ができます。

RAファミリアプリケーション開発骨格:App0
RAファミリアプリケーション開発骨格:App0

開発したApp0プロジェクト圧縮ファイルは、コチラよりダウンロード可能です。ご自由にご利用ください。

e2 studioへのインポート方法は、インポート>既存プロジェクトをワークスペースへ>アーカイブ・ファイルの選択で、App0.zip指定です。

App0開発手順

以下にApp0プロジェクトの作成手順を示します。

1)FSPで新規Bare Metal – Minimalプロジェクト生成
2)App0 FSPパースペクティブでGenerate Project Contentクリック
3)他の周辺回路サンプルコードのsrc>SEGGER_RTTとcommon_utility.hをコピーし、App0プロジェクト>srcフォルダへペースト
4)src>hal_entry.cのL3へextern void UserMain(void)追記、L19へUserMain()追記
5)src上で新規>ソース・ファイルをクリックし、UserMain.c追加
6)src上で新規>ヘッダー・ファイルをクリックし、UserDefine.h追加
7)UserMain.cとUserDefine.hへ、前章ソースコード追記
8)ビルドし、Debug>App0.mapファイルから_SEGGER_RTTを検索、そのアドレスを、RTT Viewer起動ダイアログのRTT Control Blockへ入力後OKクリック
9)評価ボードへApp0をダウンロード、実行
10)PCのRTT Viewerで図1のタイトル出力確認

4、5、6の追加ファイル名は、UserMain.c、UserDefine.hなど先頭大文字のPascal形式を用いています。これは、プロジェクト・エクスプローラーでオリジナルのFSP生成ファイルとユーザ追加ファイルの識別が容易になるからです。

また、筆者は、Cソース・ファイル毎にヘッダー・ファイルを追加するより、ソース・ファイル内にプロトタイプ宣言を追記し、個別ヘッダー・ファイルを追加しない方が好みです。4のhal_entry.cへUserMainプロトタイプ宣言を追記したのも、このためです。

UserMain()は、初期設定と無限ループに分け、初期設定にRttInit()とUserInit()を追加しています。RttInit()でタイトルをPCへ出力し、UserIint()は、内容が何もありません。骨格ですので、利用する周辺回路に応じて、ここへ初期設定コードを追記することを想定しています。

App0のプロジェクト構成とRTT Viewerへのmapアドレス設定の様子
App0のプロジェクト構成とRTT Viewerへのmapアドレス設定の様子

まとめ

RAファミリ評価ボードテストプログラムと周辺回路サンプルコードから、hal_entry.cとuser_main.cの分離ファイル構造と、RTT Viewer利用の対PC通信マクロ実装済みのアプリケーションスケルトン(骨格):App0を示しました。

この骨格へ、開発ソースコードを追加していけば、ユーザ追加部分のRAファミリ間可搬性が高く、デバッグ効率も高い、RAファミリアプリケーションが開発できます。

もちろん、3月末を目標に開発中のRAファミリテンプレートも、このApp0へ評価ボード実装LED点滅やチャタリング対策済みSW機能などを追加します。RAファミリテンプレート構想はコチラの4章、RAテンプレートの仕組みはコチラの関連投稿を、参照ください。

最近の組込みCコード書き方

RAファミリFSP生成のBare Metal Blinkyサンプルコードの書き方が、筆者のCコード書き方と違っていて驚いた点を示します(FSP:Flexible Software Packageとは何かは、コチラの関連投稿を参照)。

変数宣言位置

FSP生成Bare Metal Blinkyサンプルコードの変数宣言
FSP生成Bare Metal Blinkyサンプルコードの変数宣言

筆者のC変数宣言は、関数の冒頭、実行文の前に全ての変数宣言を行います。しかし、Bare Metal Blinkyサンプルコードは、変数が必要になった直前で変数宣言をしています。こちらの方が、コードが読み易いですね。

これは、使うC言語規格が異なるからです。筆者は、古いC90(1990年版)、FSPは、C99(1999年版)以降の規格、書き方を採用しています(参考文献:C言語の仕様)。

C言語規格も改良や改版が進み最新規格は、C11(2011年版)です。更に、C17やC2xなどへ進化中だそうです。下位(旧版)互換性は、コンパイラが賢いので保たれています。エッジAIが導入されると、古い書き方は止めなさいとアドバイスが出たりするかもしれません😅。

IoT MCU開発では、従来比、他者が開発したコードやライブラリを読み、理解・利用する機会も格段に増えます。

独立行政法人情報処理推進機構から、組込みソフトウェア開発向けコーディング作法ガイド[C言語版]ESCR Ver. 3.0(2018年)のPDF版がダウンロード可能です。

ガイド想定利用者は、プログラマやレビュー者(P3参照)とありますので、本ブログ読者は目を通しておくのも良いと思います。

新しい規格に縛られる必要は、コンパイラのおかげでありません。しかし、FSP生成サンプルコードに習い、今後はC99以降の書き方を採用します。

いわゆるLチカサンプルコードであっても、なおざりにできない例です。そこで、基になったFSP生成のBare Metal BlinkyとMinimalスケルトン(骨格)の差をまとめます。

Bare Metal Blinky生成方法

各種周辺回路サンプルコードは、FSPとは別に評価ボード毎に提供されます。しかし、Bare Metal Blinkyだけは、FSPで生成可能です(FSPと評価ボード毎の周辺回路サンプルコードは、コチラの関連投稿を参照)。

その狙いは、筆者のような古いC記述者へ新しい記述法を知らせる、または、Blinkyと周辺回路無しのMinimalなスケルトンとの差分を知らせる、などが考えられます。

FSP生成Bare Metal Blinkyは、通常の新規プロジェクト作成方法と同じ、ファイル>新規>Renesas C/C++ Project>Renesas RAクリックが最初の手順です。ダイアログに従って手順を勧めると、最後にBare Metal – BlinkyかMinimalかの選択が可能です。

Bare Metal Blinky生成方法
Bare Metal Blinky生成方法

Blinky選択とFinishクリックで、g_ioport I/O Portスタックだけが配置済みの[Blinky]FSP Configurationパースペクティブが開きます。

[Blinky] FSP Configurationのスタック
[Blinky] FSP Configurationのスタック
念のため、Generate Project Contentをクリック後、src>hal_entry.cを開くと、1章で示したC99以降の書き方で記述したBlinkyサンプルコードが生成されます。

Bare Metal BlinkyとMinimalの差分

Bare Metal Blinky(左)とMinimal(右)の差分
Bare Metal Blinky(左)とMinimal(右)の差分

BlinkyとMinimalスケルトンの差は、hal_entry()のTODO: add your own code hereの下にBlinkyコードが有るか無いかだけです。FSP Configurationも全く同じです。

つまり、IOPORT未使用のアプリケーションは無いので、例えMinimalと言えデフォルトでg_ioport I/O Portスタックは配置済みで、そのスタック利用例がBlinkyという訳です。

FSP生成Bare Metal Blinkyに習い、筆者も今後はC99以降の新しい書き方でCソースコード記述をしていきます。

RAテンプレート仕組み

ルネサスRAファミリテンプレート(ベアメタル編)を3月末目標に開発中です。サンプルコード活用・流用によるアプリケーション開発が容易なことが、弊社テンプレートの特徴です。このテンプレート仕組みを “少しだけ(!?)” 説明します。

全部説明すると、読者ご自身でテンプレートを開発し、購入者数が減るかもしれないからです😂。

仕組みまとめ

MCU開発者の最初の壁に穴をあけるテンプレート
MCU開発者の最初の壁に穴をあけるテンプレート

テンプレートの仕組みを “少し” しか説明しないので、まとめを最初に示します。

MCUアプリケーション早期開発は、ベンダ提供の公式サンプルコード活用・流用が王道です。しかし、単機能の利用例を判り易く示すことが目的のサンプルコードでは、複数機能の並列実装が困難です。

MCU開発の最初の壁が、この「サンプルコードを、どのように実開発へ利用するか」です。

既に弊社テンプレートの購入者様、または上級者は、この壁を突破し効果的サンプルコード活用アプリケーション開発方法を知っています。Know-how(ノウハウ)です。

サンプルコード利用時の課題は、「無限ループ」です。

この課題に、弊社テンプレートは時分割で対応しました。説明を更に加えると、読者がご自分でテンプレート相当を開発される危険性がありますので、仕組み説明はここまでにします。

以降の章は、サンプルコード課題の具体例を示します。また、この課題が生じる原因、特にRAファミリ開発でFSPサンプルコードが重要である訳を説明、最後にテンプレートのメリットを示します。

RAファミリに限らずプロトタイプ開発や早期アプリケーション開発が目的の弊社テンプレートにご興味がある方は、テンプレートサイトに主要ベンダテンプレートが各1000円で販売中、概要は無料ダウンロード可能です。

※RAファミリテンプレート(ベアメタル編)も1000円予定。FreeRTOS対応アプリケーションテンプレートのみ2000円。RAファミリテンプレートもV2以降でRTOS対応予定。

販売テンプレートには、本稿で説明できない多くの工夫も実装済みです。ダウンロード概要を読んで、自作されるよりも、弊社から是非ご購入ください😌。

サンプルコード課題の具体例

評価ボードテストプログラム構造(FPB-RA6E1の例)
評価ボードテストプログラム構造(FPB-RA6E1の例)

サンプルコードを実開発へ利用する時の課題、具体例を示します。

RAファミリ評価ボードのテストプログラム:TPです(プロジェクト名:quickstart_fpb_re6e1_ep)。電源投入後、搭載LEDが点滅し、SW押下げで点滅間隔が変わり、評価ボードの正常性をテストします。

このTPのuser_main部分を抜粋しました。評価ボードにより多少異なりますが、基本動作は同じです。

LED点滅間隔は、無限ループ内のR_BSP_SoftwareDelay(g_delay)が決めます。このR_BSP_SoftwareDelay処理中は、MCUを独占するため、他の処理はできません(割込み処理は除く)。

MCUの並列処理は、RTOS利用が常套手段ですが、RTOS理解やベアメタル比大きな処理能力とRAMが必要です。

そこで、RTOSを使わずにベアメタルで並列処理をするため、LED点滅を時分割処理し、空き時間に別処理を実行するのが、テンプレートの仕組みです。

テンプレートの仕組み
テンプレートの仕組み

サンプルコード課題の原因

サンプルコードの構造は、基本的な「初期設定」+「無限ループ処理」です(基本のキ:組込み処理参照)。

この構造で、①内蔵周辺回路の初期設定 → ②周辺回路の監視(時間消費も含む)→ ③監視結果の処理実行を行います。②と③を、無限ループ内で繰返します。

①初期設定と③結果処理は、開発アプリケーションへそのまま流用ができます。問題は、結果処理以外の無限ループ内が全て監視(時間消費)になる点です。監視中は、他の処理はありません。

つまり、周辺回路のMCU「専用」利用例という訳です。専用ですから、監視結果の処理実行が有ろうが無かろうが問題はありません。

ところが、1つの無限ループ内へ、単純に別周辺回路の「②監視と③結果処理」を入れると、無限ループは、周辺回路「専用」から「共用」へ変ります。

共用する他の周辺回路の監視結果処理の実行有無に応じて、もう1つの周辺回路の監視結果起動間隔も変わります。起動間隔が変わっても問題ない場合もありますが、多くの場合、問題でこれが課題です。

例えば、ウオッチドックタイマ定時リセットや、前章のLED点滅間隔などです。

共用無限ループ内の別サンプルコード処理有無により、当該サンプルコード処理間隔が変わるという問題は、開発初心者には簡単に解決できない大きな壁:課題です。

FSPサンプルコードが重要な訳

FSP構成とGUI設定の様子
FSP構成とGUI設定の様子

RAファミリ共通のHAL API生成ツールがFSPです。FSPのBoard Support Package (BSP)とHardware Abstraction Layer (HAL)Driversが、評価ボードとRA MCU差を隠蔽し、RAファミリ共通APIをGUIで生成します。

Boardは、評価ボードを指しますが、ユーザ独自開発ボードでも、BSPだけを変更すれば、評価ボードを使って開発したソフトウェアが、そのまま独自開発ボード上でも動作します。

つまり、FSPは、プロトタイピング開発に適したツールです。RAファミリアプリケーションの早期開発ポイントは、FSP活用です。但し、FSPソフトウェア開発者は、知っておくべき作法があります。

例えば、2章で示したGPIO制御前後のR_BSP_PinAccessEnable()やR_BSP_PinAccessDisable()などです。これらは、BSP GPIOレジスタの電圧レベルアクセス制御許可/禁止を設定します。

仮に、R_BSP_PinAccessEnable()をコメントアウトすると、ビルドは成功しますがLEDは点滅しません。ワーニングなどもありませんから、作法を知らないと点滅しない原因は、まったく不明になります。

これらは、GPIOアクセスとセットで知るべき作法です。このような作法は、分厚いFSPユーザマニュアルのどこかに記載されているハズですが、ルネサスエキスパートが提供するサンプルコードからセットで抜き出し、そのまま利用する方が簡単です。

※BSP GPIOアクセスの代わりに、上記許可/禁止追記不要なHAL GPIOアクセスもあります。コレも作法の1つです。

また、ルネサス独自内蔵周辺回路:イベントリンクコントローラのサンプルコードなども、同一MCUコア利用の競合他社差別化に役立つかもしれません。
※イベントリンクコントローラは、MCUを介さずに周辺回路間の連携動作が可能なハードウエア。

マニュアルよりもサンプルコードを読み、評価ボードで試す、“習うより慣れよ” です。

FSPサンプルコードは、このような作法や差別化ヒントが詰まった宝庫です。RAファミリアプリケーション開発には、必読書です。

FSP開発例はコチラ、評価ボードサンプルコードは、コチラの関連投稿も参照ください。

テンプレートメリット

本稿では、しばしば “そのまま” という太字キーワードがでてきます。MCUアプリケーション開発は、ベンダ公式サンプルコードが、そのまま利用・活用する部分と、開発者が “工夫を加える部分” とを、素早く見極める目:Know-howも必要です。

Know-how獲得には、弊社テンプレートとMCU評価ボード+Baseboardが、お役に立てると思います。テンプレートもアプリケーションの1つなので、テンプレートへ追記した豊富な日本語コメントで、そのまま流用している部分と、工夫を加えた部分がソースコード上で確認できるからです。

テンプレートを活用し、アプリケーションをプロトタイピング、次ステップでプロトタイプアプリをチューニングし、完成度を上げます。

プロト目的は、アプリ早期開発、この目的に、ベンダ公式サンプルコード流用・活用と弊社テンプレートを利用します。

既製品の流用・活用・利用は、物足りなく感じる方もいるかもしれません。しかし、弊社テンプレートは、チューニング時、開発者が工夫を追加できる余地がいくらでもあります。アプリ完成度向上には、ご購入者独自の工夫も大切ですので、ご安心ください😁。

LibreOffice 7.3 WriterとWord 2019互換性

Interoperability of Office Word and LibreOffice Writer
Interoperability of Office Word and LibreOffice Writer

2022年2月2日、LibreOffice 7.2 Communityが7.3へ改版されました。Microsoft Officeとの互換性重視の改版です。そこで、Word 2019 → LibreOffice 7.3 Writer読込み、LibreOffice 7.3 Writer → Word 2019読込みの試行結果を示します。

Word ⇋ Writer相互運用性は、かなり向上しました。

互換性試行条件

Microsoft Office Word 2019をWord、LibreOffice 7.3 Community WriterをWriterと略します。

試行条件(OSは、Windows 10 Pro 21H2使用)
1) Wordで原稿作成(作成拡張子docx)
2) Word原稿文書を、Writerで編集保存(保存拡張子docx、またはodt)
3) Writer編集文書を、Wordで再編集(拡張子docx)

拡張子の違いは、まとめ章の後に説明します。また、Word原稿は、前投稿メタバースとIoTを例文として流用します。

Word原稿 → Writer読込み

Word文書をWriterで開く(拡張子docx)
Word文書をWriterで開く(拡張子docx)

1行当たりの表示文字数が異なりますが文章(テキスト)は、Writer読込みに問題はありません。改行も正しく読込まれています。

図のレイアウト崩れは、「図の上下折返し」がWordデフォルト、Writerデフォルト「左右動的折返し」と異なるためです。Writer側の図を選択後、【 H2 】インターネット進化版…の後へ移動し、図の大きさを段落間に調整するとWord原稿と同じレイアウトになります。

試行では、このWriter調整後保存します。ファイル形式の確認は、Word形式を選択します。なお、ODF形式で保存すると、ファイルサイズが992KBから521KBへ小さくなります。

ファイル形式の確認でWord形式を選択
ファイル形式の確認でWord形式を選択

Writer編集 → Word読込み

Writer編集保存ファイル拡張子は、docxです。保存ファイルをWordで開くと、最初のWord原稿と同じものが、表示文字数も含め再現されます。文章や図表のレイアウト崩れなどもありません。

Writerのdocxファイル出力は、Word互換性が高いことが判ります。

まとめ:互換性評価結果

完成した文書の配布は、PDFが基本です。しかし、文書の開発中は、異なるアプリケーションやOS環境での相互運用もあり得ます。相互運用時、異種環境でも100%文書互換性があると便利です。

本稿は、Word作成docxファイルを、Writerで編集後docxファイルへ保存、最後にWord再編集を試行し、従来比、LibreOffice 7.3 Writerは、Word相互運用性が高まったことを示しました。ファイル拡張子は、全てdocxを使いました。

WordのdocxファイルをWriter読込み時、テキスト読込みは改行含め問題無し、図表レイアウト崩れは手動での修正が容易です。一方、Writerのdocxファイル出力におけるWord読込みは、テキスト図表ともに問題ありません。

従って、Word ⇋ Writer相互運用ができるレベルに達したと評価します。

大サイズWord文書、Excel/PowerPoint文書のLibreOffice運用については未調査です。

まとめは、以上です。

 

補足として、ODFファイル拡張子と相互運用向上Tipsを示します。

Open Document Format(ODF)拡張子

ODFは、完全オープンなISO標準ファイル形式です。異種アプリケーション/OS間のファイル相互運用が、ODFの目的です。

Windows/Mac/Linuxマルチプラットフォーム対応のLibreOfficeは、デフォルトでこのODFファイルを扱い、拡張子が下記です。

・odt(LibreOffice Writer文書ファイル)
・ods(LibreOffice Calc表計算ファイル)
・odp(LibreOffice Impressプレゼンテーションファイル)

各ODFファイルは、Google Workspaceも対応済み、また、Microsoft Officeも自社独自ファイル形式(docx/xlsx/pptx)に加え、ODF形式へも対応しました。

相互運用性は、アプリケーションや実装ODFバージョンなどにより100%互換には至っておりません。不足分は、本稿で示したような手動での対応が必要です。不足分の程度により相互運用可否が決まります。

少なくともベンダ囲い込みや、ライセンス使用料を気にせずに運用できるメリットが、ODFにはあります。

相互運用向上Tips

2章でdocxファイルよりもodtファイルの方が、保存サイズが小さいことを示しました。そこで、初めからWord原稿をodtファイルとして保存 → Writer編集 → Word再編集の相互運用性を、2章docxファイル原稿時と比較しました。

odtファイルは、Word再編集の読込み時、図表に加え文書もレイアウト崩れが生じました。Tipsは、以下です。

・Word ⇋ Writer相互運用文書は、docxファイル編集保存が良い
・相互運用文書レイアウト崩れを避けるには、文書(テキスト)と図表を分離、最終稿のみで図表レイアウトが良い
・Wordでは苦手な日本語文字数取得が、Writerは容易

文字数取得は、要約作成時に便利です。複数範囲をカーソルで囲むと、Writer下段ステータスバーにトータル文字数が表示されます。弊社ツイッターの要約作成に活用中です。

LibreOffice 7系の更新は、Officeと相互運用性を更に高めるよう予定されています。これにより、例示したWriter側の図表レイアウト崩れなども解消すると思います。GUIなどのアプリ操作性は、単なる慣れの問題です。

Windows/Mac/Linuxマルチプラットフォーム動作、相互運用性も向上中の無償LibreOfficeを、Microsoft Office代替Plan Bとして気軽に活用してはいかがでしょう。

弊社LibreOffice関連投稿は、コチラを参照ください。

メタバースとIoT

コロナ過での海外出張、特に日本帰国時が大変です。(少し長い!)出国時帰国時記事で良く判ります。デジタル達人でさえこうですから、一般人の肉体的、精神的負担は計り知れません。

COVID-19が生んだコンタクトレス・テクノロジ、メタバースやアバターは、パンデミック社会生活の負担解消が目的です。また、IoTとも無関係ではありません。

インターネット進化版メタバース

インターネット進化版メタバース構成
インターネット進化版メタバース構成

電子メールやウェブサイトを生んだインターネット、その進化版がメタバースです。世界中のコンピュータやネットワーク内で構築される3次元仮想空間とその提供サービスです(Wikipediaより)。

SNSのMeta(旧Facebook)やMicrosoftが、メタバースに注力するのは、必然です。巨大インターネット企業GAFAMの次の収入源、ビジネス領域だからです。
※Metaverseは、meta(超)+universe(宇宙)の造語。
※GAFAMは、Google、Apple、Facebook、Amazon、Microsoftのこと。Big Fiveとも呼ばれる。

これら企業のメタバースは、「現実」の人の移動や接触無しに、安全でより効率的な社会生活ができる「仮想空間」をリアルに提供します。仮想空間内の「本人」が、アバターです。

インターネット進化版メタバースは、COVID-19パンデミック規制が例え終息したとしても、ウイルス耐性を持つ仮想空間による新しい社会生活基盤を全世界に与え、経済活動もこの中で行われます。電子メールやSNS、ウェブサイト同様、生活必需基盤となるでしょう。

メタバース内のなりすまし防止、安全性や本人を保証する要素技術がセキュリティです。メタバース入口のWindows 11のTPMもその1つと言えそうです(Windows 11 TPMは、コチラの関連投稿を参照)。

デジタル後進国日本

江戸時代の鎖国や国民性も影響しているデジタル後進国日本は、最新情報の海外調達でも障害や人的負担が大きいことが、最初の2記事から判ります。

アジア唯一のG7国:日本も、最新情報を遅延なく入手し続けないと、後進化に拍車がかかるかもしれません。※劣化日本の傾向と対策は、お時間があればコチラの関連投稿も参照ください。

AI翻訳も身近になりましたが、IoT MCU開発者は、和訳に拘らず英文による情報入手が効率的なのは明らかです。

IoT進化

全てのモノがインターネット接続するIoTも、メタバースにより進化します。

現在は、主に自動車や産業機器などの「人間以外」のモノが対象です。メタバースでは、これら対象に「人間」も加わります。例えば、2~3年後実現の舐めると味がするテレビ。人間の味覚もネットで繋がります。

IoTデバイスは、モノのセンサデータAD化とネット登り方向への送信が主でした。メタバースにより、人間相手の下りデータDA化やGUIなども重要になりそうです。上下データ同時制御や高度GUIには、IoT MCU高性能化も必要です。

ゲームヘッドセットの視覚、聴覚の仮想化
ゲームヘッドセットの視覚、聴覚の仮想化

現在のゲームヘッドセットが提供する視覚、聴覚の仮想化に加え、触覚、味覚、嗅覚などの五感も仮想化できれば、より人間が使いやすいメタバースになります。

更に、エッジ/クラウドAIやロボット技術も加えれば、モノ対人間、人間(アバター含む)同士、人間対モノの繋がり実現のメタバースは、無限の可能性をIoTデバイスへ与えます。

同様に、

・熱さ・冷たさを判断する感覚
・空間の中で、自分の体がどこにあるのかを把握する感覚
・身体のバランスをとるための平衡感覚

など、五感に加えメタバースとの相性が良い三感覚の研究もあります。これらは、IoTデバイスとも相性が良さそうです。

メタバースは、モノから人間を対象に加えたIoTデバイスへ、多大なインパクトを与えると思います。

RAファミリ開発環境Tips

ルネサス統合開発環境:e2 studioが、2022-01へバージョンアップされました(2022年1月16日号TOOL NEWS)。RAファミリは、「ソフトウェアパッケージ(=FSP)が同梱されたインストーラをダウンロードしインストールを行うこと」と、アップデート方法に注意書きがあります。

ところが、リンク先インストーラのe2 studioバージョンは、本日時点で昨年12月9日のFSP v3.5.0更新時、2021-10のままです。e2 studioは旧バージョンのため、2022-01へ手動にてアップグレートが必要です。

RAファミリ開発環境 GitHub状況

上記のように、RAファミリ開発環境は

・統合開発環境:e2 studio
・FSP(Flexible Software Package)とFSP版数に対応した評価ボードサンプルコード

の2種類、サンプルコードを含めると3種類が、それぞれ別タイミングでバージョンアップします。

また、ダウンロード先がGitHub内にあるため、RAファミリ開発環境の全体像と役割を把握していないと、混乱が生じます。そこで本稿で、整理します。

ちなみに、本日時点のRAファミリ開発環境GitHub状況が下図です。

GitHub上のRAファミリ開発環境のFSPとe2 studio(橙色がニュースリンク先)
GitHub上のRAファミリ開発環境のFSPとe2 studio(橙色がニュースリンク先)
GitHub上のRAファミリ評価ボードのサンプルコード
GitHub上のRAファミリ評価ボードのサンプルコード

RAファミリ開発環境 全体像と役割

「主役はFSP、e2 studioは脇役」、これがRAファミリ開発環境の役割です。

従って、FSPバージョンアップ時は、新FSP用ワークスペースを作成し、ここへ、旧FSP開発アプリケーションをコピー(インポート)、新FSPワークスペースでRAアプリケーション開発を継続するのがお勧めの開発手法です。

※HAL API生成ツールがFSPです。つまり、HAL(Hardware Abstraction Layer)より上位のRAアプリケーションは、FSP版数に依存しないのが本来の姿です。現状のFSPは、HAL API自体も変わる可能性があり「下位互換性」が未保証のため、安全策をとります。

もちろんe2 studioバージョンアップ時も別フォルダへインストールすれば、新旧両e2 studioの併用が可能です。但し、脇役e2 studioは、主役FSPほどの安全策は不要です。

例えば、前章のFSP v3.5.0インストーラのe2 studio 2021-10を手動更新(e2 studio>ヘルプ(H)>更新の検査クリック)し、2021-10へ上書きインストールした場合は、初めにインストールしたC:\Renesas\RA\e2studio_v2021-10_fsp_v3.5.0フォルダへ、e2 studio 2022-01が上書き更新されます(赤字v2021-10部分は不変)。

手動更新が成功したかを確認するには、e2 studio>ヘルプ(H)>e2 studioについて(A)をクリックし、下記ダイアログVersion:2021-10部分が、2022-01へ変わったことを目視確認します。

e2 studio 2021-10の手動2022-01更新確認方法
e2 studio 2021-10の手動2022-01更新確認方法

主役FSP更新、脇役e2 studio同一版対処

e2 studioはバージョンアップなし、FSPのみバージョンアップする場合は、GitHubからFSP_Packs_<version>.zipをダウンロードしインストールすれば、FSPのみの更新も可能です。この場合は、e2 studio内で新旧FSPが選択可能です。

この場合も、新旧FSPで開発アプリケーションのワークスペース分離が無難です。

理由は、プロジェクトのFSP設定ファイル:configuration.xmlにFSP利用版数が記述されており、旧FSPを新FSPへ変更する場合、下記ワーニングが表示されるからです。OKクリックで新FSPがアプリケーションへ適用されます。

アップグレートFSPへの変更方法とワーニング表示(FSP v3.4.0→v3.5.0の例)
アップグレートFSPへの変更方法とワーニング表示(FSP v3.4.0→v3.5.0の例)

利用FSP変更後、Generate Project Contentをクリックし新FSPでのHAL APIを再生成、当該プロジェクトクリーン、再ビルドでコンパイル成功すれば、同じアプリケーションで新旧FSPが使えます。

FSPアップグレートは、新規RAファミリ追加、新規周辺回路追加など、「旧FSP提供以外の新規追加」が主な内容ですので、基本的に旧FSP開発アプリケーションは、新FSPでもコンパイル成功するハズです。

評価ボードサンプルコードがFSP版数対応なのは、これら「新規追加の使用例」を示すためです。(もちろん、旧FSPバグ修正も含む)。

※但し、RTOS関連アップデートもFSP更新に含まれることには注意してください。RAベアメタル開発では、新旧FSPコンパイル成功確率は高いハズですが、RTOS開発時は、新FSPリリースノートに目を通し、RTOS関連の変更有無確認が必要です。

コンパイル不成功の時は、新FSP環境で当該プロジェクト再設計が必要になります。

まとめ

RAファミリ開発環境は、新旧版が全てGitHub内にあり、統合開発環境e2 studio、FSP、評価ボードサンプルコードのアップグレートがそれぞれ別タイミング、付属説明も簡易なため混乱します。混乱回避のためにRAファミリ開発環境の役割とFSP更新Tipsを示しました。

FSPが主役、e2 studioは脇役、これがRAファミリ開発環境の役割です。FSPアップグレート時は、新旧FSPワークスペースを分離し、新FSPワークスペース内で再度HAL APIを生成、生成HAL APIがそのまま旧アプリケーション上でコンパイル成功すれば、安全にFSP更新ができます。

おまけ:Windows 11アップグレート

WIndows 11アップグレート可能通知
WIndows 11アップグレート可能通知

弊社Windows 10 21H2に、Windows 11アップグレートOK通知が届きました。

弊社のPCは、IoTベンダのMCU開発ツールが主役、Windowsは脇役です。今すぐの11アップグレードはNGですので、「今はWindows 10の使用を継続します」をクリックし対処しました(なお、Windows 10 21H2大型更新方法は、コチラの関連投稿を参照)。

多くのIoT MCU開発ツールの公式推薦Windows OSは、未だWindows 10です。

公式推薦OSが、Windows 11に変った後に11化しても遅くはありません。今秋の11大型更新に向け11も進化中ですので、状況観察します。

Cortex-MとRISC-V

NVIDIA買収先で成立見通しが未だに不透明なARM社Cortex-Mと非営利団体運営のRISC-V、両MCUコアの顧客利用動向記事が公開されました(2022年1月14日、ITmedia)。

極簡単に要約すると、ARM顧客の多くが現在NVIDIAと競合関係にあるため、買収成立時、Cortex-M利用の顧客将来製品の代替コア用意(=Plan B)が必要で、代替コアにRISC-Vが急浮上している、という内容です。

ARM顧客とは、エッジAIや車載半導体製品を供給中のMCUベンダ(Renesas、NXP、STマイクロなど)を指します。Plan Bは、代替案と訳されます。これは、実行案Aのトラブル時、Aの次のBが、第2の案という意味です。

半導体業界は常に変化し、これに伴い案A達成に何らトラブルが無くても、その将来性に変化が生じる可能性もあります。“Backup”としてのPlan B必要性を感じた記事です。

オープンアーキテクチャRISC-V

Cortex-M代替として急浮上のRISC-V
Cortex-M代替として急浮上のRISC-V

RISV-Vは、カルフォルニア大学バークレイ校開発のオープンアーキテクチャMCUコアで、Cortex-MのようなCISC(Complex Instruction Set Computer)命令系を、より縮小した命令系(Reduce Instruction Set Computer)へ変え、低電力動作に適すなどの特徴を持ちます。

Cなどの高級言語ソフトウェア開発者にとっては、CISC/RISC差はあまり気になりませんが、コンパイラを開発するMCUベンダにとっては、他社差別化を生む重要なパラメタです。

MCU性能の支配項は、

・MCUコア(CISC or RISC)
・コンパイラ
・製造プロセス(≒最高動作周波数)
・内蔵周辺回路

の4項目で、ARM Cortex-M使用中ベンダなら、MCUコアとコンパイラはARM供給品なので各社共通です。つまり、製造プロセスと内蔵周辺回路でしか他社差別化手段がありません。

NVIDIAがARMを買収した場合、競合他社へのMCUコアやコンパイラ供給に、自社利用品と差を付ける可能性もあります。Cortex-M使用中のMCUベンダ各社が、ARM買収成立を嫌う理由が、これです。

そこで、オープンアーキテクチャでコンパイラ開発自由度も高いRISC-Vコアが、競合他社のCortex-M将来製品コアのPlan Bとして急浮上した訳です。

ARMコアMCU開発で出遅れたRenesasは、早々とRISC-V対応MCU開発を発表しました。NXPやSTマイクロのRISC-Vコア利用は不明ですが、Renesas同様、Plan Bを持っているのは確実です。

我々開発者が、今すぐRISC-V開発を始める必要性は低いと思います。むしろ、Cortex-M代替に、低価格高性能無線機能付きESP-WROOM-32を習得した方が役立つと個人的には思います。RISC-VESP-WROOM-32の関連投稿は、リンク先を参照してください。

MicrosoftのOffice、Windows分離売却可能性

Microsoftが買収を発表した大手ゲーム会社Activision Blizzard
Microsoftが買収を発表した大手ゲーム会社Activision Blizzard

半導体業界の大きな一角を占めるMicrosoftの大手ゲーム会社Activision Blizzard買収ニュースが1月19日発表されました。買収理由は、コチラの記事が示すメタバースです。COVID-19が大きく影響しているコンタクトレス・テクノロジのメタバースは、関連投稿の3章を参照してください。

Microsoft動向で気になるのは、確定内容ではありませんが「OfficeとWindowsを売却すべき」という1月17日発表記事です。Microsoftは営利団体です。Windows 11不具合の多さ、新機能の魅力無さなど、最近のWindowsに対するMicrosoftの力の入れようの低下とも符合します。

OfficeやWindows(特にGUI)は、既に製品完成の域に達しています。手間暇が掛かるDOS-VベースのコンシューマーOS企業と、最新コンタクトレス・テクノロジやAzure、高度セキュリティ投資との親和性も高いパブリッククラウド企業とは、別会社の方が、利用者、投資家にとっても判り易いと思います。

エンタープライズ顧客重視で将来性も高いパブリッククラウド企業地位を、MicrosoftがAmazonやGoogleよりも高めたいなら、足枷の可能性もあるOffice、Windows分離売却も可能性ありと思います。

Plan B評価の違い

M&A:Mergers(合併)and Acquisitions(買収)は、半導体業界では当たり前です。激変する半導体業界のMCUベンダとMicrosoft動向記事を紹介しました。

日本社会では、Plan B評価がまだ低いのですが、MCU開発者として、「個人レベルのPlan B必要性」を感じた記事でした。日本人と外国人上司のPlan B評価の違いは、コチラの記事を参照してください。

TPM SoC Microsoft Plutonプロセサ搭載PC 5月発売

Microsoft Plutonプロセサとは、Windows 11アップグレート要件のTPMとCPUをSoCで一体化し、より強固なセキュリティを実現したWindows PCのことで、2022年5月発売予定のRenovo ThinkPad Z16/Z13が初のPlutonプロセサ搭載PCです。

Microsoft Plutonプロセサ

Microsoft Pluton(出展:Microsoft News Centor)
Microsoft Pluton(出展:Microsoft News Centor)

現行のTPMは、CPUとは別チップです。このため、TPMセキュリティを破る方法が公開されています。

この対策にMicrosoftは、TPMをSoC(System on Chip)でCPUと一体化した「Microsoft Plutonプロセサ」を、AMD、Intel、Qualcommと共同開発すると2020年11月に発表しました。

Microsoft Plutonプロセサ搭載PCのSoCセキュリティサブシステムの更新は、Windows Updateと連動しており、定期的なシステムセキュリティ更新が実行されます。

スマホ、Xbox標準のセキュリティ一体化プロセサ

SoCでセキュリティ機能を一体化したプロセサは、スマホでは標準的、ゲーム機のMicrosoft Xbox Oneでも2013年に既に導入済みです。また、コチラの関連投稿4章:TrustZone内蔵Cortex-M33にも近づいた感じがします。

スマホやXboxに遅れること約10年目の2022年、一般的なPCへもMicrosoft Plutonプロセサ(Ryzen PROシリーズ+SoC TPM)が、Renovo ThinkPad Z16/Z13へ導入されました。終わりが無くエンドレスなセキュリティ対策の実例です。

ThinkPad Z13(出展:PC Watch記事)
ThinkPad Z13(出展:PC Watch記事)

Pluton PCの今後

気になるのは2点。1つは、Microsoft Plutonプロセサが、Windows 11以降(例えばWindows 12)の一般PC要件になるかもしれない点😥、もう1つが、自己責任で「TPM 2.0回避アップグレート」したTPM無しWindows 11のTPM更新(Windows Update)はどうなるか、という点です。

2つ目に関しては、昨年TPM 2.0を回避して11アップグレートした先進ユーザが、様々な情報をネットに投稿してくれると思いますので期待しています。

仮にTPM以外の月例セキュリティUpdateは成功、今年秋のWindows 11大型更新もTPM 2.0装着PC同様成功するなら、2025年10月サポート終了Windows 10の後継OSとして、11の選択もあり得ます。OSアップグレードに対しPCハードウエアの著しい性能向上をMicrosoftが求めなかった過去経緯ともマッチするのは、このアップグレード方法です。

もちろん、TPM 2.0非搭載リスクは、自己責任です。このリクスを根底から無くすには、PCのPluton PC化が必須です。Windows 11は、PC Pluton化への過渡期用OSで、だからこそ、TPM回避Windows 11インストールをMicrosoftが公式発表したのかもしれません。

セキュリティ起因のPluton PCが一般PCに普及すれば、次期Windowsは、Pluton PCを要件とするでしょう。今後もMicrosoft動向とWindows 11改良、TPM回避先進ユーザ情報に注視したいと思います。

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

RTOS vs. BareMetal
RTOS vs. BareMetal

2022年最初の投稿は、RTOSとベアメタルを比較します。RTOSを使わないベアメタルMCU開発者が多いと思いますので、RTOS開発メリット/デメリットをベアメタル側から評価、RTOSデバッグツール紹介とベアメタル開発の意味を考えました。

RTOS目的

Flexible Software Package構成
Flexible Software Package構成

ルネサスRAファミリのFlexible Software Package構成です。左上Azure RTOSやFreeRTOSの中に、ConnectivityやUSBがあります。これらMCU共有資源を管理するシステムソフトウェアがOSで、PCのWindowsやMac、Linuxと機能的には同じです。

Real-Time性が必要な組込み用OSをRTOSと呼び、FreeRTOSやAzure RTOSが代表的です。これは、IoT MCU接続先が、Amazon Web Services(AWS)クラウドならばFreeRTOSライブラリ、Microsoft AzureクラウドならAzure RTOSライブラリ(図のConnectivity)利用が前提だからです。

※2021年のIoTクラウドシェアは、コチラの関連投稿からAWS>Azure>GCPの順です。

RAファミリに限らず、クラウド接続のIoT MCUは、これらRTOSライブラリを使ったRTOS開発になります。

RTOSメリット/デメリット

例えば、ベアメタルでUSB制御を自作する場合は、USB 2.0/3.0などの種類や速度に応じた作り分けが必要です。ライブラリがあるRTOSなら、USBポートへの入出力記述だけで利用可能です。RTOSが共有資源ハードウェア差を吸収し、アプリケーションが使い易いAPIを提供するからです。

RTOSの資源管理とは、MCUコア/Flash/RAM/周辺回路/セキュリティなどの共有資源を、アプリケーション側から隠蔽(≒ブラックボックス化)すること、とも言えます。

RTOSアプリケーションは、複数タスク(スレッドと呼ぶ場合もあり)から構成され、タスク間の優先制御もRTOSが行います。開発者は、単体処理タスクを複数開発し、それらを組み合わせてアプリケーションを構成します。RTOSアプリケーション例が下図、灰色が開発部分、コチラが関連投稿です。

Data flow diagram for a smart thermostat(出展:JACOB'S Blog)
Data flow diagram for a smart thermostat(出展:JACOB’S Blog)

RTOS利用メリット/デメリットをまとめます。

メリットは、

・RTOSライブラリ利用により共有資源活用タスク開発が容易
・移植性の高いタスク、RTOSアプリケーション開発が可能
・多人数開発に向いている

デメリットは、

・複数タスク分割や優先順位設定など、ベアメタルと異なる作り方が必要
・共有資源、特にRAM使用量がタスク数に応じて増える
・RTOS自身にもバグの可能性がある

簡単に言うと、RTOSとベアメタルは、「開発作法が異なり」ます。

ソフトウェア開発者は、RTOS利用と引換えに、自己流ベアメタル作法を、RTOS作法へ変えることが求められます。RTOS作法は、標準的なので多人数での共同開発が可能です。もちろん、ベアメタルよりもオーバーヘッドは増えます。このため、RTOS利用に相応しい十分なMCUコア能力も必要です。

RTOSタスク開発 vs. ベアメタルアプリケーション開発

最も効果的なRTOS作法の習得は、評価ボードを使って実際にRTOSタスク開発をすることです。弊社FreeRTOSアプリケーションテンプレートは、この例です。

それでも、RTOSタスク開発作法を文章で記述すると、以下のようになります。

開発対象がアプリケーションからタスク(スレッド)へ変わることが、ベアメタルとの一番の違いです。Windowsタスクバーにあるフィルダ表示や、ペイントなどと同様、タスクは、単機能の小さいアプリケーションとも言えます。

このタスクを複数開発し、複数タスクを使ってRTOSアプリケーションを開発します。タスクには、それぞれ優先順位があり、他のタスクとの相対順位で実行タスクがRTOSにより決まります。タスクの状態遷移が、RTOSへの備え:第2回、タスク管理で示した下図です。

FreeRTOS Task States
FreeRTOS Task States

ベアメタルアプリケーションとは異なり、優先順位に応じてタスクが実行(Running)され、その実行も、定期的に実行可能状態(Ready)や待ち状態(Suspended)、停止状態(Blocked)へRTOSが変えます。これは、リアルタイムかつマルチタスク処理が、RTOSの役目だからです。遷移間隔などは、RTOS動作パラメタが決めます。

ベアメタル開発は、開発者が記述した通りに処理が実行されますが、RTOS開発のタスク実行は、RTOS任せです。RTOS開発難易度の上がる点が、ここです。

一般的なIoT MCUは、シングルコアですので、実行タスク数は1個、多くの他タスクは、Not Running(super state)状態です。RTOSがタスクを実行/停止/復活させるため、スタックやRAM使用量が急増します。

これら文章を、頭の中だけで理解できる開発者は、天才でしょう。やはり、実際にRTOSタスクを開発し、頭の中と実動作の一致/不一致、タスク優先順位やRTOS動作パラメタ変更結果の評価を繰返すことで、RTOS理解ができると凡人筆者は思います。

ベアメタル開発者が手早くRTOSを理解するには、既にデバッグ済みの複数RTOSタスク活用が便利で、FreeRTOSアプリケーションテンプレートは、この要求を満たしています。概要は、リンク先から無料ダウンロードできます。

文章でまとめたFreeRTOS解説が、コチラの弊社専用ページにあります。また、本ブログ検索窓にFreeRTOSと入力すると、タスク開発例などが参照できます。

RTOSデバッグツール

percepio tracealyzer
percepio tracealyzer

さて、RTOS作法に則ってタスク開発し、RTOS動作パラメタも適切に設定しても、思ったように開発タスクが動作しない時は、ブラックボックスRTOS自身のバグを疑う開発者も多いでしょう。RTOSのバグ可能性もありえます。

この疑問に対して強力にRTOS動作を解析できるFreeRTOSデバッグツールがあります。資料が無料でダウンロードできますので、紹介します。

※このツールを使うまでもなく、弊社FreeRTOSアプリケーションテンプレートは、正常動作を確認済みです。

まとめ:RTOS vs. ベアメタル

IoT MCUのクラウド接続 → 接続クラウド先のRTOSライブラリ必要 → RTOSライブラリ利用のRTOS開発が必要、という関係です。

RTOS開発は、ベアメタルと開発作法が異なる複数タスク開発です。タスクは、優先順位に応じてRTOSがMCU処理を割当てます。また、MCU共有資源がRTOSアプリケーションから隠蔽されるため、移植性が高く多人数での大規模開発にも向いています。

一方で、RTOSオーバーヘッドのため、ベアメタルよりも高いMCU能力が必要です。

シングルコアMCUでは、RTOSとベアメタルのハイブリッド開発は困難です。開発者がRTOSを利用するなら、慣れたベアメタル開発から、RTOSタスク開発への移行が必要です。

ベアメタル開発経験者が、効果的にRTOSタスク開発を習得するには、評価ボードと複数RTOSタスクが実装済みの弊社RTOSアプリケーションテンプレートの活用をお勧めします。

ベアメタル開発意味

RTOSのタスク処理待ち(セマフォ/Queue)を使うと、ベアメタルよりも排他/同期制御が簡単に記述できます。それでも、全てのMCU開発がRTOSへ移行することは無いと思います。様々なセンサデータをAD変換するエッジMCUは、ベアメタル開発、エッジMCUを複数個束ねクラウドへ接続するIoT MCUは、RTOS開発などがその例です。

MCU開発の基本は、やはりRTOS無しの「ベアメタル開発」です。

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

ベアメタル開発スキルを基にRTOSを利用してこそ、RTOSメリットを活かしたタスクやアプリケーション開発ができます。共有資源ブラックボック化、多人数開発のReal-Time OSは、「ベアメタル開発の補完」が起源です。

PC OSとは全く逆のこの生い立ちを理解していないと、効果的なRTOS利用はできません。近年MCU性能向上は著しいのですが、向上分をRTOSだけに振り分けられる程余裕はなく、IoTセキュリティなどへも配分する必要があります。

この難しい配分やRTOS起因トラブルを解決するのが、ベアメタル開発スキルです。弊社マイコンテンプレートは、主要ベンダのベアメタル開発テンプレートも販売中、概要ダウンロード可能です。

組込み開発 基本のキ:バックナンバー

2022年最初の投稿に、筆者にしては長文すぎる(!?)のRTOS vs. ベアメタルを投稿したのは、今年以降、RTOS開発が急速に普及する可能性があるからです。

クラウド接続からRTOS必要性を示しましたが、セキュリティなど高度化・大規模化するIoT MCU開発には、移植性の高さや多人数開発のRTOSメリットが効いてきます。

また、半導体不足が落ち着けば、RTOS向き高性能MCUの新しいデバイスが、各ベンダから一気に発売される可能性もあります。スマホ → 車載 → IoT MCUが、半導体製造トレンドです。

※現状のMCUコア関連投稿が下記です。
Cortex-M33とCortex-M0+/M4の差分
Cortex-M0からCortex-M0+変化
Cortex-M0/M0+/M3比較とコア選択

IoT MCU開発が複雑化、高度化すればする程、前章のベアメタル開発や、組込み開発の基礎技術:基本のキの把握が、開発者にとって益々重要になります。

組込み開発、基本のキ:バックナンバーを示します。年頭、基本を再確認するのはいかがでしょう?
組込み開発 基本のキ:組込み処理
組込み開発 基本のキ:IoT MCUセキュリティ



傾向と対策:日本低下

 

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

年内最後の投稿に、“日本の半導体産業はどうしてダメになったのか? 今だから分かる3つのターニングポイント”(@IT、2021年12月17日)を紹介し、国際地位低下傾向の日本と、IoT MCU日本開発者の対策を示します。

半導体と通信業界から見る日本低下傾向

半導体の研究・開発者から見た日本地位低下を、3度のターニングポイント失策から分析し、現状の日本半導体は、脇役へ滑り落ちていて、名脇役の存在感を示せるかは、「舵取り」(おそらく政治家や官僚)にかかっていると結論しています。

筆者、Massa POP Izumida氏は、もちろん日本人で、本ブログ筆者と同世代だと思います。80年代に就職、90年代世界第2位の経済大国日本で中堅現役、そして、総合順位31位へ低下した現状日本を実感されている技術者だと推測します。

ATM(Asynchronous Transfer Mode)通信の研究・開発者だった本ブログ筆者も、同じような経験があります。90年代、米国、欧州、日本のATM規格競争が勃発した時、日本案が世界規格になっていれば、現状と異なるネットワーク、通信業界になっていたでしょう。“たられば”の話です。

日本人特性

周囲の意見に「同調意識が強い」日本人の性格や特性は、コチラの記事にまとまっています。「単一民族島国の中」で、上手く生きていくための特性は、必然です。

ただ、舵取りや国際競争の時に、この特性が裏目に出たのが、日本地位低下原因の1つでしょう。現状も変わらない官僚主義は、コチラの記事でも判ります。

一般国民も含めた日本人の特性変化(≒国際化)には、「数世代に渡る長い時間」が必要です。

つまり、今の日本人特性は、「ボーダレスネットワークでワールドワイドに急変した世界の中」の日本低下傾向を、スグに阻止し復帰するには適していない訳です。

日本IoT MCU開発者対策(私案)

IoT MCU日本開発者が生き残るには、「日本人以外の第2の視点とPlan B」が必要です。

日本IoT MCU開発者の対策
日本IoT MCU開発者の対策

日本開発者の現役期間が50年としても、DNAに染み込んだ同調意識もまた簡単には変わりません。

対策は、一時的にせよ、欧米人の特性で自身のIoT MCU状況を捉えることです。欧米人特性は、ネット検索で見つかります。また、欧米に限らず、アジア人特性も日本人とは大きく異なります。

これら日本人外の特性・視点で現状把握を試すと、自分との差分が判り、対策に何をすべきかが見えてきます。これは、個人キャリアプランの中で、Plan Bの1つに相当します。

具体策は、個人により異なります。私の場合は、米語です。幸い、IoT MCU関連ドキュメントやセミナーは、殆どが米語ですので、材料は豊富です。敬語の利用が少ない米語は、効率的情報伝達と取得に優れています。

別策は、国際競争下で最後に生き残っている日本自動車業界の視点を借りることです。自動車業界は、ワールドワイドな視点で、研究開発を実践中です。生き残った主因です。その取組みや視点で、Plan Bを考えるのも良いと思います。

年末年始は、現状から少し距離を取れる時期です。日本人外の視点とPlan B検討は、いかがでしょう。

次回金曜投稿:1月7日

各種メンテナンスのため大晦日投稿はなし、年内は本稿が最後、次回金曜投稿は、来年1月7日です。

弊社サイトは、年中無休です。本年も弊社のご利用、誠にありがとうございました😌。
皆様、良いお年をお迎えください。