标签: mdk

  MDK5的Pack下载地址 http://www.keil.com/dd2/pack/ 留个标记 方便 大家使用

         本人使用 keil 5 有一段时间了，发现 keil 5 真考虑周到，里面驱动库也帮你准备好了。这个新功能可以节省我们的时间，也可以让初学者能尽快上手和掌握这个芯片。大家以后既就可以很方便的建自己的工程模板了，再也不会为了找芯片的驱动库而烦恼。          今天外我来教大家来怎么使用这个建工程的利器吧。 首先是新建工程吧，如下图步骤：   因为我用的是 stm32f401 Necleo ，所以芯片型号应该要选择 stm32f401te, 选好芯片类型后，会弹出一个大的面板，如下图： 红色框里的都是一些集成在 keil 5 的启动文件， arm 内核的文件， st 公司的库函数和一些 API 等等。一个工程最起码也要选上 core 和 startup 两个选项，如下图： 然后选择 OK ，就建好了空白的工程。然后就要对工程做一些设置，如下图： 然后在你工程的路径新建一个 USE （这个大家可以随便建个文件，不一定是 USE 名字的）的文件夹，然后在里面新建一个 main.c 的文件，如下图： 然后新建的文件 main.c 添加到工程当中，步骤如下： 然后在 main.c 文件中添加如下代码： 到这里我们的空白工程建好了，后面我来教大家怎样加 keil 5 里自带的 st 库。首先我点击那个绿色的小图标，如下图：   点击后会弹出一个大的页面，然后找到 Device-StdPeriph Drivers 。如下图： 点开 StdPeriph Drivers 选项的加号图标，就可以看到 st 库目录下各外设的驱动文件，后面是他的版本说明，这是 V1.3 版本的，是比较新的，建议大家尽量使用新的库。 我这里就勾上了所有外设的驱动的文件，如下图： 然后点击 OK 后，就可以看到原先工程目录下的 Device 添加了刚才选择外设的驱动文件。添加完后大家不要急着编译工程，还有对工程进行相关的配置，否则如下图，编译不成功的： 接下来，我来配置下工程，右击 target ，然后进入配置工程的面板，步骤如下： 这里要填上 USE_STDPERIPH_DRIVER ，这就表明编译器选择了 st 的 库   然后我们来指定编译器头文件的路径         以上这两个路径是编译器编译时要找的路径，这几个头文件至关重要，这里编译器关联头文件所需要的。 当做完以上工作后，我们就可以来编译一下工程，在编译时，编译器就会根据我们的配置来编译驱动头文件和驱动的 C 文件。如下图： 当编译成功后会出现以下的信息：   下面我们要看看新的 stm32f4xx_conf.h 里的内容吧，如下图： 可以看出这跟旧版本的 stm32f4xx_conf.h 文件有些区别，在每个头文件这里多了个条件编译， 大家可以理解成开关吧，就是用来选择编译头文件用的，而这些开关都在 RTE_Components.h 这个头文件里，如下图： 编译完成后，可以看出 main.c 里包含了各驱动库的头文件，如下图： 做完以上工作后，我们就建好了一个基于库函数的模板了。 当大家编译完工程后，会发现工程目录里多出了好多文件，这是正常的，这是编译后产生的文件，如下图： 先把原来的产生的文件删除掉，删除后如下图：   现在我教大家怎样把这些文件指定每次编译后生成在指定的地方。 步骤如下： 首先还是进入工程配置的选项面板，然后在自己的工程目录里新建一个 Output 的文件，然后点击去，再点击 OK ，这样就代表告诉编译器器每次编译后生成的文件都会放在这个文件夹里。 这个跟上面的一样配置。 做好这些工作后，就可以编译工程了，编译完后生成的文件会保存在自己指定的那两个文件，如下图：     这样工程目录下的结构就清爽多了。    

最近又要开始编程了，所以忙里偷闲，再一次了解了一下开发平台的发展情况，看看是不是要换个新平台尝个鲜，也就引出了如题的一个选择题。   近几天，主要针对 Keil MDK-ARM 和 IAR EWARM 了解了一些信息。看过一些相关的讨论贴之后，决定试一下 IAR 的 EWARM（因为之前是用 Keil 的 MDK-ARM，同时也因为有好多网友认为 IAR 的 EWARM 要由于 MDK-ARM）。   EWARM 的最新版（6.60.2）试了一下，第一映像不好（对比MDK而言，主要是界面）。继续试用发现无法正常编译 STM32 标准外设库 V3.5 的例程（虽然经过一通搜索问题解决了，但还是小郁闷了一把）。   郁闷之余，去了 Keil 的主页，恰巧看到了 MDK-ARM 发布了最新的5.0版，于是下载试用。安装之后，跳出了第一个界面就让我又回到了Keil 的阵营。新版加入了 Pack Installer ,算是一个小的辅助程序，用于用户选择性的安装对应器件的相关支持文件和参考程序等等（第一感觉就是好人性化）。   于是，暂时放弃了 IAR（也许以后有空会再试试）。   简单的选择之后，想想为什么自己会这样选。其实，只是第一眼的感觉。可能很大程度上就是界面。对于硬件产品的话就是外观。于是，想到了产品设计。现在的产品，大到飞机、火箭、航母，小到手机、耳机等等，外观无疑是非常重要的一个环节。第一印象直接决定了之后的所有可能。

前天用Keil MDK 4.7A  + jlink   调试LPC2131开发板,忽然出现下面这个错误：在网上有找到解决方法，但是指标不治本，没找到原因。经过两天多的折腾（经过软件卸载、重装、系统重装）；最后终于解决这个问题，下面附上解决方法。我出现这个问题的根本原因是一个寄存器地址写错了（引用的别人的模板 ），应该是寻址带来的问题吧。 问题截图如下：    Error:Flash Download failed - Target DLL has benn cancelled  + 解决方法分两步： 1、用 ISP 软件擦除整个芯片； 2、仔细查找出哪个寄存器地址错误。 然后可以正常下载使用了。   说明：MDK的官方网站上有这个问题解决的第一步，但是没有写明原因；我完成第一步之后并没有检查源代码，以致于花费了两天的时间查硬件和编译器的错误，最后没办法重装系统，浪费的大把时间。   写在这，供需要的人查询！  

  对于RISC机器来说，对齐访问可以提高效率。ARM是RISC机器，因此在多数情况下它以对齐方式访问，即访问的地址一般是4或2的倍数。但在某些特殊应用上，对齐访问可能会带来麻烦。下面笔者以自身经历来说明有些情况是不允许对齐访问的，好在强大的MDK早就意料到这些特殊应用，并有相应的对策。 下面举例说明结构以对齐方式和非对齐方式存储的差别。 下面以三种不同的方式定义了结构体foo，见表一。其中第一种是常用的（默认情况）定义方式。第二种和第三种方式均以压缩方式存储，以非对齐方式访问。其中第二种方式关键字__packed修饰整个结构体，表明整个结构体以压缩方式存储；第三种方式关键字__packed修饰结构体中的某个域，被修饰的域以压缩的方式存储。而其它部分则采用非压缩方式。当然在示例结构体foo中，后两种定义方法达到的效果一样。 在第一种方式中，结构体成员one占用两个字节；成员two占用两个字节；成员three占用4个字节；成员four占用4个字节。 而在第二种和第三种方式中它们分别占用1个字节、两个字节、一个字节、4个字节。如果读者看到这还不是很清楚的话，那么请看其对应的汇编代码，见表二。 表一 三种定义结构体方式对比 非压缩方式存储（对齐访问） 将整个结构体以压缩方式存储 将结构体中的部分成员压缩方式存储 Struct foo {     char one;     short two;     char three;     int four; } c; __packed struct foo {     char one;     short two;     char three;     int four; } c; struct foo {     char one;     __packed short two;     char three;     int four; } c;   表二 三种定义结构体方式对应用汇编代码 非压缩方式存储（对齐方式） 将整个结构体以压缩方式存储 将结构体中的部分成员压缩方式存储 ; r0 包含了结构体c的首地址。   LDRB    r1, LDRSH   r2, LDRB    r3, LDR     r12, ; r0 包含了结构体c的首地址。   ; char one LDRB  r1,   ; short two LDRB  r2, LDRSB r12, ORR   r2, r12, r2, LSL #8   ; char three LDRB  r3,   ; int four ADD   r0, r0, #4 BL    __aeabi_uread4 ; r0 包含了结构体c的首地址。   ; char one LDRB  r1,   ; short two LDRB  r2, LDRSB r12, ORR   r2, r12, r2, LSL #8   ; char three LDRB  r3,   ; int four LDR   r12,   显然以压缩方式存储结构体节省了空间但浪费了时间。以非压缩方工存储结构体加快了速度但浪费了空间。 知道了结构体以压缩和非压缩方式存储的特点以及如何使用关键字__packed后。笔者给出在实际工作中遇到的必须使用压缩方式存储的一个例子。 大家知道FAT文件系统的DBR 区大小刚好为一个扇区（512字节）。DBR 区有一系列关于系统的数据。在处理时需要将其定义为一个结构体。程序中对这个结构体进行初始化时，需要将整个扇区的内容拷贝给这个结构体。因此这个结构体的大小正好为512字节。当然这是在压缩存储的情况下。试想如果以非压缩方式存储，结果将混乱不堪。在这种情况下必须加上关建字__packed。   该结构体定义如下： typedef __packed struct {        u8         BS_jmpBoot ;     //ofs:0.典型的如：0xEB,0x3E,0x90。        u8         BS_OEMName ;   //ofs:3.典型的如：“MSWIN4.1”。        u16        BPB_BytesPerSec;   //ofs:11.每扇区字节数。        u8         BPB_SecPerClus;    //ofs:13.每簇扇区数。        u16        BPB_RsvdSecCnt;   //ofs:14.保留扇区数，从DBR 到FAT 的扇区数。        u8         BPB_NumFATs;     //ofs:16.FAT 的个数。通常为2个。        u16        BPB_RootEntCnt;    //ofs:17.根目录项数。        u16        BPB_TotSec16;      //ofs:19.分区总扇区数(32M 时用)。        u8         BPB_Media;        //ofs:21.分区介质标识,SD卡一般用0xF8。        u16        BPB_FATSz16;      //ofs:22.每个FAT 占的扇区数。        u16        BPB_SecPerTrk;     //ofs:24.每道扇区数。对于SD卡无意义。        u16        BPB_NumHeads;     //ofs:26.磁头数。对于SD卡无意义。        u32        BPB_HiddSec;       //ofs:28.隐藏扇区数，从MBR 到DBR 的扇区数。        u32        BPB_TotSec32;      //ofs:32.分区总扇区数(=32M 时用)。        u8         BS_DrvNum;        //ofs:36.软盘使用0x00,硬盘使用0x80。SD卡无意义。        u8         BS_Reservedl;       //ofs:37.保留。        u8         BS_BootSig;        //ofs:38.扩展引导标记：0x29。通常对于SD卡无意义。        u32        BS_VolID;          //ofs:39.盘序列号。        u8         BS_VolLab ;      //ofs:43.如“Msdos ”。        u8         BS_FilSysType ;    //ofs:54.“FAT16 ”。        u8         ExecutableCode ;  //ofs:62.引导代码。        u8         ExecutableMarker ;  //ofs:510.结束标识:0xAA55。 } FAT_BPB;