该方案把手机APP或小程序、WT2605C蓝牙音频芯片、设备主控三件套串成一条链路。APP上的留言和语音文件经蓝牙推到设备，存进本地存储后由WT2605C播报出来。同一颗芯片还可以负责蓝牙音乐推流和免提通话。下面把整条链路、主控与芯片的通讯方式、以及音乐推流和通话相关功能逐一拆开讲。
一、三种硬件方案先定清楚
做这个需求第一步要选架构，三种方案差别很大，核心在谁来做MP3解码、谁来做蓝牙传输。
A方案 主控自己解码MP3加单独的蓝牙芯片传输。主控自带MP3解码能力，蓝牙芯片只负责把手机发来的文件或音频流传给主控，由主控解码后送功放。好处是主控完全掌控音频管线，能叠加自己的混音和特效。代价是主控要跑解码算法占用算力，还要配一颗独立蓝牙芯片，BOM和软件复杂度都高。
B方案 主控不解码MP3加单独的蓝牙芯片加语音播报芯片。蓝牙芯片负责通讯，主控收到文件后转交给一颗专门的语音播报芯片去解码播放。好处是主控轻量，播报芯片专业稳定。代价是要两颗独立芯片分别管通讯和播报，板面积大、跨芯片联调麻烦，两颗料的成本和布线都压在设备端。
C方案 WT2605C方案，主控把解码和传输都交给WT2605C。一颗WT2605C同时干蓝牙接收和MP3解码播放两件事，主控只发AT指令调度，不碰射频也不碰解码。好处是主控最省事，BOM从两颗料压到一颗，板面积最小。代价是文件落地和播放调度都依赖WT2605C，主控要按它的模式切换规则来配合。
留言播报场景文件小、逻辑简单，优先选C方案。本文后续都围绕C方案展开，讲清主控怎么经一路串口把活交给WT2605C。
二、WT2605C与主控的UART通讯
在C方案里，WT2605C和设备主控之间走一路串口。这是芯片对外控制的主通道。
物理上用UART引脚，对应规格书第25脚和第26脚，波特率固定115200。主控把WT2605C当成一块蓝牙音频协处理器，所有动作都用AT指令下发。
上电后WT2605C默认停在蓝牙模式3。这里要记住一个事实，芯片没有掉电记忆，每次重启都会回到蓝牙模式3，主控不要假设上电就在播放本地文件的状态。
主控和芯片之间最常用的几类交互。
切模式。主控发AT+CHMODE=4让芯片进音乐模式播本地，发AT+CHMODE=3退回蓝牙模式继续等连接，发AT+CHMODE?查询当前处在哪态。这条指令是整个方案的状态枢纽。
播索引。进音乐模式后，主控用播放类指令指定文件位置。按盘内编号播、按文件名播、按指定盘符播这几类指令已经过验证可用，具体指令名以原厂资料为准，主控按编号下发即可让芯片播某一条留言。
查忙闲。芯片第27脚BUSY是播放状态反馈脚。芯片在播本地文件时BUSY拉低，空闲拉高。主控既可以用这个脚做硬件判忙，也可以在串口轮询状态。播完一句留言后靠BUSY回到高电平，主控据此决定下一步切不切回蓝牙模式。
换盘符。本地存储可能分布在片内Flash、外接SD卡、U盘三处，分别对应fat_nor、sd0、udisk0。主控用盘符切换指令AT+CHANGE_DEV在三者间选择，用AT+CHANGE_DEV?和AT+GETALLDEV?查询当前盘和所有可用盘。留言文件落在哪块介质上，主控要先把盘符切对。
三、APP留言到设备播报的完整时序
以C方案为例，把前两节串起来，一条留言从手机到喇叭的完整过程是这样走的。
手机小程序在蓝牙模式3下经BLE把MP3分片发给WT2605C。WT2605C在模式3下同时跑着音频蓝牙、免提通话和BLE数传，收文件不影响它当前连着手机。文件按偏移加长度分片下发，每片带累加校验，防止半包写坏。
文件收齐后，WT2605C把它存进目标盘，比如片内Flash或TF卡，并分配一个索引号。主控不用参与收文件，但可以轮询存储状态确认落盘。
要播这条留言时，主控发AT+CHMODE=4切到音乐模式，再用播放索引指令指定刚存好的那条，芯片从本地介质读出MP3播给功放。BUSY脚拉低表示正在播。
播完BUSY回高，主控发AT+CHMODE=3把芯片交还蓝牙模式，等待下一次手机连接或下一条留言。整个状态切换清楚，不拖泥带水。
四、音乐推流A2DP
音乐推流走的是蓝牙音频标准里的A2DP。手机作为音源，WT2605C作为接收端，手机里的歌经蓝牙无线推到芯片，芯片解码后从DAC送功放播出来。这是WT2605C在蓝牙模式3里最核心的音频蓝牙能力。
关键点在于，A2DP推流和BLE数传在模式3下是并行的。手机一边推着歌，APP一边还能经BLE给设备发控制指令、查状态、甚至推小段留言文件。这正好解释了为什么留言播报要切到模式4、而推流留在模式3，推流和数传同态并行不打架，本地播放才需要单独切出去。
音质方面WT2605C的DAC动态范围约95分贝，支持MP3和WAV、码率覆盖8到320kbps，接车载或便携音响够用。32级音量可在串口或APP侧调节。
五、通话与通讯录相关功能
免提通话走HFP，WT2605C在蓝牙模式3下作为免提设备，手机来电时语音经蓝牙进芯片、由芯片送麦克风和功放完成双向通话。麦克风接第30脚，天线接第16脚。
来电号码显示是HFP的标准能力。若WT2605C在HFP下支持主动上报来电号码，主控能在串口收到号码信息，可用来在屏幕显示或触发TTS播报。这条要看具体固件是否开放该上报，开发前先确认。
通讯录同步要单独说清边界。完整通讯录同步走的是PBAP电话本访问协议，属于HFP之上的增强功能。WT2605C定位是蓝牙音频从芯片，它是否实现PBAP、能否经串口把整本通讯录吐给主控，规格书没有明确支撑，需要查原厂SDK确认。实务上建议把通讯录逻辑放在手机APP侧处理，设备端只负责播号码或播APP下发的提示音，不要依赖芯片去拉整本通讯录。
来电抢占这条硬约束务必写进代码。任意模式下手机一来电，WT2605C会被强制切回蓝牙模式3接通话。通话期间本地播放中断，挂断后芯片不会自动回音乐模式，必须主控手动发AT+CHMODE=4才能恢复本地播报。留言播报功能如果正在播，被来电打断后要靠这条手动恢复逻辑兜底。
六、不并行设计的实战约束
整篇方案的根是WT2605C蓝牙模式和音乐模式不能同时运行。收留言文件在模式3，播留言文件在模式4，这是两条状态线，主控必须规划好时序，绝不能一边收一边播。
三条硬约束再强调一遍。上电默认蓝牙模式3无掉电记忆。音乐模式4里若触发蓝牙音频会自动弹回模式3。来电强制抢占切到模式3且挂断需手动恢复。把这三条写进状态机，留言播报才不会在通话或重启时跑飞。
写在最后
WT2605C用一颗芯片把蓝牙音频、免提通话、BLE数传、本地MP3播放收进同一颗QFN32里，主控经一路115200串口就能调度全部动作。也就是前面说的C方案，主控既不用带BLE射频、也不用做MP3解码，一颗WT2605C收文件又播本地，把BOM从两颗料压到一颗。音乐推流和数传在模式3并行，本地播报靠模式4完成，两者靠AT+CHMODE切换衔接。通讯录这类增强功能建议留在APP侧，别压到芯片上。