[原创] 【TI首届低功耗设计大赛】低成本节能广播系统总结

说是总结——其实也完不成了，善始善终，做不完，不影响总结一下。
原本以为完成没问题的，结果突然事情多了，时间就没有了。以为元旦放假三天恶补一下，保质保量还是没有问题的，又不想病了一场……真是赔了夫人又折兵呐……先不说病的事，往往就是，成果没出来，没浪费时间的话，那就不叫损失；成果没有出来，时间却也过去了，那损失就大了。

为了不让损失扩大，至少把前面所做的东西，做以总结：

=================================我是双层的分割线===============================

a. 项目名称——低成本节能广播系统

b. 项目定位——对音质要求不高的公共场所广播级定时播放。受各项因素限制，目前阶段仅实现播放相关的功能，对于实时拾音广播，暂且先不讨论。

c. 项目规划——利用本系统，可以通过一张SD卡上保存配置信息和音乐文件，进行定时播放指定音乐的功能，整个播放系统（包括功放系统）在空闲时进入休眠模式，以降低功耗。在控制成本、减少器件使用的同时，减少功耗损失，保证播放音质可接受，同时易于操作和管理。至于成本及功耗的相关目标数据，个人能力有限，目前也无法进行估计和实际测量。（计划进一步完善的内容是，在更加庞大的系统中，需要将功放改换为通用功放机，这样就需要，要么①提供出一个电源，利用继电器等设备进行管理和控制，但是直接切断电源的工作方式不理想，要么②输出遥控信号对功放机进行开关等管理，要么③需要进一步研究通用功放机的通用接口管理方式）

d. 实现功能——声音播放，按键支持，红外遥控支持（时间原因，这部分暂未实现），文件系统的支持，wav文件的播放，时间的设定和获取，低功耗休眠和定时唤醒工作（时间原因，这部分暂未实现）

e. 原理图——这个事比较令我头疼，我没有硬件经验，根不不会用……其实那软件的名字我都记不住……画电路图，只能简单描述：MSP-EXP430FR5969 LaunchPad，保留Pad上的两个按键，利用一路SPI支持SD卡的文件系统，利用一路PWM实现声音波形的输出，利用一路CAP进行红外遥控信号的识别。输出的声音通过一个简单的功放进行信号放大。

f.  BOM——现在手里什么都没有……MSP-EXP430FR5969 LaunchPad一块，SD卡槽模块（粗看就是卡槽加3个小电阻）一个，功放D2822A（我只有个这个，不认得别的），若干电阻电容

g. 创新点——其实谈不上什么创新点，就是极大压缩了成本，意味着要把芯片的性能极大的挖掘出来

h. 软硬件设计思路——核心内容就是如何提高对芯片性能的利用率，通过衡量一些指标，发现8K8bit的单声道音质（就是传说中的电话音质）还是很难被430支持，进一步降低，选择了8K7bit，发现这个音质还是可以接受的。（为什么不降低频率，因为改变频率意味着文件的生成需要更为特殊的手段，这样就有悖于易用性了。而降低位数，无非就是实际运行的时候舍弃若干位，生成时按照8bit生成即可）。通过以上分析加上一些实验，最终确立的实现方案和基本的参数指标。与此同时，8K*8bit，对于SD卡读取速率来说，是完全没有问题的，空闲时间可以拿来作为按键的检出，如果要实现红外线输入输出的话就需要更多的分析，合理利用CPU闲时。总之优先级最高的是，保证声音播放的连续性。

i. 问题与对策——来说几个大问题，基本都集中的声音播放上，毕竟这件事已经有点接近430能力的极限了……
    1.出现播放断音
        断音的原因就是播放时不能均匀连续地把声音数据送到PWM输出。这个事情的原因很多很复杂，我后来用了双缓冲交替进行缓冲播放，即使这样都会出现断音，也许是因为两个Buffer进行交换，交换的机会很固定，一次性要读取的东西太多，造成一旦交换的机会赶在处理繁忙的时候，这次交换很可能会晚些时候才灌入数据，这样可能会耽误下一次交换。最后没有办法，索性做成一个缓冲队列型数组，加一个播放用的缓冲数组——缓冲队列随时从SD读取补充数据，播放数组也会随时进行补充，繁忙的时候没有机会补充数据也没有关系，相对空闲的时候会更多的补充数据——毕竟取数据和播放数据的速度差别还是很大的，只要有个机会，数据缓冲就会被补满，所以增加补充数据的机会，就降低了断音的可能。现在我的播放器基本上再也没有过断音。

    2.报时声音有POP声
        POP声发生在报时的时候，每个数字之间，这个没有什么妙招了，感觉好像就是两个声音文件衔接可能会出现衔接点前后数据（这两个数据往往都是相当于空白无声，具体原理不太懂，但是由于主要核心声音数据不同，导致空白无声的数据也并不是完全一样的，于是数据会有——）变化，导致输出信号突变，引发POP音。于是我将报数的声音文件切断，只保留其中核心的部分，这样即使仔细听也还有POP，但是由于相当于切去了空白部分，只保留主要的声音流，声音从一个数字突变到另一个数字，POP音就被突出的核心发音给掩盖住了。

    3.“盲目”设定时间
        这个没有什么问题，只是因为我设计时没有加上一块屏幕（谁让我穷来着……），所以找了旁门左道，设置的时候，用声音代替显示，让用户知道现在设置到多少了。设置时间时，系统就会报出现在设定的时间数，或者是分钟数。

    4.定时播放
        这个话题，其实还没有真正的实现，但是作为方案的一部分，已经早有考虑。虽然现在无法完成了，也可以作为总结的一部分简述一下，也便于我将来想要做有关处理，能够提供一个思路，别忘了。如果说正统一些的处理，那一定是通过文件系统中的配置文件，设定了休眠以后哪年哪月哪日几时几分醒来，播放什么文件——这个文件中可能有成百上千条记录，要查询起来是难而又难——主要是浪费时间，所以大多数的定时系统，也都是按星期为周期进行循环，判断是周几，几时几分播放什么，这样也就OK了。不过为了更简单，干脆可以讲配置文件配置在统一的目录下，周一一个文件，周二一个文件……只要判断了今天星期几，那么就取相应的配置文件，再进一步读取当前时间下应该播放的文件的路径。于是每次休眠以前，应该判断一下下一次醒来的具体时间，设定Alarm，到时唤醒，然后就进入低功耗模式——即便如此，还是很麻烦，因为需要各处判断并重新设置下次唤醒的时间。所以根据上面的思路，可以进一步设计为：每分钟醒来，判断现时间是否有播放任务要处理，如果没有，再次休眠；如果有，就播放，播放结束后，休眠。如果前些天没生病的话，我就要暂且先按照最后这个思路进行实现了，应该是很容易的。

    5.红外遥控信号的解析
        这个恐怕是难题一个，因为解析红外信号（大家都了解的，这个是载波发送的调频信号），需要利用定时器的中断，对信号周期进行测量。而前面说了，为了保证播放的连续均匀，所以把输出PWM声音的频率定时器的中断作为最高优先级对待了。那么实际处理定时器测量的话，对中断的要求就非常高了，尤其是中断处理的时间要尽可能短，才不会影响到声音的输出。当然了，这个问题也是之后需要花时间来分析和实验才行的。

关于这未完成任务的已完成的部分，已经有一些描述和视频对其功能进行解释和演示了，整理如下：
基本系统部分：
准备熟悉FR5969https://bbs.eeworld.com.cn/thread-447846-1-1.html
时钟和看门狗https://bbs.eeworld.com.cn/thread-448367-1-1.html

声音播放：
用小狼做播放器https://bbs.eeworld.com.cn/thread-451405-1-1.html

语音报时：
小狼，语音报时https://bbs.eeworld.com.cn/thread-452084-1-1.html

至于系统的照片……哎，咱这破手机，照出来也不聚焦，就不拿出来炫穷了吧。而且也没有什么外观设计，个人没啥本事，以上内容也就是随便做做，硬件不咋会啥，软件也就是捅咕捅咕，重在参与嘛，献丑了。

说实话，看坛子里那么多能工巧匠的，做出的东西可圈可点，我早都有心放弃了……不过一想到那样损失就更大了，于是才摸爬滚打的，熬到如今最后一天，有了这样一篇帖子，也算是坚持下来递交了考卷吧。