企业官网建设流程全解析

2019年那会儿，智慧家庭这个概念在国内已经被讲了很多年，但真正落到产品端、能稳定量产交付的方案其实并不多。我们团队当时基于TI平台做消费电子智慧家庭项目，第一篇文章整理了方案选型和芯片层面的整体框架，这一篇则把第二阶段开发过程中真正踩过的坑、验证过的数据、反复纠结过的取舍记录下来。如果你正准备用TI的芯片组去做智能家居类产品，或者正在无线选型和低功耗设计之间来回摇摆，这篇东西应该能帮你少走不少弯路。

1. 第二阶段开发的方向纠偏：从Demo能跑到产品能交付

1.1 第一阶段的复盘：我们被“芯片能力强”带偏了

第一阶段做样机的时候，我们其实犯了一个很典型的错误——过于以芯片为中心来组织整个项目。TI在智慧家庭领域的料确实很齐全：主控有MSP430和Cortex-M系列的MCU，更高阶的还有AM335x这类MPU，无线端有Zigbee、Sub-1GHz、低功耗蓝牙三条线，传感器接口、电源管理、音频放大也都能找到对应器件。结果就是我们像逛超市一样，什么芯片都想塞进方案里，样机上集成的功能点比实际需求多了一倍。

到了第二阶段，产品定义被明确以后，砍功能变成了一件非常痛苦的事。但回头来看，这个砍的过程恰恰是项目走向交付的关键。举个例子，我们最初在网关里加了一块不大不小的FPGA用于本地图像处理，理由是TI的某些处理器在AI加速上有短板，想通过FPGA补位。但实际跑下来，算法效果没有达到预期，功耗和BOM成本却涨了明显一块。最后我们把图像识别的部分全部放到云端，本地只做帧提取和上传，网关主控用一颗性价比更合适的工业级MPU就撑住了。

这里想说的核心思路是：做消费电子智慧家庭产品，功能规划必须从用户场景和使用频次出发，而不是从芯片的Datasheet出发。芯片能力再强，如果对应的功能不是用户的刚需、或者不能在成本和功耗的约束内落地，本质上就是负资产。

1.2 从使用场景反推出来的真实需求优先级

第二阶段我们换了一种方法，拉着产品、市场、研发一起把整个家庭环境里的使用场景从头到尾过了一遍。列出来的高频场景其实非常朴素：人进门灯亮、离家全屋关电、温湿度异常提醒、老人跌倒或长时间未活动告警、语音或App远程查看状态。至于那些听起来很酷炫的影音联动、设备自学习、全屋灯光秀，在一次实际问卷里的优先级排名并不高。

场景反推之后，功能模块的优先级排序变得非常明确：基础传感（人体红外、门磁、温湿度）是第一梯队，本地联动规则引擎是第二梯队，远程App和云服务是第三梯队，视觉类高级功能放到最后。这也直接影响了我们后面的硬件资源分配和协议选择——传感类节点数量会很大，它们必须便宜、省电、稳定；网关负责规则引擎和协议转换，需要计算能力但不能夸张。这套优先级贯穿了第二阶段所有技术决策，后面聊到的无线选型、低功耗设计、传感器接入方式，本质上都是从这几个高频场景延伸出来的。

现在回头看，非技术出身的同事经常问“为什么一个简单的智能家居方案要用这么多芯片”，技术团队内部早期也经常陷入“堆料”的冲动。真实的原因不是芯片越多越好，而是不同节点的物理位置、供电条件、通信距离完全不同，分散式架构是最符合现实约束的做法。

2. 无线协议选型的最终取舍：Zigbee、Sub-1GHz和BLE的三方博弈

2.1 三大无线阵营在TI生态里的代表器件和真实表现

TI在智慧家庭无线领域的产品线覆盖了IEEE 802.15.4（Zigbee / Thread）、低功耗蓝牙和专有Sub-1GHz方案。我们前期评估过的芯片包括：CC2530/CC2538/CC2652（Zigbee）、CC2640/CC2642（BLE）、CC1310/CC1352（Sub-1GHz和双频），以及后来新出的CC1354P10这类更高集成度的料。这些芯片在TI官网上都有非常成熟的协议栈和例程，SimpleLink系列的统一SDK也让代码复用变得比较方便，这是选TI平台时很大的加分项。

不过芯片是一回事，实际组网表现又是另一回事。我们分别搭了三套小规模的测试环境，每套大约30个节点加1个协调器/网关：

• Zigbee 3.0：穿墙能力中等，2.4GHz频段在密集居住环境里受到Wi-Fi干扰的情况确实存在，但Mesh组网的回退路径让整体可靠性比较高。配对和入网流程成熟，调试工具齐全。
• Sub-1GHz（433MHz/868MHz频段）：穿墙能力明显强于2.4GHz，同样发射功率下覆盖距离远得多，但速率低，适合门磁、温湿度这类小数据量传感器，不适合频繁固件升级和大块数据传输。
• BLE：手机直连非常方便，配网体验好，但Mesh的转发延迟和消息洪泛控制在当时的产品约束下不够理想。

2.2 我们为什么最终放弃了BLE Mesh作为主干

有一段时间，BLE Mesh是团队内部呼声很高的方案，理由是手机生态好、用户不需要额外买网关。但真正做原型验证的时候，问题出来了：30个节点的网络里，从网络边缘节点发一条消息到中心节点，经过多跳转发，延迟从几百毫秒到几秒不等，而且这个延迟受路由拓扑影响很大，没办法保证确定性的联动体验。

智能家居里很多联动是强实时诉求的，比如门磁触发时灯光需要立刻亮起，或者安防告警必须在几百毫秒内推送。BLE Mesh在这类场景下显得有点勉强。再加上当时BLE Mesh在功耗优化上还没有像Zigbee那么成熟的休眠节点方案，电池供电设备很难做到长续航。所以我们最终把BLE的角色限定在近场配网和手机直连，主干网络交给了Zigbee，部分远距离穿墙困难的点位混入Sub-1GHz节点做补充。

这不是说BLE一无是处，而是说它的优势在“手机为中心的互操作”，不在“大量电池设备组成的确定性网络”。想清楚这一点，选型就不纠结了。

2.3 双频器件CC1352给我们带来的实际价值与代价

CC1352是我们整个系统里比较特殊的一颗料，它同时支持Sub-1GHz和2.4GHz两个频段。最开始选它是因为项目里有一部分户外传感器（庭院门磁、户外温湿度）和室内网关之间隔着好几堵墙，2.4GHz的Zigbee信号穿墙后余量不足，我们不想为了个别点位专门架中继，就试了Sub-1GHz远程链路。

实测下来，CC1352在868MHz频段、+14dBm发射功率下，空旷环境能跑几百米的通信距离，隔两三层楼板也能保持稳定连接，这个覆盖能力确实解决了我们边缘节点的通信问题。代价也很实在：双频器件的物料成本比单频Zigbee芯片高一截，天线匹配要同时照顾两个频段，板级调试的工作量上去了。而且当时双频同时工作时的射频互扰问题需要仔细处理收发时序，我们最后是分时复用两个协议栈才把稳定性提上来。

如果再来一次，我的选择依然会是Zigbee为主干、Sub-1GHz做远距离补充的组合，但在协议架构上会更加提前考虑两个频段之间的主从关系，而不是在项目中期再做切换设计。

3. 低功耗设计的逆推法：从电池寿命倒推每一毫安的去向

3.1 先定续航目标，再谈电路设计

低功耗设计最常见的错误，是一上来就翻芯片的sleep current指标，觉得数据漂亮就完事了。实际产品设计里，电池续航是由整个系统的能量预算决定的，节点每做一件事都会花钱：定时醒来采样、无线收发、应答网关的查询、偶尔的固件升级，每一笔都要算进账单里。

我们在第二阶段定的续航目标是：采用两节AA碱性电池的门磁/温湿度节点，在正常家庭使用频率下至少存活18个月。这个目标不是拍脑袋定的，而是产品团队做了用户调研之后发现，消费者对换电池这件事的耐心大约在一年半左右，低于这个数就会被频繁吐槽。

定下目标以后再倒推：电池可用容量（碱性电池实际放电效率要打折）、节点平均电流、每天的工作次数、每次工作的时长，全部变成约束条件。这套逆推法的好处是，等到画原理图和写固件的时候就非常清楚哪些电流是必须花的，哪些可以通过设计省掉。

3.2 一个典型Zigbee传感节点的电流预算计算示例

为了让你有直观感受，我把当时算的一个典型节点预算拿过来。节点每天的工作模式是：大部分时间处于睡眠状态，每10秒醒来一次读传感器并做简单判断，每变化上报一次，每天被动响应网关查询若干次，每周做一次父节点链路健康检查。

单次采样和判断的MCU工作时间假设为3ms，工作电流约5mA，这部分折算到平均电流就是0.015mA×（3ms占空比）之类的算法，实际上我们用的是更细颗粒度的积分法：把一天内所有的电流事件（睡眠电流、唤醒时间、采样电流、发送电流、接收窗口电流）按时长加权平均。算出来一个合格节点的全年平均电流在20μA到40μA之间，对应两节AA电池（等效容量约2000mAh到2500mAh，还要折扣碱电池在低速率放电下的容量保持率）就能达到上述18个月的目标。

分享一个当时比较关键的经验：不要把Zigbee协议栈的电流消耗当成固定值，它跟你网络拓扑、父节点轮询间隔、重传策略强相关。我们实际测试时，如果父节点功率不稳导致频繁重传，整机平均电流能直接翻倍。所以低功耗不只是节点自己的事，是整个网络健康度的事。

3.3 实际掉电数字：那些被忽略的“隐藏耗电大户”

预算做得再漂亮，上真机以后还是会发现几个隐藏耗电大户。我们遇到了两个，印象非常深刻。

第一个是传感器上电瞬间的浪涌电流。某些温湿度传感器在开始的毫秒级时间里瞬间电流很大，如果电源设计没能处理好，节点每次采样都会额外消耗一笔电量。解决办法是给传感器供电加软启动开关，或者让MCU先稳定电源，再等几十毫秒让传感器进入稳定状态再读数据。

第二个是无线接收窗口的持续监听。Zigbee休眠节点为了能收到来自父节点的消息，需要定期打开接收窗口，如果这个窗口开得太宽、频率太高，节点平均电流会被快速拉高。我们最后是用TI协议栈里的休眠管理模式，精确控制RX窗口时长，配合端到端的确认机制，才把这块电流压下来。

另外还要提醒一下，电池本身有自放电率，碱性电池在高温高湿环境下的自放电会更严重。做寿命计算时留出15%到20%的余量比较稳妥，不然到用户手上很可能出现提前低压告警。

4. CCS开发环境与工程落地：从官网下载到量产烧录的完整链路

4.1 TI官网CCS版本选择与仿真器匹配的注意事项

TI的开发环境Code Composer Studio（CCS）是绕不开的一环，尤其是当你不满足于复制官方例程、想真正裁剪协议栈和调试底层问题的时候。CCS可以在TI官网直接下载，但有个容易踩坑的点：不同芯片、不同协议栈版本对CCS版本有隐性的兼容要求。我们项目里的无线节点用的是CC2530和CC2652，这两代芯片恰好横跨了CCS的多个大版本，如果直接装最新版CCS去打开老工程的例程，编译报错和链接错误会让人崩溃。

我们的做法是：在TI官网上根据芯片型号找到对应的SDK下载页面，页面里通常标注了验证过的CCS推荐版本和编译器版本，严格按照这个组合来装环境。比如当年的CC2530老工程需要IAR较多，而CC2652走SimpleLink SDK则更推荐CCS加TI Clang编译器。把编译器版本锁定以后，工程迁移的报错率明显下降。

仿真器方面，我们用的是XDS110系列，通过TI官网下载对应的调试驱动。这个环节比较容易被低估，但实际项目中是最常见的卡点——驱动版本不对会导致仿真器连不上芯片，有时候换了电脑也识别不了。我的建议是：把所有开发电脑统一安装同一个版本的XDS驱动，并将驱动包归档到团队共享目录，避免不同同事之间的环境差异造成调试定位时间浪费。

4.2 从官方例程出发，搭建属于自己的工程骨架

TI的官方例程质量很高，里面的外设初始化、协议栈回调、低功耗状态机基本都能跑。但直接拿例程当产品代码用是不现实的，因为例程里有很多演示逻辑，比如按键切换、OLED屏打印、串口日志，这些都会额外吃资源，而且在产品形态里毫无意义。

我们从官方例程搭建自研工程骨架的过程，可以归纳为三步：

1. 裁剪例程：把演示外设的驱动和测试任务全部删掉，保留协议栈初始化和最基本的无线收发回调，让工程能在一个干净的框架里编译通过。
2. 抽象硬件层：将LED控制、按键、串口等例程相关的函数，替换成自己的硬件抽象层接口。比如定义了app_sensor_read()、app_sensor_sleep()这样的函数，底层具体是用I2C还是单总线，对业务逻辑不可见。
3. 固化低功耗框架：把TI官方的电源管理接口封装成app_enter_sleep()和app_wakeup()两个函数，所有任务都通过事件触发而不是轮询，这样既方便后期优化功耗，也避免代码结构变成一锅粥。

工程骨架稳定下来以后，最重要的一个原则是：协议栈版本一旦跑通，就不再轻易升级。TI的SDK常年更新，每次升级都伴随API变更、配置项变化，对量产项目来说升级的动力远小于风险。我们当时的无线模块固件，整个第二阶段始终保持在一个已验证的SDK版本上，只做增量修改，这是一个保护项目稳定性的实用策略。

4.3 烧录与调试中的实际问题：芯片锁死、连接失败和批量烧录

开发过程中我们遇到过几个比较棘手的问题，这里分享具体的排查路径。

一个是芯片被锁死。表现是仿真器无法连接芯片，或者连接以后报出特定错误码。这种现象经常发生在反复烧录、调试器在芯片擦写过程中意外断开的情况下。解决方法是通过TI官方工具链中针对该芯片的强制恢复功能，让芯片重新进入可擦除状态。需要注意的是，恢复操作会清掉Flash里的内容，如果是量产阶段出这个问题就比较麻烦，所以量产烧录必须用稳定的工装夹具，减少人工插拔带来的接触不良。

另一个是电脑系统更新之后仿真器突然识别不到。大多数情况下是驱动被系统重置了，重新安装TI官网的XDS驱动即可。这里有一个自己的习惯：优先使用随CCS安装包一起提供的驱动，而不是单独下载的通用串口驱动，两者的匹配度不一样，我用后者踩过一次坑。

批量烧录方面，小批量阶段用XDS110加排针手工烧录还能忍受，到了几千片量级必须引入离线烧录器或者产线上的批量烧录工装。TI的很多芯片支持通过专用的烧录工具直接写入固件和配置信息，不需要为每片板子连接仿真器。这部分投入不要省，手工烧录在批量阶段出错率极高，而且很难追溯。

5. 传感器接入与数据质量：真实世界里的数据没那么干净

5.1 数字接口选择：I2C、SPI还是单总线

智慧家庭节点上最常见的传感器包括温湿度（SHT系列、HDC系列）、人体红外（PIR）、光照（环境光传感器）、门磁（干簧管或霍尔传感器），以及部分气体传感器。接口上，I2C是最普遍的选择，优点在于引脚少、多设备可以挂一条总线；SPI吞吐量更高，适合数据量较大的MEMS传感器；单总线则更加节省IO，但时序要求比较敏感，端口配置稍有不慎就容易出现偶发读失败。

我们在设计时是混合使用的：温湿度和光照走I2C，门磁和PIR走GPIO中断，网关上的气流传感器用SPI。这里想深入展开一个原则：传感器接入第一步不是看芯片规格书支持什么接口，而是看这个传感器的唤醒时间和稳定时间能不能满足低功耗时序的要求。很多数字传感器上电之后需要几十毫秒甚至更长时间才能输出稳定数据，如果MCU醒来后立刻读，很可能拿到的是上一次残留数据或无效数据。这也是很多新手做出来节点读数飘忽的根本原因。

5.2 温湿度、人体红外和光照传感器的实测数据坑

我们曾经在一个批次的温湿度节点上发现，同样型号的传感器，装到不同的外壳里，湿度读数偏差能到10%RH以上。后来排查清楚了：问题出在传感器开窗位置和外壳内部空气流动上。如果传感器周围形成局部死区，或者紧挨着电路板上的发热器件，测出来的湿度就会明显偏大。解决方法是传感器不要在板上直接正对发热源，留出通风孔，并且做一颗传感器的校准补偿。

人体红外传感器（PIR）的坑更多集中在误报和漏报。PIR本身只能检测红外变化，对静止人体无能为力，这是物理原理决定的，不是选型问题。我们在实际测试中发现，安装在空调出风口附近的PIR会出现频繁误触发，因为气流温度变化被传感器当成人体活动。处理方式是在固件里加两次确认的判定机制，第一次触发后等几百毫秒再确认一次，同时结合门磁的状态做联合判断，误报率明显下降。

光照传感器看起来简单，但实际安装时的遮光结构会直接影响量程。我们曾把光照传感器放在半透明外壳后面，发现衰减后的读数低到没有实用价值。后来验证了几种透光材料，选了一种对可见光透过率较高的方案，并对不同外壳衰减系数做了软件校正。

5.3 布线与电源噪声对传感器数据的影响

传感器数据漂移，有时候不是传感器本身的问题，而是板级电源和地处理不当。我们在一个阶段性的原型板上发现，网关读取温湿度时偶尔会出现异常跳变，用示波器抓了供电轨，发现传感器供电上有幅度非常大的纹波尖峰，来源是旁边的DC-DC开关节点和天线发射瞬间的电流突变。

从那以后，我们的传感器板级设计多了几条铁律：传感器供电从LDO输出取，不要直接并联在DC-DC输出上；传感器旁边放一个100nF和10μF的组合去耦电容；I2C和单总线走线尽量短，避免与射频走线平行；多个传感器共用I2C总线时，在总线上加适当的上拉电阻并测量波形，防止因为线缆电容过大导致时序不合格。这些看起来都是教科书里的基础内容，但项目一紧张就容易被忽略，而数据质量恰恰是被这些细节决定的。

给传感器数据做时间序列方面的后处理也很有价值。我们在固件里加入了中值滤波逻辑，连续三次采样取中间值，同时丢掉了明显超出正常量程的野值。这套逻辑非常简单，但让上报到后台的数据干净了很多，也减少了云端的异常数据告警量。

6. 回看这一阶段：六个提醒，给准备入局的人

基于这段TI消费电子智慧家庭项目第二阶段的经历，我把最想对后来者说的话整理成六条提醒，都是我实实在在交过学费才换来的认知。

第一，不要在芯片选型上追新。TI的产品迭代很快，但新的芯片、新的协议栈往往伴随着不成熟的驱动和社区资料。对于消费电子量产项目来说，选一颗市面上已经有两三年量产验证的经典芯片，远比选最新旗舰舒服。我们用老的CC2530做Zigbee网络，资料多到几乎每个问题都能搜到方案，反而成了项目最大的护城河。

第二，先验证功耗再画板子，而不是画完板子再调功耗。功耗设计要从节点定下来的第一天就开始计算和验证。我们在中期才做功耗优化，前面几版硬件因为器件选型和电路拓扑的原因，怎么调固件也降不到目标电流，最后只能改版，白白浪费了时间。

第三，无线调试要预留足够的环境。一堵墙和一栋楼的区别非常巨大，不要指望办公室的无线测试环境能代表真实家庭环境。我们在各个阶段都用过不同方法，包括把节点放到实墙环境的测试点里做长期运行测试，虽然麻烦，但暴露了很多实验室里看不出来的问题。

第四，协议栈版本一旦跑通，立刻冻结。开发一开始就要把这个规则立起来，避免团队里有人出于好奇去升级SDK导致连锁问题。冻结协议栈不代表不维护，而是所有变更都经过明确的变更管理流程。

第五，把联动规则引擎放在网关本地。云不可用的时候，本地联动仍然要能工作，这是一个智慧家庭系统的基本尊严。我们在第二阶段的一个关键改动，就是把联动规则的解析和执行全部下沉到网关边缘计算模块里，云端只做配置下发和数据展示。事实证明这个选择非常正确，掉线和弱网场景下的体验好了很多。

第六，天线和结构设计要提前介入。无线设备的射频性能不是芯片一颗料决定的，天线匹配、外壳材质、五金件的位置都会影响信号。我们曾经在某款外壳里发现，节点穿墙能力大幅下降，最后查到是外壳内部的金属支架正好靠着天线净空区。这类问题如果等到结构开模之后再改，成本非常惊人。

写在最后：一点真实的个人感想

做这类智慧家庭项目，很多时候感觉不是在做芯片开发，而是在做各种工程问题的优先级排序。TI平台本身足够成熟，官方SDK和文档也很全面，真正拉开项目差距的，往往是对真实场景的理解深度、对成本和功耗的敬畏，以及团队在遇到脏活累活时愿不愿意去深究。我到现在还记得，为了搞定一个节点在低温环境下的重启问题，我们蹲在冰箱旁边反复插拔测试设备，最后发现只是电源管理配置里一个定时器源的选择不当。这类问题不会出现在任何官方文档里，它只存在于你愿不愿意把系统当成一个整体去理解和拆解。

这套平台的思维方式和工程方法，放到今天依然适用。选择一套成熟方案，吃透它的边界，然后在边界之内做出自己的优化，这可能比追逐每一代新芯片更有价值。