作者：伟德官网 日期：2025-12-01 浏览： 来源：伟德APP下载

1. 以目标驱动的文档体系

在一个产品或项目的开发初期，最关键的是先确立清晰的目标。随后形成一套完整的开发文档框架，确保全体人员对需求、实现路径和质量标准有一致认知。常用的六类文档包括：

- 产品需求说明（PRD），描述产品的核心特性与目标市场

- 功能需求说明（FRD）， detailing 必须具备的功能清单

- 系统实现方案说明，阐述实现思路、关键技术路线与满足需求的手段

- 硬件说明书，描述硬件体系结构与部件选型依据

- 软件/固件设计说明，明确在目标处理器下的软件架构与实现要点

- 测试与验证计划，规定需要覆盖的测试项及验证方法

2. 需求定义的要点与落地案例

需求定义应围绕系统用途、输入输出实现方式以及是否需要用户界面等要素展开。对于小型嵌入式产品而言，明确需求至关重要，因为它能避免后续出现RAM不足、CPU 拍不出应对能力等风险。简单案例示例（用于参考）：

- 系统描述：温泉水泵换水系统

- 电源：9–12V直流供电

- 水泵功率：375W

- 功能要点：单相交流电机控制、低水位保护、可设定的水泵运行时长、提供人工干预模式用于维护、运行时长以30分钟为单位可调、显示屏显示开关状态、剩余时间和人工干预状态，并具备低水位监测与显示

- 商用扩展：EMI/EMC、安全认证、使用环境（温度、湿度、盐雾等）等方面的额外需求

3. 将需求转化为技术规格

在确定需求后，需将用户层面的需求转化为可实现的技术要点，核心思路包括：

- 输入/输出信号处理速率需要多快？

- 是否可使用专用集成电路（ASIC/FPGA）替代通用处理器来完成特定任务？

- 系统是否存在大量用户输入/输出操作，需在处理器选型时纳入考虑？

- 系统与外部设备的接口类型与数量有哪些？

- 设计是否需要具备后续可扩展性或应对需求变化的能力？是否应选用较少概率需要替换的芯片，避免过快被市场替代而带来重新设计成本

4. 处理器选型的要点（结构化要点，从 2.1 至 2.12）

2.1 I/O 引脚数量

- 评估内部存储器需求后，判断是否需要外部存储，以决定是否给外部I/O引脚留足空间以及是否需要额外的驱动资源。

2.2 接口数量

- 选择具备所需外设接口的处理器，确保后续软件可以直接利用内置接口（如USB、Ethernet、I2C、SPI、USART等），避免额外外设带来的成本与复杂性。

2.3 内存容量

- RAM/ROM 的需求来自变量数量、缓冲区大小、队列长度和堆栈需求。若内存不足，需考虑外部内存，但要权衡地址总线和引脚资源的消耗。

2.4 中断数量

- 中断用于对突发事件快速响应，但过多的中断会增加系统复杂度。先明确实际需要的中断数，再评估是否有手段合并或轮换中断。

2.5 实时处理要求

- 实时性通常决定是否需要硬件加速、DMA、内置控制器等。内置接口或专用控制器往往能显著提升实时性能。

2.6 开发工具与生态

- 新处理器往往伴随新开发工具、IDE、编译器等伟德APP。成本不仅体现在采购价，还包括学习成本、仿真和调试成本。

2.7 处理器速度与指令体系

- 速度不仅看主频，还要看指令集、架构设计（RISC/CISC）及内存访问效率。不同应用对带宽和吞吐的要求不同，需结合实际需求评估。

2.8 ROM 类型与容量

- 常用有EPROM/Flash，是否需要可擦写、可在线升级的存储要结合固件更新策略来决定。

2.9 电源与功耗

- 需评估供电方案、是否需要电池供电、以及休眠/待机功耗，以确保整机能在目标使用场景稳定工作。

2.10 工作环境

- 温度、湿度、振动、盐雾等环境因素会直接影响器件选型与封装形式，应提前评估。

2.11 使用寿命与生命周期成本

- 对于长期运行的工业设备，优先考虑长期供货和可升级能力，尽量避免因芯片停产而引发的大规模重新设计。

2.12 技术资料与生态支持

- 常用、成熟的处理器有更多的资料、开发案例和社区支持，能显著降低开发风险与周期。

5. 开发成本的预测与核算

开发成本通常由人力、材料、开发工具和测试工具等组成。经验性核算包括：

- 人力成本（工程、管理、销售、支持等）

- 硬件材料和试错成本（PCB、元件浪费、迭代次数）

- 开发系统与工具软件的购买与维护

- 测试设备与仿真环境的投入

总体而言，人力成本往往成为关键驱动，需在项目初期就进行可观的成本预测与分配。

6. 硬件与软件开发文档的撰写要点

6.1 硬件文档撰写思路

- 以需求与系统规格为起点，给出硬件接口的详细定义，使硬件设计与软件实现在同一张“地图”上推进

- 设计时要给出可让工程师理解的设计意图，以及软件开发者在对接硬件时需要的关键信息（如内存/I/O 地址分布、端口用途、时钟源、外设驱动参数等）

- 对于复杂系统，通常将硬件描述分为两部分：硬件指标与工作原理，以及面向软件的控制接口和编程信息

6.2 软件文档撰写思路

- 软件需求说明应覆盖需要实现的功能、性能指标、与硬件参数的耦合关系

- 规定软件之间、处理器与外设之间的通信协议、缓冲区接口、命令/应答格式、信号控制等

- 通过流程图、伪代码或描述性文本，清晰呈现实现路径与关键算法

- 注意软硬件的分工与接口定义，确保团队协同高效，避免因文档滞后导致的变更成本快速上升

7. 嵌入式高手的取舍与理解

- 功能越多越倾向于软件实现，硬件实现往往带来成本与复杂度的不可控增长；反之，将更多功能落在硬件上虽可提升实时性与稳定性，但会增加硬件成本与迭代成本

- 实际设计中需要在软硬件之间做平衡：对于成本敏感的消费类产品，倾向于在软件层实现更多功能；对于需要高可靠性、低功耗或高实时性的工业设备，可能更偏向在硬件层实现关键功能

- 案例思考：一个基于ARM的音频嵌入式系统，若采用独立解码芯片实现解码，成本较高但实现简单；若让ARM通过软件实现解码，需付出额外的代码与 ROM、RAM 资源，并可能影响实时性，但可以显著降低硬件成本与外设数量。最终取舍应以目标市场、成本结构与维护策略为依据

8. 总结与互动

一份成熟的嵌入式产品开发计划，应从明确目标、建立完整文档体系开始，贯穿需求定义、技术选型、成本评估以及软硬件协同设计的全过程。若在实践中有所收获，欢迎交流讨论，互相学习提升。

返回