RA用e2studio 2022-07リリース

2022年8月31日より、FSP v4.0.0同梱RAファミリ最新開発環境e2studio 2022-07が、ダウンロード可能です。

FSP for RA MCU Family, version 4.0.0. (2022/08/31)

FSP同梱インストーラ利用指示

RAファミリはFSP同胞インストーラ利用指示
RAファミリはFSP同梱インストーラ利用指示

RAファミリ以外の単体e2studioバージョンアップは、7月20日でした。

RAファミリのアップデートは、上記リリースノートのようにFSP(Flexible Software Package)同梱インストーラ利用指示があるため、RA用のe2studio 2022-07リリースは、単体から1.5ヶ月遅れの8月31日になりました。同梱インストール理由は、不明です(単体e2studio+単体FSPインストールも可能ですが、指示に従う方がBetter)。

また、e2studio 2022-04以降、Windows 11-64bitに正式対応しました。弊社の先行Win11 21H2も、最新FSP同梱RA用e2studio 2022-07の正常動作確認済みです。

但し、ルネサス半導体セミナーやリリースノート、サンプルコードの説明書きなどは、未だWin10です。

Win11への移設は、今秋予定の22H2発表後でも良いと思います。Win11 22H2は、9月20日リリース情報があります。仮に9月20日なら、次回投稿は、弊社Win11 21H2の22H2大型更新レポートになるでしょう。

Example Project Bundle

RA6E1(左)とRA4E1(右)サンプルコード一覧
RA6E1(左)とRA4E1(右)サンプルコード一覧

弊社推薦RA6/4ファミリ評価ボード:FPB-RA6E1、FPB-RA4E1サンプルコード:FPB-RA6E1/FPB-RA4E1 Example Project Bundleも、最新版がリリースされました(2022/08/11)。

最新Example Project Bundleでも、多くのベアメタルサンプル、FreeRTOSサンプルは1個(下線)、Azure RTOSサンプルは0個です。

Cortex-M33コア採用のRA6/4は、IoT MCUでFSPもRTOS対応済みです。先ずは、ベアメタル開発でFSPに慣れてもらうという意図でしょうか?

RA開発環境まとめ

9月16日時点の最新RA開発環境バージョンアップ状況をまとめたのが下図です。

RA用開発環境のバージョンアップ状況
RA用開発環境のバージョンアップ状況

RA用の開発環境は、FSPバージョン版数が不揃いです。例えば、FSP同梱e2studioのFSP版数は、v4.0.0なのに、最新Example Project BundleのFSP版数は、v3.8.0で1世代前です。

しかし、v3.8.0のExample Project Bundleは、下図のようにFSP ConfigurationのBSPタブで最新FSP version 4.0.0へ変更が可能です。変更後、Generate Project Contentをクリックすれば、FSP v4.0.0でのAPIコードやひな型コードが生成されます。

FSPバージョン変更方法
FSPバージョン変更方法

また、直にIoT MCU RTOS開発を始めたいベアメタル開発経験者には、FreeRTOSやAzure RTOSサンプルコード数が少ないことも問題です。

対策案として、前投稿説明のベアメタルサンプルコードからRTOSコードを自作する方法をお勧めします。

RTOSの目的や機能を教科書から学ぶよりも、自作サンプルコードから理解していくベアメタル起点のRTOS習得方法は、RTOSスキルを磨きベアメタル補完RTOS開発の面白さを知る良い方法だと思います。



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ソフトウェア開発手法としてまとめました。

STM32 Azure RTOS開発ツール拡充

2022年4月20日、STマイクロエレクトロニクス(以下ST)は、Azure RTOS開発ツールを拡充し、より幅広いSTM32MCU対応を発表しました。拡充したSTM32MCUリストが下記です。

List of STM32 with X-Cube-AZRTOS Package(出典:The ST blog)
List of STM32 with X-Cube-AZRTOS Package(出典:The ST blog)

弊社販売中STM32G0xテンプレートで使ったSTM32G0や、テンプレート開発中のSTM32G4も、Azure RTOS開発が容易になりました。

CMSIS RTOSからAzure RTOSへ

今回の発表前までは、販売中のNXP版FreeRTOSアプリケーションテンプレートに続き、STM32G4を使ってST版“CMSIS-RTOS”アプリケーションテンプレートを構想していました。

しかし、今回のAzure RTOS開発ツール充実発表を受け、“CMSIS-RTOS”から“Azure RTOS”対応へ変更することにしました。STのAzure RTOSサンプルコードが活用でき、また、Microsoft公式Azure RTOS情報もあるからです。

※ARM社規定のCMSIS RTOSは、FreeRTOSやAzure RTOSをラップ(wrapper)するRTOSです。同じCMSIS RTOS APIでFreeRTOSまたはAzure RTOSが使え、開発アプリケーション流用性は高まります。但し、ラップ関数分のオーバーヘッドが生じます。詳しくは、構想投稿の4章を参照してください。

STがAzure RTOS開発ツールMCUを拡充した背景は、Microsoft Azureクラウド接続IoT MCUの急増だと思います。リストアップした9種のSTM32MCUが、IoT MCU有力候補と言えます。

Azure RTOS開発ツールインストール方法

STM32G4を例に、Azure RTOS開発ツールインストール方法を示します。現在のSTM32G4開発ツールが、下記版数です。

・STM32CubeIDE v1.9.0               (以下CubeIDE)
・STM32CubeMX v6.5.0               (以下CubeMX)
・STM32Cube FW_G4 v1.5.0        (以下FW_G4)
・X_CUBE_AZRTOS_G4 v1.0.0    (以下AZRTOS_G4)

X-CUBE-AZRTOS-G4が、今回発表したSTM32G4のAzure RTOS開発ツールです。

FreeRTOSは、CubeMXのMiddlewareに実装済みです。一方、Azure RTOS は、ExpansionsパッケージのAZRTOS_G4によりCubeMXへ機能追加します。Expansionsパッケージ追加のため、少し手間がかかります。

① CubeIDEのHelp>Manage Embedded Software Packagesクリック
② Embedded Software Packages ManagerのSTMicroelectronicsタブ選択
③ X_CUBE_AZRTOS_G4のAvailable Version 1.0.0を選択し、Installクリック

X-CUBE AZRTOS-G4のインストール
X-CUBE AZRTOS-G4のインストール

AZRTOS_G4インストール後、使用コンポーネントの選択が必要です。

④ CubeMXのPinout & Configurationタブ内Software Packsをクリック
⑤ Select Components(Alt+O)を開き、Software Packs Component Selectorで追加Azure RTOSコンポーネント:RTOS ThreadX/File system FileX/USB LevelX…などを選択し、OKクリック

STM32G4評価ボード:NUCLEO-G474REを使う場合は、RTOS ThreadXを選択し、Core/Low Power supportを選択すれば十分です。但し、念のため、Performance InfoやTraceX supportも選択しておきます。

インストールしたAzure RTOS ThreadX版数が、6.1.8であることも判ります。

Software Packs Component Selector
Software Packs Component Selector

Azure RTOS ThreadXサンプルコードインポートと動作確認

インストールしたAZRTOS_G4が正常動作するかをAzure RTOS ThreadXサンプルコードと評価ボード:NUCLEO-G474REで確かめます。確認方法が下記です。

① CubeIDEのInformation CenterからImport STM32Cube exampleをクリック
② STM32 Project from STM32Cube ExamplesのExample Selectorタブで、BoardのName:NUCLEO-G474RE、Middleware:ThreadXを選択

STM32G4評価ボード:NUCLEO-G474REのAzure RTOSサンプルコード
STM32G4評価ボード:NUCLEO-G474REのAzure RTOSサンプルコード

STM32G4 Azure RTOS ThreadXサンプルコードは、現在3個です。最も基本的な、

③ Tx_Thread_Creationを選択し、Finishクリック。CubeIDEへTx_ThreadX_Creationサンプルコードがインポート。
④ CubeIDEのTx_Thread_Creation.iocをクリックし、CubeMXで、Generate Code(Alt+K)を実行
⑤ CubeIDEでTx_Thread_Creationをビルドし、評価ボードへダウンロード
⑥ 評価ボードのLED2が、500ms点滅と200ms点滅を3回繰返し、その後1秒点滅に変わる

以上で、STM32G4 Azure RTOS開発ツールのX_CUBE_AZRTOS_G4インストールを、ThreadXサンプルコードで動作確認しました。

使用したTx_ThreadX_Creationサンプルコードの説明は、次週以降に行う予定です。直ぐ知りたい方は、Tx_ThreadX_Creationフォルダ内readme.htmlを参照してください。

まとめ

STが、STM32G0やSTM32G4、STM32U5などのIoT MCUに対し、Azure RTOS開発ツール拡充を発表しました。

STM32G4を例に、CubeMXへExpansionsパッケージのX_CUBE_AZRTOS_G4でAzure RTOS機能の追加方法、Azure RTOS ThreadXサンプルコードインポート、NUCLEO-G474REでThreadXサンプルコードの動作確認をしました。

STM32G0(Cortex-M0+/64MHz)、STM32G4(Cortex-M4/170MHz)、STM32U5(Cortex-M33/160MHz)は、弊社IoT MCUテンプレートの開発対象です。

今回の発表を受け、STM32G4のRTOSを、CMSIS-RTOSからAzure RTOSへ変更し、ST版Azure RTOSアプリケーションテンプレート開発を計画中です。

RAファミリのRTOS

RAファミリは、FreeRTOSとAzure RTOS、両方に対応しています。このうち、FSP v3.6.0でサンプルコードを提供しているのがFreeRTOSです(プロジェクト名:freertos_評価ボード名_ep)。

本稿は、このFreeRTOSサンプルコードを簡単に解説します。

キューとセマフォ利用サンプルコード

freertos_fpb_ra6ep1_epのユーザ追加部分とFSP生成ソースコード
freertos_fpb_ra6ep1_epのユーザ追加部分とFSP生成ソースコード

最新版FSP v3.6.0のRA6E1評価ボードサンプルFPB-RA6E1 Example Project BundleのRTOSサンプルコードが、上図freertos_fpb_ra6e1_epです(freertos_fpb_ra4e1_epも同じ)。

ユーザ追加RTOSタスク:キュー送信タスク、受信タスクと、定期割込みでセマフォ生成し、生成セマフォ取得でRTT Viewerへメッセージ出力するタスクの、合計3タスクを追加(タスクプライオリティ同一)。

ユーザ追加RTOSオブジェクト:キューとセマフォの2オブジェクトを追加。

FSP生成ソースコード:追加タスク毎にFSPが entry.c 生成(中身は、下図右側)。

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

基本的には、FreeRTOS公式Hardware independent FreeRTOS exampleや、弊社NXP版FreeRTOSアプリケーションテンプレートと同様の処理。

詳細は、FreeRTOSアプリケーションのQueueデータ送受信FreeRTOSサンプルプロジェクトfreertos_generic詳細などの関連投稿をご覧ください。

RAファミリRTOS現状まとめ

FSPを使ったRAファミリFreeRTOS/Azure RTOSの現状をまとめると、下記です。

・FreeRTOS習得スタートは、キューとバイナリセマフォオブジェクト理解(弊社FreeRTOSアプリケーションテンプレートも同様)。
・ベアメタル開発では使わないObjects窓へ、バイナリセマフォ/ミューティックス/キューなどFreeRTOSの8オブジェクト追加。Azure RTOSは4オブジェクト追加。

FreeRTOSとAzure RTOSの追加可能Objects
FreeRTOSとAzure RTOSの追加可能Objects

・Azure RTOS関連資料は、Microsoft公式のコチラ
・FSP v3.6.0提供FreeRTOSサンプルコード数は、1個。Azure RTOSサンプルコードは未提供。

あとがき

RAベアメタルテンプレートを先週発売した直後に今回RTOSの投稿をしたのは、ベアメタル/RTOSに関係なく「RAファミリ開発の鍵はFSP」を示したかったからです。

FSPは、RAファミリのMCU資源(MCUコア/内蔵周辺回路など)を対象に、HAL APIを生成するツールです。開発者は、FSPが生成したHAL APIを使ってRAファミリのアプリケーションを開発します。

FSP対象は、ベアメタルの場合は、MCUコアやIOポートなど実際の回路、RTOSの場合は、タスクやスレッド、RTOSが提供するセマフォやキューなどの様々なオブジェクト(≒仮想回路)が、ベアメタル対象に加わるだけと考えると判り易いと思います。

FSPは、ベアメタル開発用をベースにRTOS開発へも対応し、プライオリティなどRTOS独特の設定も、ベアメタルと同様のGUIで設定します。

つまり、ベアメタルとRTOS両方対応FSPを上手く使いこなせるかが、RAファミリソフトウェア開発の鍵です。効率的にFSPを習得する最初のツールが、RAベアメタルテンプレートと言えます😄。

RAベアメタルテンプレートでFSP習得
RAベアメタルテンプレートでFSP習得

次の段階、つまりRTOS開発へ対応したRAテンプレートも思案中です。ただ、RAベアメタルテンプレートご購入者様からの様々なフィードバックやFSPのRTOSサンプルコード数が増えた後、暫くしてから実現するつもりです。

先ずは、RAベアメタルテンプレートでRAファミリ開発の鍵、FSPを習得してください。ご購入、お待ちしております。

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

FPB-RA6E1で動作中のSimpleTemplateとRTT Viewer
FPB-RA6E1で動作中のSimpleTemplateとRTT Viewer
FPB-RA4E1で動作中のBaseboardTemplateとRTT Viewer
FPB-RA4E1で動作中のBaseboardTemplateとRTT Viewer

ルネサスCortex-M33コア搭載RAファミリ向けRAベアメタルテンプレート(税込1000円)を本日より発売します。概要、仕様、テンプレート提供プロジェクト構成は、コチラから無料ダウンロードできますので、ご検討ください。

RAファミリのポジション

RAファミリ位置づけ(出展:記事に加筆)
RAファミリ位置づけ(出展:記事に加筆)

ルネサスのARM Cortex-M系MCUは、競合他社比、発売が出遅れました。RXやSynergyなどの独自32ビットMCUファミリも供給中のルネサスRA位置づけが上図です。詳細は、コチラの関連投稿3章に説明済みです。

まとめると、RAファミリは、外付けE2エミュレータなどが不要の低価格評価ボードと容量制限なし無償コンパイラ利用など、他のルネサス32ビットファミリには無い個人レベルでも開発可能なARM Cortex-M33/M23/M4コア採用IoTセキュリティ強化MCUです。

RAファミリ開発の鍵:FSP

Flexible Software Package構成
Flexible Software Package構成

RAファミリ開発の鍵は、FSP:Flexible Software Packageです。一言で言うと、HAL APIコード生成ツール。MCU動作速度、内蔵周辺回路などのパラメタをGUIにより設定後、RAファミリ間で共通のHAL APIを一括生成します。
※HAL:Hardware Abstraction Layer

FSP活用で、RAファミリ間での移植性に優れたソフトウェア開発ができます。しかしながら、多くのパラメタをGUI上で設定するため、煩雑で特に初心者にとっては取っ付きづらい面もあります。

また、競合他社より後発のIoT向けMCUですので、FreeRTOSやAzure RTOS、TrustZoneなどのIoTセキュリティにも対応しています。RAファミリの拡張性、将来性を提供するツールがFSPです。

つまり、FSP習得が、RAファミリを使いこなす鍵です(コチラの関連投稿で詳細が判ります)。

RA6/4E1グループ選択理由

RAファミリカタログ(出典:ルネサス)
RAファミリカタログ(出典:ルネサス)

様々なラインナップを供給するRAファミリの中で、汎用性と超低価格な評価ボードも供給済みなのが、RA6E1グループ(Cortex-M33/200MHz)とRA4E1(Cortex-M33/100MHz)グループです。

※RA6E1評価ボード:FPB-RA6E1、RA4E1評価ボード:FPB-RA4E1

RA6/4E1グループとFSPで開発したソフトウェアは、RAファミリ間で共通に使える汎用性を持ちます。また、評価ボードで動作するFSPサンプルコードもありますので、FSP習得にも適しています。

RA6とRA4の分岐点は、最大動作周波数です。

240MHz動作のRA6は、大容量Flashを搭載し、高性能で多機能MCUマーケットを狙い、更に高性能なRA8シリーズへの発展性があります。100MHz動作のRA4は、高性能低消費電力MCUマーケット狙いで、Cortex-M23搭載5Vトレラント性も持つRA2シリーズへ高い親和性を持ちます。

従って、RAファミリ開発を始めるMCUとして、RA6/4E1グループいずれも適していると言えるでしょう。

※RA6最大動作周波数は、カタログでは240MHzとありますが、RAベアメタルテンプレートで用いた評価ボードFPB-RA6E1は、最大200MHz動作です。他RA6シリーズも、同様に現在200MHzです。
※RA8シリーズは、未発売です。

実務直結RAベアメタルテンプレートでFSP習得

近い将来、RTOSやTrustZoneなど、多くのIoT MCU技術を学ぶ必要があります。それでも、MCUの基本技術は、ベアメタルです(コチラの関連投稿参照)。

弊社RAベアメタルテンプレートVersion 1は、RAファミリ中核汎用RA6/4E1グループの超低価格評価ボードを使い、基本のベアメタル開発で、効率的にFSPを習得することが目的です。

FSP習得には、評価ボードサンプルコードが適しますが、サンプルコードは、複数処理が当然の実務応用が簡単ではありません。弊社テンプレートは、複数サンプルコードの活用・流用が簡単で、実務にも使えます。

弊社テンプレートと詳細な説明資料、安価で簡単、拡張性にも優れた推薦開発環境を使えば、誰でも簡単にMCUベアメタル開発の高い障壁を乗越えられ、かつ、FSP習得も可能です。

RAベアメタルテンプレート購入方法は、コチラを参照してください。ご購入、お待ちしております。

FSP v3.6.0更新

昨年12月、RAファミリ開発ツールFSP v3.5.0更新から3ヶ月後の3月5日、新FSP v3.6.0付きe2 studio 2022-01最新版がリリースされました。3月25日、各種評価ボードサンプルコードもFSP v3.6.0対応版となり、RAファミリ開発環境が新しくなりました。

※FSP v3.6.0付きe2 studio 2022-01は、コチラからダウンロードできます。
※各種RA評価ボードサンプルコード FSP v3.6.0版は、コチラからダウンロードできます。

新RAファミリ開発環境

弊社RAファミリ向けテンプレートは、FSP v3.5.0で開発し、3月末発売を予定しておりました。ところが、本家ルネサスRAファミリ開発環境の主役FSPがv3.6.0へ更新され、評価ボードサンプルコードもこれに対応しました。

従って、弊社テンプレートも、これら新環境への対応を確認した上で発売する方が、テンプレートご購入者様の更新手間などを避けるため、好ましいと判断しました。

新開発環境で再構築した弊社RAファミリテンプレートV1(ベアメタル版)発売は、4月末に変更致します。

3ヶ月開発

RAファミリ開発環境の主役:FSP、脇役:e2 studio、各種評価ボードサンプルコードの関係は、コチラに投稿済みです。また、RAファミリテンプレート(ベアメタル版)構想は、コチラの4章、昨年12月の頃です。

RAファミリロードマップ(出展:ルネサスセミナー)
RAファミリロードマップ(出展:ルネサスセミナー)

一方、ルネサスFSP更新は、2~3ヶ月間隔で行われます。新発売のRAファミリデバイスが追加されるためでしょう。今回のように、開発製品リリース直前でFSP更新や開発環境が新しくなることは、多々あり得ます。

ルネサスRA6シリーズウェビナーで紹介された、RAファミリロードマップが上図です。今年以降も、圧倒的な製品展開スピードで新デバイスがどんどん追加されます。

殆どの場合、開発製品は、新環境へもそのまま適用できるハズです。が、その確認には、時間と手間が掛かります。

今回発売変更の教訓は、資料作成なども含めた開発開始から終了は、3ヶ月程度で1開発を完了させるスピード開発が必要だと言うことです。

このスピード開発には、開発中のRAファミリテンプレートが役立ちます。0から開発するのに比べ、既に動作確認済みのテンプレートへ実装機能を追加すれば、プロトタイプが出来上がるからです。

このRAファミリテンプレートは、App0を基に開発しています。App0投稿は、コチラを参照ください。

第2のRAサンプルコード

ルネサスRAファミリ開発に評価ボード毎のサンプルコードが重要であることは、過去何回か投稿済みです。今回は、これとは別の、「Stacks毎」に提供される第2のサンプルコード利用方法を説明します。

RAプロジェクトソースコード開発手順

FSPパースペクティブへ追加するLPM Stack
FSPパースペクティブへ追加するLPM Stack

ごく簡単にRAプロジェクトのソースコード開発手順を説明すると、

1) 利用「Stack」をFSPパースペクティブへ追加
2) Generate Project Contentクリック
3) 生成されたDeveloper AssistanceのStack API群から、利用APIをソースコード上へコピー&ペースト

という3手順の繰返しです。Stackとは、MCU周辺回路のことです。

評価ボードサンプルコードは、あらかじめ1)~3)をエキスパートが行い、サンプルで利用するStackとStack APIは、エキスパートが選択済みの実動作プロジェクトです。

一方、開発者自らが、1)~3)手順でソースコード開発する時は、どのStackを追加するか、利用するAPIは何か、を検討する必要があります。この検討に必要な情報は、全てFSPパースペクティブへ配置したStackのℹ️から得られます。

ℹ️をクリックすると、Stack PropertiesのAPI infoタブ相当の英文解説が読めます。内容は、Function、Overview、Exampleなどです。API info表示内容と同じですが、より詳しい説明が得られます。

「Stack毎」に提供される第2のRAサンプルコードとは、このExampleのことです。

Low Power Modes (r_lpm)の例

RAファミリの4低電力動作モード(出展:RA6E1ユーザーズマニュアル)
RAファミリの4低電力動作モード(出展:RA6E1ユーザーズマニュアル)

MCUアプリケーションに、低電力動作は必須です。RAファミリには、スリープ/ソフトウェアスタンバイ/スヌーズ/ディープソフトウェアスタンバイの4低電力動作モードがあります。例えば、RA6E1グループユーザーズマニュアルハードウェア編の10章を参照ください。

電力消費の最も大きいMCUを停止するのが、スリープモードです。スリープからの復帰時間も短く、簡単で効果的な低電力動作が可能です。

RAファミリで低電力動作を行うには、FSPパースペクティブへ、最初の図に示したLow Power Modes (r_lpm)スタックを追加します。

Stackのℹ️とサンプルコード

追加Stack ℹ️クリックで表示されるのが、LPMの詳細説明です。LPMスタック追加で増える5個全てのLPM APIが解ります。また、スリープモードプロパティがデフォルト設定済みなのも解ります。

このスリープモードのExampleが、下記LPM Sleep Exampleです。

LPM Sleep Example
LPM Sleep Example

利用APIは、R_LPM_Open()とR_LPM_LowPowerModeEnter()の2個のみです。assert(FSP_SUCCESS == err)は、次章で説明します。

注意点は、この「Stacks毎」に提供されるサンプルコードは、一般的なサンプルコード構成、つまり、初期設定と無限ループ内処理の記述形式ではないことです(一般的サンプルコード構成については、コチラの関連投稿参照)。

ここで示されているのは、LPMスリープモード時に利用するAPIとその利用順序です。

つまり、最初にR_LPM_Open()でスタックAPI利用可否を判断し、次に、R_LPM_LowPowerModeEnter()でスリープ動作OKの判断をしているだけです。

LPM以外のStack Examplesでも同様です。繰返しになりますが、Stack Exampleは、利用APIとその利用順序を示します。

従って、自分のソースコードへ取込むには、Developer Assistance内に生成された5個のLPM APIから、R_LPM_Open()を初期設定へ、次に、R_LPM_ LowPowerModeEnter()を無限ループ内の適当な個所へ、コピー&ペーストすれば、LPMスリープモードのソースコードが完成です。

assert(FSP_SUCCESS == err)

assert()は、()内が真の時は、何もしません。偽の時は、発生場所や関数名、ファイル名などをコンソール出力し、プログラムを停止します。API利用後の結果判断に活用しています。

「Stacks毎」に提供されるサンプルコードでは、多くのStack API利用箇所で使われています。

lpm_fpb_ra6e1_wpと比較

lpm_fpb_ra6e1_wpのFSPパースペクティブとhal_entry.cのMain loop部分
lpm_fpb_ra6e1_wpのFSPパースペクティブとhal_entry.cのMain loop部分

評価ボード毎のサンプルコードにも、低電力動作サンプルがありますので、前章Stack Exampleと比較します。

RA6E1の場合は、lpm_fpb_ra6e1_epです。このFSPパースペクティブとhal_entryのMain loopの一部抜粋が上図です。多くのLPM関連スタックが追加済みで、Main loopの低電力動作を解読するのも大変です。

これは、評価ボードサンプルコードが、初めに示した4低電力動作モードの状態遷移を示すプロジェクトだからです。スリープ動作のみを実装する時は、前章LPM StackのExampleを参照した方が簡単に理解できます。

勿論、評価ボードサンプルコードとStack Example、両方を参考にしてソースコードを開発する方が良いことは言うまでもありません。

Stack Exampleが、評価ボードサンプルコード理解を助ける第2のサンプルコードとして役立つことを示したかった訳です。

追加Stacks一覧

本稿は、LPM Stackを例に第2のサンプルコードを説明しました。

FSPパースペクティブへ追加可能なStackは、Stackタブを選択後、右上のNew Stack>をクリックすると一覧表示されます。

まとめ

RAファミリのソースコード開発は、FSPパースペクティブへStackを追加後、一括生成されるDeveloper Assistance内の多くのStack API群の中から、利用APIを適切な順序でソースコードへコピー&ペーストすることで進めます。

利用Stackに複数動作モードがあるなど評価ボードサンプルコードが複雑な場合や、開発者自らが利用Stack APIを検討する場合は、第2のサンプルコードとして、追加Stackのℹ️クリックで得られるExampleに示されるStack APIとその利用順序を参考に、ソースコード開発をする方法を示しました。

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ファミリ開発環境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も進化中ですので、状況観察します。