如何去实现一种基于PIC32MX3的低功耗低成本蓝牙音箱电路设计？

　　蓝牙和音频应用实际上就是互为对方而生。 蓝牙市场成功的第一个十年几乎完全得益于在音频耳机中的集成蓝牙技术。 当智能手机走进人们生活时，蓝牙仍是一种自然选择，几乎在每一个部智能手机芯片中都能找到蓝牙的踪迹。 人们喜欢用智能手机传输音乐。
　　随着蓝牙和智能手机的不断发展，应用已经有些跟不上速度了，尽管这在某种程度上有悖正常事物发展顺序。 然而，随着只能由一个蓝牙主机设备到一个蓝牙从设备单向通话时代的迅速完结，上述情况也在发生变化。
　　对设计工程师来说，这意味着多协议、多连接、多设备，以及一个崭新而美妙的音频应用世界已如黎明破晓般来临。 智能手机用户希望有更多选择，而蓝牙技术已为此做好了准备。
　　起点：A2DP
　　在十多年时间里，蓝牙高级音频分发规范 （A2DP） 让各种各样的设备实现了很便利的无线立体声功能。 不过，现在的客户更希望用智能手机通过异于原有设想的方式来控制音频娱乐。
　　当与音视频遥控规范 （AVRCP） 等其它规范结合使用时，可把智能手机当做无线遥控器控制家中的其它蓝牙音频设备，不过应用可能会变得十分复杂。
　　虽然旨在让最终用户拥有的几乎是无缝应用，但这些应用却在软件开发和认证时给设计工程师带来诸多大挑战，而且在一个生态系统内，在要求互操作能力的配件上实现这些应用时情况尤为严重。
　　设计人员有两种架构选择。 在过去十年中，主流架构要求蓝牙模块在硬件中执行大多数功能——配对、连接和音频传输。 也就是说，蓝牙模块是一个音频编解码器，通过硬线连接方式执行这些功能。 另一种架构选择则是在软件中执行几乎全部功能；于是，32 位 MCU 在这种架构中登场了。 在软件中实现蓝牙堆栈就是将实际音频转换为架构中非常薄的一层。 这样，设计人员便能在任何地方、任何时间访问大量配置的数据流。
　　对于传统蓝牙模块，同时执行蓝牙串行端口规范 （SPP） 和高级音频分发规范 （A2DP） 是不可能的。 通过让软件访问蓝牙协议堆栈，设计人员能创建这样的应用，即能保持多个设备与音频流连接，在让用户听到声音内容的同时也可控制该音频流以及通常与音频无关的其它功能。 换句话说，音频流和控制数据流同时工作，但不会中断其中任何一个。
　　把音频和数据控制组合在一起
　　一个简单易懂的例子就是将台灯和扬声器系统组合在一起，让用户在欣赏音乐的同时，用智能手机控制台灯亮度。 该应用经过复杂的扩展后，便可用智能手机控制照明系统——色彩、强度、随音乐做出的各种变化，以及控制音频流。 在该应用中增加“智能家庭”概念扩大了控制范围，可控制自动调温器、车库门开启器，以及其它支持蓝牙的家用电器，而这些家电曾支持传统音频编解码器。
　　蓝牙控制在这些应用中具有安全优势，因为可对数据流经进行配置，使其独立于物联网 （IoT）。 几乎没有人愿意把自己车库门开启器的简单过程暴露在云端的操作不确定中，而这种情况却最容易发生，如采用 WI-Fi 解决方案时。
　　在已有多个规范同时工作的应用中组合音频和数据控制功能，会更多地扩展新应用。 在音频娱乐领域，支持软件的概念被称作“打断” （break-in），它允许多个手持设备控制同一个音频流。 在聚会时，人们可以从同一个支持蓝牙的音频内容库中轮流挑选自己喜欢的音乐。 启用自动点唱 （juke-box） 模式后，最终用户可在播放列表中添加自己喜爱的乐曲。 MCU 解决方案启用了“打断” 模式，允许多达七部智能手机采用不同的音频传输和控制方式控制同一个音频系统。
　　把音频与控制融合
　　尽管 Bluetooth SIG 已制定并批准了 30 多个规范，但在蓝牙“音频 + 控制”的全新应用领域发展初期，最重要的大概是以下四个：
　　串行端口规范 （SPP）——RS-232 无线数据传输的标准替代方案
　　高级音频分发规范 （A2DP）——用于多媒体音频传输的最常见规范。 通过 SBC 传输音频内容，并支持 MPEG 和 AAC 压缩编解码器。
　　音视频遥控规范 （AVRCP）——用于电视、家庭影院等的标准化遥控规范，通常与 A2DP 配合使用。 最近获批的特性是音频同步，例如，当手持设备上的音量改变时，受控于该手持设备的系统音量也作相应调节。
　　免提规范 （HFP） — 远程通话
　　多个规范在软件实现过程中可以同时激活，这让设计人员在创建新应用时拥有极大的灵活性。 换言之，把数据流和音频流集成在一起将会促成更高级的系统。
　　在设计阶段，必须提供仿真、测试和认证（应牢记利用蓝牙）所需的一切。 因此，一个完整的开发系统远不止音频部分，还会集成用于控制显示器、按钮、LED、智能手机和音乐的各种功能。 此外，还应包括用于音频处理功能的 DSP 能力。 系统控制——当然不仅是音乐本身，迫使我们不得不采用 32 位 MCU。
　　图 1 所示为基本蓝牙音频系统的数据通道和主要元件，我们以此为起点详细介绍创建此类功能的基本设计点。
　　从全新“音频 + 控制”应用组合的角度看该图，发送设备 （source） 侧为手机，正在传输可以进行加密的编码数据（音频和控制）。 数据会最终找到进入基带层（蓝牙无线电）的途径。 数据流执行接收设备 （sink） 侧的协议堆栈，接收侧设备可以是上文提到的任何设备/智能家电。
　　软件解决方案同时包括多协议堆栈和一个可以在源代码中修改的应用层。 堆栈处理规范通信，能与各种各样附加应用元件进行互动，包括音频解码器、数字过滤、发送侧速率转换和控制特性。 有多个解码器可用于支持蓝牙 A2DP 音频流的音频，包括 SBC、AAC 和 MP3。 利用这种模块化解决方案，设备制造商可按照特性、控制和存储器成本区分各种潜在的解决方案。
　　
　　开发板
　　为通信链路的接收 （sink） 侧系统创建开发和入门套件是一项重要工作。 虽然兼容性和互操作性测试能让设计人员更轻松地开发应用，但对于任何 MCU 供应商来说则是一个极为重要的问题。
　　目前有多种移动 OS，包括安卓 （Android）、苹果的 IOS、微软的嵌入式 Windows 以及黑莓 （Blackberry） 系统，且每个系统都有众多 OS 版本。 为确保一款切实可行的最终用户产品，套件供应商必须进行数百次兼容性和互操作测试。 根据列出的问题清单，设计人员在选择套件时，必须可靠地保证其设计能通过这些测试且返工量最少或无需返工。
　　Microchip Technology 便是该设计领域的竞争者之一。 该公司在蓝牙音频开发套件中采用了其 PIC32MX3 和 PIC32MX4 器件。 图 2 所示为基本硬件配置。
　　
　　我们具体看一下该公司的 DV320032 蓝牙音频开发套件。 该套件由 100 MHz 中级 32 位 PIC 器件提供动力，具有多达 100 个 I/O 和 512 KB 闪存/128K RAM。 这一基本套件集成了可支持 Cambridge Silicon Radio 的 CSR8811 收发器的蓝牙 HCI 子板（也可提供低成本模块）。 此外，还包括一个 DAC 子板，板上集成了一个 24 位 192 kHz DAC 和耳机输出、USB 主机端口和设备接口、一个 2 英寸彩色 LCD 显示屏以及按钮控制功能。 为使开发工作变得更轻松，该套件可驱动许多不同的功能，如苹果认证适配器 （Apple Authentication Adapter） 选项、一个调试接口、一个 SPI 闪存。
　　MCU 顶部有一个可编程接口模块 （PIM），可让开发人员可选择改换处理器，而不必担心失去宝贵的设计时间。 将来，设计人员利用该模块还能用更低成本或更高性能的器件灵活地更换标准 MCU。
　　固件的可获取性始终是套件开发的一个关键问题。 Microchip 提供如图 3 所示固件。
　　
　　Microchip 还把基于其 32 位旗舰 MCU 的更高端入门套件——200 MHz PIC32MZ2048ECH144 推向市场。 DM320006 PIC32MZ 嵌入式连接入门套件也可与另一个系统配合来实现蓝牙功能。 多媒体扩展板 2 （DM320005-2） 包括一个无控制器图形驱动、4.3 英寸的 WQVGA 显示屏、多点触控投射式电容触控 （PCAP） 按钮控制、VGA 摄像头、Wi-Fi、蓝牙 HCI 模块、基于 AKM Semiconductor AK4953 的 24 位立体声音频编解码器、3 轴加速计和一个温度传感器。 一种能与 Microchip MPLAB Harmony 软件架构配合工作的演示功能正被集成到该套件中，以支持蓝牙数据和音频应用。
　　哪个解决方案合适？
　　不可否认，蓝牙“音频 + 控制”应用的尖端性和复杂性令开发人员在如何开始开发方面感到些许困惑。 当然，关键器件就是 MCU 本身。 如前所述，32 位 MCU 及其 32 位指令集是同时组合音频和控制功能的理想选择。 在首次选择使用哪个套件时，开发人员可以参考表 1。该表介绍了一些应用及相应的存储器和 MIPS 要求。
　　
　　第一栏（描述）说明所运行的蓝牙规范和其它应用。
　　这些示例仅作演示之用，但组合在一起则说明一点，就是对于从最简单（仅蓝牙数据堆栈）到最苛刻的应用（多规范和高品质 ACC 解码器）来说，存储器和峰值 MIPS 会出现显著变化。
　　结论
　　一个使用语音进行数据控制的蓝牙开发新时代将孕育出许多全新的应用，让多个蓝牙规范同时激活并拥有多点控制、多线连接成为现实。 这些应用可能开发难度大，尤其因为它们必须通过蓝牙交互操作和兼容性测试。 这些应用中的许多也将会把 32 位 MCU 作为必要器件，但这不是为了满足数据深度之需，而是为了获得指令集资源。
　　虽然硅器件供应商提供的开发套件和固件能显著减少设计工作，但始终没有一个万能解决方案出现。 开发人员因此必须认真挑选适合自己应用的正确解决方案，同时还应考虑固件的可获取性和硬件的性能。