第三章：技术语言转译——如何把硬件时序、中断优先级讲给市场部听？

说实话，这个题目是我在课程里最想讲的一章。

为什么？因为我见过太多技术牛人，在跟市场部开会时，把好好的项目讲黄了。我自己也踩过这个坑。有一次，我花了半小时解释中断嵌套的优先级反转问题，市场总监直接打断我：“你就告诉我，能不能按时交货？”

嗯，那一刻我明白了——不是他们听不懂，是我不会说。

3.1 先搞清楚：市场部到底想听什么？

市场部的人，脑子里装的是三件事：

• 卖点——这东西凭什么比竞品好？
• 风险——会不会延期？会不会出bug？
• 成本——BOM贵不贵？开发周期多长？

你跟他们讲“时序裕量0.5ns”，他们只会眨眼睛。但如果你说“这个芯片在高温下可能会偶尔卡顿”，他们立刻坐直了。

3.2 硬件时序：别讲建立时间，讲“能不能跑稳”

我个人习惯，跟市场部聊时序时，从来不说“建立时间”“保持时间”这些词。我会这样说：

场景：你设计了一个高速ADC采集板，采样率10MSPS。

技术语言：“这个ADC的时序要求是t_setup=2ns，t_hold=1.5ns，FPGA的IO延时必须控制在±0.3ns以内。”

转译后：“这块板子每秒能采集1000万次数据，每次采集的时机必须精确到纳秒级。如果信号稍微晚到一点点，数据就错了。我们已经在FPGA里做了自动校准，保证不管温度怎么变，都能稳定采集。”

你看，市场部听到的是：速度快、精度高、稳定可靠。这不就是卖点吗？

3.3 中断优先级：别讲嵌套，讲“谁更重要”

中断优先级这个东西，最容易把非技术人员绕晕。什么抢占优先级、子优先级、中断向量表……我自己刚入行时都搞混过。

我的转译方法：

把中断优先级比作“公司的紧急事务处理流程”：

• 最高优先级（比如NMI）——火灾报警。不管你在干什么，立刻跑。
• 高优先级（比如定时器中断）——CEO的电话。重要，但可以等10秒。
• 低优先级（比如按键中断）——同事问你要个文件。等手头事忙完再说。

有一次，市场部问我：“为什么我们的设备有时候按键没反应？”

我解释说：“因为当时CPU正在处理一个更紧急的任务，比如电机堵转保护。按键响应被暂时搁置了。等紧急任务处理完，按键就正常了。”

他们立刻理解了，还追问：“那这个紧急任务处理需要多久？会不会影响用户体验？”

你看，他们关心的是“用户会不会觉得卡”，而不是“中断优先级怎么配置”。

3.4 实战案例：一次成功的跨部门沟通

我记得有个项目，做的是工业网关。硬件上有个棘手问题：SPI总线的时序裕量不够，高温下可能丢数据。

技术方案：降低SPI时钟频率，从20MHz降到10MHz。代价是数据吞吐量减半。

如果我跟市场部说“SPI时序裕量不足，需要降频”，他们肯定问“能不能不改？”

我是这么说的：

“这个网关在85°C高温环境下，数据传输可能会出现偶发错误。概率大概是万分之一。我们有两个选择：

• 方案A：不改硬件，出货后靠软件重传机制补救。但重传会导致响应变慢，用户可能会投诉。
• 方案B：把数据速率降低一半，但保证100%不出错。而且这个速率仍然满足客户需求，因为客户实际只用到了30%的带宽。”

市场部听完，立刻选了方案B。他们还主动跟客户沟通，把“降速”包装成了“增强稳定性”。最后客户很满意。

3.5 建立你的“技术翻译词典”

我建议每个嵌入式工程师，都给自己准备一份“翻译词典”。把常用的技术术语，转译成市场部能听懂的话。

技术术语	转译（对市场部说）
时序裕量	系统在极端条件下的稳定余量
中断优先级	紧急任务的响应顺序
DMA传输	数据搬运工，不占用CPU时间
看门狗定时器	系统自动重启保护
RTOS任务调度	多任务同时运行的交通指挥
功耗管理	省电模式，延长电池寿命
EMC/EMI	抗干扰能力，不干扰其他设备

3.6 总结：沟通的本质是信任

说了这么多，其实核心就一句话：市场部不是不懂技术，而是不懂你的术语。

他们需要的是：

• 知道产品强在哪里（卖点）
• 知道风险有多大（概率、影响）
• 知道什么时候能交付（时间线）

你把这些讲清楚，他们自然信任你。信任建立了，后面的协作就顺畅了。

嗯，这一章就到这里。下一章我们聊聊“如何跟采购部解释BOM成本为什么降不下来”——那又是另一个故事了。