LPC54110 MP3解码+频谱

li--wei--hao · 发表于 2018-4-23 11:07:27

本帖最后由 li--wei--hao 于 2018-4-23 11:09 编辑

从社区兑换的LPC54110开发板到手后，一直想做个东西试试，之前用msp430f2132和VS1003做过一个mp3播放器，正好板载有wm8904解码芯片，所以便动起了做个软解码的mp3播放器，当然目前完成的部分只能算是完成了核心功能，细节部分并未实现。
我的开发环境如下：eclipse + gcc-arm-none-eabi-5_4-2016q3 + pyocd
keil版本也有，不过没有gcc版本完善
SDK版本为 SDK_2.3.1_LPC54114J256、FATFS版本为 ff13a
helix解码为网上找到的可用于gcc的一个版本
为了方便调度，然后加入了freertos。

下面简单说一下我在制作过程中注意到的一些地方，如有错误，还请大家指正。
1. status_t I2S_TxTransferSendDMA(I2S_Type *base, i2s_dma_handle_t *handle, i2s_transfer_t transfer)
这个函数调用后，通过观察SDK源码，应该是将要传输的数据送进了一个传输队列，队列容量默认为4，源码如下
i2s dma struct.png

I2S_NUM_BUFFERS 宏默认为4

2.根据上述发现，我在mp3解码过程中是这样处理的
QQ截图20180423101745.png

即第一次传输时直接传输就可以，由于我在这里使用了双缓冲，所以第二次及后续解码完成并送进发送队列后必须等上次数据发送完后再进行下一次解码，否则有可能导致数据被覆盖或内部错误，这也是我后来加入freertos调度的原因，否则这个while(!dma_flag)会造成很大的延时。

3.官方自带的25flash在地址处理的地方有错误，一度让我很郁闷。。。
QQ截图20180423100829.png

如图，下边是我修改过的
QQ截图20180423100838.png

至于为什么使用25flash，那是因为我闲来无事，想在液晶显示歌名之类的，所以需要存储GBK字库，这里使用的是12*12的点阵字体，此外为了方便后续扩展，加入了一个小型GUI µGUI ，虽然我也制作了ASCII的点阵字库，但这个GUI自带不同大小的ASCII点阵字体，所以就没有用到了。
为了将GBK字库写入flash，又写了一个简单的模块将字库写入flash,也就是app_makeflash.c这个文件了。

还有一个地方就是TF卡和25 flash共用一个SPI，同时使用TF卡和25 flash会造成片选冲突，所以我再源码中添加了这样一句，用来切换片选
QQ截图20180423105108.png

回到MP3歌名显示，需要使能FATFS的中文支持，但是unicode转GBK的表太大，所以将这两表提取出来做成了单独的bin文件，放置到TF卡就可以了，也可以放到flash，不过我有拖延症，一直也没有添加flash的支持代码。。。
QQ截图20180423103533.png

这便是两部分支持代码了，unicode转gbk部分的转换表是由我手动剔除和添加(花了好长时间。。。)了一部分空数据构造的，然后又用C写了个简单的工具生成了bin文件，而到gbk转unicode的码表，由于要添加的数量巨大，所以又写了个根据规则补充文本的小工具进行补充的，最后再转成bin文件的。
整理源码的时候发现转bin文件的源码找不到了

接下来就是频谱了，我使用的是ARM官方的DSP库，这个库在NXP官方SDK中也有，使用很简单，就是调用fft变换，然后根据计算结果刷屏就好了。实际效果如下。顺便提一句，这个屏幕是U盾上的，有兴趣的朋友可联系我或右转数码之家论坛寻找资料

对了，还有一个地方就是IIS的频率，为了计算PLL的频率和对应参数，我又编了一组根据M、N、P参数计算MDEC、NDEC、PDEC或者根据MDEC、NDEC、PDEC反推M、N、P以及计算SELR、SELI、SELP的小工具，下图就是我修改过的频率部分了，当然了，那个频率并没有精确到和44.1K完全一致，差距应该在1%之内吧(我也不是很确定).
QQ截图20180423104548.png