第2章嵌入式系统概述

第2章：嵌入式系统概述：MCU与MPU的区别，RTOS与裸机系统的选择，典型嵌入式架构分析

2.1 MCU与MPU：两个世界，两种思维

很多新手问我，MCU和MPU到底差在哪？

我一般会打个比方：MCU就像一辆自行车，MPU像一辆汽车。自行车简单、省油、够用就行。汽车复杂、耗油、但能跑高速。你想想看，去楼下买个菜，骑自行车就够了。要上高速跑长途，那必须得开车。

从技术角度说，MCU（微控制器）把CPU、内存、外设都集成在一个芯片里。我做过一个智能插座项目，用的就是STM32F103，一颗芯片搞定所有事。MPU（微处理器）则不同，它只是个处理器核心，你得自己配DDR、Flash、各种控制器。

核心区别一览：

维度	MCU	MPU
集成度	高，片上集成RAM/Flash	低，需外接内存和存储
功耗	毫瓦级，可电池供电	瓦级，通常需要散热
实时性	硬实时，中断响应快	软实时，受OS调度影响
成本	几元到几十元	几十到几百元
典型应用	传感器、电机控制、家电	路由器、工控机、智能终端

我遇到过最典型的选型翻车案例：有人用树莓派（MPU）去做一个温湿度采集器。结果发现功耗太大，电池撑不过半天。其实用个ESP32（MCU），成本十分之一，功耗百分之一，完全够用。

我的选型建议：

任务单一、实时要求高 → 选MCU
需要跑Linux、多任务、图形界面 → 选MPU
拿不准时，先看功耗预算和成本预算

2.2 RTOS vs 裸机：什么时候该上系统？

裸机系统，说白了就是一个大循环。我最早做51单片机时，就是while(1)里轮询所有任务。简单、直接、没有学习成本。

但问题来了。当你需要同时处理按键、显示、通信、传感器时，裸机就变得很痛苦。我记得有个项目，客户要求按键响应时间不超过10ms，同时还要处理串口数据。裸机里我用了定时器中断+状态机，代码写得跟意大利面条似的。

RTOS（实时操作系统）就是来解决这个问题的。它帮你管理任务调度、资源同步、时间管理。

什么时候该上RTOS？

任务数超过3个，且需要并发执行
有严格的时间约束（比如10ms内必须响应）
需要任务间通信（队列、信号量、邮箱）
代码复杂度高，需要模块化

我个人习惯是：如果项目代码量超过5000行，或者任务数超过5个，直接上RTOS。别犹豫，后期维护成本会低很多。

避坑指南：我曾经在一个低功耗项目里用了FreeRTOS，结果发现空闲钩子里的休眠逻辑写错了，导致功耗比裸机高了3倍。RTOS不是万能药，它本身也有开销。任务切换、中断延迟、内存占用，这些都要算进去。

常见的RTOS选择：

FreeRTOS：开源、轻量、资料多。我90%的项目都用它。
RT-Thread：国产精品，组件丰富，适合IoT。
uC/OS：商业级，稳定，但需要授权。
Zephyr：Linux基金会维护，支持蓝牙、WiFi协议栈。

2.3 典型嵌入式架构分析

嵌入式系统架构，说白了就是「硬件怎么搭、软件怎么跑」。我把它分成三类：

2.3.1 单芯片架构（SoC）

这是最常见的。一颗MCU搞定所有。比如智能手环，用Nordic nRF52840，集成了蓝牙、ADC、GPIO、Flash。软件上跑个FreeRTOS，任务包括：心率采集、显示刷新、蓝牙通信、按键检测。

// 典型任务划分示例
void task_heart_rate(void *param) {
    while(1) {
        read_ppg_sensor();
        calculate_bpm();
        vTaskDelay(pdMS_TO_TICKS(100)); // 10Hz采样
    }
}

void task_display(void *param) {
    while(1) {
        update_oled();
        vTaskDelay(pdMS_TO_TICKS(50)); // 20Hz刷新
    }
}

void task_ble(void *param) {
    while(1) {
        ble_stack_process();
        vTaskDelay(pdMS_TO_TICKS(10));
    }
}

2.3.2 双芯片架构（MCU+MPU）

我做过一个工业网关项目，就是这种架构。MCU负责实时控制（采集传感器、控制继电器），MPU负责上层应用（数据上传、Web界面、日志存储）。

为什么这么分？因为MCU实时性好，但算力弱。MPU算力强，但实时性差。各取所长。

通信方式：MCU和MPU之间一般用SPI或UART。我习惯用自定义协议，帧头+长度+命令+数据+校验。简单可靠。

2.3.3 分布式架构（多节点）

大型系统，比如智能工厂，会有几十个节点。每个节点是一个MCU，通过CAN总线或RS485连接。中央控制器（通常是MPU或工控机）负责汇总数据、下发指令。

这种架构的难点在于：同步、冲突、容错。我踩过一个坑：CAN总线上的两个节点同时发送高优先级报文，导致总线仲裁失败。后来加了随机退避时间才解决。

架构选型总结：

场景	推荐架构	理由
智能家居单品	单芯片MCU	成本低、开发快
工业网关	MCU+MPU	实时+算力兼顾
工厂自动化	分布式多节点	可靠性高、可扩展

嗯，这一章的内容就这些。记住一句话：没有最好的架构，只有最合适的。下次你拿到一个项目需求，先别急着画原理图，花半天时间想清楚：用MCU还是MPU？上不上RTOS？架构怎么搭？这半天时间，能帮你省下后面几个月的返工时间。

📚 课程目录