STM32单片机学习

前言：从51开始，单片机玩了很长时间了，有51，PIC，AVR等等，早就想跟潮流玩玩ARM，但一直没有开始，原因-不知道玩了ARM可以做什么（对我自己而言）。如果为学习而学习，肯定学不好。然后cortex-m3出来了，据说，这东西可以替代单片机，于是马上开始关注。也在第一时间开始学习，可惜一开始就有点站错了队，选错了型（仍是对我自己而言）。我希望这种芯片应该是满大街都是，随便哪里都可以买得到，但我选的第一种显然做不到。为此，大概浪费了一年多时间吧，现在，回到对我来说是正确的道路上来啦，边学边写点东西。这里写的是我的学习的过程，显然，很多时候会是不全面的，不系统的，感悟式的，甚至有时会是错误的，有些做法会是不专业的。那么，为什么我还要写呢？这是一个有趣的问题，它甚至涉及到博客为什么要存在的问题。显然，博客里面的写的东西，其正确性、权威性大多没法和书比，可为什么博客会存在呢？理由很多，我非专家，只说我的感慨。我们读武侠小说，总会有一些创出独门功夫的宗师，功夫极高，然后他的弟子则基本上无法超越他。我在想，这位宗师在创造他自己的独门功夫时，必然会有很多的次的曲折、弯路、甚至失败，会浪费他的很多时间，而他教给弟子时，则已去掉了这些曲折和弯路，当然更不会把失败教给弟子，按理说，效率应该更高，可是没用，弟子大都不如师。为什么呢？也许知识本身并不是最重要的，获取知识的过程才是最重要的？也许所谓的知识，并不仅仅是一条条的结论，而是附带着很多说不清道不明的东西？如植物的根，一条主根上必带有大量的小小的触须？闲话多了些，就权当前言了。下面准备开始。一、条件的准备我的习惯，第一步是先搭建一个学习的平台。原来学51，PIC，AVR时，都是想方设法自己做些工具，实验板之类，现在人懒了，直接购买成品了。硬件电路板：火牛板软件：有keil和iar可供选择。网上的口水仗不少，我选keil，理由很简单，这个我熟。目前要学的知识中，软、硬件我都不熟，所以找一个我有点熟的东西就很重要。在我相当熟练之前，肯定不会用到IAR，如果真的有一天不得不用IAR，相信学起来也很容易，因为这个时候硬件部分我肯定很熟了，再加上有 keil的基础，所以应该很容易学会了。调试工具：JLINK V8。这个不多说了，价格便宜又好用，就是它了。二、热身细细端详，做工精良，尤其那上面的3.2吋屏，越看越喜欢。接下来就是一阵折腾了，装JLINK软件，给板子通电，先试试JLINK能不能与电脑和板子通信上了。真顺，一点问题也没有。于是准备将附带的程序一个一个地写进去试一试。一检查，大部分例子的HEX文件并没有给出，这要下一步自己生成，但是几个大工程的例子都有HEX文件，如MP3，如UCCGI测试等，写完以后观察程序运行的效果。因为之前也做过彩屏的东西，知道那玩艺代码量很大，要流畅地显示并不容，当时是用AVR做的，在1.8吋屏上显示一幅画要有一段时间。现在看起来，用STM32做的驱动显示出来的画面还是很快的，不过这里显示的大部分是自画图，并没有完整地显示一整幅的照片，所以到底快到什么程度还不好说，看来不久以后这可以作为一个学习点的。一个晚上过去了，下一篇就是要开始keil软件的学习了。三、开始编程硬件调通后，就要开始编程了。编程的方法有两种，一种是用st提供的库，另一种是从最底层开始编程，网上关于使用哪种方法编程的讨论很多，据说用库的效率要低一些。但是用库编程非常方便，所以我还是从库开始啦。库是ST提供的，怎么说也不会差到哪里，再说了，用32位ARM的话，开发的观念也要随之改变一点了。说说我怎么学的吧。找个例子，如GPIO，可以看到其结构如下：SOURCE（文件夹）- APP（文件夹）-CMSIS（文件夹）-STM32F10x_StdPeriph_Driver（文件夹）Lis（文件夹）OBJ（文件夹）其中SOURCE中保存的是应用程序，其中又有好多子文件夹，而CMSIS文件夹中和STM32F10x_StdPeriph_Driver文件夹中是ST提供的库，这样，如果要做新的工程只要将这个文件夹整个复制过来就行，其中APP中保存自己的代码。因为我们用51单片机时一般比较简单，有时就一个文件，所以通常不设置专门的输出文件夹，而这里做开发，通常会有很多个文件加入一个工程中，编译过程中会产生很多中间文件，因此设置专门的文件夹LIS和OBJ用来保存中间文件。下面就将设置简单描述一下。将复到过来的GPIO根目录下的所有文件删除，因为我们要学着自己建立工程。用菜单Project-New uVision Porject.。.建立新的工程，选择目标器件为STM32103VC，这个过程与建立51单片机的工程没有什么区别，这里就偷点懒，不上图了。接下来看一看怎么设置。点那个品字形，打开对话框这里就给个图了，相信有一定操作基础的人应该会用。顺便提一下，原来用VC或者IAR时总觉得它们的一个功能：就是建立一个是Debug组和Release组，这个功能挺好的，从这个图可在Keil里也是一样可以建的。将刚才那个文件夹图中CMSIS中的文件加入CMSIS组，一共3个，其中SourceCMSISCoreCM3有两个C语言源程序文件全部加入，另外还有一个在SourceCMSISCoreCM3startuparm文件夹中，这个文件夹中有4个.s文件， 我们选择其中的 startup_stm32f10x_hd.s文件。这是根据项目所用CPU来选择的，我们用的CPU是103VC的，属于高密度的芯片，所以选这个。至于LIB中的文件，就在这儿：SourceSTM32F10x_StdPeriph_Driversrc啦。这里有很多个文件，把什么文件加进去呢？怕麻烦的话，把所有文件全部加进去，这并不会增加编译后的代码量，但会增加很多的编译时间。接下来设定目标输出文件夹。上面这个图怎么出来的就不说啦，单击“Select Foler for Objects。”，在弹出来的对话框中选择OBJ文件夹。同样方法，选择List文件的输出文件夹。设置好后，如果直接编译是不行的，会出错。还需要提供头文件所在位置。单击c/C+标签页。第一次进入时Include Paths 文本框中是空白的，点击其后的按钮打开对话框，增加相应的路径这样路径就设好了。单击OK，回到上一界面，然后再单击OK，退出设置，即可编译、链接。下一会要试一试新的3.12版的库效果如何了。升级库光盘中所带的例子是3.10的，另外还有一个3.12的，我 试着将3.12的库替代原来的库，还真有问题，下面就简述问题及解决方法。（1）将库文件解压库文件名是：stm32f10x_stdperiph_lib.zip，解压后放在任意一个文件夹中。（2）由于原作者做了很好的规划，每一个项目中都分成三个文件夹，并且在source文件夹中又做了3个文件夹，其中APP文件夹是放自己写的文件的，其他的两个是从库中复制过来的，因此，想当然地把3.1.2版本中相同的两个文件夹：CMSIS和STM32F10x_StdPeriph_Driver直接复制过来，以为一切OK，结果一编译，出来一堆错误。其中有错误：SourceAppmain.c（7）： error： #20： identifier “GPIO_InitTypeDef” is undefined。.。还有大量的警告：SourceSTM32F10x_StdPeriph_Driversrcstm32f10x_flash.c（130）： warning： #223-D： function “assert_param” declared implicitly看了看，在APP文件夹中还有一些不属于自己的东西：stm32f10x_conf.h，stm32f10x_it.h，stm32f10x_it.c，打开一看，果然是3.10版本的，没说的，换。，找到STM32F10x_StdPeriph_Lib_V3.1.2ProjectTemplate文件夹，用里面的同样的文件替换掉这几个文件，这回应该万事大吉了吧。再一看，依然如故，没办法了，只好细细研究了。通过观察，发现原来可以编译通过的工程，在main.c下面挂满了.h文件，而这个通不过的，则少得很。这是编译能通过的工程这是编译通不过的工程显然，有些文件没有被包含进来。一点一点跟踪，发现大部分的头文件都包含在stm32f10x_conf.h中，而这个文件又出现在stm32f10x.h中，其中有这样的一行：#ifdef USE_STDPERIPH_DRIVER#include “stm32f10x_conf.h”#endif看来，是这个USE_STDPERIPH_DRIVER没有被定义啊，于是，人为地去掉条件：/#ifdef USE_STDPERIPH_DRIVER#include “stm32f10x_conf.h”/#endif再次编译，果然就OK了。可是，可是，也不能就这么去掉啊，怎么办呢？万能的网啊，一搜果然就有了。到设置 C/C+页面在那个define中加入“USE_STDPERIPH_DRIVER，STM32F10X_HD”当然，去掉条件编译前面的注释，回到原样。再次编译，一切顺利。可是，原来的工程例子也没有加这个啊，怎么回事呢？再次打开原来的例子，找到stm32f10x.h，可以看到有这么一行：而新的stm32f10x.h中则是这样的：原来那个3.1.0版的stm32f10x.h被人为地修改了一下，所以，不在define中定义也不要紧，而新升级的3.1.2则不行了。至此，简单的升级搞定。内存学习ARM中的RO、RW和ZI DATA一直以来对于ARM体系中所描述的RO，RW和ZI数据存在似是而非的理解，这段时间对其仔细了解了一番，发现了一些规律，理解了一些以前书本上有的但是不理解的东西，我想应该有不少人也有和我同样的困惑，因此将我的一些关于RO，RW和ZI的理解写出来，希望能对大家有所帮助。要了解RO，RW和ZI需要首先了解以下知识：ARM程序的组成此处所说的“ARM程序”是指在ARM系统中正在执行的程序，而非保存在ROM中的bin映像（image）文件，这一点清注意区别。一个ARM程序包含3部分：RO，RW和ZIRO是程序中的指令和常量RW是程序中的已初始化变量ZI是程序中的未初始化的变量由以上3点说明可以理解为：RO就是readonly，RW就是read/write，ZI就是zeroARM映像文件的组成所谓ARM映像文件就是指烧录到ROM中的bin文件，也称为image文件。以下用Image文件来称呼它。Image文件包含了RO和RW数据。之所以Image文件不包含ZI数据，是因为ZI数据都是0，没必要包含，只要程序运行之前将ZI数据所在的区域一律清零即可。包含进去反而浪费存储空间。Q：为什么Image中必须包含RO和RW？A：因为RO中的指令和常量以及RW中初始化过的变量是不能像ZI那样“无中生有”的。ARM程序的执行过程从以上两点可以知道，烧录到ROM中的image文件与实际运行时的ARM程序之间并不是完全一样的。因此就有必要了解ARM程序是如何从ROM中的image到达实际运行状态的。实际上，RO中的指令至少应该有这样的功能：1. 将RW从ROM中搬到RAM中，因为RW是变量，变量不能存在ROM中。2. 将ZI所在的RAM区域全部清零，因为ZI区域并不在Image中，所以需要程序根据编译器给出的ZI地址及大小来将相应得RAM区域清零。ZI中也是变量，同理：变量不能存在ROM中在程序运行的最初阶段，RO中的指令完成了这两项工作后C程序才能正常访问变量。否则只能运行不含变量的代码。说了上面的可能还是有些迷糊，RO，RW和ZI到底是什么，下面我将给出几个例子，最直观的来说明RO，RW，ZI在C中是什么意思。1; RO看下面两段程序，他们之间差了一条语句，这条语句就是声明一个字符常量。因此按照我们之前说的，他们之间应该只会在RO数据中相差一个字节（字符常量为1字节）。Prog1：#include stdio.hvoid main（void）;Prog2：#include stdio.hconst char a = 5；void main（void）;Prog1编译出来后的信息如下：=Code RO Data RW Data ZI Data Debug948 60 0 96 0 Grand Totals=Total RO Size（Code + RO Data） 1008 （ 0.98kB）Total RW Size（RW Data + ZI Data） 96 （ 0.09kB）Total ROM Size（Code + RO Data + RW Data） 1008 （ 0.98kB）=Prog2编译出来后的信息如下：=Code RO Data RW Data ZI Data Debug948 61 0 96 0 Grand Totals=Total RO Size（Code + RO Data） 1009 （ 0.99kB）Total RW Size（RW Data + ZI Data） 96 （ 0.09kB）Total ROM Size（Code + RO Data + RW Data） 1009 （ 0.99kB）=以上两个程序编译出来后的信息可以看出：Prog1和Prog2的RO包含了Code和RO Data两类数据。他们的唯一区别就是Prog2的RO Data比Prog1多了1个字节。这正和之前的推测一致。如果增加的是一条指令而不是一个常量，则结果应该是Code数据大小有差别。2; RW同样再看两个程序，他们之间只相差一个“已初始化的变量”，按照之前所讲的，已初始化的变量应该是算在RW中的，所以两个程序之间应该是RW大小有区别。Prog3：#include stdio.hvoid main（void）;Prog4：#include stdio.hchar a = 5；void main（void）;Prog3编译出来后的信息如下：=Code RO Data RW Data ZI Data Debug948 60 0 96 0 Grand Totals=Total RO Size（Code + RO Data） 1008 （ 0.98kB）Total RW Size（RW Data + ZI Data） 96 （ 0.09kB）Total ROM Size（Code + RO Data + RW Data） 1008 （ 0.98kB）=Prog4编译出来后的信息如下：=Code RO Data RW Data ZI Data Debug948 60 1 96 0 Grand Totals=Total RO Size（Code + RO Data） 1008 （ 0.98kB）Total RW Size（RW Data + ZI Data） 97 （ 0.09kB）Total ROM Size（Code + RO Data + RW Data） 1009 （ 0.99kB）=可以看出Prog3和Prog4之间确实只有RW Data之间相差了1个字节，这个字节正是被初始化过的一个字符型变量“a”所引起的。3; ZI再看两个程序，他们之间的差别是一个未初始化的变量“a”，从之前的了解中，应该可以推测，这两个程序之间应该只有ZI大小有差别。Prog3：#include stdio.hvoid main（void）;Prog4：#include stdio.hchar a；void main（void）;Prog3编译出来后的信息如下：=Code RO Data RW Data ZI Data Debug948 60 0 96 0 Grand Totals=Total RO Size（Code + RO Data） 1008 （ 0.98kB）Total RW Size（RW Data + ZI Data） 96 （ 0.09kB）Total ROM Size（Code + RO Data + RW Data） 1008 （ 0.98kB）=Prog4编译出来后的信息如下：=Code RO Data RW Data ZI Data Debug948 60 0 97 0 Grand Totals=Total RO Size（Code + RO Data） 1008 （ 0.98kB）Total RW Size（RW Data + ZI Data） 97 （ 0.09kB）Total ROM Size（Code + RO Data + RW Data） 1008 （ 0.98kB）=编译的结果完全符合推测，只有ZI数据相差了1个字节。这个字节正是未初始化的一个字符型变量“a”所引起的。注意：如果一个变量被初始化为0，则该变量的处理方法与未初始化华变量一样放在ZI区域。即：ARM C程序中，所有的未初始化变量都会被自动初始化为0。总结：1; C中的指令以及常量被编译后是RO类型数据。2; C中的未被初始化或初始化为0的变量编译后是ZI类型数据。3; C中的已被初始化成非0值的变量编译后市RW类型数据。附：程序的编译命令（假定C程序名为tst.c）：armcc -c -o tst.o tst.carmlink -noremove -elf -nodebug -info totals -info sizes -map -list aa.map -o tst.elf tst.o编译后的信息就在aa.map文件中。ROM主要指：NAND Flash，Nor FlashRAM主要指：PSRAM，SDRAM，SRAM，DDRAM