
正文
esp8266 SDK开发之编译流程
提示:扫一扫查出行【扫一扫了解最新限行尾号】
复制提示
最近刚完成自己8266的小项目,已经发布在github上,有兴趣的朋友可以看一下
github地址:esp-ujn
1. 通过MQTT协议与服务器交互
2. 内置HTTP服务器,支持通过浏览器进行参数配置
编译流程分析
我们在编译8266代码时可以使用项目中的 gen_misc.sh (Windows下为 gen_misc.bat )脚本,选择合适的参数后就会在 sdk/bin/ 文件夹中生成可烧录的文件,如 eagle.flash.bin , eagle.irom0text.bin 。 但这样存在的问题是每次编译时都需要选择一遍编译参数,所以一般会使用 make 命令进行编译,如:
make COMPILE=gcc BOOT=none APP= SPI_SPEED= SPI_MODE=QIO SPI_SIZE_MAP=
这是因为 gen_misc.sh 的作用仅仅是供用户选择编译参数,最终的编译过程是通过 make 命令依据Makefile文件中定义的若干规则来进行的。接下来通过如下几个方面来探讨整个编译流程
- Makefile的组织形式
- 烧录文件的生成过程
- Makefile的执行过程
一、Makefile的组织形式
SDK中Makefile文件以树形结构组织。总体上分为3类:主文件,项目配置文件,库配置文件。
|--sdk/
|----Makefile
|----project/
|------Makefile
|------user/
|--------Makefile
|------json/
|--------Makefile
如上图所示
- sdk/Makefile 主文件
- sdk/project/Makefile 项目配置文件
- sdk/project/json/Makefile 库配置文件
平常开发过程中,一般我们只需要关注项目配置文件与库配置文件即可。如有时为了程序的模块化,需要将不同的功能模块编译成独立的库。这时需要修改项目配置文件,并创建对应的库配置文件。例如我们需要添加一个json库。这时就需要:
- 在 sdk/project/ 下创建文件夹 sdk/project/json/
- 将 sdl/project/user/Makefile 拷贝到 sdk/project/json/ 下
- 修改 sdk/project/json/Makefile
- 修改 sdk/project/Makefile
需要在两个Makefile中做出的改动如下:
#sdk/project/json/Makefile
GEN_LIBS = libjson.a #库名 #sdk/project/Makefile
SUBDIRS = user \
json #库目录
COMPONENTS_eagle.app.v6 = user/libuser.a \
json/libjson.a #库路径
二、烧录文件的生成过程
对于Non-FOTA模式,编译完成后会在 sdk/bin/ 目录下生成 eagle.flash.bin 与 eagle.irom0text.bin 。显然这两个文件并不是编译器的直接产物,一般来说编译器会通过我们的代码生成一个可执行程序。那么这两个文件是从何而来的呢?实际上这两个文件是编译后生成的可执行文件的一部分。可执行文件被拆解成了多个部分,然后拼凑出了这两个文件供我们烧录。我们的代码经过编译后会生成一个elf文件,它的路径在 sdk/project/.output/eagle/debug/image/eagle.app.v6.out 。这个一个标准的elf文件,可以使用 readelf 命令查看它的一些信息。
#readelf -h
ELF 头:
Magic: 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00
类别: ELF32
数据: 2 补码,小端序 (little endian)
版本: 1 (current)
OS/ABI: UNIX - System V
ABI 版本: 0
类型: EXEC (可执行文件)
系统架构: Tensilica Xtensa Processor
版本: 0x1
入口点地址: 0x40100004
程序头起点: 52 (bytes into file)
Start of section headers: 549292 (bytes into file)
标志: 0x300
本头的大小: 52 (字节)
程序头大小: 32 (字节)
Number of program headers: 5
节头大小: 40 (字节)
节头数量: 19
字符串表索引节头: 16 #readelf -S
共有 个节头,从偏移量 0x861ac 开始:
节头:
[Nr] Name Type Addr Off Size ES Flg Lk Inf Al
[ 0] NULL 00000000 000000 000000 00 0 0 0
[ 1] .data PROGBITS 3ffe8000 0000e0 000804 00 WA 0 0 16
[ 2] .rodata PROGBITS 3ffe8810 0008f0 0015d0 00 A 0 0 16
[ 3] .bss NOBITS 3ffe9de0 001ec0 006f18 00 WA 0 0 16
[ 4] .irom0.text PROGBITS 40210000 0092c0 038b44 00 AX 0 0 16
[ 5] .text PROGBITS 40100000 001ec0 0073fc 00 AX 0 0 4
[ 6] .xtensa.info NOTE 00000000 041e04 000038 00 0 0 1
[ 7] .comment PROGBITS 00000000 041e3c 001bbd 00 0 0 1
[ 8] .debug_frame PROGBITS 00000000 0439fc 00211c 00 0 0 4
[ 9] .debug_info PROGBITS 00000000 045b18 014bec 00 0 0 1
[10] .debug_abbrev PROGBITS 00000000 05a704 003f8a 00 0 0 1
将可执行文件 eagle.app.v6.out 转变为可烧录文件的过程定义在 sdk/Makefile ,也就是在主文件中。大体流程如下:
#将.text、.data、.rodata和.irom0.text节的数据转存到文件
objcopy --only-section .text -O binary eagle.app.v6.out eagle.app.v6.text.bin
objcopy --only-section .data -O binary eagle.app.v6.out eagle.app.v6.data.bin
objcopy --only-section .rodata -O binary eagle.app.v6.out eagle.app.v6.rodata.bin
objcopy --only-section .irom0.text -O binary eagle.app.v6.out eagle.app.v6.irom0text.bin
#通过eagle.app.v6.text.bin、eagle.app.v6.data.bin和eagle.app.v6.rodata.bin生成eagle.app.flash.bin
python sdk/tools/gen_appbin.py eagle.app.v6.text.bin eagle.app.v6.data.bin eagle.app.v6.rodata.bin
#将最后生成的可烧录文件放到sdk/bin/目录下
mv eagle.app.flash.bin sdk/bin/eagle.flash.bin
mv eagle.app.v6.irom0text.bin sdk/bin/eagle.irom0text.bin
通过上边 readelf -S 获取到的节区表信息可以看到,实际在内存中出现的节只有 .text 、 .data 、 .bss 、 .rodata 和 .irom0.text 。
.text + .data + .rodata => eagle.flash.bin
.irom0.text => eagle.irom0text.bin
通过比较这几个节的大小与烧录文件大小的关系可以得到相同的结果( eagle.flash.bin 文件中除了包含程序节数据,还有少量的配置数据)。 .bss 节虽然在内存中出现但是在程序初始化时会被整个清零,所以不必出现在烧录文件中。这几个节包含的数据内容如下:
| 节名 | 作用 |
| .text | 存放代码 |
| .data | 存放已初始化的全局变量 |
| .bss | 存放未初始化的全局变量 |
| .rodata | 存放只读数据 |
| .irom0.text | 存放标注有ICACHE_FLASH_ATTR的代码或ICACHE_RODATA_ATTR的变量 |
三、Makefile的执行过程
在前边已经提到,我们写的代码最终会编译为一个elf格式的可执行文件( eagle.app.v6.out ),接下我们通过具体Makefile文件中的代码对整个编译的执行过程进行分析。之前讲到 sdk/Makefile 为主文件,也就是所有编译时用到的逻辑都在其中定义。我们整个的编译流程中需要按顺序产生如下几类目标:二进制目标文件、库文件、elf文件、烧录文件。那么如何通过一个主Makefile来完成这些工作呢,这里需要先看一下其余两类起配置作用的Makefile。这两类Makefile的最后都会有如下代码:
PDIR := ../$(PDIR)
sinclude $(PDIR)Makefile
它的作用是包含自己父文件夹中的Makefile文件,那么最后主Makefile文件中的内容会被包含到库配置文件与项目配置文件中。在项目配置文件中,它的作用是产生elf可执行文件与烧录文件,在库配置文件中,它的作用是产生静态链接库。主Makefile中,最主要的显式规则如下,通过这两条规则产生了所有我们需要的文件。
...
314 all: .subdirs $(OBJS) $(OLIBS) $(OIMAGES) $(OBINS) $(SPECIAL_MKTARGETS)
...
.subdirs:
@set -e; $(foreach d, $(SUBDIRS), $(MAKE) -C $(d);)
这两条规则的目标都是伪目标,并不会产生任何文件,我们所需要的所有文件都是目标 all 的依赖文件。
$(OBJS) |
二进制目标文件 |
$(OLIBS) |
静态链接库 |
$(OIMAGES) |
elf可执行文件 |
$(OBINS) |
烧录文件 |
$(SPECIAL_MKTARGETS) |
一直为空 |
第一个依赖文件 .subdirs 是一个伪目标,也就是每次编译时都会先执行 .subdirs 中定义的操作,也就是遍历所有含Makefile文件的子文件夹,执行 make 命令。通过这种方式产生的结果就是 make 工具的当前路径发生了改变。拿上边列出的项目结构为例,我们一次编译过程可分为
- 我们在 sdk/project/ 文件夹下执行 make 命令编译源码
- sdk/project/Makefile包含 sdk/Makefile 的内容
- 构建目标 all
- 依赖文件 .subdirs 不存在,进行构建
- 遍历 sdk/project/ 下所有含Makefile文件的子文件并执行 make 命令
这时如果执行了 sdk/project/json/Makefile ,那么此时 make 工具的当前路径变为了 sdk/project/json/ 。此时 sdk/project/json/Makefile 对上层Makefile进行包含后再次构建目标 all 。一般来说 sdk/project/json/ 中不会再有包含Makefile的子文件夹,那么此时目标 all 的第一个依赖项 .subdirs 会立刻返回,然后再对其余的依赖项进行构建。
还有一点需要说明的是目标 all 的依赖项并不是全都有值的,比如 $(SPECIAL_MKTARGETS) 的值就一直为空,表示不存在此依赖项。继续拿上边的项目结构举例:
| make当前路径 |
$(OBJS) |
$(OLIBS) |
$(OIMAGES) |
$(OBINS) |
| sdk/project/ | 空 | 空 | eagle.app.v6.out | eagle.app.v6.bin |
| sdk/project/json/ | json.o | libjson.a | 空 | 空 |
根据 make 当前路径的不同,目标 all 有不同的依赖项,然后再根据主Makefile中定义隐式规则对依赖项进行构建,即完成了整个项目的构建过程。
有的朋友可能对Makefile的语法不熟悉,这里推荐一个网站
https://www.gnu.org/s/make/manual/make.html
官方的教程很详细







