7.1 硬件软件协同设计：边界与接口

7.1 硬件软件协同设计：边界与接口

本节摘要：嵌入式系统是软硬件一体的工程，很多产品的成败在画原理图之前就定了——功能放硬件还是放软件、接口怎么定义、时序责任归谁。本节给出功能划分的四条判断依据、软硬件接口文档的必备要素，并用一个"滤波放哪层"的典型分歧案例演示协同设计的推演过程。读完你能在设计期就把后面的坑填掉一半。

从一个返工案例说起：边界画错的代价

某电机控制项目初期，硬件团队为省成本把电流采样电阻的阻值减半，心想"软件增益调一下就行"。软件团队接手后发现：采样信号幅度掉了一半，信噪比跟着恶化，软件滤波怎么调都无法在要求的响应时间内恢复精度——硬件省了三毛钱，软件花了三周，最后还是改回硬件方案。这个案例里双方都没做错事，错的是没有"协同设计"这道工序：硬件决策不知道软件的能力边界，软件方案不知道硬件的物理约束。协同设计的本质，就是让两边在做决定之前互相知道对方的账本。

功能划分的四条判断依据

一个功能到底放硬件电路、芯片外设还是软件算法？四条依据按顺序过：

实时性依据：微秒级以下且不容抖动的，放硬件（专用外设、可编程逻辑、模拟电路）。3.2 节的时序案例已证明软件做不了纳秒级的确定性。变化频率依据：需求会变、参数要调的，放软件——固件能 OTA 升级，电路改不了。滤波器类型想随时换，就软件实现；基波抑制这种从不改的，可以硬件 RC。成本批量依据：出货量极大时，一颗几毛钱的硬件滤波电路比几十行的软件代码更划算（软件占用的 Flash 与 CPU 也是成本）；小批量则相反，功能尽量软件化摊薄开发成本。功耗依据：持续运行的固定功能放硬件（专用低功耗前端），软件方案意味着 CPU 不能睡——2.4 节的占空比省电法在硬件面前经常不敌。

四条依据经常打架，打架时用一句话裁决：把"确定性"给硬件，把"灵活性"给软件。时序、隔离、驱动能力这些不容变通的物理需求交给电路；策略、协议、用户逻辑这些必然演进的需求交给代码。

接口文档：软硬件之间的合同

功能划完，边界上要签"合同"。一份合格的软硬件接口文档至少写清四件事：信号定义（每个引脚的名字、方向、电平标准、默认状态——悬空还是上拉，上电期间是什么态）；时序承诺（谁在什么条件下多长时间内必须响应，最坏值而非典型值——7.3 节预算思维的接口版）；电气约束（驱动能力、压降、上拉阻值，以及"软件配置前不得使能"之类的保护顺序）；异常行为约定（对方失效时本方应进入什么状态）。这份文档的价值在异常时才充分显现：联调出问题时，有合同的团队按条款定位责任，没合同的团队互甩锅并重焊电路。

  软硬件接口文档骨架（示例：传感器接口页）
  ┌────────────────────────────────────────────┐
  │ 信号：SENSOR_OUT  方向：传感器→MCU            │
  │ 电平：0 至 3.3V，MCU 侧输入上拉禁止            │
  │ 时序：数据在时钟上升沿前 50ns 稳定（最坏值）    │
  │ 电气：传感器输出阻抗最大 1k，需 MCU 侧高阻输入  │
  │ 异常：传感器失联（总线超时）→ MCU 报错并停采样  │
  │ 上电：MCU 配置完成前传感器输出保持高阻          │
  └────────────────────────────────────────────┘
​

协同优化的边界：谁也别越界替谁做主

协同的另一半是各自领域内的优化不越界。硬件侧常见越界：为省成本压缩裕量（电源余量、去耦电容减配），把"够用"建立在软件从不生病的天真假设上。软件侧常见越界：用软件修补硬件的物理缺陷（噪声大靠均值滤波硬压、时序乱靠重试硬凑）——修补可以救急，但每次软件修补硬件缺陷，都在给系统的不可预测性加杠杆。健康的协同是：硬件问题回到硬件解决（加电容、改布线），软件只负责自己层的问题；实在必须软件兜底的（如传感器漂移校准），在架构里显式设计，而不是散落在各处的"补丁式滤波"。

完整案例：一款电子体温计的协同推演

背景：一款医用体温计，精度正负 0.1 度、测量时间小于 10 秒、纽扣电池寿命一年。操作：用四条依据走一遍划分。温度传感器选热敏电阻加固定分压（硬件解决"量程与接法"，从不变化）；ADC 采集用片内 12 位（外设层）；噪声滤波用软件滑动平均加校准曲线（策略会随传感器批次调整，放软件）；自动关机用定时器加停机模式（功耗依据，软件控制占空比）；测量超时保护用硬件看门狗兜底（生存性需求，独立于软件正确性）。接口文档里最关键一条：热敏电阻的 B 值公差要求写入采购规格——把软件校准能力的边界反推成硬件采购标准。结果：首批样机测量一致性达标，软件侧只做了一轮校准系数调整。解读：这个案例的每一个"放哪"的决定都有一条依据背书，接口文档把软件的能力边界（校准能力有限）转化为硬件的采购约束（B 值公差收紧）——协同设计产出的是决定与条款，不是气氛。

一页接口文档的最小模板

接口文档不必厚重，一页纸够用，关键是字段齐全。给一个可直接套用的骨架：

接口名称：NTC 测温通道
信号与电气：PA3（ADC 通道3）；分压拓扑 3.3V - 10k 精阻 - NTC - GND；
            源阻抗 ≤ 10kΩ；线长 ≤ 10cm，远离时钟走线
时序约束：  上电 100ms 后方可首次采样；连续采样间隔 ≥ 10µs
精度责任：  硬件保证分压电阻精度 ±1%；软件负责校准与滤波，
            系统精度目标 ±0.5 度（25 至 40 度区间）
异常约定：  ADC 读数饱和（0 或 4095）按传感器断线/短路处理，
            软件上报故障码 0x21，硬件不另设判断电路
变更流程：  任一参数改动须双方签字确认并更新版本号，
            旧版本接口的支持期为一个量产周期
​

逐字段看这份合同的约束力：时序约束里的"100ms"吸收了传感器上电稳定时间（谁先采样谁背锅的问题提前销案）；精度责任把"测不准"的责任切成两段，联调时各查各的账；异常约定让故障行为成为规格而非巧合；变更流程则防止"顺手改个电阻"这种善意小动作绕过软件的知情权。这份模板与 5.2 节的优先级表、7.3 节的预算表同属一类工具——把口头默契变成可验收的条款。

问题：小项目一个人软硬件都做，还要写接口文档吗？

写，但写给自己看，份量减半。单人软硬件的真实风险不是扯皮，而是脑子里的口头协议会静默漂移：三周后改硬件参数，你不会记得软件里哪三处依赖旧值；换一颗传感器，你不会记得当初为什么把采样点定在那个时刻。一页纸接口文档对单人的价值是"给三个月后的自己留备忘"——尤其四要素里的异常约定与最坏时序，恰恰是记忆最先丢失的部分。惯例是文档与代码同库存放，硬件改动合并请求里必须同步更新接口页，让"改了硬件没改文档"在评审里显形。工具越轻越好，一页 Markdown 就够，关键是它随代码一起演进。

本节要点回顾

• 四条划分依据：实时性给硬件、变化频率给软件、成本批量算总账、功耗看占空比；打架时"确定性给硬件、灵活性给软件"。
• 接口即合同：信号、时序（最坏值）、电气约束、异常行为四要素；联调扯皮的解药在设计期就写好。
• 优化不越界：硬件裕量别省，软件别硬补物理缺陷；必须软件兜底的要在架构里显式设计。
• 边界反推规格：软件能力边界可以转化为硬件采购标准——这是协同设计的高级形态。
• 体系位置：边界画对了，下一节考虑运行期的另一面——故障终将发生，系统怎么活下来。