一、新建工程:
点击File->New->C++ project
然后我们会发现下图的界面,在这个界面中有STM32等工程的现成选项,右侧还有该工程支持的编译链,如Cross Arm gcc,根据这个我们就可以判断前面的软件安装成功了。此时我们可以直接点击新建一个基于STM32模版的工程,也可以创建一个空的工程,然后自己配置工程结构,就像我们使用MDK一样。此处我们以创建空工程为例子。
点击Empty project,输入工程名和路径,Next。
选择编译链,由于我们安装的是GNU ARM的工具链,所以选择对应的,然后指定工具链的路径。
创建好了之后,我们就可以看到下图的效果了,可以看到,这个工程完完全全是一个空的。现在我们向这个工程中添加文件,
就像我们之前在MDK环境下配置模版一样,先创建四个文件夹
然后从官方库文件中拷贝对应文件到该工程对应文件夹下。
需要注意的是,官方库文件中有一些文件是与编译环境相关的,官方提供的环境有一下几种
我们通过比较后发现,TrueSTUDIO和eclipse环境的工程文件格式是一样的,所以确定选用TrueSTDUIO工程的文件
首先是启动文件
然后还有链接文
件
这两个文件根据对应芯片容量决定。
文件拷贝完了后,将鼠标点到工程框中右键刷新,我们就可以看到工程结构更新了,如下图
正如在MDK环境下开发我们需要配置define项,include包含项和debug项一样,在eclipse也要做这些工作。
二、工程配置:
点击在工程浏览器中选中该工程,然后点击project->properties选择项,
就会弹出如下对话框,在这个对话框中主要在setting中配置,首先看看Tool setting,该选项有四块,即汇编(Assembler)选项,C编译器选型,C++编译器选项,链接选项,每一块中preprocessor用来设置预编译的,即设置define。includes用来设置路径包含的,所以启动文件等汇编文件要加到第一个选项块中,ld格式的链接文件要加到第四个块中
上面设置好了后,由于创建工程时我们已经设置了编译器,所以这个地方应该是正确的,如下图
点击应用,OK。
三、开始编译:
然而立马就出现下面的问题。
找不到make文件,通过查资料我们可以知道GNU Toolchain中是不自带make工具的,但是make工具其实都是一样的,所以我们能否使用Eclipse自带的make工具呢?
当然可以:
同样打开工程设置,点击Tool Chain Editor,选择Builder工具为CDT内部Builder,
然后重新编译,可以看到编译进度了,如果不行请先清楚编译,再编译一次。
然而又出错了。
这个问题的大致意思是这两个指令的调用格式不正确,但是由于这两条指令是汇编指令,他的调用格式是由编译器决定的,我们怎么知道他的正确的调用格式呢?我们先通过搜索找到这条指令调用的地方。
既然这条汇编指令的格式是由编译器决定的,那么我们怎么知道这条指令正确的格式呢?还记得之前创建工程时有现成的工程模版吗?我们可以创建一个现成的工程模版,然后编译发现这个现成的模版编译是没有问题。然后对比两个工程中的这条指令格式,我们发现了一个惊人的差异,如下图:
好了,问题找到了,在这两条指令的=r中间加上一个&符号即可。两条指令中都要加。然后再编译
编译通过,生成了可执行文件elf和hex。
然而我们将编译信息拉到右边后可以发现,编译没有问题,但是在链接时出现了问题。
即找不到Reset_Handler。怎么会找不到Reset_Handler呢,我们都知道Reset_Handler是在启动文件中定义了的,没有找到除非启动文件没有被编译。
于是我们来看看编译输出的文件夹,即debug文件夹。
发现只有3个文件夹有输出,启动文件确实没有输出,为什么呢?初步怀疑是Eclipse没有识别启动文件。
那么我们就需要知道eclipse究竟能够识别那些文件,我们打开窗体属性看看,即window->preferences:
然后找到File Type,我们可以看到,软件能够识别的汇编文件拓展为*.S是大写的S
而我们工程中的启动文件是小写的s,所以没有识别出来,我尝试将小写s格式添加进去发现添加失败,提示跟大写S重复,好吧,我们直接将启动文件改成大写S吧。
然后再编译,OK编译成功,也没有链接的错误。
四、开始调试:
编译完成后,我们就要进行下载和调试了。首先进行调试的配置。
Run->Debug Configurations。
我们可以看到GDB SEGGER Jlink Debugging选项下面是空的,双击这个选项
然后就新建了一个选项卡,设置debug的名称,调试的工程和源文件
切换到Debugger选项卡,此处才是关键。
在设置之前,我们普及一下关于调试的基本知识,这个只是不一定是标准的,只是我个人的一些理解。
我们都知道,调试实际就是我们的调试窗口与Jlink通讯,然后Jlink与开发板通讯,Jlink与开发板通讯是由Jlink GDBServerCL完成的,所以我们的调试窗口要与Jlink通讯,起始只需要与Jlink GDBServerCL通讯即可,那么是什么来代表这个调试窗口呢,那自然就是GNU工具链的GDB调试器了,所以我们整体的调试思路就清晰了,就是GNU GDB与Jlink GDBServerCL通讯,前者扮演客户端的角色,后者扮演服务器的角色。
好了,再来看看这个配置窗口,服务器设置自然选择Jlink GDBServerCL,而客户端自然选择GNU工具链中的GDB了,然后设置芯片型号,链接模式,传输速度等。
为了保险,取消掉startup中的这连个选项
好了,点击Debug开始调试,我们就可以看到我们的软件进入了调试模式,并且停留在了main函数的第一个有效行上面。
调试界面基本都是一样的,watch窗口也能调出来。设置断点,全速运行都行。
如果想结束调试,只需要点击上方的红色方块即可,此时Jlink的GDB会自动关闭,然后点击右侧的C/C++选项卡即可回到工程的编辑视图了。
OK,整个教程到此结束
上传一个LED闪烁的例子:
https://yunpan.cn/OcvADIXx2ZEzSH 访问密码 5c12
Demo3.zip (3.95 MB)
再来介绍一个可能会引发编译错误的问题
通过上面的内容,我们能够知道,eclipse的工程文件跟磁盘上面的文件是同步的,比如,在我们工程的目录所在文件夹中存在这样一个文件/lib/inc/a.c,那么通过reflash后,在我的工程中也必定会加入/lib/inc/a.c这样的文件,而不会MDK那样需要手动添加。
那么问题来了,如果在这个工程中我写了一个测试代码,保存为test.c,该文件也存放在工程目录中,但是由于他是一个测试代码,实际使用是并不需要,如果我们在eclipse中点击remove可能就直接从磁盘上删除了,此时,我们就需要给这个工程添加一个过滤器,将test.c过滤掉。
打开工程设置
找到这个地方
正如图中所说明的那样,第一级的文件夹表示这个文件夹会添加到工程中进行编译,第二级代表这个文件夹的过滤七,被过滤的文件或文件夹不会被编译的
现在添加一个过滤规则
然后回到工程看看效果
我们可以发现被过滤掉的文件上面有一个划线,表面该文件不会被编译的。
上一篇:JLINK给STM32下载的两种模式--jtag & sw连线及配置
下一篇:STM32 用jlink下载失败 环境配置
推荐阅读最新更新时间:2024-03-16 16:09