Xây dựng môi trường phát triển tích hợp có giao diện đồ họa trên linux cho uclinux trên vi xử lý motorola dragonball vz328

Do đó, mục tiêu của đề tài này là hiện thực một công cụ phát triển ứng dụng có giao diện đồ họa cho uClinux... Bây giờ, ta hãy phân tích quy trình phát triển một ứng dụng cho uClinux, vi

Cán bộ hướng dẫn khoa học: TS Lê Ngọc Minh

Cán bộ chấm nhận xét 1: TS Thoại Nam

Các bộ chấm nhận xét 2: TS Trần Viết Huân

Luận văn thạc sĩ được bảo vệ tại HỘI ĐỒNG CHẤM BẢO VỆ LUẬN VĂN THẠC SĨ TRƯỜNG ĐẠI HỌC BÁCH KHOA, ngày 24 tháng 07 năm 2006

Trước tiên, tôi xin chân thành cảm ơn TS Lê Ngọc Minh đã nhiệt tình hướng dẫn và định hướng để tôi hoàn thành luận văn này

Cảm ơn Ba, Mẹ luôn động viên tinh thần và khuyến khích tôi hoàn thành tốt luận văn Xin chân thành cảm ơn các bạn Nguyễn Thanh Hiên và Nguyễn Anh Kiệt đã cho tôi những ý kiến quý báu về đề tài

Xin cám ơn bạn Hồ Văn Trọng và Hà Thủy Tú, những kiến thức và kinh nghiệm của các bạn đã giúp tôi rất nhiều

Cuối cùng, xin cảm ơn Thu Hiền, em đã động viên, khuyến khích và góp ý cho tôi rất nhiều trong việc thực hiện đề tài

TÓM TẮT

Ngày nay, hệ thống nhúng có mặt ở khắp mọi nơi Thật ra, chúng ta gặp rất nhiều hệ thống nhúng trong cuộc sống hằng ngày mà chúng ta có thể không nhận ra Chúng xuất hiện ở nhiều hình dạng và kích thuớc, từ những thiết bị điều khiển từ xa cho tới máy tính trong xe hơi Những thiết bị này quá thông dụng đến nỗi chúng ta hoàn toàn không thể nhận ra rằng chúng ta đang giao tiếp với máy tính

Nếu so với PC (Personal Computer), vai trò của hệ điều hành trong một hệ thống nhúng cũng không kém tầm quan trong Những hệ điều hành này cho phép chúng ta đưa những tính năng thường thấy ở những thiết bị lớn vào những vật dụng phổ biến như đầu máy video (Video Cassette Recorder - VCR) với chi phí thấp Chính điều này tạo nên một trong những tính chất hấp dẫn của thiết bị nhúng, đó là sự đa dạng cả về kích thước vật lý lẫn sức mạnh tính toán Hiện nay trên thị trường có nhiều

hệ điều hành cho các thiết bị nhúng và một trong số đó là uClinux

Tuy nhiên, hiện nay, những công cụ hỗ trợ việc phát triển ứng dụng cho uClinux rất hạn chế, việc phát triển ứng dụng cho uClinux vẫn còn được thực hiện trên console

và những công cụ không chuyên biệt Điều này khiến cho việc phát triển ứng dụng cho uClinux trở nên khó khăn

Do đó, mục tiêu của đề tài này là hiện thực một công cụ phát triển ứng dụng có giao diện đồ họa cho uClinux

ii

ABSTRACT

Embedded systems are everywhere In fact, you touch more embedded systems

in your everyday life than you probably realize They come in many shapes and sizes, from the TV remote control to the “engine computer” in your car These devices are in fact so prevalent that you do not even realize that you are interacting with a computer

at all

Like PC, the role of operating system in embedded system is not less important The operating systems help embedded systems have their power There are many operating systems for embedded systems and uClinux is just one of them

However, now, the tools supporting for developing applications for uClinux are not good A generic text editor and command line shell are the common tools used by the majority of uClinux developers

So, the target of this thesis is developing a supporting tool for developing uClinux applications

iii

MỤC LỤC

1 GIỚI THIỆU 8

1.1 Tổng quan 8

1.2 Cấu trúc luận văn 10

2 MAKEFILE & NGÔN NGỮ CẤU HÌNH 12

2.1 Makefile 12

2.1.1 Nội dung của một Makefile 12

2.1.2 Những Rule và Target của Makefile 13

2.1.3 Phony Target 14

2.2 Ngôn ngữ cấu hình 15

2.2.1 Quy ước trong ngôn ngữ cấu hình 16

2.2.2 Những phát biểu (statements) có trong ngôn ngữ config 16

3 PHÁT TRIỂN ỨNG DỤNG CHO UCLINUX 19

3.1 Cấu trúc thư mục của uClinux-dist 19

3.2 Những target cơ bản của top Makefile 20

3.3 Target config 21

3.4 Target dep 23

3.5 Target all 23

3.5.1 Target subdirs 24

3.5.1.1 Target linux 25

3.5.1.2 Target subdirs 26

3.5.2 Target romfs 27

iv

3.5.3 Target modules 28

3.5.4 Target modules_install 29

3.5.5 Target image 30

4 ECLIPSE 31

4.1 Giới thiệu 31

4.2 Những khái niệm căn bản 32

4.2.1 Workbench 32

4.2.2 Resources 32

4.2.3 Editor 33

4.2.4 View 33

4.2.5 Wizard 33

4.2.6 Perspective 33

4.3 Kiến trúc của Eclipse Platform 34

4.3.1 Platform Runtime 35

4.3.2 Workspace 35

4.3.3 Workbench 36

4.3.4 Team support 37

4.3.5 Help 37

4.4 Eclipse plug-in 37

4.4.1 Tổng quan về Eclipse plug-in 37

4.4.1.1 Dependency 39

4.4.1.2 Extension 40

4.4.2 Extension point 40

5 CÁC CÔNG CỤ LIÊN QUAN 43

5.1 YETI 43

5.1.1 Giới thiệu 43

5.1.2 TinyOS và nesC 43

5.1.3 YETI 44

5.1.3.1 Plug-in System 44

5.1.3.2 TinyOS Environment Wrapper 46

5.2 Sử dụng Eclipse như là IDE cho uClinux 46

5.2.1 Ưu điểm của phương pháp 46

5.2.2 Khuyết điểm 47

6 PHƯƠNG HƯỚNG GIẢI QUYẾT VẤN ĐỀ 48

6.1 Chức năng cấu hình 49

6.1.1 Thể hiện câu hỏi 49

6.1.2 Thể hiện câu trả lời 50

6.1.3 Sự phụ thuộc giữa các câu hỏi 51

6.2 Chức năng tạo dependency 53

6.3 Chức năng tạo file image 53

6.4 Chức năng tạo project 54

6.4.1 Tạo project và file header 54

6.4.2 Tạo file source code 54

6.5 Editor 55

6.6 Chức năng hỗ trợ khác 55

7 HIỆN THỰC 56

7.1 Kiến trúc uClinux plug-in 56

7.2 Usecase diagram 58

7.3 Class diagram 59

7.3.1 Package uClinux 59

7.3.2 Package uClinux.utilities 61

7.3.3 Package uClinux.model.configuration 62

vi

7.3.4 Package uClinux.action 63

7.3.5 Package uClinux.ui.dialog 63

7.3.6 Package uClinux.ui.preferences 64

7.3.7 Package uClinux.ui.perspectives 64

7.3.8 Package uClinux.ui.wizards 65

8 KẾT LUẬN VÀ PHƯƠNG HƯỚNG MỞ RỘNG 66

8.1 Kết luận 66

8.2 Những hạn chế của đề tài 68

8.3 Phương hướng mở rộng 69

TÀI LIỆU THAM KHẢO 71

PHỤ LỤC 75

A uClinux 75

B Motorola DragonBall VZ328 75

C Toolchain 76

vii

DANH MỤC HÌNH

Hình 1.1: Cấu hình cho uClinux 9

Hình 3.1: Sơ đồ mô tả quy trình build ứng dụng trên uClinux 19

Hình 3.2: Sơ đồ mô tả quá trình cấu hình uClinux .22

Hình 3.3: Sơ đồ hoạt động của target dep 23

Hình 3.4: Trình tự thục thi của target all 24

Hình 3.5: Sơ đồ hoạt động của target linux 25

Hình 3.6: Sơ đồ hoạt động của target subdirs 26

Hình 3.7: Sơ đồ hoạt động của target romfs 27

Hình 3.8: Sơ đồ hoạt động của target modules 28

Hình 3.9: Sơ đồ hoạt động của target modules_install 29

Hình 3.10: Sơ đồ hoạt động của target image 30

Hình 4.1: Hình ảnh minh họa các khái niệm trong Eclipse 34

Hình 4.2: Kiến trúc của Eclipse platform 35

Hình 4.3: Sự mở rộng workbench UI bằng plug-in help của workbench thông qua actionSets extension point 42

Hình 5.1: Outline 44

Hình 5.2: Đồ thị của một ứng dụng TinyOS ở hai mức độ chi tiết 45

Hình 7.1: Sơ đồ kiến trúc của uClinux plug-in 56

Hình 7.2: Usecase diagram 59

Hình 7.3: Class diagram của package uClinux 60

Hình 7.4: Class diagram của package uClinux.utilities 61

Hình 7.5: Class diagram của package uClinux.model.configuration 62

Hình 7.6: Class diagram của package uClinux.action 63

Hình 7.7: Class diagram của package uClinux.ui.dialog 63

Hình 7.8: Class diagram của package uClinux.ui.preferences 64

Hình 7.9: Class diagram của package uClinux.ui.perspectives 64

Hình 7.10: Class diagram của package uClinux.ui.wizards 65

Hình 8.1: Giao diện của chương trình 66

Hình 8.2: Wizard cho tác vụ “make config” 67

Hình 8.3: Wizard tạo project mới 68

CHƯƠNG 1 GIỚI THIỆU

1.1 Tổng quan

Đối với hệ điều hành Windows hay Linux, việc tiến hành viết chương trình chạy

trên những hệ điều hành này tương đối thuận tiện vì chúng ta có những công cụ phát

triển có giao diện đồ họa như: Visual Studio cho Windows hay KDevelop cho Linux

Những công cụ này cung cấp cho chúng ta chức năng soạn thảo, biên dịch, debug trên

một môi trường đồ họa dễ sử dụng, thân thiện Tuy nhiên, đối với uClinux, việc tiến

hành viết một chương trình lại không được dễ dàng như vậy

Chúng ta hãy nhìn lại cách thức phát triển ứng dụng bằng Java thời kỳ ban đầu,

khi chưa có các IDE (Intergrated Development Environment) hỗ trợ Khi đó, để phát

triển ứng dụng bằng Java, ta phải:

- Sử dụng một chương trình soạn thảo văn bản để viết chương trình

- Sử dụng lệnh javac để compile chương trình

- Sử dụng lệnh java để thực thi chương trình

Bây giờ, ta hãy phân tích quy trình phát triển một ứng dụng cho uClinux, việc

phát triển ứng dụng cho uClinux sẽ phải trải qua các bước sau:

- Viết chương trình: Bước này được thực hiện bằng cách sử dụng các chương

trình soạn thảo như vi, emacs, …

- Thêm chương trình vừa viết vào trong hệ thống các ứng dụng của uClinux.1

- Tiến hành cấu hình cho uClinux Ở bước này, người sử dụng sẽ cung cấp

thông tin cho uClinux bằng cách trả lời các câu hỏi Như mô tả trong hình 1.1

- Tiến hành tạo dependency, chuẩn bị cho việc build kernel ở bước sau

- Tiến hành build kernel, compile các ứng dụng Cuối cùng là tạo file image

để chuẩn bị cho việc download vào target ở bước sau

1 Xin tham khảo thêm phần [1]

- Tiến hành download file image vào target và thực thi chương trình.1

Hình 1.1: Cấu hình cho uClinux

Từ đó, ta thấy việc phát triển ứng dụng cho uClinux hiện nay cũng gặp vấn đề

giống như đối với Java Đó là:

- Ngoại trừ việc viết chương trình, tất cả các bước compile, build, thực thi đều

được tiến hành trên console, không phải là một môi trường tương tác tốt đối

với người sử dụng

- Những công cụ dùng để thực hiện các bước trên đều là những công cụ tách

biệt, không tiện lợi cho người sử dụng

1 Xin tham khảo trong [13]

Tuy nhiên, hiện nay, với sự xuất hiện các IDE hỗ trợ Java như JBuilder,

JDeveloper, Eclipse, … việc lập trình bằng ngôn ngữ Java đã trở nên dễ dàng và tiện

lợi hơn rất nhiều Thế nhưng cho đến nay, những người phát triển ứng dụng cho

uClinux vẫn chưa có được một IDE, một công cụ hỗ trợ hiệu quả cho công việc của

mình., một công cụ tích hợp cung cấp tất cả các chức năng cần thiết trong việc phát

triển ứng dụng với uClinux và đồng thời hỗ trợ giao diện đồ họa cho người sử dụng

Để giúp giải quyết phần nào những khó khăn mà những người làm việc với

uClinux đang gặp phải, đề tài này sẽ hiện thực một công cụ có giao diện đồ họa hỗ trợ

cho việc phát triển ứng dụng cho uClinux

Tuy nhiên, việc phát triển từ đầu một công cụ như vậy trong thời gian có hạn

của đề tài là điều rất khó khăn Do đó, chúng ta sẽ tận dụng những công cụ có sẵn và

bổ sung những chức năng cần thiết cho công cụ này Và công cụ đó là Eclipse, một

IDE có khả năng mở rộng chức năng Việc sử dụng Eclipse để hiện thực những công

cụ hỗ trợ việc phát triển phần mềm hiện nay đang phát triển khá là mạnh mẽ, trong đó,

những công cụ hỗ trợ cho việc phát triển ứng dụng cho những hệ thống nhúng trên nền

Eclipse cũng có khá nhiều Như là:

- TinyOS, một plug-in hỗ trợ việc phát triển ứng dụng cho hệ đều hành TinyOS

Đây là một hệ điều hành mã nguồn mở (open-source operating system) được thiết

kế cho mạng cảm ứng nhúng không dây (wireless embedded sensor networks)

- KPIT CORONA, một plug-in được phát triển dựa trên Eclipse V3.1.1 và CDT

3.0.1, hỗ trợ cho việc phát triển ứng dụng trên dòng microcontroller 16-bit

XC166, tích hợp simulator, version control (CVS), …

1.2 Cấu trúc của luận văn

Luận văn được tổ chức như sau:

- Chương 2 trình bày về những công cụ đang được sử dụng trong quá trình

phát triển ứng dụng cho uClinux: Makefile và ngôn ngữ cấu hình

(configuration language)

- Chương 3 trình bày về quy trình cấu hình uClinux, tạo dependency cho

kernel và tạo file image cho uClinux

- Chương 4 trình bày về công cụ được chọn để tiến hành hiện thực luận văn,

Eclipse

- Chương 5 trình bày về phương hướng giải quyết vấn đề

- Chương 6 trình bày tổng quát về việc hiện thực đề tài

- Chương 7 trình bày kết quả đạt được, những hạn chế của đề tài và phương

hướng mở rộng tiếp theo

CHƯƠNG 2 MAKEFILE & NGÔN NGỮ CẤU

HÌNH (CONFIGURATION LANGUAGE)

2.1 Makefile1

Việc build một chương trình khác với compile một chương trình ở chỗ, build

không chỉ compile mà còn thực hiện nhiều tác vụ khác như tạo môi trường link các thư

viện, … Do đó, việc build phức tạp hơn việc compile rất nhiều Trong Linux, để build

một chương trình, chúng ta sẽ tạo ra một tập tin văn bản, thường file này có tên là

Makefile Trong tập tin này chúng ta sẽ mô tả cách thức build một chương trình và

make sẽ sử dụng tập tin này như input để tiến hành build chương trình

2.1.1 Nội dung của một Makefile

Như đã nói ở trên, Makefile là một file văn bản cho make biết cách thức biên dịch và liên kết chương trình

Trong Makefile ta có thể có:

¾ Rule: Cho ta biết khi nào và bằng cách nào tạo ra hoặc update một hoặc

nhiều file (target của rule)

¾ Định nghĩa biến (variable definition): Là một dòng trong Makefile, xác

định giá trị chuỗi cho một biến, giá trị này có thể được dùng trong những

phần sau của Makefile

Biến trong Makefile được xác định bằng cách dùng ký tự ‘$’ Ví dụ:

$(A), có nghĩa là tham khảo biến A

¾ Directive: Là một lệnh yêu cầu make thực hiện một task đặc biệt trong khi

đọc Makefile Task đó bao gồm:

1 Để hiểu thêm về Makefile, xin tham khảo [12]

o Đọc một Makefile khác

o Dựa trên giá trị của các biến, quyết định việc sử dụng hay bỏ qua một

phần của Makefile

o Định nghĩa một biến bằng cách sử dụng directive define

¾ Comment: Một comment trong Makefile bắt đầu bằng ký tự ‘#’ Bản thân

ký tự này và phần còn lại của dòng sẽ được bỏ qua Comment có thể xuất

hiện ở một dòng bất kỳ của Makefile, ngoại trừ dòng lệnh define Một dòng

lệnh mà có chứa một comment thì được xem như rỗng và sẽ được bỏ qua

2.1.2 Những Rule và Target của Makefile

Một rule trong Makefile sẽ cho make biết cách thức thực thi một chuỗi các lệnh để build file target từ file nguồn Nó cũng xác định một danh sách các

phụ thuộc (dependencies) của file target Danh sách này nên bao gồm tất cả các

file được sử dụng như là input cho những lệnh trong rule

Một rule đơn giản có dạng như sau:

target : dependencies

command

Một target thường là tên của một file được tạo ra bởi chương trình, ví dụ

của target là những file thực thi hay file object Một target cũng có thể là tên của

một action, như là ‘clean’

Một dependency là một file được dùng như input để tạo ra target Một

target thường phụ thuộc vào nhiều file Trong trường hợp target là tên của action

thì dependency cũng sẽ là tên của một action, khi đó, việc thi hành target sẽ được

diễn ra sau khi dependency được thi hành

Một command là một action mà make sẽ thực thi Một rule có thể có

nhiều hơn một command, mỗi command sẽ được viết trên một dòng của Makefile

Thông thường, một command nằm trong một rule cùng với dependency và được

dùng để tạo target file nếu có bất kì một dependency thay đổi Tuy nhiên, rule xác

định command cho target không cần có dependency

Một rule sẽ giải thích cách thức và thời điểm tạo ra hoặc cập nhật những file là target của rule Make thực thi những command trên dependency để tạo ra

hoặc cập nhật target Một rule cũng có thể giải thích cách thức và thời điểm thực

thi action

Trong một Makefile có thể còn những thứ khác ngoài rule, nhưng một Makefile đơn giản chỉ cần chứa rule Rule trong Makefile có thể phức tạp hơn

dạng được nêu ra ở trên, nhưng nhìn chung, nó cũng phù hợp với dạng thức đó

Bình thường, chúng ta thường gặp nhất là một rule chỉ có một target Tuy nhiên, trong nhiều trường hợp đặc biệt, chúng ta có thể gặp trường hợp một rule

có nhiều target và một target có nhiều rule

Một phony target là một target có tên không phải là tên của file Nó chỉ là

tên cho một vài command sẽ được thực thi khi bạn đưa ra một yêu cầu cụ thể Có

hai lý do để dùng phony target: Để tránh việc xung đột với file có cùng tên, và để

cải thiện hiệu suất

Nếu bạn viết một rule có command không tạo ra file target, command này sẽ được thực thi mỗi lần target được “gọi” Ví dụ:

Phony target trên sẽ ngừng hoạt động nếu có một file tên ‘clean’ được tạo

ra trong thư mục này Bởi vì rule này không có dependency, file ‘clean’ chắc chắn

sẽ được xem như là đã được cập nhật và những command của nó sẽ không được

thực thi Để tránh trường hợp này xảy ra, bạn có thể khai báo rằng target là phony

một cách tường minh, bằng cách sử dụng target đặc biệt PHONY như sau:

.PHONY: clean clean:

Nếu thực hiện như vậy thì lệnh ‘make clean’ sẽ thực thi những lệnh trong rule, bất kể file mang tên ‘clean’ có tồn tại hay là không

2.2 Ngôn ngữ cấu hình 1 (Configuration language)

Trước khi tiến hành build kernel cho Linux, cũng như đối với uClinux, chúng ta phải xác lập một tập hợp các giá trị, những giá trị này sẽ xác định kết cấu

và chức năng của kernel Những thông tin để tiến hành cấu hình thường được ghi

vào file config.in hay Config.in, những thông tin này được viết bằng ngôn ngữ cấu

hình, chương trình cấu hình cho hệ thống sẽ đọc những file này để giao tiếp với

người sử dụng trong việc thu thập thông tin hỗ trợ trong quá trình build kernel

Sau đó, thông tin có được sẽ được ghi ra file

Mặc dù ngôn ngữ cấu hình (xin được gọi tắt là ngôn ngữ config) có vẻ giống như một tập con của ngôn ngữ shell, nhưng không phải, chúng có cú pháp

và ngữ nghĩa khác với shell Vì chúng ta có thể phải cấu hình kernel, modules, …

cho uClinux trước khi chúng ta deploy ứng dụng trong khi đó quá trình cấu hình

này sẽ sử dụng ngôn ngữ config Do đó, trong phần này chúng ta sẽ tìm hiểu một

cách sơ lược về ngôn ngữ config

1 Xin tham khảo thêm trong [3]

2.2.1 Quy ước trong ngôn ngữ cấu hình

Ký tự ‘\’ ở cuối dòng cho biết câu lệnh còn tiếp tục ở dòng tiếp theo

Ký tự ‘#’ thường dùng cho comment, comment này bắt đầu từ vị trí của

‘#’ đến hết dòng Tuy nhiên, những dòng có dạng ‘# … is not set’ thì không phải

là comment

/prompt/ là một chuỗi ký tự được bao bằng dấu nháy đơn (‘) hoặc dấu

nháy kép (“)

/word/ là một từ đơn (single unquoted word), một từ được bao bằng dấu

nháy đơn, hoặc dấu nháy kép

/symbol/ là một single unquoted word Một symbol phải có tên theo dạng

CONFIG_*

/dep/ dùng để chỉ sự phụ thuộc Nó là một /word/ Lúc runtime, một /dep/

phải có giá trị là “y”, “m”, “n” hoặc “”

/expr/ là một biểu thức sử dụng các toán tử ‘=’, ‘!=’, ‘-a’, ‘-o’ và ‘!’

2.2.2 Những phát biểu (statements) có trong ngôn ngữ config

Ngôn ngữ Config xác định 18 statement đơn giản, 1 ‘if’ statement, 1

‘source’ statement, những ‘menu’ statement Các statement được phân thành

nhóm như sau:

¾ Text statement: Những statement này hiển thị /prompt/ như là câu thông

báo cho người sử dụng, bao gồm:

- mainmenu_name /prompt/

- comment /prompt/

- text /prompt/

¾ Ask statement: Những statement này sẽ hiển thị /prompt/ và cho phép

người dùng nhập thông tin cho /symbol/ Chúng bao gồm:

- bool /prompt/ /symbol/

- hex /prompt/ /symbol/ /word/

- int /prompt/ /symbol/ /word/

- string /prompt/ /symbol/ /word/

- tristate /prompt/ /symbol/

¾ Define statement: Những statement thuộc nhóm này dùng để gán giá trị

/word/ cho /symbol/

- define_bool /symbol/ /word/

- define_hex /symbol/ /word/

- define_int /symbol/ /word/

- define_string /symbol/ /word/

- define_tristate /symbol/ /word/

¾ Dependent statement: Với những statement này, giá trị của /symbol/ sẽ phụ

thuộc vào danh sách các /dep/

- dep_bool /prompt/ /symbol/ /dep/ …

- dep_mbool /prompt/ /symbol/ /dep/ …

- dep_tristate /prompt/ /symbol/ /dep/ …

¾ Unset statement: Khi ta cần gán giá trị rỗng cho /symbol/, ta sẽ dùng phát

biểu unset

- unset /symbol/

¾ Choice statement: Phát biểu này được dùng để biểu diễn một danh sách các

lựa chọn cho user

- /prompt/ /word/ /symbol/ {/word/ /symbol/}*

¾ If statement: Đây là một phát biểu điều kiện

- if [/expr/]; then

/statement/

…

fi

¾ Source statement: Phát biểu này được sử dụng trong việc đọc nội dung của

file có tên được xác định bởi /word/

CHƯƠNG 3 PHÁT TRIỂN ỨNG DỤNG CHO

UCLINUX

Việc phát triển ứng dụng cho uClinux được tiến hành theo các bước sau:

1 Viết chương trình Công việc này sẽ được thực hiện bằng các trình soạn

thảo như vi, egit, emacs, …

2 Building

3 Upload file image lên thiết bị để thực thi

Trong đề tài này, chúng ta chỉ tập trung vào bước thứ 2, building Quy trình hoạt

động của bước building có thể được mô tả như sau:

Hình 3.1: Sơ đồ mô tả quy trình build ứng dụng trên uClinux

3.1 Cấu trúc thư mục của uClinux-dist

Sau khi hoàn tất việc cài đặt uClinux, chúng ta sẽ có được thư mục và

uClinux-dist Cấu trúc thư mục của uClinux-dist bao gồm:

¾ Makefile: Makefile này đóng vai trò hết sức quan trọng trong việc điều khiển

quá trình phát triển ứng dụng cho uClinux Tất cả các tác vụ trong việc

building đều được mô tả trong Makefile này Từ bây giờ, ta sẽ gọi Makefile

này là top Makefile để phân biệt với các Makefile trong các thư mục khác

¾ config: Thư mục config chứa các script và Makefile cần thiết cho việc

config

¾ vendors: Vì uClinux thực chất chỉ là một hệ điều hành, nên khi phát triển

ứng dụng trên uClinux, ta cũng cần biết ứng dụng của chúng ta sẽ hoạt động

trên thiết bị nào Trên thị trường hiện nay có nhiều nhà sản xuất các thiết bị

nhúng và mỗi nhà sản xuất lại có nhiều thiết bị Thư mục ‘vendors’ chứa các

thư mục (gọi là vendor directory) mang tên của các sản xuất như là

Arcturus,… Mỗi vendor directory này lại chứa các thư mục con, mỗi thư

mục con này mang tên của thiết bị (product) của nhà sản xuất, gọi là product

directory Những product directory này chứa các file cần thiết cho việc build

file image tương ứng với từng product

¾ tools: Thư mục ‘tools’ chứa những tool cần thiết cho việc build File

romfs-inst.sh trong thư mục này thường được dùng bởi Makefile của các product

directory

¾ glibc và uClibc: GNU C library (glibc) và uClibc là những thư viện C được

sử dụng trong uClinux

¾ user: Những chương trình ứng dụng của user được lưu trong thư mục này

3.2 Những target cơ bản của top Makefile

Như đã nói ở phần trên, mọi tác vụ trong việc building đều bắt đầu từ top

Makefile, top Makefile sẽ quản lý quá trình building Trong phần này, chúng ta sẽ tìm

hiểu một cách khái quát những target căn bản của top Makefile và trong những phần kế

tiếp, chúng ta sẽ tìm hiểu chi tiết về quy trình hoạt động của từng target

¾ config: Target này được dùng để lấy thông tin về thiết bị mà chúng ta sẽ làm

việc; thư viện C mà chúng ta sẽ dùng như: glibc hay uClibc, …; cấu hình của

kernel; các ứng dụng sẽ được build, …

¾ dep: Target này được dùng để tạo ra những dependency cần thiết cho quá

trình build kernel

¾ all: Target all là target mặc định của top Makefile, target này dùng để

compile những code cần thiết (kernel, ứng dụng của user, thư viện, …) và

sau đó tạo file image để upload lên thiết bị

Trong đề tài này, chúng ta sẽ tập trung vào target config

3.3 Target config

Config là bước đầu tiên trong quá trình build ứng dụng trên uClinux Những

thông thu thập được trong bước này sẽ được cung cấp cho các bước tiếp theo Để có

thể lấy được thông tin, hệ thống sử dụng ngôn ngữ config để đưa ra các câu hỏi cho

user

Tác vụ config có thể được mô tả bằng sơ đồ sau:

End

Execute config (make config)

Select 'Vendor/Product' Select 'Libc Version'

Select 'Default all settings (lose changes)' (Yes/No) Select 'Customize Kernel Settings' (Yes/No) Select 'Customize Module Settings' (Yes/No) Select 'Customize Vendor/User Settings' (Yes/No) Select 'Update Default Vendor Settings' (Yes/No)

Set default config

Kernel Settings customization was selected?

Module Settings customization was selected?

Vendor/User Settings customization was selected?

3.4 Target dep

Sau khi có được thông tinvề kernel, modules, library, chúng ta tiến hành tạo các

dependency cho việc build kernel thông qua target dep cua top Makefile

Sơ đồ hoạt động của target dep được mô tả dưới đây:

Hình 3.3: Sơ đồ hoạt động của target dep

3.5 Target all

Target all là target default của top Makefile, target này phụ thuộc vào các target

khác của top Makefile Trình tự thực thi của all:

Hình 3.4: Trình tự thực thi của target all

3.5.1 Target subdirs

3.5.1.1 Target linux

Start

End

File linux-2.4.x/.depend

exists? No Display errormessage

Execute target all in linux-2.4.x/Makefile

3.5.1.2 Target subdirs

Hình 3.6: Sơ đồ hoạt động của target subdirs

3.5.3 Target modules

Hình 3.8: Sơ đồ hoạt động của target modules

3.5.4 Target modules_install

Hình 3.9: Sơ đồ hoạt động của target modules_install

3.5.5 Target image

Hình 3.10: Sơ đồ hoạt động của target image

CHƯƠNG 4 ECLIPSE

4.1 Giới thiệu

Ban đầu, Eclipse được phát triển bởi IBM Theo như thông tin từ IBM, IBM đã

đầu tư hơn 40 triệu dollar cho việc phát triển Eclipse, trước khi chuyển giao nó cho

eclipse.org như là một phần mềm open source

Xét về mặt ứng dụng, Eclipse được biết đến như là một IDE có khả năng mở

rộng Tuy nhiên, nếu xét về mặt bản chất thì Eclipse được biết đến như một platform

Eclipse bao gồm hai phần chính: Phần lõi (core) và các plug-in Bạn có thể thay thế các

plug-in không cần thiết bằng các plug-in khác cung cấp các chức năng phù hợp với nhu

cầu của bạn, chính điều này khiến cho Eclipse trở thành platform cho các công cụ khác

Khi bạn download Eclipse, bạn sẽ có Java Development Toolkit (JDT) để viết

và debug những chương trình Java và Plug-in Development Environment (PDE) dùng

để mở rộng Eclipse Nếu tất cả những gì bạn cần là một Java IDE thì bạn không cần gì

khác ngoài JDT Và đây là thứ mà hầu hết người dùng Eclipse sử dụng

Tuy nhiên, JDT chỉ là một sự bổ sung cho Eclipse Mục đích của Eclipse

platform là cung cấp những dịch vụ cần thiết cho việc tích hợp những công cụ phát

triển phần mềm được hiện thực như là những plug-in cho Eclipse Platform phải được

mở rộng với những plug-in như là JDT Điểm đặc biệt trong thiết kế của Eclipse là mọi

thứ đều là plug-in hoặc một tập các plug-in, ngoại trừ phần runtime kernel

Thiết kế plug-in làm cho Eclipse trở nên dễ mở rộng Tuy nhiên, quan trọng hơn

là platform cung cấp một cách thức được định nghĩa trước cho các plug-in hoạt động

chung với nhau (thông qua các extension point) Vì thế, những đặc tính mới có thể

được thêm vào không chỉ dễ dàng mà sự gắn kết này không dễ gì nhận thấy được

Thông thường, khi thực thi những tác vụ khác nhau bằng Eclipse, bạn không thể chỉ ra

ở điểm nào thì một plug-in kết thúc và một plug-in khác bắt đầu

4.2 Những khái niệm căn bản1

Từ quan điểm của người sử dụng, có ba loại resource khác nhau, đó là:

File, Folder và Project

¾ Workspace: Workspace có thể xem là một nơi tập trung những file dữ liệu

của bạn Platform workbench có thể xem là một công cụ dùng để duyệt và

thao tác workspace Workspace chứa một tập hợp các resource

¾ Files: Khái niệm file trong Eclipse giống như khái niệm file trong hệ thống

file Một file chứa một dãy các byte Nội dung của file thì độc lập với

platform

¾ Folders: Một folder có thể chứa những folder khác và nhiều file Khái

niệm folder trong Eclipse cũng giống như trong hệ thống file

¾ Projects: Một project là một tập hợp nhiều file và folder Nhưng project

không thể chứa project khác Nó là một vật chứa (container) trong việc tổ

chức những resource khác nhau có mối liên hệ với nhau

Những resource của workspace được tổ chức theo dạng cây, với project ở trên đỉnh, folder và file nằm ở dưới Một resource đặc biệt, resource gốc của

1 Xin tham khảo thêm [10] và [19]

workspace, được xem như gốc của cây resource Resource này được tạo ra ngầm

khi workspace được tạo ra và tồn tại trong thời gian workspace tồn tại

Một workspace có thể có nhiều project

Navigator view hiển thị project và những resource khác mà bạn đang làm việc

Eclipse cung cấp cho chúng ta nhiều loại view như: Navigator, Tasks, Outline, …

4.2.5 Wizard

Wizard nên được sử dụng khi có một task phải trải qua nhiều bước (step)

và những step này phải được hoàn tất theo một trật tự được định sẵn

Trong Eclipse, một wizard thường được sử dụng cho việc tạo resource, import hoặc export resource Nó cũng có thể được sử dụng cho việc thực thi một

task bao gồm một chuỗi các step

4.2.6 Perspective

Mỗi cửa sổ workbench chứa một hoặc nhiều perspective Một perspective định nghĩa một tập các view trong cửa sổ workbench Bên trong cửa

sổ, mỗi perspective chia sẻ tập editor giống nhau Mội perspective cung cấp một

tập chức năng giúp dễ dàng thực hiện một loại task hay công việc với những loại

resource nhất định Ví dụ: Java perspective kết hợp các view mà bạn thường

xuyên sử dụng khi edit file source Java, trong khi đó, Debug view kết hợp các

view mà bạn sẽ sử dụng khi debug chương trình Java

Dưới đây là hình ảnh minh họa cụ thể các khái niệm ở trên

Hình 4.1: Hình ảnh minh họa các khái niệm trong Eclipse

4.3 Kiến trúc của Eclipse platform

Bên cạnh platform runtime kernel, Eclipse platform bao gồm các component:

Workbench, workspace, help và team Ngoài ra còn có những tool khác được “gắn” vào

để bổ sung thêm chức năng cần thiết cho người sử dụng

Hình 4.2: Kiến trúc của Eclipse platform

Chức năng chính của Platform runtime là phát hiện ra những plug-in nào

có mặt trong Eclipse Mỗi plug-in có một file manifest ở dạng XML, trong đó liệt

kê ra những kết nối mà plug-in cần có Những kết nối này bao gồm những

extension-point mà plug-in này cung cấp cho những plug-in khác và những

extension-point của các plug-in khác mà nó cần Bởi vì số lượng plug-in có khả

năng là lớn nên các plug-in không được load cho đến khi chúng thật sự cần thiết

nhằm tối thiểu thời gian khởi động (start-up) và tài nguyên (resource) cần thiết

Platform Runtime

với một thư mục con trong thư mục workspace của Eclipse Mỗi project có thể có

file và folder; thông thường, mỗi folder tương ứng với một thư mục con trong thư

mục của project, nhưng một folder cũng có thể được link tới một thư mục nào đó

trong hệ thống file (filesystem)

Những thay đổi trên resource được workspace quản lý bằng cách duy trì một history những thay đổi Điều này khiến cho chúng ta có thể undo những thay

đổi một cách dễ dàng, cũng như là quay trở lại trạng thái lưu trữ trước đó (có thể

là từ nhiều ngày trước), tùy thuộc vào việc user cấu hình history Phương pháp

này cũng hạn chế những rủi ro trong việc mất resource

Khi có thay đổi ở resource, workspace cũng có trách nhiệm “thông báo”cho những tools có liên quan sự thay đổi này Những tool này có thể cung

cấp code cho việc cấu hình resource của project khi cần thiết

được xây dựng dựa trên SWT Vấn đề cần được lưu ý là việc Eclipse sử dụng

SWT/JFace không có nghĩa rằng chúng ta phải sử dụng chúng trong ứng khi

chúng ta dùng Eclipse để phát triển ứng dụng Thay vào đó, chúng ta có thể dùng

AWT hoặc Swing Tuy nhiên, nếu chúng ta phát triển một plug-in thì chúng ta bắt

buộc phải dùng SWT/JFace

1 Để biết thêm về SWT và JFace, xin tham khảo [28], [23], [24]

4.3.4 Team support

Plug-in team support giúp cho việc sử dụng hệ thống quản lý phiên bản (version control) được dễ dàng hơn trong việc quản lý resource trong project của

user và xác định workflow cần thiết trong việc lưu và lấy dữ liệu từ kho chứa

(repository) Một chương trình client của Concurrent Versions System (CVS)

được tích hợp trong Eclipse platform

Ngay từ ban đầu, Eclipse được thiết kế như là một IDE mở, điều này đươc thể

hiện trong thiết kế của Eclipse, thiết kế của Eclipse là một thiết kế “lỏng” (loosely

connected design), thiết kế này phù hợp đối với những hệ thống không được thiết kế

đầy đủ ban đầu mà là những hệ thống được xây dựng từ các component riêng biệt,

những component này sẽ được tạo ra khi cần thiết

4.4.1 Tổng quan về Eclipse plug-in

Một plug-in trong Eclipse là một thành phần (component) cung cấp một

loại dịch vụ nhất định Eclipse Runtime cung cấp một nền tảng cho việc khởi

động và hoạt động của một tập hợp các plug-in, những plug-in này làm việc

chung với nhau để cung cấp một môi trường hoàn hảo cho việc phát triển các

plug-in khác Bên trong một Eclipse instance, một plug-in được bao bọc trong

một instance của plug-in runtime class, hay để đơn giản chúng ta gọi là plug-in

class Plug-in class cung cấp sự hỗ trợ về quản lý và cấu hình cho plug-in