开始之前，必须得先给大家打个预防针：我不是什么权威，下文的方法仅仅是我在实践中摸索出来的、对我目前阶段比较有效的个人经验。
它不一定科学，不一定普适，甚至可能在高手眼里漏洞百出。我只是把它作为一个样本分享出来，希望能给正在同样困境里的朋友一点点启发。请务必结合自己的实际情况去批判性地吸收，有用的拿走，没用的略过就好。
最后再唠叨一句：所有的方法论都是‘鞋，合不合脚只有自己知道。我的分享只是给展示了一双我穿着跑过步的鞋，至于它适不适合，需要自己去试穿、去感受。欢迎在评论区分享的看法，但请别因为我没提到某个点就喷我，毕竟我的认知有限，不可能面面俱到。

往期专栏

数据结构学习
C语言学习
蓝桥杯单片机学习
其余专栏总集

基础认知

大一刚接触嵌入式，很多人第一反应不是兴奋，是迷茫：
一会儿有人说学 STM32，一会儿又说搞 Linux 才有前途；搜个驱动开发，出来一堆设备树、内核源码、交叉编译；再一看课程表，C 语言、单片机原理、微机原理、数字电路……每个都像一座山。

这时候最容易走两条歪路：

资料囤积型：收藏一百个教程，真正动手时发现连第一个工程都跑不起来。

跟敲视频型：照着敲能亮灯，但换个板子、换个串口、换个需求就不会改了。

我想把路线说得更像人话一点：嵌入式不是背名词，也不是追热点；它更像一种“在限制条件下把系统做出来、并且出问题能救回来”的能力。
只要抓住这个核心，很多选择反而简单了。

软件如何发展

别急着选 RTOS 还是 Linux，先问自己一个问题：更想写跑在系统上的软件，还是更想把系统本身搭起来？
我通常把嵌入式 Linux（以及更广义的嵌入式）分成两块：

应用开发：写的是业务软件、界面、网络通信、功能逻辑。
说白了，很多时候它跟 PC 应用开发很像：也是读写文件、网络、线程、协议、UI……只是资源可能更紧一点。
如果走这条路：C 语言、数据结构、（可能还有 Java/Qt）这些基本功要打扎实，系统底层懂一点会更舒服，但不必一上来钻内核。

底层系统：关注的是 bootloader、内核、驱动、rootfs、设备树、启动链路、性能/时序/稳定性。
这条路的“爽点”在于：掌握的是通用能力，换行业、换产品，很多问题本质相同——系统起不来、驱动不工作、性能不稳定、时序出错、资源不够……会从系统角度给出办法。

这里我不想制造“驱动 vs 应用”的对立。现实是：驱动和应用并不是截然分开的。
做应用做久了，迟早会遇到“为什么偶尔卡住”“为什么 IO 延迟飘”“为什么串口丢数据”；这时候懂一点底层，会非常踏实。反过来，懂底层再看应用，也会更清楚哪些设计是可靠的。

C 语言要学到什么程度

在学嵌入式之前，C 语言基础基本逃不掉。汇编有没有？**有当然更好，但真别把它当门槛。**用到的汇编点通常很集中：启动、异常/中断入口、少量关键指令。很多时候是“看到它、知道它在干什么”就够了。

那 C 语言到底要学到什么程度？我给一个不玄学的标准：
不需要把每个标准库函数背下来，但至少要具备这些“能干活的能力”：

能写一些小程序：数组排序、输入数字求和、字符串处理、简单文件读写。

能看懂并正确使用：指针、结构体、数组、函数指针（尤其是后面写驱动/回调时非常常见）。

能解释清楚“内存”相关的问题：
比如栈/堆大概是什么、指针越界为什么危险、为什么野指针会让程序随机崩溃。

学 C 唯一靠谱的方法就是多写、多错、多改。
编译出错没关系，去读错误信息、去定位是哪一行；运行出错没关系，去加日志、去单步、去缩小问题范围。
甚至可以给自己定个“很朴素的训练题来源”：做纯 C、纯逻辑的题（不涉及界面），因为它们能逼把思路写清楚。

嵌入式到底是什么

很多人对嵌入式的误解是：以为嵌入式=单片机=点灯。
其实更准确的说法是：嵌入式系统通常由 处理器 + 存储 + 外设 + 软件栈 构成。
软件栈从下到上可以粗暴分成：启动/底层支持 →（可选）操作系统（RTOS 或 Linux）→ 驱动/中间件 → 应用。

这个分层不是为了“显得专业”，它是为了帮排查问题。以后一定会遇到这种场景：

“怎么突然收不到串口数据了？”
如果脑子里有分层，会先问：

是硬件电平/连线问题？

是外设时钟/配置问题？

是中断没进？

是缓冲区满了？

是任务被饿死了？

是 Linux 里权限/设备节点/参数不对？
会发现排查路径非常清晰，不会靠运气瞎改。

类比一下：
嵌入式像“做一辆车”，不能只会开（写应用），也不能只会修发动机（写底层）。最靠谱的成长方式是：先把车开起来，再逐步学会修关键系统。

MCU / RTOS / 嵌入式 Linux

我更喜欢这样解释三者区别：它们是在 资源、实时性、生态复杂度 上做取舍。

MCU

资源少，但确定性强

MCU 场景常见特点：Flash/RAM 小、功耗敏感、强调确定性响应。会频繁跟寄存器、外设时钟、中断、UART/I2C/SPI/CAN 打交道，调试常见 SWD/JTAG。

很多人会卡在这里的一个坑：
“我把功能都写在中断里，感觉很爽，结果系统一忙就炸。”
要尽早建立一个观念：中断里做“快且必要”的事，耗时逻辑尽量挪到主循环/任务里。
怎么验证做得对？很简单：在串口高频输入、传感器高频采样时，系统还能稳定吗？丢包吗？卡死吗？这就是验证。

RTOS

当不再是一个 while(1)，它用规则帮控复杂度

当的 MCU 程序不再是“一个 while(1) + 中断”，而变成“多个任务需要协作、互斥、按周期运行”，RTOS 就非常有价值。它提供任务调度、队列、信号量/互斥锁等机制，让系统行为可控。

可以这么理解：
RTOS 像一个“靠谱的排队系统”。不是不会干活，而是当事多起来，需要规则来防止互相踩踏。

学 RTOS 时别陷入“背 API”。重点是能回答这些问题：

为什么需要多个任务？每个任务职责是什么？

哪些资源需要互斥？锁粒度怎么控制？

周期任务的抖动从哪来？怎么解释、怎么测？
这些才是面试、也是真实工程最关心的。

嵌入式 Linux

生态强，但要学会“跟系统打交道”

当需要更复杂的网络/文件系统/驱动生态（摄像头、Wi-Fi、蓝牙、容器、GUI 等），Linux 是优势，但实时性与资源开销需要权衡。

Buildroot 这类构建系统对入门很友好：可以更快拿到一套可启动系统，把“交叉编译工具链、rootfs、内核、bootloader”组织起来。
之后再逐步理解每个部件在做什么：启动链路怎么走、rootfs 怎么裁剪、设备树怎么描述硬件、驱动怎么匹配。

驱动是什么

很多新生一听驱动就觉得神秘，其实驱动的核心一句话就够了：
驱动就是把硬件能力包装成软件接口，让上层能稳定使用。

在 MCU 上可能写的是外设驱动/板级驱动：GPIO、UART、定时器、I2C/SPI 等。
在 Linux 上写的是内核驱动：字符设备、I2C/SPI 子系统、网络框架的一部分等等。

设备树（Devicetree）是 Linux 世界里描述硬件的一种关键机制。
可以把设备树理解成“硬件说明书的结构化版”：它告诉内核“我板子上有哪些设备、它们的地址/中断/引脚是什么”。驱动再通过匹配关系绑定上去。

生活化类比：

设备树像“酒店房间号和设施清单”

驱动像“管家”
客人（上层应用）不关心电路怎么走，但希望“开灯就亮、关灯就灭、坏了能报修”。

学驱动时最容易忽略的一点是：驱动不止是“能用”，更是“好用、稳定、可排查”。
这就是为什么调试与工程化在嵌入式里是必修：软硬件耦合 + 时序问题 + 资源受限，必须能把问题定位出来。