从 SoC 到整机：虎麟如何基于 Ambiq Apollo 构建低功耗 AI 穿戴设备
对于一款智能穿戴产品，SoC 选型通常不是比较哪颗芯片主频最高。实际项目里，我们更关心尺寸够不够、续航能不能达到目标、需要接多少 Sensor、有没有 Audio 或 Display、本地需要处理多少数据，以及哪些任务应该留在设备端完成。
Ambiq Apollo 是虎麟在低功耗智能穿戴项目中重点关注的平台之一。从 Apollo3、Apollo4，到 Apollo330 Plus 和 Apollo5，不同系列覆盖了从低功耗 Sensor / BLE，到 Display、Audio、Signal Processing 和 Edge AI 的不同能力区间。
但对虎麟来说，芯片规格只是开发起点。真正需要解决的是：如何把 SoC 的能力放进一台尺寸、电池和成本都受到约束的真实产品里。
01 低功耗 SoC，首先要放回整机功耗里计算
穿戴设备的电池通常只有几十到几百 mAh。假设一款设备使用 100 mAh 电池，7 天续航对应的理论平均电流约为 595 μA；如果目标提高到 14 天，平均预算进一步下降到约 298 μA。
100 mAh ÷ 168 h ≈ 595 μA；100 mAh ÷ 336 h ≈ 298 μA
这几百微安并不是只留给 SoC，还要同时覆盖 Sensor、BLE、Storage、PMIC、LED、Haptic 等外围器件。Ambiq 的低功耗平台可以提供一个更好的基础，但最终 Battery Life 仍然取决于整机的工作状态设计。
Apollo3 Blue Plus 的公开规格中，CPU 执行功耗约为 6 μA/MHz，BLE 关闭、RTC 保持运行时的 Deep Sleep 约为 1 μA。Apollo4 Blue Plus 的官方规格则以约 29 μW/MHz 的 CPU Active Power 表示其工作功耗。对虎麟来说，这些数字的意义不是“哪一代更省电”，而是确认平台是否有足够的低功耗空间，让 Firmware 去管理 Active、Idle、Sleep、Sampling、Sync 和 Storage。
所以我们在 SoC 选型阶段更关心的问题通常是：Sensor 多久采一次？BLE 多久同步一次？SoC 每次被唤醒多久？Flash 是逐条写还是批量写？Display 或 Audio 需要持续运行多久？
02 从 Apollo SDK Demo 到一台真正的产品，中间还有完整的工程链
Evaluation Board 上跑通 BLE、Sensor 或 Audio Demo，只能证明某个功能能够工作。真正进入产品开发以后，还要继续完成 Product Definition、SoC Selection、Power Architecture、Schematic & PCB、Board Bring-up、BSP / Driver、Sensor / Audio / BLE、Storage、Low-Power Firmware、OTA & Security、APP Integration，以及后续 DV 与 Production。
这些工作并不是彼此独立的。Hardware 增加一个 Sensor，不只是原理图多一个器件；Firmware 还要继续定义 Sampling Rate、Interrupt、Buffer、Storage、BLE Synchronization 和 Power State，APP 则需要处理设备配置、历史数据、同步状态和 OTA。
所以虎麟在 Apollo 平台上的工作重点并不是单独完成 MCU Programming，而是让 Hardware、Firmware 和 Software 从一开始就在同一套产品架构里工作。
03 数据量，往往比芯片主频更早决定产品架构
穿戴产品体积很小，但内部数据量并不一定小。以 16 kHz / 16 bit / Mono PCM 为例，Raw Audio 的数据率约为 256 kbps，也就是 32 KB/s。连续采集 1 小时约 115 MB，4 小时接近 460 MB。
16 kHz × 16 bit × 1 channel = 256 kbps ≈ 32 KB/s ≈ 115 MB/hour
这时候产品问题很快就不再是“MCU 能不能接数字麦克风”，而会变成：数据在哪里 Buffer、是否压缩、外部 Storage 需要多大、什么时候写 Flash、什么时候通过 BLE 传输，以及手机不在线时数据如何保留。
健康穿戴也一样。一个 Sensor 以 25 Hz 连续采样，一天就是 2,160,000 Samples；如果每个 Sample 为 16 bit，单通道 Raw Data 约 4.32 MB/day。
25 Hz × 86,400 s = 2.16 million samples/day ≈ 4.32 MB/day at 16 bit
因此很多穿戴产品最终真正要设计的，是一条完整的 Data Path：Sensor / Audio → Processing → Storage → BLE → APP。Apollo 的 Peripheral、Memory 和 Firmware Scheduling，最终都要服务于这条链路。
04 不同 Apollo 系列，对应的是不同的产品预算
虎麟不会简单按照“新一代一定比上一代更适合”来选择 Apollo。不同产品需要解决的问题不同，不同 Apollo 系列对应的也不是一个简单的性能排行榜，而是不同的 System Budget。
Apollo3：Sensor、BLE 与低功耗优先
Apollo3 Blue Plus 使用 Cortex-M4F，最高 96 MHz，最高 2 MB Flash + 768 KB RAM，并集成 BLE、PDM、SPI / I²C 等接口。对于以 Sensor Acquisition、基本本地处理和 BLE 为主的无屏设备或健康节点，这类资源组合仍然有明确价值。
Apollo4：有屏穿戴需要更多 Graphics、Memory 与 Audio 资源
Apollo4 Blue Plus 最高 192 MHz，提供最高 2.75 MB RAM、2 MB MRAM、2D / 2.5D GPU，并支持最高约 500 × 500 px 的显示系统。对 Smartwatch 或有屏健康设备来说，Watch Face、Animation、Health Dashboard 和 Touch Interaction 会同时消耗 RAM、Graphics、Display 和 Power Budget，因此 SoC 的角色已经不仅是 Sensor Controller。
Apollo330 Plus：更多本地 Signal Processing 开始变得实际
Apollo330 Plus Series 转向 Arm Cortex-M55 + Helium，最高 250 MHz，提供 2 MB SRAM + 2 MB NVM，并加强 Audio、高速外部存储和不同连接配置。对虎麟来说，这一代更重要的变化不是主频本身，而是 DSP、Audio Processing、Sensor Fusion、TinyML 和部分 Edge Processing 有了更合适的运行基础。
Apollo5：设备端 AI 的边界继续向前移动
Apollo510 是 Apollo5 Family 的首款产品，最高 250 MHz，并把片上资源提升到 4 MB NVM + 3.75 MB SRAM。Ambiq 公布的 AI / ML benchmark 中，相比典型 Cortex-M4F，Apollo510 可达到最高 10× Performance 和 30× Power Efficiency。这个数字属于 Ambiq 自身测试口径，但它清楚反映出 Apollo5 的方向：让更多 Speech、Health 和 Sensor AI Workload 留在低功耗 Endpoint 上执行。
05 我们不会为了“AI”而把所有计算塞进设备端
如果一款产品的主要目标只是采集、存储、同步，再交给 APP / Cloud，那么更大的 SRAM、更高的 CPU Performance 和更复杂的 Edge AI 能力未必能给最终产品带来同等价值。
反过来，如果设备希望本地完成 Noise Reduction、Voice Activity Detection、Sensor Fusion、Health Signal Processing、Feature Extraction，甚至部分 AI Inference，那么 Compute、Memory 和 Firmware Architecture 的要求会明显提高。
所以虎麟不会把 Apollo3、Apollo4、Apollo330 Plus 和 Apollo5 理解成一个“越新越好”的排序。真正的问题是：产品需要多少计算能力，同时愿意为这些计算付出多少功耗、Memory、PCB 空间和 BOM。
06 虎麟在 Apollo 平台上真正做什么
对虎麟来说，Apollo 的能力边界主要位于 SoC 之上的产品工程层。
在产品定义阶段，我们会根据 Battery、Sensor、Audio、Display、Connectivity、Local Processing 和 Product Size 确定平台与外围架构。Hardware 侧继续完成 Power Architecture、Schematic、PCB，以及 Sensor、Audio、Display、External Storage 等外围集成与 Board Bring-up。
Firmware 侧则基于 AmbiqSuite 和公开 SDK / BSP 完成 Peripheral Driver、Sensor、BLE、Audio、Storage、Low-Power State、OTA、Security Architecture 和 Device Protocol，并继续向 Device SDK、APP Integration、Data Synchronization、Prototype、DV 与 Production Test 延伸。
我们的能力边界并不在 Ambiq 芯片本身的 Silicon Design、内部 RF IP 或原厂闭源模块。如果问题进入芯片 Errata、Closed-source Stack 或 Silicon Level，本身仍需要 Ambiq 的技术支持。
虎麟所做的，是把原厂提供的 SoC、SDK 和开发生态真正转化成一台可以运行、验证并进一步进入量产的 Wearable Product。
数据来源
本文涉及的芯片规格与性能数据来自 Ambiq 官方公开资料；涉及性能提升的对比数据采用 Ambiq 自身 benchmark 口径，不代表所有实际模型或产品均达到相同比例。
• Ambiq — Apollo330 Plus Series
虎麟科技
虎麟科技围绕 AI Recording Wearables、Health Wearables、有屏智能穿戴及其他新形态智能硬件，提供从产品定义、SoC 与 PCBA、嵌入式固件、Sensor / Audio / BLE，到 APP、Cloud 与 AI Integration 的研发支持。
在 Ambiq Apollo 平台上，我们更关注的是根据产品尺寸、续航、Sensor、Display、Audio、本地计算和数据链需求选择合适的技术架构，并进一步完成从 Hardware → Firmware → APP → Product Validation 的工程落地。
Apollo 是 SoC。如何把它变成产品，是另外一件事。
联系我们
Email：allen.yue@szhulin.com
手机号：+86 13510104324
公众号：虎麟科技
虎麟科技｜AI 智能穿戴