phÂn tÍch, thiẾt kẾ phẦ Ềm nhÚngstorage.sharetailieu.net/data/20190402/v_l0_01819... ·...

ĐẠI HỌC QUỐC GIA HÀ NỘI TRƯỜNG ĐẠI HỌC CÔNG NGHỆ

TRẦN MINH TUẤN

PHÂN TÍCH, THIẾT KẾ PHẦN MỀM NHÚNG

LUẬN VĂN THẠC SỸ

HÀ NỘI, 2008

Luận văn Thạc sĩ 2008 Phân tích, Thiết kế phần mềm nhúng

Trần Minh Tuấn Đại Học Công Nghệ - Đại Học Quốc Gia Hà Nội

1

MỤC LỤC

DANH MỤC HÌNH VẼ BẢNG BIỂU TRONG LUẬN VĂN ................................. 3

BẢNG THUẬT NGỮ VÀ KÝ HIỆU SỬ DỤNG ..................................................... 5

LỜI GIỚI THIỆU ..................................................................................................... 6

CHƢƠNG 1: TỔNG QUAN VỀ THIẾT KẾ........................................................... 8

HỆ THỐNG NHÚNG ............................................................................................... 8

1.1 Hệ nhúng và các khái niệm ................................................................................ 8

1.1.1 Hệ thống nhúng .......................................................................................... 8

1.1.2 Hệ thống nhúng thời gian thực .................................................................... 8

1.2 Giới thiệu chung về thiết kế hệ thống nhúng .................................................... 10

1.2.1 Xác định yêu cầu sản phẩm ....................................................................... 11

1.2.2 Lựa chọn bộ vi xử lý ................................................................................. 11

1.2.2 Phân bổ giữa phần cứng và phần mềm ...................................................... 12

1.2.3 Thực hiện và lặp lại................................................................................... 14

1.2.4 Thiết kế chi tiết phần cứng và phần mềm .................................................. 14

1.2.5 Tích hợp phần cứng phần mềm ................................................................. 15

1.2.6 Kiểm thử ................................................................................................... 16

1.2.7 Bảo trì và cập nhật .................................................................................... 16

CHƢƠNG 2: THIẾT KẾ PHẦN MỀM NHÚNG ................................................. 17

2.1 Phần mềm nhúng ............................................................................................. 17

2.1.1 Sự khác biệt giữa phần mềm nhúng và phần mềm thông thường trên PC .. 18

2.1.2 Nguyên tắc thiết kế chung ......................................................................... 19

2.1.3 Thiết kế phần mềm nhúng với RTOS ........................................................ 20

2.2 Kiến trúc phần mềm nhúng.............................................................................. 24

2.2.1 Round robin .............................................................................................. 24

2.2.2 Round robin với ngắt ................................................................................ 25

2.2.3 Kiến trúc Function – Queue - Scheduling .................................................. 26

2.2.4 Kiến trúc Hệ điều hành thời gian thực (RTOS) ......................................... 27

2.3 Các phương pháp đặc tả và thiết kế phần mềm nhúng...................................... 28

2.3.1 Phương pháp đặc tả hình thức (formal method) ......................................... 28

2.3.2 Phương pháp đặc tả bán hình thức (semi-formal method).......................... 30

2.4 Công cụ phát triển phần mềm nhúng ............................................................... 35

2.5 Case study về thiết kế phần mềm nhúng .......................................................... 38

2.5.1 Phân tích yêu cầu ...................................................................................... 38

2.5.2 Thiết kế ..................................................................................................... 44

2.5.3 Phân chia tác vụ ........................................................................................ 48

2.5.4 Kiến trúc phần cứng của hệ thống ............................................................. 48



2

CHƢƠNG 3: HỆ ĐIỀU HÀNH THỜI GIAN THỰC ........................................... 49

3.1 Tính đa nhiệm ................................................................................................. 49

3.1.1 Lập lịch ưu tiên (Preemptive Scheduling) ................................................. 51

3.1.2 Kích hoạt và bỏ kích hoạt tác vụ (Activation and Deactivation of Tasks) .. 51

3.1.3 Lập lịch hướng sự kiện (Event-Driven Scheduling)................................... 51

3.2 Theo dõi các tác vụ .......................................................................................... 52

3.3 Truyền thông giữa các tác vụ ........................................................................... 52

3.4 Quản lý bộ nhớ ................................................................................................ 54

3.5 Quản lý tài nguyên .......................................................................................... 54

3.6 RTOS và ngắt .................................................................................................. 55

3.7 Liên lạc trong RTOS thông dụng ..................................................................... 56

3.8 Khả năng sử dụng RTOS ................................................................................. 56

3.9 Ưu nhược điểm của hệ điều hành thời gian thực .............................................. 57

3.10 Hệ điều hành thời gian thực µC/OS ............................................................... 58

CHƢƠNG 4: CÁC CÁCH TIẾP CẬN VỚI BÀI TOÁN NHẬN DẠNG CHỮ

NÔM ........................................................................................................................ 63

4.1 Nhận dạng chữ Nôm bằng mạng nơ-ron .......................................................... 63

4.1.1 Áp dụng mạng nơ-ron trong nhận dạng chữ Nôm...................................... 63

4.1.2 Thưc nghiêm ............................................................................................. 64

4.2 Ứng dụng Tesseract để nhận dạng chữ Nôm .................................................... 66

4.2.1 Tóm tắt về Tesseract ................................................................................ 66

4.2.2. Áp dụng với chữ Nôm.............................................................................. 68

4.3. So sánh và thảo luận ....................................................................................... 69

CHƢƠNG 5: ỨNG DỤNG VÀ PHÁT TRIỂN PHẦN MỀM NHẬN DẠNG CHỮ

NÔM CHO THIẾT BỊ NHÚNG ............................................................................ 70

5.1 Phân tích ứng dụng trên môi trường nhúng ...................................................... 70

5.2 Thực nghiệm chương trình nhận dạng dựa trên Tesseract với môi trường µC/OS

.............................................................................................................................. 76

KẾT LUẬN ............................................................................................................. 77

TÀI LIỆU THAM KHẢO ...................................................................................... 78

PHỤ LỤC ................................................................................................................ 80



3

DANH MỤC HÌNH VẼ BẢNG BIỂU TRONG LUẬN VĂN

DANH MỤC HÌNH VẼ

Hình 1.1 Quan hệ giữa hệ nhúng và thời gian thực ...................................................... 9

Hình 1.2 Quy trình thiết kế co-design ....................................................................... 10

Hình 1.3 Thiết kế máy in laser .................................................................................. 13

Hình 1.4 Một ví dụ về vấn đề big endian/little endian ............................................... 15

Hình 1.5 Mối liên hệ về chi phí sửa lỗi cho mỗi giai đoạn......................................... 16

Hình 2.1 Phần mềm nhúng trong hệ thống ................................................................ 17

Hình 2.2 Thành phần phần mềm nhúng..................................................................... 18

Hình 2.3 Cấu trúc đề nghị của một tác vụ ................................................................. 23

Hình 2.4 Kiến trúc Round robin ................................................................................ 25

Hình 2.5. Kiến trúc Round-robin with interrupts ....................................................... 26

Hình 2.6 Kiến trúc Function-Queue-Scheduling ....................................................... 27

Hình 2.7 Kiến trúc Hệ điều hành thời gian thực ........................................................ 28

Hình 2.8 Biểu đồ luồng dữ liệu hệ thống đồng hồ báo thức ...................................... 31

Hình 2.9. Biểu đồ trạng thái ...................................................................................... 32

Hình 2.10 Đặc tả theo giả mã .................................................................................... 33

Hình 2.11 Qui trình phát triển blueprint .................................................................... 34

Hình 2.12 Cấu trúc của SPT profile .......................................................................... 35

Hình 2.13 Quá trình phát triển và biên dịch phần mềm nhúng ................................... 38

Hình 2.14 Hình dáng của thiết bị .............................................................................. 39

Hình 2.15 Biểu đồ ngữ cảnh của hệ thống ................................................................. 40

Hình 2.16 Biểu đồ Use Case ..................................................................................... 41

Hình 2.17 Biểu đồ tuần tự cho ca sử dụng Playback a message ................................. 42

Hình 2.18 Alarm while playback a message .............................................................. 43

Hình 2.19 Ngữ cảnh vào và ra khỏi chế độ stand-by ................................................. 44

Hình 2.20 Biểu đồ lớp của hệ thống .......................................................................... 46

Hình 2.21 Các hệ thống con trong Digital Sound Recorder ....................................... 46

Hình 2.22 Biểu đồ lớp hệ thống Audio ...................................................................... 47

Hình 2.23 Biểu đồ tuần tự nghe một thông điệp ........................................................ 47

Hình 2.24 Thiết kế phần cứng của hệ thống .............................................................. 48

Hình 3.1 Cấu trúc hệ điều hành thời gian thực ......................................................... 49

Hình 3.2 Hoạt động chia nhỏ thời gian và tuần tự ..................................................... 50

Hình 3.3 Một ví dụ về semaphore ............................................................................. 52

Hình 3.4 Truyền thông của RTOS ............................................................................. 53

Hình 3.5 Các khối bộ nhớ được gán trong RTOS ...................................................... 55

Hình 3.6 Cấu trúc một tác vụ .................................................................................... 59

Hình 3.7 Biểu đồ chuyển trạng thái của tác vụ .......................................................... 59



4

Hình 3.8 Hàm dịch vụ ngắt trong µC/OS .................................................................. 61

Hình 4.2. Câu truc mô-dun của chương trinh ............................................................ 65

Hình 4.3 Lưu đô huân luyên mang ............................................................................ 66

Hình 4.4 Kiến trúc tổng quát của Tesseract ............................................................... 67

Hình 5.1 Quá trình học chữ Nôm .............................................................................. 70

Hình 5.2 Quá trình nhận dạng ................................................................................... 70

Hình 5.3 Biểu đồ ngữ cảnh của hệ thống ................................................................... 71

Hình 5.4 Biểu đồ Use case của hệ thống ................................................................... 72

Hình 5.5 Biểu đồ tuần tự của hệ thống nhận dạng chữ Nôm ...................................... 73

Hình 5.6 Biểu đồ lớp của hệ thống nhận dạng chữ Nôm ........................................... 74

Hình 5.7 Trạng thái của tác vụ khi thực thi trong hệ thống ........................................ 75

Hình 5.8 Biểu đồ chuyển đổi giữa các tác vụ ............................................................ 75

DANH MỤC BẢNG BIỂU

Bảng 2.1 Bảng các sự kiện tác động lên hệ thống ...................................................... 41

Bảng 2.2 Các đối tượng của hệ thống ........................................................................ 45

Bảng 4.1 Môt kêt qua nhận dạng ............................................................................... 65

Bảng 4.2 Kêt qua nhân dang chư Nôm vơi Tesseract................................................. 68

Bảng 5.1 Các sự kiện tác động vào chương trình ...................................................... 72

Bảng 5.2 Kết quả thực hiện tác vụ nhận dạng ........................................................... 76



5

BẢNG THUẬT NGỮ VÀ KÝ HIỆU SỬ DỤNG

ANN Kỹ thuật nhận dạng dựa trên mạng nơ ron (Artifical neural

network)

ASIC Vi mạch tích hợp chuyên dụng (Application Integrated IC)

CPU Bộ xử lý trung tâm (Central Processing Unit)

CSP Một ngôn ngữ hình thức mô tính tương tác trong các hệ

thống (Communicating Sequential Process)

DMA Truy cập bộ nhớ trực tiếp (Direct Memory Access)

FPU Đơn vị xử lý dấu phải động (Float Processing Unit)

IC Mạch tích hợp (Integrated Circuit)

ISR Hàm dịch vụ ngắt (Interrupt Service Routine)

JTAG Một chuẩn giao tiếp để truyền dữ liệu được đưa ra bởi

JTAG (Joint Test Action Group)

K-NN Kỹ thuật nhận dạng dựa trên láng giềng gần nhất

(K-Nearest Neighbor)

OMG Tên của một tổ chức (Object Management Group)

PLD Thiết bị logic khả trình (Programmable Logic Device)

ROOM Mô hình hoá hướng đối tượng thời gian thực (Real time

Object Oriented Modelling)

RTOS Hệ điều hành thời gian thực (Real time Operating System)

UML-SPT Một chuẩn mô tả cho các ứng dụng thời gian thực dựa trên

UML

TCB Khối điều khiển tác vụ (Task Control Block)

VHDL Một ngôn ngữ đặc tả phần cứng (Vhsic Hardware

Description Language)

UML Ngôn ngữ mô hình hoá thống nhất (Unified Modelling

Language)



6

LỜI GIỚI THIỆU

Thời gian gần đây, các Hệ thống nhúng – Thời gian thực được quan tâm nhiều hơn

ở Việt Nam, và trên thế giới thì các hệ thống này đã và đang được phát triển mạnh mẽ

và là xu hướng thịnh hành ở các nước Công nghiệp vì những lợi ích to lớn, thiết thực

mà nó mang lại. Theo các chuyên gia nhận định, sự phát triển của máy tính (PC) đã

chuyển sang giai đoạn thứ 3 - giai đoạn của môi trường thông minh mà hệ thống

nhúng là cốt lõi (còn gọi là giai đoạn hậu PC - Internet). Phát triển hệ nhúng và phần

mềm nhúng đang là quốc sách của nhiều quốc gia.

Tuy nhiên muốn xây dựng Hệ thống nhúng – Thời gian thực tốt, đáp ứng được yêu

cầu đòi hỏi người thiết kế và phát triển phải có sự hiểu biết sâu về hệ thống, thiết bị

phần cứng, những vấn đề về hệ điều hành thời gian thực (RTOS), lập trình nhúng, các

giải thuật trong lập lịch (Scheduling), cấp phát (Allocation), bố trí hệ thống (layout),

phân chia phần cứng – phần mềm (HW-SW partioning)…Việc thiết kế và xây dựng hệ

thống nhúng cần phát triển theo hướng co-design [7]. Nghĩa là phải phát triển phần

cứng và phần mềm đồng thời nhằm xác định giải pháp tối ưu nhất cho hệ thống nhúng.

Mục đích của luận văn là đi sâu nghiên cứu các phương pháp, cách thức nhằm phân

tích, thiết kế tốt phần mềm nhúng trong hệ thống nhúng - thời gian thực.

Bên cạnh mục đích trên, còn có một mục tiêu rất quan trọng và thiết thực đó là

nghiên cứu các cách tiếp cận nhận dạng chữ Nôm để xây dựng ứng dụng cho bài toán

này trên thiết bị nhúng. Về lĩnh vực nhận dạng, nhận dạng chữ là bài toán rất hữu ích

trong việc số hóa dữ liệu ở dạng văn bản giấy hoặc ảnh. Với chữ Latin bài toán đã

được nghiên cứu và phát triển từ lâu và hiện có nhiều phần mềm nhận dạng ký tự Latin

với độ chính xác cao. Gần đây một số ngôn ngữ tượng hình như chữ Trung Quốc hay

chữ Nhật Bản cũng đã được giải quyết bằng nhiều phương pháp nhận dạng khác nhau

như: láng giềng gần nhất [9], mạng nơ-ron [29].

Ở Việt Nam, vấn đề nhận dạng chữ Quốc ngữ cũng đang được nhiều tổ chức thực

hiện, ví dụ VnDOCR [5] cho phép quét, đọc ảnh văn bản với nhiều định dạng khác

nhau và kết quả nhận dạng là văn bản có kiểu phông tùy chọn. Tuy nhiên với bài toán

nhận dạng chữ Nôm, bài toán nhận dạng rất có ý nghĩa trong việc khôi phục và gìn giữ

di sản văn hóa dân tộc, hiện vẫn chưa có nhiều nghiên cứu với kết quả khả quan. Một

số tổ chức đã nghiên cứu và xây dựng một số phần mềm liên quan đến số hóa chữ

Nôm như: bộ phông chữ Nôm của Viện Hán Nôm, phần mềm Từ điển Hán Nôm trên

PDA của Trung tâm công nghệ thông tin Thừa Thiên Huế [5], phần mềm đánh văn bản

chữ Hán Nôm cua tac gia Trần Uyên Thi và Alexandre Lê, phần mềm từ điển Trực

tuyến Việt-Hán-Nôm biên soạn dựa trên cuốn Tự điển Hán -Việt của Thiều Chửu do

nhóm tác giả Phan Anh Dũng và Nguyễn Thế thực hiện [4]. Đây là những nền tảng cần



7

thiết khích lệ tôi nghiên cứu bài toán nhận dạng chữ Nôm để ứng dụng vào các nguồn

văn bản đang tồn tại rất nhiều trong các thư viện, công trình văn hoá, và trong đời sống

hàng ngày cũng như xây dựng những tiện ích nhận dạng chữ Nôm trên thiết bị nhúng

để đáp ứng nhu cầu của nhân dân.

Luận văn được chia thành 5 chương và phụ lục. Trong đó:

Chƣơng 1: trình bày về hệ thống nhúng thời gian thực và tổng quan về thiết kế

những hệ thống này.

Chƣơng 2: trình bày về phần mềm nhúng và các phương pháp thiết kế.

Chƣơng 3: trình bày về hệ điều hành thời gian thực (RTOS) và các dịch vụ của

nó.

Chƣơng 4: trình bày về các cách tiếp cận với bài toán nhận dạng chữ Nôm và

những kết quả thực nghiệm của các phương pháp.

Chƣơng 5: trình bày về phân tích chương trình nhận dạng chữ Nôm dựa trên

Tesseract cho thiết bị nhúng và thực nghiệm trên hệ điều hành thời gian thực

µC/OS.



8

CHƢƠNG 1: TỔNG QUAN VỀ THIẾT KẾ

HỆ THỐNG NHÚNG

1.1 Hệ nhúng và các khái niệm

1.1.1 Hệ thống nhúng

Trong thế giới thực của chúng ta bất kỳ một thiết bị hay hệ thống điện/điện tử

có khả năng xử lý thông tin và điều khiển đều có thể tiềm ẩn trong đó một thiết bị hay

hệ nhúng, ví dụ như các thiết bị truyền thông, thiết bị đo lường điều khiển, các thiết bị

phục vụ sinh hoạt hàng ngày như lò vi sóng, máy giặt, camera…Rất dễ dàng để có thể

kể ra hàng loạt các thiết bị hay hệ thống như vậy đang tồn tại quanh ta, chúng là hệ

nhúng. Vậy hệ nhúng thực chất là gì và nên hiểu thế nào về hệ nhúng? Hiện nay cũng

chưa có một định nghĩa nào thực sự thoả đáng để được chuẩn hoá và thừa nhận rộng

rãi cho hệ nhúng mà vẫn chỉ là những khái niệm diễn tả về chúng thông qua những đặc

thù chung [25]. Tuy nhiên ở đây chúng ta có thể hiểu hệ nhúng là một phần hệ thống

xử lý thông tin tích hợp trong các hệ thống lớn, phức hợp và độc lập ví dụ như trong

ôtô, các thiết bị đo lường, điều khiển, truyền thông và thiết bị thông minh nói chung.

Chúng là những tổ hợp của phần cứng và phần mềm để thực hiện một hoặc một nhóm

chức năng chuyên biệt, cụ thể (Trái ngược với máy tính PC mà chúng ta thường thấy

được sử dụng không phải cho một chức năng mà là rất nhiều chức năng hay phục vụ

chung cho nhiều mục đích).

Chúng ta có thể kể ra rất nhiều các ứng dụng của hệ thống nhúng đang được sử

dụng hiện nay, và xu thế sẽ còn tiếp tục tăng nhanh. Một số lĩnh vực của các hệ thống

nhúng có thể được nhóm như sau:

Các thiết bị điều khiển

Ôtô, tàu điện

Truyền thông

Thiết bị y tế

Hệ thống đo lường thẩm định

Toà nhà thông minh

Thiết bị trong các dây truyền sản xuất

Rôbốt

…

1.1.2 Hệ thống nhúng thời gian thực

Hệ thống thời gian thực là hệ thống mà tính đúng đắn của toàn bộ hệ thống phụ

thuộc cả vào tính đúng đắn về chức năng và tính đúng đắn về thời gian. Tính đúng đắn

về thời gian được hiểu là yêu cầu của hệ thống phải đảm bảo thoả mãn về tính tiền



9

định trong hoạt động của hệ thống. Tính tiền định nói lên hành vi của hệ thống thực

hiện đúng trong một khung thời gian cho trước hoàn toàn xác định. Khung thời gian

này được quyết định bởi đặc điểm hoặc yêu cầu của hệ thống, có thể là vài giây và

cũng có thể là vài nano giây hoặc nhỏ hơn nữa. Ở đây chúng ta phân biệt yếu tố thời

gian gắn liền với khái niệm về thời gian thực. Không phải hệ thống thực hiện rất nhanh

là sẽ đảm bảo được tính thời gian thực vì nhanh hay chậm hoàn toàn là phép so sánh

có tính tương đối vì mili giây có thể là nhanh với hệ thống điều khiển nhiệt nhưng lại

là chậm đối với các đối tượng điều khiển điện như dòng, áp…. Hơn thế nữa nếu chỉ

nhanh không thì chưa đủ mà phải đảm bảo duy trì ổn định bằng một cơ chế hoạt động

tin cậy. Chính vì vậy hệ thống không kiểm soát được hoạt động của nó thì không thể là

một hệ thống đảm bảo tính thời gian thực mặc dù hệ thống đó có thể cho đáp ứng rất

nhanh, thậm chí nhanh hơn rất nhiều so với yêu cầu đặt ra. Một ví dụ minh hoạ tiêu

biểu đó là cơ chế truyền thông dữ liệu qua đường truyền chuẩn Ethernet truyền thống,

mặc dù ai cũng biết tốc độ truyền là rất nhanh nhưng vẫn không phải hệ hoạt động thời

gian thực vì không thoả mãn tính tiền định trong cơ chế truyền dữ liệu (có thể là rất

nhanh và cũng có thể là rất chậm nếu có sự canh trạnh và giao thông đường truyền bị

nghẽn).

Người ta phân ra làm hai loại đối với khái niệm thời gian thực là cứng (hard

real-time) và mềm (soft real-time). Thời gian thực cứng là khi hệ thống hoạt động với

yêu cầu thoả mãn sự ràng buộc trong khung thời gian cứng tức là nếu vi phạm thì sẽ

dẫn đến hoạt động của toàn hệ thống bị sai hoặc bị phá huỷ. Ví dụ về hoạt động điều

khiển cho một lò phản ứng hạt nhân, nếu chậm ra quyết định có thể dẫn đến thảm hoạ

gây ra do phản ứng phân hạch và dẫn đến bùng nổ cả hệ thống. Thời gian thực mềm là

khi hệ thống hoạt động với yêu cầu thoả mãn ràng buộc trong khung thời gian mềm,

nếu vi phạm và sai lệch nằm trong khoảng cho phép thì hệ thống vẫn có thể hoạt động

được và chấp nhận được. Ví dụ như hệ thống phát thanh truyền hình, nếu thông tin

truyền đi từ trạm phát tới người nghe/nhìn chậm một vài giây thì cũng không ảnh

hưởng đáng kể đến tính thời sự của tin được truyền đi và hoàn toàn được chấp nhận

bởi người theo dõi. Thực tế thấy rằng hầu hết hệ nhúng là các hệ thời gian thực và hầu

hết các hệ thời gian thực là hệ nhúng. Điều này phản ánh mối quan hệ mật thiết giữa

hệ nhúng và thời gian thực và tính thời gian thực đã trở thành như một thuộc tính tiêu

biểu của hệ nhúng. Vì vậy hiện nay khi đề cập tới các hệ nhúng người ta đều nói tới

đặc tính cơ bản của nó là tính thời gian thực.

Hình 1.1 Quan hệ giữa hệ nhúng và thời gian thực



10

1.2 Giới thiệu chung về thiết kế hệ thống nhúng

Các kỹ sư xây dựng hệ thống nhúng luôn phải đối mặt với nhiều khó khăn trong

quá trình thiết kế hệ thống. Từ việc xác định phân bổ giữa phần cứng và phần mềm

cho đến việc tính toán để thiết kế đạt những mục tiêu về hiệu năng và chi phí. Việc xây

dựng hệ thống nhúng ngày càng trở lên phức tạp vì yêu cầu ngày càng cao. Họ phải

xây dựng những hệ thống ngày càng thông minh hơn, có nhiều chức năng hơn nhưng

lại phải được gói gọn trong một không gian nhỏ hơn, ít tiêu thụ điện năng hơn, thời

gian sản xuất nhanh hơn và chi phí cho hệ thống giảm. Có lẽ bởi vì liên quan đến sự

kết hợp của ít nhất hai nguyên tắc phức tạp và sáng tạo: kỹ nghệ phần mềm và thiết kế

logic. Vấn đề này thường liên quan đến xây dựng một cái mới mà mọi người chưa

từng xây dựng bao giờ hay đơn giản là có quá nhiều sự lựa chọn như: sử dụng bộ vi xử

lý nào cho phù hợp, cách sắp xếp các bus, triển khai bằng ngôn ngữ lập trình nào, có

sử dụng hệ điều hành hay không, môi trường phát triển …làm cho người phát triển

nhiều lúc không biết bắt đầu từ đâu.

Không giống với việc thiết kế các ứng dụng phần mềm trên máy tính, việc thiết

kế một hệ thống nhúng phải thực hiện thiết kế cả phần cứng và phần mềm một cách

song song. Mặc dù không phải lúc nào cũng vậy nhưng thực tế cho thấy đây là cách

thức tiếp cận việc thiết kế hệ thống nhúng một cách hiệu quả và ảnh hưởng sâu sắc đến

việc xây dựng hệ thống.

Quy trình thiết kế hệ thống nhúng bao gồm các bước sau:

Xác định yêu cầu sản phẩm

Phân bổ phần cứng phần mềm

Thực hiện và lặp lại

Thiết kế phần cứng/phần mềm nhúng

Tích hợp phần cứng/phần mềm

Kiểm tra

Bảo trì và nâng cấp

Hình 1.2 Quy trình thiết kế co-design



11

1.2.1 Xác định yêu cầu sản phẩm

Chúng ta cần phải xác định:

Hệ thống làm gì?

Những thành phần vào ra bao gồm những gì?

Giao diện hệ thống

Trong hệ thống nhúng việc xác định yêu cầu là rất quan trọng. Nó có thể giúp

chúng ta tránh được những vấn đề sau này như lượng RAM thiết kế cho hệ thống

nhúng không đủ cho hoạt động hay bộ xử lý được chọn có tốc độ quá chậm cho công

việc…Sau khi yêu cầu sản phẩm đã được xác định thì công việc tiếp theo là xác định

liệu sử dụng bộ vi xử lý có phải là sự lựa chọn tốt nhất không. Những câu hỏi sau đây

có thể hữu ích khi xác định xem sử dụng bộ vi xử lý có hợp lý không:

Đầu vào và đầu ra được xử lý và cập nhật ở tốc độ nào? Mặc dù xung đồng hồ

vẫn đang tăng lên nhưng có một giới hạn trên thực tế với tốc độ bộ vi xử lý có

thể đọc từ một đầu vào hoặc cập nhật đầu ra và vẫn đang thực hiện công việc.

Nếu hệ thống phải thực hiện việc xử lý quan trọng, xử lý bộ đệm, hoặc những

tính toán khác thì tỉ lệ cập nhật sẽ giảm xuống.

Liệu có một mạch tích hợp đơn (IC) hoặc một thiết bị logic khả trình (PLD)

thực hiện được công việc không? nếu có thì sử dụng bộ vi xử lý là không cần

thiết.

Hệ thống có nhiều đầu vào và ra, như công tắc hay màn hình hiển thị không?

nếu có thì bộ vi xử lý sẽ giải quyết công việc thuận lợi hơn.

Những giao tiếp gì đối với những hệ thống bên ngoài? Nếu hệ thống phải nói

chuyện với hệ thống khác dùng giao thức điều khiển liên kết dữ liệu đồng bộ

(SDLC) hoặc một vài giao thức truyền thông phức tạp khác thì sử dụng bộ vi xử

lý là lựa chọn đúng đắn.

Hệ thống có phải tính toán và xử lý nhiều việc không? Ví dụ hệ thống đánh lửa

(khởi động) điện tử hiện đại có rất nhiều đầu vào (các cảm ứng không khí, động

cơ rpm …) với những liên quan phức tạp sẽ có vài lựa chọn thay vì sử dụng bộ

vi xử lý.

Liệu thiết kế có được sửa đổi khi nó hoàn thành hoặc thay đổi trong quá trình

thiết kế không? Có cần phải tuỳ biến sản phẩm cho những phiên bản đặc biệt

không? những yêu cầu này đều ảnh hưởng đến việc có lựa chọn bộ vi xử lý hay

không.

Thật may là công việc này của người thiết kế đang trở lên dễ dàng hơn do chi phí của

bộ vi xử lý sẽ giảm nhưng tốc độ và hiệu năng của nó sẽ được tăng lên.

1.2.2 Lựa chọn bộ vi xử lý

Giả sử chúng ta đã quyết định sử dụng bộ vi xử lý cho hệ thống nhúng của mình

thì vấn đề tiếp theo là lựa chọn bộ vi xử lý cho phù hợp với hệ thống cần xây dựng.

Thực tế cho thấy có nhiều sự lựa chọn đúng bộ xử lý cho hệ thống nhúng bởi vì sẽ có



12

vài bộ xử lý có thể đạt các yêu cầu đặt ra. Sự lựa chọn bao gồm việc cân bằng các yếu

tố giữa chi phí và các chức năng. Một số vấn đề cần phải được xem xét khi lựa chọn:

Số lượng chân vào ra yêu cầu

Những giao tiếp yêu cầu

Yêu cầu bộ nhớ

Xem xét vấn đề thời gian thực

Môi truờng phát triển

Tốc độ xử lý được yêu cầu

Khả năng của ROM

Kiến trúc bộ nhớ

1.2.2 Phân bổ giữa phần cứng và phần mềm

Thiết kế hệ nhúng sẽ liên quan đến cả hai vấn đề là thiết kế các thành phần phần

cứng và các thành phần phần mềm, người thiết kế phải xác định xem vấn đề nào được

giải quyết trong phần cứng và vấn đề nào thì giải quyết ở phần mềm. Sự lựa chọn này

được gọi là phân bổ quyết định.

Những nhà phát triển ứng dụng thường phát triển với phần cứng được xác định

trước có thể có những khó khăn trong việc điều chỉnh về phần cứng để nâng cao hiệu

quả xử lý vấn đề. Tuy nhiên họ cũng có thể đã gặp phải những vấn đề lựa chọn cân

nhắc giữa phần cứng và phần mềm. Ví dụ, trong những ngày đầu của PC (trước khi

giới thiệu bộ xử lý 80486), những bộ xử lý 8086, 80286 và 80386 đều không có đơn vị

xử lý dấu phảy động trên chip. Những bộ xử lý này yêu cầu những thiết bị đi kèm, đơn

vị xử lý dấu phảy động 8087, 80287 và 80387 (FPUs) để chạy trực tiếp các chỉ thị dấu

phảy động trong chương trình. Nếu PC không có một FPU, thì mã chương trình phải

chặn những chỉ thị dấu phảy động lại và thực hiện một ngoại lệ hoặc hàm bẫy lỗi sẽ

thực hiện vấn đề xử lý dấu phảy động trên phần mềm. Tuy nhiên điều này sẽ chậm hơn

nhiều so với có đơn vị xử lý dấu phảy động trên bảng mạch nhưng chí ít thì mã

chương trình cũng được thực thi.

Một ví dụ khác về phân bổ giữa phần cứng và phần mềm, ta có thể mua một

thiết bị modem cho PC của mình rồi cắm vào khe ISA như vậy trên máy tính đã có

mạch thực hiện điều chế và giải điều chế. Nếu ít tiền hơn ta có thể mua một win

modem để cắm vào khe PCI và sử dụng bộ vi xử lý để trực tiếp xử lý các chức năng

của modem. Việc thiết kế là kết hợp giữa các thành phần phần cứng và phần mềm để

cho ra một giải pháp thiết kế nhúng hiệu quả nhất. Chúng ta có thể thực hiện việc thiết

kế một chức năng nào đó dựa trên phần mềm (ví dụ CPU không có đơn vị FPU ở trên),

dựa trên phần cứng hoặc dựa trên cả phần cứng và phần mềm. Để làm rõ hơn về vấn

đề phân chia giữa phần cứng và phần mềm chúng ta sẽ xét tiếp một ví dụ về thiết kế

máy in laser.

Hình 1.3 mô tả một thiết kế cho máy in laser. Với sự giúp đỡ từ những nhà thiết

kế máy in laser chúng ta có thể hình dung ra những công việc có thể thực hiện trong



13

máy in laser (phần mềm). Bộ vi xử lý nắm bắt luồng dữ liệu đến thông qua cổng song

song, cổng tuần tự RS-232C, cổng USB, hoặc cổng Ethernet vào trong bộ đệm.

Hình 1.3 Thiết kế máy in laser

Cùng một thời điểm, bộ xử lý quản lý các cổng dữ liệu và chuyển những dữ liệu đến

thành luồng điều chế (stream of modulation) và những tín hiệu điều khiển cho ống

phóng laser, gương xoay, trống xoay, bộ phận quản lý giấy. Chúng ta có thể thấy điều

này làm cho bộ xử lý phải làm rất nhiều việc do đó giới hạn hiệu năng của hệ thống.

Chúng ta có thể tìm cách nâng cao hiệu năng của hệ thống bằng cách thêm nhiều bộ xử

lý và phân chia những nhiệm vụ đồng thời giữa chúng. Điều này sẽ làm cho tốc độ xử

lý tăng lên, chi phí tăng lên, nhưng không có nhiều thông tin hơn để in.

Khi phân tích giải pháp thiết kế chúng ta sẽ thấy rằng những công việc mà ảnh

hưởng đến hiệu năng của hệ thống cũng có những cận giới hạn nhất định và được mô

tả đầy đủ. Những công việc này có thể được xử lý bằng các phương pháp thiết kế một

cách dễ dàng và có thể thực hiện theo giải pháp dựa trên phần cứng. Ví dụ trong thiết

kế máy in laser này, chúng ta có thể sử dụng một khối phần cứng cho việc ghi các

điểm laser trên bề mặt của trống máy in. Điều này sẽ giải phóng cho bộ xử lý để thực

hiện những công việc khác và chỉ yêu cầu nó khởi tạo và phục vụ phần cứng nếu có lỗi

nào đó xảy ra.

Những yêu cầu cho phần cứng chặt chẽ hơn nhiều so với phần mềm bởi vì nó

phức tạp hơn, mất chi phí cho sửa lỗi phần cứng nhiều hơn so với sửa lỗi phần mềm.

Nếu phần cứng là IC chuyên về ứng dụng tùy biến (Custom - ASIC) thì cần phải xem

xét nhiều hơn vì tính phức tạp của việc thiết kế một IC tùy biến. Nếu cách tiết cận này

dường như quá rủi ro cho dự án, đội thiết kế có thể chuyển sang giải pháp phần mềm

hoặc đội thiết kế có thể đưa ra quyết định cần phải sử dụng một bộ xử lý mới hơn,

mạnh hơn để nâng cao hiệu năng. Tuy nhiên điều này cũng liên quan đến vấn đề chi

phí, những công cụ mới, bố cục mạch mới, đường dữ liệu rộng hơn, tính phức tạp cao

hơn. Hai triết lý thiết kế khác nhau này đã được áp dụng thành công cho thiết kế máy

in laser trong các công ty sản xuất máy in ngày nay. Một bên thì thiết kế khả năng điều

chỉnh hiệu năng của bộ xử lý để tối thiểu hoá dùng các thiết bị phần cứng chuyên biệt.



14

Ngược lại thì bên kia sử dụng các thiết bị phần cứng chuyên biệt để giảm gánh nặng

cho bộ xử lý. Cả hai đều có những sản phẩm cạnh tranh nhưng thực hiện hai chiến

lược thiết kế khác nhau cho phân chia các thành phần cứng và mềm.

Quyết định phân chia là một vấn đề tối ưu và phức tạp. Nhiều thiết kế hệ thống

nhúng yêu cầu:

Nhạy cảm về giá

Người đi đầu về giải pháp

Không theo chuẩn

Cạnh tranh thị trường

Bản quyền

Những yêu cầu dường như mẫu thuẫn lẫn nhau này sẽ làm cho khó tạo ra một

thiết kế tối ưu cho sản phẩm nhúng. Giải pháp phân bổ phụ thuộc vào bộ xử lý nào sử

dụng trong thiết kế, cách thực hiện thiết kế tổng thể và kinh nghiệm của người thiết kế.

1.2.3 Thực hiện và lặp lại

Phần thực hiện và lặp lại của qui trình này thể hiện một vùng phân chia mờ giữa

thực hiện và phân bổ phần cứng/phần mềm (được thể hiện ở hình 1.2). Trong bước này

phần thiết kế phần mềm và phần cứng sẽ được tách ra và thực hiện đồng thời. Giai

đoạn này thể hiện những công việc thiết kế đầu tiên trước khi đội phần cứng và phần

mềm thực hiện công việc cụ thể của lĩnh vực mình. Mặc dù các vấn đề chính đã được

phân bổ giữa các thành phần phần cứng và phần mềm, tuy nhiên vẫn còn những vấn đề

có thể dịch chuyển giữa ranh giới này khi các ràng buộc thiết kế được mô hình hoá và

hiểu rõ hơn. Trong giai đoạn này đòi hỏi người thiết kế thực hiện nhiều sự lựa chọn

liên quan đến công cụ, môi trường… Nhà thiết kế phần cứng có thể sử dụng các công

cụ mô phỏng để hỗ trợ cho quá trình thiết kế của mình như bộ mô phỏng kiến trúc.

Nhà thiết kế phần mềm có thể sẽ chạy những đoạn mã chuẩn trên những bo mạch đơn

độc lập sử dụng bộ vi xử lý đích. Những bo mạch này thường liên quan đến những

mạch đánh giá và chúng sẽ được dùng để đánh giá hiệu năng của bộ vi xử lý chạy trên

đoạn mã kiểm tra. Những mạch đánh giá này cũng cung cấp một môi trường gỡ lỗi và

thiết kế phần mềm thuận tiện cho đến khi hoàn thành xong phần cứng của hệ thống.

1.2.4 Thiết kế chi tiết phần cứng và phần mềm

Bước này đi sâu vào thực hiện thiết kế chi tiết phần cứng và phần mềm sau khi

đã có những đặc tả và phân chia các thành phần phần cứng, phần mềm. Ở giai đoạn

này cần có những công cụ đặc biệt để hỗ trợ quá trình thiết kế và mô hình một cách

trực quan. Ví dụ để thiết kế chi tiết phần cứng cần có các công cụ để mô tả phần cứng

như VHDL hay Verilog. Đối với phần mềm có rất nhiều công cụ hỗ trợ trong gia đoạn

này như: Timed CSP, Z, UML-Realtime…(sẽ được trình bày chi tiết hơn ở chương 2)



15

1.2.5 Tích hợp phần cứng phần mềm

Giai đoạn tích hợp giữa phần cứng và phần mềm của vòng đời phát triển hệ

thống nhúng phải có những công cụ đặc biệt và phương pháp để quản lý độ phức tạp.

Qui trình tích hợp phần cứng và phần mềm nhúng là quá trình thực nghiệm và gỡ lỗi.

Thực nghiệm ở đây có nghĩa là phải xác định xem phần mềm thiết kế ra có chạy tốt

trên nền phần cứng không và có thực sự hiểu tài liệu đặc tả phần cứng không. Ví dụ,

một vấn đề về big endian/ little endian trong quá trình tích hợp. Người thiết kế phần

cứng thực hiện thứ tự các byte được tổ chức theo big endian, còn người thiết kế phần

mềm cho rằng theo thứ tự little endian. Điều này có nghĩa là thành phần phần mềm và

phần cứng có thể đúng đắn trong quá trình thiết kế riêng nhưng bị lỗi trong quá trình

tích hợp do giao tiếp bị hiểu nhầm. Ví dụ: cổng tuần tự được thiết kế cho một ASIC

với một bus 16 bit vào ra. Cổng là vùng bộ nhớ ánh xạ tại địa chỉ 0x400000, 8 bit của

một từ là phần dữ liệu của cổng, 8 bít khác là phần trạng thái của cổng. Thậm chí

người thiết kế phần cứng có thể xác định những bit nào là trạng thái, bit nào là dữ liệu

thì người thiết kế phần mềm vẫn có thể gán sai địa chỉ cổng khi ghi vào cổng theo cách

truy cập byte (hình 1.4).

Hình 1.4 Một ví dụ về vấn đề big endian/little endian

Nếu sử dụng mô hình big endian và tính địa chỉ theo byte, thì thuật toán nên kiểm tra

các bít trạng thái tại địa chỉ 0x400001 và bít dữ liệu được đọc từ hoặc viết tới địa chỉ

0x400000. Nếu sử dụng mô hình bộ nhớ little endian thì ngược lại. Hệ thống nhúng

thường có độ phức tạp cao và hành vi không xác định mà nó chỉ có thể được phân tích

khi xảy ra. Việc cố gắng mô hình và mô phỏng chính xác hành vi của hệ thống có thể

mất nhiều thời gian hơn thời gian phát triển sản phẩm. Khi những công cụ mô hình

hoá được cải tiến thì sẽ nâng cao hơn khả năng tìm ra lỗi sớm.

Gỡ lỗi hệ thống nhúng cũng gần giống như gỡ lỗi ứng dụng trên Desktop. Nhìn

chung có ba yêu cầu cho việc gỡ lỗi hệ nhúng thời gian thực:



16

Kiểm soát thực thi - khả năng thực hiện, dừng, hoạt động tối đa của bộ xử lý và

bộ nhớ.

Thay thế bộ nhớ - thay thế bộ nhớ dựa trên ROM bằng RAM để nâng cao tốc

độ, dễ tải mã, gỡ lỗi và sửa đổi.

Phân tích thời gian thực - lần theo luồng mã để phân tích thời gian thực.

Nhiều hệ thống nhúng không thể gỡ lỗi trừ khi chúng được thực hiện ở tốc độ thực và

việc chạy một chương trình nhúng dưới bộ gỡ lỗi có thể làm chậm chương trình.

1.2.6 Kiểm thử

Kiểm thử hệ thống nhúng cần sự quan tâm đặc biệt vì không những nó phải

đảm bảo các chức năng của hệ thống hoạt động đúng và đủ mà còn phải đảm bảo cả về

yếu tố thời gian thực hiện. Đặc biệt trong những hệ thống an toàn, an ninh liên quan

đến mạng sống con người, việc kiểm thử cần phải thực hiện kỹ hơn vì chỉ cần một lỗi

nhỏ cũng gây ra những thảm họa đáng tiếc. Do đó yêu cầu về kiểm thử và độ tin cậy

đối với hệ thống nhúng đòi hỏi phải chặt chẽ hơn đa số các ứng dụng trên Desktop. Ví

dụ nhiều ứng dụng trên Desktop có những rò gỉ về bộ nhớ và khi chương trình chạy

được một khoảng thời gian thì máy tính sẽ bị tràn bộ nhớ, tuy nhiên trên Desktop thì

RAM và không gian swap là tương đối lớn và nhiều khi không phải là vấn đề. Ngược

lại đối với hệ thống nhúng, do chúng thường hoạt động liên tục nên chỉ cần một lỗi rò

gỉ bộ nhớ nhỏ cũng có thể gây ra trục trặc. Nếu phát hiện ra lỗi sớm hơn thì chi phí để

sửa lỗi sẽ ít hơn là khi phát hiện ra lỗi muộn, hình 1.5 dưới đây thể hiện mối liên hệ

này.

Hình 1.5 Mối liên hệ về chi phí sửa lỗi cho mỗi giai đoạn

1.2.7 Bảo trì và cập nhật

Đa số các nhà thiết kế hệ thống nhúng (khoảng 60 %) thực hiện bảo trì và nâng

cấp sản phẩm tồn tại hơn là thiết kế lại sản phẩm mới. Hầu hết họ không phải là những

thành viên của đội thiết kế ban đầu của sản phẩm, do đó họ phải dựa vào kinh nghiệm,

kỹ năng và những tài liệu về sản phẩm để hiểu sản phẩm ban đầu và thực hiện bảo trì

nâng cấp. Giai đoạn này đòi hỏi cần phải có những công cụ để bóc tách được những

vấn đề từ mã nguồn để nhanh chóng hiểu nó. Ví dụ muốn đáp ứng nhanh yêu cầu mới

đặt ra cho sản phẩm được thực hiện bằng cách cần tăng tốc độ bộ vi xử lý lên 25%, tuy

nhiên nó sẽ gây ra những thay đổi đến toàn bộ thiết kế, do đó cần có sự nghiên cứu kỹ

lưỡng với những giải pháp đưa ra.



17

CHƢƠNG 2: THIẾT KẾ PHẦN MỀM NHÚNG

2.1 Phần mềm nhúng

Trong những ngày đầu của hệ thống nhúng, tất cả những công việc xây dựng hệ

thống (bao gồm cả phần cứng và phần mềm) đều được xử lý bởi một kỹ sư. Các thành

phần phần mềm chỉ chiếm một phần nhỏ trong toàn bộ quá trình thiết kế và phát triển:

khoảng 5% đến 10%. Qua thời gian, phần công việc kỹ thuật dành cho phát triển phần

mềm nhúng đã tăng đáng kể. Vào giữa những năm 80 thì phần công việc được thực

hiện bởi các chuyên gia phần mềm lớn hơn 50%, và đến nay mặc dù thiết kế phần

cứng ngày càng trở lên phức tạp thì công sức giành cho xây dựng phần mềm nhúng

chiếm khoảng 70% đến 80%.

Hình 2.1 Phần mềm nhúng trong hệ thống

Do yêu cầu của hệ thống, ngày càng nhiều phần mềm cần được phát triển trong

một khoảng thời gian ngắn và môi trường để kiểm thử cho phần mềm nhúng cũng cần

sớm hơn (ngay trong quá trình phát triển phần mềm). Rất nhiều giải pháp đã được đưa

ra bao gồm những môi trường mẫu thực thi mã, mô phỏng tập chỉ thị, và sử dụng các

bảng mạch đánh giá chuẩn, chi phí thấp để kiểm thử phần mềm trên môi trường giống

môi trường đích. Ngoài ra những công nghệ kết nối máy chủ - máy đích chi phí thấp

cũng đang trở lên phổ biến, ví dụ sử dụng một giao tiếp JTAG. Điều này tạo điều kiện

cho các đội phần cứng và phần mềm nhúng thực sự phối hợp làm việc với nhau sử

dụng những kỹ thuật đồng thiết kế (co-design) và đồng kiểm chứng (coverification).

Thời gian dành cho phát triển phần mềm nhúng tăng lên, trong khi đó dưới áp

lực cạnh tranh thì thời gian đưa các sản phẩm nhúng ra thị trường đang giảm xuống.

Điều này ảnh hưởng nhanh chóng đến chiến lược thiết kế. Những thiết kế ban đầu

thường khá đơn giản, chỉ bao gồm những mã chương trình được thiết kế của một tổ



18

chức, đơn vị. Khi các hệ thống đã trở lên phức tạp, một mô hình đa nhiệm đã được áp

dụng rộng rãi cho phát triển phần mềm và nhiều nhà phát triển đã sử dụng những sản

phẩm hệ điều hành thời gian thực (RTOS) thương mại chuẩn cho hệ thống của mình.

Phần phần mềm mua sẵn hay sở hữu trí tuệ (intelectual property - một từ vay mượn từ

thiết kế phần cứng) trong hệ nhúng đã tăng lên đều đặn và xem như một tiêu chuẩn để

áp dụng. Được thể hiện trong hình vẽ 2.2.

Hình 2.2 Thành phần phần mềm nhúng

Phần mềm cho hệ thống nhúng có những yêu cầu khác với những phần mềm

chạy trên máy tính cá nhân hoặc trên máy trạm. Ngoài việc trả lời câu hỏi “Hệ thống

phải làm gì?” người thiết kế phải biết được “Thời gian đáp ứng cho chức năng đó là

bao lâu?”.

2.1.1 Sự khác biệt giữa phần mềm nhúng và phần mềm thông thƣờng trên

PC

Sự khác nhau giữa việc phát triển hệ thống nhúng và hệ thống chạy trên máy tính

thông thường có thể liệt kê một số điểm như sau [13]:

Hệ thống nhúng được thiết kế cho các tác vụ đặc biệt, trong khi các máy tính là

các nền tảng tính toán và xử lý chung. Các bộ xử lý trong hệ thống nhúng là các

vi xử lý chuyên biệt. Nó được lập trình chỉ để thực hiện một vài tác vụ. Thay

đổi các tác vụ có thể đòi hỏi phải thiết kế lại hệ thống hoặc thay đổi toàn bộ hệ

thống.

Hệ thống nhúng được hỗ trợ bởi một số lượng lớn các vi xử lý và kiến trúc vi

xử lý.

Hệ thống nhúng thường được cân nhắc cùng với chi phí phát triển.



19

Các hệ thống nhúng được thiết kế cùng với phần cứng được chỉ định sẵn. Chính

vì thế, tính năng của hệ thống luôn được cân nhắc cùng với chi phí phát triển.

Ngoài ra với một số tác vụ cần phải có những phần cứng chuyên biệt.

Hệ thống nhúng có các ràng buộc thời gian thực: phần này được đặc tả trong hệ

thống nhúng thời gian thực.

Nếu hệ thống nhúng sử dụng hệ điều hành thì hầu như nó phải sử dụng hệ điều

hành thời gian thực. Giống như vi xử lý nhúng, hệ điều hành nhúng cũng có rất

nhiều (cả thương mại và phi thương mại) và có cách quản lý khác nhau. Tuy

nhiên mục tiêu quan trọng là nó phải giải quyết các vấn đề khắt khe về mặt thời

gian và chia sẻ tài nguyên.

Khó khăn khi xử lý lỗi phần mềm nhúng: với phần mềm nhúng, việc debug

chương trình để tìm lỗi đòi hỏi phải có những phần cứng hỗ trợ, thông thường

được gọi là emulator.

Hệ thống nhúng có ràng buộc về điện năng: Với nhiều hệ thống nhúng vấn đề

năng lượng được coi là quan trọng hàng đầu. Phương pháp đầu tiên để duy trì

năng lượng Pin là tắt bớt các dịch vụ không cần thiết trong quá trình hoạt động

hoặc chuyển vào các chế độ tiết kiệm năng lượng khi cần thiết. Hầu hết các vi

xử lý cho hệ thống nhúng đều có các chế độ tiết kiệm năng lượng. Phần mềm

thường đặt bộ vi xử lý trong những chế độ này với các chỉ thị đặc biệt hoặc ghi

một giá trị tới thanh ghi điều khiển bên trong vi xử lý. Các chế độ tiết kiệm điện

thường thấy như: sleep mode, low-power mode, idle mode, standby mode, ...

Hệ thống nhúng thường chạy trong môi trường có điều kiện khắt khe: Hệ thống

nhúng có mặt ở mọi nơi và có thể được thiết kế để làm mọi thứ. Chính vì thế

khi thiết kế hệ thống phải đặc biệt chú trọng tới các yếu tố phần cứng có khả

năng chịu được điều kiện môi trường. Ví dụ như các hệ thống nhúng kiểm tra

trong hầm lò, lò phản ứng hạt nhân, trên không gian...

Hệ thống nhúng có ít tài nguyên (tốc độ xử lý của CPU, bộ nhớ, cổng vào ra ...)

hơn nhiều so với các ứng dụng Desktop.

Chương trình của hệ thống nhúng được lưu trong ROM.

2.1.2 Nguyên tắc thiết kế chung

Thiết kế hệ thống nhúng phải đối mặt với nhiều yếu tố tác động và thông

thường phức tạp hơn việc thiết kế các ứng dụng trên desktop. Trong quá trình thiết kế,

không những người thiết kế phải trả lời câu hỏi hệ thống làm gì mà còn phải biết được

tốc độ thực thi của hệ thống và khả năng đáp ứng thời gian từ đó đưa ra những lựa

chọn trong quá trình thiết kế. Thời gian thực thi luôn là yếu tố đặc trưng của một hệ

thống nhúng thời gian thực. Hơn nữa, phải xác định khoảng thời gian thực thi nào

quan trọng để điều tiết bộ lập lịch. Điều này phụ thuộc vào tính chất của hệ thời gian

thực cứng hay mềm.



20

Để thiết kế phần mềm hiệu quả, chúng ta cũng phải biết về các thiết bị phần

cứng. Ví dụ hệ thống của chúng ta sẽ nhận dữ liệu từ một cổng tuần tự ở tốc độ 9600

bit (khoảng 1000 ký tự) trên giây. Nếu mỗi ký tự nhận được sinh ra một ngắt thì phần

mềm thiết kế phải đảm bảo phục vụ được các hàm ngắt cổng tuần tự thực hiện 1000

lần trong một giây. Ngược lại, nếu phần cứng cổng tuần tự có thể copy những ký tự

đến vào bộ nhớ thông qua một kênh DMA và hệ thống không phải quan tâm đến các

ký tự ngay lập tức khi chúng đến thì ta sẽ không phải xử lý hàm ngắt nhiều như trường

hợp trên nữa. Chúng ta cũng phải biết được tốc độ của bộ vi xử lý để xác định xem

mỗi tính toán mất bao nhiêu thời gian và liệu nó có ảnh hưởng đến deadline không khi

thiết kế.

Thiết kế phần mềm nhúng cũng sử dụng những kỹ năng kỹ nghệ phần mềm nói

chung. Các khái niệm cấu trúc, mô-đun, thành phần, lớp, đối tượng cũng đóng vai trò

quan trọng trong thế giới phần mềm nhúng. Các công cụ và phương pháp thiết kế cũng

vậy, có những cái chung hoặc mở rộng cho thiết kế hệ thống nhúng. Không có công cụ

nào có thể đảm bảo được chất lượng thiết kế hệ nhúng, mà chất lượng thiết kế phụ

thuộc vào kinh nghiệm, sự hiểu biết và tính cẩn thận của người thiết kế.

Do việc gỡ lỗi và kiểm thử cho hệ thống nhúng khá là khó khăn nên trong quá

trình thiết kế cần xem xét đến vấn đề này.

2.1.3 Thiết kế phần mềm nhúng với RTOS

a. Hoạt động chung

Các hệ thống nhúng thường không làm gì cho đến một thời điểm nào đó hoặc

có sự kiện bên ngoài yêu cầu đáp ứng. Ví dụ: nếu không có dữ liệu để in, các máy in

laser sẽ không làm gì ngoài việc “wake up” từng phút hoặc dịch chuyển trống máy in

một chút. Nếu người dùng không nhấn công tắc hoặc các phím thì máy quét mã vạch

sẽ chuyển sang trạng thái nghỉ ngơi cho bộ xử lý.

Do các sự kiện bên ngoài thường gây ra các ngắt, và có thể gây ra ngắt bằng

cách đặt thời gian trong bộ định thời, các ngắt trở thành một yếu tố điều khiển của

phần mềm nhúng. Một kỹ thuật thiết kế hệ thống nhúng thường dùng là khoá từng tác

vụ của RTOS mà ngốn nhiều thời gian lại và đợi cho một hàm ngắt hoặc tác vụ khác

gửi một thông điệp hay gây ra một sự kiện hoặc giải phóng một semaphore để thông

báo cho tác vụ đó biết có việc cần xử lý. Khi một ngắt xảy ra, hàm ngắt sử dụng các

dịch vụ RTOS để truyền tín hiệu cho một hoặc nhiều tác vụ. Từng tác vụ sẽ thực hiện

công việc của mình và có thể lại truyền tín hiệu cho một tác vụ khác. Theo cách này,

từng ngắt có thể tạo ra một dãy các tín hiệu và các hoạt động của tác vụ.

b. Viết các hàm ngắt ngắn gọn

Nhìn chung viết các hàm ngắt ngắn gọn thì tốt hơn là viết các hàm ngắt dài thực

hiện nhiều công việc. Có hai lý do để thực hiện điều này: Thứ nhất, vì ngay cả những

hàm ngắt có độ ưu tiên thấp nhất vẫn được ưu tiên thực hiện trước những mã tác vụ có

mức ưu tiên cao nhất. Viết những hàm ngắt dài sẽ làm cho sự đáp ứng các mã tác vụ



21

chậm hơn. Thứ hai là, các hàm ngắt thường có xu hướng gây ra nhiều lỗi và khó gỡ lỗi

hơn mã tác vụ.

Hầu hết các sự kiện yêu cầu những đáp ứng khác nhau từ hệ thống phần mềm:

hệ thống phải khởi tạo lại cổng phần cứng, lưu lại dữ liệu nhận được, khởi tạo lại bộ

điều khiển ngắt, phân tích dữ liệu nhận được, tính toán các đáp ứng,…Thời hạn đối

với những đáp ứng này có thể rất khác nhau. Mặc dù khởi tạo lại cổng phần cứng và

bộ điều khiển ngắt, lưu dữ liệu có thể cần ngay lập tức, nhưng việc phân tích dữ liệu

và đáp ứng cho nó thường không gấp như vậy. Do đó trong hàm ngắt nên xử lý những

hành động cần đáp ứng gấp và sau đó truyền tín hiều cho một tác vụ để thực hiện

những công việc còn lại.

c. Phân chia bao nhiêu tác vụ cho phù hợp?

Một trong những vấn đề đầu tiên khi thiết kế hệ thống nhúng là việc phân chia

công việc hệ thống ra thành các tác vụ RTOS. Một câu hỏi đặt ra là “liệu phân chia ra

thành nhiều tác vụ thì tốt hay ít tác vụ thì tốt ?”. Để trả lời câu hỏi này, hãy xem xét

những ưu nhược điểm mà ảnh hưởng đến việc phân chia tác vụ:

Ƣu điểm:

Với nhiều tác vụ hơn, chúng ta sẽ kiểm soát thời gian đáp ứng các phần khác

nhau của công việc được tốt hơn. Ví dụ ta chia công việc của một hệ thống ra

thành 8 tác vụ thì lúc đó có thể gán được 8 mức ưu tiên khác nhau cho các tác

vụ. Chúng ta sẽ có được thời gian đáp ứng tốt cho công việc được thực hiện ở

những tác vụ có mức ưu tiên cao hơn. Nếu ta sử dụng số tác vụ trong khoảng từ

1 đến 8 thì sẽ nhận được những đáp ứng trong khoảng đó.

Với nhiều tác vụ hơn, hệ thống sẽ được chia thành nhiều mô-đun xử lý độc lập

hơn. Ví dụ nếu hệ thống có một máy in, một cổng tuần tự, một kết nối mạng,

một bàn phím và nếu xử lý tất cả những thiết bị này trong một tác vụ, thì tác vụ

đó sẽ dễ bị nhầm lẫn và rối tung lên. Sử dụng tác vụ tách biệt cho từng thiết bị

sẽ làm cho chương trình rõ ràng và dễ xử lý hơn.

Với nhiều tác vụ hơn, ta có thể bao gói dữ liệu hiệu quả hơn. Nếu kết nối mạng

được xử lý bởi một tác vụ tách biệt thì chỉ có mã trong tác vụ đó cần truy cập

tới các biến chỉ trạng thái của giao tiếp mạng.

Nhƣợc điểm:

Với nhiều tác vụ hơn, chúng ta có thể có nhiều dữ liệu được chia sẻ giữa các tác

vụ hơn. Điều này dẫn tới cần nhiều cơ chế semaphore để kiểm soát và do đó sẽ

mất nhiều thời gian để bộ vi xử lý xử lý semaphore hơn và cũng có thể gây ra

nhiều lỗi liên quan đến semaphore.

Với nhiều tác vụ hơn, chúng ta có thể cần nhiều yêu cầu để truyền thông điệp từ

một tác vụ tới tác vụ khác thông qua pipe, mailbox, queue …Điều này cũng dẫn

tới mất nhiều thời gian xử lý và có cơ hội xảy ra lỗi hơn.



22

Mỗi tác vụ đều yêu cầu một stack; do đó với nhiều tác vụ hơn sẽ cần phải cấp

nhiều bộ nhớ hơn, ít nhất là cho stack và có khi còn cho các thông điệp giữa các

tác vụ.

Mỗi lần RTOS chuyển tác vụ, bộ xử lý sẽ phải mất thời gian để lưu lại những

trạng thái của tác vụ đó và khôi phục lại khi thực hiện tiếp. Một điều khác nữa

là khi thiết kế nhiều tác vụ thì có thể dẫn đến RTOS chuyển tác vụ nhiều hơn và

làm giảm thông lượng của hệ thống.

Nhiều tác vụ hơn cũng đồng nghĩa với việc có nhiều lời gọi tới RTOS hơn. Các

nhà sản xuất RTOS có thể nâng cao những sản phẩm của họ bằng cách thông

báo thời gian chuyển đổi giữa các tác vụ của hệ thống, đặt các thông điệp vào

mailbox, đặt các sự kiện …Điều đó sẽ làm cho sản phẩm của họ nhanh hơn, tuy

nhiên các chức năng RTOS sẽ không làm những thứ mà khách hàng quan tâm.

Do đó thông qua việc xem xét các ưu nhược điểm của việc phân chia tác vụ trên,

người thiết kế hệ thống sẽ phải nghiên cứu rất kỹ lưỡng các yếu tố để tiến hành phân

chia tác vụ hợp lý cho hệ thống của mình. Và thêm tác vụ chỉ khi có những lý do cần

thiết như:

Cần các tác vụ cho mức ưu tiên: Ưu điểm rõ ràng của kiến trúc RTOS

đối với những kiến trúc khác là nâng cao được khả năng điều khiển đáp

ứng của các mã tác vụ. Do đó có nhiều tác vụ sẽ có khả năng gán những

mức ưu tiên cao hơn cho các phần việc đòi hòi yêu cầu thời gian đáp ứng

chặt chẽ hơn. Ví dụ trong hệ thống nhúng theo dõi bể xăng ngầm, sự

kiện bấm nút sẽ cần đáp ứng tốt hơn những tính toán về mức xăng (mất

nhiều thời gian), vậy nên mã viết cho hai phần này của hệ thống cần

được đưa vào những tác vụ riêng rẽ.

Cần những tác vụ cho việc gói gọn: Khi xử lý với phần cứng được chia

sẻ bởi các phần khác nhau của hệ thống thì nên thêm vào đó một tác vụ

riêng biệt. Ví dụ, mã xử lý các nút bấm trên một bảng nút phía trước máy

in laser, sử dụng màn hình máy in để trả kết quả lại cho người dùng, và

mã dùng để di chuyển giấy thông qua cơ chế của máy in cũng sử dụng

màn hình để hiển thị hết giấy hoặc kẹt giấy. Nếu cả hai phần của hệ

thống đều có thể ghi trực tiếp ra màn hình thì có thể sinh ra tranh chấp

do cả hai có thể đều muốn ghi ra màn hình cùng một thời điểm. Nên việc

đưa thêm một tác vụ tách biệt để điều khiển màn hình là cần thiết và có

thể giải quyết được vấn đề này. Khi những tác vụ khác trong hệ thống có

thông tin cần ghi ra màn hình chúng sẽ gửi thông điệp tới tác vụ màn

hình. RTOS sẽ đảm bảo việc đưa các thông điệp vào queue và xác định

xem thông điệp nào được hiển thị trước. Tương tự như vậy, nếu có nhiều

phần của hệ thống muốn lưu dữ liệu vào một bộ nhớ flash thì nên thêm

một tác vụ riêng có trách nhiệm quản lý bộ nhớ flash sẽ làm đơn giản

hoá vấn đề.



23

d. Sử dụng cấu trúc tác vụ hiệu quả

Tác vụ duy trì một vòng lặp vô hạn chờ tín hiệu từ RTOS để thực hiện một

công việc nào đó. Tín hiệu thường được định dạng trong một thông điệp từ hàng đợi.

Tác vụ này khai báo các dữ liệu private của nó.

Hình 2.3 Cấu trúc đề nghị của một tác vụ

Ưu điểm của cấu trúc này là:

Khi tác vụ không làm gì cả, hàng đợi đầu vào của nó sẽ ở trạng thái trống

(empty), tác vụ sẽ bị khoá và không tiêu tốn thời gian xử lý của CPU.

Tác vụ này không chứa các dữ liệu public cho các tác vụ khác chia sẻ. Các tác

vụ khác muốn xem hoặc thay đổi dữ liệu private của tác vụ này cần viết một

yêu cầu gửi tới hàng đợi. Do đó không có dữ liệu chia sẻ và không có

semaphore.

Tác vụ trong hệ thống nhúng thường được cấu trúc như các máy trạng thái: trạng thái

được lưu trong các biến private của tác vụ, thông điệp mà tác vụ nhận được trong hàng

đợi của nó là các sự kiện.

e. Tránh việc khởi tạo và huỷ các tác vụ

Mọi RTOS cho phép tạo các tác vụ khi hệ thống khởi động. Hầu hết RTOS cho

phép tạo và huỷ các tác vụ khi hệ thống đang chạy. Tuy nhiên, ta nên tránh các hành

động này vì hai lý do như sau: thứ nhất, các hàm tạo và huỷ tác vụ thường tiêu tốn

nhiều thời gian xử lý của CPU, thường cao hơn nhiều so với việc nhận một semaphore

hoặc ghi một thông điệp vào mailbox. Thứ hai, khi tạo một tác vụ thì thao tác này

tương đối tin cậy nhưng thao tác huỷ bỏ tác vụ là một thao tác không tin cậy vì khó có

thể huỷ bỏ một tác vụ mà không để lại một chút gì liên quan và dễ sinh ra lỗi. Ví dụ,



24

nếu huỷ một tác vụ trong khi tác vụ đó đang nắm giữ một semaphore, khi mà các tác

vụ khác cần semaphore đó có thể bị khoá mãi mãi.

f. Xem xét đến việc tắt phân lát thời gian

Chúng ta biết rằng bộ lập lịch RTOS luôn thực hiện những tác vụ sẵn sàng có

độ ưu tiên cao nhất. Tuy nhiên có vấn đề nảy sinh khi có hai hay nhiều tác vụ có cùng

mức ưu tiên và không tác vụ nào có mức ưu tiên cao hơn. Một lựa chọn mà hầu hết các

RTOS đưa ra trong tình huống này là chia nhỏ thời gian thành các lát, để bộ xử lý thực

hiện luân phiên tất cả các tác vụ, mỗi tác vụ trong một lát thời gian ngắn. (thực hiện

tác vụ này trong một lát thời gian được chia rồi lại chuyển sang tác vụ khác và cứ như

vậy cho đến khi thực hiện xong). Lựa chọn này rất là tuyệt vời khi có nhiều người

dùng có chương trình chạy trên cùng một hệ thống, nếu sử dụng các lát thời gian chia

nhỏ thì từng chương trình sẽ được gán CPU để xử lý công việc và mọi người đều thấy

tiến triển công việc của mình. RTOS cũng cho phép chúng ta tắt lựa chọn này. Với

nhiều hệ thống ta nên cân nhắc để làm việc này vì phân chia nhỏ thời gian cho các tác

vụ cũng sẽ dẫn đến có nhiều chuyển đổi tác vụ trong khi thực hiện nên sẽ gây ra làm

giảm thông lượng của hệ thống.

g. Hạn chế các dịch vụ không cần thiết của RTOS trong hệ thống

Hầu hết các RTOS, ngay cả những cái khá nhỏ cũng đều đưa ra nhiều dịch vụ

hơn so với nhu cầu sử dụng trong một dự án cụ thể. Do nhiều RTOS cho phép cấu

hình lại chúng để loại bỏ những dịch vụ không cần thiết cho dự án, ta có thể tiết kiệm

được không gian nhớ và khả năng tính toán của CPU bằng việc cấu hình một tập các

dịch vụ RTOS đủ dùng cho hệ thống của mình. Ví dụ nếu hệ thống cần xây dựng sử

dụng bảy pipe và một queue, chúng ta sẽ phải thêm cả mã pipe và mã queue vào trong

hệ thống. Nếu có thể thay thế queue bằng cái pipe thứ tám, ta có thể loại bỏ mã queue

RTOS ra khỏi hệ thống.

Nhiều nhà thiết kế hệ nhúng thích đưa các shell vào trong RTOS và gọi shell

thay vì gọi trực tiếp RTOS từ mã. Điều này không chỉ hạn chế phần còn lại của mã với

tập các dịch vụ của RTOS đã được lựa chọn, mà còn làm cho mã chương trình trở lên

khả chuyển hơn từ RTOS này tới các RTOS khác bởi vì chỉ cần viết lại shell.

2.2 Kiến trúc phần mềm nhúng

Người ta chia kiến trúc hệ thống nhúng ra làm 4 loại [13]: Round robin, Round

robin với ngắt, Function-queue-scheduling và hệ điều hành thời gian thực.

2.2.1 Round robin

Đây là kiến trúc đơn giản nhất, nó không có cơ chế ngắt, không có vấn đề về dữ

liệu chia sẻ (thường xẩy ra đối với kiến trúc có cơ chế ngắt) và vấn đề về độ trễ. Vòng

lặp chính đơn giản chỉ kiểm tra lần lượt từng thiết bị vào ra và phục vụ khi thiết bị đó

yêu cầu. Dưới đây là khuôn mẫu về kiến trúc này:



25

Hình 2.4 Kiến trúc Round robin

Do tính đơn giản của nó, kiến trúc round – robin được áp dụng cho việc thiết kế một số

hệ thống nhúng đơn giản.

Ví dụ: Kiến trúc này được áp dụng cho thiết kế thiết bị đo điện tử. Thiết bị này

dùng để đo điện trở, cường độ và hiệu điện thế dòng điện theo các đơn vị ohm, amp,

vol trong một số khoảng khác nhau. Một thiết bị đo điện tử thông thường có 2 cực mà

người sử dụng sẽ dùng để chạm vào 2 điểm của mạch điện cần đo, một màn hình hiển

thị, và một nút xoay to dùng để chọn đơn vị và khoảng để đo. Hệ thống sẽ đo và hiển

thị kết quả gần nhất vừa đo. Tại mỗi thời điểm hệ thống sẽ kiểm tra vị trí của nút xoay

và thực hiện tính toán đo tương ứng sau đó định dạng kết quả đưa ra màn hình. Kiến

trúc Round-robin hoạt động tốt đối với hệ thống này bởi vì chỉ có 3 thiết bị vào ra,

không có những yêu cầu chặt về thời gian đáp ứng của hệ thống. Bộ vi xử lý có thể

đọc phần cứng và đưa ra những đánh giá thích hợp tại mỗi thời điểm. Kiến trúc này chỉ

có được ưu điểm là sự đơn giản so với các kiến trúc khác, trong khi đó nó có một số

nhược điểm mà không thể áp dụng được cho nhiều hệ thống:

Khi một thiết bị nào đó cần thời gian đáp ứng nhanh hơn thời gian mà bộ xử lý

phải đi qua và xử lý tất cả các thiết bị trong vòng lặp thì hệ thống không đáp

ứng được.

Nếu thời gian đáp ứng không yêu cầu tuân thủ tuyệt đối một deadlines thì hệ

thống cũng chưa chắc đã hoạt động tốt vì khi trong vòng lặp có một việc xử lý

chiếm nhiều thời gian.

Kiến trúc này không bền vững (fragile).

2.2.2 Round robin với ngắt

Kiến trúc này phức tạp hơn vì có thêm vào cơ chế ngắt, các hàm ngắt dùng để

xử lý những việc cấp thiết của phần cứng và sau đó thiết lập các cờ. Nó cho phép

chúng ta điều khiển một chút về mức độ ưu tiên và hàm ngắt sẽ nhận được thời gian

đáp ứng tốt bởi vì tín hiệu ngắt sẽ làm cho bộ xử lý dừng những công việc đang xử lý

và thay vào đó là thực hiện công việc trong hàm ngắt. Tất cả những việc xử lý cho vào

trong hàm ngắt thì đều có mức độ ưu tiên cao hơn mã tác vụ trong vòng lặp chính.



26

Hơn nữa ta có thể gán nhiều mức độ ưu tiên cho cho các hàm ngắt trong hệ thống và

điều khiển được mức độ ưu tiên đó. Khuôn mẫu của kiến trúc này như sau:

Hình 2.5. Kiến trúc Round-robin with interrupts

Nhược điểm chính của kiến trúc này là tất cả các mã tác vụ đều thực hiện ở mức độ ưu

tiên như nhau. Giả sử rằng những phần xử lý trong mã tác vụ của hình trên với các

thiết bị A, B, và C mất khoảng 200 mili giây cho mỗi thiết bị. Nếu tất cả các thiết bị A,

B, C đều ngắt khi bộ vi xử lý thực hiện câu lệnh tại đỉnh vòng lặp, thì mã tác vụ cho

thiết bị C có thể phải đợi tới 400 mili giây trước khi nó bắt đầu được xử lý.

2.2.3 Kiến trúc Function – Queue - Scheduling

Trong kiến trúc này, các hàm ngắt sẽ thêm những con trỏ hàm vào hàng đợi con

trỏ hàm cho hàm chính gọi. Hàm chính chỉ đọc các con trỏ từ hàng đợi và gọi các hàm.

Điều làm cho kiến trúc này trở lên thú vị là không có luật nào nói rằng hàm main()

phải gọi các hàm theo một thứ tự nhất định mà các hàm ngắt xảy ra. Nó có thể gọi

chúng dựa trên bất kỳ lược đồ về mức ưu tiên phù hợp với mục đích của người thiết

kế. Bất kỳ hàm tác vụ nào muốn đáp ứng nhanh hơn có thể được thực hiện sớm hơn.

Dưới đây là khuôn mẫu của kiến trúc này.



27

Hình 2.6 Kiến trúc Function-Queue-Scheduling

Mặc dù kiến trúc function-queue-scheduling làm giảm thời gian đáp ứng xấu

nhất của hệ thống đối với những mã tác vụ có mức độ ưu tiên cao, nhưng nó vẫn còn

chưa đủ tốt bởi vì một số hàm mã tác vụ có mức độ ưu tiên thấp hơn sẽ phải chờ khá

lâu, nó sẽ ảnh hưởng đến thời gian đáp ứng của những hàm có mức ưu tiên cao hơn.

2.2.4 Kiến trúc Hệ điều hành thời gian thực (RTOS)

Trong kiến trúc này, như những phần trước chúng ta đã thảo luận thì hàm ngắt

sẽ tiếp quản những việc xử lý cấp thiết nhất (những thứ mà không thể chờ được), sau

đó chúng truyền tín hiệu cho mã tác vụ để thực hiện những công việc còn lại. Sự khác

nhau giữa kiến trúc này với các kiến trúc trước là:

- Việc đánh tín hiệu giữa các hàm ngắt và với mã tác vụ được xử lý bởi hệ

điều hành thời gian thực. Chúng ta không cần phải sử dụng những biến dùng

chung cho mục đích này.

- Không có vòng lặp trong mã để quyết định xem sẽ thực hiện công việc gì

tiếp theo. Hệ điều hành thời gian thực biết được tất cả những công việc cần

thực hiện và nó sẽ thực thi những công việc nào cần thiết tại mỗi thời điểm.

- Hệ điều hành thời gian thực có thể tạm thời dừng một hàm mã tác vụ đang

được xử lý để thực hiện một nhiệm vụ khác.

Có rất nhiều Hệ điều hành thời gian thực mà ta có thể mua để áp dụng cho mục đích

cụ thể và khi mua hệ điều hành này ta sẽ có ngay những giải pháp cho vấn đề thời gian

đáp ứng cùng với các công cụ gỡ lỗi. Nhược điểm chính của kiến trúc này là vấn đề

bản thân hệ điều hành thời gian thực cũng cần thời gian để xử lý những công việc của

hệ điều hành. Chúng ta sẽ nhận được thời gian đáp ứng tốt hơn khi tiêu tốn ít thông

lượng.



28

Hình 2.7 Kiến trúc Hệ điều hành thời gian thực

2.3 Các phƣơng pháp đặc tả và thiết kế phần mềm nhúng

2.3.1 Phƣơng pháp đặc tả hình thức (formal method)

Các phương pháp hình thức là các kỹ thuật toán học cho việc đặc tả, phát triển

và kiểm định các hệ thống phần mềm và phần cứng. Cách tiếp cận này đặc biệt quan

trọng đối với các hệ thống cần có tính toàn vẹn cao, chẳng hạn hệ thống điều khiển lò

phản ứng hạt nhân hay điều khiển tên lửa, khi an toàn hay an ninh có vai trò quan

trọng, để góp phần đảm bảo rằng quá trình phát triển hệ thống sẽ không có lỗi, điều

này cũng rất phù hợp cho phát triển các hệ thống nhúng vì đòi hỏi những yêu cầu ràng

buộc khắt khe. Các phương pháp hình thức đặc biệt hiệu quả tại giai đoạn đầu của quá

trình phát triển (tại các mức yêu cầu và đặc tả hệ thống), nhưng cũng có thể được sử

dụng cho một quá trình phát triển hoàn chỉnh của một hệ thống.

Các phương pháp hình thức có thể được sử dụng để mô tả về hệ thống cần phát

triển, tại bất kỳ mức độ chi tiết nào và bất cứ pha nào trong vòng đời phát triển phần

mềm. Khi một đặc tả hình thức đã được phát triển xong, đặc tả đó có thể được sử dụng

làm một hướng dẫn trong quá trình hệ thống thực được phát triển (nghĩa là được hiện

thực hóa trong phần mềm hoặc phần cứng). Sau đó đặc tả này có thể được dùng làm cơ

sở cho việc chứng minh các tính chất của hệ thống. Các đặc tả hình thức mô tả ở mức

độ chính xác logic cao. Nó loại trừ những nhầm lẫn mập mờ không tránh khỏi trong



29

các đặc tả phi hình thức. Tính chính xác này giúp cho người diễn tả và người đọc

chúng có tiếng nói chung, đạt được sự nhất quán, giúp cho phát triển hệ thống ổn định

an toàn.

Định nghĩa đặc tả hình thức:

Đặc tả hình thức là một mô tả chính xác các hành vi và thuộc tính của hệ thống

được viết trên một số ngôn ngữ có cơ sở toán học, nó mô tả một cách ngắn gọn và chặt

chẽ các yêu cầu mà một hệ thống được giả định là sẽ thực hiện. Vì vậy có thể loại trừ

những chi tiết mập mờ và mô tả được những thay đổi tổng quát cộng với những thay

đổi của hệ thống trong tương lai.

Có khá nhiều phương pháp hình thức được áp dụng cho đặc tả, phát triển và

kiểm định các hệ thống nhúng, thời gian thực. Trong bài luận văn này đưa ra giới thiệu

các phương pháp phổ biến đã được nghiên cứu và ứng dụng rộng rãi để phát triển các

hệ thống trong công nghiệp. Ngoài ra, do yêu cầu và đặc trưng của từng loại hệ thống

nhúng người ta còn có thể kết hợp các phương pháp hình thức với nhau hoặc với các

phương pháp bán hình thức (sẽ được trình bầy ở phần sau) để mô tả đầy đủ và chính

xác về hệ thống cần xây dựng.

a. Timed CSP (Communicating Sequential Processes)

Timed CSP là ngôn ngữ đặc tả mở rộng về tính thời gian thực của CSP. Nó là

một ngôn ngữ đặc tả hình thức để mô hình và phân tích các hành vi điều khiển động

của các hệ thống song song và phân tán. Trong Time CSP yếu tố thời gian thực được

mô hình bởi các số thực dương.

Một số tiến trình mô hình các mẫu hành vi của một hệ thống hay một thành

phần, các mẫu này sẽ quyết định việc điều khiển các hành động nội tại và môi trường.

Các thao tác tiến trình cho phép phân tách các tiến trình theo một cấu trúc phân cấp

thành các tiến trình con tương tác với nhau. Trong Timed CSP có hai cách khác nhau

để định nghĩa một tiến trình: thuật ngữ tiến trình và vị từ.

Timed CSP là ngôn ngữ đặc tả mạnh để mô hình các hành vi động. Tuy nhiên

nó không cung cấp bất kỳ cấu trúc nào để mô hình hành vi có thể chuyển đổi dữ liệu.

Vì vậy, Timed CSP thường được sử dụng kết hợp với một ngôn ngữ đặc tả khác như

Z.

b. Đặc tả B

B là ngôn ngữ đặc tả được phát triển tại Bell Labs và xuất hiện khoảng năm

1969. Nó được áp dụng rộng rãi trong công nghiệp và trong các trường học để xây

dựng hệ thống đòi hỏi tính đúng đắn, chặt chẽ (bao gồm cả hệ thống nhúng - thời gian

thực).

Theo phương pháp B, những yêu cầu ban đầu được thể hiện thành tập các máy

trừu tượng và sử dụng cách tiếp cận hướng đối tượng trong các giai đoạn phát triển. B

dựa trên tập hợp các ký hiệu đủ mạnh để thể hiện các mức độ từ đặc tả, thiết kế đến

thực hiện hệ thống. Nó cũng cung cấp các công cụ để kiểm tra cú pháp, kiểm tra mô

hình, chứng minh và các công cụ sinh mã.



30

c. Đặc tả Z

Một đặc tả viết trong Z là sự trộn lẫn của các câu lệnh toán học, hình thức, với

các văn bản giải thích phi hình thức. Phần mô tả hình thức: cho một số mô tả chính

xác, khoa học của hệ thống. Còn phần phi hình thức để làm tài liệu.

Thành phần hình thức của Z sử dụng lý thuyết tập hợp quen thuộc (lý thuyết tập

hợp có phân loại). Đặc biệt hơn nữa, đặc tả Z sử dụng các sơ đồ cho phép nhóm các

đối tượng đặc tả lại thành các bộ phận.

Đặc tả Z có thể được ứng dụng vào tất cả các pha của vòng đời phần mềm. Và

kinh nghiệm đã chỉ ra rằng việc xây dựng một mô hình toán học cho hệ thống như Z sẽ

mạng lại lợi ích to lớn trong qúa trình phát triển phần mềm. Hiện nay có một số công

cụ hỗ trợ Z như CICS của IBM, Inmos T800 của Transputer, …

d. ObjectZ và TCOZ (RT-Z) (tích hợp của ObjectZ và timed CSP)

Cốt lõi của ObjectZ là ngôn ngữ Z. ObjectZ mở rộng đặc tả theo hướng đối

tượng cho phép đặc tả có thể tạo ra các lớp và tính kế thừa các lớp. ObjectZ được mở

rộng để đặc tả các hệ thống có tính liên tục và thời gian thực.

RT-Z là kết hợp của ngôn ngữ Z và Timed CSP cho phép đặc tả các hệ thống

thời gian thực. Ngôn ngữ Z đặc tả sâu tính cấu trúc còn Timed CSP lại biểu diễn rất tốt

cho các hệ thống thời gian thực.

e. Mạng Petri (Pertrinet)

Năm 1962 Carl Adam Petri đã công bố phương pháp mô hình hình họa tác vụ

hay quá trình theo sự phụ thuộc nhân quả đã được phổ cập rộng rãi và được biết tới

như ngày này với tên gọi là mạng Petri. Ngôn ngữ đặc tả hình thức nổi tiếng về tính

hiệu quả.

Mạng Petri được sử dụng phổ biến để biểu diễn mô hình và phân tích các hệ

thống có sự cạnh tranh trong quá trình hoạt động. Một hệ thống có thể hiểu là một tổ

hợp của nhiều thành phần và mỗi thành phần thì đều có các thuộc tính. Các thuộc tính

đó có thể thay đổi và được đặc trưng bởi các biến trạng thái. Một chuỗi các trạng thái

sẽ mô tả quá trình động của một hệ thống. Mạng Petri thực sự là một giải pháp mô tả

hệ thống động với các sự kiện rời rạc tác động làm thay đổi trạng thái của các đối

tượng trong hệ thống theo từng điều kiện cụ thể trạng thái của hệ thống. Mạng Petri

được thiết lập dựa trên 3 thành phần chính: (1) Các điều kiện, (2) các sự kiện, và (3)

quan hệ luồng. Các điều kiện có thể là thoả mãn hoặc không thoả mãn. Các sự kiện là

có thể xảy ra hoặc không. Và quan hệ luồng mô tả điều kiện của hệ trước khi sự kiện

xảy ra. Các điều kiện đòi hỏi phải thoả mãn để một sự kiện xảy ra hoặc chuyển trạng

thái thực hiện thì được gọi là điều kiện trước (precondition). Các điều kiện mà được

thoả mãn khi một sự kiện nào đó xảy ra thì được gọi là điều kiện sau (postcondition).

2.3.2 Phƣơng pháp đặc tả bán hình thức (semi-formal method)

Các phương pháp bán hình thức là các kỹ thuật đặc tả, phát triển và kiểm định

các hệ thống phần mềm và phần cứng theo cấu trúc sử dụng các thành phần đồ hoạ và



31

được ứng dụng rộng rãi trong phân tích thiết kế phần mềm nói chung bao gồm cả các

hệ thống nhúng, thời gian thực như SDL, UML... Cách tiếp cận này giúp cho người

phát triển mô hình hoá hệ thống một cách trực quan dễ hiểu và các bộ phận tham gia

phát triển hệ thống có thể hiểu và đóng góp được nhằm xác định đúng hệ thống cần

xây dựng. Các phương pháp này được áp dụng tại tất cả các pha trong vòng đời phát

triển phần mềm.

a. Biểu đồ luồng dữ liệu (Data Flow Diagram)

Có nhiều cách mô tả thiết kế phần mềm, phụ thuộc vào thông tin gì được truyền

đạt. Một phương pháp được sử dụng là biểu đồ luồng dữ liệu. Biểu đồ luồng dữ liệu

chỉ ra mỗi tiến trình như là một khối (vòng). Những đường kẻ nối các khối chỉ ra các

thông tin được chuyển giữa các tiến trình. Theo cách thiết kế này trước hết chúng ta sẽ

phân tích các yêu cầu của hệ thống và xác định các mô-đun chức năng, rồi sau đó tiến

hành vẽ biểu đồ theo luồng dữ liệu của các mô-đun chức năng đã phân tích, nhằm mục

đích xác định được tác vụ theo các ràng buộc chặt chẽ mà hệ thống nhúng đòi hỏi.

Ví dụ hệ thống đồng hồ báo thức: có thể được chia làm 6 tác vụ như sau:

DisplayTask, TimebaseTask, ButtonTask, AlarmcontrolTask, AlarmtoneTask,

ErrorTask. Hình 2.8 thể hiện biểu đồ luồng dữ liệu giữa các tác vụ trong hệ thống đồng

hồ báo thức.

Hình 2.8 Biểu đồ luồng dữ liệu hệ thống đồng hồ báo thức

b. Biểu đồ trạng thái (Statechart Diagram)

Biểu đồ trạng thái thể hiện từng trạng thái có thể có trong hệ thống và những

đầu vào, ra gây ra thay đổi thành trạng thái khác. Như hình 2.9 thể hiện biểu đồ trạng

thái tổng quát, hệ thống chuyển từ trạng thái này sang trạng thái khác nhờ các trigger.

Trong một hệ thống phức tạp hơn, từng đầu vào gây ra những thay đổi trạng thái được

thể hiện và chỉ rõ từ trạng thái cũ ra trạng thái mới. Cách đặc tả này hữu dụng trong

các ứng dụng có các trạng thái và sự dịch chuyển của các trạng thái.



32

Hình 2.9. Biểu đồ trạng thái

c. Giả mã (Pseudo code)

Phương pháp tiếp theo là sử dụng giả mã để thiết kế phần mềm. Bước đầu tiên

là mô tả lôgic và mô tả chức năng mức cao. Danh sách liệt kê này mô tả bằng tiếng

anh chính xác những gì phần mềm sẽ làm. Bước tiếp theo là đi vào giả mã thực nhưng

giả mã vẫn còn được mô tả dưới dạng tiếng anh có cấu trúc, đoạn text thêm vào mô tả

những cờ gì, biến gì và những loại phần tử khác được xử lý để thực hiện những chức

năng mô tả. Điểm thuận lợi của phương pháp này là các mô tả chức năng có thể được

ghi ra và chi tiết được hoàn chỉnh trong quá trình thiết kế, cuối cùng được chuyển

thành giả mã.

Những mô tả chức năng và giả mã hữu dụng cho những hệ thống đơn giản được

viết bởi một lập trình viên. Nếu nhiều lập trình viên làm việc trên cùng một dự án và

đặc biệt là nếu nhiều bộ xử lý được sử dụng thì phải dùng một số phương tiện để mô tả

đầy đủ những thông tin được chuyển giữa các tiến trình hoặc các chức năng được thực

hiện bởi các lập trình viên. Thông tin về phân chia thời gian cho các chức năng thời

gian thực là rất quan trọng. Ví dụ, chức năng X phải được gọi trong Y mili giây của

chức năng Z hoặc là sẽ mất sự đồng bộ trong hoạt động. Trong một hệ thống phức tạp,

có nhiều mức tài liệu là rất hữu dụng. Những lược đồ khối tổng thể chỉ ra những dữ

liệu gì được truyền ra vào hệ thống, những lược đồ khác chỉ ra sự truyền thông giữa

các hệ thống nhỏ hoặc bảng mạch hoặc những chức năng chính của firmware và dùng

giả mã hoặc lược đồ trạng thái để mô tả từng chức năng hoạt động. Ví dụ ở hình 2.10

là mô tả một phần mềm về bộ chuyển đổi giao thức đơn giản. Hệ thống nhận dữ liệu từ

cổng tuần tự RS-232 từ một hệ thống chủ, thực hiện việc xử lý, lưu dữ liệu vào bộ đệm

và gửi nó cho một hệ thống thứ hai thông qua một giao tiếp khác. Giao thức

XON/XOFF được sử dụng để điều khiển luồng dữ liệu:



33

Hình 2.10 Đặc tả theo giả mã

Phần mềm xử lý xung quanh vòng lặp này. Hệ thống thực sự còn bao gồm một

số việc về kiểm tra lỗi và những công việc khác nhưng đã được loại bỏ để đơn giản

hoá mô tả. Việc sử dụng giả mã cũng có những hạn chế nhất định như khó mô tả được

hệ thống lớn phức tạp và mỗi lần thêm một chức năng mới cho ứng dụng thì cần phải

xác định lại mô tả giả mã, ví dụ cách truyền tham số cho một hàm, gán các thanh ghi

để tính toán một biểu thức…Mỗi lần chuyển sang một nền phần cứng mới thì cần thực

hiện lại xây dựng mã chương trình cho phù hợp với kiến trúc bộ xử lý mới.

d. Thiết kế sử dụng UML

UML đã trở thành một phương pháp luận thiết kế phần mềm nhúng quan trọng

trong những năm gần đây [10][19] (ngoài ra còn có UML-Realtime một phương pháp

thiết kế kết hợp giữa UML và ngôn ngữ hướng đối tượng thời gian thực ROOM do

công ty Object time đưa ra). Có hai cách thông dụng để sử dụng công cụ thiết kế đó là:

như một bản đặc tả thiết kế ứng dụng để hướng dẫn viết mã chương trình hoặc như là

một phương tiện để sinh mã trực tiếp. Việc sinh mã vẫn còn có những hạn chế và cần

nâng cao tính năng này do nhiều vấn đề riêng biệt đối với từng loại hệ thống không thể

thể hiện hết được. Phương pháp phân tích thiết kế và lập trình hướng đối tượng cũng là

sợi dây xuyên suốt trong quá trình thiết kế sử dụng UML.

Đối với UML có một đặc điểm thuận lợi là có thể xây dựng những trình biên

dịch mô hình cho các nền phần mềm khác nhau, như vậy là có thể sinh ra chương trình

chạy trên nhiều kiến trúc vi xử lý khác nhau tiết kiệm chi phí phát triển. Một nền phần

mềm đơn giản là tập các công nghệ xác định cấu trúc phần mềm như cấu trúc dữ liệu,

cách truy cập dữ liệu, các luồng và tác vụ, cấu trúc bộ vi xử lý và định vi chương trình.

Tất cả các chi tiết này được đưa vào trong bộ biên dịch mô hình để xác định vào một

nền phần cứng đích.



34

Hình 2.11 Qui trình phát triển blueprint

Về ứng dụng nhúng thời gian thực, UML tập trung vào hỗ trợ cho việc mô hình

hoá cơ chế hoạt động song song, hành vi, truyền thông của các tác vụ và cho phép diễn

tả được những đặc tính định lượng của hệ thống thời gian thực (như thời hạn, giai

đoạn, mức ưu tiên,…). Ngoài ra, OMG đã đưa ra thêm bản mô tả (profile) dành cho

các hệ thống thời gian thực là bản profile về lập lịch, hiệu năng, thời gian (Scheduling,

Performace và Time) được ký hiệu là UML-SPT [23].

Bản profile UML–SPT xác định một tập các khái niệm thích hợp cho mô hình

hoá hệ thống thời gian thực nhằm mục đích tích hợp những ký hiệu được sử dụng bởi

các kỹ thuật phân tích hệ thống thời gian thực hiện có vào trong UML. UML-SPT

được tổ chức thành hai phần chính: Thứ nhất là xác định tập các khái niệm chung làm

nền tảng cho định nghĩa các khái niệm phức tạp hơn đảm bảo mô hình hoá những đặc

tính thời gian thực. Thứ hai là dựa trên những khái niệm đã được định nghĩa trước để

phân tích những hành vi thời gian thực của ứng dụng dựa trên UML.

Phần đầu của SPT bao gồm ba gói con (hình 2.12):

Gói mô hình hoá tài nguyên chung (General Resource Modelling) xác định

những khái niệm chung về Resource và QualityOfService. Nó cũng giới thiệu

những mô hình nhân quả để làm sáng tỏ khía cạnh động của hệ thống.

Gói mô hình hoá thời gian (General Time Modelling) xác định thời gian và

những cơ chế liên quan đến thời gian như timer, clock …

Gói mô hình hoá tính song song (General Concurrency Modelling) xác định

những khái niệm cơ bản để đặc tả tính song song của ứng dụng.



35

Hình 2.12 Cấu trúc của SPT profile

Phần tiếp theo của SPT tập trung vào các kỹ thuật phân tích hành vi thời gian

thực của ứng dụng dựa trên UML. Trong phần này cung cấp các gói nhỏ hơn cho

những phân tích khác nhau như: gói phân tích khả năng lập lịch (Schedulability

Analysis) xác định những khuôn mẫu, nhãn, ràng buộc cho phân tích khả năng lập

lịch; tương tự như vậy gói phân tích hiệu năng (Performance Analysis) cũng cung cấp

những thứ đó để phân tích hiệu năng. Các gói này đều sử dụng những khái niệm đã

được xác định trong profile về resource, concurrency và time như đã đề cập ở trên.

Tóm lại, UML-SPT đưa ra tập những khuôn mẫu, nhãn và ràng buộc cho mô

hình hoá những ứng dụng thời gian thực ở mức cao, chi tiết. Bản profile này cũng hình

thành một khung tốt cho xác định lại những khái niệm riêng biệt để giải quyết vấn đề

thời gian thực.

2.4 Công cụ phát triển phần mềm nhúng

Người lập trình ứng dụng thường thực hiện công việc trên cùng một loại máy

tính mà ứng dụng chạy. Ví dụ, viết chương trình chạy trên Window thì thường thực

hiện công việc lập trình trên máy chạy Window. Việc sửa chữa, dịch, liên kết và gỡ lỗi

chương trình đều trên cùng một máy. Điều này thay đổi khi xây dựng hệ thống nhúng.

Thứ nhất, hầu hết hệ thống nhúng đều có những phần cứng chuyên biệt để gắn với các

bộ cảm ứng hoặc để điều khiển, và chỉ có cách duy nhất là thử phần mềm trên phần

cứng chuyên biệt đó. Thứ hai, các hệ thống nhúng thường sử dụng các bộ vi xử lý mà

chưa bao giờ được sử dụng trên máy trạm. Rõ ràng là chương trình không thể tự nhiên

dịch ra được các chỉ thị phù hợp với bộ vi xử lý lựa chọn cho hệ thống và chương trình

cũng không thể tự nhiên nhẩy vào trong bộ nhớ của hệ nhúng để thực hiện được. Phần

dưới đây sẽ đề cập đến những công cụ có thể thực hiện điều này.



36

Các máy chủ và đích

Trong thế giới nhúng, có nhiều lý do để thực hiện những công việc lập trình

ứng dụng trên một hệ thống khác với hệ thống mà chương trình chạy. Hệ thống phát

triển có thể không có bàn phím, màn hình, ổ đĩa và các thiết bị ngoại vi cần thiết cho

lập trình. Do đó, hầu hết công việc lập trình cho hệ thống nhúng được thực hiện trên

một máy tính (host) có cài đặt các công cụ lập trình. Chỉ sau khi chương trình được

viết, biên dịch và liên kết nó mới được chuyển tới máy đích.

Trình biên dịch chéo

Hầu hết hệ thống máy tính để bàn được dùng như là các host cùng với bộ biên

dịch, asssembler, bộ liên kết … để xây dựng chương trình chạy trên host. Những công

cụ này được gọi là những công cụ địa phương. Bộ biên dịch trên hệ thống Window NT

được dựa trên kiến trúc của Intel Pentium, chúng được sử dụng để xây dựng những

chương trình chạy trên nền tảng Intel Pentium. Bộ biên dịch này có thể hữu dụng khi

chúng ta dùng bộ vi xử lý Pentium để xây dựng hệ thống, nhưng nó hoàn toàn không

có ích lợi gì nếu như chúng ta sử dụng một bộ xử lý đích khác, ví dụ như: Motorola

68000, MIPS hay Zilog Z80. Những bộ xử lý mới hơn này không hiểu được các chỉ thị

nhị phân của Pentium. Nhưng trong trường hợp này thì các chỉ thị Pentium là cái mà

bộ biên dịch sinh ra. Vậy nên những gì chúng ta cần là một bộ biên dịch chạy trên hệ

thống host nhưng có thể sinh ra những chỉ thị nhị phân mà bộ xử lý đích trên hệ thống

nhúng có thể hiểu được. Những bộ biên dịch như vậy được gọi là bộ biên dịch chéo.

Về môi trường lý tưởng, nếu viết một chương trình bằng C hoặc C++, ta có thể

biên dịch trên bộ biên dịch địa phương và chạy trên host, thì cũng có thể dịch chương

trình thông qua bộ biên dịch chéo và có được chương trình chạy trên môi trường đích.

Thật không may, điều này không đúng như vậy thậm chí là trong lý thuyết. Trong lý

thuyết, một chương trình biên dịch không có lỗi với bộ biên dịch địa phương cũng biên

dịch không có lỗi trên bộ biên dịch chéo. Những qui tắc xây dựng chương trình đã

được xác định trong bộ biên dịch. Tuy nhiên, trong thực tế ta sẽ thấy rằng những cấu

trúc được chấp nhận ở một trình biên dịch này có thể sẽ không được chấp nhận ở trình

biên dịch khác. Chúng ta sẽ không gặp vấn đề với những câu lệnh như if, switch hay

vòng do loop; nhưng lỗi sẽ xảy ra nếu chúng ta sử dụng hàm mà không khai báo hoặc

sử dụng một kiểu khai báo cũ. Các nhà cung cấp bộ biên dịch vẫn đang làm việc để tối

thiểu hoá vấn đề này nhưng nó vẫn đang tồn tại.

Thực tế là nếu chương trình làm việc tốt trên host và được biên dịch thành công

với bộ biên dịch chéo nhưng cũng không có gì đảm bảo là nó sẽ hoạt động trên hệ

thống đích. Những vấn đề thường gặp phải khi chuyển một chương trình C từ nền này

sang nền khác như những biến được khai báo kiểu int có thể có 1 kích cỡ trên host

nhưng khi đưa sang máy đích lại có một kích cỡ khác.

Bởi vì những điều này nên chúng ta mong muốn có những cảnh báo từ bộ biên

dịch chéo. Ví dụ, nếu mã gán một con trỏ void cho một phần tử int, bộ biên dịch địa

phương có thể hiểu hai thực thể đó là cùng một kích thước và không đưa ra cảnh báo.



37

Ngược lại bộ biên dịch chéo có thể cảnh báo rằng int và con trỏ void không cùng kích

thước trên hệ thống đích.

Bộ Assembler chéo và chuỗi công cụ

Một công cụ khác chúng ta sẽ cần khi xây dựng chương trình với ngôn ngữ

Assembler là bộ Assember chéo. Tức là bộ Assembler chạy trên host nhưng sinh ra

các chỉ thị nhị phân thích hợp với máy đích tương tự như với bộ biên dịch chéo. Hình

2.13 dưới đây mô tả qui trình xây dựng phần mềm cho hệ thống nhúng. Chúng ta có

thể thấy những file đầu ra của công cụ này sẽ trở thành file đầu vào của công cụ tiếp

theo do đó các công cụ này phải tương thích với nhau và hình thành một chuỗi công cụ

(tool chain) cho phát triển ứng dụng.

Bộ liên kết/ bộ định vị (Linker/Locator) cho phần mềm nhúng

Công việc của bộ biên dịch chéo cũng giống như bộ biên dịch địa phương là

đọc một file mã nguồn và sinh ra một object file phù hợp cho bộ liên kết. Một bộ liên

kết cho hệ nhúng sẽ làm những công việc khác với bộ liên kết địa phương do bản chất

hai chương trình khác nhau. Bộ liên kết cho hệ thống nhúng thường gọi đến bộ định vị

hoặc bộ liên kết định vị. Điểm khác nhau cơ bản giữa một bộ liên kết địa phương và

bộ định vị là ở chính các file mà chúng tạo ra. Bộ liên kết địa phương tạo ra một file

trên ổ đĩa của hệ thống Host và nó được đọc bởi bộ loader của hệ điều hành khi người

sử dụng yêu cầu chạy chương trình. Loader sẽ tìm tới đoạn bộ nhớ để nạp chương

trình và copy chương trình từ đĩa vào trong bộ nhớ trong và thực hiện một số xử lý

khác trước khi chạy chương trình. Locator thì ngược lại, tạo ra một file và file đầu ra

này sẽ được copy vào hệ thống đích. Sau đó nó sẽ phải tự thực thi. (Chú ý rằng trong

hệ thống nhúng sẽ không có hệ điều hành tách biệt; locator sẽ gắn mã chương trình của

chúng ta với RTOS và sự kết hợp này được copy tới hệ thống đích chỉ trong một lần).

Trong hầu hết các hệ thống nhúng đều không có loader. Khi locator thực hiện

xong file đầu ra của nó sẽ được copy vào hệ thống đích. Do đó, locator phải biết được

vị trí chương trình nằm trong bộ nhớ và sắp đặt địa chỉ. Và một vấn đề khác mà locator

cũng cần giải quyết đó là trong môi trường nhúng thì một số phần của chương trình

được kết thúc trong ROM và một số phần trong RAM.

Đưa phần mềm nhúng vào trong hệ thống đích

Locator sẽ xây dựng một file mô tả ảnh của phần mềm đích và sau đó đưa file

đó lên hệ thống đích. Có nhiều cách để thực hiện điều này:

Bộ lập trình PROM

Cách cổ điển là dùng file đó để tạo ra một ROM hoặc PROM do việc tạo ROM

chỉ thích hợp khi đã hoàn thành xây dựng phần mềm do chi phí cho công cụ xây dựng

ROM khá cao. Để đưa chương trình vào PROM đòi hỏi một thiết bị được gọi là bộ lập

trình PROM. Cái này phù hợp với có những thay đổi trong phần mềm hoặc trong khi

đang gỡ lỗi.



38

Hình 2.13 Quá trình phát triển và biên dịch phần mềm nhúng

Việc đặt PROM vào một socket trên hệ thống đích thay vì hàn chặt nó vào mạch sẽ

tiện lợi hơn cho quá trình gỡ lỗi và thay đổi chương trình nếu như chúng ta tìm thấy lỗi

và cần xoá nội dung trong PROM. Khi định sử dụng một bộ lập trình PROM thì cần

xem xét kỹ rằng bộ đó có thể hiểu được file đầu ra mà locator tạo ra.

ROM Emulator

Một cách phổ biến khác cho việc đưa phần mềm vào hệ thống máy đích để gỡ

lỗi đó là sử dụng một thiết bị ROM emulator, một thiết bị dùng để thay thế ROM ở hệ

thống đích. Emulator này sẽ có chức năng giống như ROM trên máy đích. Tuy nhiên

ROM Emulator bao gồm một hộp điện tử lớn và một cổng tuần tự hoặc một kết nối

mạng để kết nối với host. Phần mềm chạy trên host có thể gửi file được tạo ra bởi

locator cho ROM Emulator và thiết bị này hoạt động giống như ROM trên máy đích.

2.5 Case study về thiết kế phần mềm nhúng

Đây là một ví dụ về phân tích và thiết kế hệ thống nhúng hướng đối tượng sử

dụng UML. Hệ thống được đưa ra phân tích ở đây là máy ghi âm số (Digital Sound

Recorder) [14]. Thiết kế sử dụng một bộ vi xử lý nhúng trong thiết bị và ngôn ngữ lập

trình C++.

2.5.1 Phân tích yêu cầu

Máy ghi âm số là một thiết bị điện tử được thiết kế để ghi âm và nghe lại những

đoạn ghi âm trong máy. Thông điệp được ghi âm bằng cách sử dụng một micro gắn

sẵn trong thiết bị và sau đó được lưu trữ trong bộ nhớ. Người dùng có thể nghe lại

những thông điệp được ghi một cách dễ dàng tại bất cứ lúc nào thông qua một loa đặt

ở trước thiết bị. Máy ghi âm số phải nhỏ, gọn, đẹp, dễ sử dụng, chạy tiết kiệm pin (pin

sạc).



39

Hình 2.14 thể hiện giao diện của thiết bị. Đó là một thiết bị cầm tay, màn hình phẳng

với các nút bấm ở bề mặt.

Hình 2.14 Hình dáng của thiết bị

Những đặc điểm chính của thiết bị:

Khả năng lưu giữ 20 thông điệp khác nhau. Độ dài của mỗi thông điệp bị giới

hạn bởi bộ nhớ thiết bị.

Menu trên thiết bị được thiết kế thuận tiện dễ sử dụng.

Truy cập trực tiếp tới bất kỳ thông điệp nào.

Có đồng hồ báo thức. Người dùng có thể đặt báo thức hàng ngày. Chuông báo

thức tắt khi người dùng bấm một phím bất kỳ hoặc tự tắt sau 60 giây.

Màn hình LCD đầy đủ chức năng. Ngày giờ hiện tại luôn hiện trên màn hình và

trên màn hình cũng có những chỉ dẫn rõ ràng về cách sử dụng và đang thực hiện

công việc gì.

Một bộ chỉ thị mức pin. Hệ thống sẽ phát ra những tiếng beep đặc trưng khi gần

hết pin.

Có chế độ chờ để tiết kiệm điện. Hệ thống sẽ tắt những thiết bị ngoại vi khi

chúng không sử dụng và sẽ hoạt động bình thường trở lại khi người dùng bấm

một phím.

Chất lượng âm thanh tốt. Âm thanh được xử lý ở 6 Khz, 8 bit trên mẫu.

a. Những sự kiện bên ngoài

Một hệ thống nhúng luôn phải tương tác với môi trường của nó. Trong giai

đoạn đầu tiên của quá trình phân tích, chúng ta có thể coi hệ thống như là một hộp đen

phản ứng lại với các yêu cầu và thông điệp từ môi trường. Môi trường bao gồm các tác

nhân. Mỗi tác nhân tương tác với hệ thống có mục đích khác nhau và trao đổi một tập

thông điệp khác nhau.



40

Biểu đồ ngữ cảnh của hệ thống

Hình 2.15 thể hiện các tác nhân tương tác với hệ thống. Có 3 tác nhân đó là:

người dùng, pin và thời gian. Nó cũng chỉ ra các giao tiếp, các thiết bị mà cho phép hệ

thống và tác nhân trao đổi với nhau.

Hình 2.15 Biểu đồ ngữ cảnh của hệ thống

Các sự kiện

Một sự kiện là một thông điệp quan trọng từ môi trường. Một hệ thống thời

gian thực phải đáp ứng lại những sự kiện trong một khoảng thời gian nhất định. Bảng

dưới đây thể hiện các sự kiện bên ngoài có thể xảy ra trong hệ thống này. Hướng của

sự kiện có thể là “In” (từ môi trường vào hệ thống), là “Out” (từ hệ thống ra môi

trương). Sự kiện xảy ra có thể theo chu kỳ (periodic) hoặc không theo chu kỳ

(episodic). Thời gian đáp ứng đặt ở cận trên. Hệ thống có thể hoạt động không chính

xác nếu không đáp ứng được thời gian đặt ra cho các sự kiện.



41

Bảng 2.1 Bảng các sự kiện tác động lên hệ thống

b. Các Use case

Trong hệ thống này có 6 ca sử dụng khác nhau được thể hiện trong hình 2.16:

Hình 2.16 Biểu đồ Use Case

Record a message

Người dùng chọn một mục ghi thông điệp từ thư mục thông điệp lưu trữ và nhấn nút

“record”. Nếu mục ghi thông điệp đã lưu trữ thông tin thì nó sẽ được xoá đi. Hệ thống

bắt đầu ghi âm từ một micro cho đến khi nhấn nút “stop” hoặc là hết bộ nhớ.



42

Playback a message

Người dùng chọn một mục ghi và bấm nút “play”. Nếu mục ghi đó chứa thông điệp đã

được ghi, thì thiết bị sẽ phát âm thanh ra loa cho đến khi kết thúc hoặc người dùng

bấm nút “stop”.

Delete a message

Nếu người dùng chọn một mục ghi đã sử dụng và sau đó bấm nút “delete” thì bản ghi

đó sẽ xoá khỏi bộ nhớ và bộ nhớ được giải phóng.

Set the alarm time

Người dùng có thể tắt hoặc bật chế độ hẹn giờ bằng cách thiết lập lựa chọn.

Set the clock time

Người dùng có thể đặt thời gian đồng hồ và điều chỉnh nó theo múi giờ từng vùng.

Watch the time

Hệ thống thường hiển thị thời gian hiện tại và ngày trên màn hình, người dùng có thể

xem ngày giờ trên đó.

c. Biểu đồ tuần tự của Use case chính

Hình 2.17 Biểu đồ tuần tự cho ca sử dụng Playback a message

Hình 2.18 dưới đây thể hiện ngữ cảnh khi người dùng đang nghe một đoạn ghi âm thì

nhạc hẹn giờ xuất hiện.



43

Hình 2.18 Alarm while playback a message

Hệ thống có thể tắt hoặc bật màn hình, micro và loa trong những tình huống cần thiết.

Những phần tử này sử dụng một lượng pin đáng kể. Bằng cách tắt chúng hệ thống có

thể tiết kiệm được năng lượng và kéo dài thời gian của Pin.

Đối tượng Pin cũng đưa ra những cảnh báo cho hệ thống khi nó gần hết năng lượng.

Sau đó hệ thống sẽ tắt tất cả các thiết bị ngoại vi và chuyển sang chế độ stand-by. Khi

người dùng nạp Pin, hệ thống sẽ chuyển khỏi chế độ stand-by. Hệ thống ở chế độ

stand-by thì các thông điệp vẫn còn được giữ trong bộ nhớ.

Hình 2.19 đưa ra ngữ cảnh hệ thống chuyển sang chế độ stand-by và sau đó được đánh

thức bởi đồng hồ báo thức và khi gặp một cảnh báo về mức Pin, nó lại chuyển sang

chế độ stand-by.



44

Hình 2.19 Ngữ cảnh vào và ra khỏi chế độ stand-by

2.5.2 Thiết kế

Sau khi phân tích yêu cầu, ở bước này chúng ta sẽ phân tích để đưa ra các mức

thiết kế logic và chi tiết cho bài toán.

Bước đầu tiên trong xây dựng biểu đồ lớp là xác định các đối tượng:



45

Bảng 2.2 Các đối tượng của hệ thống

Người dùng tương tác với hệ thống thông qua bàn phím và màn hình. Đây là

những đối tượng bị động, do vậy chúng ta quyết định thêm một đối tượng giao tiếp

người dùng (User Interface) để quản lý việc tương tác với người dùng. Lớp User

Interface dựa vào lớp Audio Controller để thực hiện công việc. Lớp User Interface là

trọng tâm của hệ thống và sử dụng những lớp Audio Input và Audio Output để sản

sinh ra âm thanh. Thể hiện trong hình 2.20.



46

Hình 2.20 Biểu đồ lớp của hệ thống

Hệ thống được chia ra thành 5 hệ thống con: Alarm Clock, Battery, User Interface,

Memory và Audio như hình vẽ 2.21.

Hình 2.21 Các hệ thống con trong Digital Sound Recorder

Chúng ta sẽ đi sâu vào xem xét hệ thống thực hiện công việc chính đó là Audio. Mỗi

thông điệp được kết hợp bởi vài khối audio và mỗi khối audio lại được kết hợp từ

nhiều mẫu âm thanh. Những lớp Audio Input và Audio Output đòi hỏi các yêu cầu thời

gian thực chặt chẽ. Lớp Timer cung cấp thời gian chính xác cho lớp Audio Input và

Audio Output. Lớp timer là trừu tượng hoá từ thiết bị phần cứng Timer. Lớp

Microphone là trừu tượng hóa từ micro vật lý. Lớp Microphone có thể ghi lại những

mẫu âm thanh. Lớp Speaker có thể nghe lại những thông điệp được ghi.



47

Hình 2.22 Biểu đồ lớp hệ thống Audio

Hình 2.23 Biểu đồ tuần tự nghe một thông điệp



48

Những biểu đồ lớp mô tả khung nhìn tĩnh của hệ thống. Để hiểu rõ hơn nữa hành vi

của hệ thống, ta có thể tạo thêm những biểu đồ mới thể hiện khía cạnh động trong thiết

kế như biểu đồ trạng thái, biểu đồ cộng tác.

2.5.3 Phân chia tác vụ

Hệ thống có thể được phân chia ra làm các tác vụ chính như sau:

Display task: Làm nhiệm vụ hiện thị những thông báo, chỉ dẫn, thời gian lên

màn hình, và được xử lý riêng bởi một tác vụ.

Button task: Làm nhiệm vụ xử lý các ngắt do người dùng bấm một nút sinh ra.

Audio controller task: Thực hiện việc điều khiển ghi và nghe âm thanh

Timer task: Thực hiện các công việc liên quan đến thời gian như: hẹn giờ, đặt

giờ…

Battery task: Thực hiện các công việc liên quan đến xử lý năng lượng Pin.

Và sử dụng hệ điều hành thời gian thực để lập lịch phân chia hoạt động, mức độ ưu

tiên giữa các tác vụ, quản lý tài nguyên trong quá trình thực hiện.

2.5.4 Kiến trúc phần cứng của hệ thống

Thể hiện các thành phần cứng trong hệ thống và kết nối giữa chúng một cách

trừu tượng. Để có thể mô phỏng sự hoạt động và các kết nối thật sự của các thành phần

phần cứng nguời ta có thể sử dụng những ngôn ngữ đặc tả phần cứng như VHDL hoặc

Verilog để mô tả (phần này nằm ngoài phạm vi của luận văn).

Hình 2.24 Thiết kế phần cứng của hệ thống



49

CHƢƠNG 3: HỆ ĐIỀU HÀNH THỜI GIAN THỰC

Hệ điều hành thời gian thực là hệ điều hành hỗ trợ khả năng xây dựng các hệ

thống thời gian thực. Những ứng dụng này bao gồm các hệ thống thiết bị điện tử, các

robot công nghiệp, các hệ thống cảnh báo… Một RTOS cho phép tạo một hệ thống

thời gian thực nhưng không đảm bảo hoàn toàn rằng ứng dụng cuối cùng sẽ là ứng

dụng thời gian thực; điều này còn đòi hỏi tính đúng đắn của quá trình phát triển phần

mềm (như qui trình áp dụng, kinh nghiệm người xây dựng, …). Một đặc điểm rất quan

trọng của RTOS là cung cấp những công cụ cần thiết để xây dựng nên những tác vụ có

khả năng xác định được thời gian thực thi của chúng trong hệ thống hoàn chỉnh. Một

RTOS thường đi vào hai phần cơ bản là: phần nhân và phần chức năng của hệ điều

hành. Phần nhân thường thực hiện những chức năng lập lịch tác vụ, quản lý bộ nhớ.

Phần hệ điều hành có thể có những driver cho ổ đĩa, các cổng tuần tự và các tài nguyên

chung khác. Một đặc điểm chung của RTOS là hệ thống sẽ sinh ra một loại ngắt thông

dụng (được gọi là 1 tích tắc của bộ định thời), thường ở mức 20 Hz (50ms). Điều này

được sử dụng để tính thời gian, lập lịch công việc, và những hàm chức năng khác.

Không phải tất cả các RTOS đều yêu cầu có ngắt bộ định thời hệ thống. Các hệ điều

hành thời gian thực thường hỗ trợ những chức năng sau đây:

Đa nhiệm, bao gồm: kích hoạt và bỏ kích hoạt các tác vụ, thiết lập mức ưu tiên

cho tác vụ, lập lịch tác vụ.

Truyền thông giữa các tác vụ

Quản lý bộ nhớ

Hình 3.1 Cấu trúc hệ điều hành thời gian thực

3.1 Tính đa nhiệm

Đa nhiệm là việc lập lịch quá trình xử lý và luân chuyển CPU giữa các tác vụ.

Đa nhiệm tối ưu hoá hiệu suất của CPU và cung cấp cho các ứng dụng khả năng mô-

đun hoá. Một trong những khía cạnh quan trọng nhất của tính đa nhiệm là cho phép



50

người lập trình ứng dụng quản lý những yếu tố cố hữu phức tạp của ứng dụng thời

gian thực. Tất cả các chức năng kích hoạt và bỏ kích hoạt tác vụ, lập lịch, và sắp xếp

mức ưu tiên đều là phần chức năng đa nhiệm. Đa nhiệm có thể thực hiện bằng cách

chia nhỏ thời gian thành các lát (time slicing). Theo phương pháp này, các tác vụ được

chuyển lần lượt để được sự phục vụ của bộ xử lý. Mỗi lần ngắt xuất hiện thì một tác vụ

khác sẽ được thực hiện và mỗi tác vụ được thực hiện trong khoảng thời gian một tích

tắc (50 ms đối với tích tắc 20 Hz ). Toàn bộ thời gian thực hiện cho một tác vụ tương

ứng phụ thuộc vào tổng số tác vụ. Những tác vụ có mức ưu tiên cao hơn có thể được

thực hiện nhiều hơn một tích tắc. Một tác vụ mà cần ít hơn một tích tắc có thể được

ngắt sớm hơn để dành thời gian còn lại cho tác vụ tiếp theo.

Lập lịch tuần tự và chia nhỏ thời gian về cơ bản là giống nhau, ngoại trừ việc

những tác vụ được lập lịch tuần tự sẽ thực thi cho đến khi kết thúc còn những tác vụ

được chia nhỏ thời gian thì thực hiện cho đến khi hết thời gian. Những tác vụ hoạt

động theo cơ chế lập lịch có thể từ bỏ điều khiển trước khi kết thúc. Trong trường hợp

đó chúng có thể được thực hiện lại từ công việc bỏ dở giữa chừng thay vì thực hiện lại

từ đầu.

Hầu hết các RTOS đều hỗ trợ cách thức chia nhỏ thời gian hoặc lập lịch tuần tự.

Lập lịch tuần tự cũng có thể kiểm tra và dừng những tác vụ chiếm dụng CPU. Trong

bất kỳ hệ thống lập lịch nào thì tại một thời điểm chỉ có một tác vụ có quyền kiểm soát

CPU. Hình 3.2 minh hoạ sự khác nhau giữa hoạt động chia nhỏ thời gian và hoạt động

tuần tự.

Hình 3.2 Hoạt động chia nhỏ thời gian và tuần tự



51

3.1.1 Lập lịch ƣu tiên (Preemptive Scheduling)

Lập lịch ưu tiên là phương pháp phổ biến nhất của lập lịch tác vụ khi sử dụng

một RTOS và là một trong những ưu điểm chính của việc sử dụng RTOS. Dưới cơ chế

lập lịch ưu tiên, một tác vụ được thực hiện cho đến khi nào kết thúc hoặc cho đến khi

nào có một tác vụ có mức ưu tiên cao hơn chiếm dụng. Nó được sử dụng khi việc đáp

ứng hệ thống là quan trọng và hầu hết các nhân thời gian thực thương mại đều theo

kiểu lập lịch này. Tác vụ có độ ưu tiên cao nhất luôn nhận được ngay quyền điều khiển

CPU.

3.1.2 Kích hoạt và bỏ kích hoạt tác vụ (Activation and Deactivation of

Tasks)

Những tác vụ dưới RTOS có thể ở trạng thái sẵn sàng hoặc không sẵn sàng.

RTOS nắm giữ một danh sách các tác vụ ở trạng thái sẵn sàng và quyền ưu tiên thực

hiện của chúng. Một tác vụ sẵn sàng sẽ được thêm vào danh sách tác vụ và thực hiện

chúng theo thứ tự. Khi một tác vụ ở trạng thái không sẵn sàng, nó sẽ được xoá khỏi

danh sách. Một tác vụ sẵn sàng có thể bị ngăn chặn hoạt động bởi vì nó bị khoá hoạt

động do một nguyên nhân nào đó. Một tác vụ khi được gán quyền điều khiển nó có thể

thực hiện đến khi hoàn thành hoặc đến khi không thể thực hiện tiếp được nữa.

3.1.3 Lập lịch hƣớng sự kiện (Event-Driven Scheduling)

Vấn đề thêm và loại bỏ tác vụ từ danh sách tác vụ được dựa trên việc thay đổi

các tình huống gọi là lập lịch hướng sự kiện. Trong hệ thống hướng sự kiện, ưu tiên,

một sự kiện được xem như là một ngắt hoặc một tác vụ có thể xác định những tác vụ

khác cần được kích hoạt. Ví dụ nó có thể thực hiện điều này bằng cách thiết lập một

semaphore hoặc đặt dữ liệu vào trong một mailbox. Tác vụ mà được thiết lập kích hoạt

từ trước bởi RTOS khi sự kiện này xảy ra, sẽ được kích hoạt nếu nó có mức ưu tiên

cao hơn tác vụ hiện thời. RTOS có thể kích hoạt một tác vụ khi một semaphore được

đặt hay một thông điệp được chuyển đến, chỉ khi nó được thiết lập từ trước. Trong một

hệ thống dựa trên RTOS, những hàm dịch vụ ngắt (ISR) thường nhận điều khiển thông

qua RTOS do đó một hàm dịch vụ ngắt có thể không cần đặt semaphore để bắt đầu

một tác vụ. Thay vào đó, RTOS có thể lập lịch tác vụ dựa trên sự kích hoạt của ngay

bản thân ISR.

Một lưu ý cuối cùng về lập lịch: Cả hai hệ thống lập lịch tuần tự và lập lịch ưu

tiên đều cho phép một tác vụ thực thi cho đến khi kết thúc. Điểm khác biệt là trong hệ

thống ưu tiên, một tác vụ thực hiện cho đến khi kết thúc hoặc bị chiếm quyền ưu tiên.

Giữa hai tác vụ sẵn sàng có mức ưu tiên khác nhau, tác vụ có mức ưu tiên cao hơn

luôn được ưu tiên so với tác vụ có mức ưu tiên thấp hơn và kết thúc trước. Nếu hai tác

vụ có cùng mức ưu tiên và đều sẵn sàng tại một thời điểm thì một RTOS phức tạp

thường kích hoạt tác vụ có thời gian thực hiện lâu hơn. RTOS chỉ biết được những tác

vụ đã được tạo. Mã cho những tác vụ khác có thể nằm trong bộ nhớ nhưng RTOS

không thấy chúng cho đến khi chúng được tạo.



52

3.2 Theo dõi các tác vụ

RTOS theo dõi dấu vết của các tác vụ bằng khối điều khiển tác vụ (TCB). Đây

là nơi RTOS lưu các thông tin về tác vụ. Một mục TCB được tạo ra cho tất cả các tác

vụ được quản lý bởi RTOS. TBC lưu trữ những thông tin như sau: số hiệu tác vụ (task

ID), trạng thái của tác vụ (task state), mức ưu tiên (task priority), địa chỉ tác vụ (task

address), con trỏ ngăn xếp tác vụ (task stack pointer).

Ngăn xếp tác vụ là ngăn xếp bộ vi xử lý. Khi một tác vụ có quyền điều khiển,

con trỏ ngăn xếp bộ vi xử lý sẽ được sửa đổi để trỏ tới ngăn xếp cho tác vụ đó. Từng

tác vụ phải được gán đủ bộ nhớ để lưu ngữ cảnh bộ xử lý, các biến và thông tin cần

thiết. Khi một tác vụ dừng thực hiện vì một lý do nào đó, RTOS sẽ lưu con trỏ ngăn

xếp tác vụ vào trong TCB. Và khi tác vụ đó sẵn sàng chạy lại, RTOS sẽ phải lấy con

trỏ ngăn xếp đó ra từ TCB, bỏ những giá trị đó vào con trỏ ngăn xếp bộ xử lý và trả

quyền điều khiển cho tác vụ.

Tuỳ thuộc vào từng RTOS, TCB có thể chứa thêm những thông tin như về môi

trường cho tác vụ …Ngoài ngăn xếp cho tác vụ, RTOS cũng có những ngăn xếp cho

chính bản thân RTOS sử dụng.

3.3 Truyền thông giữa các tác vụ

Trong hệ thống có sử dụng RTOS, dữ liệu thường được chuyển qua RTOS. Nó

có thể hỗ trợ những dịch vụ semaphore, bộ đệm, hàng đợi và mailbox để truyền thông

giữa các tác vụ.

Semaphore cung cấp cơ cấu chia sẻ dữ liệu được sử dụng trong hầu hết các

nhân của hệ điều hành đa nhiệm. Những tác dụng của semaphore là: điều khiển việc

truy cập tới tài nguyên chia sẻ, phát tín hiệu khi sự kiện xuất hiện và cho phép hai tác

vụ đồng bộ hoạt động. Một semaphore đơn giản là một giá trị không âm. Khi một tác

vụ sử dụng tài nguyên, nó cần semaphore như khoá để truy cập tài nguyên. Khi sử

dụng tài nguyên, tác vụ đó làm cho giá trị của semaphore giảm đi 1. Khi không sử

dụng nữa, semaphore lại được tăng lên 1. Các tác vụ khác nếu cố tình muốn giảm

semaphore xuống giá trị nhỏ hơn 0 thì sẽ bị khoá lại và đặt vào hàng đợi semaphore.

Semaphore được cài đặt ba toán tử trong hệ điều hành là: INITIALIZE, WAIT, và

SIGNAL. Sự khác biệt trong hệ thống RTOS là tất cả truy cập tới semaphore đều được

truyền thông qua RTOS.

Hình 3.3 Một ví dụ về semaphore



53

Một bộ đệm RTOS giống như bộ đệm FIFO nhưng do RTOS quản lý. Khi một

tác vụ A cần chuyển dữ liệu nó sẽ yêu cầu một bộ đệm từ RTOS, bỏ dữ liệu vào trong

đó và thông báo với RTOS chuyển đến tác vụ B. Tác vụ B nhận được con trỏ trỏ tới bộ

đệm, con trỏ này xác định vị trí bộ đệm trong bộ nhớ và dung lượng dữ liệu của nó.

Một hàng đợi là một chuỗi các bộ đệm. tác vụ A có thể đặt một thông điệp vào

bộ đệm và chuyển bộ đệm đó cho tác vụ B. Tác vụ B có thể bận khi thông điệp gửi đi

kế tiếp đã sẵn sàng, lúc đó tác vụ A sẽ đề nghị RTOS đặt thông điệp kế tiếp này vào

hàng đợi, nơi mà tác vụ B sẽ xử lý lần lượt theo thứ tự.

Trong cấu trúc mailbox, thông thường một tác vụ nhận thông điệp từ vài tác vụ

khác. RTOS quản lý mailbox, lưu giữ thông điệp cho một tác vụ cho đến khi tác vụ đó

sẵn sàng đọc thông điệp. Giống như mailbox ngoài thực tế, khi một tác vụ đã gửi

thông điệp thì nó không thể lấy lại được. Tuỳ thuộc vào RTOS, một tác vụ có thể kiểm

tra mailbox và đợi mail khi không có. Hình 3.4 tóm tắt cơ chế truyền thông trong

RTOS. Ở ví dụ đầu tiên (bộ đệm RTOS), Tiến trình A chuyển dữ liệu cho tiến trình B

thông qua một bộ đệm. Ở ví dụ thứ 2 (hàng đợi RTOS), Tiến trình A đổ đầy dữ liệu

vào các bộ đệm (hàng đợi) 1, 2 và đang đổ dữ liệu vào bộ đệm 3. Tiến trình B đang lấy

dữ liệu từ bộ đệm 1. Ở ví dụ thứ 3 trong hình 3.4 là một RTOS mailbox. Các tiến trình

A, B và C đang đưa dữ liệu vào một mailbox chung cho tiến trình D. Từng thông điệp

của mỗi tiến trình sẽ được lưu một cách riêng biệt. RTOS thông thường cho phép tiến

trình gửi gán các mức ưu tiên cho thông điệp gửi đi.

Hình 3.4 Truyền thông của RTOS



54

Một tác vụ có thể sẵn sàng thực thi sau khi có một sự kiện xảy ra hoặc có thể

được lập lịch bắt đầu thực thi muộn hơn. Nó cũng có thể được lập lịch thực thi khi một

semaphore được đặt, một khoảng thời gian nhất định đã trôi qua hoặc thực thi tác vụ

vào một thời điểm xác định trong ngày.

3.4 Quản lý bộ nhớ

RTOS thường cấp phát bộ nhớ dưới dạng các khối, vùng nhớ liên tục có kích

thước nhỏ nhất. Ví dụ nếu kích thước của khối là 1K, một tác vụ cần một bộ đệm 14

byte cũng phải yêu cầu một khối và nhận được khối 1K bộ nhớ gán cho nó. Việc xác

định kích thước khối nhớ cũng rất quan trọng trong thiết kế hệ thống. Một tác vụ cần

nhiều khối nhớ thường cần bộ nhớ liên tục, do đó RTOS có nhiệm vụ đi tìm những

khối nhớ liên tục đủ dung lượng yêu cầu. Nếu khối nhớ quá nhỏ bộ nhớ có thể bị phân

mảnh do khi giải phóng khối nhớ không thực hiện theo thứ tự liên tục, ngược lại nếu

khối nhớ quá lớn sẽ gây ra lãng phí không cần thiết vì có ít khối nhớ đạt yêu cầu bộ

nhớ của tất cả các tác vụ. Hình 3.5 sẽ minh hoạ cả hai vấn đề này. Trong nửa bên trái

của hình, khi các khối bộ nhớ quá nhỏ, bộ nhớ sẽ bị phân mảnh. Tác vụ 1 được gán ba

khối nhớ sau đó giải phóng hai khối, tác vụ 2 cũng như vậy, tác vụ 3 được gán bốn

khối nhớ, tác vụ 4 có hai khối. Bây giờ nếu tác vụ thứ 5 cần 3 khối liên tiếp thì sẽ gặp

vấn đề. Các khối 1,2,5,7,8,13 và 16 đều chưa cấp phát nhưng không thể tìm được ba

khối nhớ trống liên tiếp. Nên tác vụ 5 không có đủ bộ nhớ để thực hiện. Phần còn lại

của hình 3.5 thể hiện vấn đề ngược lại khi các khối nhớ quá lớn. Các tác vụ từ 1 tới 4

đều được gán một khối nhớ mặc dù những tác vụ này chỉ cần rất ít bộ nhớ trong phần

được cấp phát và tác vụ 5 cũng không còn bộ nhớ để thực thi.

3.5 Quản lý tài nguyên

Tài nguyên là bất kỳ thực thể nào được sử dụng bởi các tác vụ. Tài nguyên có

thể là thiết bị I/O như máy in, bàn phím, bộ nhớ,…Bộ định thời cũng là một loại tài

nguyên, RTOS có thể cung cấp các bộ định thời hệ thống được thực hiện trong phần

mềm và đếm tích tắc thời gian. Tài nguyên chia sẻ có thể được sử dụng bởi nhiều tác

vụ, điều này đòi hỏi phải có kế hoạch chia sẻ tài nguyên sao cho đảm bảo vấn đề đồng

bộ hoá dữ liệu giữa các tác vụ. RTOS có trách nhiệm quản lý các tài nguyên hiệu quả

và tránh xung đột giữa các tác vụ khi sử dụng tài nguyên ví dụ như dùng semaphore,

gán quyền thực hiện.



55

Hình 3.5 Các khối bộ nhớ được gán trong RTOS

3.6 RTOS và ngắt

Ngắt bắt đầu với các tín hiệu từ phần cứng, hầu hết các chip vào ra điều khiển

cổng tuần tự hoặc giao tiếp mạng cần sự chú ý của CPU lúc có một sự kiện xảy ra. Khi

một ngắt xuất hiện, bộ xử lý sẽ xử lý ngắt đó, lưu lại địa chỉ trả về và điều khiển hàm

dịch vụ ngắt. Giả sử khi một tác vụ đang thực thi thì ngắt xuất hiện, địa chỉ trả về được

lưu vào ngăn xếp của tác vụ. Một RTOS thường có những dịch vụ nhân đặc biệt cho

ngắt. Khi hàm dịch vụ ngắt có quyền điều khiển nó có thể thực hiện những dịch vụ đặc

biệt này. RTOS thường cung cấp ít nhất ba loại dịch vụ cho ISR. Dịch vụ đầu tiên,

mục vào của ngắt cho phép hàm dịch vụ ngắt thông báo cho RTOS biết là ngắt đã xảy

ra. Hàm mục vào ngắt có thể lưu lại ngữ cảnh của bộ xử lý hoặc những thông tin khác

được cung cấp bởi các nhà sản xuất RTOS. Dịch vụ ISR thứ hai là để yêu cầu đặt một

semaphore. Dịch vụ thứ ba là một lời gọi thoát khỏi dịch vụ, nó sẽ thông báo cho

RTOS biết khi thủ tục ngắt hoàn thành nhiệm vụ.

Các dịch vụ RTOS đặc biệt được cung cấp cho các ISR bởi vì các ISR không

dùng được các dịch vụ thông thường của RTOS. Các dịch vụ thông thường không cho



56

phép sự trở lại. Ví dụ nếu một ngắt xảy ra trong khi RTOS đang thực hiện và ISR cố

gắng sử dụng chức năng RTOS đang thực hiện thì sẽ sinh ra lỗi.

Khi ISR thoát (thông qua RTOS), RTOS có thể thực hiện việc chuyển tác vụ,

dành quyền điều khiển cho tác vụ khác có mức ưu tiên cao hơn tác vụ mà đã bị ngắt.

3.7 Liên lạc trong RTOS thông dụng

Các RTOS thì khác nhau, nhưng trong phần này sẽ liệt kê danh sách các dịch vụ

RTOS thông dụng cần thiết cho việc giao tiếp (với tên mang tính đặc tả):

Define_Task: Xác định một tác vụ được thực hiện. Những tham số thông

thường được truyền cho RTOS có thể bao gồm số hiệu tác vụ, mức ưu tiên và

địa chỉ mục vào của tác vụ

Activate_Task: Yêu cầu kích hoạt một tác vụ. Những tham số được truyền cho

RTOS bao gồm cả số hiệu tác vụ.

Deactivate_Task: Bỏ kích hoạt tác vụ. Tham số bao gồm số hiệu tác vụ.

Yield: Thông báo cho RTOS biết tác vụ đã thực hiện xong và tác vụ khác trong

danh sách có thể được thực thi.

Define_Timeslice: Xác định khoảng thời gian giữa các time-slice mà tác vụ

được phép thực thi.

Allocate_Memory: Yêu cầu một một lượng khối nhớ xác định.

Mailbox_In: Nhận được một thông điệp vào mailbox. Tham số bao gồm số hiệu

tác vụ và số hiệu mailbox.

Send_Mail: Gửi mail tới một mailbox. Tham số có thể bao gồm số hiệu

mailbox, số hiệu tác vụ đích và mức ưu tiên của thông điệp.

Wait_On: Đợi cho đến khi hàng đợi có thông điệp, semaphore được thiết lập,

hoặc mailbox nhận được thư.

3.8 Khả năng sử dụng RTOS

Một RTOS không phải phù hợp với mọi ứng dụng. RTOS có thể không là một

giải pháp tốt nếu thiết bị phải thực hiện những ngắt ở tốc độ rất cao như trong hệ thống

điều khiển động cơ mức thấp hoặc khi hệ thống đơn giản không cần đến các chức năng

phức tạp của RTOS. Trong hệ thống mà bộ xử lý càng gần với việc điều khiển phần

cứng mức bit thì càng ít nhu cầu sử dụng RTOS trong hệ thống.

Một RTOS thường được sử dụng khi hệ thống cần đến tài nguyên chia sẻ, cần

phân bổ bộ nhớ. Nói chung trong những hệ thống phức tạp nhưng các tác vụ có thể

được lập lịch trong khoảng thời gian của bộ định thời (tích tắc) thì dùng RTOS có thể

có ý nghĩa. Thậm chí trong những hệ thống đơn giản, một RTOS có thể được sử dụng

để cấu trúc sự hoạt động của mã. RTOS cũng hữu dụng khi chúng ta cần sử dụng

những tài nguyên cơ bản (ổ đĩa, màn hình hiển thị, …).

RTOS thường được sử dụng khi các tác vụ được lập lịch tuần tự không thể đảm

bảo được những công việc có mức ưu tiên cao nhất sẽ được thực hiện trước. Sử dụng



57

lập lịch ưu tiên, RTOS có thể đảm bảo những chức năng quan trọng sẽ được thực hiện

đúng giờ.

Hầu hết RTOS đều có khả năng cấu hình được, chúng ta bắt đầu với hạt nhân

cơ bản và thêm những đặc trưng cần thiết cho hệ thống của mình. Nếu hệ thống có sử

dụng các ổ đĩa, giao tiếp mạng, chúng ta có thể thêm mô-đun bao gồm các driver và

mô-đun TCP/IP của RTOS.

Khi cân nhắc sử dụng một RTOS, hãy xem xét cả đến chi phí của nó. Một số

RTOS có phí mua một lần, trong khi những cái khác có cả phí cho mỗi sản phẩm sản

xuất ra. Chúng ta có thể trả phí bản quyền theo cách: trả mức phí cơ bản cho nhân hệ

điều hành và trả thêm phí cho mỗi mô-đun thêm vào.

Sự phân chia giữa một RTOS và nhân là không rõ ràng. Nói chung một nhân thì

nhỏ hơn so với RTOS tương ứng và nó không cung cấp đầy đủ các đặc trưng của

RTOS đầy đủ. Phần nhân có thể cung cấp các chức năng lập lịch và quản lý phù hợp

với những hệ thống nhúng nhỏ.

Sử dụng RTOS cũng đồng nghĩa với tốn kém bộ nhớ hơn do từng tác vụ đều có

ngăn xếp riêng của nó. Một số RTOS được liên kết vào mã chương trình, trong khi

những cái khác lại hoạt động giống như hệ điều hành của PC. RTOS được nạp từ một

thiết bị lưu trữ và chương trình của chúng ta thực thi như là một ứng dụng. Việc lựa

chọn RTOS nào có thể ảnh hưởng lớn đến các thiết bị phần cứng vì cần phải có những

tài nguyên cơ bản mà RTOS đó yêu cầu.

Các chuẩn truyền thông cũng rất quan trọng. Nhiều RTOS bây giờ hỗ trợ

TCP/IP. Nếu sử dụng một chuẩn giao tiếp như vậy chúng ta có thể liên lạc với bất kỳ

hệ thống khác sử dụng cùng chuẩn giao thức đó mà không liên quan đến sử dụng hệ

điều hành gì.

Sử dụng một RTOS trên bộ vi điều khiển có thể có một số khó khăn sau: không

gian mã chương trình có giới hạn, con trỏ ngăn xếp có thể được thực hiện trong phần

cứng (làm cho ngăn xếp tác vụ không thể thực hiện) và bộ nhớ RAM rất giới hạn.

RTOS cho vi điều khiển thường là những nhân rất cơ bản, không có nhiều đặc trưng

thêm vào.

3.9 Ƣu nhƣợc điểm của hệ điều hành thời gian thực

Nhân thời gian thực (còn được gọi là hệ điều hành thời gian thực - RTOS) giúp

cho dễ dàng thiết kế và mở rộng các ứng dụng thời gian thực, có thể thêm mới các

chức năng mà không yêu cầu phải thay đổi nhiều tới phần mềm. Tác dụng của RTOS

làm đơn giản hoá quá trình thiết kế bằng việc chia nhỏ mã ứng dụng thành các tác vụ

riêng biệt. Với một hệ RTOS ưu tiên, mọi sự kiện yêu cầu thời gian khẩn cấp đều được

bắt giữ nhanh chóng và hiệu quả. RTOS giúp cho việc quản lý tài nguyên được tốt hơn

với các dịch vụ hệ thống như semaphore, mailbox, queue ...

Tuy nhiên cũng phải cân nhắc khi sử dụng RTOS vì một số chi phí: nhân, yêu

cầu thêm ROM/RAM, chiếm CPU từ 2 – 4 %.



58

Hiện tại có trên 80 hệ RTOS thương mại cho các vi xử lý 8 bit, 16 và 32 bit.

Một vài RTOS là các hệ điều hành hoàn chỉnh, không chỉ bao gồm nhân thời gian thực

mà còn có các mô-đun quản lý I/O, hệ thống giao diện, hệ thống file, ...

3.10 Hệ điều hành thời gian thực µC/OS

Trong phần này, luận văn sẽ trình bày những vấn đề chính trong cấu trúc nhân

thời gian thực µC/OS. Một hệ điều hành thời gian thực rất nhỏ (khoảng hơn 5000 dòng

mã lệnh) [17], nhưng hiện đã được áp dụng và triển khai thành công vào rất nhiều dự

án có yêu cầu khắt khe về đáp ứng thời gian (như các hệ thống trong hàng không, y tế

…). Nhằm nắm bắt được những vấn đề cơ bản trong việc thiết kế xây dựng hệ thống

nhúng theo kiến trúc thời gian thực và thực hiện phần thực nghiệm trong quá trình

nghiên cứu vì nhân của nó cũng khá nhỏ và miễn phí cho mục đích giáo dục. Ngoài ra

trên thị trường còn có rất nhiều hệ điều hành thời gian thực nổi tiếng khác như: QNX,

VxWorks, Embedded Linux, Window CE…Các phần trình bày chính là:

Cách quản lý truy cập tới miền găng của µC/OS

Cấu trúc và trạng thái của tác vụ

Cách viết hàm xử lý ngắt

Cách quản lý nhịp đồng hồ

Khởi động hệ thống µC/OS

Khởi động hệ thống đa nhiệm

a. Các miền găng

Cũng giống như các nhân thời gian thực khác, µC/OS cũng vô hiệu hoá các

ngắt khi chương trình thực thi miền găng. Do ảnh hưởng tới vấn đề đáp ứng các ngắt

nên thời gian vô hiệu hoá các ngắt là một vấn đề quan trọng. µC/OS duy trì thời gian

vô hiệu hoá ngắt đến mức tối thiểu, nhưng thời gian này còn tuỳ thuộc nhiều vào kiến

trúc vi xử lý và chất lượng mã được sinh bởi chương trình dịch. Mọi vi xử lý đều cung

cấp các chỉ thị để vô hiệu/hữu hiệu hoá các ngắt và chương trình dịch C phải có cơ chế

thực thi các chỉ thị này bằng ngôn ngữ C hoặc Assembly (đối với một số trình biên

dịch). Trong µC/OS, hai macro được định nghĩa để vô hiệu/hữu hiệu các ngắt đó là

OS_ENTER_CRITICAL() và OS_EXIT_CRITICAL(). Các macro có thể khác nhau

tuỳ theo từng vi xử lý. Chính vì thế, chúng được viết trong file cấu hình dành riêng cho

vi xử lý trong OS_CPU.H (khi thực hiện porting).

b. Các tác vụ

Một tác vụ là một hàm lặp vô hạn. Nó giống như những hàm khác trong C chứa

đối số và một kiểu trả về nhưng không bao giờ trả về giá trị (hình 3.6). µC/OS có thể

quản lý tới 64 tác vụ (phiên bản µC/OS-II), trong đó có 2 tác vụ hệ thống, 4 tác vụ từ

OS_LOWEST_PRIO tới OS_LOWEST_PRIO-3. Người dùng có thể quản lý 56 tác

vụ. Mỗi tác vụ được gán một mức ưu tiên duy nhất từ 0 tới OS_LOWEST_PRIO-2. Vì

nhân theo kiểu lập lịch ưu tiên nên µC/OS luôn chọn tác vụ có độ ưu tiên cao nhất để

thực thi. Số hiệu độ ưu tiên cũng được sử dụng để làm định danh của tác vụ.



59

Hình 3.6 Cấu trúc một tác vụ

Để µC/OS quản lý các tác vụ của ứng dụng, bước đầu tiên là phải tạo các tác

vụ. Trong µC/OS hàm OSTaskCreate() và OSTaskCreateEx() (phiên bản II) thực hiện

điều này.

c. Các trạng thái của tác vụ

Các tác vụ có thể nhận 1 trong 5 trạng thái: DORMANT, READY, RUNNING,

WAITING FOR AN EVENT hoặc INTERRUPTED.

DORMANT: Tác vụ nằm trong bộ nhớ (ROM hoặc RAM) nhưng không sẵn

sàng cho µC/OS do chưa được tạo.

READY: Khi một tác vụ được tạo nó được đặt trạng thái là READY.

RUNNING: Tác vụ đang có sự phục vụ của CPU.

WAITING FOR AN EVENT: Đang chờ sự kiện.

INTERRUPTED: Ngắt xuất hiện khi đang thực hiện tác vụ và CPU đang thực

thi thủ tục ngắt.

Hình 3.7 mô tả biểu đồ chuyển trạng thái của các tác vụ trong µC/OS-II.

Hình 3.7 Biểu đồ chuyển trạng thái của tác vụ



60

Trạng thái DORMANT tương ứng với tác vụ đã nằm trong chương trình nhưng

chưa nằm trong quản lý của µC/OS. Khi µC/OS gọi hàm OSTaskCreate() hoặc

OSTaskCreateEx() thì tác vụ trên mới thực sự được quản lý bởi hệ điều hành và

chuyển sang trạng thái READY. Tác vụ có thể được tạo bất cứ lúc nào, khi tạo tác vụ

mới được gán quyền ưu tiên cao hơn thì nó sẽ chiểm ngay quyền điều khiển của CPU.

Tác vụ có thể trở về trạng thái DORMANT khi nó bị xoá khỏi µC/OS bằng

OSTaskDel().

Quá trình đa nhiệm được bắt đầu khi gọi OSStart(). Sau đó OSStart() sẽ chọn

tác vụ có trạng thái READY và có độ ưu tiên cao nhất để chuyển sang trạng thái

RUNNING.

Một tác vụ đang chạy có thể tự trì hoãn chính nó bằng cách gọi OSTimeDly().

Trong khi trì hoãn, tác vụ khác nếu có quyền ưu tiên cao hơn vẫn có quyền chiếm

CPU. Khi thời gian trì hoãn kết thúc, OSTimeTick() sẽ khôi phục trạng thái

RUNNING cho tác vụ.

Tác vụ đang chạy cũng có thể đợi sự xuất hiện của sự kiện bằng việc gọi

OSSemPend(), OSMBoxPend() hoặc OSQPend(), tác vụ chuyển sang trạng thái

WAITING. Khi tác vụ đợi một sự kiện, tác vụ có độ ưu tiên cao nhất tiếp theo được

quyền sử dụng CPU. Khi sự kiện xuất hiện, tác vụ lại chuyển sang trạng thái READY.

Sự xuất hiện của sự kiện có thể được báo bởi một tác vụ khác hoặc bằng ISR. Tác vụ

đang chạy luôn có thể bị ngắt trừ khi µC/OS vô hiệu hoá các ngắt. Khi đó, tác vụ trong

trạng thái ISR. Khi ngắt xuất hiện, tác vụ bị tạm dừng, ISR chiếm quyền điều khiển

CPU. Khi tất cả các tác vụ đều đợi sự kiện, µC/OS sẽ thực hiện tác vụ OSTaskIdle().

d. Khối điều khiển tác vụ

Khi tác vụ được tạo, nó được gán một khối điều khiển tác vụ (TCB). µC/OS sử

dụng TCB để duy trì trạng thái của tác vụ khi nó được thực thi theo kiểu lập lịch ưu

tiên. Khi tác vụ được khôi phục quyền điều khiển CPU (sau khi kết thúc ngắt), trạng

thái thực thi của tác vụ được khôi phục nhờ TCB. Tất cả TCB được lưu trú trong

RAM.

e. Lập lịch tác vụ

µC/OS sử dụng bộ lập lịch tác vụ được thực hiện bởi hàm OSSched(), nó luôn

chọn tác vụ có độ ưu tiên cao nhất để thực thi. Đối với lập lịch mức ISR sẽ được quản

lý bởi hàm OSIntExit() (lập lịch sau khi thoát khỏi ngắt).

Thời gian để lập lịch các tác vụ luôn là hằng số cho dù số tác vụ được tạo là bao

nhiêu. Nếu ứng dụng gọi OSSchedLock() hoặc xuất hiện ngắt (điều kiện

OSIntNesting>0), tác vụ lập lịch sẽ kết thúc. Khi bộ lập lịch tìm thấy tác vụ có độ ưu

tiên cao nhất, OSSched() sẽ kiểm tra xem tác vụ có độ ưu tiên cao nhất có phải là tác

vụ hiện thời hay không, điều này để tránh lãng phí một bước chuyển ngữ cảnh.



61

f. Các ngắt trong µC/OS

µC/OS yêu cầu dịch vụ ngắt ISR viết bằng hợp ngữ. Đỗi với những trình biên

dịch C hỗ trợ nhúng mã hợp ngữ inline thì có thể viết dịch vụ ngắt bằng hợp ngữ ngay

trong mã C.

Giả mã cho ISR như sau:

Hình 3.8 Hàm dịch vụ ngắt trong µC/OS

Trong đoạn mã trên, việc tăng trực tiếp OSIntNesting nhanh hơn nhiều so với

việc gọi hàm OSIntEnter() vì trong hàm OSIntEnter() hệ thống còn phải thực hiện việc

vô hiệu hoá các ngắt khác.

g. Nhịp đồng hồ

µC/OS yêu cầu cung cấp một đồng hồ thời gian để thực thi các chức năng liên

quan đến đo thời gian mà các dịch vụ cần đến. Một tích tắc cần xuất hiện 10 đến 100

lần trong một giây.

Trong µC/OS, người phát triển phải cho phép các ngắt thời gian xảy ra sau khi

khởi động hệ thống đa nhiệm (Sau khi gọi hàm OSStart()). Không được cho phép ngắt

thời gian xảy ra giữa hai lời gọi: OSInit() và OSStart() vì trong trường hợp đó µC/OS

sẽ trong trạng thái không được định nghĩa và hệ thống dễ gây ra lỗi.

Nhịp đồng hồ trong µC/OS được phục vụ bởi việc gọi hàm OSTimeTick() từ

một ngắt đồng hồ. Mã cho ngắt đồng hồ phải được viết bằng hợp ngữ vì nó phải truy

cập trực tiếp đến các thanh ghi. Trong trường hợp không viết được ISR cho ngắt đồng

hồ, người phát triển có thể gọi trực tiếp hàm OSTimeTick() từ mức tác vụ. Để làm

điều này, trước tiên tạo một tác vụ có độ ưu tiên cao hơn các tác vụ hiện có trong ứng

dụng, ngắt thời gian cần báo hiệu cho tác vụ này thông qua semaphore hoặc mailbox.

Tác vụ này được gọi là Tick Task.

h. Khởi động hệ thống µC/OS

Khởi tạo hệ thống µC/OS bằng cách gọi hàm OSInit() trước khi gọi bất cứ dịch

vụ nào. OSInit() sẽ khởi tạo mọi biến và cấu trúc dữ liệu của µC/OS. Nó cũng khởi tạo

tác vụ OSTaskIdle() với độ ưu tiên không đổi là OS_LOWEST_PRIO. Khởi động hệ

thống đa nhiệm µC/OS bằng cách gọi hàm OSStart(). Trước khi bắt đầu gọi hàm này

chúng ta phải tạo ít nhất một tác vụ cho chương trình ứng dụng.



62

i. Porting µC/OS

Porting µC/OS có nghĩa là cấu hình µC/OS để gắn nó với một vi xử lý xác định.

Hầu hết µC/OS được viết bằng C chuẩn trong đó có sử dụng các kiểu dữ liệu có khả

năng chuyển giữa các môi trường khác nhau, các bộ dịch khác nhau. µC/OS được thiết

kế có tính khả chuyển cao nên việc porting trên các vi xử lý khác nhau là khá dễ dàng.

Một vi xử lý có thể chạy µC/OS nếu nó thoả mãn các yêu cầu sau:

Có trình biên dịch C cho loại vi xử lý này.

Cho phép vô hiệu/hữu hiệu hoá các ngắt từ C.

Vi xử lý phải hỗ trợ ngắt và cần cung cấp một ngắt xuất hiện trong khoảng thời

gian đều đặn (10 đến 100Hz).

Vi xử lý phải hỗ trợ một ngăn xếp phần cứng và cho phép lưu các thông tin trên

ngăn xếp đó (có thể tới nhiều Kbyte).

Vi xử lý phải có các chỉ thị để tải, lưu con trỏ ngăn xếp và các thanh ghi CPU

khác trên ngăn xếp hoặc trong bộ nhớ.

Chi tiết về hệ thống µC/OS có thể tham khảo thêm tại [17] [21].



63

CHƢƠNG 4: CÁC CÁCH TIẾP CẬN VỚI BÀI TOÁN NHẬN

DẠNG CHỮ NÔM

4.1 Nhận dạng chữ Nôm bằng mạng nơ-ron

4.1.1 Áp dụng mạng nơ-ron trong nhận dạng chữ Nôm

Với những kết quả ban đầu đạt được cùng với nhóm nghiên cứu về nhận dạng

chữ Nôm tại trường Đại học Công nghệ, Luận văn cũng đưa ra cách tiếp cận sư dung

mạng nơ -ron để thực nghiệm với bài toán nhận dạng chữ Nôm vì một số ly do chính

sau: Thứ nhất , tôc đô nhân dang của mạng nơ -ron nhanh vì sau khi học thì việc xác

định một ký tự giống ký tự nào nhất chỉ là việc nhân ma trận . Hơn nữa việc này có thể

làm song song trên môi nut trong cung môt tâng [30]. Thứ hai la khối lượng dữ liệu

lưu trư để nhận dạng nho - chỉ cần lưu trữ mảng trọng số đã xác định trong quá trình

huân luyên mang ma không cân lưu trư tâp dư liêu mẫu chuân và tâp dư liêu ra chuân.

Thứ ba la ta có thể dễ dàng điêu chinh tôc đô nhân dang hay đô chinh xác băng viêc

thay đôi sô tâng ân va sô nut trên môi tâng . Tăng sô tâng va sô nut trên môi tâng se

tăng đô chinh xac nhưng lai giam tôc đô nhân dang . Lý do cuối cùng là dựa trên các

phương pháp đã áp dụng có kết quả tốt vê nhân dang chư tương hinh Trung Quôc và

Nhât Ban [31].

Có nhiều mạng nơ-ron co thê áp dụng vào bài toán nhân dạng, ở đây ta áp dụng

mạng Perceptron đa tầng v ì những ưu điểm của mạng này trong bài toán nhận dạng

chữ Latin [12]. Tuy nhiên tôi và nhóm nghiên cứu đã phân tích và điều chỉnh các

thông số của mạng để phù hợp với chữ Nôm.

Câu truc mang mô ta trong Hinh 4.1 gôm:

Tâng vao: 24x24 tín hiệu vào, biêu diên băng môt mang nhi phân 24x24 phân tư đươc

tạo thành từ mỗi một ảnh ký tự Nôm.

Tâng ra: 16 tín hiệu, biêu diên băng môt mang nhị phân 16 phân tư.

Tâng ân: sô lương tâng va sô nơ-ron trên môi tâng tuy chon.

- Hàm chuyển sử dụng:



64

Ban đầu các trọng số được gán ngẫu nhiên trong khoảng nao đo . Trong quá trình

học, các trọng số được tự điều chỉnh sao cho phù hợp với các mẫu học , làm giảm sai

số giữa giá trị đâu ra chuân Ys với giá trị tính toán thưc tê outs . Viêc hiêu chinh trong

sô dừng khi qua trinh huân luyên hôi tu tai một ngương lôi châp nhân đươc hoăc dưn g

sau một sô lần học xác định trước.

Sau khi qua trinh huân luyên đã xong , bô trong sô đăc trưng cho thông tin nhân

dạng được lưu trữ lại trong tệp tin để sử dụng cho quá trình nhận dạng. Viêc nhân dang

chỉ đơn giản là quá trình biến đ ổi mẫu vào X thành mẫu ra Y dựa trên bộ trọng số đã

xác định. Mâu ra Y se đươc nhân dang nêu no thuôc tâp mâu ra chuân đa dung đê huân

luyên mang . Ngươc lai , mạng không nhận dạng được nếu sau quá trình biến đổi trên

mạng thu được mẫu ra Y không thuộc tập mẫu chuẩn đã học .

4.1.2 Thƣc nghiêm

Tôi và nhóm nghiên cứu đã xây dựng chương trinh thưc nghiêm để học và nhân

dạng các ký tự Nôm chứa trong một ảnh và đưa ra ngữ nghĩa bằng tiếng Việt và ti ếng

Anh. Thành phần chính của chương trình là mạng Perceptron đã mô tả trong phần trên .

Mạng hoạt động như hộp đen , vơi bô trong sô đa hoc , biên đôi 24x24 tín hiệu vào

dạng nhị phân thành 16 tín hiệu ra dạng nhị phân . Vơi ch uôi nhi phân ra 16 bits,

chương trinh se tao môt bô khoa gôm cac sô nguyên thuôc miên gia tri 0216

-1. Bô

khóa này được sử dụng làm chỉ số của mảng ngữ nghĩa và được ánh xạ với chỉ số mỗi

dòng ngữ nghĩa (tương ưng vơ i nghia cua môt ky tư ) trong cac têp tin chưa nghia cua

tư.

Sử dụng mạng nơ -ron vào nhận

dạng ta phải tiến hành qua hai bước

chính là bước huân luyên mang va bước

nhân dang . Quá trình huấn luyện dựa

trên nguyên tắc học có giám sát với tập

mẫu {(Xs,Ys)}. Trong đo , Xs la mang

nhị phân 24x24 phân tư biêu diên anh

môt ky tư Nôm , Ys la mang nhi phân

16 phân tư . Đầu ra sử dụng mảng 16

phân tư đê biêu diên chăn 2 byte dư liêu

và biểu diễn được 216 giá trị khác nhau

nên đu đê biêu diên hơn 9000 ký tự

Nôm. Ý tưởng cơ bản của quá trình

huấn luyện mạng là xác định bộ trọng

số W sao cho:

outs = f(Xs,W) =Ys đối với mọi mẫu

học s.

Hình 4.1 Câu truc mang Perceptron

đa tâng cho bài toán nhận dạng chữ

Nôm



65

Chương trinh gôm ba mô-đun chinh:

- Chuẩn hoá dữ liệu vào: xư ly đưa cac anh vào vê dang chuân , tách dòng, tách

ký tự , chuyên môi ky tư thanh môt mang tin hiêu v ào; tạo tập các mẫu vào

chuân la tâp hơp cac mang nhi phân kich thươc 24x24 đươc tao tư anh chưa

các mẫu ký tự cần học ; tạo tập các tín hiệu ra chuẩn để phân lớp ký tự , tâp tin

hiêu ra chuân la tâp cac mang nhi phân kich thươc 16.

- Nhân dang: chuyên môi mang tin hiêu vao thanh môt mang tin ra tương ưng

thông qua hang loat cac tinh toan tai cac nut trong mang nơ-ron.

- Xác định ngữ nghia: nạp nội dung tệp tin ngữ nghĩa vào mảng ngữ nghĩa, môi

dòng tương ứng với một phần tử của mảng . Chuyên mang tin hiêu ra 16 bits

thành một số nguyên (khóa) thuôc bô khoa, sô nguyên nay chinh la chi sô cua

phân tư mang chưa nghia cua ky tư .

Mô hinh hoat đông hê thông đươc chi ra như trong Hinh 4.2:

Hình 4.2. Câu truc mô-dun của chương trinh

Bô dư liêu mâu huấn luyện là môt anh chưa khoảng 4232 ký tự chữ Nôm chuẩn .

Tâp mâu ra chuân : đươc tao ngươc tư bô khoa , môi khoa thuôc đ oạn 0216

-1 đươc

chuyên thanh môt mang nhi phân 16 phân tư . Quá trình huấn luyện mạng thực hiện

theo lưu đô Hinh 4.3.

Hê thông đươc thư nghiêm trên môi trương phân cưng : Pentium IV, 1.5GHz, Bus

800/ Cache 1MB, RAM: 256MHz; HDD 80GB, 7200rpm; phân mêm : Windows XP

SP 2, .Net Framework 2.0. Một ví dụ về kêt qua được thể hiện trong bảng 4.1.

Bảng 4.1 Môt kêt qua nhận dạng

Mâu vao : đoạn thơ trong truyện kiều

1866

Kêt qua nhân dang :

Chuân hoa dƣ

liêu vao

NHÂN DANG

Xác định ngữ

nghia

Mảng nhị

phân 24x24 Mảng nhị

phân 16



66

So với nghĩa thực tế, ở đây kết quả nhận dạng có sai một số ký tự. Kết quả này sẽ

được phân tích trong phần 4.3.

Hình 4.3 Lưu đô huân luyên mang

4.2 Ứng dụng Tesseract để nhận dạng chữ Nôm

4.2.1 Tóm tắt về Tesseract

Tesseract [27] là một chương trình nhận dạng chữ (OCR) mã mở do HP phát

triển từ năm 1984 tới 1994, được biên dịch và chạy trên cả 2 môi trường Linux và

Windows. Năm 1995 Tesseract là một trong ba bộ nhận dạng chữ có độ chính xác cao

nhất tại cuộc thi tổ chức tại Đại học Nevada, Las Vegas [32]. Cuối năm 2005,

Tesseract được công bố dưới dạng bản quyền mã mở (Apache License 2.0) và được

Google tiếp tục phát triển (http://code.google.com/p/tesseract-ocr/). Hiện nay Tesseract

nhận dạng được sáu ngôn ngữ: Anh, Pháp, Ý, Đức, Tây ban nha, Hà lan.

Kiến trúc của Tesseract được mô tả khá đầy đủ trong [27], cùng với tài liệu thiết

kế về chi tiết các lớp, các hàm ở trang web http://tesseract-ocr.repairfaq.org/. Tesseract

Câu hinh mang

Khơi tao mang

trọng số

Nạp ảnh chứa N

mâu

Phân tich anh

Xác định ảnh ký tự

tiêp theo

Băt đâu

Kêt thuc

Chuyên sô nguyên i

thành mảng 16 bits

Chuyên ảnh ký tự

thành mảng

24x24 bits

Sai

Đung

Câp nhât mang trong

sô

Tính hệ số lỗi

Tính đầu ra thực tế

Tính hệ số lỗi trung

bình

Chuyên đên mâu vao kê

tiêp

Còn mẫu ký tự trong

ảnh

Còn mẫu vào chuẩn

Hê sô lôi nhỏ hơn

ngương lôi

Sai

Đung

Sai

Đung

i < N

Vòng lặp nhỏ hơn Số

vòng lặp tôi đa

Đung

Đung

Sai

Sai

http://tesseract-ocr.repairfaq.org/



67

hiện chỉ nhận dạng các ảnh văn bản một cột dữ liệu, không có phần phân tích dàn

trang (layout).

Bước đầu tiên là phân tích các thành phần liên thông từ một ảnh đầu vào và lưu

lại các đường viền ngoài của các thành phần đó. Ở giai đoạn này, những đường nét

viền ngoài được thu thập cùng với nhau và lồng hoàn toàn vào nhau thành các đốm

mầu (blob).

Các blob được tách thành các dòng văn bản và được phân tích tiếp để xác định

những đoạn văn bản chữ nghiêng hoặc cân xứng. Các dòng văn bản được tách ra thành

các từ khác nhau theo khoảng cách giữa các ký tự. Đoạn văn bản có độ nghiêng xác

định được tách trực tiếp ra thành các ô ký tự. Đoạn văn bản cân xứng được tách ra

thành các từ sử dụng những khoảng trống xác định.

Lưu đồ hoat đông cua Tesseract đươc mô ta trong Hinh 4.4.

Phân tích thành

phần kết nốiTiền xử lý

Ảnh đầu

vào

Ảnh nhị phân

Tìm ra các dòng

văn bản và từ

Đường viền

các ký tự

Các đường bao ký

tự được tổ chức

thành các từ

Nhận dạng từ 1Nhận dạng từ 2

Bộ tách ký tự Bộ kết hợp ký tự

Bộ phân lớp ký tự

tĩnhTừ điển

Bộ phân lớp

thích nghi

Bộ phân tích

số

Từ thích hợp

Hình 4.4 Kiến trúc tổng quát của Tesseract

Trong quá trình huấn luyện, từ một ảnh đầu vào chứa các ký tự hoặc đoạn văn

bản cần để huấn luyện, Tesseract sẽ áp dụng các thuật toán xử lý ảnh để phân tích ảnh

đầu vào thành các dòng, các từ rồi đến các ký tự riêng biệt. Sau đó chương trình sẽ

trích xuất ra các đặc trưng tương ứng với các ký tự. Trong quá trình huấn luyện các

đặc trưng cần trích xuất là các phân đoạn xấp xỉ theo đa giác và những đặc trưng này

được xem như là các khuôn mẫu của dữ liệu huấn luyện và được lưu vào cấu trúc dữ

liệu k-d tree.

Tesseract dùng kỹ thuật k-NN [9] để thực hiện phân lớp đối tượng. Với một

vector có n đặc trưng: (A1(x), A2(x), …, An (x)). Thì cách tính khoảng cách từ đối tượng

x tới y được tính như sau:

D(x, y) =

n

i

ii yAxA1

2))()((



68

Đối tượng gần với mẫu nhất sẽ có khoảng cách tổng hợp trên tất cả các đặc trưng

là nhỏ nhất.

4.2.2. Áp dụng với chữ Nôm

Tesseract ban đầu được thiết kế chỉ để nhận dạng văn bản tiếng Anh. Sau này nó

đã được chỉnh sửa và phát triển để nó có khả năng nhận dạng các ngôn ngữ khác. Với

bài toán chữ Nôm ta có thể sử dụng lại các kỹ thuật tiền xử lý rất tốt của Tesseract như

công đoạn xử lý nhiễu, căn chỉnh độ nghiêng [28], tách dòng, tách từ để áp dụng vào

cho chữ Nôm.

Do chữ Nôm là hệ thống chữ tượng hình viết theo dạng có kích thước cố định và

các chữ không dính nên khi dùng Tesseract để tách từ cũng dễ hơn so với tách từ trong

các ngôn ngữ khác. Tuy nhiên sau khi tách từ thi một số ký tự tương đối giống nhau và

khó xác định hai “từ gốc” thuộc về hai ký tự khác nhau hay thuộc về cùng một ký tự.

Một nhược điểm của Tesseract là nó có thể sẽ xử lý chậm với những ngôn ngữ có tập

ký tự lớn (như chữ Nôm có hơn 4000 ký tự). Do đó ta cần phải có những sửa đổi trong

mã nguồn để cho phù hợp. Chương trình hiện tại cũng đã được sửa đổi tại một số mô-

đun để nâng cao khả năng phân đoạn đối với chữ Nôm.

Tôi đã thử nghiệm huấn luyện và nhận dạng chữ Nôm trên hệ điều hành Ubuntu

7.4, Tesseract 2.03 với một số sửa đổi trong mã nguồn. Bộ dữ liệu dùng để huấn luyện

là 4232 ký tự chữ Nôm cho mỗi loại kiểu chữ thường, chữ đậm, chữ nghiêng và thêm

khoảng 2000 chữ Nôm trong bản kiều 1866. Bộ dữ liệu dùng để nhận dạng là bản

truyện kiều năm 1866. Kêt qua nhân dang trang đầu tiên của truyện kiều đạt 94,9 %,

thời gian nhận dạng khoảng 15 giây. Khi tiến hành nhận dạng 10 trang đầu tiên thì kết

quả đạt khoảng 89,8 % trong thời gian khoảng trên 1 phút. Kết quả nhận dạng được

thể hiện trong Bang 4.2.

Bảng 4.2 Kêt qua nhân dang chư Nôm vơi Tesseract

Đầu vào: đoạn thơ trong truyện kiều

1866

Kêt qua nhận dạng:



69

4.3. So sánh và thảo luận

Những kết quả nhận dạng trong luận văn được tiến hành thực nghiệm trên cùng

một bộ dữ liệu khoảng 4232 chữ Nôm chuẩn để tiến hành đánh giá so sánh kết quả của

hai cách tiếp cận nhằm mục đích nghiên cứu [11] và đưa ra những định hướng phát

triển hệ thống nhận dạng chữ Nôm có chất lượng tốt.

Thông qua các kết quả thực nghiệm này và các thử nghiệm khác mà chúng tôi đã

tiến hành thì nhận thấy rằng Tesseract có những mô-đun cho việc tiền xử lý và phân

đoạn là khá tốt với chữ Nôm ví dụ như xử lý độ nghiêng của văn bản, loại bỏ nhiễu,

tách dòng, tách chữ. Và kết quả nhận dạng có độ chính xác trung bình khoảng 93%.

Đối với phương pháp nhận dạng chữ Nôm theo mạng nơ-ron, chúng tôi cũng đã xây

dựng một mô-đun tiền xử lý đơn giản để tách ảnh đầu vào thành các chữ Nôm riêng

biệt và khi thử nghiệm với mô hình mạng nơ-ron đề xuất, kết quả nhận dạng đạt tới

gần 100% vơi môt phân tâp mâu đa hoc , với mẫu có nhiều biến đổi so với tập mẫu

chuân thi đô chinh xac con thâp . Điêu nay do mô -đun tiên xư ly con đơn gian , chưa

chú trọng việc chuẩn hóa dữ liệu vào mà chỉ tập trung vào xây dựng mạng nhận dạng .

Đối với phương pháp nhận dạng trong Tesseract do sử dụng k-NN và tổ chức dữ

liệu theo k-d tree nên đòi hỏi bộ nhớ lớn để lưu trữ các mẫu đã học nên khả năng

chuyển sang môi trường nhúng sẽ khó khăn hơn so với phương pháp nhận dạng bằng

mạng nơ ron vì chỉ cần lưu lại bộ trọng số cần thiết . Xét riêng về mô -đun nhân dang

thì nhận dạng bằng mạng nơ -ron ưu viêt hơn vê tinh kha chuyên , tính linh động, tôi ưu

lưu trư va kha năng tich hơp cao . Ở chương 5 dưới đây tôi sẽ đưa ra những phân tích

và áp dụng mô đun nhận dạng dựa trên Tesseract cho môi trường nhúng để thực

nghiệm, định hướng những nghiên cứu tiếp theo và hoàn thiện ứng dụng.



70

CHƢƠNG 5: ỨNG DỤNG VÀ PHÁT TRIỂN PHẦN MỀM

NHẬN DẠNG CHỮ NÔM CHO THIẾT BỊ NHÚNG

5.1 Phân tích ứng dụng trên môi trƣờng nhúng

Chương trình nhận dạng được chia thành 2 phần chính: quá trình học và quá

trình nhận dạng. Quá trình học được thực hiện trên Desktop và các file chứa các đặc

trưng tương ứng với từng chữ sẽ được lưu lại và đưa lên thiết bị mobile để phục vụ cho

quá trình nhận dạng. Tuy nhiên theo phương pháp nhận dạng dùng K-NN trong

Tesseract thì để có kết quả nhận dạng với độ chính xác cao thì các file này tương đối

lớn, đòi hỏi máy có đủ bộ nhớ để lưu trữ. Cách thiết kế này cũng đúng với việc sử

dụng các phương pháp nhận dạng khác mà có thể phù hợp hơn với các thiết bị nhúng

như dùng ANN. Trên máy Desktop sẽ tiến hành việc xây dựng mạng nơron phù hợp

và thực hiện quá trình học để xác định được bộ trọng số w tốt nhất, sau đó chỉ cần đưa

bộ trọng số này lên thiết bị di động phục vụ cho quá trình nhận dạng. Như vậy đối với

phương pháp này thì tốn rất ít bộ nhớ để lưu trữ.

* Hình thể hiện quá trình học trên Desktop:

Input Image Preprocessing

step

Line, Character

Segmentation

Extracted

features

Files about prototype of

characters

Hình 5.1 Quá trình học chữ Nôm

* Quá trình nhận dạng theo Tesseract:

Recognition

routine (K-NN)

Input Image Preprocessing

step

Line, Character

Segmentation

Extracted

features

Load files (or W)

from training stepBuild K-d

tree

matching features

Result

Hình 5.2 Quá trình nhận dạng



71

Ở phần này tôi sẽ trình bày việc phân tích thiết kế một hệ thống nhận dạng chữ

Nôm trên mobile, trong đó ứng dụng mô-đun nhận dạng của Tesseract đã nêu ở trên và

được xem như một hộp đen khi sử dụng. Người dùng sẽ sử dụng camera có sẵn trên

điện thoại để chụp hình chữ Nôm hoặc dùng những ảnh chụp sẵn lưu trong máy để làm

đầu vào cho chương trình nhận dạng. Các thiết bị phần cứng như nút bấm, màn hình,

camera …được điều khiển bởi hệ điều hành nhúng trên thiết bị mobile.

Sự kiện bên ngoài:

Chúng ta xem hệ thống như là một hộp đen phản ứng lại các yêu cầu và thông

điệp từ môi trường. Môi trường bao gồm các tác nhân. Từng tác nhân tương tác với hệ

thống có những mục đích khác nhau và trao đổi một tập các thông điệp. Hình 5.3 thể

hiện biểu đồ ngữ cảnh của hệ thống, trong biểu đồ này chúng ta thấy có 2 tác nhân

tương tác với hệ thống đó là: User và Battery. User tương tác với hệ thống thông qua

các nút bấm, màn hình. Battery tương tác với hệ thống để thông báo mức pin, khi pin

gần hết một ngắt phần cứng xảy ra và chương trình sẽ thực hiện hàm ngắt thông báo về

mức pin rồi dừng các công việc tính toán hiện tại để chuyển sang chế độ chờ.

User

Nom recognition system on mobile

device

Battery

System

Interface

Actuators

+ Battery level meter

+ Buttons

+ Camera

+ Screen

Recognition Request

Power

Hình 5.3 Biểu đồ ngữ cảnh của hệ thống

Sự kiện là một thông điệp từ môi trường. Bảng 5.1 dưới đây chỉ ra các sự kiện chính

bên ngoài có thể xảy ra tác động vào hệ thống. Trong đó cột có tên là “A” chỉ ra sự

kiện đó đến theo chu kỳ kí hiệu là P (Periodic) hay đến một cách ngẫu nhiên ký hiệu là

E (Episodic).



72

Bảng 5.1 Các sự kiện tác động vào chương trình

Event System Response Direction A Resp

1 User press a recognition

command

a. Show task

progress display

b. Start recogniton

step

in E 0.5s

2 User press start camera

button

Start capture image in E 0.5s

3 Low battery alarm Warn the user and

stop current task

in E 0.5s

Biểu đồ use case mức gộp của hệ thống:

Recognize an image

Capture an image

Open an image

User

<<include>>

<<include>>

Hình 5.4 Biểu đồ Use case của hệ thống

Hệ thống có 3 use case chính là recognize an image, capture an image và open

an image sẽ được mô tả ngắn gọn dưới đây.

Ca sử dụng Recognize an image

Tác nhân: Người sử dụng

Mục đích: Nhận dạng một ảnh chữ Nôm và cho ra kết quả.

Mô tả: Từ menu của chương trình người dùng sẽ chọn lệnh để thực hiện quá

trình nhận dạng. Chương trình sẽ cho phép người sử dụng có thể chọn một ảnh

đã có sẵn trên điện thoại hoặc bắt đầu chụp một ảnh mới để nhận dạng.

Kết quả: trả về kết quả nhận dạng từ một ảnh

Ca sử dụng Capture an image


Mục đích: Chụp một ảnh từ môi trường bên ngoài.



73

Mô tả: Khi người sử dụng chọn chức năng chụp ảnh, chương trình sẽ kích hoạt

camera và thực hiện quá trình chụp ảnh. Trong ca sử dụng này chương trình sẽ

hỏi người sử dụng có lưu lại ảnh vừa chụp không hay chỉ nhận dạng để biết kết

quả mà không lưu lại ảnh.

Kết quả: trả về ảnh vừa chụp.

Ca sử dụng Open an image


Mục đích: Chọn một ảnh đã tồn tại trên điện thoại

Mô tả: Khi người sử dụng chọn chức năng mở file ảnh, chương trình sẽ đưa ra

hộp thoại cho phép người dùng chọn được ảnh mong muốn.

Kết quả: mở ảnh vừa chọn.

Biểu đồ tuần tự

Hình 5.5 dưới đây mô tả biểu đồ tuần tự cho ngữ cảnh nhận dạng chữ Nôm trên

thiết bị mobile.

: User : System : Camera :

RecognitionEngine

recognition request

capture or open an image?

capture command

start camera to capture an image

return an image

recognize the image

return the result

If user choose

capture command

If user choose open

an existing image

open command

recognize the image

return the result

save image and result

save result

{ 0.5 s }

{ 0.5 s }

Display open dialog

{ 0.5 s }

Choose an existing image

{ 0,5 s }

Hình 5.5 Biểu đồ tuần tự của hệ thống nhận dạng chữ Nôm



74

Biểu đồ lớp

Người sử dụng tương tác với hệ thống thông qua bàn phím và màn hình. Đây là

những đối tượng bị động, do vậy chúng ta sử dụng thêm một đối tượng giao tiếp người

dùng User Interface để quản lý việc tương tác với người dùng. Lớp User Interface dựa

vào lớp RecognitionEngine để thực hiện nhận dạng, nó cũng kết nối với Battery để

nắm bắt được tín hiệu về mức pin và với lớp View, GraphicContext để quản lý thông

tin trên màn hình. Lớp RecognitionEngine sử dụng những lớp Camera hoặc

FileSystem để tạo ảnh đầu vào cho quá trình nhận dạng. Biểu đồ lớp của hệ thống

được thể hiện trong hình 5.6.

Hình 5.6 Biểu đồ lớp của hệ thống nhận dạng chữ Nôm

Phân chia tác vụ

Chương trình có thể được chia ra làm 5 tác vụ chính:

Recognition_Task: Thực hiện các công việc liên quan đến quá trình nhận dạng.

Display_Task: Thực hiện việc quản lý màn hình như hiển thị các menu tương

tác với người dùng, trạng thái và kết quả công việc.

Button_Task: Xử lý phím bấm.

Camera_Task: Điểu khiển camera.

Filesystem_Task: Quản lý việc mở file, lưu và xoá file.



75

Và sử dụng hệ điều hành nhúng để lập lịch phân chia hoạt động, mức độ ưu tiên giữa

các tác vụ, quản lý tài nguyên trong quá trình thực hiện. Hình 5.7 thể hiện trạng thái

của các tác vụ khi thực thi trong hệ thống.

DORMANT

READY

OSCreateTask

RUNNING

ISR

WAITING

OSIntExit

Interrupt

Delete

Task is Preemptive

OSIntExt

Pend or Delay time

Have Event

Delete

Msg Queue is empty

Pend OS Queue

Hình 5.7 Trạng thái của tác vụ khi thực thi trong hệ thống

Khi chạy chương trình, hệ thống ở trạng thái idle (không thực hiện gì). Người

dùng sẽ gửi yêu cầu thông qua các phím bấm và hệ thống sinh ra ngắt gọi tác vụ xử lý

phím bấm, sau đó gọi các tác vụ khác để thực hiện đáp ứng yêu cầu nhận dạng chữ

Nôm của người dùng. Khi không có tác vụ nào thực hiện hệ thống sẽ quay về trạng

thái idle. Hình 5.8 mô tả quá trình thực thi và chuyển đổi giữa các tác vụ trong hệ

thống để đáp ứng một yêu cầu nhận dạng.

IDLE

Button_Task

(highest priority)

Button Interrupt( call ISR )

Display_Task

Send recognition command

Camera_Task

Choose start camera or open image

Recognition_TaskResult

After finish, return to IDLE task

OSCreateTask()

OSCreateTask() Filesystem_Task

OSCreateTask()

Hình 5.8 Biểu đồ chuyển đổi giữa các tác vụ



76

5.2 Thực nghiệm chƣơng trình nhận dạng dựa trên Tesseract với môi

trƣờng µC/OS

Từ cách tiếp cận nhận dạng chữ Nôm dựa trên mã nguồn mở Tesseract đã đề

cập ở trên với nhiều mô đun hỗ trợ cho việc huấn luyện và nhận dạng tôi đã tiến hành

tách riêng phần mô đun nhận dạng và đưa lên môi trường hệ điều hành thời gian thực

µC/OS.

Chương trình thực nghiệm được viết bằng C++ và biên dịch trên môi trường

Visual C++. Phiên bản hệ điều hành thời gian thực sử dụng là µC/OS-II, một mã

nguồn mở cho mục đích học tập và nghiên cứu (nếu cho mục đích thương mại thì cần

có bản quyền [17]). Trong phiên bản này đã có nhiều cải tiến về quản lý các tác vụ và

nhiều mở rộng mới cho phép dễ dàng chuyển sang nhiều kiến trúc bộ vi xử lý khác

nhau.

Chương trình thực nghiệm được viết với hai tác vụ: tác vụ chính thực hiện việc

xử lý nhận dạng (có mức ưu tiên cao hơn) và một tác vụ về hiển thị để mô phỏng được

quá trình khởi tạo tác vụ, lập lịch và thực hiện tác vụ trong nhân thời gian thực µC/OS.

Ngoài ra khi khởi tạo hệ thống bằng hàm OSInit(), hệ thống sẽ tạo ra tác vụ idle task

(OSTaskIdle()). Độ ưu tiên của nó luôn được đặt là OS_LOWEST_PRIO (mức ưu tiên

thấp nhất) do đó nó sẽ được gọi khi không còn tác vụ nào đang thực hiện. Hệ thống

cũng tạo thêm 1 tác vụ thống kê (OSTaskStat()) để tính toán phần trăm sử dụng CPU

của ứng dụng.

Tác vụ nhận dạng có mức ưu tiên cao hơn trong hệ thống nên nó sẽ được lập

lịch để thực thi trước tác vụ hiện thị. Kết quả thể hiện trong bảng 5.2.

Bảng 5.2 Kết quả thực hiện tác vụ nhận dạng

Đầu vào: đoạn thơ trong truyện kiều 1866 Kêt qua:

Thời gian thực hiện tác vụ nhận dạng sẽ tuỳ thuộc rất nhiều vào đặc tính của ảnh

chữ Nôm làm đầu vào, nếu ảnh chữ Nôm lớn, chứa nhiều chữ thì thời gian thực hiện

tác vụ nhận dạng sẽ chậm và ngược lại. Đối với khổ thơ thực nghiệm trên thì thời gian

thực hiện của tác vụ nhận dạng khoảng 1 giây. Ngoài ra với cơ chế của hệ điều hành

thời gian thực thì chúng ta cũng có thể lập lịch để thực hiện đồng thời tác vụ nhận

dạng và các tác vụ khác để đảm bảo những ràng buộc của hệ thống. Việc thực nghiệm

đưa mô đun nhận dạng dựa trên Tesseract lên môi trường µC/OS để ta có thể hiểu rõ

hơn những công việc cần làm khi đưa ứng dụng lên môi trường nhúng, những yêu cầu

đặt ra đòi hỏi tối ưu về lưu trữ và tốc độ xử lý của chương trình.



77

KẾT LUẬN

Luận văn đã trình bày về các vấn đề trong xây dựng hệ thống nhúng và đi sâu

vào các phương pháp phân tích, thiết kế và xây dựng phần mềm nhúng. Sử dụng

những ưu điểm của hệ điều hành thời gian thực trong thiết kế hệ thống nhúng, người

thiết kế có thể thiết kế các tác vụ và các mô-đun cho chương trình mà không cần thiết

phải bận tâm nhiều đến các ràng buộc thời gian thực. Việc đảm bảo các đáp ứng thời

gian thực được quản lý bởi hệ điều hành thời gian thực. Người phát triển chỉ cần tập

trung vào đặc tả thiết kế thế giới thực cho bài toán.

Phần mềm nhúng sử dụng hệ điều hành thời gian thực tăng khả năng sử dụng

lại của phần mềm, tăng tính đóng gói cho chương trình. Hơn nữa, các hệ điều hành

thời gian thực cung cấp các khả năng trừu tượng hoá trên nhiều nền phần cứng khác

nhau để phát triển chương trình. Chúng hỗ trợ các thư viện hàm dành riêng cho các

kiến trúc phần cứng khác nhau, do đó chương trình không phải bận tâm nhiều tới các

kiến trúc phần cứng.

Bên cạnh đó, những kết quả đang khich lê đạt được từ việc nghiên cứu các cách

tiếp cận nhận dạng chữ Nôm trong luận văn sẽ mở ra nhiều hướng cho xây dựng

những hệ thống nhận dạng chữ Nôm có tính ứng dụng cao trong thực tế. Tôi cũng đã

tiến hành thực nghiệm phần đưa mô đun nhận dạng xuống môi trường hệ điều hành

thời gian thực µC/OS và sử dụng nhân hệ điều hành này để khởi tạo, lập lịch tác vụ

hoạt động cho chương trình nhận dạng để chúng ta có thể hình dung rõ hơn về cách

thức hoạt động của phần mềm sử dụng kiến trúc hệ điều hành thời gian thực. Tuy

nhiên vẫn còn nhiều vấn đề phức tạp cần xư ly, nâng cao cả về nhận dạng chữ Nôm và

triển khai ứng dụng trên môi trường nhúng cụ thể như viêc chuân hoa dư liêu vao , việc

trích xuất các đặc trưng phù hợp với chữ Nôm, viêc xây dưng câu truc mang nhiêu

tâng, vân đê vê bô nhơ , khả năng xử lý , hạn chế của các thư viện lập trình . Tôi cũng

đưa ra môt sô hương phat triên tiếp theo như sau:

Thư nhât la co thê sư dung ma nguôn mơ Tesseract đê phat triên cac ưng dung

nhân dang chư Nôm băng viêc tiếp tục cải tiến cac mô -đun tiên xư ly , mô-đun nhận

dạng và xư ly kêt qua để nâng cao chất lượng nhận dạng chữ Nôm .

Thư hai là ap dung mang nơ -ron đê phat triên ứng dụng nhân dang chư Nôm

hoàn chỉnh trên môi trường nhúng như cac thiêt bi di đông, và mở rộng thêm các mô -

đun xử lý như khôi phuc chư Nôm mơ, thiêu net, phát triển các ứng dụng đa từ điển.

Thứ ba là nghiên cứu phương pháp trích xuất những đặc trưng phù hợp cho nhận

dạng chữ Nôm, điều này sẽ làm tăng độ chính xác khi nhận dạng. Và xây dựng những

ứng dụng nhận dạng chữ Nôm viết tay.



78

TÀI LIỆU THAM KHẢO

Tiếng Việt

[1] PGS. TS. Nguyễn Ngọc Bình, “Một số ý kiến về phát triến, ứng dụng công nghệ

thông tin của Việt Nam”, Hội thảo Quốc gia Hội nhập Quốc tế về Khoa học và Công

nghệ, 2005.

[2] PGS. TS. Phạm Thượng Cát, “Hệ thống nhúng và sự phát triển của công nghệ

thông tin”, Tạp chí Tin học và điều khiển, 2005.

[3] Phan Anh Dũng, Dương Văn Việt, Hoàng Thị Ngọc Dung – Trung tâm Công nghệ

thông tin Thừa Thiên Huế, “Đưa Chư Han-Nôm Vao Thiêt Bi Câm Tay ”, Hội nghị chữ

Nôm, 2006.

[4] Phan Anh Dũng, Nguyễn Thế, “Từ điển Trực tuyến Việt-Hán-Nôm”, 2006.

[5] Phòng nhận dạng và xử lý ảnh Viện công nghệ thông tin , “Phân mêm nhân dang

chư Viêt in”, 1997-1998.

Tiếng Anh

[6] Arbib, Michael A. (Ed.), “The Handbook of Brain Theory and Neural Networks”,

MIT Press, 1995.

[7] Arnold Berger, “Embedded Systems Design: An Introduction to Processes, Tool

and Techniques ”, CMP Books, 2002.

[8] Bentley, J. L, “Multidimensional binary search tree used for associative

searching”, Commun, ACM, 1975, pp 509–517.

[9] Belur V. Dasarathy, “Nearest Neighbor (NN) Norms: NN Pattern Classification

Techniques”, IEEE Computer Society Press, 1991.

[10] Bruce Powel Douglass, “Advances in the UML for Real-time System, Third

Edition”, Addition Wesley, 2004.

[11] Cheng-Lin Liu, Hiromichi Fujisawa, “Classification and Learning for Character

Recognition: Comparasion of Methods and Remaining Problems”, NNLDAR

Workshop, 2007.

[12] Daniel Admassu, “Unicode Optical Character Recognition”, 2005.

[13] David E. Simon, “An Embedded Software Primer”, Addison Wesley, 1999.

[14] Ivan Porres Paltor, Johan Lilius, “A Case Study on Designing Embedded Systems

using UML notation”, TUCS Technial Report, 1999.

[15] Jack Ganssle, “The Art of Designing Embedded Systems”, Newnes, 1999.

[16] Jack Ganssel, Michael Barr, “Embedded Systems (World Class Designs)”.

Newnes, 2007.

[17] Jean Labrosses, “Micro C OS II: The Real Kernel”, Newnes, 2002.



79

[18] Jiamei Cai, Tieming Chen, and Liying Zhu, “A Structure Modelling Method for

Multi-task Embedded Software Design”, Zhejiang University of Technology, ICESS

2004.

[19] Luciano Lavagno, Grant Martin and Bran Selic, “UML for real design of

Embedded Real-Time Systems”, Kluwer Academic, 2004.

[20] Michael Barr, “Programming Embedded Systems in C and C++”, O’Reilly,

1999.

[21] Micrium Inc, “µC/OS-II Reference Manual”, Newnes, 2002.

[22] Mingrui Wu, Bo Zhang, Ling Zhang, “A Neural Network Based Classifier for

Handwritten Chinese Character Recognition”, ICPR'00 - Volume 2, 2000.

[23] Object Management Group, “UML Profile for Schedulability, Performance, and

Time”, OMG document ptc/02-03-02, Needham MA, 2002.

[24] Olli S, Jaakko, “A Embedded Systems, Lecture Notes”, Helsinki University of

Tech, 2006.

[25] Peter Marweden, “Embedded Systems Design”, Springer, 2006.

[26] Qing Li and Carolyn Yao, “Real-time Concepts for Embedded Systems”, CMP

Books, 2003.

[27] Ray Smith, “An Overview of the Tesseract OCR Engine”, OSCON, 2007.

[28] Ray Smith, “A Simple and Efficient Skew Detection Algorithm via Text Row

Accumulation”, Proc of the 3rd Int, Conf. on Document Analysis and Recognition

(Vol. 2), IEEE 1995, pp 1145-1148.

[29] Richard Romero, Robert Berger, Robert Thibadeau, David Touretzky, “Neural

Network Classifiers for Optical Chinese Character Recognition”, In Proceedings of

the Fourth Annual Symposium on Document Analysis and Information Retrieval,

1995.

[30] Sacha Barber, “An introduction into Neural Networks”, 2003, pp 277-280.

[31] Sargur N. Srihari, Xuanshen Yang, Gregory R. Ball, “Offline Chinese

handwriting recognition: an assessment of current technology”, 2007.

[32] Stephen V. Rice, Frank R. Jenkins, Thomas. A. Nartker, “The Fourth Annual Test

of OCR Accuracy, Technical Report 95-03”, Information Science Research Institute,

University of Nevada, Las Vegas, July 1995.

[33] Stuart R.Ball, “Embedded Microprocessor Systems”, Newnes, 2002.



80

PHỤ LỤC

A. Một số ví dụ về các hệ thống nhúng

Trong phần này sẽ đưa ra ví dụ về các hệ thống nhúng khác nhau trong mọi lĩnh

vực đời sống của con người để chúng ta có thể thấy được sự phát triển mạnh mẽ của

những hệ thống loại này.

1. Máy in

Sử dụng nhiều loại vi xử lý: Intel,

Motorola, ARM 32 bit …)

2. Rô bốt thăm dò sao hoả của NASA

(Twin Mars Rovers)

Bộ xử lý: Radiation Hardened 20 Mhz

PowerPC

Sử dụng hệ điều hành thời gian thực

thương mại

3. Chó rô bốt (Sony Aibo ERS-7)

Bộ xử lý: 64-bit MIPS R7000

Sử dụng hệ điều hành thời gian thực

Aperios của Sony



81

4. Trạm tự kiểm tra của IBM (IBM self checkout station)

Bộ vi xử lý: X86

Hệ điều hành: Window Embedded

XP

Được sử dụng trong các cửa hàng

lớn

5. Tay Rô bốt công nghiệp (Kuka Industrial

Robot Arms)

Bộ vi xử lý: X86

Hệ điều hành: Window CE và những

HĐH khác

Được sử dụng trong các dây truyền lắp

ráp công nghiệp

6. Điện thoại thông minh (Motorola MOTO Q9h)

Bộ vi xử lý: TI OMAP (ARM + DSP)

Hệ điều hành: Window CE 6.0



82

B. Thống kê về những xu hƣớng trong thiết kế hệ thống nhúng

Phần này sẽ đưa ra những thống kê về xu hướng trong thiết kế hệ thống nhúng

tập trung vào các vấn đề chính như: Loại bộ vi xử lý nào được sử dụng? Hệ điều hành

gì được dùng? Dùng ngôn ngữ lập trình nào?. Dữ liệu thống kê được lấy từ cuộc khảo

sát thiết kế bởi EETimes và tạp chí thiết kế hệ thống nhúng 2006.

1. Những kiến trúc bộ vi xử lý đƣợc dùng rộng rãi

ARM

X86

MIPS

Xscale (ARM)

Renesas SuperH

PowerPC

Thống kê số lượng vi xử lý 32 & 64 bit được bán

2. Nhân hệ điều hành đƣợc sử dụng trong các thiết kế

Thống kê giữa hệ điều hành thương mại và những loại khác

0.00% 5.00% 10.00% 15.00% 20.00% 25.00% 30.00% 35.00% 40.00%

PowerPC

SuperH

MIPS

X86

ARM

Processor Sales Volume

0.00% 5.00% 10.00% 15.00% 20.00% 25.00% 30.00% 35.00% 40.00% 45.00%

Open Source

Internally Developed

None

Commercial OS



83

Thống kê giữa các hệ điều hành thương mại

3. Ngôn ngữ lập trình đƣợc sử dụng trong xây dựng ứng dụng nhúng

Thống kê các ngôn ngữ lập trình sử dụng

0.00% 5.00% 10.00% 15.00% 20.00% 25.00% 30.00%

Others

Palm

Green Hills

Symbian

Wind River

Microsoft Emb.

0.00% 10.00% 20.00% 30.00% 40.00% 50.00% 60.00% 70.00%

Others

Assembly

Java

C#

C++

C

phÂn tÍch, thiẾt kẾ phẦ Ềm nhÚngstorage.sharetailieu.net/data/20190402/v_l0_01819... ·...

Documents