单片机程序架构

TO ：TOTAL：共11 页

CC ：DATE：

FM ：BILL ZHANG Ref No：

??????????????????????????????????????????SUBJECT：音乐天使UI界面程式设计总结报告

Contents :

一．前言

二．313系统软体简介

三．UI界面的组成及特点

四．音乐播放模式下UI处理

五．收音机模式下UI处理

六．心得报告

一．前言

本次专案开发的目标是在中颖86H313的音乐播放DEMO软体平台上，依照

SPEC实现按键控制播放/暂停，模式切换（一共三个模式：SD卡/USB音乐文件播放；数控收音机；LINE IN信号播放），搜台存台，音量控制等基本功能。

显示界面是5COM×７ＳＥＧ的ＬＥＤ，由四个８字及少数几个状态图标组

成。

本次使用的软体平台是demo code v５.６１版

二、 313系统软体简介

313硬体以8051MCU为内核，集成DSP/ADC/DAC等功能，这里就不再详述。313系统软体是由上海的列位高手同仁精心制作而成，结构清晰，功能齐全，并且还在不断完善当中，下图是系统软体的基本逻辑架构：

UI界面的处理是在APP应用层内进行的，涉及到对API和DRV的调用。良好的UI 界面应该是：尽可能少的独自占用RAM和ROM资源，尽可能少的改动系统软件结构，尽可能少的与API和DRV产生重复性关联结点。

系统软体的main()函数主要负责处理各个模式之间的切换，以及电池电压检测。音乐文件播放、收音机、录音、OTG功能等，统一通过sys_mode这个RAM为标志进出各自的模块，各模块在切换的时候，须先执行当前模块的标准退出流程，

使占用的资源得到完整释放，否则容易导致读取歌曲文件时超时等突发事件。

下面是main()函数的主要结构图：

因为晶振一旦通了电就是一直震荡不停止的，所以整个系统软体就是一个大的无条件的无限循环，这个无条件的无限循环里包含着数个有条件的无限循环，如: music_loop，退出条件是sys_mode的值不为MODE_MUSIC，而在这些无限循环分支里根据需要分配了诸多各种各样的有限循环，条件判断，数据搬运和对端口操作/信号释放。这些指令和语句组成了整个系统软体。

三、UI界面的组成及特点

UI（User Interface）即人机交互系统，是整个软体系统里专责解读来自外界（用户）的信号（操作指示），及时处理，并实时给予反馈（让用户了解状况）的软体功能模块。消费类电子产品UI的主要硬件组成有: 按键板、LCD或LED显示屏、喇叭，复杂一点的还包含有：遥控器、麦克风、传感器、陀螺仪、电机马达等。

不可缺的首先是界面，所有的反馈必须透过LCD/LED显示给用户，否则用户无法知道当前的状态，就不叫UI了。相对于信号的读取，信号的释放过程显得比较简单，不管是LED还是LCD，在RAM内存里根据点数建立一段显示BUF区，根据信号处理结果往BUF区里面写数，再定时从BUF区送往LCD/LED刷屏点亮就可以了。要注意的是刷屏的频率，除了达到人眼动态视觉特性条件之外，还考虑另外一个因素，举例：如需要显示秒表功能，那么刷新时间间隔必须小于100ms，否则将读不到秒表最小位的正确数值。

本专案用的是LED界面，不像LCD自带有硬件驱动模块，需要透过建立程式对IO口操作来实现。考虑到313底层在读取U盘的时候在主循环里会有长达1秒的停滞，这个时间片段，想要LED能做到实时变化，最后决定采用中断子程序里操作的方式。

UI系统的运行过程也就是对外界信号的处理过程，产生这种信号的因素主要有以下几个：

1.用户按键输入，例如：调节音量

2.某单一任务时间到Timeout，例如：当前歌曲播放完毕

3.端口状态变化，例如：拔插U盘

所以UI处理子函数的启动条件跟KEY事件有关，跟TIMER事件有关，跟IO 口状态事件有关。

四、音乐播放模式下UI处理

音乐播放模式music_loop主要是MCU与DSP混合应用，处理MP3等格式文件的解码和播放，需要的UI界面有：歌曲播放/暂停，前一曲/后一曲，快进/快退，当前是SD播放还是USB播放等。

为了跟系统软体里原有的music_proc_evt_timer()作个区分，在主函数music_loop 里面只添加music_ui_evt_timer()这一个功能函数，所有的UI处理都集中在这个函数和music_proc_evt_key()里。二者间存在因果关系，music_proc_evt_key()为因，music_ui_evt_timer()为果。

这里看个人习惯，添加music_ui_evt_timer()的目的是一点都不动到系统软体原来的内容，降低出BUG的风险，提高可移植性。当然也可以直接改动原来的函数music_proc_evt_timer()。

music_ui_evt_timer()函数框架图如下：

注意的是图中列出的所有分时操作事项的单次执行时间都不能超出20ms, 即不要有delay_1m(xxx)的函数调用，不然timer1~timer3的所有事件处理无法实现真正的实时。将会导致显示画面走时不准、按键不灵等现象。

timer1~timer3 是根据任务多寡的需要在100us中断计时子程序里另外设立的timer counter，跟20ms_timer同样性质。

五、收音机模式下UI处理

收音机模式fm_loop主要是对FM模组(这里是AR1019)的IIC控制，搜台状态读取。需要的UI界面有：当前频率画面，搜台画面，取台画面，音量画面等。

同理，在主函数fm_loop里面只添加fm_ui_evt_timer()这一个功能函数，所有的UI处理都集中在这个函数和fm_proc_evt_key()里。二者间存在因果关系，

fm_proc_evt_key()为因，fm_ui_evt_timer()为果。

fm_ui_evt_timer()函数框架图如下：

上面增加了一个250ms的time counter，是因为经多次调试发现，对于AR1019自动搜台而言，这是一个比较合适的时间间隔，在这个时间间隔能搜到最多的台，并且按任意键比较方便停台（因为键盘扫描是放在主函数里而不是中断处理，搜台间隔太短的话，时间片段都被AR1019占用，将没有时间做键扫描，导致任意键停台不灵）。当然，这个time counter的值也许还有更合适的，可以经过对fm模组的专业测试，多次进行调整，得出最佳结果。

自动搜台的每一个单步期间要确保AR1019占用的时间小于125ms, 不然显示BUF的数据将得不到及时更新。

六、心得报告

通过本次专案开发，加深了对中颖313芯片应用层面上的认识。过程中也遇到了一些如：插入U盘时显示画面僵住，转功能有POP声，盘内无歌曲文件的标志找不到，模式切换等问题点和难点，后经过反复调试得以解决。部分结果还待接受大家和客户的检验是否OK。

过程中曾经发生的一些错误是不够细心造成的，浪费了时间来查改，以后要加深认真细致工作作风的培养。

目前测到的从fm到music模式切换平均时间间隔为3秒（纯歌曲文件）。是否还能更快未来还需深入研究。

因时间仓促，本版DEMO软件可能还存在有不完善的地方，还需要经过部门的全面测试和验证，请多多给予批评和指正。

感谢陈SIR，沈工和刘工在过程中给予的帮助和宝贵意见。

AR1019的driver程式是黄巍提供的，以及一路上的指导。没有这些肯定还在摸索中，在此深表谢意。

报告人： BILL ZHANG