关注+星标公众号，不错过精彩内容
来源 | 瑞萨嵌入式小百科
摘要
本文面向具备嵌入式C、MCU外设和RTOS基础的工程师，简要解析FSP（Renesas RA Flexible Software Package）中BSP、HAL、Middleware与RTOS的职责边界、依赖关系和API命名规则。
FSP是瑞萨电子为RA系列MCU提供的一套高质量、可扩展的软件框架。
从内容上看，FSP是一个用C语言编写的、高度可定制的软件包，包括外设驱动程序，涵盖MCU上几乎所有常用外设。
在操作系统方面，FSP支持FreeRTOS，Azure RTOS以及配套中间件。
在安全和存储相关功能上，FSP集成了Arm Mbed TLS、Mbed Crypto以及LittleFS，方便实现加密通信和文件系统功能。
在图形显示方面，支持SEGGER emWin以及TES的Dave2D，适用于有显示需求的应用。
FSP不是单纯的驱动库，而是一套围绕RA MCU架构优化的软件平台。FSP提供统一的软件框架和配置机制，可集成裸机应用、FreeRTOS、Azure RTOS ThreadX等操作系统环境。帮助工程师减少底层重复开发，把重点放在应用逻辑和产品功能上。
01
为什么需要FSP
现代嵌入式系统通常需要同时处理通信、图形、安全、文件系统、云连接和多任务调度等功能。传统的“主循环+中断+手写寄存器”开发方式，在项目复杂度升高后会遇到以下问题：
外设初始化分散，维护困难；
MCU或外设切换时移植成本高；
时钟、引脚、中断配置容易出错；
协议栈、安全和文件系统从零开发成本高；
团队协作时缺少统一配置入口。
FSP的目标是通过分层架构、统一API、图形化配置和自动代码生成降低这些问题带来的工程成本。
02
FSP总体分层模型
FSP可以简化理解为以下结构：
图 1 FSP总体分层结构
FSP包含BSP、HAL、Middleware、FreeRTOS、Azure RTOS以及第三方软件组件。
FSP的核心思想是：
上层调用下层能力，下层不依赖上层应用。
这种结构可以在外设、协议栈或MCU型号发生变化时，将影响范围尽量限制在配置和模块边界内。
03
BSP：系统启动和板级适配
BSP（Board Support Package）位于FSP底层，负责提供RA MCU启动环境、器件支持以及板级相关初始化。BSP主要完成：
时钟初始化；
中断配置；
栈、堆区域定义以及运行环境相关配置；
C/C++运行时环境初始化；
I/O引脚初始配置；
板级特定初始化；
软件延时、寄存器保护、锁机制等基础服务。
工程上应将BSP视为启动层和板级差异管理层，不要把产品应用逻辑写入BSP，也不要在应用代码中随意初始化底层寄存器。
04
HAL：外设驱动抽象
HAL，即Hardware Abstraction Layer，位于BSP 之上。HAL驱动封装了外设寄存器访问、状态管理、中断处理以及硬件资源控制。
典型HAL模块请参考图1中HAL驱动部分。
HAL的重要设计思想是：
接口定义能力，实例实现能力。
例如SPI功能既可以由专用SPI外设实现，也可以由SCI的SPI模式实现。在满足相同接口定义的情况下，例如SPI功能可以由不同硬件模块实现，应用层代码可以最大程度保持一致。
图 2 HAL的接口、实例和具体外设关系。
HAL常见调用API如下：
05
Middleware：复杂功能和协议栈
Middleware位于HAL之上、应用之下，用于封装复杂外设和系统级服务。它解决的不是单个寄存器或单个外设问题，而是完整功能栈问题。
典型Middleware包括：
例如，应用需要实现USB CDC通信时，通常应优先使用USB PCDC Middleware，而不是直接操作USB寄存器或基础USB驱动。Middleware内部会组合基础驱动、描述符、事件处理和传输依赖，应用只需关注打开、发送、接收和事件处理。
Middleware的主要价值：
减少重复开发：USB、TLS、TCP/IP、文件系统等功能复杂，使用现成Middleware 可以降低风险。
提升代码复用：同一功能栈可迁移到具备相应外设资源的不同RA MCU。
降低应用复杂度：应用层不需要直接管理协议状态机、中断和底层传输细节。
06
RTOS：多任务组织
FSP集成FreeRTOS和Microsoft Azure RTOS ThreadX。对于简单应用，可以使用裸机方式运行；但当系统包含多个通信接口、GUI、文件系统、安全协议或云连接时，RTOS能显著改善软件结构。
RTOS主要提供：
线程/任务调度；
优先级管理；
信号量；
队列；
互斥锁；
软件定时器；
线程间通信；
内存管理。
FreeRTOS适合资源受限MCU，具有较小内存占用，并支持任务、队列、信号量、互斥锁、软件定时器和任务通知等机制。
ThreadX更强调确定性和丰富系统服务，支持抢占式调度、Preemption-Threshold、事件标志、消息队列、内存池和TraceX调试能力。
RTOS使用建议：
中断回调尽量短；
耗时逻辑放在线程中处理；
使用队列、信号量或任务通知传递事件；
控制线程优先级数量；
提前评估每个线程的栈大小；
明确静态或动态内存分配策略。
07
FSP API命名规则
FSP API命名具有明确层级含义，工程师可以通过前缀快速判断代码所属模块和抽象层级。
点击可查看大图
FSP的几个核心概念：
点击可查看大图
理解这些概念后，就能更容易看懂FSP Configurator生成的代码结构。
08
总结
RA FSP的设计思想可以概括为：
底层确定，上层可组合；配置驱动生成，接口约束协作；保留源码可见性，同时减少底层重复劳动。
其中：
BSP解决“系统如何可靠启动”；
HAL解决“外设如何被一致访问”；
Middleware解决“复杂功能如何被复用”；
RTOS解决“并发任务如何被组织”；
Application专注于产品应用逻辑。
对工程师而言，掌握FSP的关键不是记住几个API，而是理解各层职责边界、生成文件来源、接口与实例关系、Stack依赖组合，以及回调和RTOS上下文。理解这些之后，RA工程就会从“配置器生成了一堆文件”变成一套可审查、可替换、可维护的软件架构。
------------ END ------------
