在嵌入式设备研发中，硬件和软件通常可以由不同工程人员分别负责，但这并不意味着两部分可以独立设计到最后再进行组合。

MCU选型会限制程序可使用的Flash、RAM、GPIO和外设资源；软件需要实现的采集、通信、存储、升级或低功耗功能，又会反过来影响主控、电源、外部存储和接口电路设计。

因此，嵌入式软硬件协同并不是简单地“硬件做好以后交给软件写程序”，而是从技术方案阶段开始，持续明确资源、接口、时序、数据和异常处理边界。

对于一个典型嵌入式设备，可以把这条研发链路简化为：

产品功能 → 系统方案 → MCU及器件选型 → 资源分配 → 原理图与PCB → 底层驱动 → 设备功能 → 通信协议 → 板级调试 → 系统联调 → 样机验证

真正容易产生返工的问题，往往就出现在这些环节之间的接口处。

一、嵌入式软硬件协同具体要解决什么问题？

所谓软硬件协同，核心不是让硬件工程师和软件工程师同时开始工作，而是让双方使用同一套系统约束。

例如，一个设备需要完成四路传感器采集、一路RS485通信、一路CAN通信、本地Flash存储和状态指示，那么在选择MCU之前，就应该知道这些功能分别需要哪些资源。

硬件侧需要考虑：

软件侧则需要明确采样周期、数据处理量、缓存大小、通信频率、协议格式、异常恢复和任务调度等问题。

两部分需要在设计阶段形成对应关系。

例如软件需要保存大量离线数据，就不能等PCB完成后才发现内部Flash容量不足；软件需要通过GPIO控制某个模组复位，就必须在原理图阶段预留对应控制引脚。

因此，嵌入式软硬件协同首先解决的是：

软件功能需求能不能在真实硬件资源上实现，以及硬件资源是否为软件运行预留了正确的接口和条件。

二、MCU选型之前，为什么应该先做资源规划？

很多项目容易按照“以前用过某个MCU，所以这次继续使用”的方式确定主控。

对于功能简单、需求固定的产品，这种方式可能没有问题。但随着设备接口、数据处理和通信功能增加，只根据经验或CPU主频选择MCU，容易忽略真正限制项目的资源。

一个相对完整的MCU资源规划，至少要回答以下几类问题。

处理性能是否满足需求

需要考虑的不只是主频，还包括设备实际执行什么任务。

简单的状态控制与高频数据采集、复杂算法、多协议通信，对处理能力的要求完全不同。

Flash和RAM是否足够

Flash主要用于程序及固定数据存储，RAM则与运行时变量、通信缓存、任务栈和数据缓冲直接相关。

如果后续存在功能扩展、协议栈增加或者升级需求，资源规划还应该保留适当余量，而不是在第一版程序中就把资源用到极限。

外设接口是否够用

常见资源包括：

• GPIO；

• UART；

• SPI；

• I²C；

• CAN；

• ADC；

• DAC；

• PWM；

• 定时器；

• DMA。

这里不能只看芯片手册写着“支持多少个接口”，还要继续确认不同外设之间是否存在引脚复用冲突。

其他条件是否匹配

包括工作电压、功耗、封装尺寸、工作环境、外围器件以及供应情况等。

所以，合理的MCU选型实际上应该建立在一张“功能—资源对应表”上，而不是单独比较芯片参数。

关于不同主控平台如何根据产品条件选择，可以进一步延伸到后续的“STM32、ESP32还是嵌入式Linux”选型专题。

三、GPIO和外设资源为什么要在原理图之前基本确定？

GPIO看起来只是一些引脚，但它往往是嵌入式硬件和软件之间最直接的接口。

例如一个GPIO可能用于：

传感器中断、继电器控制、LED、按键输入、模组复位、芯片使能或者设备状态检测。

对于每个关键GPIO，设计阶段最好至少明确：

尤其需要关注“上电默认状态”。

例如某个GPIO负责控制继电器、功率输出或者外部模组，如果MCU刚启动、程序尚未初始化时引脚处于不确定状态，就可能出现短暂误动作。

这种问题不能只依靠后期修改应用程序处理，还需要硬件默认状态与软件初始化逻辑共同保证。

外设分配也存在类似问题。

如果多个器件共享SPI，需要提前确认片选方式；多个I²C器件需要检查设备地址；UART、CAN、PWM和定时器资源则可能与其他引脚功能产生复用关系。

因此，GPIO表和外设资源表并不是项目完成后的文档，而应该在原理图设计阶段就逐步建立。

四、为什么原理图设计阶段已经需要考虑软件？

原理图决定的不只是电气连接，也在很大程度上决定了软件以后“能不能控制”和“怎样控制”。

例如下面这些硬件设计都直接影响嵌入式软件。

外设复位与使能

无线模组、传感器或者其他芯片是否需要独立复位？

如果需要，MCU是否能够控制？

Boot配置

设备如何进入正常程序、Bootloader或者下载模式，需要在硬件阶段确定对应引脚及电平关系。

调试接口

SWD、JTAG、UART等调试方式是否预留，会直接影响样机阶段的问题定位效率。

外部存储

如果产品需要参数保存、日志、数据缓存或升级文件，应该在设计阶段确认内部存储是否够用，以及是否需要外部Flash等器件。

中断信号

传感器或者外部器件是否通过中断通知MCU，会影响硬件连线，也影响软件任务组织方式。

电源控制

低功耗设备可能要求MCU主动关闭传感器、通信模组或者部分电源域，这类需求同样必须在硬件设计中预留控制条件。

因此，在原理图完成之前进行一次软硬件接口检查，往往比样机回来以后再修改硬件成本更低。

五、PCB阶段的软件协同主要体现在哪里？

PCB Layout本身主要属于硬件设计，但嵌入式调试需求仍然应该影响部分布局决策。

例如样机阶段通常需要测量：

• 各路电源；

• MCU复位；

• 时钟；

• 通信信号；

• SPI或I²C；

• 关键GPIO；

• 模拟采集信号。

如果完全没有测试点，出现异常时定位难度会明显增加。

程序下载和调试接口也要考虑实际可操作性。如果接口被结构件遮挡、空间过小或者样机装配后无法连接，后续软件调试同样会受到影响。

对于需要通信的设备，RS485、CAN、Ethernet等接口还需要结合PCB布线、接口保护、连接方式及现场条件综合设计。

所以，PCB阶段的软件参与重点并不是指导工程师怎样布线，而是确保后续需要调试和控制的关键节点能够被访问、测量和验证。

六、驱动开发与硬件调试的边界在哪里？

嵌入式设备第一次上电以后，经常遇到一个典型问题：

某个外设不能正常工作，到底是硬件问题还是驱动问题？

实际上，两者往往需要一起排查。

以一个SPI传感器为例，如果读取不到设备数据，可能需要依次检查：

1. 器件供电是否正常；

2. 复位和使能状态是否正确；

3. SPI引脚连接是否正确；

4. MCU对应外设是否正确初始化；

5. 时钟频率和SPI模式是否匹配；

6. 片选时序是否符合器件要求；

7. 实际波形是否正常；

8. 寄存器读写流程是否正确。

如果只看软件代码，无法确认真实电气信号；如果只使用示波器观察波形，也未必能判断软件发送的数据内容是否符合协议。

所以，驱动开发阶段通常也是嵌入式项目最典型的软硬件联合调试阶段。

比较合理的方式是先验证最小硬件闭环，再逐渐增加功能。

例如：

电源正常 → MCU启动 → 调试接口正常 → 基础GPIO → 单个外设 → 通信接口 → 多模块组合 → 完整业务逻辑

这样出现问题时，定位范围会比一次性运行全部功能更小。

七、设备通信为什么不仅仅是“把串口调通”？

UART、RS485、CAN、Ethernet、BLE或Wi-Fi解决的主要是数据传输通道问题。

真正让两个设备能够长期正确交换数据，还需要应用层通信规则。

例如一个设备通过RS485连接上位机，即使双方串口参数已经一致，也仍然需要定义：

如果这些内容到上位机或APP开始开发时才确定，嵌入式端很可能需要反复调整。

协议设计还要考虑异常情况。

例如：

数据只收到一半怎么办？

连续两帧数据粘在一起如何识别？

命令超时以后是否重试？

重复命令能否再次执行？

旧版本上位机连接新版本设备时怎样处理？

这些问题通常比“串口发送一串字符”更接近设备真正投入使用后的通信需求。

因此，设备通信协议最好在软硬件基本方案确定后尽早定义，并由设备端与应用端共同确认。

八、高采样、多任务设备为什么还要关注数据链路？

对于简单控制设备，MCU可能只是读取状态并执行控制。

但数据采集、状态监测或者测试控制设备还需要关注数据从输入到输出的完整路径。

例如：

传感器 → ADC → DMA → RAM缓存 → 数据处理 → 协议打包 → 通信发送

如果采样速度提高，每一个环节都会受到影响。

假设设备持续产生数据，而通信瞬时速度低于采集速度，就必须考虑缓存。

如果缓存被占满，又需要提前定义：

是丢弃旧数据？

停止采集？

覆盖数据？

还是保存到本地存储？

类似地，多任务系统还需要考虑高优先级采样任务是否会被耗时通信操作阻塞。

因此，嵌入式软件设计不仅要保证“每个功能单独可用”，还要检查系统在持续运行时的数据流和时序是否能够闭环。

这一点在工业数据采集设备中尤其重要。

关于传感器、ADC、MCU和工业通信之间的完整采集链路，可以进一步参考《工业数据采集设备如何设计？从传感器、嵌入式到通信接口的系统分析》。

九、异常处理为什么应该在研发阶段定义？

设备正常工作只是嵌入式软件的一种状态。

真实运行过程中还可能遇到：

• 传感器无响应；

• 通信断开；

• 接收数据错误；

• 外部设备掉线；

• 存储读写失败；

• 参数异常；

• 电源波动；

• 程序任务异常；

• 网络连接失败。

如果程序只实现正常流程，一旦遇到异常就只能依赖重新上电，产品实际稳定性通常会受到影响。

嵌入式软件可以根据具体项目规划相应机制，例如超时、重试、状态机、看门狗、错误码、故障记录、通信重连和安全状态恢复等。

但并不是机制越多越好。

例如，通信失败是否应该无限重试，需要根据系统功能判断；看门狗复位以后哪些状态能够恢复，也需要结合设备用途设计。

关键在于：

在方案阶段先识别重要异常，再确定硬件和软件各自承担什么处理责任。

有些异常可以通过软件恢复，有些则必须通过硬件保护或电路设计解决。

十、样机上电以后，软硬件联调应该按照什么顺序进行？

第一版PCBA完成以后，不建议立即运行所有业务功能。

更稳妥的方式通常是分层验证。

第一阶段：基础硬件检查

先确认输入电源、各路电源、短路情况、复位和关键时钟等基础条件。

第二阶段：MCU启动与下载

确认主控能够稳定启动，下载和调试接口正常。

第三阶段：基础外设

从GPIO、串口等较容易观察的功能开始，逐步验证硬件资源。

第四阶段：传感器与功能器件

逐个验证SPI、I²C、ADC、存储器和其他外围器件。

第五阶段：设备通信

确认RS485、CAN、Ethernet、BLE、Wi-Fi等项目实际使用接口及通信协议。

第六阶段：完整业务逻辑

在底层功能稳定后，再组合采集、控制、通信、存储和状态管理。

第七阶段：异常及持续运行测试

测试断线、重连、重启、掉电、异常输入以及长时间运行等场景。

这种逐层验证方式的价值在于，一旦出现问题，可以比较快速地缩小问题范围。

如果第一版程序直接同时启动全部外设、通信和业务任务，一旦系统异常，往往很难判断究竟是哪一个模块造成。

十一、日志和版本管理为什么也是嵌入式联调的一部分？

嵌入式项目在样机调试过程中通常会不断修改。

如果没有明确版本，很容易出现：

“这块板使用的是哪个固件？”

“这个问题在哪个版本处理过？”

“现在测试的数据对应哪一次硬件修改？”

因此，即使项目规模不大，也建议建立基本的硬件和软件版本对应关系。

例如：

PCB V1.0 + Firmware V0.8

或者记录某次测试对应的硬件版本、固件版本和关键参数。

软件日志同样有价值。

对于无法长期连接调试器的设备，合理记录启动原因、关键状态、错误码和通信异常，可以帮助后续判断问题发生的位置。

尤其对于状态监测、测试控制及长期运行设备，日志往往不仅是开发工具，也可能成为后续问题追溯的重要依据。

十二、怎样判断嵌入式软硬件联调已经基本完成？

“程序可以运行”不能完全等同于联调完成。

不同项目验收标准不同，但至少应该围绕实际产品需求验证关键功能。

通常可以关注几个方面：

如果产品有明确精度、响应时间、采样率、功耗或环境指标，还应该根据双方约定的测试条件进一步验证。

这里尤其需要区分：

功能完成、样机验证完成和产品量产准备完成并不是完全相同的阶段。

嵌入式联调主要解决的是当前软硬件系统是否按照设计目标正确协同运行。

十三、北京心玥科技如何参与嵌入式软硬件开发？

北京心玥科技有限公司围绕电子产品研发、嵌入式软硬件开发、工业电子设备开发、智能硬件与IoT以及PCB/PCBA工程实现开展相关研发工作。

嵌入式项目可以根据当前研发阶段确定参与范围。

对于从需求阶段开始的项目，可以围绕设备功能、硬件资源、主控、接口和通信方式进行方案设计，再逐步进入原理图、PCB和嵌入式固件开发。

对于已有硬件的项目，可以结合已有原理图、PCB、芯片资料和接口定义开展固件、驱动、通信协议或功能开发。

对于已有样机但存在问题的项目，则可以根据现有资料和实际测试现象确定软硬件调试及设计调整范围。

相关工作可根据项目需求涉及：

MCU及核心器件选型、原理图与PCB设计、嵌入式固件、GPIO和外围设备驱动、UART、SPI、I²C等板级接口，以及RS485、CAN、Ethernet、BLE、Wi-Fi等设备通信。

在工业电子设备项目中，还可以围绕数据采集、状态监测、测试控制和设备通信等具体需求开展软硬件协同设计，并根据硬件设备需要配套上位机、APP或Web管理功能。

实际项目并不要求所有环节都由同一方重新开发。已有硬件、已有固件或者已有通信协议的项目，也可以先评估现有资料，再明确需要继续开展的研发范围。

项目最终交付的样机、设计文件、BOM、固件源码、通信协议、测试资料及其他技术文件，以双方实际合作范围和合同约定为准，并非默认全部交付。

嵌入式软硬件开发真正需要解决的，并不是简单地把电路和代码分别完成，而是让主控资源、硬件接口、驱动、通信和设备运行逻辑形成一个能够持续验证的系统。

越早把这些接口和边界明确下来，后续样机阶段越容易定位问题，也越有利于项目继续迭代。

常见问题 FAQ

1. 嵌入式开发和硬件开发可以完全分开吗？

可以由不同团队分工，但系统资源和接口不能完全独立规划。MCU资源、GPIO、存储、电源、通信和调试接口都会直接影响嵌入式软件，因此最好在方案和原理图阶段完成关键接口确认。

2. MCU选型主要需要看哪些参数？

需要结合实际功能综合考虑处理性能、Flash、RAM、GPIO、UART、SPI、I²C、CAN、ADC、PWM、定时器、DMA、功耗、封装和使用环境等因素。不能只根据主频判断。

3. 已经完成PCB以后再开发嵌入式程序可以吗？

可以，但前提是硬件设计已经为软件功能提供足够的资源和接口。如果GPIO、存储、通信或调试接口没有提前匹配软件需求，后续可能需要修改硬件。

4. 驱动调试时怎样判断是软件问题还是硬件问题？

通常需要结合电源、电平、时钟、复位、实际总线波形和软件配置共同判断。对于SPI、I²C、UART等接口，既要确认硬件信号，也要核对初始化参数、时序和数据内容。

5. RS485或CAN接口调通以后为什么还需要设计通信协议？

RS485和CAN主要定义通信物理层或数据链路能力，实际设备之间还需要定义地址、命令、数据、校验、应答、错误码和超时等应用层规则，才能形成完整的设备通信机制。

6. 北京心玥科技可以只做现有硬件的嵌入式软件吗？

可以根据已有硬件资料和项目状态评估参与范围。已有原理图、PCB或样机的项目，可以针对固件、驱动、设备通信、功能开发或软硬件联调等具体工作确定合作内容。