企业官网建设流程全解析

很多刚接触嵌入式的人，都纠结过一个问题：手上有个项目，到底是选 STM32 还是树莓派。这两者名字里都有“处理器”，看起来好像都能干活，但实际上完全不是一个物种。用一个不太严谨但很直观的说法：STM32 是“单片机”，树莓派是“一台小的 Linux 电脑”。搞清楚这个本质区别，选型就不会跑偏。

这篇就把两者的差别掰开揉碎讲清楚，从硬件架构、软件生态、实时性、功耗、项目选型、实际开发中容易踩的坑，到两者组合使用的场景，一次说透。文末附一个我在项目里实际用过的选型决策方法，可以直接套用。

1. 硬件架构的本质差异：MCU 与 MPU 的分水岭

1.1 从一块“片上系统”看 STM32 的定位

STM32 是典型的 MCU，也就是微控制器，核心是 Cortex-M 系列内核，常见的包括 M0、M3、M4、M7 等，较新的还有 M33。它的设计哲学是“单芯片搞定一切”。CPU 核心、Flash 存储、SRAM 内存、定时器、ADC、DAC、UART、SPI、I2C、CAN、USB 控制器等，全都集成在一片硅片上，封装小到 QFN 甚至 BGA，焊在板子上几乎不占地方。

这种高度集成的设计带来了几个关键特性。首先是成本极低，一颗主流型号批量价格可能只要几块钱到十几块人民币；其次是功耗低，很多型号在睡眠模式下电流可以降到微安级，适合电池供电；另外是启动极快，上电到跑起 first line 代码通常只需要毫秒级甚至微秒级，没有复杂的引导过程，确定性很高。

但也正因为集成度高，MCU 的资源是固定的。Flash 从几十 KB 到几百 KB，SRAM 从几 KB 到几百 KB，这个数据规模你去跑 Linux 内核根本不现实。所以 STM32 通常跑的是裸机代码或者轻量级 RTOS，比如 FreeRTOS、RT-Thread、UCOS 等。

1.2 树莓派是“微型电脑”而非单片机

树莓派采用的是 MPU 架构，也就是微处理器，核心是 Cortex-A 系列，常见的有 A53、A72、A55 等。它和 STM32 最大的区别是，CPU 和存储是分离的，内存是独立的 SDRAM 颗粒，通常以 POP 或板载的方式焊在主板上，容量普遍在 512MB 到 8GB 甚至更高。操作系统则跑在 SD 卡或 NVMe 固态硬盘上，常见的是 Raspberry Pi OS，也就是基于 Debian 的 Linux 发行版，也可以用 Ubuntu、Arch Linux、甚至 Windows IoT。

硬件上也和 STM32 不同，树莓派的板载资源极其丰富：USB 口、HDMI 口、以太网口、Wi-Fi 蓝牙模块、Camera 接口、DSI 显示接口、GPIO 引脚阵列。这种形态决定了它和“单片机”完全不是一个赛道的东西。它是一个完整的最小 PC 系统，闲鱼上随便收一块旧型号，插个 SD 卡，接上显示器和键盘，就能当一台轻量级电脑用。

1.3 为什么架构差异决定了后边的所有差别

很多人只看表面，觉得两者都能点个灯、读个传感器，就以为差不多。但架构差异是一票否决级的。MCU 的最大价值是确定性和资源可控，而 MPU 的最大价值是算力和操作系统生态。这两种特性天然对立。

你不可能用 STM32 去并行跑几十个复杂进程、在上面训练神经网络模型，也不可能让树莓派在上电后 50 毫秒内完成一次精确的电机控制响应。理解这一点，后面所有关于性能、开发方式、实时性、功耗的讨论就都有了参照系。

2. 软件生态与开发方式的云泥之别：裸机、RTOS、Linux

2.1 STM32 的开发方式：寄存器、标准库与 CubeMX

STM32 的开发上手路径我自己的体验是：第一步裸机点灯，第二步标准库熟悉外设，第三步 HAL 库 + CubeMX 图形化配置，然后跑 FreeRTOS 做多任务。这个过程由浅入深，每一层都在让你更逼近硬件本身，甚至直接操作寄存器。

底层开发让你知道，GPIO 口输出高低电平的本质是把某个寄存器的某个位写 1 或写 0；UART 发送一个字节的本质是往数据寄存器写数据然后等待标志位；ADC 采集一次电压的本质是配置转换通道、启动转换、读结果寄存器。这种“贴地飞行”式开发看起来原始，但价值巨大：出了问题你能从最底层去排查，不会被高层的抽象遮挡。

CubeMX 的出现确实大幅度降低了配置门槛。图形界面里点一点，选择引脚功能、配置时钟树、安排外设参数，然后自动生成初始化代码，编译下载就能跑。但注意，任何工具帮你做的都是“生成配置代码”，业务逻辑的实时性、状态机设计、中断优先级规划，依然靠自己的积累。尤其是中断嵌套和临界区保护，你做不好，系统就是一个随时会死机的炸弹。

2.2 树莓派开发方式：Linux 生态与 Python 的甜蜜陷阱

树莓派的大部分开发者用的是 Python。这非常正常，因为 Linux 下做应用层开发，Python 的生态太丰富了：读取 GPIO 有 RPi.GPIO，读传感器有各种第三方库，采集摄像头用 OpenCV，图形界面用 Tkinter 或 PyQt，网络通信用 Flask 搭个 API。几乎你想到的每一个功能点，pip install 一下就有了，这种开发效率确实爽。

但 Python 在这类系统上的致命弱点必须点名：解释型语言，GIL 全局锁，垃圾回收停顿，再加上 Linux 内核本身不是硬实时系统。树莓派的 GPIO 翻转延时在某些条件下可能达到几毫秒甚至更多，这在控制伺服电机、做高速脉冲输出、解析精准时序信号时，完全是灾难级别的不确定性。

另外一个常见误区是：树莓派的 GPIO 驱动能力并不强。它的 GPIO 输出电压是 3.3V，输出电流只有几毫安，不能直接驱动继电器、直流电机这些大功率设备。很多人以为有 GPIO 就能接各种东西，结果一接继电器，电压被拉低、系统重启，或直接烧毁引脚。你需要驱动板、光耦隔离、电平转换电路，这一点和裸金属 MCU 的设计理念完全不同。

2.3 实时性：硬实时与软实时的根本分野

为什么再三强调实时性，因为这是项目选型中最容易被忽略的核心指标之一。所谓硬实时，是指系统必须在规定时间内完成某个任务，否则就是故障。比如电机电流环的控制周期可能要求 50 微秒到一个 100 微秒，延迟一个周期，电流就可能失控。

STM32 + RTOS 下，中断响应时间可以做到微秒级别，任务切换由你控制，你可以为最关键的任务分配最高优先级，配合中断嵌套，几乎所有时序要求苛刻的场景都能满足。配合定时器硬件 PWM、正交编码器接口、DMA 搬运，实时控制闭环完全可行。

树莓派跑 Linux，任务调度交给内核 CFS 调度器，很多系统服务在后台抢占资源，即使你把 Python 进程的 nice 值调到最低、CPU 亲和性设为单核，内核的中断处理、内存回收、swap 操作一样可能导致响应抖动。而且你无法保证 Linux 系统不会瞬间发生调度延迟。树莓派做图形、视觉、复杂的非实时数据处理没有问题，但“精密运动控制”千万别指望它。

3. 性能、功耗、接口与成本的全面横向对比

3.1 算力对比：不是一个量级的选手

STM32 主频常见在 24MHz 到 480MHz，主流系列如 F103 是 72MHz，F407 是 168MHz，H743 是 400MHz 级别，最新的 H7 系列带双精度 FPU 和 DSP 指令集，算力在 MCU 里确实拔尖了。但它要和树莓派比性能就太欺负人了。

树莓派 4B 用的是 1.5GHz 四核 Cortex-A72，高端的 5B 已经到 2.4GHz 四核 A76，内存高达 8GB 甚至 16GB。它的整数和浮点运算能力、内存带宽、存储 I/O，都在 STM32 的几个数量级之上。说直白一点，STM32 在一个完整的裸机循环里对几百个数据进行 PID 运算已经是极限应用了，树莓派则可以在一个进程里用 OpenCV 实时处理高清视频流。

所以比较两者性能根本没有意义，它们的设计目标完全不同。只有在实际项目中，你才能定义清楚自己需要的性能到底是多少，是关系到实时控制的纳秒级响应，还是缺乏图像处理和存储吞吐的大数据量计算。

3.2 电源与功耗：电池场景下 STM32 完胜

从功耗角度讲，STM32 的价值观是“绝对不允许浪费每一微安”。运行模式通常在几十毫安，睡眠模式能做到微安级别，停机模式甚至只有几百纳安。我之前做过一款电池供电的环境监测设备，一颗 18650 电池配合低功耗定时唤醒，采集温湿度并通过 NB-IoT 上报，理论续航能达到一年以上。这种场景你用树莓派想都别想，一块树莓派空载跑 Linux 至少需要数百毫安，再加外设轻松上安培级，而且它的电源规范非常严苛，电压不稳就容易系统崩溃、文件系统损坏。

除非项目场景是有稳定电源适配器，或者设备本身电量非常充足，否则功耗指标会让树莓派直接出局。

3.3 接口资源与硬件扩展能力

外设接口方面两者各有千秋，但性质不同。STM32 的 UART、SPI、I2C、CAN、USB、ADC、DAC、定时器，都是直接挂在芯片上的，你能精确地配置每一个引脚，做极高速率的周期性采样，产生精确 PWM。很多工业控制板、仪器仪表、电机驱动板，底层都是这种形式的 MCU 在裸跑。

树莓派的 GPIO 引出了 40 个引脚，也支持 UART、SPI、I2C、PWM，但它的引脚复用要进入 Linux 的设备树进行配置，并且很多操作在用户态进行是有损耗的。再有树莓派的通信外设数量和数据吞吐能力也有限，比如 SPI 只有两个硬件控制器，而 STM32 的 F4 系列就有多个 SPI，还可以通过 DMA 做高速无 CPU 干预的数据搬移。

如果你是做传感器采集、PLC 控制、无人机飞控这类硬件密集型的项目，MCU 几乎是必然选择。如果你要接显示器、USB 设备、摄像头、网线并运行一个 web 服务，树莓派才是个合适的宿主。

3.4 成本核算不能只看芯片价格

只看芯片 BOM 成本，STM32 甚至能做到比一杯奶茶还便宜，树莓派板子动辄数百块人民币。但完整项目的成本要看整个生命周期。

MCU 方案的人力成本高，硬件设计复杂，画 PCB 要留意电源、晶振、调试接口，软件要一行行底层的写，调试周期长。但量产后单板成本极低，逻辑简单，稳定可靠，很适合大规模部署。

树莓派方案硬件开发几乎为“零”，不用设计核心电路，直接买开发板开干，外设插上即用，软件生态丰富，一个懂 Python 的工程师几天就能搞定原型。但量产时每一台设备都要买一块树莓派，成本高，而且树莓派不是工业级器件，工作温度范围窄、可靠性存疑、连接器松动可能导致 SD 卡文件系统损坏。如果产品要过严格的 EMC 测试、高低温测试，树莓派方案翻车的概率很大。

所以成本核算一定要站在整个项目定位上：小批量原型验证、工具类产品，树莓派是真香。要量产、要可靠性、要控制成本，转向 MCU方案是必然路径。

4. 项目选型实战角度：什么场景选什么，什么时候可以“混搭”

4.1 经典 MCU 项目画像：电机控制、传感器采集、工业控制器

给我一个最典型的 MCU 项目拆解：一个直流无刷电机驱动器。

电流采样需要 10kHz 到 20kHz 的同步采样率，三个桥臂的 PWM 输出需要精确到微秒级死区控制，换相逻辑需要在一个 PWM 周期内完成，速度环 PID 需要几百微秒的循环周期。这种流水线式的处理，每个环节都是硬实时。树莓派的 Python + Linux 根本做不到，因为你无法保证代码何时被执行，也无法保证中断响应时间。一旦某个周期超时，电机就会抖动、异响甚至烧毁功率管。STM32 的定时器和 ADC 可以完美协同：PWM 定时器触发 ADC 采样，DMA 把数据搬到内存，完成比较、更新、输出，整个过程不需要 CPU 频繁介入，完全可控。

工业现场常见的 Modbus RTU 通讯、CANopen 总线、EtherCAT 从站，更是 MCU 的主场。这些现场总线的时序要求、协议栈实现、物理层处理，都需要在几毫秒甚至几十微秒内完成，这是 Linux 系统难以保证的。

4.2 经典树莓派项目画像：图像识别、Web 服务、多媒体终端

再说一个树莓派做得飞快的项目：视觉检测终端。

比如在传送带上拍照片，用训练好的模型做缺陷分类，然后通过网口把结果上传到数据库，可能还需要在 HDMI 显示屏上画一个实时更新的看板，提供 Web API 给其他系统查询。这个项目如果用 STM32 做，从零开始移植一个完整的 TCP/IP 协议栈就耗尽精力，更不用说跑模型推理了。

树莓派在这里的优势是：Linux 自带了完整的网络栈、GPU 驱动、OpenCV 库、PyTorch 的 CPU 版本推理框架、多语言开发环境。你只需要写好 Python 脚本，摄像头对接、模型加载、结果输出全都是 pip install 级别的工作。做原型通常两三天就能看到效果。这种项目给单片机做，纯粹是拿肉搏战打核战争，完全用错工具。

4.3 混合架构：让 MCU 干苦活，让树莓派干巧活

真正高水平的项目，往往是混合架构。我做过一个农业环境监控柜，就是典型的两级配合。

底层用 STM32 做所有硬件实时任务：循环采集空气温湿度、土壤湿度、光照强度，输出 PWM 控制水泵和风机，检测风速、雨量等报警信号，执行本地紧急断电逻辑。上层用树莓派 4B 做非实时与高复杂度的任务：运行 7 天 24 小时的本地数据记录服务，用 MQTT 协议通过 4G 模块把数据上传到云平台，在本地跑一个简单的网页服务，展示所有传感器曲线和远程控制按钮。

两者之间用 UART 通信，自定义一个简单的 RS485 帧协议。底层上报传感器数据，上层下发控制指令。这样分工的好处非常明显：MCU 保证了每一路输出的实时响应和可靠性，树莓派负责了所有“很难写”的通信和界面功能。即使树莓派崩溃了，最多是远程看不了数据，现场设备依然按安全逻辑运行，不会造成事故。

这种架构在很多产品里很常见：工业 HMI 用 MPU 做显示和联网，底层 PLC 或 MCU 做逻辑控制。医疗设备的上位机软件跑 Windows 或 Linux，下位机一定是 MCU 或者 DSP。机器人项目里，运动控制和传感器融合放 MCU，路径规划和视觉处理放高性能 CPU。选型不是二选一，而是合理分工。

4.4 我做项目时用的“选型决策清单”

这么多年的习惯，我拿到项目需求会先过一遍下面这个清单，几乎不会翻大车。它不是死规则，但如果你不知道怎么选，按这个顺序走一遍就清楚了：

• 有没有硬实时要求：中断响应时间是否要求微秒级？控制周期是否要求毫秒级？如果“是”，树莓派直接出局。
• 功耗是否受限：是否电池供电、对续航有硬指标？如果“是”，STM32 基本是唯一解。
• 数据处理复杂度：是否要做图像处理、AI 推理、大规模日志存储？如果“是”，MCU 单挑会很痛苦。
• 是否需要复杂通信协议栈：Wi-Fi、蓝牙、MQTT、Web API 等是否为核心功能？MCU 上做这些不是不行，但开发周期和调试难度成倍增加。
• 量产规模和环境条件：要产几千几万台？工作温度、振动、EMC 是否严苛？如果是，工业级 MCU 方案是稳妥选择。

还有一个经常被忽略的因素：团队能力边界。如果你团队只会 Python、不会嵌入式 C，同时项目没有硬实时需求，强行上 STM32 只会让项目烂尾。工具再正确，用不来也是白搭。所以识时务地选树莓派搭一个原型出来，比执着于“正统选型”更重要。

5. 从开发实战角度对比：我用 STM32 和树莓派踩过的坑

5.1 STM32 开发中容易忽视的细节

首先是硬件层面的坑。STM32 的引脚多数是 5V 耐压的，但很多型号的 ADC 输入通道并不容忍超过 VDD 的电压，如果侥幸直接把外部 5V 信号分压进 3.3V ADC 口，调节电位器时容易直接烧掉端口。所以高电压信号进入芯片之前，一定要确认电气规格，加保护电路或者选用合适的分压网络。

其次是开发工具链。Keil 编译完代码后，烧录器连接不稳、目标板供电不足、启动引脚配置错误，都可能引发“总是烧不进去程序”的假象。我遇到过几次 ST-Link 一直报连接失败，最后发现是目标板的 3.3V 电压被一个短路的外设拉低了，供电不稳导致芯片无法进入调试模式。排查了半小时才把问题定位到电源上，所以 MCU 开发第一铁律永远是：先量电源，再说话。

软件层面，中断优先级一定要花心思设计。FreeRTOS 的配置文件里，PendSV 和 SysTick 中断优先级必须设置为最低优先级，否则临界区保护无法正常工作，你可能遇到随机死机、任务卡死、调度异常。还有优先级反转的问题，高优先级任务等待低优先级任务释放信号量，配合互斥量的优先级继承机制才能避免。这些全是血泪教训。

5.2 树莓派开发中的高频翻车点

树莓派用起来门槛低，但不代表没有坑。最经典的一个是“直接拔电导致 SD 卡损坏”。Linux 的文件系统缓存并不会实时全部写盘，如果你直接断电，文件系统索引和数据块可能出现不一致，轻则启动时报错自动修复，重则直接启动不了。正确姿势是使用系统关机命令，等它完全停止后再断电。批量部署时更要小心，尽量使用只读文件系统或者带软锁的存储方案。

树莓派的 GPIO 操控也是翻车重灾区。直接用 RPi.GPIO 库在 Python 里做循环翻转，翻转频率最多到几十 kHz，而且因为 Linux 用户态和内核态切换开销，定时不稳定。如果项目真的需要高速 GPIO 脉冲，必须借助 DMA 和硬件 PWM 外设来实现。所以不能把这套 GPIO 想成和 STM32 的寄存器操作一样可靠。

另一个容易忽略的是电源。树莓派官方电源是 5V 3A USB-C 或 microUSB，但很多第三方电源在负载变化时电压跌落明显。你插上多个 USB 设备，外接一堆传感器，结果发生欠压，屏幕上会弹出黄色闪电图标，4B 以上的型号甚至会降低 CPU 频率以保护供电，最直接的后果就是原本流畅的摄像头识别帧率骤降。所以树莓派供电要买足够余量的电源，线材也要选用阻抗低的短粗线，不然老出诡异的问题。

5.3 通信和联网要注意的坑

STM32 连接网络模块时常见的问题是模块和主控之间电平不匹配。很多 NB-IoT、Wi-Fi 模块是 3.3V 逻辑，但串口逻辑电平也可能是 1.8V 或 2.8V，也有的是 5V，直连能把两边都烧掉。正确做法是查数据手册确认电平一致后再接线。UART 的波特率误差也是一个隐藏雷区，两边都写 115200，但如果系统时钟配置有偏差，或者模块固件默认波特率和手册不一致，就会收到乱码。实在无法调通时，先用逻辑分析仪抓波形，看字节间隔和电平是否符合预期，这样可以精准判断问题。

树莓派联网的坑主要体现在防火墙、网络管理和进程管理上。默认镜像自带的网络配置工具和 NetworkManager 同时存在时，你改哪个都可能不生效。最稳妥的是选一个管网络的管理器，配置好静态 IP 或者 DHCP 保留，然后彻底禁用另一个。跑服务时，默认端口经常被系统服务占用，并且很多服务和进程在崩溃退出后不会自动重启，生产环境里需要写 systemd 服务单元文件，守护进程永远开着，崩溃就自动拉起，才能保证设备长时间在线。

5.4 从调试方式看两者的差异

STM32 的调试是“微观调试”。你通过调试器在线仿真，可以看到寄存器值、内存变量、外设状态，断点可以精确打在中断服务函数里面。你能精确知道某条指令执行了多少周期，哪一次中断响应慢了。这种调试方式对时序类问题极其有效，但对数据分析、协议追踪就不太直观。ESP32 这类还支持日志输出，STM32 则要自己串口打印。

树莓派的调试是“宏观调试”。你会通过 SSH 登进去，ps、top、journalctl、dmesg、tcpdump、strace 这样一层一层地看问题。你可以用 Python 交互式终端实时操作硬件，改个脚本马上跑一遍，开发体验是快速试错的节奏。但你要审计一个中断响应时间超时的问题，工具就非常有限了。你只能抓出一个大致的 stat 数据，很难看到微秒级的执行细节，这个大家要有预期。

6. 常见问题与避坑速查表

6.1 典型问题排查：单片机方向

6.2 典型问题排查：树莓派方向

6.3 选型时的三个“一票否决”场景

我总结出三个必须立刻决定方向的条件，不需要慢慢斟酌，出现即锁定结果。

第一个，项目要求微秒级或严格毫秒级确定性响应，比如电机控制、飞控、电源控制、主动悬架，有这种硬实时需求的场合，就不要犹豫，树莓派靠边站，直接选 STM32 或者同类 MCU。

第二个，项目主场景是高算力计算，比如目标检测、语义分割、大量数据服务，这时 STM32 算力根本撑不起来，老老实实上树莓派，或者更专业的带 NPU 的开发板。

第三个，量产成本敏感且设备数量大的场景，你算一遍物料清单和人工维护成本就会明白，一颗 STM32 加自制 PCB 的方案比整块树莓派开发板量产要省得多，前提是你具备硬件设计能力，或者找人合作。

6.4 我一个实际项目的选型实例复盘

做一个室内空气质量监测仪的时候，需求列表是这样的：能测 PM2.5、温湿度、CO2，显示在屏幕上，同时把数据上传到家里的 HomeAssistant。

通过这个需求倒推硬件方案，我选择了 STM32。理由是：传感器数据采集很简单，没有复杂计算；要持续运行，功耗要低；PCB 可以做到很小，塞进塑料外壳里。STM32 采集传感器，用 UART 和 WiFi 模块通信，走 MQTT 协议上传。开发周期大概一周，整个 BOM 成本控制得很好，SMT 贴片后组装即用。

后来另一个朋友的项目是想做一个“家庭植物大棚管家”。需求包括：根据照片判断植物是否生病，摄像头拍照，土壤湿度检测，自动浇水控制，远程查看。我劝他把视觉部分留给树莓派，把土壤采集和浇水控制交给一小块 STM32。最终结构是：树莓派上运行摄像头应用和图像分类模型，STM32 跑去控制水泵和读取土壤湿度，两者通过串口通信。这个项目如果全部让树莓派做，浇水控制很难做到时机精准；全部用 STM32，植物生病的图像判断又根本没戏。各取所长才是解。

7. 扩展能力与未来协作：接口如何在项目中打通

7.1 常见 STM32 + 树莓派通信方式的选择

我最推荐的是 UART 串口通信，因为它简单、可靠，两边都是现成接口，裸机代码和 Linux 下都能轻松操作。协议根据数据量来决定。

数据量小，控制指令级别，自定义几个字节的固定帧格式就够了。比如帧头 + 指令码 + 数据 + 校验和。开销极低，解析逻辑简单，出现问题也好排查。

数据量中等，比如大量传感器列表需要周期上报，建议使用 JSON 配合换行符做流式解析。树莓派用 Python 一次性读入多行 JSON，STM32 这边自己拼字符串通过串口发出即可，开发效率高，结构清晰。

数据量再大，比如带上图像的场景，UART 已经不够，建议用 USB 虚拟串口或者直接用 USB 作为大容量存储、网络接口。树莓派可以模拟成一个 USB 外设，和 STM32 的 USB OTG 对接，但复杂度更高，一般项目不推荐。

7.2 配合中的关键工程细节：逻辑隔离

MCU 系统与 MPU 系统之间最容易被忽略的一层，是电气隔离。树莓派跑 Linux 系统，本身有大量高频开关噪声，如果和 STM32 直接共地共电源，很容易把电源噪声引入模拟采样电路。

我在设计两级系统时，会把它们分成两个电源域：树莓派用 5V 供电板，STM32 用独立 3.3V LDO 或 DC-DC。串口之间的通信，数据量大但速率低，用光耦隔离或者数字隔离芯片，能有效阻止地环路干扰。这个方法简单实用，也能避免一方异常时烧坏另一方的风险。

这个设计思想上最大的收益是“运维解耦”。树莓派上跑的服务经常更新、重启、崩溃，但它和底层控制逻辑是完全隔离的，不会蔓延到现场的实时控制部分。这种稳定边界带来的价值，比那一点硬件成本高得多。

7.3 开发节奏建议：先 MCU 底层，再树莓派上层

做混合架构时，开发顺序反过来才省心。先完成 STM32 的全部本地逻辑，用串口助手模拟上位机指令，把底层功能调稳定、实时性验证达标。再把树莓派接上去，开发它的数据存储、上报、界面逻辑。否则如果你先写树莓派代码，底层的协议对不上，你会在调串口协议上浪费成倍的时间。

这个顺序其实和写软件的分层思想一模一样：先确保内核稳定，再在其上构建业务。硬件系统也一样，底层控制是地基，上层应用是房子，地基不牢，上面怎么搭都歪。

8. 最后分享一点实际使用中的心得

我这些年下来最深刻的感受就是，选型本身不是技术高低的较量，而是对自己需求认知的映射。很多人被误导，以为选树莓派就高级、选 STM32 就落后，实际上它们都是极好的工具，只要你用对场合。

我自己的习惯是，随身带两种板子。手头如果只是临时验证一个想法、处理一份数据、搭一个网页，一定抓个树莓派来用，几行 Python 就能快速验证。而涉及到真正要接入现场的硬件、要长期稳定运行、要对系统有绝对掌控的时候，我会坐下来老老实实画一块 STM32 的 PCB，陪着它调驱动、调时序、优化功耗。两种板子在不同项目里都是救命稻草，谁也替代不了谁。

还有一个比较个人的建议：无论你最终选哪个，一定要把开发环境和调试工具链搞到极度顺手。STM32 这边花一天时间把 CubeMX、编译链、烧录脚本调顺，树莓派这边把 SSH 免密、VNC、VS Code Remote 配置到位，后面开发效率直接翻倍。别小看环境准备这一步，很多项目的工期拖延都是从“环境调不通”开始的。

希望这篇内容能帮你在选型的时候少走弯路，也欢迎看完之后对照自己的项目再过一遍那个决策清单。选对工具，项目就成功了一半；剩下的，就交给耐心和积累了。