1. 为什么低功耗设计开始拥抱Cortex-M33这几年的低功耗MCU市场确实有意思。以前一提低功耗大家脑子里蹦出来的基本都是Cortex-M0最高主频跑个几十兆功耗能压到微安级别完事。但这两年风向明显变了NXP、瑞萨、ST、兆易创新这些厂商的新品低功耗系列不约而同开始往Cortex-M33上靠。你去看这颗“Low-Power MCU Embeds Arm Cortex-M33”的定位它已经不是传统意义上那种“省电就行”的简单单片机而是把功耗、性能、安全这三件事揉在一起做了。为什么会有这个转变核心原因是终端产品的需求变了。以前的低功耗设备比如烟雾报警器、体温计、遥控器芯片干的活确实很单一Cortex-M0绰绰有余。但现在的低功耗设备在干什么可穿戴设备要跑心率算法甚至本地跑个简单的人体活动识别工业传感器要加密通信怕数据被中间人截胡智能门锁要处理指纹图像、还要防侧信道攻击资产追踪器要在NB-IoT和BLE之间切换同时维护好几个协议栈。这些负载对算力的要求是实打实的Cortex-M0跑起来真的很吃力。你让M0去跑一个AES-256-GCM加一个椭圆曲线签名验证CPU占用率直接飙到七八成RTOS任务调度都开始抖动。而Cortex-M33跑同样的活儿可能只占两成不到剩下的算力还能干别的。再加上TrustZone硬件隔离安全相关的活儿可以扔到安全区里跑普通应用代码再乱也碰不到密钥。这就是M33在低功耗MCU里立足的根本逻辑不只是更低功耗而是单位功耗下能干的活更多、更安全。这篇文章主要聊聊这类芯片的核心架构、低功耗设计的实际落地思路以及我实际调试中踩过的坑。想给低功耗项目选型、或者正准备从M0/M4往M33迁移的朋友可以重点看看第二、三、四部分。2. Cortex-M33到底强在哪不只是主频高了2.1 从架构层面看M33和M0/M4的区别先说结论Cortex-M33不是M4的替代品也不是M0的简单升级版它走的是ARMv8-M主线架构定位是“带安全扩展的中间档内核”。它的直接对标其实是Cortex-M4但在几个关键指标上做了取舍和增强。指令集方面M33支持完整的DSP扩展和可选配的浮点单元FPU单精度。主频做上来以后它的整数运算能力大致比同主频的M4高5%到15%因为流水线设计更优分支预测也做了改进。更重要的是它的中断响应做了硬件自动压栈优化中断延迟可以做到12个周期以内这个对实时控制场景很有吸引力。但M33真正的杀手锏是TrustZone技术。这个东西在Cortex-M23/M33这一代内核上首次引入MCU领域本质是把芯片的地址空间划分为安全区Secure World和非安全区Non-Secure World。划分的粒度可以做到单颗中断、单个外设、甚至单页内存。这对低功耗物联网设备非常关键因为设备一旦部署到现场固件升级、密钥管理、通信加密这些安全操作如果和主应用混在一起跑任何一个缓冲区溢出漏洞都可能导致密钥泄露。有了TrustZone密钥相关代码锁死在安全区非安全区的应用代码就算被攻破也没法直接读取密钥。和Cortex-M0对比M33在主频、算力、外设访问效率上全面领先功耗当然也高一些。但如果你做的是电池供电且需要联网加密的设备这个功耗增量换来的算力和安全能力是值得的。举个我实际评估过的例子一个BLE心率胸带方案数据率不高但需要每包数据做AES-CCM加密M0跑加密时功耗尖峰很明显而M33因为加密指令执行更快反而能更早睡回去整体平均功耗居然和M0方案差不多。对比项Cortex-M0Cortex-M4Cortex-M33架构ARMv6-MARMv7E-MARMv8-M MainlineDSP扩展不支持支持支持浮点单元无可选单精度可选单精度TrustZone安全隔离不支持不支持支持可裁剪中断延迟典型约16周期约12周期约12周期典型主频范围16-72MHz72-240MHz64-180MHz安全相关指令无无SVC、SG等安全扩展指令2.2 低功耗不只是降低主频TrustZone和功耗管理的联动很多人以为TrustZone只和安全有关和功耗管理八竿子打不着。实际用下来你会发现两者的联动关系相当重要。最典型的一个场景是密钥存储处理。M33的TrustZone可以把OTP一次性可编程存储和密钥管理单元放在安全区里控制。设备在睡眠之前应用代码只需要把要加密的数据包交给安全区的服务调用接口通过SG指令进入安全世界安全区里的固件自动完成密钥读取、加密握手、数据包签名然后返回结果。这个过程里非安全区代码完全不知道密钥什么时候被读取过也不知道密钥存在哪。从功耗角度看这种设计带来的好处是整个加密通信的数据面和控制面可以分离。也就是说非安全区里的通信协议栈可以独立睡眠和唤醒不需要为了做一次加密操作而把整个系统全部拉起来。反过来安全区服务被调用时硬件会自动把安全区相关的电源域拉起来。这种粒度控制在M0/M4上是做不到的安全功能只能靠软件层做个壳要么全上电要么全下电没有中间态。我在实际的低功耗门锁项目里用M33就这么设计过指纹识别算法在非安全区跑识别阈值模型和密钥在安全区保存用户按下指纹时传感器中断唤醒非安全区算法跑完把特征值通过安全API送进安全区比对比对完立刻睡眠。整个过程中蓝牙协议栈始终处于休眠状态直到匹配成功才被唤醒。这种架构下系统待机电流能压到几个微安比传统单核方案反而更省电因为睡眠状态更纯粹唤醒事件更少。所以M33的低功耗强项不能只看数据手册里那行“Standby Current 1.x μA”那个数字任何芯片都能写出来。真正的区别在于它能不能让整个系统以更合理的方式睡眠、更精准地按需唤醒而TrustZone的引入恰好提供了这种精细控制的架构基础。3. 低功耗M33的实战设计从时钟到外设的全链路优化3.1 时钟树设计低功耗的第一道门槛很多低功耗项目翻车不是芯片不行而是时钟配置太粗糙。M33内核本身频率高跑起来功耗确实比M0高但它也提供了一系列降频手段。关键是你系统里不需要Cortex-M33一直全速跑。以一颗常见的M33低功耗MCU为例它通常有多个时钟源外部低速晶振32.768kHz、外部高速晶振8MHz-25MHz、内部RC振荡器低速和高速各一、还有PLL。低功耗设计的第一原则就是能不用PLL就不用PLL。PLL一开后面整个模拟电路都要供电功耗可能多出几百微安。我自己做低功耗项目时的习惯是Run模式下按需开启PLL但任务跑完立刻切回内部RC或直接降频。大部分时间跑在32.768kHz外部晶振上只让M33运行在几MHz的低频状态处理定时、按键扫描、传感器轮询这些轻负载任务。需要高算力时比如跑加密或算法从睡眠模式快速唤醒PLL锁定后全速跑几百微秒跑完再睡。这种“跑一段睡一段”的节奏实际平均功耗比一直低频运行要低。因为芯片在极短的时间内完成计算然后进入深度睡眠睡眠电流通常是微安级甚至更低而低频运行虽然瞬时功耗低但持续时间长总体能量消耗反而更大。M33的中断控制器NVIC在低功耗模式下是可以配置成“事件驱动唤醒”的。也就是说不需要CPU轮询任何标志位外设事件比如RTC秒中断、低功耗定时器溢出、GPIO边沿触发可以直接把CPU从睡眠中拉起来。关键是唤醒后要知道从哪里继续执行M33的异常返回机制会保证现场恢复不需要写任何额外的汇编代码。这一点比老架构体验好很多。3.2 外设的低功耗设计GPIO、串口、ADC的隐藏功耗源外设层面的功耗坑比内核多得多。我列几个排查时最容易忽略的点都是实际项目中踩过的GPIO上下拉状态。这是最大的隐藏功耗源。一颗M33低功耗MCU在深度睡眠模式下GPIO如果被配置成浮空输入引脚电平不确定的话输入缓冲器可能产生持续漏电流一个引脚几十微安到上百微安很正常。多个引脚加起来待机电流直接翻倍。我一般要求在进入睡眠前把所有不用的GPIO统一配置为模拟模式如果芯片支持的话或者固定为输出低电平。特别是串口RX引脚来自外部设备时如果外部设备没上电RX线上电平不确定串口外设的输入缓冲器就会一直漏电。很多工程师在排查低功耗问题时怎么都查不出那几百微安的电流最后发现就是串口RX引脚悬空导致的。串口接收端口是否有上拉这个问题其实挺有讲究。从硬件上看M33系列MCU的串口RX引脚在复位默认状态下通常内部上下拉是关闭的。但进入低功耗模式前建议把RX引脚的内部上拉使能打开确保外部设备不驱动时RX线保持确定的高电平。否则UART外设虽然没开但引脚电平浮空缓冲器照样耗电。这在低功耗项目中非常容易被忽略。ADC的参考电压。ADC模块在低功耗模式下如果不彻底关闭其参考电压缓冲器reference buffer会持续耗电。有些芯片的ADC参考电压默认由内部LDO供电即使ADC没启动转换只要外设时钟没关这个LDO就在跑。排查方法很简单把外设时钟全部关闭逐个打开ADC外设时钟观察电流变化。低功耗定时器不一定是低功耗的。有些芯片提供多个定时器但真正能在深度睡眠模式下运行的只有一小部分。如果你选错了定时器在睡眠模式下它会唤醒系统时钟源来回切换表面看是睡了实际每隔几百微秒就醒一次平均功耗完全下不来。这个要仔细看数据手册里的“低功耗模式外设支持”表格。3.3 MCU启动流程与低功耗状态的衔接很多人在调试M33启动流程时也遇到和低功耗相关的问题系统明明进入了深度睡眠但一觉醒来时钟配置乱套了外设状态也变了。这其实不怪芯片而是启动代码没有区分“冷启动”和“热启动”两条路径。M33的启动流程和M0/M4类似复位后从向量表取出初始SP和PC进入SystemInit函数依次配置时钟、初始化SRAM、拷贝数据段。但如果系统是从深度睡眠模式下唤醒的比如RTC唤醒或外部事件唤醒并不需要重新初始化所有外设只需要恢复时钟源、恢复中断向量表偏移、恢复关键外设寄存器状态即可。如果在唤醒路径上执行了完整的SystemInit反而会把某些外设配置重置掉导致唤醒后系统出现异常。我实际遇到过一个问题设备从睡眠模式唤醒后低功耗定时器的计数值被Load了默认值导致本应每隔10秒唤醒一次结果每1秒就唤醒一次。排查了很久才发现是启动代码在唤醒路径上对定时器外设做了完整的软件复位。后来改成用“复位原因寄存器”RCM区分冷启动和热启动只在冷启动时执行完整初始化问题立刻解决。这里顺便说一点M33特有的由于TrustZone的存在启动流程会多一个安全区的初始化步骤。安全区代码Secure Firmware需要在非安全区应用跑起来之前先完成自身初始化然后通过VTOR向量表偏移寄存器和NSVTOR非安全向量表偏移寄存器把控制权交给非安全区。如果你在做低功耗唤醒安全区的初始化肯定不能每次都做否则睡眠唤醒延迟会高到无法接受。通常的做法是安全区初始化一次之后深度睡眠时保留安全区SRAM的内容和状态唤醒后直接跳回非安全区。4. 实操记录用M33低功耗MCU做个蓝牙传感器节点4.1 需求设定与硬件资源分配为了把前面讲的这些原理落到实际我拿一个真实的项目来拆解一颗M33内核的低功耗蓝牙传感器节点用来做冷链运输的温度记录电池用两节AA电池要求待机电流低于5μA正常运行时平均电流低于10μA能连续工作一年以上。硬件上除了MCU本身外围还有一颗温湿度传感器、一颗BLE射频前端芯片外挂方案以及一个用于固件升级和调试的串口接口。MCU负责定时唤醒读取传感器数据通过BLE广播发送数据包然后继续睡眠。这里我选的芯片型号不具备蓝牙功能所以BLE走外挂方案MCU和外挂BLE芯片之间通过UART通信。这种“MCU外挂BLE”的架构很常见也比较适合讲解低功耗流程因为MCU的睡眠策略可以控制得很死。整个系统有几种运行状态状态模式电流持续时间说明深度睡眠LP-Sleep仅32.768kHz运行约2.5μA默认状态等待RTC唤醒传感器采样Run模式内部RC 8MHz约1.5mA约5ms读取温湿度并存储BLE发送Run模式PLL开启约3mA约10ms通过UART发送数据包广播等待Sleep模式UART开启约50μA约30ms等待BLE芯片确认4.2 核心代码从睡眠到唤醒的完整流程这部分代码是调试过程中最终稳定的版本我做了精简但保留核心逻辑。整体思路是RTC定时唤醒唤醒后执行传感器采样和BLE数据上报完成后立刻再次睡眠。#include m33_soc.h #include rtc.h #include uart.h #include sht30.h /* 冷启动标志位于不初始化数据段 */ static uint32_t cold_boot_flag __attribute__((section(.noinit))); int main(void) { uint32_t reset_cause; /* 1. 先判断本次复位原因 */ reset_cause RCM-GET_CAUSE(); if (reset_cause RCM_CAUSE_POR) { /* 冷启动完整初始化 */ cold_boot_flag 0x5A5A; /* 写入冷启动标识 */ SystemInitFull(); /* 配置PLL、外设时钟 */ SHT30_Init(); UART_Init(115200); RTC_Init(10); /* 每10秒唤醒一次 */ } else { /* 热启动从深度睡眠唤醒只恢复必要状态 */ SystemInitLight(); /* 重新使能内部RC和GPIO */ /* 保留传感器和UART的配置无需重新初始化 */ } /* 2. 执行本轮任务 */ uint32_t temperature SHT30_ReadTemp(); uint32_t humidity SHT30_ReadHumidity(); uint8_t packet[8]; packet[0] 0xAA; /* 包头 */ packet[1] (temperature 8) 0xFF; packet[2] temperature 0xFF; packet[3] (humidity 8) 0xFF; packet[4] humidity 0xFF; packet[5] crc8(packet, 5); packet[6] 0x55; /* 包尾 */ UART_Send(packet, 7); /* 3. 配置进入深度睡眠前的GPIO状态 */ GPIO_ConfigAllAnalog(); /* 除唤醒脚以外的引脚全部配成模拟模式 */ GPIO_SetWakeupPin(GPIO_PIN_BLE_IRQ); /* 设置BLE中断引脚为唤醒源 */ /* 4. 进入深度睡眠模式 */ __WFE(); /* 唤醒后继续执行从头开始判断复位原因 */ NVIC_SystemReset(); }代码逻辑并不复杂可能不少人已经看出来了这个方案用的是“每次唤醒后软件复位”的方式而不是“从WFI之后继续执行”的传统流程。为什么要这么干原因有两点第一深度睡眠模式下很多外设和SRAM的供电域是会被切断的。从深度睡眠唤醒后一些外设寄存器已经丢失外设状态不可信。与其在唤醒路径上花大量代码去恢复和验证每个外设状态不如直接软复位让系统从头跑一遍反正整个流程也就5毫秒左右功耗Impact可以忽略。第二M33在深度睡眠唤醒后如果安全区加载了带TrustZone的固件非安全区应用代码的堆栈指针、状态寄存器可能是不可信的。直接软复位能保证系统进入一个确定的状态避免各种隐性bug。我见过有些工程师在M33低功耗项目中坚持用“继续执行”的方式结果遇到各种奇奇怪怪的问题某个外设在唤醒后配置丢失导致通信错误或者栈指针恢复异常导致hardfault。排查起来非常费劲。当然软复位的方式也有代价就是唤醒延迟会增加因为调度器、RTOS、协议栈都需要重新初始化。如果项目对唤醒延迟要求非常高比如需要在1毫秒内从睡眠恢复到全速运行那软复位就不合适了就得改成“状态机恢复”的方式。但大多数传感器类低功耗应用唤醒延迟几毫秒完全不影响软复位反而更省事。4.3 电流实测与调试方法代码烧进去之后关键就是实测电流。我用的测量方法是用万用表串联在电池正极先看平均电流然后用示波器加低噪声电流探头抓瞬态波形。实测数据如下状态预期电流实测电流差异原因深度睡眠5μA4.3μA略低于预期芯片表现不错传感器采样BLE发送3mA3.8mA略高于预期UART通信效率低平均电流10μA8.7μA满足设计指标第2项的3.8mA比预期高了0.8mA分析后发现是因为UART通信时BLE芯片要求MCU先发送一个唤醒命令然后需要等待BLE芯片的响应这期间MCU处于忙等状态白耗了几毫秒。优化方案是把忙等改成等待中断MCU在等待期间进入Sleep模式电流能再降一大截。另外说说ADC方面。这个项目里温湿度传感器走的是I2C接口没有用到ADC。但我在另一个项目里用到了M33内部的ADC做电池电压监测原理和通用MCU ADC类似ADC模块通常是逐次逼近型SAR ADC内部有采样保持电容和比较器转换过程需要多个时钟周期。低功耗项目的关键是在ADC使用完毕后必须显式关闭ADC模块本身及其参考电压缓冲器只保留芯片的掉电检测模块BOD来监测电池电压。因为BOD模块通常是一个独立的低功耗电压比较器和主ADC共用一个模拟前端但功耗低得多。如果为了省事直接开着主ADC慢慢采样一个毫安级别的电流就白耗了。M33的ADC还有一个特性它支持在低功耗模式下通过硬件触发启动采样比如通过低功耗定时器触发采样完成后通过DMA搬移数据整个过程CPU不参与也不需要CPU从睡眠中唤醒。只有数据超过阈值时才产生中断唤醒CPU。这种“智能传感器接口”的思路在需要周期性监测模拟量但又不想频繁唤醒CPU的场景下非常实用。5. 开发环境搭建VS Code和厂商SDK的配合玩法5.1 选型用官方IDE还是VS Code低功耗M33芯片的开发环境不同厂商的体验差别很大。有些厂商的官方IDE用的是老牌的Eclipse或自家定制的IDE界面老旧代码补全和调试体验一言难尽。而VS Code这几年在嵌入式圈子里流行起来配合Cortex-Debug插件和J-Link使用体验完全不输商业IDE。我用VS Code搭建M33开发环境核心组件包括组件用途说明ARM GCC Toolchain编译工具链推荐arm-none-eabi-gcc 10.3以上版本Cortex-Debug插件调试支持J-Link、OpenOCD、ST-Link等CMake工具工程管理配合厂商SDK的CMake模板J-Link Commander烧录与调试SEGGER的J-Link配合最佳厂商SDK寄存器定义与驱动不同厂商命名不同但结构类似用VS Code的好处是代码检索、跳转、Git集成都很好用调试配置写好后F5键启动调试断点、变量监视、寄存器查看都支持。当然如果你是第一次用M33芯片建议先用厂商的官方示例工程把板子跑起来确认开发环境没问题再切换到VS Code工作流。否则一上来就折腾编译链接脚本容易陷入环境问题无法自拔。5.2 一个典型的编译烧录流程以SEGGER的J-Link为例编译生成hex文件后用JLinkExe命令行工具烧录#!/bin/bash # 编译 cmake -B build -DCMAKE_TOOLCHAIN_FILEarm-none-eabi.cmake cmake --build build -j # 烧录 JLinkExe -device M33_DEVICE -if SWD -speed 4000 -autoconnect 1 \ -CommanderScript flash.jlink # flash.jlink文件内容 h loadfile build/main.hex r g exit烧录后可以直接在J-Link RTT Viewer里看到printf输出。RTTReal-Time Transfer是SEGGER提供的一种调试输出方式它利用MCU的调试接口SWD/JTAG和RAM缓冲不需要额外占用UART引脚也不会中断程序执行。对低功耗调试特别友好因为调试过程中不会因为printf阻塞程序运行可以精确看到电流波形和日志的对应关系。5.3 调试M33的一些坑M33调试时有几个和M0/M4不太一样的点值得单独说断点数量有限。很多M33低功耗芯片的调试单元DWT只支持4个硬件断点加上1个Flash断点如果有。如果你在中断处理函数里打了很多断点可能超出硬件限制调试器会报错。解决办法是少打断点多用Log输出。TrustZone调试访问限制。如果启用了TrustZone调试器对非安全区调试默认可以访问但安全区的寄存器和内存访问会被硬件限制。有时候你在安全区固件里设断点却发现断点根本不会命中多半是调试权限没配好。需要在调试器配置里显式启用安全调试访问一般是设置DHCSR的Debug Authentication位。低功耗模式下调试器断连。这是最常见的问题芯片进入深度睡眠模式后内核时钟被关了调试器无法访问核心调试会话直接断开J-Link报错“Cannot access target”。解决办法是在调试配置里把调试器设置为“低功耗调试模式”Low Power Debug内核在睡眠时会保留调试接口的时钟。不是所有芯片都支持但M33系列大部分都支持。如果实在不支持那就只能靠串口Log和RTT输出来做低功耗调试了。6. 从M0/M4迁移到M33你需要知道的兼容性差异6.1 代码层面的主要改动点如果你的老产品用的是M0或M4现在要迁移到M33低功耗芯片代码迁移的工作量其实比你想象的要少但有一些坑需要提前规避。外设驱动库不用重写。大部分厂商SDK提供的HAL库或LL库API风格都是统一的。M33的低功耗外设比如LPUART、LPTIM、RTC等命名和用法在M0/M4时代就有迁移过来基本是改头文件引用和时钟频率宏定义的事。但有几个地方必须仔细检查中断优先级配置。M33的NVIC和M4一样支持可配置优先级但ARMv8-M架构的特性是安全区中断和非安全区中断的优先级是分开管理的。如果你启用了TrustZone中断优先级配置函数不能简单套用M4的写法需要指定中断属于安全区还是非安全区。否则中断进不来或者优先级配置无效。SysTick和低功耗定时器的优先级设置。M33内核的SysTick在非安全区使用时默认优先级可能设得不太合理导致低功耗唤醒处理被高优先级中断打断。我遇到过的情况是RTC唤醒中断把系统从睡眠拉起但在处理RTC中断的过程中SysTick中断又进来了两者优先级配置不当导致唤醒流程执行到一半又睡回去表现为设备偶尔完全不响应。最后把RTC中断优先级提到SysTick之上才解决。6.2 TrustZone是否一定要用很多第一次用M33的工程师会纠结TrustZone到底要不要用用了会不会太复杂我的建议是分两种情况如果你的产品需要出厂后升级固件或者需要保护密钥、证书等敏感数据那TrustZone值得用。哪怕只是把密钥锁在安全区里非安全区应用随便怎么写都碰不到密钥这点安全价值在物联网设备被抄板、被逆向的今天越来越宝贵。如果产品不需要网络通信也没有敏感数据保护需求那完全可以把TrustZone关闭把M33当一颗增强版M4用。芯片的全功能模式Non-Secure only性能就是M4加强版代码迁移反而简单。不过有一点需要注意M33如果不启用TrustZone和M4在向量表结构、启动代码上还有一些细微差别。比如ARMv8-M的向量表增加了安全相关字但如果你不用TrustZone这些字会被跳过。启动代码的汇编部分建议直接用厂商提供的startup文件不要图省事把M4的startup文件拿来改很容易漏掉M33特有的系统初始化步骤。7. 写在最后的几条实操经验把整个M33低功耗项目走下来我总结几条实操经验不一定全对但都是真金白银踩出来的第一低功耗项目的电流测量不能只看平均电流一定要用示波器抓瞬态电流波形。平均电流7μA听起来很好看但如果实际波形是每隔几毫秒就有一个50μA的电流尖峰说明系统根本没有进入深度睡眠而是反复被唤醒又睡回去。这种问题只有看波形才能发现。第二GPIO在睡眠前的状态管理是低功耗的胜负手。一定要逐个引脚排查上下拉状态特别是串口RX脚、外部中断脚、I2C引脚。建议写一个进入睡眠前统一配置GPIO的函数把IO状态收敛到确定值调试时能省一半时间。第三M33的TrustZone在低功耗项目中不要一上来就全量启用。先把基础功能和功耗测试跑通再叠加安全功能。否则安全固件本身引入的功耗问题会和非安全区的低功耗问题混在一起排查困难度翻倍。第四如果项目对成本敏感可以考虑去掉外部晶振完全依赖内部RC振荡器。M33系列芯片的内部RC振荡器精度通常能到1%以内BLE通信对时钟精度要求虽然严格但配合蓝牙芯片的硬件时钟同步机制内部RC完全够用。去掉外部晶振不仅能省一个物料还能省下晶振起振电路的功耗。总的来说低功耗MCU选M33已经不是单纯追求功耗数字的下降而是追求在安全、算力和功耗之间找到最优解。对产品经理来说这是功能升级的底气对嵌入式工程师来说这是值得花时间去掌握的下一代低功耗平台。这个方向的后续思路我还在验证另一个项目M33搭配外置AI加速器做端侧语音识别利用TrustZone做语音模型和用户敏感音频数据的隔离同时在音频处理完成后立刻进入深度睡眠。后面跑了实测数据再单独写一篇。