MDK升级后的头文件冲突
//=====================================================================
//TITLE:
// MDK升级后的头文件冲突
//AUTHOR:
// norains
//DATE:
// Friday 17-June-2011
//Environment:
// Keil MDK 4.2
// .NET Micro Framework Porting 4.1
//=====================================================================
因为在移植的时候，发现了不少MDK编译的一些问题，于是便想升级到最新版本，看看是否这些存在的问题已经被修复。可是没想到的是，在MDK 4.0可以顺利编译通过的.NET Micro Framework Porting Solution，到了MDK 4.2却是会发生编译错误，如图所示：
从图中可以看到，是usb_def.h文件出错，理由是某些类型没有被定义。像这种情形我们出来起来是很有经验的，十有八九是没有包含stm32f10x.h文件。也就是说，只要在包含usb_def.h之前包含stm32f10x.h文件即可，比如：
依照该思路，查找自己所建立的solution，才发现自己的代码中根本就没有使用到usb_def.h文件，而编译的时候却提示该文件有错！这究竟是怎么回事呢？
经过对比才发现，MDK 4.2版本的" /Keil/ARM/RV31/INC"路径下增加了USB的相关文件，而其中的"usb.h"就是追魁祸首！
为什么会如此呢？因为"usb.h"也是.NET Micro Framework Porting的一个代码文件，其位于"$(SPOCLIENT) /DeviceCode/pal/COM/usb"！而代码中为了使用.NET Micro Framework的USB资源，所以简单地如此包含了该头文件：
但在对solution进行编译的时候，首先搜索的是"/Keil/ARM/RV31/INC"路径，因此该"usb.h"便是"/Keil/ARM/RV31/INC/usb.h"，而不是"$(SPOCLIENT) /DeviceCode/pal/COM/usb/usb.h"。
那应该如何解决这个问题呢？最简单的方法可能大家都能猜到，直接将"/Keil/ARM/RV31/INC/usb.h"给删掉！当然，这个方法是可行的，但却感觉并不是那么完美。谁知道删掉它，会不会对别的方面有影响呢？这只是一个治标而不治本的方法。
其实还有更好的方式，在包含的时候，指出其相对路径即可。比如我使用"usb.h"这个头文件的源代码是位于"$(SPOCLIENT) /DeviceCode/Targets/Native/STM32F10x/DeviceCode/USB/"，根据之前所说的所需要的.NET Micro Framework Porting的"usb.h"是位于"$(SPOCLIENT) /DeviceCode/pal/COM/usb"，那只需要在代码中如此指出即可：
更改之后编译，顺利通过，如图所示：
