AI MCU

AI機能搭載の最新MCUを一覧表にまとめました。人物検出や機器異常検出などのAIアルゴリズム処理には、従来Cortex-M7クラスの高性能MPU(Micro Processor Unit)が必要でした。MPU比、低コストで低消費電力なAI MCUによるエッジAIメリットを示します。

Summary:AI MCUまとめ

AI機能搭載の最新MCU一覧
ベンダ AI MCU、コア AI特徴、AIアプリケーション AI開発ツール
STマイクロ STM32シリーズ
Cortex-M0+他コア対応
コア対応機械学習ライブラリ生成
ポンプ異常検出
NanoEdge AI Studio(専用)
NXP MCX Nシリーズ
Cortex-M33 x2(+NPU)
AI専用NPU処理
顔検出
MCUXpresso IDE(汎用)
ルネサス RAファミリ
Cortex-M85(+Helium)
汎用ベクタ演算Helium処理
人物検知/モータ故障検出
Reality AI(専用)

マイコンでAI」、STマイクロNXPルネサスが競演、2023年5月12日、MONOist記事をまとめたのが上表です。

記事によると、MCU大手3ベンダが、第7回AI・人工知能EXPO(春)2023年5月10~12日、東京ビックサイト会場で、表掲載AI MCUを使って、エッジAI実働デモ展示を行っています。

ChatGPTなどAI利用が一般化し始めました。組込み分野のMCUへもAI搭載の高機能化が始まります。

AI MCUアプローチ

STマイクロは、ソフトウェアでのAI処理、NXPは、専用ハードウェアNPU(Neural Processing Unit)でのAI処理、ルネサスは、汎用ベクタ演算ハードウェアHeliumによるAI処理と、3社3様のAI MCUアプローチです。

また、AI処理開発に、ソフトウェアアプローチのSTマイクロは、STM32コアに応じた専用機械学習ライブラリ生成ツール:NanoEdge AI Studioを使用、同じハードウェアアプローチですが、NXPは、汎用MCUXpresso IDEを使用、ルネサスは、専用Reality AIツール使用、などAI開発ツールも異なります。

NanoEdge AI Studioは、MCU開発者にAI専門知識が無くてもMCUコア性能に合わせたAI実装ができるそうです。

エッジAI MCUアプリケーションとメリット

Cortex-M85搭載RAファミリによるAI人物検出デモ(出展:ルネサス)
Cortex-M85搭載RAファミリによるAI人物検出デモ(出展:ルネサス)

各社のAI実働デモから、上図のような人物・顔検出と機器異常検出が、エッジAI MCUのターゲットアプリケーションのようです(関連投稿:RAファミリ最新情報)。

これらAI処理にMPUは使わず、小パッケージ、低コストの本稿AI MCUを使い、家電や機器内の既存MCUを置換えることで「装置構成はそのままに様々なAI機能を追加実装できる」これが、AI MCUのメリット、更に革命と言われる理由です。

Afterword:新たなMCU開発方法

実装AI機能により、求められるAI MCUコア性能もCortex-M0+からCortex-M85など様々です。それでも、MPUやGPU(Graphics Processing Unit)利用よりは、低コストエッジAIが実現できそうです。

従来MCUの置換えメリットだけでなく、AI MCUを使った新しい装置開発も面白いと思います。

各社AI MCUは、セキュリティ対応も強化されています。AI、IoTセキュリティ、RTOS…などなど、従来のCortex-M系ベアメタルMCU開発に加え、多くの新知識と追加開発がAI MCUに必要です。正直、食傷気味です😣。

従って、専門知識が無くてもAI実装できるツールなどは、大歓迎です。新しいMCUには、各種ツール活用の新しい開発方法を、拘りなく使える柔軟性も必要です(関連投稿:新しいMCUハードソフトの学び方)。

ツールを使っているうちに、専門知識や関連知識は、自ずと身についてくるハズです。



RAファミリ最新情報とFSP

ルネサスは、最近元気です。特にRAファミリMCUにその傾向が顕著です。RAファミリ最新情報を2件ピックアップし、ルネサスRAファミリソフトウェア開発の鍵:FSP習得の重要性を示します。

Cortex-M85搭載AI処理実装RAファミリ

Cortex-M85搭載RAファミリによるAI人物検出デモ(出展:ルネサス)
Cortex-M85搭載RAファミリによるAI人物検出デモ(出展:ルネサス)

2023年3月14日~16日、ドイツ開催embedded world 2023で、ルネサスは、Cortex-M85コア搭載のRAファミリへAI処理を実装し、人物検出へ適用したデモを行いました。

従来、人物検出アルゴリズム実行には、Cortex-M7クラスMPU(Micro Processor Unit)が必要でした。このCortex-M85搭載RAファミリにより初めてMCUでもAI処理可能となり、MPU比、低コストで低消費電力動作など革命が起こるそうです。

このCortex-M85搭載RA MCUは、2023年中にリリース予定です。

SDR搭載RAファミリサンプル出荷

SDR(Software Defined Radio)は、ソフトウェアにより無線機能の変更が可能なハードウェアのことです。Cortex-M33コアRAファミリに搭載するSDRは、Bluetooth 5.3 Low Energyまでの各種Bluetooth仕様に対応しました。

つまり、ソフトウェアを更新すれば、常に最新バージョンBluetooth準拠のMCUになる訳です。2023年4月11日、このRA MCUのサンプル出荷が始まりました。

SDR搭載RA MCUは、ルネサス初の22nm製造プロセスMCUです。但し、22nmロジックとは異なる製造プロセスの不揮発性メモリを混載封止したSIP(System In Package)版MCUです。

不揮発性メモリまで同一の22nmで製造し、さらに高速で製造原価を下げたMCUの提供時期は、未定です。SIP版で機能優先のサンプル出荷を開始したのでしょう。

RAファミリへ最新技術を適用する理由

これら最新技術は、従来のMCUファミリには搭載しづらいです。その理由が以下です。

先ずハードウェア的には、最新技術が22nmなど先端MCU製造プロセスをベースにしていること、また、IoT向きCortex-M33/M85コアのRAファミリの方が、従来コアへ最新技術を追加するより性能的にも導入し易いこと、などです。

次にソフトウェア的には、RAファミリが、新しいFSP(Flexible Software Package)で開発することも一因です。簡単に言うと、FSPはAPI生成ツールです(関連投稿:MCUベンダAPI生成ツール比較2020年版)。

FSPは、HALやBSPなどハードウェア依存部分を隠ぺいしつつ効率的MCUソフトウェア開発ができる
FSPは、HALやBSPなどハードウェア依存部分を隠ぺいしつつ効率的MCUソフトウェア開発ができる

IoT MCU製品は、従来のベアメタルソフトウェア開発へ、RTOSや通信、セキュリティなど様々な機能が追加されます。

これら追加機能は、製品毎に適用が大きく変わる可能性が高く、その変更に対し開発ソフトウェア流用性や、柔軟かつ素早い対応も求められます(前章SDR搭載RA MCUが一例)。

FSPは、BSP(Board Support Package)やHAL(Hardware Abstraction Layer)を利用しMCU個別ハードウェア依存部分を隠ぺいしつつ、効率的かつ柔軟にソフトウェアの早期開発ができるよう工夫されています。

最新ルネサスMCUファミリソフトウェア開発の鍵FSP

つまり、ルネサス最新技術を活用したIoT MCU製品の早期開発には、FSPを上手く使えることが重要です。

FSPが扱うソフトウェアは、従来のベアメタル開発だけでなく、RTOS(Azure RTOS/FreeRTOS)や通信、各種USB、TrustZoneセキュリティなどと広範囲に及ぶため、FSP活用にはコツや慣れも必要です。

逆に、この鍵となるFSPを開発者が習得すれば、RAファミリに限らずルネサス最新IoT MCU製品化に、大きく貢献できる訳です。FSPは、RAファミリ以外のルネサスMCU開発へも適用されています。

まとめ

最新RAファミリソフトウェア開発の鍵:FSP
最新RAファミリソフトウェア開発の鍵:FSP

最新技術搭載のルネサスRAファミリMCUは、今後急速に増えます。最新RAソフトウェア開発の鍵:FSPを習得し、ベアメタル/IoT MCUソフトウェア開発に貢献できるようスキルを磨きましょう。

FSP習得方法

弊社RAベアメタルテンプレート(1000円税込)は、効率的かつ効果的にFSP習得ができます。将来的には、RTOSへも対応したRA RTOSテンプレート(仮名)も開発予定です。

判り易い添付資料と低価格で入手性が良いFPB-RA6E1、または、FPB-RA4E1評価ボードと、Baseboardを利用すれば、どなたでもFSP提供サンプルコードを活用、流用したRAベアメタル開発が可能で、FSP利用のコツも掴めます。是非、ご活用ください。




Tips)最新FSP v4.3.0でも、RTOS開発に100%対応はしていません。例えば、Developer Assistanceは、ベアメタルHAL callback関数定義はできますが、FreeRTOS callback関数定義はできません。
今後のFSP改版で、RTOSへの対応も広がるでしょう。但し、FSP習得タイミングとしては、ベアメタル開発に完全対応済みの「今がチャンス」と言えます。



RAファミリクラウド開発環境提供

ルネサスは、クラウド上のMCU開発環境でRAファミリの開発ができる「クイックコネクトスタジオ」の提供を開始しました(2023年3月1日)。

ブラウザのみで使えるクラウド開発結果を、ローカル環境のe2 studioへダウンロード可能でRAファミリプロトタイプ開発の早期立上げに役立ちます。

クラウド開発の利用手順

クイックコネクトスタジオ利用手順(EK-RA2E1開発例)
クイックコネクトスタジオ利用手順(EK-RA2E1開発例)

クラウドMCU開発環境クイックコネクトスタジオの利用手順を、簡単にまとめます。

  1. クラウドクイックコネクトスタジオへログイン
  2. 画面右側のGETTING STARTに沿って操作
  3. 新規プロジェクト作成→RAボード選択→PMODモジュール選択→ビルド→開発Zipファイルをローカル環境へダウンロード
  4. クラウド開発Zipファイルをローカル環境e2 studioへインポート
  5. 手元に用意したRAボード+PMODモジュールで実動作確認

Zipファイルには、ハードウェア選択肢のRAボードとPMODモジュールのベアメタル開発サンプルコードが生成済みです。1~3で使うツールはブラウザのみ、新規プロジェクト作成からZipファイルダウンロードまで数分でできます。

クイックコネクトスタジオのクラウドハードウェア構成と同じものをローカル側に用意すれば、直に動作するサンプルコードが僅か数分で入手できる訳です。

クイックコネクトスタジオ利用により、プロトタイプ開発の早期立上げが実現可能です。

EK-RA2E1、EK-RA6M4評価ボード対応中

4月5日現在、クイックコネクトスタジオが対応しているのは、EK-RA2E1EK-RA6M4の2種RAファミリ評価ボードです。PMODモジュールは、通信関連がBluetoothとWi-Fi、センサ関連がフローセンサと湿度・温度センサです。

関連投稿:PMODモジュール

これらは、IoT製品向きの品揃えです。現在のハードウェア選択肢は少数ですが、今後、品揃えも豊富になるでしょう。

また、ベアメタル開発だけでなくRAファミリの得意分野FreeRTOSやAzure利用のRTOS開発や、セキュリティ強化TrustZoneへも、クイックコネクトスタジオが対応する可能性があります。

注)Cortex-Mxコアに比べTrustZoneなどのセキュリティ強化Cortex-M33/23コアがRAファミリ特徴。

サンプルコードの新しい入手方法

MCU利用の早期製品化には、プロトタイプ開発が必須です。

ベンダ各社は、多くのサンプルコードを提供しプロトタイプ開発支援を行っています。しかしながら、提供サンプルコード数が多いため、どのサンプルコードを利用すれば良いか開発者が迷う欠点もあります。

クイックコネクトスタジオは、評価ボードや使用センサ、通信方法をGUIで選択しながらMCUハードウェアが構築でき、構築ハードウェアの最新サンプルコードをクラウド上で簡単に作成できます。

つまり、プロトタイプ開発に適すサンプルコードを、間違わずに簡単入手が可能です。また、プロトタイプの仕様が変更になっても、クラウド上で「クイック」に対応できます。

さらに、RTOS開発では、AWSやAzureの接続先、TrustZone利用有無、OTA更新有無など製品化の選択肢がベアメタル開発に比べより多くなります。

注)AWS:Amazon Web ServicesはFreeRTOS、Azure:MicrosoftクラウドはAzure RTOS利用。OTA:Over The Airは、IoT製品ソフトウェア更新をクラウド経由で行うこと。

クラウド上で、これら接続先や利用有無に応じた必須ライブラリを自動的にZipパッケージ化してくれれば、ローカル開発環境の準備ミスも防げます。

クイックコネクトスタジオは、プロトタイプサンプルコードの新しい入手方法になると期待できそうです。

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

RAベアメタルテンプレートのP1
RAベアメタルテンプレートのP1

ローカル環境でのFSP利用RAファミリベアメタル開発は、弊社RAベアメタルテンプレート(税込1000円)をお勧めします。RAファミリの低価格で入手性も良いFPB-RA6E1FPB-RA4E1評価ボードと、Baseboardで動作確認済みです。

添付資料には、RAファミリ開発の鍵となるFSPの使い方やe2 studioのTipsも掲載済み、FSPサンプルコードを活用できる実務直結テンプレートです。

RAファミリ開発の早期習得ができ、添付資料P1~P3は、テンプレートサイトから無料ダウンロードも可能です。

ご購入、お待ちしております。



RAファミリFSP v4.3.0公開

お知らせ:3月31日金曜投稿はお休み

虫歯治療
虫歯治療

3月31日の金曜投稿は、虫歯治療のため休みます🤒。先週投稿と同じ内容です。

RAファミリFSP v4.3.0公開

RAファミリ向け最新FSP v4.3.0同梱e2 studio 2023-01
RAファミリ向け最新FSP v4.3.0同梱e2 studio 2023-01

2023年3月19日、RAファミリ最新FSP v4.3.0同梱e2 studio 2023-01が公開されました。1月16日公開の他のルネサスMCUファミリ向けe2 studio 2023-01公開から2ヶ月遅れです。

過去のRAファミリFSP更新と異なる点を説明します。

FSP v4.3.0新規インストール

過去のRAファミリFSP更新は、最新e2 studio内に複数のFSPが同居できました。例えば、1つ前のe2 studio 2022-10では、FSP version 4.2.0~3.6.0が同居しており、選択可能でした。

今回のFSP v4.3.0は、新規e2 studio 2023-01フォルダへFSP v4.3.0が新規インストールされます。従って、FSP v4.3.0は、この新規e2studio_v2023-01_fsp_v4.3.0フォルダから起動されます。

FSP v4.3.0新規インストールe2 studio 2023-01
FSP v4.3.0新規インストールe2 studio 2023-01

高密度モニタ125%~175%スケーリングのツールバー表示改善

高密度モニタとは、4K(3840×2160)など解像度が高いモニタのことで、最近流行中です。フルHD(1920×1080)に比べ、縦横2倍の表示が可能です。

但し、4K解像度では、Windows表示テキストが小さすぎて見にくいため、125%~175%の拡大表示へ変更し利用するのが一般的です。e2 studio 2023-01では、このスケーリング変更時のe2 studioツールバー表示が改善されました。

高解像度モニタ活用中の方なら表示変更が判るでしょう。筆者は、100%表示の愛好家ですので、具体的な改善内容は、残念ながら判りません。

関連投稿

MCU開発に適すモニタ解像度(1920×1080~3K)。
MCU開発に適すモニタサイズ(メインモニタ:24~27型、ノートPC:16型)。

まとめ

FSP v4.3.0同梱e2 studio 2023-01デフォルトインストール
FSP v4.3.0同梱e2 studio 2023-01デフォルトインストール

最新FSP v4.3.0同梱e2 studio 2023-01デフォルトインストールが、新規FSPインストールに変わり、これが高解像度モニタ用のツールバー起因なのかは、筆者のPC環境では判りません。

しかし、新規インストールの方が、過去開発環境をそのまま維持できるメリットもあります。デメリットは、ディスク容量など軽微です。

流行のPC環境に伴ってMCU開発環境も変化します。より効率的MCU開発環境へのステップアップ更新と考えます。


8/16ビットMCU置換えを狙う32ビットMCU

半導体不足が続いています。対策として、8/16ビットMCU置換えを狙った、汎用低コストの新しい32ビットMCUを2種紹介します。

STマイクロ:STM32C0シリーズ

STマイクロ、2023年1月12日、低価格なSTM32C0シリーズ(Cortex-M0+:48MHz、Flash:16K/32K、RAM:6K/12K)を発表。

STM32C0とSTM32G0の位置づけ(出展:STMサイト)
STM32C0とSTM32G0の位置づけ(出展:STMサイト)

ルネサス:RA2グループ

ルネサス、2021年10月13日、省スペース低消費電力向けにRA2E2グループ(Cortex-M23:48MHz、Flash:64K、RAM:8K)を、RA2シリーズへ追加。

RA2E2評価ボードのMCU基板アートワーク
RA2E2評価ボードのMCU基板アートワーク

8/16ビットMCU置換え最新32ビットMCU特徴

  • 少数ピン/小型パッケージ
  • 小容量Flash/RAM
  • 低消費電力
  • 低価格(8/16ビットMCUと同等)

8/16ビットMCU置換えを狙う32ビットMCU特徴です。置換え32ビットMCUと言えば、古くからNXP:LPC800シリーズが有名なので、本稿は省略しました。

動作周波数が高くても、Sleepなどの超低消費電力動作時間も長く、実働消費電力は驚くほど小さくなります。また、古い8/16ビットMCUよりも入手性に優れます。

置換え32ビットMCUメリット

旧MCU開発は、周辺回路ドライバなども自主開発することが多く、ドライバとアプリケーションの境界も開発者毎にバラバラでした。最新MCU開発は、ドライバはベンダHAL API生成ツールが自動生成します。

その結果、開発者は、アプリケーション開発に集中でき、ソフトウェア開発費も安くなります。

※HAL API:MCUハードウェアに依存しない(Hardware Abstraction Layer)API。シリーズ/グループが異なっても開発アプリケーション流用が容易。

既に実装済みの旧8/16ビットMCU機能を最新32ビットMCUへ置換える時も、この最新MCU開発環境が使えるため、効率的なソフトウェア開発が可能です。更に、置換えだけでなく、新機能追加、IoTやセキュリティなど高機能アップグレートも容易です。

最新汎用32ビットMCUは、半導体不足にも有効です。紹介したSTマイクロ、ルネサスいずれも、上位MCUへの置換えが可能な基板アートワークができるピン配置を採用しています。

つまり、IoT時代に合わせた開発スキルやソフトウェア発展性があり、基板ハードウェア持続性も期待できるなど、8/16ビットMCU置換え汎用32ビットMCU採用には、多くのメリットがあります。

STM32G0テンプレート、RAベアメタルテンプレート

STM32C0シリーズ開発には、STM32G0Xテンプレート、RA2グループ開発には、RAベアメタルテンプレートがお役に立てます。



FSPベアメタルサンプルのRTOSスレッド化

前投稿FSPベアメタルサンプルコード:sci_uart_fpb_ra6e1_epを、RTOSスレッド化する方法を示します。

多くのルネサスRA公式サンプルコードを活用した効率的なRTOSスレッド開発が本方法で可能です。FreeRTOS、Azure RTOS両方に使えます。

サンプルコードベースRTOSスレッド開発

RTOS開発は、複数スレッドを組合せ全体を動作させます。ベアメタルコードに比べ、個々のスレッドは、独立性や移植性が高い特徴があります。スレッド優先度やセマフォなどのRTOSオブジェクトを適切に設定すると、複数スレッド全体処理としてユーザ所望のシステム動作をします。

スレッドは、勝手に回る歯車、優先度やRTOSオブジェクトは、各歯車をシステム全体で上手く動作させる手段と考えると解りやすいと思います。

スレッドとRTOSの役目
スレッドとRTOSの役目

スレッド設計法は、機能別や処理手順別など様々あり、唯一の方法は無さそうです。しかし、先ずは、歯車となるスレッドを開発し、次に、開発スレッド優先度やRTOSオブジェクトを調整しながら、システム全体動作を仕上げるのがRTOS開発の方法です。

本稿は、スレッド単体開発の1方法として、ルネサスRAファミリ公式FSPベアメタルサンプルコードを活用したサンプルコードベースのRTOSスレッド開発法を示します。複数スレッドを組合せたRTOSオブジェクトの適切な調整や設定に関する内容は、含みません。

公式ベアメタルサンプルコードは、各ベンダエキスパートが開発し、評価ボードで動作確認済みの高信頼ソフトウェアです。また、MCU周辺機能毎に多くのサンプルコードが提供中です。

これらベアメタルコードを活用する本方法は、FreeRTOS/Azure RTOSどちらのRTOSスレッド開発へも使えます。

RTOSスレッド化方法

詳細は、後で説明しますが、先ず、ベアメタルサンプルをスレッド化する手順を簡単に示します。方法全体像が判っていると把握しやすいからです。

  1. スレッド無しで空の新規RTOSプロジェクト作成
  2. g_ioport以外のベアメタルサンプルFSPスタックを、RTOS FSPスタックへImport
  3. hal_entry.c以外のベアメタルサンプルsrcファイルを、RTOSプロジェクトsrcフォルダへコピー
  4. 新しいスレッド:MyThreadをRTOSプロジェクトへ追加後、Gegerare Project Contentクリック
  5. MyThread_entry.cへ、初期設定と無限ループ処理を追記

1で新規作成した空のRTOSプロジェクトへ、2と3で対象ベアメタルサンプルから内容を追加、4でベアメタルmain()相当の新しいMyThreadを追加後、FSPを使ってRTOSプロジェクトを自動生成します。

生成後、5でRTOSプロジェクトのMyThread_entry.c初期設定と無限ループを追記します。追記内容は、ベアメタルサンプルの初期設定と無限ループ処理です。

つまり、1~5手順全てFSPベアメタルサンプルからの単純コピーでRTOSスレッド化が可能です。

次章から、前投稿で用いたベアメタルサンプルコード:sci_uart_fpb_ra6e1_epを、FreeRTOSスレッド化する具体例を使って、各詳細手順を示します。

1. 空の新規FSP freertos_uartプロジェクト作成

スレッド無しで空の新規FreeRTOSプロジェクト作成
スレッド無しで空の新規FreeRTOSプロジェクト作成

スレッド無し空FreeRTOSプロジェクトを新規作成します。新規RTOSプロジェクト名は、freertos_uartとでもしてください。

2. sci_uart_fpb_ra6e1_epのFSPスタックImport

sci_uart_fpb_ra6e1_epのFSPスタックImport
sci_uart_fpb_ra6e1_epのFSPスタックImport

freertos_uartプロジェクトのFSPスタックへ、sci_uart_fpb_ra6e1_epのg_ioport以外のFSPスタックを全てImportします。Importした各スタックプロパティは、オリジナルプロパティと同じに手動で設定してください。

3. sci_uart_fpb_ra6e1_epのsrcファイルコピー

sci_uart_fpb_ra6e1_epのsrcフォルダファイルコピー
sci_uart_fpb_ra6e1_epのsrcフォルダファイルコピー

sci_uart_fpb_ra6e1_epのhal_entry.c以外のsrcファイルを全て、freertos_uartのsrcへコピーします。

4. freertos_uartプロジェクトへ新しいUart Thread追加後、Generate Project

新しいUart_Thread追加
新しいUart_Thread追加

新しいスレッドのSymbolは、Uart_threadとしてください。先頭を大文字にする目的は、FSPが自動生成したファイルやスレッドが使う全小文字表記とユーザ追加のそれらを、大小文字で区別するためです。

Tips:大文字利用は、好みの問題です。RTOS開発は、多数のスレッドやオブジェクトソースが、プロジェクト・エクスプローラのsrcフォルダに表示されます。自分が追加したソース(バグ有り?)と純FSP生成ソースを、一目で区別できるメリットがあります。

最後にGenerate Project Contentをクリックし、FSPによりRTOSプロジェクトを自動生成します。

5. Uart_Thread_entry.cへ初期設定と無限ループ処理追記

RTOSプロジェクトのsrcフォルダ内に、Uart_thread_entry.cが生成されます。

先頭の#include “Uart_thread.h”に、sci_uart_fpb_ra6e1_epのsrcファイルにある#include “common_utils.h”、 #include “uart_ep.h”、 #include “timer_pwm.h”を追記します。
これら4個の#include文は、freertos_uartの全srcファイルに手動で追記します。

Uart_thread_entry.cの初期設定
Uart_thread_entry.cの初期設定

RTOS初期設定は、Uart_thread_entry.c のTODO: add your own code here以下へ、sci_uart_fpb_ra6e1_epの初期設定:hal_entry.cのL41からL93までをコピーします。

sci_uart_fpb_ra6e1_epの無限ループ処理は、コピーした初期設定の後方にあるuart_ep_demo()です。

RTOS無限ループ内には、上図でコメントアウトしたコンテキストスイッチが必要です。そこで今回は、RTOSプロジェクトuart_ep.cのuart_ep_demo()内へ、直接コメントアウトしたFreeRTOSコンテキストスイッチ:vTaskDeley(1)を追記します。

uart_ep.cのuart_ep_demo()へ追記するコンテキストスイッチ
uart_ep.cのuart_ep_demo()へ追記するコンテキストスイッチ

Tips:#include “Uart_thread.h”が、FreeRTOS関連API:コンテキストスイッチ追記を可能にします。

sci_uart_fpb_ra6e1_epとfreertos_uartスレッド同一動作確認

RTOSプロジェクトをビルドし、評価ボードへダウンロード後、実行してください。前稿のベアメタルサンプルコードと全く同じ処理が、開発したfreertos_uartスレッドで確認できます。

FreeRTOS/Azure RTOSスレッド化差

本稿で示したFreeRTOSスレッド化とAzure RTOSスレッド化の差は、コンテキストスイッチのみです。FreeRTOSならvTaskDelay(1)、Azure RTOSならtx_thread_sleep(1)が、コンテキストスイッチです。

Tips:コンテキストスイッチは、FreeRTOS/Azure RTOS開発手法のRTOS処理フローなどを参照してください。

ベアメタルサンプルコードをAzure RTOSスレッド化する時は、手順1で、新規Azure RTOSプロジェクトを作成し、手順5のvTaskDelay(1)の代わりに、tx_thread_sleep(1)を使えばOKです。

Tips:FSP生成スレッドMyThread_entry.cの無限ループ内には、作成RTOSプロジェクトに応じて初めからvTaskDelay(1)、またはtx_thread_sleep(1)が実装済みです。

本方法が、FreeRTOS/Azure RTOSどちらのRTOSスレッド開発へも使えることが分かります。

補足

2023年1月16日、e2 stidioは2022-10のまま、RAファミリFSPがv4.2.0へ更新されました。本稿は、FSP v4.2.0/4.1.0両方で動作確認済みです。



FSP利用RAファミリUARTの使い方

RAファミリ評価ボードFPB-RA6E1PFB-RA4E1FPB-RA2E1などは、MCUのUARTとPCの接続に古いハードウェア知識が必要です。そこで、FPB-RA6E1のUARTとPC接続(USB UART Bridge)を解説し、FSPサンプルコードで動作確認しました。

FSPサンプルコード:sci_uart_fpb_ra6e1_ep

sci_uart_fpb_ra6e1_epのFSP Configuration
sci_uart_fpb_ra6e1_epのFSP Configuration

FPB-RA6E1(Cortex-M33/200MHz、Flash/1MB、RAM/256KB)のUARTとPC接続の公式サンプルコードが、sci_uart_fpb_ra6e1_epです。このFSP (Flexible Software Package)スタックConfigurationが上図です。

簡単に説明すると、FSP UARTスタックを使ってPCとUART(115200bps、8-Non-1)で接続し、Timerスタックを使ってPWMでLED1輝度を変えます。UART受信した1-100値が、PWM設定値です。

つまり、Tera Term経由でPCから1-100を入力すると、評価ボードLED1の輝度がPWM 1-100%で変わります。

sci_uart_fpb_ra6e1_epのreadme.txt
sci_uart_fpb_ra6e1_epのreadme.txt(一部抜粋)

サンプルコード付属readme.txtの上記は、MCUのUARTピンを、どうやってPCのUSBへ接続するかが、開発経験者でも解りにくい箇所です。Windows 7より前の古いMCU開発者なら解るかもしれません。

USB UART Bridge

シリアルポート(出展:ウィキペディア)
シリアルポート(出展:ウィキペディア)

Windows 7以前の古いPCには、RS-232Cコネクタ:シリアルポートが実装済みでした。シリアルポートの用途は、MCUとの通信や、特定アプリのライセンスキーなど多数ありました。

しかし、Windows 7以降、RS-232Cコネクタは消えUSBへと変わりました。

消えたRS-232Cの代わりにUSB経由でMCUと通信を行うのが、USB UART Bridgeです。実績あるデバイスとして、FTDI社のFT232RLが有名でした。

つまり、MCU UART入出力ピンをPCへ接続するには、USB UART Bridge(=USBシリアル変換アダプタ)が必要なことを知っている古いMCU開発者のみreadme.txtが判る訳です。

最近のMCU評価ボードは、USBシリアル変換アダプタとMCUプログラム/デバッグを、1本のUSBで共用しているものが多く、USB UART Bridgeを別途追加し開発する例は稀です。PCのUSBポート数が少なくなってきたからでしょう。

お勧めUSBシリアル変換アダプタ

「FTDI USBシリアル変換」で検索すると、USB 2/3.1や5/3.3V対応など様々なアダプタが、様々な価格で現れます。

殆どの5Vデバイスは、3.3V入力を5V High入力と認識します。それでも、MCUと接続する電圧は、5Vと3.3Vを選択できる方が無難です。High誤認識を防ぐことや、5V耐性が無いMCUピンでも接続できるからです。

低価格で入手性も良く、5/3.3V選択ができるお勧めのUSB UART Bridgeが、FTDI FT232RL USB-TTLシリアル変換アダプタ3個セットです。基板上にスルーホールがあるため、MCU UARTピンとの直接接続も簡単です。

お勧めハードウェアループバックテスト

低価格で3個入り品質に不安な方は、購入後、ハードウェアループバックテストをお勧めします。

ハードウェアループバックテストとは、デバイスの送信:TXDと受信:RXDを結線し、送信データが受信データに現れるかをハードウェア的にテストすることです。このテストにより、購入アダプタが、正常動作することを確認します。

Tera Termを接続すれば、TXD LED、RXD LED動作も確認できます。また、Windows 11 22H2は、お勧めFTDI FT232RL USB-TTLを、追加ドライバなしでUSB Serial Portと認識することも分かります。

ハードウェアループバックテスト
ハードウェアループバックテスト

sci_uart_fpb_ra6e1_ep動作確認

前章までのハードウェア知識を使って、評価ボード:FPB-RA6E1(搭載RA6E1 MCUは、VCC:2.7~3.6 V動作)とシリアル変換アダプタ:FTDI FT232RL USB-TTL(3.3V選択)、PC USBを接続しました。

サンプルコード:sci_uart_fpb_ra6e1_epが示すMCU UART入出力ピンとUSB UART Bridge TXD/RXD接続、PC Tera Termの1-100入力による評価ボードLED1の輝度変化動作が確認できます。

sci_uart_fpb_ra6e1_epの動作確認
sci_uart_fpb_ra6e1_epの動作確認
sci_uart_fpb_ra6e1_epのTera Term入力(橙)と出力(白)
sci_uart_fpb_ra6e1_epのTera Term入力(橙)と出力(白)
sci_uart_fpb_ra6e1_epのFPB-RA6E1とシリアル変換アダプタの結線
sci_uart_fpb_ra6e1_epのFPB-RA6E1とシリアル変換アダプタの結線

Tips:上記ArduinoコネクタのD1 TX (P109)、D0 RX (P110)へMCU UART使用ピンを変えるには、FSP UARTスタックの利用Channel 0をChannel 9へ変更すればOK。

ルネサスRAファミリ評価ボードは、本稿で示したMCU UART用にUSB 1本、e2 studioプログラム/デバッグ用に別のUSB 1本、合計2本のUSBが必要です(PC側もUSB 2ポート必要)。

このe2 studio プログラム/デバッグ用USBの通信ツールが、J-Link RTT Viewerです。sci_uart_fpb_ra6e1_epでは、FSPバージョンやsci_uart_fpb_ra6e1_ep操作方法が示されます。

sci_uart_fpb_ra6e1_epのJ-Link RTT Viewer
sci_uart_fpb_ra6e1_epのJ-Link RTT Viewer

次投稿:ベアメタルサンプル → RTOSタスク化

サンプルコード:sci_uart_fpb_ra6e1_epは、FSP UARTスタックのベアメタル利用例で、良くできています。ベアメタルに限らず、RTOSへの応用範囲も広いです。

そこで次回は、ベアメタルサンプルコード:sci_uart_fpb_ra6e1_epを、RTOSのタスク化する方法を投稿する予定です。この方法により、多くの公式サンプルコードを活用し、効率的にRTOS開発が行えます。

FSP利用関連投稿:FSP利用FreeRTOSアプリの作り方FSP利用FreeRTOS/ベアメタルアプリ起動方法



FSP利用FreeRTOSアプリ起動動作

ルネサスFSPの役目、RTOSアプリ起動動作
ルネサスFSPの役目、RTOSアプリ起動動作

前回FSP利用FreeRTOSアプリの作り方で、ルネサス公式サンプルコードを流用・活用した実践的RTOSアプリ開発方法を示しました。今回は、前回開発したアプリを使ってFSPの役目、RTOSアプリがどのように動作開始するかを説明します。

これからRTOS開発を始めるベアメタル開発経験者に役立つと思います。

前回のおさらい

FPB-RA6E1評価ボードのLED1点滅速度を、SW1プッシュ割込みで変える1スレッドのみを持つRTOSアプリの開発方法を、新規FreeRTOS Blinkyプロジェクトへ評価ボード実装済みベアメタルサンプルコードを移植することで説明したのが、前回のfreertos_blinkyプロジェクトでした。

※12月9日投稿時、FSP Importした割込みコントローラ初期化の記述を忘れていました。翌日10日に追記済みです。お詫びします<(_ _)>。

本稿の目的

ルネサスFSP(Flexible Software Package)は、ベアメタル、FreeRTOSとAzure RTOS、これら3者に対応した周辺回路API とMCU起動ファイルを自動生成するツールです。

※MCU起動ファイルは本稿ではstartup.c、main.c、ユーザファイルの3つを指します。

従って、初めてFSPを利用する時は、戸惑う部分もあります。例えば、ベアメタル開発には無関係のスレッドやオブジェクト設定エリアがあること、FreeRTOS開発時でもタスクではなくスレッドへ統一された説明やパラメタ設定があるなどです。

つまり、1つのFSPでベアメタル、FreeRTOS、Azure RTOSの3者に同時対応したため、FSPパラメタ設定や説明に解りにくい点があります。

※本稿も、FSPに習ってタスクではなくスレッドを用います。

また、当然ですが、ベアメタルとRTOSでは、FSP生成のMCU起動コードも異なります。何度か開発すれば、ベアメタルとRTOSでどこが違うかが判ります。しかし、初めからハッキリ区別した説明があるとFSPとRTOS理解が早くなります。

そこで本稿は、FSP生成MCU起動ファイルとベアメタル/RTOSユーザファイルまでの動作差を説明します。

FSP自動生成MCU起動ファイル(startup.cとmain.c)

startup.c:リセット後のMCU動作開始には、動作クロック設定やRAMゼロクリアなど、様々な前処理が必要です。これら前処理を行うのが、startup.cです。startup.cは、ベアメタル/RTOSともに同じ処理です。

main.c:ベアメタルでは、startup.c→main.c→user_main.cと処理が進みます。RTOSは、startup.c→main.cだけです。main.cの処理内容がベアメタルとRTOSで異なります(次章の図参)。

ベアメタルのmain.cは、実質のメイン関数であるuser_main.cへの橋渡しファイルで処理はありません。なぜ橋渡しファイルを使うかは、後で説明します。

RTOSのmain.cには、ユーザがFSP Configurationで追加したスレッドやオブジェクトの生成関数が、FSPにより自動追加されます。例えば、前回のfreertos_blinkyプロジェクトのmain.cなら、下線部分です。

freertos_blinkyプロジェクトのmain.cファイル
freertos_blinkyプロジェクトのmain.cファイル

FSP生成のmain.cは、スレッドやオブジェクトを生成し、最後に橙色で囲ったRTOSタスクスケジューラを起動してリターン(終了)します。

つまり、RTOSのmain.cは、「全てのRTOS処理を開始するための前処理、準備」を行います。

因みに、FSP生成startup.cやmain.cは、ユーザが勝手に変更を加えにくいようプロジェクトファイル階層の深い部分や、ユーザフォルダ:srcとは別フォルダ内にあります。

FSP生成ベアメタルまたはRTOSユーザファイル(user_main.cまたはuser_thread_entry.c)

ベアメタル(左)とRTOS(右)のユーザファイル:srcフォルダ内容
ベアメタル(左)とRTOS(右)のユーザファイル:srcフォルダ内容

逆にユーザファイルは、変更を加え易いよう最上位のユーザフォルダ:srcの中にFSPが生成します。ベアメタルならuser_main.c、RTOSならuser_thread_entry.cです。

ベアメタルでは、実質のメイン関数:user_main.cがmain.cから起動します。user_main.cは、周辺回路の初期設定と、無限ループの2構成から成るごく普通のメイン関数です(関連投稿:組込み開発 基本のキ 組込み処理)。

一方、RTOSは、main.c内でFSPが追加した生成関数user_thread_createによりuser_thread_entry.cが起動します。前章のfreertos_blinkyプロジェクトで示すと、blinky_thread_createとblinky_thread_entry.cです。

ユーザが複数スレッドを追加した場合は、各スレッドが下図のようにmain.c内で生成され、RTOSによる複数スレッド並列動作となります。

ルネサスFSP生成のベアメタル起動動作(右)とRTOSアプリ起動動作(左)
ルネサスFSP生成のベアメタル起動動作(右)とRTOSアプリ起動動作(左)

それぞれのスレッドは、優先度やセマフォなどのRTOSオブジェクトに従って、つまりRTOS環境で制御されます。

FSP利用のRTOS開発は、main.cまでがベアメタル動作、これ以降はRTOS動作環境になります。

ベアメタルのmain.cがuser_main.cへの橋渡しファイルなのは、右側のRTOS動作環境の形に無理やり(?)合わせたためだと思います。FSPは、Azure RTOS>FreeRTOS>ベアメタルの順位で設計されたからでしょう。

まとめ:FSP利用FreeRTOSアプリ起動動作

ユーザ設定のFSP Configurationを基にFSPは、周辺回路APIを生成し、同時に、MCU起動ファイル(startup.cとmain.c)とユーザファイルを分離して生成します。

FSP自動生成ファイルやAPIには、ユーザが手動変更しないようわざわざ下記注意コメントが先頭に付いています。

/* generated XYZ source file – do not edit */

また、FSP生成ユーザファイルにも下記コメントが付いています。

/* TODO: add your own code here */

これらFSPコメントに従って、ユーザがコメントの後へユーザコードを追加すればアプリが開発できます。ただ、開発にはFSPが生成するファイル内容や、FSPが想定しているベアメタル/RTOSアプリ動作の理解が必須です。

そこで本稿は、FPB-RA6E1 FreeRTOSアプリ(freertos_blinky)を使ってFSPが生成したMCU起動ファイルとRTOSユーザファイル動作を説明しました。

その結果、ベアメタルでは橋渡し役のmain.cが、RTOSでは全てのRTOS動作開始の前処理、準備を行うことを示しました。

ルネサスMCU開発は、FSP理解が鍵です。FSPが自動生成するベアメタルとRTOSユーザファイルまでの起動動作が判ると、FSP理解とベアメタル開発経験者のRTOS開発が容易になります。



FSP利用FreeRTOSアプリの作り方

ルネサスFSP(Flexible Software Package)とサンプルコード利用の「実践的FreeRTOSアプリの作り方」を示します。下記の最新開発環境を用いました。古い環境や別評価ボードでも同じ結果が得られると思います。

 全体流れ説明

先ず本FreeRTOSアプリ開発の全体の流れを説明します。というのは、組込み開発で良くあるサンプルコード付属説明:readme.txtとソースコード動作が不一致など、少々込み入った内容を含むからです。

  1. FPB-RA6E1購入時インストール済みサンプルコード:qiuckstart_fpb_ra6e1_epは、ベアメタルソフト。readme.txt記載のSW1プッシュでLED1/2点滅速度変化とは不一致。
  2. SW1プッシュでLED1/2点滅速度変化へFSP改造(1と2は、ベアメタル開発)。
  3. FPB-RA6E1で、新規LED1/2点滅FreeRTOSアプリ作成(3以降は、FreeRTOS開発)。
  4. 作成FreeRTOSアプリのLEDスレッドへ、2.のベアメタルのSW1プッシュLED1/2点滅速度変化改造FSPと、ソースコード移植。
  5. LED2は、FreeRTOSアプリエラー表示用とするため、点滅処理から削除。

本稿の背景

ベアメタル開発者は1と2、RTOS開発者は3以降が実行できれば、SW1プッシュでLED1点滅速度変更の1スレッドのみを持つFreeRTOSアプリを開発できます。

「実践的FreeRTOSアプリ開発」としたのは、0からアプリを開発するのではなく、豊富に提供される公式サンプルコードを流用・活用し、所望アプリを早く効果的に開発する例を示したかったからです。

RTOSのメリットを説明した資料は多く見かけます。しかし、具体的なRTOSアプリ開発方法を示す資料が少ないことも背景にあります。

以下、1~5の説明を加えます。細かい説明は後回しにし、まとめ章を先に読むとより全体が解り易いと思います。従って、まとめ章を先に記述します。また、最後の章に、RTOS開発の基盤となるRAベアメタルテンプレート宣伝(?)もあります。

まとめ:実践的RTOSアプリ開発方法

評価ボード実装済みLED1とSW1は、いわば開発アプリ正常動作中を示すインジケータです。開発したFreeRTOSアプリをテンプレートとし、所望機能のスレッドを追加していけば、最終的に様々なFreeRTOSアプリを早期に開発できます。

FreeRTOSをRAファミリFSP利用例としましたが、Azure RTOSでも同様です。

つまり、本稿のアプリは、RTOSテンプレート骨格で説明した内容を、より具体化したものです。

もちろん複数スレッド追加時は、スレッド優先度やスレッド間制御(セマフォ/キュー/ミューティックスなど)の検討も必要になります。これらは、追加スレッドがほぼ完成した後の検討項目です。

先ずは、必要な個々のスレッドを単体・単独で開発し、その後、複数スレッド結合へと段階的に進める方法がRTOS開発には適していると考えます(関連投稿:FreeRTOS/Azure RTOSソフトウェア開発手法)。

複数スレッドの検討方法は、文章量が増えるため割愛しました。別途改めて、投稿する予定です。

1:qiuckstart_fpb_ra6e1_ep動作とreadme.txt

サンプルコードzip内のqiuckstart_fpb_ra6e1_ep
サンプルコードzip内のqiuckstart_fpb_ra6e1_ep

評価ボードに初めからインストール済みのサンプルコードが、quickstart_fpb_ra6e1_epです。zip内に収められています。e2 studioは、zip内にあるサンプルコード説明書:readme.txtをIDE内にインポートしません。

Tips:zip解凍後のreadme.txtを、サンプルコードプロジェクト内へ手動でコピーしておくと、いろいろ便利。
Tips:quickstart _fpb_ra6e1_epのfpb_ra6e1が評価ボード名、epはexample projectの略。別評価ボード利用時は、fpb_ra6e1部分が異なる。

quickstart_fpb_ra6e1_epのreadme.txtが下記です。

quickstart動作とreadme.txtの不一致箇所
quickstart動作とreadme.txtの不一致箇所

下線部:評価ボードSW1でユーザLED1/2点滅制御とありますが、この動作はFPB-RA6E1にはありません。しかし、quickstart_fpb_ra6e1_epソースコードには、SW1割込み処理:callback_irq1ds_buttonでLED1/2点滅delay変更処理が記述済みです。

これは、RAファミリのソースコードがHAL(Hardware Abstraction Layer)記述で、MCUが変わっても同じソースコードを使えるからです。別評価ボードのソースコードとreadme.txtを、そのままFPB-RA6E1へコピー流用している訳です。

組込み開発ではMCUの種類が多いため、このように既存資産をコピーして当該MCUコードや資料を作ることは良くあります。その結果、今回のようにreadme記述内容とサンプルコード動作が不一致なことも多々あります。

Tips:逆に上記は、MCUソフトウェア開発の本質が「サンプルコードやFSPなどの既存資産を上手くコピー活用すること」を示しているとも言えます!

2:SW1プッシュ割込みでLED1/2点滅速度変化へFSP改造

readme.txt記述とサンプルコード動作不一致の原因が、FSPです。

そのままコピーできるreadmeやサンプルコードと異なり、FSPは、当該MCU毎に設定が必要です。不一致の原因は、FPB-RA6E1のFSP設定にミス(忘れ)があるからです。

動作一致のためには、外部割込みコントローラ(External IRQ)とFPB-RA6E1のSW1(P205)の接続が必要です。下記のようにP205ピン設定を変更後、Generate Project Contentをクリックします。

quickstart_fpb_ra6e1_epを再ビルドし、評価ボードへダウンロードすれば、readme内容と同じSW1プッシュでLED1/2点滅速度が変わります。

外部割込みコントローラ(External IRQ)とS1(P205)を接続するピン設定
外部割込みコントローラ(External IRQ)とS1(P205)を接続するピン設定

3:LED1/2点滅新規FreeRTOSアプリ作成

新規FreeRTOSアプリ作成は、ベアメタルアプリ作成と同じ方法です。そこで、本稿は、ベアメタル作成との差分のみを示します。

LED点滅の新規FreeRTOSアプリ作成(ベアメタル作成との差分)
LED点滅の新規FreeRTOSアプリ作成(ベアメタル作成との差分)

新規作成FreeRTOSプロジェクト名は、freertos_blinkyとでもしてください。FSP Summaryが下記です。

FSP Summary
FSP Summary

このfreertos_blinkyを評価ボードへダウンロードすると、LED1/2が1秒毎に点滅します。生成したLEDスレッド:blinky_thread_entry.cのvTaskDelay(configTICK_RATE_HZ)が、1秒点滅の仕組みです。

4:LEDスレッドへ、2:SW1プッシュLED1/2点滅速度変化改造FSP移植

2:で改造したSW1割込みでLED1/2点滅速度を変える機能を、3の新規FreeRTOSアプリへ移植します。

freertos_blinkyのFSP Stacksタブを選び、画面上で左クリックしImportを選択します。From fileにquickstart_fpb_ra6e1_epを選び、configuration.xmlを開きます。Stack ImportでExternal IRQを選ぶとquickstart_fpb_ra6e1_epの割込みコントローラ設定がfreertos_blinkyへ移植できます。

Tips:移植するFSPスタック数が多い時は、Import機能が便利。

FSP Import
FSP Import

しかし、割込みコントローラとSW1(P205)間の接続はImportできません。そこで、1:と同様にP205ピン設定を割込みコントローラと接続し、Generate Project ContentクリックでFSP移植は完了です。

Tips:FSP Importは簡単便利だが、上記のように同一MCUであっても、ピン設定はImportされない。また、ピン設定が無くてもエラー表示もない。代替方法に、New Stackクリックでスタック群から追加機能を選ぶ方が、ピン設定忘れが少ないかもしれない。

次に、SW1割込み処理:callback_irq1ds_buttonを移植します。

callback_irq1ds_button処理は、e2studioのDeveloper Assistanceを開き、callback_function_definitionをクリックし、blinky_thread_entryの後へペーストで追記します。今回は、TODO:add your own code hereコメント後へ、quickstart_fpb_ra6e1_epのSW1割込み処理をコピー&ペーストし移植します。

コピー後エラーが表示される箇所は、全て定数未定義部分ですので、quickstart_fpb_ra6e1_ep定数部分もコピー&ペーストします。

Tips:e2 studioは、デフォルトではソースコード変更後、このように即コンパイルエラーを表示。

最後に、vTaskDelay(configTICK_RATE_HZ)のconfigTICK_RATE_HZ を、割込み処理で作成したg_delayへ変更します。

以上で、割込み処理の移植完了です。ビルドし、SW1でLED1/2点滅速度が変わることが確認できます。

SW1割込み処理:callback_irq1ds_buttonの移植
SW1割込み処理:callback_irq1ds_buttonの移植

12月10日追記:FSP Importした割込みコントローラ初期化の移植記述を忘れていました。追記します。

Importした割込みコントローラの初期化:icu_initializeも、下図のようにblinky_thread_entry.cへ移植します。

割込みコントローラの初期化処理の移植
割込みコントローラの初期化処理の移植

5:LED2点滅処理削除

LED2は、FreeRTOSアプリのエラー表示に使います。例えば、追加したスレッド初期設定に失敗した時のインジケータなどです。そこで、下記のようにLED2をLEDスレッドの点滅処理から外します。

LED2点滅処理削除
LED2点滅処理削除

以上で、SW1プッシュでLED1点滅速度変更の1スレッドのみを持つFreeRTOSアプリ完成です。

このFreeRTOSアプリへRTOSテンプレート骨格で投稿した7メニュー形式表示、LED2エラー表示などの機能を更に追加しFreeRTOSテンプレートとします。

FreeRTOSテンプレートは、全てのFreeRTOSアプリ開発の出発点となり、所望スレッド機能を追加していけば、効率的に様々なRTOSアプリ開発が可能です。

Tips:本稿はFreeRTOSテンプレート開発方法に重点を置き投稿。実FreeRTOSテンプレートは、もっと解り易い構造とソースコードで提供。

RTOS開発はベアメタル開発スキル必須

前章1~5から「RTOS開発には、ベアメタル開発スキルが必須」であることがお解り頂けたと思います。

組込み開発は、説明不足の事柄が非常に多いです。また、サンプルソフトとreadme.txtなどの説明不一致も多々あります。説明対象を初心者/中級者の誰にするか、どこまで説明するか、などなど読者を絞り難いこと、説明側にとっては、自明の理の内容が多いことがその理由です。

本稿で追記したTipsや背景となる技術スキルが無いと効率的に先へ進めないと思います。ベアメタルを補う目的のRTOS開発ではなおさらです。

RAファミリで、FSP利用の効率的なベアメタル開発スキルを身に付けるには、弊社RAベアメタルテンプレートがお勧めです。ソースコードに豊富な日本語コメントを付加し、付属説明資料にはTipsやFSPノウハウなども記載しています。RAベアメタルテンプレート説明サイトは、コチラをご覧ください。

ルネサス以外のベアメタル用テンプレートも多数ご用意しております。また、NXPのFreeRTOSアプリケーションテンプレートも販売中です。



64ビットMCU得失

RZファミリ位置付け(出展:ルネサスサイト)
RZファミリ位置付け(出展:ルネサスサイト)

今年春の3月2日、ルネサスが64ビットRISC-Vコア搭載の汎用MPU:RZ-Fiveを発表しました(!=MCU)。

本稿は、RISC-Vの簡単な紹介と、MCUの64ビット化得失についてまとめました。

RISC-V

リスク ファイブ(RISC-V)は、2010年にカルフォルニア大学バークレイ校(2022年世界大学ランキング第4位)で開始されたプロジェクト。オープン標準命令セットアーキテクチャ(ISA)でオープンソースライセンス。使用料無料。用途に応じた32/64/128ビット対応アーキテクチャで、RISC-Vチップや派生成果物の作成も許可。(Wikipediaより)。

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

ルネサスなどのMPU/MCUチップ製造側にとっては、ARMコアベースに比べ、ライセンス料が無く競合他社差別化や独自性も出し易いのがRISC-Vコアと言えそうです。※RZファミリには、ARMコア(Cortex-A55とCortex-M33ディアルコア)のRZ/G2ULもあるため、ArmベースMPUが最初の右グラフに記載。

日経xTECH記事(2022-09-13)によると、ルネサス以外にも、既に多くのRISC-V利用MPUや32ビットMCUが発表されています。RISC-V CPU搭載ノートPCも販売中です。

関連投稿:Cortex-MとRISC-V1GHz 64ビットMPUのRZ/A3UL

IoT MCU要件

CPUやMPUは、64ビット化が進んでいます。Windows 11は、32ビット対応版がありません。また、ルネサスRZ-Five同様、NXPやSTマイクロでもMPUは全て64ビットです。

これは、CPU/MPUに要求されるセキュリティ機能や性能を満たすには、先行するサーバやデータセンタで開発したソフトウェア資産の移植が、64ビットの方が容易だからです。

一方、MCUは、性能・機能の向上と消費電力増加のバランスが、MPUに比べ重視されます。MCU設置個数は、MPUよりも桁違いに多いため既存MCU資産を活かすバイアスが働くためです。最初の右側グラフで、16ビットRL78が低消費電力の代表として表示されていることからも解ります。

このバランスのため現状のIoT MCU主流は、32ビットMCUです。

しかし、MCU製造プロセス改良や、電力供給の世界情勢、自動車ADASと半導体供給状況などにより、IoTセキュリティ機能への要求や、低消費電力への要求バランスは大きく変わる可能性もあります。場合よっては、CPU/MPU同様、64ビットMCUがIoTに適すかもしれません。

アクティブ消費電力とスリープ消費電力両方を減らせるSOTBプロセス(出典:ルネサスサイト)
アクティブ消費電力とスリープ消費電力両方を減らせるSOTBプロセス(出典:ルネサスサイト)

関連投稿:ルネサスのMCU新製造プロセス SOTB

また、IoT必須のRTOSをMCUへ適用する場合には、32ビットカウンタでは、タイマー満了周期が短い問題も指摘されています。

結論:64ビットMCU見通し

既存MCU資産(特にソフトウェア)をそのまま活かしMCU性能を上げるには、同一コア高速化が適します。一方、サーバやデータセンタのセキュリティ機能移植を考えると、64ビットMCUも有力です。また、IoT MCUのRTOS開発時は、32ビットカウンタの短さに注意が必要かもしれません。

ビット幅を意識することは、Cなどの高級言語でMCU開発する限り稀です。しかし、RTOS開発時や更なる性能・機能向上(例えばエッジAI)、効率的セキュリティ導入を求める時は、32ビットMCU限界が現れることもあり得ます。

アーキテクチャ変更で得るものと失うものバランス、トータル開発コスト、これらが次世代IoT MCUを決めます。今後主流のIoT MCUが32/64ビットいずれになるかは、流動的です。だからこそ、最新IoT MCUやMPU、RISC-V動向を注意深く観察する必要があるというのが結論です。