📚 课程目录第3章开发环境搭建

3. 开发环境搭建

做嵌入式开发这么多年，我经常被问到同一个问题：“我这项目到底该用裸机、RTOS，还是直接上Linux？”

说实话，没有标准答案。选错了架构，后面改起来真是欲哭无泪。我自己就踩过这个坑——有一次给一个数据采集器选型，图省事直接上了裸机，结果后期要加网络协议栈，代码改到怀疑人生。

这一章，咱们就把这三种架构掰开揉碎了讲清楚。你想想看，搞懂了它们的本质区别，以后选型心里就有底了。

3.1 裸机系统：最纯粹的“跑马灯”时代

裸机系统，说白了就是没有操作系统。你的代码直接在硬件上跑，一个main()函数里写个大循环，所有任务按顺序执行。

核心特征：单任务顺序执行，无任务调度，无资源管理。

我刚开始学单片机时，用的就是裸机。那时候觉得，这不就是嵌入式开发的全部吗？后来才发现，这只是冰山一角。

3.1.1 裸机系统的典型结构

void main(void)
{
    // 硬件初始化
    SystemClock_Config();
    GPIO_Init();
    UART_Init();
    
    while(1)
    {
        // 任务1：读取传感器
        sensor_data = read_sensor();
        
        // 任务2：处理数据
        process_data(sensor_data);
        
        // 任务3：发送结果
        send_uart(sensor_data);
        
        // 延时，防止跑太快
        delay_ms(100);
    }
}

这种结构，简单直观。但问题也很明显——所有任务串行执行。如果某个任务卡住了，整个系统就瘫痪了。

我曾经踩过的坑：有一次做LED点阵屏驱动，裸机下跑得好好的。后来加了个按键扫描，结果按键按下时屏幕会闪。查了半天，原来是按键消抖的延时把显示刷新给堵住了。这就是裸机系统的典型问题——任务之间互相干扰。

3.1.2 裸机系统的适用场景

场景	说明	举例
任务极简单	只有1-2个任务，且无复杂交互	温度传感器读取、LED控制
资源极度受限	RAM < 2KB，Flash < 16KB	8位单片机、小家电控制
实时性要求极高	响应时间 < 1μs	电机控制PWM生成
成本敏感	芯片单价 < 1元	玩具、遥控器

说白了，裸机系统适合那些“做完一件事再做另一件事”的场景。一旦任务多了，或者需要同时处理多个事件，裸机就力不从心了。

3.2 实时操作系统（RTOS）：让任务“并行”起来

RTOS的出现，解决了裸机系统的核心痛点——多任务并发。它通过任务调度器，让多个任务“看起来”在同时运行。

我个人习惯用FreeRTOS，开源、轻量、资料多。当然，uC/OS、RT-Thread也都是好选择。

3.2.1 RTOS的核心机制

RTOS有几个关键概念，你得先搞明白：

任务（Task）：每个任务就是一个独立的无限循环，有自己的栈空间。
调度器（Scheduler）：决定哪个任务该运行。常见的有抢占式调度和协作式调度。
同步与通信：任务之间通过信号量、消息队列、互斥锁等机制交互。
中断管理：中断服务程序（ISR）可以唤醒任务，实现快速响应。

我建议：刚开始学RTOS时，别急着看源码。先理解“任务”这个概念——它就是一个独立的执行流，有自己的“生命”。你只需要告诉调度器“什么时候该运行哪个任务”，剩下的交给系统。

3.2.2 一个典型的RTOS任务示例

// 任务1：读取传感器
void vTaskSensor(void *pvParameters)
{
    while(1)
    {
        sensor_data = read_sensor();
        // 将数据发送到队列
        xQueueSend(xDataQueue, &sensor_data, 0);
        vTaskDelay(pdMS_TO_TICKS(100)); // 延时100ms
    }
}

// 任务2：处理数据
void vTaskProcess(void *pvParameters)
{
    while(1)
    {
        // 从队列接收数据
        if(xQueueReceive(xDataQueue, &sensor_data, portMAX_DELAY))
        {
            process_data(sensor_data);
        }
    }
}

// 任务3：发送结果
void vTaskSend(void *pvParameters)
{
    while(1)
    {
        // 等待信号量
        if(xSemaphoreTake(xSendSemaphore, portMAX_DELAY))
        {
            send_uart(sensor_data);
        }
    }
}

你看，三个任务各自独立，通过队列和信号量通信。传感器任务每100ms读一次数据，处理任务有数据就处理，发送任务等信号量来了再发。互不阻塞，各司其职。

3.2.3 RTOS的适用场景

场景	说明	举例
多任务并发	3-10个任务需要同时处理	智能家居网关、无人机飞控
中等实时性	响应时间 1μs ~ 10ms	工业控制器、机器人
资源适中	RAM 4KB ~ 64KB，Flash 32KB ~ 256KB	STM32F1/F4系列
需要任务隔离	不同任务不能互相影响	医疗设备、汽车电子

注意：RTOS不是万能的。它引入了任务切换开销（通常几十微秒），而且需要额外的RAM和Flash来存储任务栈。我见过有人用8位单片机跑RTOS，结果RAM全被任务栈吃掉了，得不偿失。

3.3 Linux系统：当嵌入式需要“全能”

Linux进入嵌入式领域，是因为有些场景太复杂了——需要文件系统、网络协议栈、图形界面、数据库……裸机和RTOS根本扛不住。

我记得第一次在ARM开发板上跑Linux时，那种感觉就像从自行车换成了汽车。但代价也很明显——启动慢、实时性差、资源消耗大。

3.3.1 嵌入式Linux的特点

功能完整：支持多进程、多用户、文件系统、网络、图形界面。
驱动丰富：大部分硬件都有现成驱动，不用自己写。
生态强大：开源社区、第三方库、开发工具应有尽有。
实时性不足：标准Linux不是硬实时系统，任务调度延迟不可控。

核心矛盾：Linux的“全能”和“实时性”是冲突的。为了功能完整，它牺牲了确定性。如果你需要微秒级的响应，Linux不是好选择。

3.3.2 嵌入式Linux的适用场景

场景	说明	举例
复杂应用	需要文件系统、网络、数据库等	智能路由器、网络摄像头
人机交互	需要图形界面、触摸屏	智能家居中控、工业平板
资源丰富	RAM > 64MB，Flash > 256MB	ARM Cortex-A系列、RISC-V
开发周期短	利用现有软件生态快速开发	物联网网关、边缘计算

3.4 三种架构的对比总结

说了这么多，咱们用一张表来做个直观对比：

维度	裸机系统	RTOS	Linux系统
任务调度	无，顺序执行	抢占式/协作式	时间片轮转+优先级
实时性	极高（无调度开销）	高（微秒级）	低（毫秒级，不可控）
资源需求	极低（KB级）	低（KB~几十KB）	高（MB~GB级）
开发复杂度	低	中	高
功能完整性	差	中	强
典型芯片	8位/16位MCU	32位MCU	32位/64位MPU
典型应用	遥控器、传感器	无人机、工业控制	路由器、智能终端

3.5 如何选择？我的经验法则

每次做项目选型，我都会问自己三个问题：

有多少个任务需要同时处理？ 1-2个→裸机；3-10个→RTOS；10个以上或需要复杂交互→Linux。
实时性要求有多高？ 微秒级→裸机或RTOS；毫秒级→RTOS；秒级或无所谓→Linux。
硬件资源够吗？ RAM < 4KB→裸机；4KB~64KB→RTOS；> 64MB→Linux。

我个人的建议：如果项目复杂度中等，优先考虑RTOS。它比裸机灵活，比Linux简单。而且现在很多MCU都内置了RTOS支持，比如STM32的CubeMX可以直接生成FreeRTOS代码，上手很快。

下面这张图，帮你快速定位：

嗯，这张图基本把三种架构的定位说清楚了。你想想看，如果你的项目只需要做一件事，比如读个温度、亮个灯，裸机就够了。但如果要同时处理传感器、通信、显示、控制，RTOS是更好的选择。至于Linux，它适合那些“功能复杂、资源丰富、对实时性要求不高”的场景。

最后说一句：没有最好的架构，只有最合适的。选型时多想想项目的实际需求，别盲目追求高大上。我见过太多人用Linux做LED控制，结果成本翻了好几倍，性能还没裸机好。