录音机调试第七天

关于毕设的一些调试感悟系列

这是此系列的最后一篇博客了，目前我已经完成了全部的调试工作，是时候欢迎我的小宝贝闪亮登场了，今天就花点时间，好好总结一下所有的调试细节。

核心思想：站在巨人的肩膀上啃食星空！（我可不是啮齿类动物哈哈哈!!!）

遇到一个项目之后，我们需要如何入手分析和开发呢？我的回答是，先从搜集资料开始，一定不要闭门造车，这是其一；其二是要学会利用手头的工具进行试探性验证工作，比如一些板载的资源和开发板供应商提供的开发例程，从程序中学习开发常用的函数库和必备的编程思路；其三是要勇于实践，在失败中不断总结思路，有时候遇到了问题，可以放上一段时间，这可不是放弃治疗，而是需要换一个思路，或者换一个状态，重新出发。当然了，如果你要是有兴趣，可以把自己的热情凝聚在自己的开发之路上，我之所以想一直持续的更新这个博客，是因为我不想看到下一个遇到问题后，就手忙脚乱的你，因为曾经的我，也和未来的你一样，对于未知充满了暂时性的恐惧，但作为技术人而言，永攀高峰，向着为人类带来美好的光明之路出发。

这里也提醒一下诸位技术人，如果像我一样，有技术迭代的需求的人，请不要把自己的任务进度放在这个平台，因为我上一次的博客，自己和自己博客内容有重复，还得改成转载，才可以再次发表，虽然经历了重申，最后才得以面世。赌一赌，这一篇能否发出去呢？全凭缘分。

1.硬件平台的搭建

用的是正点原子的硬件平台-阿波罗(STM32H743)，所以基本不用再额外调试硬件系统，只是程序调试上需要再花一些时间进行调整。

设计的硬件系统包括LCD屏的显示、麦克风模块和SD卡存储模块

暂时发现需要改进的地方包括以下几点：

（1）对于TFT屏的显示

之所以要改进屏幕显示，是因为要完成软件运行状态的显示和做一个音频的频谱分析。之前还担心这个TFT屏和LCD屏的处理上会有一些故障问题，得亏正点原子，已经把两个硬件的库做了兼容性处理，但这个代价就是舍弃掉7寸屏大小，只能显示到和LCD屏一样的大小（分辨率：800*400）。经过测试，也发现，如果写的分辨率超出了这个范围，则不会显示，屏幕会和背景色保持一致。

（2）对于SD卡的文件管理系统的调整

一开始打开工程，映入眼帘的是内存管理函数的部分，所以脑子里第一个念头便是一定要改文件管理架构，不然无法在录音程序执行完后，自动挂载music文件夹，从而丧失掉对于乐器的模拟发声。所以更改文件管理程序，需要熟悉C语言中对于文件的管理的函数。而我对于系统层级的软件管理还是一知半解，无法从软件上进行功能的实现，所以我又探索出了第二条思路，就是借助硬件系统，进行强制转换，需要设定GPIO引脚的方向为输入类型，电平是接3.3v。

故可以这样实现，将两个例程放在一起，用单片机的一个管脚作为输入信号的标志位，从而让单片机执行不同的程序。但要求单片机在功能切换的时候，都必须进行一次复位操作，保证正常的功能切换（模拟出音频播放的功能来）。本质是想实现资源的分时复用，将不同的程序根据自己的实际需求进行手动的功能切换，股也可以理解为是隔离式设计。

如果这样，那我也可以进行频谱的显示，从而来实现对音频信号的频谱分析结果。

（3）对于麦克风模块的工作模式的理解

刚接触的时候，一直叫做麦克风模块，后来随着学习的不断深入，逐渐知道了这个WM8978本质上是一个集成数据采集，编码和解码功能的芯片，而真正用到音频处理这个领域，是因为外部设计了麦克风和扬声器，才保障可以正常的音频录制和音频播放功能。至于具体的编解码的格式和数据的传送方式，以及设定目标格式的命令字都是需要提前在程序中进行声明处理。

2.软件系统的调试

软件系统包括的任务是硬件系统中的驱动程序的编写和使用DSP库对采集的声音信号进行显示：高级一点的话，需要使用低通滤波器，对于高频噪声进行滤除。上述的内容是最初接触的时候，我的想法，后面随着调试的不断总结，对整个软件架构进行了重新的设计，首先是整体上分为两块，一部分是音频的播放，另一部分是音频的采集。利用外部的接口对程序中的两部分进行了隔离处理，在进行频谱分析的音频采集时，总会丢失掉一些关键性数据，索性对于频谱分析的功能也进行了硬件的隔离设计，故是一种总分结构。

1）TFTLCD屏-7寸 RGB TFTLCD

通过比对单片机的LCD屏和RGB屏的显示处理过程，明白了开发板为了兼容两者，在底层库文件的开发上做了取舍，统一将屏幕缩放到400*800的分辨率上，所以现在看到的显示界面是只有部分的显示。对于屏显，其实就是对每个像素点进行逐个赋值，然后进行统一的显示，好在正点原子已经完成了底层硬件的适配，所以作为开发人员，重点是学会对于库函数的调用，即可完成完成的设计。

2）麦克风模块-WM8978

作为开发板上的板载资源，它的存在，确实是可以提供一个更多可能性的平台，特别是对于音频文件的处理上，也是得益于野火的资料，才让这样一件事情变得十分的容易。利用好这个芯片，不单单是要完成文件保存格式协议的理解，还包括对于单片机内部资源的调用，比如DMA，这样可以将采集到的数据直接写入到存储设备中，又考虑到写入的速度可能不够理想，又在程序执行过程中进行了数据的缓存设计，保障数据的完整性。

3）SD卡存储文件的管理

SD卡单纯只是一个存储设备，给啥写啥。写入的音频数据是已经过WM8978完成了编码处理的格式化的文本，所以如果要提取音频文件，必须从WAV协议入手，知道音频数据究竟存在了哪里，要如何获得。而读取音频数据的过程是对SD卡中所存储文件完成解码的过程，本程序中使用的是WAV格式。想玩好存储设备，必须要搞懂文件的管理架构，知道知道文件的写入函数，文件的读取函数，读和写的过程中是否会干扰后续的操作。

3.暂时的安排

1）读一读正点原子的开发资料，理解例程中的数据传递的流程

现在不单单是这个项目，需要明白数据的传递流程，任何一个项目都必须知道数据的流向，这样才能明白当前和未来的处理过程。理清数据的传递过程才是调试的根本出路。

下面是两个开发板提供商的开源资料：在这里表示万分感谢！

野火

原子

从上面的实验教程中挑选如下的五个实验进行应用性学习:

遇到一个项目，不能是完整的学习，搞清楚每个环节，每个函数，每个定义的出处，这个对于技术党来说，可不是适用的，我们的期望是短时间内进行高效的学习，遇到一个新问题或者技术难题，可以通过一个短期的探索，进行试探性解决，而且这个时间越快越好。而对于深挖技术背后的逻辑，发掘下一代技术的突破点，则需要明白技术诞生的历史，底层逻辑，应用范畴，未来发展等，从而制定出下一代的标准。所以我才把这些实验都叫做学习的样本，需要进行应用性学习，能够用起来，用得好，就是一个进步的标志。

（1）音乐播放实验

这个实验是完成了对于乐器的模拟发声，本质上是对于存入的数据，进行DAC转换后，接入扬声器，从而实现音频的播放。但好巧不巧，这个WM8978已经集成了内部的16bit的DAC，并且还可以对WAV格式文件进行解码处理，从而还原出音频。

学习利用SAI使用I2S协议驱动wm8978

通过DMA进行数据的传输：用SAI 的子模块A，其TX 是使用的DMA1 数据流 5 的通道87 来传输的；并且将DMA2 数据流3 设置为：双缓冲循环模式，外设和存储器宽度相同（16 位/32 位），并开启DMA 传输完成中断（方便填充数据）。给缓冲器填充数据需要在传输完成一次后，在中断中调用这个函数 sai_tx_callback();

wav_play_song函数，是播放 WAV的最终执行函数，该函数解析完 WAV文件后，
设置 WM8978和 I2S的参数（采样率，位数等），并开启 DMA，然后不停填充数据，实现 WAV播放，该函数还进行了按键扫描控制，实现上下曲切换和暂停 /播放等操作。该函数通过判断wavtransferend是否为 1来处理是否应该填充数据，而到底填充到哪个 buf saibuf1或 saibuf2则是通过 wavwitchbuf标志来确定的，当 wavwitchbuf=0时，说明 DMA正在使用 saibuf2，程序应该填充 saibuf1；当 wavwitchbuf=1时，说明 DMA正在使用 saibuf1，程序应该填充 saibuf2

上图是DMA进行双缓存的执行逻辑过程，而双缓存的设计，正好适应了对于左右声道音频的数据处理，在16bit的数据存储上，其实是传递的音频数据是左左右右左左右右这样的数据格式。

上图是I2S的通信需要配置的信号引脚定义。

（2）录音机实验

这个是我认为最需要关注的一个实验了，因为开发板自带的例程已经可以完成音频的采集和播放，并且可以将音频文件进行存储，这样我就诞生了对于数据处理的新的理解。这里也提醒一下各位技术党们，以后项目中遇到了存储模块，可以从存储的写入和读取的部分，进行数据的拦截，或者叫做数据的采集。万变不离其宗，数据也是有入有出的，守住了大门，啥人都能碰到，在技术层面更是如此。所以我最终是在数据写入SD卡之前，对数据进行了频谱分析。这里也得感谢正点原子，将数据的存入过程，分为了命令块和数据块两个部分，从而方便了对于采集得到的音频进行获取和分析。

（3）SD卡的存储实验

因为FAT文件管理的执行过程，所以我选择绕开了这个模块，数据该存接着存，我只是在存之前进行数据的处理，处理过后，存储的还是原始数据，而频谱的分析的数据就是之前采集过程中的数据。得力于STM32H743强劲的性能，没有让我在时序上多花费一分一秒。STM32 YES!!!

（4）DSP实验

算是STM32单片机内部集成的一个硬核，可以完成一些复杂数学函数的编程和计算，而这里使用到了其中的FFT变化，对于采集的音频数据做一个频域的分析，市面上的对于音频文件的频谱分析，基本都还用的是这一套逻辑。而其配置过程也是十分的友善，具体的可以参看后面挑选的参考设计的博客。

（5）RGB TFT显示实验

​ 调用单片机的LCD屏和TFT屏的函数库的封装是否一致呢？现在可以明确回答，是一致的，但是为了兼容性，也做了一些舍弃，就是只能显示400*800分辨率的范围。

（6）DMA数据传输实验：理解双缓冲含义

​ 编码后的结果，会直接由DMA传输到内存，只有等256点全部传输完成才会进入到DMA的传输完成中断，这样保证了每个采样点的间隔时间都是一致的。

​ DMA发送完成中断指的是每次指定字节发送完成后便产生一个中断。这个可以从DMA初始化的环节，进行字节数目的确定。

​ 为了方便接收音频数据，我们使用DMA 传输完成中断，每当一个缓冲满了之后，硬件自动切换为下一个缓冲，同时进入中断服务函数，将数据暂存到自己建立的缓冲FIFO，将FIFIO的内容借助写入函数写入到SD 卡的wav 文件。所以可以参考一下这个设计思路，在需要紧急存储的数据的时候，可以先对数据进行本地的在线缓存，然后再借助有限的发送单元，将数据发送出去。想到去年那个设计，对于NRF24L01而言，其一次性最多能只能发送32个字符，所以如果直接传送这么多，会让数据丢失很多，如果当时要是建立一个缓存单元，传一个，我发一个，这样，不就想发多少发多少了。也避免了对于数据包，进行分帧接收。之所以要避免分帧处理，是因为，如果需要对数据进行编帧，那么可能涉及到数据传送的先后次序。要求数据必须对等，是一个标准的结构，每一帧多少，如何开启下一次的传送以及本次传送是否完成等等问题。

对于数据传输的梳理如下：

首先声音信号经过麦克风模块，完成ADC转换（了解ADC转换过程），将采集的信号按照（理解转换后的数据存储过程）存储到SD卡中，进而完成音频信号的采集；对于音频信号的播放，主控首先从SD卡中读取（理解从SD卡中读取数据的过程）对应扇区的数据，然后对读取到的数据进行DAC转换(对读取到的数据进行DAC转换的过程)，然后把转换后的电压值输送到麦克风集成模块中。

之所以要如此苛刻的关注数据的每一步动态，其实是为了知晓从何处截取数据，才不会干扰整个系统的运作过程。那反过来想，如果数据都跟踪不对，那如何才能对数据进行正确的处理呢？

故而在阅读例程中需要解决两个问题：

（1）麦克风模组对于音频信号的采集方式

​ 内部ADC的转换完成后数据的处理过程：

​ 内部DAC的转换完成后数据的处理过程：

WAV是微软公司开发的一种音频格式文件，用于保存Windows平台的音频信息资源，它符合资源互换文件格式(Resource Interchange File Format， RIFF)文件规范。标准格式化的WAV文件和CD格式一样，也是44.1K的取样频率，16位量化数字，因此在声音文件质量和CD相差无几！ WAVE是录音时用的标准的WINDOWS文件格式，文件的扩展名为“WAV”，数据本身的格式为PCM或压缩型，属于无损音乐格式的一种。

WAVE整体结构如表 WAVE文件结构 ：

data chunk是WAVE文件主体部分，包含声音数据，一般有两个编码格式：PCM和ADPCM，ADPCM(自适应差分脉冲编码调制)属于有损压缩，现在几乎不用， 绝大部分WAVE文件是PCM编码。PCM编码声音数据可以说是在“数字音频技术”介绍的源数据，主要参数是采样频率和量化位数。绝大部分WAVE文件是PCM编码。

PCM编码声音数据可以说是在“数字音频技术”介绍的源数据，主要参数是采样频率和量化位数。

看到这个PCM编码，全称是Pulse Code Modulation,即脉冲编码调制。可以说是对于市面上的数字通信协议的一个高度总结性概括，这个协议既可以理解为是标准的通信协议，也可以理解为是自由协议，由收发双方按照一定的电平标准，对于数据进行适当的编码，完成数据的传输工作。

前天的分享可能有点稀疏，大体是因为数据在麦克风模块内部转换完成后，就会直接从DMA中转移到SD卡中，在转移过程中，采集的数据会被WM8978模块进行PCM编码，然后数据被以WAV格式存储到SD卡中。故而分析数据，必须从SD卡处进行数据的获取。按照之前WAV格式的编码，我们知道数据被放在文件的最后，有一个统计数据大小的标志符（后者有一个DATA的标识符），它的后面是采集得到的所有音频源数据。

在WAV编码程序中利用如下函数获得数据在存储卡中的起始位置：

wavx->datastart=wavx->datastart+8;		//数据流开始的地方.

除此之外，我还需要知道目前在程序中采用的采样率和采集的数据位数是多少：

采样率: 44.1kHz

采集的数据宽度: 16bit (采集信号的实部) （对于虚部直接赋0）

上图是理解WAV格式中对于16bit编码的音频源数据是如何在存储卡中进行存放的规律展示，即左左右右左左右右……，其中每一个字代表一个字节。

采集的数据量: 4096

对于已经实现的DSP频谱分析中采用的上述参数是多少：

采样率： 1024hz

采集的数据宽度： 32bit //需要对于采集的数据进行编码

采集的数据量： 1024

关于f_write函数你知道多少呢？下面是它的参数定义

 FRESULT f_write (
        FIL* fp,          /* [IN] Pointer to the file object structure */
        const void* buff, /* [IN] Pointer to the data to be written */
        UINT btw,         /* [IN] Number of bytes to write */
        UINT* bw          /* [OUT] Pointer to the variable to return number of bytes  written  */
);

（2）SD卡在程序中对于数据的存储方式

​ 在SD卡中进行数据的读取：

​ 数据的读取部分，因为还涉及到一个音频播放的功能，所以暂时先不打算通过读取接口 来实现声音原始数据的获取。

​ 在SD卡中进行数据的写入：
例程中通过下面的函数来对SD的写入数据，所以想在这里对写入的数据进行分析。

​ 那目前在程序采集过程中对于采集的音频数据无法完整播放，大概率是因为FFT处理过程， 会干扰数据的写入过程，那我需要再深入了解一下这个音频数据的写入过程中，发生了什么事情？？

​ 大概率是因为处理的时间过长，导致数据在存储过程中发生了覆盖，导致一些数据丢失了，从而使写入的数据远小于采集到的数据，在播放环节也无法完成对于的回放，说明了我需要降低调整频谱分析的点数，目前的频谱分辨率是40Hz，即在屏幕上看到的频谱显示的间隔是40Hz。

*res=f_write(f_rec,pdatabuf,SAI_RX_DMA_BUF_SIZE,(UINT*)&bw);//写入文件

​ 我是通过上述的函数，完成了对音频数据的获取，而这个函数是将采集到的音频数据文件写入到SD卡中。注意是音频文件中的数据部分，而不包含音频文件头命令的部分。故而我称之为走进去的门。春春你看，这里，我们就已经走进了数据的大门了。

2）可以在网上寻找STM中DSP模块的使用

后续的安排是，转换过程中，数据的输入方式和转换过程，前提是了解到上述采集模块对于数据的处理方式。

可以先尝试把例程中的幅度谱先调试出来，然后再考虑数据的流向，从而只需要更改数据的输入端就可以了。

操作如下，将F4的显示程序，直接搬到H7的平台上，进行平台的移植。

参考网址一：https://blog.csdn.net/hduxiejun/article/details/46287341?utm_medium=distribute.pc_relevant.none-task-blog-2%7Edefault%7EBlogCommendFromBaidu%7Edefault-17.control&dist_request_id=&depth_1-utm_source=distribute.pc_relevant.none-task-blog-2%7Edefault%7EBlogCommendFromBaidu%7Edefault-17.control

close all; %Turn off all the pictures 
clc;      
% DC=1;   %The magnitude of the dc signal 
% Amp1=1; %The amplitude  of the first signal 
% Amp2=3; %The amplitude  of the second signal 
% Amp3=5; %The frequency of the third signal 
% Fre1=10;%The frequency of the first signal )
% Fre2=40;%The frequency of the Second signal 
% Fre3=80;%The frequency of the third signal 
Fs=40960; %The sampling frequency
N=4096;   %The sampling points 
t=[0:1/Fs:1]; %Sampling time
% S=DC+Amp1*sin(2*pi*Fre1*t)+Amp2*sin(2*pi*Fre2*t)+Amp3*sin(2*pi*Fre3*t); %信号
S=[

]
%Display the original signal
subplot(3,1,1);
plot(S,'b');
grid on;
xlabel('                                                                       Frequency/HZ');
ylabel('Voltage');
title('The original signal');
Y = fft(S,N);    %Do FFT transform 
Module = (abs(Y));   %:Acquire modulus
subplot(3,1,2);
F=([1:N]-1)*Fs/N; 
h = stem(F(1:N/320)/10,Module(1:N/320),'fill','--');
set(get(h,'BaseLine'),'LineStyle',':')
set(h,'MarkerFaceColor','red')
grid on;
xlabel('                                                                       FFTout[i]');
ylabel('FFT module');
title('the module value of FFT');
Module=Module/(N/2);  
Module(1)=Module(1)/2;
F=([1:N]-1)*Fs/N; 
subplot(3,1,3);
h = stem(F(1:N/320),Module(1:N/320),'fill','--');
set(get(h,'BaseLine'),'LineStyle',':')
set(h,'MarkerFaceColor','red')
grid on;
xlabel('                                                                       Frequency /HZ');
ylabel('Voltage');
title('Amplitude - frequency curves');

note: plot(x) 当x 为一向量时,以x 元素的值为纵坐标,x 的序号为横坐标值绘制曲线。

可以借助MATLAB的程序来理解博主在单片机中实现FFT的处理过程和相关信号的定义。补充一下，之所以会把这个老哥的MATLAB程序搬到这里，完全是为了正确的理解FFT处理过程在单片机内部的运作过程，因为原博文并没有提供完整的工程信息，所以只能通过这个MATLAB程序来理解执行逻辑。我可这是个鬼才，，，，哈哈哈！！！

参考网址二：https://blog.csdn.net/ysudykx/article/details/79515134#%E7%BB%93%E6%9E%9C?utm_medium=distribute.pc_relevant.none-task-blog-baidujs_title-4&spm=1001.2101.3001.4242

参考网址三：

https://www.cnblogs.com/menlsh/p/4154070.html

采样率： Fs

采样点： N = 1/Fs

频谱幅度： 直流是原来的N倍，交流是原来的N/2倍

基波频率（采样分辨率）： f = Fs/N 即显示频谱是的频率间隔

基4采样： 输入的点数必须是4^n 即(16/64/256/1024/4096)

上述是为了理解FFT变换中对于一些需要自定义的参数的理解。懂了这些参数，才能在最后的频谱分析和显示设计上做到心中有数。

为了做好显示部分，需要掌握在LCD屏上进行画线和画矩形的函数，下面是例程中用到函数的参数定义：

 //画线
       //x1,y1:起点坐标
       //x2,y2:终点坐标  
       void LCD_DrawLine(u16 x1, u16 y1, u16 x2, u16 y2) 

//在指定区域内填充单个颜色
       //(sx,sy),(ex,ey):填充矩形对角坐标,区域大小为:(ex-sx+1)*(ey-sy+1)   
       //color:要填充的颜色
 void LCD_Fill(u16 sx,u16 sy,u16 ex,u16 ey,u16 color)
 // LCD_Fill(0,240,0,260,WHITE);

经过一番苦心钻研，可算是把频谱分析的图像做出来了，在验证环节，可以先自定义一个输入信号，如果对自定义的输入信号进行FFT变换和显示界面的设计，验证成功后，将输入的信号源换成采集到的音频数据，就可以完成频谱的显示工作了。在这里我遇到了两个问题，需要记录一下，其一是对于显示界面的设计，其二是对于采集的音频数据的处理。

问题一：显示界面如何设计？

按照我对网上的资料的查询和学习，发觉这个显示环节是没有固定的章法的，为毛呢？因为每个开发者手头的硬件资源条件存在差异，比如：屏幕的大小，屏幕的显示方式呀；软件部分也是存在差异，比如：不同的芯片对应不同的封装函数，采集的数据类型不同，显示要求的范围，显示的频谱分辨率不同等等。最后结果是，回过头来，还是得用德胜大大的话，以事实为依据，运用辩证的思维来解决当下的问题，我的解决办法是按照采集的数据量的幅度和大小，进行分类对待，如果数据的幅度比较小，数据量也比较小，可以用串口打印出数据，然后用肉眼进行数据的幅度缩放和设定规定的显示分辨率；而幅度大且数据量巨多，则可以用串口打印出要处理的数据，然后用MATLAB进行仿真设计，确定好需要滤除的数据和显示的范围。

问题二：对于SD卡中的原始数据该如何处理呢？

按照WAV文件格式的编码，我们已经知道原始数据在源文件中的存储位置和存储的方式，所以左右声道中，我们只需要处理一个声道，然后将采集的数据还原为16bit的形式，然后才能经过FFT的频谱处理。如果大家在这一点的处理上有问题了，可以给我留言，我会对你负责的。。朋友！

最后再思考一个潜在问题，按照奈奎斯特采样定律，采样率是输入信号频率的两倍以上才可以，而输入信号的频率是100Hz~2kHz，故需要处理的数据是4096个。

3）确定调试方案的步骤

目前有两个思路来解决这个FFT转换，思路一是借助SD卡作为数据转换的媒介，需要先完成ADC转换，然后把数据存储到SD卡中，然后调用DSP中的FFT函数，依次对采集的数据的进行处理，然后并且把数据存储到另一个扇区。思路二是直接在程序中定义一个数组，然后调用FFT对数据进行处理，完成后，把数据直接存储到SD卡中。

我最后选择的是思路三，奈何STM32H743的性能实在是有点过剩，就这么在线处理结果，然后在线显示，依然能够坚挺的运行，我也是被粉了一波。爱了呀! 不禁要喊出那句 STM YES !

接收数据的方式有两种，一种是在DMA中断中，进行数据的存储，因为用的是双缓存，所以需要注意的接收次序。另一种是在SD卡中，在声音播放的位置，把声音都读出来，然后进行数据的分析。

而事实是在数据在写入SD卡前进行了数据的获取，并不是在DMA和播放环节获取的数据。在得到数据后，一度以为这不是真正的数据，所以用串口打印出数据后，用MATLAB进行了实验性验证，发现是音频数据，那我就可以放心大胆地调试后续的FFT处理环节了。开心呐！处理步骤：

第一步，先用串口将采集到的音频数据，进行串口打印显示

实验的数据：

利用之前的MATLAB对采集的数据进行初步分析，还算可以。

第二步，随后根据采集的音频数据，按照采样分辨率进行数据的频谱分析

前天目标是完成程序的DSP部分的全部调试，期望能从matlab中找到合适的参数，来最终分析采集得到的音频数据。所以详细的安排又可以分解为如下步骤来完成：

（1）先进行测试性验证工作，目前已经完成了左声道数据的采集工作，并且将数据用串口进行了打印输出，并用MATLAB进行了初步的验证

（2）完成整个程序框图的搭建，重点是整合DSP库、音乐播放器和录音机三个例程，并且分别验证各自独立的功能效果是否符合预期

备注：目前的问题是在FFT处理过程中采集的音频数据，无法实现完整播放。但是根据前期的经验，如果减少待处理的数据量，反而会将数据正确写入文件。故需要调整好合适的参数，实现数据的正确存储。

（3）对采集的数据进行深度分析，并从中得到有用的信息，目前的频谱分析是以40Hz为间隔进行的显示处理，并且将采集的音频文件进行部分的回放，对于基本的功能，也完成了设计。

第三步，将MATLAB显示的频谱转移到LCD屏幕上

（1）下图是经过MATLAB进行初步调试的频谱图，大概会是这样的设计。之所以高频在右边，是因为我处理的是后一半数据；假设处理前一半数据，则预期显示的结果会是幅度高的在左边，低的在右边。

接下来我会验证前一半数据包含的信息是否是右半平面的数据，而如果是，则对右半平面的数据实现TFT屏的显示设计。具体的仿真验证结果如下：

如上图所示基本符合任务需求，那么重点来了，如何把这个图像搬到TFT屏上呢。结合前面提到的问题一和问题二，完成了频谱的显示工作。

最后是将整个频谱搬移到TFT屏上，如上图所示，大概率会是这样的显示界面。

（2）完成各个分立功能（录音功能，频谱显示，音乐模拟播放）的验证和测试。

4.工作总结

很高兴能见证这个小玩意的诞生，幸福呀，宝贝。

感谢正点原子

感谢野火

感谢STM32H743

感谢孙同学！！！哈哈 : )

感谢永不放弃的自己！