Blog's Home

一、KEIL MDK有时编译生成的烧录文件有问题

最近因为这个编译的问题折腾了整整两天，每天都加班，搞得头大如斗，这个必须是要记录总结一下。一开始本来工程中使用了LFS文件系统，但是实际测试中，发现这个LFS对写SPI FLASH耗时非常的长，比如说正常写入只需要1s，加了这个LFS，耗时需要4s，整整是原来4倍的时间，这一点不细说这个LFS的问题，然后就是准备把LFS从代码中去除掉，于是花了两三天时间，费了挺大劲，终于把它去掉了，换成了直接读写SPI FLASH的形式，测了确实是没有问题，但是这个时候，问题来了：这个修改后的工程编译生成的文件完全是不正常的，现象是会造成DSP控制出错，然后DSP一直是个异常的，不知道为啥异常，对比来对比去，确实没有发现问题，于是只好拿原来可以运行的工程和现在的工程对比，把两个工程通过SPI发送给DSP的命令数据全部打印出来做对比，果然这个思路是对的，虽然花了很大的力气，但是确实发现两个工程打印出来的数据在某些模块的控制上，命令数据完全对应不上，不仅是内容对应不上，而且长度也对应不上，因为两个工程对于DSP的控制是完全一模一样的，不可能存在这么大的差异。于是调试看，在调试中发现，异常工程在某些模块的DSP控制过程中，取保存在MCU FLASH中的常量数组中的数据时，取出来的数据竟然完全是错误的，取出来的数据和数组中实际放置的数据完全不一样，那么就是这里出问题了，会什么会有这样的问题呢？问了老司机，他说他以前就有碰到这样的问题，应该是编译器的问题，导致编译出来的文件有问题，于是我把那个常量数组定义的源文件稍微改了下然后编译再下载进去，果然调试看数据就对了，于是乎，我就把整个工程的所有文件全部重新编译，然后生成的烧录文件下载后，再把发给DSP的命令打印出来，果然，这下和那个正常的工程命令是完全一样的。TMD，浪费了我一天半的时间，搞得心贼累，最后发现是编译器的问题，好像具体是因为有些文件改了但是编译器没有重新编译，它这个编译是按文件的时间来判断是否需要编译的，不知道怎么的，然后编译出来的文件可能不是全部的最新的源文件编译的，所以对应不上，烧录进去程序跑起来就有点莫名其妙的错误。这下好了，找到问题了，因为这个工程不是最新的，只是为了用来找这个问题的原因，所以没用最新的，而是用了去除了LFS但是又和之前的工程差异尽量小的工程，也是为了保持尽可能的小改动，这样方便定位是哪些改动导致的问题。然后，我就把最新的工程，照着前面的处理方式，既对那个放置常量数组的文件做了小改动重新编译，然后又把整个工程的文件全部重编译了一遍，这样应该总没问题了，然后烧录进去，尼玛，DSP仍然有问题，也是和之前那个异常工程一样的问题，唉，叹口气，真的是服了，没有办法，只好像上面一样，再次把这个工程发给DSP的命令数据打印出来，发现仍然是那几个模块的数据不一样，长度也不一样，但是因为这个相比之前的工程，改了DSP的LIMIT，所以有差异是正常的，而且长度也确实是变长了，所以综合分析这些命令数据也是没问题的，那么问题出在哪呢？实在是没辙了，只好把工程发给了老司机让他帮忙看看，他重新编译生成烧录文件烧录进去后，竟然是正常的，没有问题，不过此时因为换了台机器，难道是硬件板子的问题，于是我又拿回来，重新烧录了进去，然后发现仍旧不正常，这就奇葩了，我这边编译生成的文件烧进去就是异常的，他那边编译生成的烧进去就是正常的，这TM，而且这个工程我是全部重新编译过了的，然后老司机说，把之前生成的.obj的中间文件全部删除掉，然后再全部重新编译看看，我照做了，编译完后再烧进去，靠，正常了，反复测了下，确实正常了，这也太离谱了，又TM是编译的问题，真不知道该说什么了。本来之前的工程是全部重编译后就正常了，现在这个工程也是全部重编译了，但是生成的文件仍然有问题，直到把所有的原来生成的中间文件全部删除再重新全部编译后，烧录文件才正常，唉，这也太那个了，这样搞的我很崩溃，这编译这么多的问题，因为这个鬼问题，花了我整整两天，真是是日了狗。

一、协议类

1、USB协议：

常用的HID协议，可以用做通信，如鼠标设备、键盘设备。

常用的MSC协议，大容量存储，一般就是U盘功能。

AUDIO协议，这个其实也是常用的，用于USB音频数据的传输，如声卡设备。

2、TCP/IP协议：

目前互联网使用的网络协议，这个比较复杂，内容也多，不说要深入的理解，但起码要有个整体性的了解，比如TCP协议、UDP协议、DHCP动态主机配置协议这些常用的，要比较的了解其原理。

1、在产品的设计上，还是要考虑全面一点，尤其是特殊情况的处理。比如说更换了MCU芯片，新的固件和旧的固件就要限制不能互相升级，或者说不能让它升死，这样就可以避免使用旧MCU的机器升级新固件导致变砖要返厂维修，新MCU的机器升了旧固件导致变砖要返厂维修，这样不好，用户体验不好，别人也会说你做出来的东西怎么连这样的情况都没考虑到。

以CS4272为例，其实也没啥太多的东西，就几点。

1、确认时钟是否正常，即MCLK、SCLK、LRCLK这三个时钟是不是都是正常的。

2、确认MCU的SPI通讯是正常的，这个可以用示波器探一下看看就知道了。

3、如果上面两项都正常，那么4272应该是能够正常初始化的，只要正常初始化后，即使没有输入信号，其SDOUT脚也是会输出波形的，所以用示波器探一下这个脚，有波形了，则说明4272已经在工作了。

4、最后的话，可以直接将4272的SDOUT与SDIN短接，这样ADC部分的数字输出即接进了DAC部分的数字输入，然后输入一个信号进4272，则4272会输出一个同样的模拟信号。这里也是用示波器，一是探一下进来的信号是否有，然后进ADC输入引脚前的信号是否正常，然后DAC输出引脚是否有信号输出，有的话基本就没问题了，单独4272这部分就通了。

使用source insight 4.0版本查看代码时，发现存在有文件中文显示乱码的问题，也不是所有的文件，就是有一部分文件会这样。

解决方案如下：

File->Reload As Encoding，将编码格式由GB2312改为ASCII UTF-7，再Load，这样中文显示就正常了。

私人文章，登录状态下方可查看。

先上张图，图中画出了S/PDIF数据的组织形式。一个S/PDIF块由192个数据帧组成，每个数据帧由两个子帧组成，每个子帧共32位数据：前4位为前导码，次4位为辅助数据，8-27位共20位为音频采样数据，V为有效位，U为用户位，C为信道位，P为奇偶校验位，具体描述如下图。

1、LCD1602/2402的第3脚，是决定屏幕偏压，也即对比度的脚，一般会接个电阻到地，大小一般是1K，如果接大了，比如10K，则对比度会很低，屏幕字体显示根本看不出来，只有淡淡的痕迹。

2、AT32F413的MCU，在使用MDK编译器开1级优化时，原来可以用的LCD1602驱动，居然会导致乱码，然后改回0级优化时，就又不会乱码了，估计还是个时序的问题。

3、脉冲编码器/电位器的使用，不同的型号，其旋转产生的脉冲波形是有差异的，自然程序也要跟着调整，一般接示波器看看就知道怎么改了。

私人文章，登录状态下方可查看。

多的就不说了，今年IC严重缺乏，ST的MCU更是水涨船高，迫不得已需要更换为国产的MCU，选择了ARTERY的。

原MCU为STM32F103RCT6，更换为AT32F413RCT7，pin to pin的，然后FLASH和SRAM大小一致。以下为移植过程中需要注意的点。