2、硬件开发流程基础：硬件开发的生命周期（需求、设计、验证、生产）、硬件版本管理（Git for Hardware）、硬件构建与持续集成

大家好，我是老张。今天咱们聊聊硬件开发流程。

很多人觉得硬件开发就是画板子、焊接、调试。其实不然。一个成熟的硬件产品，从想法到量产，有一套完整的生命周期。我见过太多团队，上来就画原理图，结果后期改得面目全非。说白了，流程不是束缚，是保命符。

2.1 硬件开发的生命周期

硬件开发的生命周期，我习惯把它分成四个阶段：需求、设计、验证、生产。每个阶段都有明确的输入和输出。

2.1.1 需求阶段

这个阶段最容易被人忽视。你想想看，需求没搞清楚，后面全是白干。

需求文档要包含什么？

  • 功能需求：板子要做什么？比如采集温度、控制电机。
  • 性能指标：采样率多少？精度多高？功耗多少？
  • 接口定义：用USB还是以太网？串口波特率多少？
  • 环境约束：工作温度范围？是否要过认证（FCC/CE）？
我的经验：需求文档一定要让软件团队也签字。我在项目中遇到过，硬件留了SPI接口，软件说“我们只用I2C”。结果改版两次，浪费了两周。

2.1.2 设计阶段

设计阶段包括原理图设计和PCB布局布线。

原理图设计要注意什么？

  • 器件选型：别只看价格，要看供货周期。我吃过这个亏。
  • 电源树：每个芯片的供电电压、电流都要算清楚。
  • 去耦电容：位置、数量、容值，一个都不能少。

PCB设计呢？

  • 层叠结构：信号层、电源层、地层怎么分配？
  • 阻抗控制：高速信号要算阻抗，别凭感觉。
  • 热设计：大功率器件要留散热空间。
避坑指南：我曾经在PCB布局时，把晶振放在了板边。结果EMI测试直接超标，被迫改版。记住：晶振要远离板边和连接器。

2.1.3 验证阶段

验证阶段就是“找茬”。

验证包括：

  • 功能测试：每个功能点都要测到。
  • 信号完整性测试：用示波器看波形，看有没有过冲、振铃。
  • 电源测试：纹波、噪声、上电时序。
  • 环境测试：高低温、振动、湿度。

我建议每个硬件工程师都准备一份测试清单。每测一项，打一个勾。别靠脑子记，会漏的。

2.1.4 生产阶段

生产阶段，说白了就是“把设计变成产品”。

这里要注意：

  • DFM（可制造性设计）：焊盘大小、间距、过孔位置，都要考虑SMT工艺。
  • 测试夹具：量产时怎么测？要不要做ICT（在线测试）？
  • BOM管理：物料编码、替代料、供应商信息，都要清楚。
关键点：生产阶段不是设计的终点。我见过很多设计，实验室跑得好好的，一到产线就出问题。为什么？因为产线的环境、操作手法和实验室不一样。所以，一定要做小批量试产。

2.2 硬件版本管理（Git for Hardware）

说到版本管理，很多人觉得那是软件的事。硬件用什么Git？

嗯，这里要注意。硬件也需要版本管理。而且，比软件更复杂。

为什么？因为硬件有二进制文件（原理图、PCB文件），还有文本文件（BOM、测试报告）。Git对二进制文件的支持并不好，但我们可以用一些技巧。

2.2.1 硬件仓库的结构

我建议每个硬件项目都建一个Git仓库，结构如下：

project_root/
├── hardware/
│   ├── schematic/          # 原理图源文件
│   ├── pcb/                # PCB源文件
│   ├── bom/                # BOM文件
│   └── gerber/             # 生产文件
├── firmware/               # 固件代码
├── software/               # 上位机软件
├── docs/                   # 文档
│   ├── requirements.md     # 需求文档
│   ├── design_review.md    # 设计评审记录
│   └── test_report.md      # 测试报告
└── README.md               # 项目说明

2.2.2 二进制文件的版本管理

原理图和PCB文件通常是二进制格式（比如Altium的.PcbDoc、KiCad的.kicad_pcb）。Git没法做diff。

怎么办？

  • 方法一：用Git LFS（Large File Storage）。把二进制文件托管到LFS，仓库里只存指针。
  • 方法二：导出为文本格式。比如KiCad可以导出为.sch和.kicad_pcb，这些是文本文件，Git可以diff。
  • 方法三：生成PDF或图片，作为“快照”提交。这样至少能看到版本变化。
我的习惯：每次提交时，在commit message里写清楚“改了哪里，为什么改”。比如：“修改了电源部分的去耦电容布局，因为原设计纹波过大”。这样以后回溯时，一看就懂。

2.2.3 分支策略

硬件开发也要用分支。我推荐：

  • main分支：只放经过验证的、可以生产的版本。
  • develop分支：日常开发用。
  • feature分支：每个新功能或改版，开一个分支。
  • release分支：准备生产时，从develop拉一个release分支，做最终验证。
注意：硬件分支不要太多。我见过有人一个项目开了20个分支，最后自己都搞不清哪个是哪个。硬件改版成本高，分支要精不要多。

2.3 硬件构建与持续集成

持续集成（CI）在软件领域已经很成熟了。硬件能不能做CI？

能，但和软件不一样。硬件的CI，核心是自动化验证。

2.3.1 硬件CI能做什么？

硬件CI可以做的事情：

  • 自动检查原理图：比如检查有没有未连接的引脚、电源网络是否正确。
  • 自动运行DRC（设计规则检查）：检查PCB的线宽、间距、过孔大小是否符合规则。
  • 自动生成BOM：从原理图导出BOM，并检查物料库存。
  • 自动运行仿真：比如电源仿真、信号完整性仿真。
  • 自动生成生产文件：Gerber文件、钻孔文件、贴片坐标文件。

2.3.2 硬件CI的工具链

我常用的工具链：

环节 工具 说明
原理图检查 KiCad ERC / Altium DRC 自动检查电气规则
PCB检查 KiCad DRC / Altium DRC 自动检查设计规则
仿真 LTspice / PSpice 电源、信号仿真
BOM生成 Python脚本 / 工具自带 导出BOM并检查
生产文件生成 KiCad / Altium 自动导出Gerber
CI平台 GitLab CI / Jenkins 调度以上工具

2.3.3 一个简单的硬件CI流水线示例

假设我们用GitLab CI，流水线可以这样写：

stages:
  - check
  - simulate
  - export

check_schematic:
  stage: check
  script:
    - kicad-cli sch erc project.sch
    - echo "ERC passed"

check_pcb:
  stage: check
  script:
    - kicad-cli pcb drc project.kicad_pcb
    - echo "DRC passed"

simulate_power:
  stage: simulate
  script:
    - ltspice -b power_supply.asc
    - echo "Simulation done"

export_gerber:
  stage: export
  script:
    - kicad-cli pcb export gerber project.kicad_pcb
    - echo "Gerber files generated"
  artifacts:
    paths:
      - gerber/
我的建议：硬件CI不要追求“全自动”。有些验证（比如信号完整性测试）还是需要人工看波形。CI的作用是“把能自动化的都自动化”，让人去处理那些需要判断的事情。

2.3.4 硬件CI的挑战

说实话，硬件CI做起来比软件难。为什么？

  • 工具许可证：很多EDA工具需要许可证，CI环境里怎么部署？
  • 运行时间：仿真可能跑几个小时，CI流水线会很长。
  • 硬件依赖：有些验证需要连接实际硬件（比如烧录固件、测试信号），CI环境里怎么搞？

我的做法是：分步走。先把能自动化的（ERC、DRC、BOM检查）跑起来。仿真和硬件测试，可以单独设置一个“夜间构建”任务，每天跑一次。

总结一下：硬件开发流程不是死板的条条框框，而是帮你少走弯路的指南。版本管理让每个改动都有迹可循。持续集成让重复的工作自动化。这三样东西，你越早用，越早受益。

好了，这一章就到这里。下一章我们聊聊硬件设计的具体工具和技巧。有什么问题，欢迎交流。

← 上一章 📖 返回目录 下一章 →