扶余城里小老二1. 为什么MCU需要轻量级RPC框架
在嵌入式开发中，主控MCU和协处理器之间的协作非常常见。比如用STM32做主控，搭配nRF52832处理蓝牙通信，或者用ESP32连接传感器网络。传统做法是通过串口发送原始数据，然后在接收端手动解析，这种方式不仅效率低，而且维护困难。
我遇到过这样一个项目：主控STM32需要从协处理器获取传感器数据。最初用串口传输JSON字符串，结果发现解析JSON消耗了30%的CPU资源，内存占用更是惊人。后来改用二进制协议，但每次新增功能都要重新设计数据格式，开发效率极低。
RPC（远程过程调用）框架能完美解决这些问题。它让开发者像调用本地函数一样调用远程函数，底层通信完全透明。在资源受限的MCU上实现RPC，需要重点考虑三个因素：
- 内存占用：协议栈应该控制在几KB以内
- 执行效率：函数调用延迟要小于1ms
- 开发便利：接口定义要简单直观
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 协议设计的关键取舍
2.1 二进制协议 vs 文本协议
文本协议（如JSON）可读性好但效率低。实测在STM32F103上解析一个包含3个字段的JSON需要2ms，而同样结构的二进制协议只需0.1ms。我们的轻量级RPC选择二进制协议，帧格式设计如下：
code复制[函数ID(1字节)][参数1(4字节)]...[参数N(4字节)]
对于有返回值的函数，响应帧增加返回数据段：
code复制[执行结果(1字节)][返回数据(N字节)]
2.2 类型系统的简化
在PC端的RPC框架（如gRPC）支持复杂的类型系统，但这在MCU上不现实。我们的方案做了以下简化：
- 所有基本类型（int/float等）统一转为32位传输
- 不支持结构体嵌套
- 指针参数必须明确指定数据长度
例如一个温度读取函数：
c复制// 从机端实现
int read_temp(float *out, int sensor_id);
// 主机端调用
float temp;
rpc_read_temp(&temp, 1); // 读取ID=1的传感器
2.3 错误处理机制
考虑到MCU资源有限，我们采用最简错误码方案：
- 0x00: 成功
- 0x01: 无效函数ID
- 0x02: 参数错误
- 0xFF: 执行失败
在从机端的实现示例：
c复制int rpc_led_set(int state) {
if(state != 0 && state != 1)
return 0x02; // 参数错误
HAL_GPIO_WritePin(LED_GPIO, state);
return 0x00; // 成功
}
3. 内存优化实践
3.1 静态内存分配
动态内存分配在MCU上容易导致碎片化。我们的框架全部采用静态内存：
c复制#define MAX_PARAMS 8
#define MAX_FUNCTIONS 20
typedef struct {
void (*func)(void);
uint8_t param_sizes[MAX_PARAMS];
uint8_t param_count;
} FunctionEntry;
FunctionEntry function_table[MAX_FUNCTIONS];
3.2 参数打包技巧
为了减少内存拷贝，参数直接通过寄存器传递。在ARM Cortex-M架构上可以利用AAPCS调用约定：
assembly复制; 函数跳转实现
ext_call_fun PROC
LDR R12, [SP] ; 加载函数地址
PUSH {R4-R7} ; 保存寄存器
MOV R7, R3 ; 参数4
MOV R6, R2 ; 参数3
MOV R5, R1 ; 参数2
MOV R4, R0 ; 参数1
LDR R0, [SP,#4] ; 参数5
LDR R1, [SP,#8] ; 参数6
LDR R2, [SP,#12] ; 参数7
LDR R3, [SP,#16] ; 参数8
BLX R12 ; 调用函数
POP {R4-R7} ; 恢复寄存器
BX LR ; 返回
ENDP
3.3 注册表设计
函数注册采用索引表方式，避免字符串比较：
c复制void rpc_register(uint8_t id, FunctionEntry *entry) {
if(id < MAX_FUNCTIONS) {
function_table[id] = *entry;
}
}
// 注册示例
FunctionEntry led_func = {
.func = led_control,
.param_sizes = {4},
.param_count = 1
};
rpc_register(1, &led_func);
4. 完整实现案例
4.1 硬件环境搭建
以STM32F407（主机）和nRF52840（从机）为例：
- 物理连接：UART3（STM32）与UART0（nRF52840）交叉连接
- 波特率：115200
- 硬件流控：禁用
接线示意图：
code复制STM32 TX -> nRF52840 RX
STM32 RX <- nRF52840 TX
GND相连
4.2 从机端实现
首先实现框架核心：
c复制// rpc_core.c
void rpc_process(uint8_t *data, uint16_t len) {
uint8_t func_id = data[0];
if(func_id >= MAX_FUNCTIONS)
send_error(0x01); // 无效ID
FunctionEntry *entry = &function_table[func_id];
if(entry->func == NULL)
send_error(0x01);
// 参数解包
uint32_t params[MAX_PARAMS];
uint8_t *ptr = data + 1;
for(int i=0; i<entry->param_count; i++) {
memcpy(¶ms[i], ptr, entry->param_sizes[i]);
ptr += entry->param_sizes[i];
}
// 调用函数
int result = call_function(entry->func, params);
send_response(result);
}
然后实现具体功能：
c复制// sensor_interface.c
int temp_sensor_read(float *out) {
*out = read_ds18b20();
return 0;
}
void rpc_init() {
FunctionEntry temp_func = {
.func = (void*)temp_sensor_read,
.param_sizes = {4},
.param_count = 1
};
rpc_register(0x10, &temp_func);
}
4.3 主机端封装
创建易用的客户端接口：
c复制// rpc_client.h
typedef struct {
UART_HandleTypeDef *huart;
uint8_t tx_buf[32];
uint8_t rx_buf[32];
} RPC_Client;
int rpc_call(RPC_Client *client, uint8_t func_id, void *params, void *result);
实现调用逻辑：
c复制int rpc_get_temp(RPC_Client *client, float *temp) {
return rpc_call(client, 0x10, NULL, temp);
}
// 使用示例
RPC_Client client = { .huart = &huart3 };
float temperature;
if(rpc_get_temp(&client, &temperature) == 0) {
printf("Current temp: %.1fC\n", temperature);
}
4.4 性能实测
在72MHz的STM32F407上测试：
- 空调用延迟：0.3ms
- 带1个float参数的调用：0.4ms
- 内存占用：
- 代码段：3.2KB
- 数据段：1.5KB
相比传统Modbus协议，速度提升5倍，内存占用减少60%。
5. 进阶优化技巧
5.1 批量调用支持
对于需要连续读取多个传感器的场景，可以实现批量调用：
c复制#pragma pack(push, 1)
typedef struct {
uint8_t count;
uint8_t func_ids[8];
uint32_t params[8];
} BatchCall;
#pragma pack(pop)
int rpc_batch_call(RPC_Client *client, BatchCall *call, void **results);
5.2 异步回调机制
通过中断实现异步通知：
c复制void HAL_UART_RxCpltCallback(UART_HandleTypeDef *huart) {
if(huart == client.huart) {
parse_response(client.rx_buf);
}
}
// 注册回调
void rpc_set_callback(uint8_t func_id, void (*cb)(void*));
5.3 功耗优化
在低功耗设备上，可以：
- 使用DMA传输减少CPU唤醒时间
- 压缩协议头（从1字节压缩到4bit）
- 实现唤醒词机制
实测在nRF52840上，优化后每次RPC调用平均功耗从120uA降至45uA。
6. 常见问题解决
6.1 字节序问题
虽然Cortex-M系列都是小端模式，但跨平台时需要注意：
c复制uint32_t normalize_endian(uint32_t val) {
#ifdef BIG_ENDIAN
return __REV(val);
#else
return val;
#endif
}
6.2 超时处理
可靠的通信需要超时机制：
c复制int rpc_call_with_timeout(RPC_Client *client, uint32_t timeout_ms) {
uint32_t start = HAL_GetTick();
while(!response_received) {
if(HAL_GetTick() - start > timeout_ms)
return -1;
__WFI(); // 进入低功耗等待
}
return 0;
}
6.3 调试技巧
添加调试接口可以输出协议细节：
c复制void dump_packet(uint8_t *data) {
printf("RPC Packet:");
for(int i=0; i<data[0]+1; i++) {
printf(" %02X", data[i]);
}
printf("\n");
}
在实际项目中，这套框架成功应用在智能家居控制器上，主控通过RPC同时管理蓝牙模块、温湿度传感器和LED阵列，代码量比传统方案减少40%，而可靠性显著提高。最关键的体会是：在资源受限环境下，适当的约束反而能带来更简洁高效的设计。