現(xiàn)在主要講解一下在GCC移植UCGUI，Makefile工程如何加入目錄，加入源碼，c標準庫，編譯選項的設置。

筆者的Makefile模板提取自uboot，工程中加入目錄，加入源碼都是很簡單的，詳細的介紹請參考前面章節(jié)” GCC啟動代碼工程應用實例”。下面主要介紹UCGUI目錄下很多的源碼文件Makefile的編寫，一種可行的方式就是把GUI目錄上所有的c文件，不管有無用到，均加入工程進行編譯，第一次編譯時間較長，但以后不用重復編譯。因此這部分的Makefile實現(xiàn)如下：

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，最終生成該目錄下的靜態(tài)庫文件，以供頂層目錄的Makefile鏈接輸出相應的可執(zhí)行代碼文件，工作方式與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二級編譯優(yōu)化或-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

設置庫，嵌入式開發(fā)很大程度上依賴于標準c庫。在linux操作系統(tǒng)下，標配的c庫為glibc，glibc囊括了幾乎所有的UNIX通行標準，可見其內容包羅萬象。因此glibc對于很多嵌入式系統(tǒng)來說過于臃腫和龐大，并且很多函數嚴重依賴于linux的系統(tǒng)調用。筆者在較老版本交叉編譯工具開發(fā)裸機代碼，可以鏈接glibc，但新版本的工具卻無法順利鏈接glibc。為了解決glibc在嵌入式應用中的不足，很多面向嵌入式的c標準庫已經被開發(fā)出來，如uclibc、newlib、eglibc等。這些嵌入式c庫特點就是比glibc小很多，相對獨立，可不需要操作系統(tǒng)支持，不支持glibc的完整實現(xiàn)，很多功能可以根據空間需求進行取舍。一般開發(fā)linux系統(tǒng)，可以用glibc，如果對代碼容量等方面有要求，也可使用嵌入式c庫。筆者測試用相同的UCGUI移植代碼分別鏈接uclibc和glibc，代碼容量差距相當明顯，鏈接uclibc時，可執(zhí)行代碼只有270k，而glibc達到700k。此處采用uclibc作為c庫，對于在linux下做開發(fā)而采用glibc的讀者，可以下載uclibc的最新源碼庫，通過make menuconfig簡單配置，用交叉編譯工具編譯源碼庫，即可生成交叉編譯工具可使用的c庫。嵌入式開發(fā)最常使用到字符處理、數學處理方面的庫函數，非linux操作系統(tǒng)開發(fā)，只能鏈接靜態(tài)庫，在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工程設置完畢，跳轉到頂層目錄，執(zhí)行make即可開始編譯工程。編譯時產生一大堆錯誤，主要是提示頭文件未找到，micrium給出的GUIDemo目錄下的測試代碼寫的不夠嚴謹，源代碼中include頭文件名不區(qū)分大小寫。例如實際要#include“GUI.h”，但有些源碼中是#include"GUI.H"，這對于windows來說是沒有區(qū)別的，因為windows文件系統(tǒng)不區(qū)分大小寫，但linux卻是區(qū)分大小的，因此會提示找不到文件。windows操作系統(tǒng)假定它的用戶是兒童，對一般用戶來說，apple和Apple都是蘋果，沒有區(qū)別。但linux/unix操作系統(tǒng)假定它的用戶是專業(yè)人士，apple和Apple雖然都是蘋果，但它們的大小、產地、口感等均是不同的，因此是有區(qū)別的。為了代碼的可重用，這些問題都是需要注意的，尤其是同時在windows和linux下做開發(fā)，應保證一定的規(guī)范性。如在windows下文件目錄名區(qū)分大小寫，在linux下文件名加后綴(如.c、.h)表示這個文件的用途等。此處沒有好的方法，只能修改GUIDemo下所有不區(qū)分頭文件名大小寫的源碼。

修改編譯通過后，會在頂層目錄生成三個比較重要的文件，ucgui.map為鏈接Mapping文件，這里可以看到各個全局符號、各個段內存鏈接位置、大小等信息。s3c2416.dis為工程的匯編生成文件，這是編譯器經過編譯所有的源碼并進行鏈接最終給出的匯編文件，這是最權威的查錯文件，編譯器的bug以及任何用戶的失誤造成編譯器未能很好地按照用戶的本意編譯等出現(xiàn)的問題，在這里都可以查找出。s3c2416.bin即為我們用來燒錄進SD卡或nand等存儲器的二進制代碼文件。

此處說明一點，筆者此系列的裸機例程都是有啟動代碼的，可以自動從sd/mmc卡、nand啟動的，代碼的燒錄與一般的bootloader的燒錄方式無異。最常用的燒錄方式是把裸機bin代碼通過SdBoot工具進行格式轉換，再通過三星sd卡燒寫工具IROM_Fusing_Tool把轉換后的bin代碼燒寫進sd卡，設置成sd卡啟動即可。從sd卡啟動成功后，通過調用相關的Nand模塊接口函數，實現(xiàn)代碼固化進Nand，以后即可從Nand啟動。詳細教程請參考筆者前面章節(jié)的” GCC啟動代碼工程應用實例”或” MDK啟動代碼工程應用實例”。

筆者采用了相同的UCGUI移植源碼在MDK、GCC下進行編譯，MDK和GCC均設置成二級優(yōu)化條件下，對比這兩個平臺下編譯器、標準c庫的差異。

編譯后，MDK下生成的二進制可執(zhí)行代碼大小為250k，而GCC在采用uclibc標準庫時可執(zhí)行代碼大小為273k，在老版本的GCC交叉編譯工具上，采用glibc生成的代碼大小為700k，從代碼容量看，MDK生成的代碼更小，采用GCC加uclibc并不比商業(yè)公司開發(fā)的平臺工具差很多。在linux下做嵌入式開發(fā)，對代碼容量、性能有要求的話，無特殊情況，采用嵌入式c庫如uclibc、newlib等更適合。

均把所有源碼加入工程中進行全部編譯，MDK下編譯時間需225秒，可以明顯看到提示窗口的源碼在一個一個編譯，GCC下編譯時間為42秒，源碼編譯時可看到窗口是在刷屏的，編譯速度不是MDK能比的。

此處并不能準確對比MDK與GCC代碼生成質量的優(yōu)劣，只能以UCGUI多層裁剪測試作為一個對比項。MDK生成的可執(zhí)行代碼裁剪打點速度為11526060 pixel/秒，而GCC生成的可執(zhí)行代碼打點速度為11985690 pixel/秒，打點速度GCC高出4%，可以看出開源免費的GCC編譯器以及c庫uclibc同樣高效優(yōu)越。

對比可以看出，GCC與MDK不分上下，某些方面GCC做的更好，如編譯速度。當然，MDK還有必殺技MicroLIB，這是MDK專為arm嵌入式應用高度優(yōu)化的庫，用了這個外掛庫后，任何其它編譯器的標準c庫都暗然失色，當然只能夠支持部分c庫的實現(xiàn)?？傮w來說，對于移植平臺多、開源免費的GNU軟件來說，能達到絲毫不輸商業(yè)軟件的性能，確實令人尊敬，選擇GNU軟件進行開發(fā)也是相當不錯的。

移植后的UCGUI效果：

對于ucgui的移植，總體還是比較簡單的，主要是根據特定的LCD和觸摸屏進行相應的接口移植，這只需要實現(xiàn)相應的LCD、觸摸屏驅動模塊即可。如果讀者在windows下進行過win32窗口編程(非MFC)，那么對于ucgui的界面編程也會是得以應手的。

ucgui_MDK.rar，MDK平臺下的UCGUI 3.98版移植源碼工程，需根據特定LCD、觸摸屏進行驅動模塊的更改。

http://pan.baidu.com/s/1eQvcNWe

u