近期的项目需要在RTT下，使用SD卡运行FAT文件系统，而且还能通过USB将这个SD卡虚拟化成大容量可存储设备，在项目初期遇到了一些小问题，记录一下，防止别的朋友踩坑。
初始化后FAT头文件的包含问题；
RTT与CubeMX生成的其他模组文件的兼容；
测试平台：STM32F407VGT6
STM32CubeMX版本：6.1.2
HAL库版本：1.16.1
RTT组件包版本：3.1.3
FAT头文件包含问题
RTT与CubeMX其他模组文件的兼容
以往来说，笔者都是比较懒，都是像下面一样将各种外设的xx.h文件和自己写的一些xx.h文件都包含到main.h中，然后一些自定义的或者其他的.c文件直接包含main.h文件即可，这样的做法简单无脑。
但是在cubeMX生成的FAT工程里，将fatfs.h包含在main.h中就疯狂报错，具体如下：
我在网上查了半天，就看到了两个人跟我遇见的问题一样但是问而无果，所以这里把报错当做代码引用一下，增加编译报错关键字来让有同样问题的人搜到这篇博客。
error type>(36): error: #20: identifier "Diskio_drvTypeDef" is undefined
extern Diskio_drvTypeDef USER_Driver;
../FATFS/App/fatfs.h(37): error: #20: identifier "FATFS" is undefined
extern FATFS SDFatFS; /* File system object for SD logical drive */
../FATFS/App/fatfs.h(38): error: #20: identifier "FIL" is undefined
extern FIL SDFile; /* File object for SD */
../FATFS/App/fatfs.h(41): error: #20: identifier "FATFS" is undefined
extern FATFS USERFatFS; /* File system object for USER logical drive */
../FATFS/App/fatfs.h(42): error: #20: identifier "FIL" is undefined
extern FIL USERFile; /* File object for USER */
../Middlewares/Third_Party/FatFs/src/ff_gen_drv.c: 0 warnings, 6 errors
compiling syscall.c...
../Middlewares/Third_Party/FatFs/src/ff_gen_drv.h(57): error: #20: identifier "_VOLUMES" is undefined
uint8_t is_initialized[_VOLUMES];
../FATFS/App/fatfs.h(37): error: #20: identifier "FATFS" is undefined
extern FATFS SDFatFS; /* File system object for SD logical drive */
../FATFS/App/fatfs.h(38): error: #20: identifier "FIL" is undefined
extern FIL SDFile; /* File object for SD */
../FATFS/App/fatfs.h(41): error: #20: identifier "FATFS" is undefined
extern FATFS USERFatFS; /* File system object for USER logical drive */
../FATFS/App/fatfs.h(42): error: #20: identifier "FIL" is undefined刚开始我以为这样做没有问题，但是解决报错将近两个小时后觉得根据语法和编译原理的知识仍然没有解决，所以就尝试恢复到代码初始生成的状态。当我把头文件恢复到main.c以后就不报错了。
到此为止，就是因为头文件的不当包含出现的问题，这样让我想出了几个利害关系：
- 根据MDK的编译机制，如果写在一起，对其中任意一个头文件进行修改就会对所有包含这个头文件的.c文件进行重新编译，这样很费时间；
- 会让整个工程杂乱无序，不符合高内聚低耦合的程序设计宗旨；
- 对于程序的移植会出现各种各样想不通看不懂的问题；
- 对于开源程序来说会让使用者不利于阅读与部分移植；
虽然并没有分析出包含在main.h中到底有什么错误，但是也确实该改掉这种方式了，这个问题就到此为止吧!
之前一直使用的RTT只是用到了UART,TIM,IIC等简单的外设，这次一下子开了很多复杂功能就出现了一些问题。按照之前的RTT移植过程的配置都没出现什么问题，这一次配置完成后编译0error0warning但是shell界面只出现了版本输出，不显示msh>的命令行提示。
很快就锁定了问题所在，但是在此之前需要先介绍一下几个知识点。
- msh(或者说shell)实质上是一个进程，只要是进程就要参与时间片轮转调度才能运行，一个任务只要不让出cpu的使用权，其他任务就永远不会被轮到执行。
- RTT的任务调度与轮转是依靠单个任务中使用rt_thread_mDelay()函数，是使自己暂时挂起来让出cpu的使用权。
- Main函数实质上是一个进程，如果main不结束且者main函数中没有rt_thread_mDelay()让出资源或者在某一个进程中卡死，都会使程序卡死，导致其他进程无法使用cpu。
回到正题，msh配置没问题但是不显示说明目前的进程并没有让出cpu的使用权，进而说明程序在某个地方陷入循环或者卡死。进过Debug后发现程序卡死在初始化的MX_USB_DEVICE_Init()，这是USB的初始化，进而深入查找在其调用的USB底层文件看到了一个裸机开发熟悉的函数HAL_Delay()，就是他让程序卡死的。为什么呢？再来几个知识点。
- HAL库的HAL_Delay函数的原理是使用systick内核滴答定时器进行精准定时从而延时的，在裸机开发中经常使用到。
- RTT的时基定时器默认也是systick内核滴答定时器，通过这个定时器控制进程调度和时间片轮转，从而控制进程调度。由rt_thread_mDelay()函数进行调用控制。
所以在RTT系统中不能出现HAL_Delay函数，否则会使程序卡死。在MX_USB_DEVICE_Init()中的底层配置中调用了这个函数，因此程序卡死在这里。然后我又查了一下，我滴乖乖，SDIO和USB的操作中都不同程度的存在HAL_Delay函数，原因在于RTT与FAT一样属于第三方的软件包，不是ST官方的东西，所以在兼容性上与CubeMX生成的其他文件会有差异与兼容问题，不过由于HAL库的全面与强大，通常这种兼容问题都只需要进行小部分修改即可解决。
因为HAL_Delay()函数存在的地方不少，所以直接替换这个函数不太合适。所以我们直接修改HAL_Delay()的定义。在stm32f4xx_hal.c文件中，包含rtthread.h文件，然后找到HAL_Delay()函数，将函数体全部注释，因为rt_thread_mdelay()函数的传入参数与HAL_Delay()传入参数类型一致，直接加一句rt_thread_mdelay(Delay)即可；
或者由于HAL_Delay()是_week弱定义，我们可以直接在main.c中用户代码区重新定义一个void HAL_Delay(uint32_t Delay)，内容就一句话rt_thread_mdelay(Delay)；这样重新生成代码时就不会担心被删掉。
问题解决!!!
写在最后，未来几期博客就以目前的项目为Handle来写，涉及STM32外设开发，模块开发，RTT开发，项目完成的时候打算开源到gitee上，敬请期待。
