首页 > 代码库 > S3C2416裸机开发系列十四_GCC下UCGUI的移植(2)

S3C2416裸机开发系列十四_GCC下UCGUI的移植(2)

2024-07-03 05:07:30 224人阅读

S3C2416裸机开发系列十四

GCC下UCGUI的移植(2)

象棋小子 1048272975

现在主要讲解一下在GCC移植UCGUI，Makefile工程如何加入目录，加入源码，c标准库，编译选项的设置。

笔者的Makefile模板提取自uboot，工程中加入目录，加入源码都是很简单的，详细的介绍请参考前面章节” GCC启动代码工程应用实例”。下面主要介绍UCGUI目录下很多的源码文件Makefile的编写，一种可行的方式就是把GUI目录上所有的c文件，不管有无用到，均加入工程进行编译，第一次编译时间较长，但以后不用重复编译。因此这部分的Makefile实现如下：

include $(TOPDIR)/config.mk

SRCS := $(wildcard *.c)$(wildcard *.C)

OBJS := $(SRCS:.c=.o)$(SRCS:.C=.o)

CURDIR := $(shell pwd)

FOLDER := $(notdir $(CURDIR))

LIB := lib$(FOLDER).a

.PHONY: all clean

all: .depend $(LIB)

$(LIB): $(OBJS)

@$(AR) $(ARFLAGS) $@ $(OBJS)

clean:

rm -f .depend *.o $(LIB)

#########################################################################

# defines$(obj).depend target

include$(TOPDIR)/rules.mk

sinclude .depend

#########################################################################

把这个Makefile模板加入到GUI下所有的子目录和GUIDemo目录中，其它目录的Makefile也类似编写加入，这样即可把所有要编译的源码加入工程。每个子目录的Makefile需加入该目录下要编译的源码文件，生成该目录下的源码依赖关系文件.depend，最终生成该目录下的静态库文件，以供顶层目录的Makefile链接输出相应的可执行代码文件，工作方式与uboot是完全一致的。

修改顶层目录的Makefile，加入各个子目录Makefile的路径，以调用编译该目录下的源码。子目录路径SUBDIRS变量的修改如下:

SUBDIRS = $(TOPDIR)/start_code $(TOPDIR)/apps

SUBDIRS += $(TOPDIR)/GUI/AntiAlias $(TOPDIR)/GUI/ConvertColor \

$(TOPDIR)/GUI/ConvertMono $(TOPDIR)/GUI/Core \

$(TOPDIR)/GUI/Font $(TOPDIR)/GUI/LCDDriver \

$(TOPDIR)/GUI/MemDev $(TOPDIR)/GUI/MultiLayer \

$(TOPDIR)/GUI/Widget $(TOPDIR)/GUI/WM

SUBDIRS += $(TOPDIR)/GUI_X $(TOPDIR)/GUIDemo

修改顶层目录的config.mk，对编译选项如-O2二级编译优化或-g加入调试等进行设置，此处需加入工程c编译器的头文件的搜索路径，对于UCGUI头文件搜索路径只需加入Config、GUI/Core、GUI/Widget、GUI/WM这四个目录路径即可。头文件搜索路径CFLAGS变量的修改如下，s3c2416没有硬件浮点单元，加-msoft-float防止配置成只支持硬浮点的交叉工具通过编译。

CFLAGS := -Wall -Wstrict-prototypes -mcpu=arm920t -msoft-float

CFLAGS += -I $(TOPDIR)/start_code -I$(TOPDIR)/apps

CFLAGS += -I $(TOPDIR)/GUI/Core -I$(TOPDIR)/GUI/Widget \

-I $(TOPDIR)/GUI/WM -I $(TOPDIR)/Config

CFLAGS += -I $(TOPDIR)/GUIDemo

设置库，嵌入式开发很大程度上依赖于标准c库。在linux操作系统下，标配的c库为glibc，glibc囊括了几乎所有的UNIX通行标准，可见其内容包罗万象。因此glibc对于很多嵌入式系统来说过于臃肿和庞大，并且很多函数严重依赖于linux的系统调用。笔者在较老版本交叉编译工具开发裸机代码，可以链接glibc，但新版本的工具却无法顺利链接glibc。为了解决glibc在嵌入式应用中的不足，很多面向嵌入式的c标准库已经被开发出来，如uclibc、newlib、eglibc等。这些嵌入式c库特点就是比glibc小很多，相对独立，可不需要操作系统支持，不支持glibc的完整实现，很多功能可以根据空间需求进行取舍。一般开发linux系统，可以用glibc，如果对代码容量等方面有要求，也可使用嵌入式c库。笔者测试用相同的UCGUI移植代码分别链接uclibc和glibc，代码容量差距相当明显，链接uclibc时，可执行代码只有270k，而glibc达到700k。此处采用uclibc作为c库，对于在linux下做开发而采用glibc的读者，可以下载uclibc的最新源码库，通过make menuconfig简单配置，用交叉编译工具编译源码库，即可生成交叉编译工具可使用的c库。嵌入式开发最常使用到字符处理、数学处理方面的库函数，非linux操作系统开发，只能链接静态库，在linux下对应库名为libc.a和libm.a。由于不使用glibc，因此标准c库应指定uclibc的库存放路径。同时，对于没有硬件除法器，浮点处理单元的arm，对取余和除法操作，浮点处理都需要libgcc.a的支持。UCGUI移植用到了这三个库，因此需要在Makefile中指定这三个库的路径，库路径设置如下，对于uclibc中的libc.a和libm.a库路径，需要读者根据自己的嵌入式库路径进行修改。

PLATFORM_LIBS :=

# 加入uclibc标准c库以及数学函数库

PLATFORM_LIBS += -L /opt/crosstool/uClibc-0.9.33.2/lib -lm -lc

# 加入gcc库

PLATFORM_LIBS += -L $(shell dirname `$(CC) $(CFLAGS)-print-libgcc-file-name`) –lgcc

至此，Makefile工程设置完毕，跳转到顶层目录，执行make即可开始编译工程。编译时产生一大堆错误，主要是提示头文件未找到，micrium给出的GUIDemo目录下的测试代码写的不够严谨，源代码中include头文件名不区分大小写。例如实际要#include“GUI.h”，但有些源码中是#include"GUI.H"，这对于windows来说是没有区别的，因为windows文件系统不区分大小写，但linux却是区分大小的，因此会提示找不到文件。windows操作系统假定它的用户是儿童，对一般用户来说，apple和Apple都是苹果，没有区别。但linux/unix操作系统假定它的用户是专业人士，apple和Apple虽然都是苹果，但它们的大小、产地、口感等均是不同的，因此是有区别的。为了代码的可重用，这些问题都是需要注意的，尤其是同时在windows和linux下做开发，应保证一定的规范性。如在windows下文件目录名区分大小写，在linux下文件名加后缀(如.c、.h)表示这个文件的用途等。此处没有好的方法，只能修改GUIDemo下所有不区分头文件名大小写的源码。

6. 代码烧录

修改编译通过后，会在顶层目录生成三个比较重要的文件，ucgui.map为链接Mapping文件，这里可以看到各个全局符号、各个段内存链接位置、大小等信息。s3c2416.dis为工程的汇编生成文件，这是编译器经过编译所有的源码并进行链接最终给出的汇编文件，这是最权威的查错文件，编译器的bug以及任何用户的失误造成编译器未能很好地按照用户的本意编译等出现的问题，在这里都可以查找出。s3c2416.bin即为我们用来烧录进SD卡或nand等存储器的二进制代码文件。

此处说明一点，笔者此系列的裸机例程都是有启动代码的，可以自动从sd/mmc卡、nand启动的，代码的烧录与一般的bootloader的烧录方式无异。最常用的烧录方式是把裸机bin代码通过SdBoot工具进行格式转换，再通过三星sd卡烧写工具IROM_Fusing_Tool把转换后的bin代码烧写进sd卡，设置成sd卡启动即可。从sd卡启动成功后，通过调用相关的Nand模块接口函数，实现代码固化进Nand，以后即可从Nand启动。详细教程请参考笔者前面章节的” GCC启动代码工程应用实例”或” MDK启动代码工程应用实例”。

7. 编译工具性能对比

笔者采用了相同的UCGUI移植源码在MDK、GCC下进行编译，MDK和GCC均设置成二级优化条件下，对比这两个平台下编译器、标准c库的差异。

7.1. 代码容量

编译后，MDK下生成的二进制可执行代码大小为250k，而GCC在采用uclibc标准库时可执行代码大小为273k，在老版本的GCC交叉编译工具上，采用glibc生成的代码大小为700k，从代码容量看，MDK生成的代码更小，采用GCC加uclibc并不比商业公司开发的平台工具差很多。在linux下做嵌入式开发，对代码容量、性能有要求的话，无特殊情况，采用嵌入式c库如uclibc、newlib等更适合。

7.2. 编译速率

均把所有源码加入工程中进行全部编译，MDK下编译时间需225秒，可以明显看到提示窗口的源码在一个一个编译，GCC下编译时间为42秒，源码编译时可看到窗口是在刷屏的，编译速度不是MDK能比的。

7.3. 代码生成质量

此处并不能准确对比MDK与GCC代码生成质量的优劣，只能以UCGUI多层裁剪测试作为一个对比项。MDK生成的可执行代码裁剪打点速度为11526060 pixel/秒，而GCC生成的可执行代码打点速度为11985690 pixel/秒，打点速度GCC高出4%，可以看出开源免费的GCC编译器以及c库uclibc同样高效优越。

对比可以看出，GCC与MDK不分上下，某些方面GCC做的更好，如编译速度。当然，MDK还有必杀技MicroLIB，这是MDK专为arm嵌入式应用高度优化的库，用了这个外挂库后，任何其它编译器的标准c库都暗然失色，当然只能够支持部分c库的实现。总体来说，对于移植平台多、开源免费的GNU软件来说，能达到丝毫不输商业软件的性能，确实令人尊敬，选择GNU软件进行开发也是相当不错的。

移植后的UCGUI效果：