Renesas RAファミリ入門
FSPとe2 studioで始める
Armマイコン開発

はじめに：RAファミリとは

RAファミリは、ルネサス エレクトロニクスが展開するArm Cortex-Mコア搭載の32bitマイコンファミリです。ルネサスには独自コアのRXファミリや16bitのRL78ファミリという長い歴史を持つ製品群がありますが、RAはそれらと並ぶ形で2019年に投入され、現在ではエントリ向けのRA0からCortex-M85搭載のハイエンドRA8まで、5つのシリーズを擁するArm系の主力ラインアップに成長しています。

RAの最大の特徴は、「ルネサスの周辺機能・品質」と「Armエコシステム」の両取りができる点です。コアがArmなので、CMSISベースのライブラリ、Arm Keil MDKやIAR Embedded Workbenchといった商用ツール、豊富なRTOS・ミドルウェアがそのまま使えます。一方でタイマやアナログなどの周辺機能、産業向けの長期供給体制はルネサスの流儀そのままです。

本記事では、RAファミリの各シリーズの位置づけを整理したうえで、公式開発環境であるe2 studioとFSP（Flexible Software Package）を使った開発の流れを、実際のコード例（Lチカ・UARTエコーバック）とともに解説します。

RA0/RA2/RA4/RA6/RA8 各シリーズの守備範囲

RAファミリは性能・用途別に5つのシリーズで構成されています。ルネサス公式の位置づけを整理すると次のとおりです。

注目のRA8シリーズ：業界初のCortex-M85搭載

RA8シリーズは業界で初めてArm Cortex-M85コアを採用したマイコン群で、RA8M1/RA8D1/RA8T1は480MHz動作で3000 CoreMark超（6.39 CoreMark/MHz）の性能を公称しています。Cortex-M85はHelium（MVE：M-Profile Vector Extension）に対応しており、Cortex-M7比でDSP・機械学習処理を最大4倍高速化できるとされています。さらにエントリライン（RA8E1：360MHz、RA8E2：480MHz）が2024年に、1GHzのCortex-M85＋250MHzのCortex-M33を組み合わせられるデュアルコア品RA8M2が2025年に加わり、Ethos-U55 NPU搭載品を含めてエッジAI用途への展開が進んでいます。

「マイコンでここまで要るのか」と思われるかもしれませんが、エッジ側での画像・音声のAI推論、モーターの高度なセンサレス制御、HMI（グラフィックス）といった用途では、従来はマイコン＋外付けDSPや小型Linux SoCで組んでいた構成を1チップに収められる可能性があり、選定の幅が大きく広がっています。

FSP（Flexible Software Package）とは

FSP（Flexible Software Package）は、RAファミリ用の公式ソフトウェアパッケージです。STM32でいうSTM32Cube（HAL＋CubeMX）、RXでいうFITモジュール＋Smart Configuratorに相当するもので、次の要素で構成されます。

• BSP（Board Support Package）：起動処理・クロック初期化・ピン設定などデバイス/ボード依存部分
• HALドライバ：UART・I2C・SPI・タイマ・ADC等のペリフェラルドライバ。r_sci_uart、r_ioport のようにモジュール単位で追加する
• RTOSサポート：FreeRTOSとAzure RTOS（現Eclipse ThreadX）の両方を公式サポート
• ミドルウェア：USB（CDC/HID/MSC）、TCP/IP（MQTT対応）、Mbed TLS／NetX Duo Secure等のセキュリティスタック

FSPとe2 studioはルネサスデバイス向けに無償で、FSPはソースコードがGitHubで公開されています。中身を追える・差分を確認できる・issueを検索できるという点は、受託開発で「ドライバの挙動を最後まで説明する」必要がある弊社のような立場では非常にありがたいポイントです。

FSPのHALドライバの考え方

FSPのAPIは「R_モジュール名_操作」という命名で統一されています。たとえばSCI（Serial Communication Interface）をUARTとして使う場合は R_SCI_UART_Open() / R_SCI_UART_Write() / R_SCI_UART_Read() / R_SCI_UART_Close() という4つが基本APIです。

もう一つの特徴がインターフェースと実装の分離です。UARTには共通インターフェース（uart_api_t）が定義されており、実装モジュール（従来SCI向けの r_sci_uart、新しいSCI_B搭載グループ向けの r_sci_b_uart 等）を差し替えても、アプリケーション側の考え方は共通です。デバイスを乗り換えても資産を活かしやすい構造になっています。

e2 studioでプロジェクトを作成する

e2 studioはEclipseベースのルネサス公式IDEで、RA向けにはGCC/LLVMツールチェーンが同梱されます。RAプロジェクトの新規作成は次の流れです。

1. File → New → RA C/C++ Project → Renesas RA を選択
2. 使用する評価ボード（EK-RA6M4等）またはデバイス型番を選択。ボードを選ぶとピン設定の初期値が自動で入る
3. ツールチェーン・RTOS（なし / FreeRTOS / Azure RTOS）を選択
4. プロジェクトテンプレートを選択。「Bare Metal - Minimal」（最小構成）か「Bare Metal - Blinky」（LED点滅サンプル入り）が基本

生成されたプロジェクトは、大きく次の3つの領域に分かれます。この区別を最初に押さえておくと迷いません。

MyProject/
├── src/
│   └── hal_entry.c        // ユーザーコードのエントリポイント（ここを書く）
├── ra_gen/                // FSP Configuratorが生成（編集禁止・再生成で上書き）
├── ra_cfg/fsp_cfg/        // Stacksタブの設定が反映されるヘッダ群
├── ra/                    // FSP本体（BSP・HALドライバのソース）
└── configuration.xml      // FSP Configuratorの設定ファイル

ユーザーコードは src/hal_entry.c の hal_entry() に書きます。ra_gen/ 以下は「Generate Project Content」のたびに再生成されるため、直接編集してはいけません。STM32CubeMXの「USER CODE BEGIN/END」コメント方式と違い、生成コードとユーザーコードがディレクトリで完全に分離されているのがFSP流です。

FSP Configuratorでペリフェラルを設定する

プロジェクトの configuration.xml を開くと、GUIのFSP Configurationビューが立ち上がります。画面下部にタブが並んでおり、役割は次のとおりです。

UARTを追加する実際の手順

例として、SCIチャネルをUARTとして追加する手順です。

1. Stacksタブで HAL/Common を選択し、New Stack をクリック
2. ドライバ一覧から Connectivity → UART (r_sci_uart) を選択
3. Propertiesビューで設定：インスタンス名（g_uart0）、チャネル番号、ボーレート（115200等）、Callback関数名（例：user_uart_callback）
4. Pinsタブで該当チャネルのTXD/RXDピンを割り当て（ボード選択済みなら初期設定済みのことが多い）
5. 右上の Generate Project Content ボタンをクリック

Generateすると、ra_gen/ に g_uart0（インスタンス）、g_uart0_ctrl（制御構造体）、g_uart0_cfg（設定構造体）が生成されます。ユーザーコードからはこの生成済み構造体を使ってAPIを呼ぶだけです。ボーレートやビット構成の計算はすべてConfiguratorが済ませてくれます。

実装例：Lチカ と UARTエコーバック

例1：LED点滅（IOPORT＋ソフトウェアディレイ）

まずは定番のLチカです。GPIOは r_ioport モジュールで、R_IOPORT_PinWrite() にポート/ピン定数（BSP_IO_PORT_xx_PIN_yy）と出力レベルを渡します。

#include "hal_data.h"

void hal_entry(void)
{
    /* LEDピンはボードの回路図で確認して読み替えてください */
    const bsp_io_port_pin_t led_pin = BSP_IO_PORT_04_PIN_00;

    /* ピン設定は生成済みの R_BSP_WarmStart() 内で R_IOPORT_Open() が
       実行済みのため、hal_entry で再度 Open する必要はありません */

    while (1)
    {
        R_IOPORT_PinWrite(&g_ioport_ctrl, led_pin, BSP_IO_LEVEL_HIGH);
        R_BSP_SoftwareDelay(500, BSP_DELAY_UNITS_MILLISECONDS);

        R_IOPORT_PinWrite(&g_ioport_ctrl, led_pin, BSP_IO_LEVEL_LOW);
        R_BSP_SoftwareDelay(500, BSP_DELAY_UNITS_MILLISECONDS);
    }
}

R_BSP_SoftwareDelay() はBSPが提供するビジーループ遅延で、単位は BSP_DELAY_UNITS_SECONDS / MILLISECONDS / MICROSECONDS から選べます。本番コードではタイマ（GPT/AGT）割り込みに置き換えるべきですが、動作確認には十分です。

例2：UARTエコーバック（割り込み＋コールバック）

次に、受信した文字をそのまま送り返すエコーバックです。FSPのUARTドライバは割り込み駆動で、受信・送信完了などのイベントはConfiguratorで登録したコールバック関数に通知されます。コールバックには uart_callback_args_t が渡され、p_args->event でイベント種別、p_args->data で受信データ（UART_EVENT_RX_CHAR 時）を参照します。

#include "hal_data.h"

static volatile bool    g_rx_flag  = false;
static volatile uint8_t g_rx_byte  = 0U;
static volatile bool    g_tx_done  = true;

/* FSP ConfiguratorのCallback欄に指定した関数名。ISRから呼ばれる */
void user_uart_callback(uart_callback_args_t *p_args)
{
    switch (p_args->event)
    {
        case UART_EVENT_RX_CHAR:              /* 1文字受信 */
            g_rx_byte = (uint8_t) p_args->data;
            g_rx_flag = true;
            break;

        case UART_EVENT_TX_COMPLETE:          /* 送信完了 */
            g_tx_done = true;
            break;

        default:
            break;
    }
}

void hal_entry(void)
{
    fsp_err_t err = R_SCI_UART_Open(&g_uart0_ctrl, &g_uart0_cfg);
    if (FSP_SUCCESS != err)
    {
        __BKPT(0);  /* 初期化失敗：デバッガで停止 */
    }

    static const uint8_t msg[] = "RA UART echo start\r\n";
    g_tx_done = false;
    R_SCI_UART_Write(&g_uart0_ctrl, msg, sizeof(msg) - 1U);

    while (1)
    {
        if (g_rx_flag && g_tx_done)
        {
            g_rx_flag = false;

            static uint8_t s_tx_byte;              /* Writeはノンブロッキングのため送信完了まで生存する変数に */
            s_tx_byte = g_rx_byte;
            g_tx_done = false;
            R_SCI_UART_Write(&g_uart0_ctrl, &s_tx_byte, 1U);  /* エコーバック */
        }
    }
}

まとまった長さの受信には R_SCI_UART_Read() で受信バッファと長さを指定し、完了を UART_EVENT_RX_COMPLETE で受ける方法が使えます。公式のサンプル集（GitHubの ra-fsp-examples リポジトリ）には評価ボードごとのUART・I2C・タイマ等のサンプルプロジェクトが揃っており、最初の動作確認はここから始めるのが近道です。

評価ボードの選び方（EK / FPB）

RAの公式評価ボードは主にEK（Evaluation Kit）とFPB（Fast Prototyping Board）の2系統です。いずれもオンボードデバッガを搭載しており、ボード1枚とUSBケーブルだけで開発を始められます。

選び方の目安は次のとおりです。

• まず触ってみたい・コスト重視：FPBシリーズ。数千円クラスで入手でき、J-Link OB内蔵なので追加投資ゼロで書き込み・デバッグまで完結
• 製品搭載予定のMCUグループを本格評価：EKシリーズ。Ethernetや各種センサーコネクタなど周辺回路が揃っており、ミドルウェア込みの評価がしやすい
• DSP/AI・グラフィックスの性能検証：EK-RA8M1（またはグラフィックス向けEK-RA8D1）でHeliumの効果を実測

RX・RL78との違いと、RAを選ぶ判断基準

ルネサスの既存ユーザーにとって最大の関心事は「RX・RL78とどう使い分けるか」でしょう。まず技術面の違いを整理します。

既存RX/RL78資産を持つ会社がRAを検討する判断基準

弊社がお客様と選定する際は、概ね次の基準で整理しています。

• 派生開発・改版が中心 → RX/RL78続行：実績あるコード・治具・ノウハウの価値は大きく、コア変更のリスクを取る理由がなければ既存ファミリの継続が合理的です。RXもRL78も現行で新製品が出ており、すぐに困ることはありません
• 新規設計でセキュリティ要件がある → RAが有力：TrustZone（Cortex-M33/M85）によるセキュア/ノンセキュア分離など、セキュリティを最初から作り込む設計はRAの得意分野です
• Armエコシステム・人材を重視 → RA：STM32等のArm経験者がそのまま戦力になり、CMSIS対応のライブラリや商用RTOS・ミドルウェアの選択肢も広がります。採用市場でも「Arm Cortex-M経験者」は独自コア経験者より圧倒的に見つけやすいのが実情です
• DSP/エッジAI性能が必要 → RA8：Helium対応のCortex-M85クラスは独自コア系にはない選択肢です
• 周辺機能の互換性は個別確認：コアは変わっても、SCI・タイマ等の周辺機能の「思想」はルネサス共通で移行の心理的障壁は低めです。ただしレジスタ互換ではないため、ドライバ層はFSPで書き直しになります

なお、さらに古いH8/SHからの移行を検討されている場合は H8/H8Sマイコン移行ガイド も参考にしてください。移行先の選択肢としてRXと並びRAも有力になっています。

STM32経験者から見たRA

STM32からRAに入るエンジニアは多く、実際、概念の対応関係を押さえればキャッチアップは速いです。

体感として大きな違いは2つです。第一に、FSPは生成コードを一切手で触らせない設計のため、CubeMXでありがちな「USER CODEコメントの外に書いて再生成で消えた」事故が起きません。第二に、FSPのAPIは非同期（割り込み駆動）が基本で、STM32 HALのようなブロッキング版・割り込み版・DMA版の3兄弟という構成ではありません。最初は戸惑いますが、慣れるとイベント駆動で統一されている分、設計は素直になります。

まとめ

RAマイコンを使った新規開発、RX・RL78・H8からの移行検討でお困りのことがあれば、弊社にお気軽にご相談ください。デバイス選定から設計・実装・量産対応まで、20年超のマイコン開発実績で一貫してサポートします。

よくある質問（FAQ）