2014年前后我第一次拿到Hexoskin智能衬衫的拆解报告时，最让我意外的是：整件衣服的“大脑”居然是一颗来自Cypress（赛普拉斯）的EZ-BLE PRoC系列模块。那会儿绝大多数可穿戴设备还在用经典蓝牙传数据，手机配对慢、功耗高，而Hexoskin已经把实时ECG、心率、呼吸率这些医疗级生物特征数据，全部压进了一颗基于ARM Cortex-M0核心的BLE SoC里。这正是今天这篇文章想拆开讲的东西——一件织物电极遍布全身的智能衬衫，是如何通过Cypress EZ-BLE PRoC模块把生理信号稳定地送到手机App的。
这篇内容适合三类人：一是正在做智能服装、医疗可穿戴硬件选型的工程师，想搞清楚BLE模块在织物环境里会遇到哪些坑；二是做嵌入式BLE开发、想了解GATT服务如何承载多路生理数据流的朋友；三是对Hexoskin这类产品好奇、想知道“一件衣服为什么能测心电图”的产品经理或爱好者。我会从硬件选型、信号链路、固件协议、实测坑点四个层面展开，全程按实际项目推进的逻辑来讲，能直接抄作业的地方尽量直接给参数和代码。
1. 从一件智能衬衫说起：Hexoskin到底在解决什么问题
1.1 医疗级生物特征监测的硬件门槛
Hexoskin的定位不是普通的运动手环，而是医疗级别的贴身穿戴设备。它同时采集单导联ECG（心电图）、心率、心率变异性（HRV）、呼吸率、呼吸量、步数、睡眠分期等多项参数。注意，ECG和光学心率是完全不同的东西——手环上的绿光PPG传感器测的是血液容积变化，而Hexoskin用的是真正贴在胸口的织物电极放大心电信号，这就意味着模拟前端的噪声要求、增益设计、抗干扰能力完全不是一个量级。
医疗级ECG放大链路的输入噪声通常要在微伏级别才能看清P波和QRS波群。织物电极和皮肤之间的接触阻抗远高于传统凝胶电极，动不动就是几十千欧到几百千欧，而且还会随着身体动作大幅波动。这样一来，放大器的输入阻抗必须做到GΩ级别，偏置电流要足够小，否则肌电噪声和运动伪影会把心电图彻底淹没。更麻烦的是，衬衫是要水洗的，织物电极经过几十次洗涤之后，电极和导线之间的连接可靠性也会下降。这些物理层面的约束，决定了Hexoskin的硬件团队从一开始就必须把“模拟前端性能”和“数字处理能力”放在同一个很小的PCB面积里考虑。
我当时在国内跟做智能服装的团队聊天时，很多人第一版方案都会用“MCU+独立BLE射频芯片+外置运放”的组合，结果做出来的原型体积大、功耗高，放在贴身衣物里既不舒适又容易掉线。这里面的核心问题不在于单个芯片选得好不好，而在于系统级的集成度——如果你有多个传感器通道的数据要同步采集、压缩、无线传输，那么主控和无线之间如果隔着一层SPI/UART接口，无论是同步时序还是功耗优化都很难做到极致。Hexoskin直接选择带BLE收发器的PRoC模块，让ECG前端和蓝牙协议栈跑在同一个芯片里，本质上就是为了解决这个系统集成度的问题。
1.2 为什么要用BLE而不是Wi-Fi或传统蓝牙
对可穿戴设备来说，无线协议的选择几乎决定了产品的功耗天花板。经典蓝牙（BR/EDR）建立连接后的射频功耗通常维持在几十毫瓦级别，而且连接建立时间长达数秒；Wi-Fi的功耗更高，还要考虑天线面积和协议栈复杂度，在一块只有拇指盖大小的模块上根本不现实；Zigbee虽然低功耗，但手机生态不支持，用户不可能为了穿一件衬衫再买一个专用网关。BLE能成为唯一合理选项，核心原因是它把“连接”变成了“按需唤醒”：平时射频完全关闭，只有设定的连接间隔窗口才打开一瞬间做数据收发，其余时间系统可以继续睡。
给Hexoskin这样的设备做功耗预算时，你会发现连续ECG采样本身并不是大头。一个16位ADC、250Hz采样率、三通道同时采集，满打满算也就是几千比特每秒的数据量，功耗大概在几百微安到几毫安之间。真正吃掉电池的是无线传输的射频开销，以及为了维持连接而必须周期性唤醒的协议栈。BLE的连接间隔（connection interval）可以从7.5毫秒到4秒之间配置，每次连接事件只会开启一小段时间的收发窗口，因此可以把平均射频电流压到几十微安甚至更低。这也是为什么Hexoskin能靠一颗容量不大的聚合物锂电池坚持数天——不是因为它省电省在传感器上，而是省在了无线链路的调度策略上。
另外，BLE在手机端的生态成熟度也是一个决定因素。iOS从iPhone 4S开始就原生支持BLE 4.0，Android从4.3（API 18）开始提供标准BLE API，这意味着用户不需要任何额外适配器，直接用手机App就能连上衬衫里的模块。相比Classic Bluetooth需要配对弹窗、配对后还要处理SPP之类的串口抽象，BLE的GATT模型天然适合传感器数据流这种“多通道、低速率、结构化”的场景。EZ-BLE协议栈里封装好了完整的GATT服务，负责产品的人只需要关注业务数据流，不用去纠结底层射频和链路层怎么组织，这大大缩短了产品从原型到交付的周期。
2. Cypress EZ-BLE PRoC模块：选它而不是nRF52832的理由
2.1 EZ-BLE PRoC的硬件规格和BLE协议栈
EZ-BLE PRoC是Cypress把自家PRoC BLE（Programmable Radio-on-Chip）系列的SoC封装成模块的产品线，典型代表是CYBLE-214009和CYBLE-013025这样的型号。模块内部通常已经集成了32-bit ARM Cortex-M0内核（工作频率48MHz）、BLE 4.2射频收发器、32.768kHz的RTC晶振、32MHz的系统晶振、天线、以及保证天线阻抗匹配的balun电路。换句话说，一颗模块就是一颗完整的BLE节点，外部只需要提供供电和传感器接口，不用再去设计射频匹配网络，也就绕开了整个硬件设计里最难验证的射频部分。
协议栈方面，Cypress（现在属于英飞凌）提供了一套完整且经过认证的BLE协议栈，支持GAP（通用访问协议）、GATT（通用属性协议）、L2CAP、SM（安全管理）等所有标准层次。对Hexoskin而言，最实用的是它支持自定义GATT服务，并且允许开发者在Cypress的BLE组件里通过工具配置特征值、通知属性、安全模式和连接参数。这套开发环境虽然谈不上漂亮，但在当时算是很稳定的。我记得Cypress的BLE协议栈有一个特点：它把GATT数据库以“表”的形式维护，用特征值句柄作为“索引”来定位读写操作。听起来有点绕，但在实际调试时，你是可以通过这个表索引快速找到某个特征值对应的处理函数入口的——这比一些其他厂商黑盒的协议栈要透明得多。
这里顺便提一下我在项目中去翻数据手册时经常用到的“索引表”思维：当一个GATT服务里有好几个特征值（比如ECG数据、呼吸数据、设备状态、电池电量）时，固件里最忌讳的就是写一串if-else分支来逐个判断UUID。更稳妥的做法是维护一张服务定义表（table），把UUID、句柄、数据处理函数指针、通知开关状态全部做成结构体数组，再用UUID或者句柄做索引（index）直接查表调用。这种“proc（过程处理）通过索引查表”的写法不仅代码量小，而且后续要新增特征值，只需要往表里加一行，不容易漏。
2.2 与主流BLE方案的对比
我在选型时把当时的几条主流BLE路线放在一起比过，简单列个表：
| 方案 | 内核 | 协议栈成熟度 | 模块化支持 | 备注 |
|---|---|---|---|---|
| Cypress EZ-BLE PRoC（CYBLE系列） | Cortex-M0 | 高，Cypress官方 | 好，自带天线 | 集成度高，低功耗均衡 |
| Nordic nRF52832 | Cortex-M4F | 极高，SoftDevice | 一般，需自研射频 | 性能强，资料多，当年很多高端产品用 |
| TI CC254x | 8051 | 高 | 有Module版 | 经典，但生态相对老旧 |
| Dialog DA14580 | Cortex-M0 | 中 | 有Module版 | 功耗极低但Flash小 |
Hexoskin选择Cypress而不是当年呼声更高的Nordic，我猜测有几层原因。首先是模块化程度：EZ-BLE PRoC直接以模块形式供货，天线、晶振、匹配网络全集成，通过了FCC/IC/CE等射频认证，这对一个服装公司来说是非常重要的——毕竟团队的核心能力在纺织和生理信号处理，不在天线调试上。其次是低功耗表现：PRoC BLE在深度睡眠模式下电流可以到1微安级别，而实际ECG连续传输场景下的平均电流也能控制在几毫安以内，足够支撑数天的贴身佩戴。第三是供货和品控：作为老牌半导体厂商，Cypress的生命周期管理和可靠性测试做得比较扎实，对医疗穿戴这种长周期产品来说，这一点比纸面性能更重要。
如果你今天重新做这个项目，我当然会建议你把nRF52832甚至nRF52840也放进待选清单——它们的处理能力、Flash大小、社区生态在近几年已经追上来了。但如果你的团队缺乏射频经验，产品的核心价值在传感器算法而非复杂的本地计算，那么“带完整天线的认证模块”依然是我给你的首选推荐。与其花三个月调天线，不如把时间花在呼吸算法和ECG滤波上，这才是Hexoskin这类产品的护城河。
2.3 天线设计与射频布线的实际考量
聊完选型就得落地画板。EZ-BLE PRoC的模块封装设计得比较好，把天线做成了PCB板载天线，周围有一圈必须留空的禁布区（keep-out area）。这个禁布区在高频下是大事，因为天线近场区域的金属、地平面、甚至高介电常数的材质都会改变天线的谐振频率和辐射效率。我第一次画板的时候偷懒，把电池的金属外壳贴着天线放，结果同一块板子在桌上测试RSSI是-45dBm，贴到胸口直接变成-75dBm，连接时不时就断。
智能服装的挑战比普通手环更特殊：天线周围是织物、人体和金属纽扣，没有一个固定的环境。同样一块模块，塞进棉质T恤和尼龙运动服里面，介电常数不一样，天线失谐程度也不一样。我当时看到Hexoskin的拆解图，他们把天线区域刻意安排在了胸口偏上的位置，周围尽量避开导电纱线和金属件，而且模块底下的地平面做了比较完整的铺铜，最大程度上减少了人体对天线的吸收。你可以理解为，天线在人体附近本质上是在一个高损耗介质旁边工作，能做的不是消除损耗，而是让失谐后的驻波比尽可能平缓，保证在几种典型穿着状态下都能保持可用灵敏度。
3. 织物电极与BLE模块的硬件集成：从传感器到天线的信号链路
3.1 ECG/呼吸传感器的信号调理
Hexoskin的信号采集链路可以拆成三段：织物电极和呼吸传感器——模拟前端——数字处理与BLE模块。ECG部分通常使用三电极或者多电极布局，信号进入芯片后先经过仪表放大器做第一级差分放大，再接一个高通的二阶滤波去除基线漂移，然后经过主放大和低通滤波，最后进入ADC采样。这里面仪表放大器的共模抑制比（CMRR）至少要做到90dB以上，否则工频干扰会从织物电极的不平衡阻抗里漏进来，直接把心电信号盖掉。
呼吸信号的采集是Hexoskin区别于大多数手环的地方。它用的不是简单的加速度计推算呼吸，而是测量胸廓的膨胀变化，常见方案有压阻式传感器带或者电感式体积描记（RIP）。RIP的原理是往织物里的线圈通一个高频小电流，胸廓变化会改变线圈的电感，进而改变振荡频率，通过频率检测就能还原呼吸波形。这条链路的信号频率很低（0.1-0.5Hz），但幅度会受到运动伪影的调制，所以模拟前端里要针对呼吸频段做一个窄带通滤波，把高频肌电和运动冲击滤掉。
值得强调的是，这些模拟前端电路在PCB上的布局很讲究。心率和呼吸信号都是毫伏甚至微伏级别的弱信号，如果数字部分的高频开关信号（比如BLE射频在2.4GHz的突发发送）通过地平面耦合进来，哪怕只有几微伏，也足以让ECG波形出现肉眼可见的毛刺。所以我通常建议把模拟前端和数字部分用星型接地或单点接地隔开，ADC采样时序也尽量避开BLE的射频发送窗口——实际做的时候可以给射频发送加一个中断标志，在发送期间暂停ADC采样或者丢弃该窗口的样本，这个细节能大幅减少数据里的周期性噪声。
3.2 模块供电与电池管理
Hexoskin这件衬衫的电池不可能做得太大，贴身穿的东西如果胸口鼓出一块电池，别说用户了，连我都不会愿意长期戴。所以整个系统的功耗预算是“挤”出来的。PRoC模块的宽电压输入（通常是1.71V-5.5V，具体要看型号）让供电设计简洁了不少，可以直接用一颗锂聚合物电池加低压差稳压器（LDO）供给模拟前端、数字部分和BLE射频部分。
电池管理上有个容易被忽略的点：ECG模拟前端和BLE射频的瞬态电流需求完全不同。BLE在发送数据的瞬间会从电源吸取十几毫安的脉冲电流，如果LDO的动态响应不够快，电源电压会瞬间跌落，反映到ECG信号上就是一个低频的毛刺。我在项目里通常会给模拟前端的电源加一个低噪声LDO，并用LC滤波器把数字电源和模拟电源隔离；同时在BLE模块的电源引脚附近放一颗大容量的储能电容（10μF级别），专门负责给射频突发供电，这样就能把电源跌落控制在一个可以接受的范围。
另一个细节是电池电压监测。BLE的GATT服务里通常会放一个电池电量特征值，但如果没有进行过校准，这个值的实际意义很有限。我的做法是在固件里用ADC周期性采样电池电压，然后根据锂聚合物电池的放电曲线，做成一个分段线性的映射表（又是查表），把电压映射到百分比。这里的“表”要经过实际充放电曲线测量才能填好，不能直接抄参考设计——不同容量、不同内阻的电池，空载和负载下的电压差异很大。
3.3 屏蔽和抗运动伪影处理
智能服装最难搞的不是硬件性能，而是动态场景下的可靠性。人在走路、跑步、翻身时，织物和皮肤的接触状态会不断改变，电极与皮肤的接触阻抗会出现低频大幅波动，这个波动经过放大器之后就是所谓的运动伪影。处理运动伪影有几个层次：第一是结构上保证电极始终贴合，Hexoskin采用的是把电极编织进贴身面料里，利用衣服的弹性提供持续的接触压力；第二是模拟前端设计上加入自适应基线恢复电路，通过积分反馈把直流偏置拉回到放大器的线性范围；第三是在数字域做自适应滤波，用加速度计信号作为参考来消除运动相关的噪声。
射频链路上的屏蔽同样重要。织物本身对2.4GHz信号有一定的吸收，如果导线走线离天线太近，信号会被带着走，导致辐射方向图畸变。我在同类项目里的经验是：所有传感器导线尽量做成差分对，并且在天线禁布区之外另走一路；如果结构允许，用一片金属化织物做一个局部屏蔽罩，把模拟前端和数字部分隔开。Hexoskin的链路正是在这几个层面做了大量隐性优化，才保证了用户从静坐到冲刺跑都能有连续可读的波形。
4. 固件与数据链路：如何用EZ-BLE把生理数据可靠地送到手机
4.1 GATT服务设计与自定义Profile
硬件链路搞定了，接下来就是固件。Hexoskin集成了多个传感器通道，如果用默认的Generic Attribute服务去传数据，肯定不行。你需要自定义一个或多个GATT Service，每个Service下面挂若干Characteristic，分别承载ECG波形、呼吸波形、HRV指标、设备状态、控制命令和电池信息。
设计自定义Profile时，我强烈建议把数据结构做成查表驱动。具体来说，在固件里定义一个特征值描述符数组，每项包含UUID、值长度、读/写/通知权限、回调函数指针。当BLE协议栈收到来自手机的读取或写入请求时，它首先根据句柄算出一个索引值，然后拿这个索引去查找这个数组，直接调用对应的处理函数。这种“index for table proc”的设计，在有多路数据流的设备上可以避免在协议栈回调里写一大坨switch-case，也让后续新增功能变得非常清晰。
一个典型的自定义GATT服务结构大概是这样的：
| Characteristic | UUID | 属性 | 数据格式 |
|---|---|---|---|
| ECG波形 | 自定义UUID-1 | 通知 | 16-bit采样值，250Hz |
| 呼吸波形 | 自定义UUID-2 | 通知 | 16-bit采样值，100Hz |
| HRV/心率 | 自定义UUID-3 | 通知 | HR、RR间隔等 |
| 控制命令 | 自定义UUID-4 | 写 | 开始/停止/采样率配置 |
| 电池状态 | 自定义UUID-5 | 读/通知 | 电量百分比和电压 |
每个通知型特征值在BLE协议栈里其实是一个环形缓冲区的“消费者”。数据采集线程（比如ADC中断里）往缓冲区写入样本，而BLE协议栈在每次连接事件到来时，从缓冲区里取一部分数据组成ATT通知包发给手机。如果你开启多个通知特征值，要注意同一连接间隔内多个特征值的通知包不能超过链路层允许的最大包数量，否则后面的包会被推迟到下一个连接事件，带来额外的延迟。
4.2 数据打包与传输策略
生理数据是连续流式的，你不能像传文件那样一帧一帧地丢。ECG 250Hz、每样本16位，意味着每秒要传500字节；呼吸波形100Hz、16位，每秒200字节；再加上HRV和状态信息，总数据量大概在每秒1KB上下。这个速率对BLE来说并不高，BLE 4.2的单连接最大可用吞吐量在几十KB/s，瓶颈通常在Packet间隔和MTU大小上。
如果用默认的MTU（23字节），一个数据包最多只能带20字节的应用数据，每秒1KB需要拆成50多个包，连接间隔稍微调大一点就会导致队列积压。更合理的做法是在连接完成后协商更大的MTU，比如把MTU提升到247字节，一次通知就能携带200多字节的样本数据，大幅降低包的数量和中断频率。协商MTU的代码很简单，就是发起一个MTU Exchange请求，但很多开发者容易忘记在手机端也要把MTU配置上调，导致协商失败后一直用默认值跑，吞吐和功耗都不理想。
数据帧格式方面，我给每个传感器通道设计了统一的帧头：帧起始标记、通道ID、序列号、数据长度、数据体、CRC16校验。序列号除了用来检测丢包，还能让手机端把多路信号在时间轴上对齐——ECG和呼吸波形的采样时间戳不同，如果不带序列号，后期做HRV等分析时就很难对齐采样点。CRC16在BLE里面看起来有点多余，因为链路层本身有重传机制，但实测下来，当手机处理不及时或后台被系统挂起时，BLE的链路层重传并不能保证应用层数据的顺序完整性，多一层CRC做最终校验还是值得的。
4.3 功耗调优：连接间隔与吞吐量的平衡
接下来是BLE开发里最需要耐心调的一步：连接参数。连接间隔（connection interval）决定了设备多久醒来一次和手机交换数据；从机和主机的每次连接事件中，又可以配置每个事件的包数量（slave latency）和超时时间。
原理上很简单：连接间隔越小，数据延迟越低，但收发窗口越频繁，平均功耗越高；连接间隔越大，功耗越低，但Buffer要做得更大，否则数据会溢出。对Hexoskin这种连续数据流，我的起始配置是连接间隔30-40毫秒，从机延迟0，超时3秒——这个组合能在功耗和延迟之间取得相对均衡，实测ECG数据端到端延迟在100毫秒以内，平均射频电流在2-3mA左右。如果只是想传心率这类低频数据，可以把连接间隔拉到100毫秒以上，再用Notification批量发送，功耗还能降一个量级。
计算吞吐量时我一般用这个简单公式：有效吞吐 = (连接间隔内可用的包数 × 每个包的负载字节数) / 连接间隔。假设MTU协商到247，连接事件里最多能发6个包，每个包有效负载244字节（247-3的ATT头），连接间隔40毫秒，那理论吞吐大概是 6 × 244 / 0.04 = 36.6KB/s，远高于我们的实际需求。这也是为什么我不建议为了速度盲目把连接间隔调到7.5毫秒——那会把功耗推高好几倍，而你的数据量根本不需要那么高的速率。
5. 实测中踩过的坑：射频干扰、掉线和数据完整性问题
5.1 天线净空区被织物覆盖导致的信号衰减
我前面提过一次天线禁布区的问题，但这里还是想单独拿出来讲，因为这是智能服装项目里回报率最高的一次踩坑。原型阶段用的模块是直接焊在PCB上的，天线朝外，测试时拿在手里信号挺好；但把整个PCBA塞进衬衫内侧的收纳袋后，RSSI直线下降，手机离开1米就开始断连。排查了几天，最后发现不是软件问题，而是收纳袋的面料正好覆盖在天线区域，而且那片面料为了屏蔽静电还织入了导电纱线——天线等于被一个损耗很大的罩子罩住了。
解决办法有两个方向：一是调整PCBA在衣服里的摆放方向，让天线尽可能贴近外层衣物且远离导电纱线；二是选用外置天线版本的模块，通过一根短的同轴线把天线引导到领口或袖口的位置。Hexoskin的实际产品里，模块并没有放在正胸口，而是放在了左侧肋下靠近腋下偏后一点的位置，这个位置皮肤接触好、但离手机口袋（通常在前侧或裤兜）不算远，同时避开了正面导电区域。如果你的产品结构允许，尽量在天线附近不要放置任何金属纽扣、拉链头或者RFID标签，这些都是隐形的信号黑洞。
5.2 连接不稳定与重连机制
老实说，BLE在贴身穿着场景下的稳定性比实验室里差很多。实测中最常见的问题是：手机锁屏进入后台后，系统可能暂停BLE回调，或者触发链路层超时断开；衣服在洗涤、折叠后，天线参数变化，早期掉线率明显上升。一款智能衬衫要成为可靠产品，重连机制比首次连接体验更关键。
我在固件里做的处理是：把连接状态机设计成“长连接优先、快速重连兜底”的双模式。正常情况下保持长连接，但App端加入一个后台保活机制，定期发一个空包检测链路。一旦检测到断连，模块立即进入低功耗广播模式，广播间隔设为100-200毫秒，同时缩短广播超时时间，避免浪费电；App端则做后台扫描和自动重连，最大重连次数和时间窗口都做了限制。这套机制让实际掉线后的恢复时间控制在几秒内，用户体验上基本可以接受。
另外要注意的是，BLE协议栈里的“断开连接”有主动和被动之分。模块长时间没有收到主机的数据包，会触发超时断开（supervision timeout）。这个超时值的配置不能太短，我见过有人把超时设成500毫秒，结果手机锁屏稍微卡一下，模块就断连了。一般建议超时在3-6秒，给系统留足缓冲。
5.3 数据校验与断点续传
数据完整性是医疗级产品绕不开的话题。BLE链路层的重传能保证单个包的可靠性，但无法保证应用层的连续性和顺序性。我在多轮测试中发现，当手机App被切到后台或者系统在做OTA时，BLE通知包的到达间隔会出现几十毫秒到几百毫秒的抖动，有的包还会被系统丢弃，ECG波形上出现肉眼可见的断点。
为了把丢数据的影响降到最低，我做了两层设计。第一层是业务层校验：每个数据帧都带序列号，手机端检测到序列号跳变时，通过一个控制特征值向模块发起补传请求，模块从本地环形缓冲区重新发送缺失的一段数据。这个缓冲区的容量不需要太大，以ECG的数据率算，缓存10秒钟的数据大约只要5KB，用模块内置的Flash或者一个外部SPI Flash很容易实现。第二层是业务层兜底：当缓冲区溢出时，优先保证ECG数据不丢，呼吸和步数等低频数据允许降级。这套优先级策略在很多医疗可穿戴项目里都适用，你不可能在所有异常场景下都保持全通道零丢失，那就必须明确哪一路数据是“生命线”。
6. 复盘与量产实话：选型原则、洗水测试和产线筛查
6.1 智能服装硬件选型的通用原则
做了几个类似的贴身穿戴项目后，我总结了一套选型原则，不一定全面，但足够避开大部分坑。
选型时先问自己三个问题：团队的射频经验有多少？产品的核心竞争力在算法还是硬件？传感器的数据量和实时性要求有多高？如果射频经验不足，直接选带认证的模块（比如EZ-BLE PRoC这类）；如果核心竞争力在算法，那么主控的Flash和算力要给够，而不是一味追求最低功耗；如果是多通道高频数据流，BLE协议栈对多连接（多个Central设备）的支持也要在选型阶段就确认清楚。
第二个原则是“模块先行，SoC后移”。原型阶段用模块快速验证，产品定型后再评估是否需要换成裸SoC以降低成本。Cypress的EZ-BLE PRoC从模块到SoC的迁移路径是相对平滑的，固件接口基本一致，这让我在项目后期有比较大的调整空间。如果你一开始就焊了一颗裸片，等到天线不达标、认证卡壳，再改结构的成本就高得多了。
第三个原则是要把功耗预算表和RF链路预算表做在前面。不是文档刷墙，而是真正把所有状态（广播、连接、深度睡眠、传感器采样、事件处理）的电流和时间占比列成表格，算出平均电流，再反推电池容量。我见过太多项目是在原型做完之后才发现电池续航只有6小时，那时候再优化功耗，牵一发而动全身。先做估算，后做验证，这是硬件项目里最省钱的工作方式。
6.2 从原型到小批量生产的关键差异
原型能跑通，不代表能批量生产。智能服装有几个在量产阶段才会暴露的问题，提前心里有数会少交很多学费。
第一个是织物洗涤的可靠性。原型机测试时不会有人真的把衬衫洗50次，但量产后的用户一定会洗。织物电极、导线和PCBA之间的连接点在反复洗涤后会出现接触电阻增大甚至断路，所以所有这些节点都要做机械加固，比如超声波焊接
