LV16-06-MDK-01-程序与编译

本文主要是STM32开发——MDK编译过程以及编译工具链的相关笔记,若笔记中有错误或者不合适的地方,欢迎批评指正😃。

点击查看使用工具及版本
Windows windows11
Ubuntu Ubuntu16.04的64位版本
VMware® Workstation 16 Pro 16.2.3 build-19376536
SecureCRT Version 8.7.2 (x64 build 2214) - 正式版-2020年5月14日
开发板 正点原子 i.MX6ULL Linux阿尔法开发板
uboot NXP官方提供的uboot,NXP提供的版本为uboot-imx-rel_imx_4.1.15_2.1.0_ga(使用的uboot版本为U-Boot 2016.03)
linux内核 linux-4.15(NXP官方提供)
STM32开发板 正点原子战舰V3(STM32F103ZET6)
点击查看本文参考资料
  • 通用
分类 网址说明
官方网站https://www.arm.com/ARM官方网站,在这里我们可以找到Cotex-Mx以及ARMVx的一些文档
https://www.st.com/content/st_com/zh.htmlST官方网站,在这里我们可以找到STM32的相关文档
https://www.stmcu.com.cn/意法半导体ST中文官方网站,在这里我们可以找到STM32的相关中文参考文档
http://elm-chan.org/fsw/ff/00index_e.htmlFatFs文件系统官网
教程书籍《ARM Cortex-M3权威指南》ARM公司专家Joseph Yiu(姚文祥)的力作,中文翻译是NXP的宋岩
《ARM Cortex-M0权威指南》
《ARM Cortex-M3与Cortex-M4权威指南》
开发论坛http://47.111.11.73/forum.php开源电子网,正点原子的资料下载及问题讨论论坛
https://www.firebbs.cn/forum.php国内Kinetis开发板-野火/秉火(刘火良)主持的论坛,现也做STM32和i.MX RT
https://www.amobbs.com/index.php阿莫(莫进明)主持的论坛,号称国内最早最火的电子论坛,以交流Atmel AVR系列单片机起家,现已拓展到嵌入式全平台,其STM32系列帖子有70W+。
http://download.100ask.net/index.html韦东山嵌入式资料中心,有些STM32和linux的相关资料也可以来这里找。
博客参考http://www.openedv.com/开源网-原子哥个人博客
http://blog.chinaaet.com/jihceng0622博主是原Freescale现NXP的现场应用工程师
cortex-m-resources这其实并不算是一个博客,这是ARM公司专家Joseph Yiu收集整理的所有对开发者有用的官方Cortex-M资料链接(也包含极少数外部资源链接)
  • STM32
STM32STM32 HAL库开发实战指南——基于F103系列开发板野火STM32开发教程在线文档
STM32库开发实战指南——基于野火霸道开发板野火STM32开发教程在线文档
  • SD卡
SD Association提供了SD存储卡和SDIO卡系统规范
点击查看相关文件下载
STM32F103xx英文数据手册STM32F103xC/D/E系列的英文数据手册
STM32F103xx中文数据手册STM32F103xC/D/E系列的中文数据手册
STM32F10xxx英文参考手册(RM0008)STM32F10xxx系列的英文参考手册
STM32F10xxx中文参考手册(RM0008)STM32F10xxx系列的中文参考手册
Arm Cortex-M3 处理器技术参考手册-英文版Cortex-M3技术参考手册-英文版
STM32F10xxx Cortex-M3编程手册-英文版(PM0056)STM32F10xxx/20xxx/21xxx/L1xxxx系列Cortex-M3编程手册-英文版
SD卡相关资料——最新版本有关SD卡的一些资料可以从这里下载
SD卡相关资料——历史版本有关SD卡的一些历史版本资料可以从这里下载,比如后边看的SD卡2.0协议
SD 2.0 协议标准完整版这是一篇关于SD卡2.0协议的中文文档,还是比较有参考价值的,可以一看

本篇笔记主要是参考的野火的文档。

一、编译过程

1. 编译过程简介

我们简单了解下MDK的编译过程,它与其它编译器的工作过程是类似的:

MDK编译过程

(1) 编译,MDK软件使用的编译器是 armcc 和 armasm , 它们根据每个C/C++和汇编源文件编译成对应的以“ .o ”为后缀名的对象文件(Object Code,也称目标文件), 其内容主要是从源文件编译得到的机器码,包含了代码、数据以及调试使用的信息;

(2) 链接, 链接器 armlink 把各个 .o 文件及库文件链接成一个映像文件“ .axf ”或“ .elf ”;

(3) 格式转换,一般来说 Windows 或 Linux 系统使用链接器直接生成可执行映像文件 elf 后,内核根据该文件的信息加载后, 就可以运行程序了,但在单片机平台上,需要把该文件的内容加载到芯片上, 所以还需要对链接器生成的 elf 映像文件利用格式转换器 fromelf 转换成“ .bin ”或“ .hex ”文件,交给下载器下载到芯片的 FLASH 或 ROM 中。

2. 具体过程

image-20230410223415106

如上图所示,MDK编译工程的输出提示主要可以分为上边6个部分:

(1) 提示信息的第一部分说明构建过程调用的编译器。图中的编译器名字是“ V5.06 update 6 (build 750) ”,后面附带了该编译器所在的文件夹。 在电脑上打开该路径,可看到该编译器包含的各个编译工具,如armar、armasm、armcc、armlink及fromelf, 后面四个工具已在上一小节已讲解,而 armar 是用于把.o文件打包成lib文件的。

image-20230410223657951

(2) 使用armasm编译汇编文件。图中列出了编译 startup 启动文件时的提示, 编译后每个汇编源文件都对应有一个独立的.o文件。

(3) 使用armcc编译c/c++文件。图中列出了工程中所有的c/c++文件的提示, 同样地,编译后每个c/c++源文件都对应有一个独立的.o文件。

(4) 使用armlink链接对象文件,根据程序的调用把各个.o文件的内容链接起来,最后生成程序的 axf 映像文件, 并附带程序各个域大小的说明,包括Code、RO-data、RW-data及ZI-data的大小。

(5) 使用 fromelf 生成下载格式文件,它根据axf映像文件转化成hex文件, 并列出编译过程出现的错误(Error)和警告(Warning)数量。

(6) 最后一段提示给出了整个构建过程消耗的时间。

构建完成后,可在工程的“Output”及“Listing”目录下找到由以上过程生成的各种文件:

image-20230410223927930

后边的文件省略,这里只列举部分文件,可以看到,每个C源文件都对应生成了.o、.d及.crf后缀的文件,还有一些额外的.dep、.hex、.axf、.htm、.lnp、.sct、.lst及.map文件。

二、编译工具链

前面编译过程中,MDK调用了各种编译工具,平时我们直接配置MDK,不需要学习如何使用它们,但了解它们是非常有好处的。例如, 若希望使用MDK编译生成bin文件的,需要在MDK中输入指令控制fromelf工具;在后面讲解AXF及O文件的时候,需要利用fromelf工具查看其文件信息, 这都是无法直接通过MDK做到的。关于这些工具链的说明,在MDK的帮助手册《ARM Development Tools》都有详细讲解, 点击MDK界面的“help->uVision Help”菜单可打开该文件。

1. 设置环境变量

用这些编译工具,需要用到Windows的命令行提示符工具,为了让命令行方便地找到这些工具,我们先把工具链的目录添加到系统的环境变量中。 查看本机工具链所在的具体目录可根据上一小节讲解的工程编译提示输出信息中找到,如本机的路径为“C:\LenovoSoft\Keil_v5\ARM\ARMCC\bin”。

2. 添加路径到PATH环境变量

(1) 右键电脑系统的【此电脑】, 在弹出的菜单中选择“属性”

image-20230410225220408

(2) 在弹出的属性页面依次点击【高级系统设置】→【环境变量】,在用户变量一栏中找到名为“PATH”的变量,若没有该变量, 则新建一个。编辑“PATH”变量,在它的变量值中输入工具链的路径,如本机的是“ C:\LenovoSoft\Keil_v5\ARM\ARMCC\bin ”, 注意要使用“ 分号 ; ”让它与其它路径分隔开,输入完毕后依次点确定:

image-20230410225611744

(3) 打开Windows的命令行。

(4) 在弹出的命令行窗口中输入“fromelf”回车,若窗口打印出formelf的帮助说明,那么路径正常,就可以开始后面的工作了; 若提示“不是内部名外部命令,也不是可运行的程序…”信息,说明路径不对,请重新配置环境变量,并确认该工作目录下有编译工具链。

image-20230410225740347

这个过程本质就是让命令行通过“PATH”路径找到“fromelf.exe”程序运行,默认运行“fromelf.exe”时它会输出自己的帮助信息, 这就是工具链的调用过程,MDK本质上也是如此调用工具链的,只是它集成为GUI,相对于命令行对用户更友好。

3.1 armcc

armcc用于把c/c++文件编译成ARM指令代码,编译后会输出ELF格式的O文件(对象、目标文件),在命令行中输入“armcc”回车可调用该工具, 它会打印帮助说明:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
C:\Users\20380>armcc
Product: MDK Plus 5.29
Component: ARM Compiler 5.06 update 6 (build 750)
Tool: armcc [4d3637]
For support see http://www.arm.com/support
Software supplied by: ARM Limited

Usage: armcc [options] file1 file2 ... filen
Main options:

--arm Generate ARM code
--thumb Generate Thumb code
--c90 Switch to C mode (default for .c files)
--cpp Switch to C++ mode (default for .cpp files)
-O0 Minimum optimization
# 中间部分省略......
-D<symbol> Define <symbol> on entry to the compiler
-g Generate tables for high-level debugging
-I<directory> Include <directory> on the #include search path

帮助提示中分三部分,第一部分是armcc版本信息,第二部分是命令的用法,第三部分是主要命令选项。

根据命令用法: armcc [options] file1 file2 …filen , 在[option]位置可输入下面的“–arm”、“–cpu list”选项, 若选项带文件输入,则把文件名填充在file1 file2…的位置,这些文件一般是c/c++文件。

例如根据它的帮助说明,“–cpu list”可列出编译器支持的所有cpu,我们在命令行中输入“armcc –cpu list”, 可查看cpu列表:

1
2
3
4
5
6
7
8
9
10
C:\Users\20380>armcc -cpu list
Warning: C3910W: Old syntax, please use '--cpu'.
The following arguments to option 'cpu' can be selected:
# ... ...
--cpu=7-R
--cpu=7-M
--cpu=7E-M
--cpu=7-A.security
--cpu=ARM7EJ-S
# 后边的省略... ...

打开MDK的Options for Targe->c/c++菜单,可看到MDK对编译器的控制命令:

image-20230410230117924

从该图中的命令可看到,它调用了-c、-cpu –D –g –O1等编译选项,当我们修改MDK的编译配置时,可看到该控制命令也会有相应的变化。 然而我们无法在该编译选项框中输入命令,只能通过MDK提供的选项修改。

了解这些,我们就可以查询具体的MDK编译选项的具体信息了,如c/c++选项中的“Optimization:Leve 1(-O1)”是什么功能呢? 首先可了解到它是“-O”命令,命令后还带个数字,查看MDK的帮助手册(【help】→【uVision help】),在armcc编译器说明章节:

image-20230410230449727

利用MDK,我们一般不需要自己调用armcc工具,但经过这样的过程我们就会对MDK有更深入的认识。

3.2 armasm

armasm 是汇编器,它把汇编文件编译成O文件。与armcc类似, MDK对armasm的调用选项可在“Option for Target→Asm”页面进行配置:

image-20230410230546472

armlink是链接器,它把各个O文件链接组合在一起生成ELF格式的AXF文件,AXF文件是可执行的,下载器把该文件中的指令代码下载到芯片后, 该芯片就能运行程序了;利用armlink还可以控制程序存储到指定的ROM或RAM地址。 在MDK中可在“Option for Target→Linker”页面配置armlink选项:

image-20230410230625703

链接器默认是根据芯片类型的存储器分布来生成程序的,该存储器分布被记录在工程里的sct后缀的文件中,有特殊需要的话可自行编辑该文件, 改变链接器的链接方式。

4. armar、fromelf及用户指令

armar工具用于把工程打包成库文件,fromelf可根据axf文件生成hex、bin文件,hex和bin文件是大多数下载器支持的下载文件格式。

在MDK中,针对armar和fromelf工具的选项几乎没有,仅集成了生成HEX或Lib的选项:

image-20230410230731311

例如如果我们想利用fromelf生成bin文件,可以在MDK的“【Option for Target】→【User】”页中添加调用fromelf的指令:

image-20230410231410382

在User配置页面中,提供了三种类型的用户指令输入框,在不同组的框输入指令, 可控制指令的执行时间,分别是编译前 (Before Compile c/c++ file )、 构建前( Before Build/Rebuild )及构建后( AfterBuild/Rebuild )执行。 这些指令并没有限制必须是arm的编译工具链,例如如果自己编写了python脚本, 也可以在这里输入用户指令执行该脚本。

图中的生成bin文件指令调用了 fromelf 工具,紧跟后面的是工具的选项及输出文件名、输入文件名。由于fromelf是根据 axf 文件生成 bin 的, 而 axf 文件又是构建(build)工程后才生成,所以我们把该指令放到“ After Build/Rebuild ”一栏。这里的路径应该是以工程所在目录为起点。

当我们重新编译工程,便会调用这条命令:

image-20230410231446006

然后我们便会在对应的目录下生成bin文件:

image-20230410231521158

三、程序的组成、存储与运行

1. CODE、RO、RW、ZI Data域及堆栈空间

在工程的编译提示输出信息中有一个语句:

1
Program Size:Code=xx RO-data=xx RW-data=xx ZI-data=xx

它说明了程序各个域的大小,编译后,应用程序中所有具有同一性质的数据(包括代码)被归到一个域,程序在存储或运行的时候, 不同的域会呈现不同的状态,这些域的意义如下:

  • Code:即代码域,它指的是编译器生成的机器指令,这些内容被存储到ROM区。
  • RO-data:Read Only data,即只读数据域,它指程序中用到的只读数据,这些数据被存储在ROM区,因而程序不能修改其内容。 例如C语言中const关键字定义的变量就是典型的RO-data。
  • RW-data:Read Write data,即可读写数据域,它指初始化为“非0值”的可读写数据,程序刚运行时,这些数据具有非0的初始值, 且运行的时候它们会常驻在RAM区,因而应用程序可以修改其内容。例如C语言中使用定义的全局变量,且定义时赋予“非0值”给该变量进行初始化。
  • ZI-data:Zero Initialie data,即0初始化数据,它指初始化为“0值”的可读写数据域, 它与RW-data的区别是程序刚运行时这些数据初始值全都为0, 而后续运行过程与RW-data的性质一样,它们也常驻在RAM区,因而应用程序可以更改其内容。例如C语言中使用定义的全局变量, 且定义时赋予“0值”给该变量进行初始化(若定义该变量时没有赋予初始值,编译器会把它当ZI-data来对待,初始化为0);
  • ZI-data的栈空间(Stack)及堆空间(Heap):在C语言中,函数内部定义的局部变量属于栈空间,进入函数的时候从向栈空间申请内存给局部变量, 退出时释放局部变量,归还内存空间。而使用malloc动态分配的变量属于堆空间。在程序中的栈空间和堆空间都是属于ZI-data区域的, 这些空间都会被初始值化为0值。编译器给出的ZI-data占用的空间值中包含了堆栈的大小(经实际测试,若程序中完全没有使用malloc动态申请堆空间, 编译器会优化,不把堆空间计算在内)。

综上所述,以程序的组成构件为例,它们所属的区域类别:

程序组件所属的区域

2. 程序的存储与运行

RW-data和ZI-data它们仅仅是初始值不一样而已,为什么编译器非要把它们区分开?这就涉及到程序的存储状态了,应用程序具有静止状态和运行状态。

静止态的程序被存储在非易失存储器中,如STM32的内部FLASH,因而系统掉电后也能正常保存。但是当程序在运行状态的时候,程序常常需要修改一些暂存数据, 由于运行速度的要求,这些数据往往存放在内存中(RAM),掉电后这些数据会丢失。因此,程序在静止与运行的时候它在存储器中的表现是不一样的,如下图:

应用程序的加载视图与执行视图

图中的左侧是应用程序的存储状态,右侧是运行状态,而上方是RAM存储器区域,下方是ROM存储器区域。

程序在存储状态时,RO节(RO section)及RW节都被保存在ROM区。当程序开始运行时,内核直接从ROM中读取代码,并且在执行主体代码前, 会先执行一段加载代码,它把RW节数据从ROM复制到RAM, 并且在RAM加入ZI节,ZI节的数据都被初始化为0。加载完后RAM区准备完毕,正式开始执行主体程序。

编译生成的RW-data的数据属于图中的RW节,ZI-data的数据属于图中的ZI节。是否需要掉电保存,这就是把RW-data与ZI-data区别开来的原因, 因为在RAM创建数据的时候,默认值为0,但如果有的数据要求初值非0,那就需要使用ROM记录该初始值,运行时再复制到RAM。

STM32的RO区域不需要加载到SRAM,内核直接从FLASH读取指令运行。计算机系统的应用程序运行过程很类似,不过计算机系统的程序在存储状态时位于硬盘, 执行的时候甚至会把上述的RO区域(代码、只读数据)加载到内存,加快运行速度,还有虚拟内存管理单元(MMU)辅助加载数据, 使得可以运行比物理内存还大的应用程序。而STM32没有MMU,所以无法支持Linux和Windows系统。

当程序存储到STM32芯片的内部FLASH时(即ROM区),它占用的空间是Code、RO-data及RW-data的总和,所以如果这些内容比STM32芯片的FLASH空间大, 程序就无法被正常保存了。当程序在执行的时候,需要占用内部SRAM空间(即RAM区),占用的空间包括RW-data和ZI-data。 应用程序在各个状态时各区域的组成如下表:

程序状态区域的组成

在MDK中,我们建立的工程一般会选择芯片型号,选择后就有确定的FLASH及SRAM大小,若代码超出了芯片的存储器的极限, 编译器会提示错误,这时就需要裁剪程序了,裁剪时可针对超出的区域来优化。