| 编辑推荐: |
文章主要介绍了裸机（无操作系统）嵌入式系统的软件架构设计方法,希望对你的学习有帮助。
本文来自于一枚嵌入式码农，由火龙果软件Alice编辑、推荐。
|
|
裸机开发这件事，门槛低，天花板高。
随便写个 while(1) 主循环，里面堆上一堆 if 判断，程序确实能跑起来。但跑起来和跑得好，完全是两码事。很多工程师写了三五年裸机代码，项目越来越大，代码越来越乱，最后系统响应迟钝、功耗居高不下、新功能加不动——问题出在哪？不是裸机不行，是架构没跟上。
做嵌入式开发的这些年，最深的一个体会是： 裸机系统的效率瓶颈，90%不在CPU算力上，而在软件架构上。 同样一颗Cortex-M0，架构好的方案能把CPU利用率控制在15%以内，架构差的方案80%都打不住。差距就是这么大。
这篇文章把我们来聊聊在裸机项目中用过的、验证过的架构方法。不扯教科书理论，只谈工程实战。
先搞清楚：你的主循环是哪种架构？
你可能见过太多项目，主循环写成这样：
int main(void)
{
system_init();
while (1) {
read_sensor();
process_data();
update_display();
check_button();
send_uart_data();
check_timeout();
// ... 还有二十几个函数
}
}
|
这是最原始的 顺序执行架构 ，也叫"超级循环"。它的问题很明显：
- 每个函数都要等上一个跑完才能执行
- 某个函数一旦阻塞，整个系统卡死
- 任务之间没有优先级，按键响应和传感器采集被一视同仁
这种写法在简单项目里没问题，但一旦系统复杂度上来，立刻暴露短板。
主循环架构的演进路线大致是这样的：
下面逐个拆解。
时间片轮询：裸机系统的第一次质变
从超级循环到时间片轮询，是裸机架构最关键的一步。
核心思路很简单： 用一个硬件定时器产生固定节拍（比如1ms），然后给每个任务分配不同的执行周期。 这样每个任务只在自己的时间窗口里运行，互不干扰。
/* 软件定时器结构体 */
typedef struct {
uint32_t period; /* 执行周期（ms） */
uint32_t counter; /* 当前计数 */
uint8_t ready; /* 就绪标志 */
void (*task)(void); /* 任务函数 */
} soft_timer_t;
/* 任务表 */
static soft_timer_t task_table[] = {
{ .period = 10, .task = key_scan }, /* 按键：10ms扫描 */
{ .period = 20, .task = sensor_read }, /* 传感器：20ms采集 */
{ .period = 100, .task = display_update }, /* 屏幕：100ms刷新 */
{ .period = 1000, .task = watchdog_feed }, /* 看门狗：1s喂一次 */
};
/* SysTick中断里只做计数和置标志，不执行任务 */
void SysTick_Handler(void)
{
for (int i = 0; i < TASK_COUNT; i++) {
if (++task_table[i].counter >= task_table[i].period) {
task_table[i].counter = 0;
task_table[i].ready = 1; /* 只置标志！ */
}
}
}
/* 主循环里轮询标志位，执行就绪的任务 */
int main(void)
{
system_init();
while (1) {
for (int i = 0; i < TASK_COUNT; i++) {
if (task_table[i].ready) {
task_table[i].ready = 0;
task_table[i].task();
}
}
}
}
|
这套方案有几个关键的设计要点：
1. 中断里只置标志，不执行任务。 这是铁律。在中断里执行复杂逻辑是裸机系统最常见的翻车原因之一。中断应该像"传令兵"，告诉主循环该干活了，但自己不动手。
2. 任务周期要合理分配。 不是所有事情都需要1ms执行一次。按键扫描10ms足够了（加上消抖正好），屏幕刷新100ms人眼根本看不出区别。周期分配得当，CPU就有大量空闲时间可以进低功耗模式。
3. 任务函数必须是非阻塞的。 每个任务函数执行完要快速返回，绝不能在里面写 delay_ms() 或者死等某个标志位。这一点后面还会展开。
时间片轮询的执行流程：
这套架构在实际项目中应用还是非常广泛的，从温控器到工业网关，覆盖面非常广。它的优势在于简单、可靠、可预测——你能精确知道每个任务多久执行一次，系统行为完全确定。
事件驱动：让CPU"按需工作"
时间片轮询解决了任务调度问题，但它有一个本质缺陷： 不管有没有事情发生，任务都在周期性执行。
传感器没有新数据？照样读。按键没人按？照样扫。这些无效执行浪费了CPU时间，更关键的是——在电池供电的产品上，浪费了功耗。
事件驱动的思路正好相反： 没有事件，CPU就休眠；有事件，才唤醒处理。
/* 事件类型定义 */
typedef enum {
EVT_NONE = 0,
EVT_KEY_PRESS,
EVT_SENSOR_READY,
EVT_UART_RX,
EVT_TIMER_TIMEOUT,
EVT_ADC_DONE,
} event_type_t;
/* 简易事件队列 */
#define EVT_QUEUE_SIZE 16
typedefstruct {
event_type_t buf[EVT_QUEUE_SIZE];
uint8_t head;
uint8_t tail;
} event_queue_t;
static event_queue_t evt_queue;
/* 中断中投递事件 */
void EXTI_IRQHandler(void)
{
event_post(EVT_KEY_PRESS);
}
void DMA_UART_IRQHandler(void)
{
event_post(EVT_UART_RX);
}
/* 主循环：取事件 → 分发处理 → 无事件则休眠 */
int main(void)
{
system_init();
while (1) {
event_type_t evt = event_get();
if (evt != EVT_NONE) {
event_dispatch(evt); /* 根据事件类型调用对应处理函数 */
} else {
__WFI(); /* 没有事件，进入低功耗等待 */
}
}
}
|
事件驱动和时间片轮询的对比：
在一个电池供电的无线传感器节点项目中，我把原来的时间片轮询改成事件驱动后，待机功耗从1.2mA降到了18μA。差距接近70倍。
不过事件驱动也不是银弹。它的复杂度比时间片轮询高不少，事件队列的溢出处理、事件优先级、事件丢失检测这些都需要额外设计。 我的建议是：对响应速度和功耗有要求的模块用事件驱动，对实时性要求不高的后台任务仍用时间片轮询，两者混合使用。
中断管理：裸机系统的命脉
裸机系统没有操作系统帮你管理中断，所有中断逻辑都得自己把控。中断写得好，系统又快又稳；写得差，各种玄学问题层出不穷。
我总结了三条中断铁律，违反任何一条迟早要出事：
铁律一：中断处理函数越短越好
中断里只做三件事：清标志、存数据、发通知。其他一概不做。
/* 反面教材：在中断里处理业务逻辑 */
void UART_IRQHandler(void)
{
uint8_t data = UART->DR;
// 以下操作全都不应该出现在中断里
if (data == FRAME_HEAD) {
parse_frame(); // 协议解析？不行
crc_check(); // CRC校验？不行
execute_command(); // 执行命令？更不行
update_display(); // 刷屏？离谱
}
}
/* 正确做法：中断里只收数据，主循环里处理 */
void UART_IRQHandler(void)
{
uint8_t data = UART->DR;
ring_buf_put(&uart_rb, data); /* 扔进环形缓冲区 */
event_post(EVT_UART_RX); /* 通知主循环 */
}
|
铁律二：搞清楚中断优先级分组
Cortex-M的NVIC支持中断优先级和抢占，但很多人从来没认真配过，全用默认值。结果就是：一个低优先级的串口中断把高优先级的电机控制中断给堵了，电机啪地一下失控。
铁律三：保护共享数据
中断和主循环之间共享的变量，必须做保护。最基本的方式是开关中断：
/* 共享变量 */
volatile uint32_t g_adc_value;
/* 中断中写入 */
void ADC_IRQHandler(void)
{
g_adc_value = ADC->DR;
}
/* 主循环中读取——必须保护 */
uint32_t read_adc_safe(void)
{
uint32_t val;
__disable_irq(); /* 关中断 */
val = g_adc_value;
__enable_irq(); /* 开中断 */
return val;
}
|
对于32位变量在32位MCU上的读写，单次访问本身是原子的，可以不加保护。但如果涉及64位数据、结构体、或者"读-改-写"操作，保护不可省略。另外别忘了 volatile 关键字——少了它，编译器优化可能让你的共享变量永远读到旧值。
状态机：把复杂逻辑拍平的利器
裸机编程最难处理的是什么？不是算法，不是驱动，是 复杂的业务流程 。
一个充电桩的充电流程就涉及：待机→插枪检测→鉴权→预充→恒流充电→恒压充电→充满→结算，中间还有各种异常处理。用 if-else 硬写，代码很快就会变成一团乱麻。
状态机是解决这类问题的标准手段。 它的核心思想是：把系统行为拆分成有限个状态，明确每个状态下该做什么、在什么条件下跳转到哪个状态。
/* 充电状态定义 */
typedef enum {
ST_IDLE, /* 待机 */
ST_PLUG_DETECT, /* 插枪检测 */
ST_AUTH, /* 鉴权 */
ST_PRE_CHARGE, /* 预充 */
ST_CC_CHARGE, /* 恒流充电 */
ST_CV_CHARGE, /* 恒压充电 */
ST_FULL, /* 充满 */
ST_FAULT, /* 故障 */
} charge_state_t;
/* 状态处理函数表 */
typedefstruct {
charge_state_t state;
charge_state_t (*handler)(void); /* 返回下一个状态 */
} state_entry_t;
static state_entry_t state_table[] = {
{ ST_IDLE, handle_idle },
{ ST_PLUG_DETECT, handle_plug_detect },
{ ST_AUTH, handle_auth },
{ ST_PRE_CHARGE, handle_pre_charge },
{ ST_CC_CHARGE, handle_cc_charge },
{ ST_CV_CHARGE, handle_cv_charge },
{ ST_FULL, handle_full },
{ ST_FAULT, handle_fault },
};
/* 状态机主调度 */
void charge_fsm_run(void)
{
static charge_state_t current = ST_IDLE;
for (int i = 0; i < STATE_COUNT; i++) {
if (state_table[i].state == current) {
charge_state_t next = state_table[i].handler();
if (next != current) {
LOG("State: %s -> %s", state_name(current), state_name(next));
current = next;
}
break;
}
}
}
|
状态机的状态跳转关系：
状态机的好处，用过的人都知道：
- 1. 逻辑清晰 ——每个状态的行为独立，出了问题直接定位到具体状态的handler函数
- 2. 天然非阻塞 ——每次调用 fsm_run() 只执行当前状态的逻辑，不需要等待，完美配合时间片轮询
- 3. 易于扩展 ——加一个新状态，只需要增加一个枚举值和对应的handler，不影响其他状态
- 4. 方便调试 ——状态跳转加个日志，整个流程一目了然
消灭delay——裸机效率的头号杀手
如果让我只给一条建议来提升裸机系统效率，那就是： 干掉所有的阻塞延时。
delay_ms(100) 这行代码看起来人畜无害，但它的本质是让CPU空转100ms，什么都不干。在一个10ms轮询周期的系统里，一个100ms的delay意味着其他所有任务被阻塞了10个周期。
非阻塞延时的实现非常简单，用系统节拍做时间戳比较就行：
/* 非阻塞延时：基于时间戳比较 */
static uint32_t sys_tick_ms; /* SysTick中断里递增 */
/* 判断是否超时 */
bool is_timeout(uint32_t start, uint32_t duration)
{
return (sys_tick_ms - start) >= duration;
}
/* 典型用法：LED闪烁（非阻塞） */
void led_blink_task(void)
{
static uint32_t last_toggle = 0;
static bool led_on = false;
if (is_timeout(last_toggle, 500)) { /* 500ms翻转一次 */
last_toggle = sys_tick_ms;
led_on = !led_on;
LED_Write(led_on);
}
}
|
再看一个更实际的例子。串口发送AT指令等待模组回复，阻塞写法和非阻塞写法的对比：
/* 阻塞写法——整个系统卡死等回复 */
bool send_at_command_blocking(const char *cmd, uint32_t timeout_ms)
{
uart_send_string(cmd);
uint32_t start = get_tick();
while (!uart_has_response()) {
if (get_tick() - start > timeout_ms)
return false; /* 超时 */
/* CPU在这里空转！其他任务全部停摆！ */
}
return true;
}
/* 非阻塞写法——用状态机分步处理 */
typedefenum { AT_IDLE, AT_WAIT_RSP, AT_DONE, AT_TIMEOUT } at_state_t;
static at_state_t at_state = AT_IDLE;
static uint32_t at_start_tick;
void at_send_nonblock(const char *cmd)
{
uart_send_string(cmd);
at_start_tick = get_tick();
at_state = AT_WAIT_RSP;
}
/* 在主循环中周期调用 */
at_state_t at_process(void)
{
switch (at_state) {
case AT_WAIT_RSP:
if (uart_has_response()) {
at_state = AT_DONE;
} else if (is_timeout(at_start_tick, 3000)) {
at_state = AT_TIMEOUT;
}
break;
default:
break;
}
return at_state;
}
|
两种写法功能完全一样，但非阻塞版本执行完立刻返回，其他任务完全不受影响。 本质上，这就是把"等待"这个动作从"CPU空转"变成了"状态记录"。
这个思维转换是从"初级裸机开发"到"高级裸机开发"的分水岭。一旦养成这个习惯，你写的裸机系统在响应速度上不会比RTOS差多少。
分层设计：让裸机代码也能"工程化"
前面讲的都是运行效率，但还有一种效率同样重要—— 开发效率 。
裸机项目最常见的困境是：代码跑得还行，但没人敢改。驱动和业务逻辑搅在一起，换个芯片要改几十个文件，加个新功能牵一发动全身。这种项目我接手过不少，重构的代价往往比重写还大。
解决办法是做分层：
举个例子，温度采集这个功能：
/* 驱动层：只管ADC怎么读 */
uint16_t drv_adc_read(uint8_t channel);
/* 服务层：把ADC原始值转成温度 */
float svc_get_temperature(void)
{
uint16_t raw = drv_adc_read(ADC_CH_NTC);
return ntc_raw_to_celsius(raw); /* 查表或公式转换 */
}
/* 应用层：根据温度做业务判断 */
void app_temp_monitor(void)
{
float temp = svc_get_temperature();
if (temp > TEMP_ALARM_THRESHOLD) {
alarm_trigger(ALARM_OVER_TEMP);
}
}
|
每一层职责清晰。换了芯片，改 drv_adc_read 就够了，上面两层一行代码不用动。换了NTC型号，改 ntc_raw_to_celsius 的转换表，应用层也不受影响。
这种隔离带来的开发效率提升，在项目后期会越来越明显。
写在最后
回头看这篇文章讲的这些方法——时间片轮询、事件驱动、中断分层、状态机、非阻塞设计、分层架构——你会发现一个共同点： 它们解决的都不是"怎么让代码跑通"的问题，而是"怎么把代码组织好"的问题。
这背后其实有一个更大的命题： 软件设计 。
做了这么多年嵌入式开发，我最大的感悟是，写代码的能力到了一定阶段就会见顶，真正拉开差距的是设计能力。同样是实现一个通信协议，有人写出来200行搞定、清晰可维护，有人写了2000行还到处是坑。差距不在编码速度，在设计思维。
而设计思维不是凭空产生的，它来自对 设计模式 的学习和实践。
本文中用到的状态机，本质上就是"状态模式"的朴素实现。事件驱动的消息分发，和"观察者模式"如出一辙。函数指针构建的handler表，就是"策略模式"的雏形。分层架构里驱动层对上层暴露统一接口，这是"适配器模式"和"外观模式"的应用。
这些设计模式不是Java和C++的专利。在C语言的嵌入式世界里，它们同样强大，甚至更有价值——因为资源受限的环境下，好的设计能省下真金白银的硬件成本。
|
订阅
