瑞萨 FSP 和 STM32 HAL 库的启动流程核心差异源于启动载体（汇编 vs C 为主）、生态设计理念（一站式整合 vs 分层松耦合）、CMSIS 版本适配，下面从「复位入口→硬件初始化→用户代码跳转」全流程拆解差异，同时保留核心共性。
一、先明确核心共性（底层逻辑一致）
无论 FSP 还是 HAL 库，启动流程的终极目标完全相同：
- 硬件复位后加载中断向量表（固定地址，硬件强制要求）；
- 执行复位处理函数，初始化核心硬件（栈、时钟、内存等）；
- 跳转到用户代码入口（
main()/entry()）； - 提供中断/异常处理的基础框架。
二、启动流程核心差异（分阶段对比）
阶段1：复位入口与中断向量表（最核心差异）
| 维度 | STM32 HAL 库（startup_*.s） |
瑞萨 FSP（startup.c） |
|---|---|---|
| 载体 | 纯汇编文件（.s） |
「极简汇编片段 + 核心 C 代码」（主体是 .c） |
| 中断向量表实现 | 汇编定义全局常量数组（如 g_pfnVectors），包含复位向量、中断服务函数指针，地址固定在 0x00000000 |
仅保留"向量表地址声明"的1-2行汇编（硬件强制），向量表本身用 C 定义（const fsp_vector_t g_vector_table[]），或通过 FSP 配置工具自动生成 |
| 复位向量指向 | 汇编函数 Reset_Handler（整个启动流程的入口） |
汇编片段指向 C 函数 Reset_Handler（无纯汇编的复位处理） |
| 核心特点 | 向量表+复位处理全在汇编，语法依赖编译器（ARMCC/IAR/GCC 各有版本） | 仅向量表地址用汇编，其余逻辑 C 化，跨编译器适配更简单 |
阶段2：复位处理函数（Reset_Handler）
这是启动流程的核心，差异体现在"实现语言"和"初始化逻辑整合度"：
| 维度 | STM32 HAL 库 | 瑞萨 FSP |
|---|---|---|
| 实现语言 | 纯汇编 | 纯 C 函数 |
| 核心步骤 | 1. 汇编初始化栈指针（SP） 2. 初始化堆（可选，汇编调用 __initialise_stackheap） 3. 汇编调用 SystemInit()（CMSIS 标准函数，初始化时钟） 4. 汇编跳转到 main() 5. 若 main() 返回，进入死循环 |
1. C 函数内调用 SystemInit()（FSP 封装版，含栈/时钟/内存初始化） 2. FSP 模块初始化（如 BSP 配置、中断管理器） 3. 按编译器适配跳转： - ARMCC：直接调 main() - GCC：调 entry()（再跳转 main()） 4. 内置 FSP 错误处理（如 main() 异常时的兜底逻辑） |
SystemInit() 差异 |
仅初始化系统时钟（HSE/HSI、PLL），功能极简，与 HAL 库松耦合 | 不仅初始化时钟，还整合： - 栈/堆配置（替代 STM32 汇编栈初始化） - FSP 模块底层配置（如中断优先级、外设基础模式） - 芯片专属硬件初始化（如 RA 系列的 BSP 配置） |
阶段3：用户代码前的初始化（main() 执行前）
| 维度 | STM32 HAL 库 | 瑞萨 FSP |
|---|---|---|
| 初始化触发 | main() 中手动调用 HAL_Init() 才会初始化 HAL 库 |
FSP 启动流程中自动完成基础初始化，main() 中只需调用 R_BSP_Init()/fsp_err_t fsp_init() 即可加载 FSP 配置 |
| 模块整合度 | HAL 库与启动流程松耦合：启动只保证系统能跑，HAL 库初始化是用户可选操作 | FSP 与启动流程深度整合：启动阶段已加载 FSP 配置文件（fsp_cfg.h），外设驱动、RTOS 适配等可直接复用 |
| 可配置性 | 需手动修改 startup_*.s 调整栈大小、中断向量表，或在 main() 中配置 HAL |
基于 FSP 配置工具（e² studio）可视化配置启动参数（栈大小、时钟、中断），自动生成 startup.c 相关代码，无需手写汇编/C |
阶段4：中断/异常处理
| 维度 | STM32 HAL 库 | 瑞萨 FSP |
|---|---|---|
| 中断处理入口 | 汇编向量表指向弱定义的中断服务函数（如 USART1_IRQHandler），用户重写即可 |
C 定义的中断处理函数（如 UART0_IRQHandler），FSP 提供 R_ICU_InterruptEnable() 等统一接口注册中断，无需直接修改向量表 |
| 异常处理 | 汇编定义 HardFault_Handler 等异常函数，用户需手动重写 |
FSP 内置异常处理框架，可通过 fsp_error_t 统一捕获/处理异常，无需手写汇编异常函数 |
三、核心设计理念差异（为什么流程不同？）
| 设计目标 | STM32 HAL 库 | 瑞萨 FSP |
|---|---|---|
| 生态定位 | 通用 HAL 库，适配所有 STM32 系列，与启动流程松耦合，允许用户替换为 LL 库/裸机 | 一站式软件包（FSP = 启动+驱动+RTOS+中间件），从启动到应用全整合，降低开发门槛 |
| 开发者门槛 | 需懂汇编（修改启动文件）、懂 HAL 库初始化逻辑 | 几乎无需汇编知识，核心逻辑 C 化，可视化配置工具替代手写代码 |
| 灵活性 vs 易用性 | 灵活性高（可自定义启动流程、替换 HAL 库），但易用性低（需手动配置多步） | 易用性高（一键配置、自动生成代码），但灵活性稍低（需遵循 FSP 框架） |
| CMSIS 版本 | 基于传统 CMSIS-Core（汇编为主） | 基于新版 CMSIS-Core（C 接口为主），兼容 ARM 最新标准 |
四、流程对比总结（一句话概括）
- STM32 HAL 库：汇编主导启动，启动流程与 HAL 库松耦合，"先让系统跑起来，再由用户手动初始化外设/库"，灵活但需手动操作多；
- 瑞萨 FSP：C 主导启动，启动流程与 FSP 深度整合，"启动阶段就完成大部分底层配置，用户只需调用统一接口即可用所有功能"，易用但需遵循 FSP 框架。
五、实操层面的影响
| 场景 | STM32 HAL 库操作方式 | 瑞萨 FSP 操作方式 |
|---|---|---|
| 修改栈大小 | 编辑 startup_*.s 中的 Stack_Size 宏（汇编） |
在 FSP 配置工具中修改"Stack Size"，自动同步到 startup.c |
| 调整系统时钟 | SystemInit() 或 main() 中调用 HAL_RCC_ConfigClockSource() |
FSP 配置工具中可视化配置时钟树，自动生成时钟初始化代码 |
| 新增中断 | 重写汇编向量表对应的中断函数，手动配置 NVIC | FSP 配置工具中添加中断，自动生成处理函数框架，调用 R_ICU 接口启用 |