Giáo trình Hệ thống nhúng (Phần 1)

n phần mềm cho hệ nhúng. Các bộ biên dịch chéo 
thường có thể cấu hình để thực thi việc chuyển đổi cho nhiều nền phần cứng khác 
nhau một cách linh hoạt. Và việc lựa chọn cấu hình biên dịch tương ứng với các 
nền phần cứng đôi khi cũng khá độc lập với chương trình ứng dụng của bộ biên 
dịch. 
Kết quả đầu tiên của quá trình biên dịch nhận được là một dạng mã lệnh 
được biết tới với tên gọi là tệp đối tượng (object file). Nội dung của tệp đối tượng 
này có thể được xem như là một cấu trúc dữ liệu trung gian và thường được định 
nghĩa như một định dạng chuẩn COFF (Common Object File Format) hay định 
dạng của bộ liên kết mở rộng ELF (Extended Linker Format) Nếu sử dụng nhiều 
bộ biên dịch cho các modul mã nguồn của một chương trình lớn thì cần phải đảm 
bảo rằng các tệp đối tượng được tạo ra phải có chung một kiểu định dạng. 
Hầu hết nội dung của các tệp đối tượng đều bắt đầu bởi một phần header để 
mô tả các phần theo sau. Mỗi một phần sẽ chứa một hoặc nhiều khối mã hoặc dữ 
liệu như được sử dụng trong tệp mã nguồn. Tuy nhiên các khối đó được nhóm lại 
bởi bộ biên dịch vào trong các phần liên quan. Ví dụ như tất cả các khối mã được 
nhóm lại vào trong một phần được gọi là text, các biến toàn cục đã được khởi tạo 
(cùng các giá trị khởi tạo của chúng) vào trong phần dữ liệu, và các biến toàn cục 
chưa được khởi tạo vào trong phần bss. 
Cũng khá phổ biến thường có một bảng biểu tượng chứa trong nội dung của tệp 
đối tượng. Nó chứa tên và địa chỉ của tất cả các biến và hàm được tham chiếu trong 
tệp mã nguồn. Các phần chứa trong bảng này không phải lúc nào cũng đầy đủ vì 
có một số biến và hàm được định nghĩa và chứa trong các tệp mã nguồn khác. 
Chính vì vậy cần phải có bộ liên kết để thực thi xử lý vấn đề này. 
• Quá trình liên kết (Linking): 
Chương 2. Các thành phần của một hệ thống nhúng 
 26 
Tất cả các tệp đối tượng nhận được sau bước thực hiện biên dịch đầu tiên đều 
phải được tổ hợp lại theo một cách đặc biệt trước khi nó được nạp và chạy ở trên 
môi trường phần cứng đích. Như đã thấy ở trên, bản thân các tệp đối tượng cũng 
có thể là chưa hoàn thiện vì vậy bộ liên kết phải xử lý để tổ hợp các tệp đối tượng 
đó với nhau và hoàn thiện nốt phần còn khuyết cho các biến hoặc hàm tham chiếu 
liên thông giữa các tệp mã nguồn được biên dịch độc lập. 
Kết quả đầu ra của bộ liên kết là một tệp đối tượng mới có chứa tất cả mã và 
dữ liệu trong tệp mã nguồn và cùng kiểu định dạng tệp. Nó thực thi được điều này 
bằng cách tổ hợp một cách tương ứng các phần text, dữ liệu và phần bss từ các 
tệp đầu vào và tạo ra một tệp đối tượng theo định dạng mã máy thống nhất. Trong 
qúa trình bộ liên kết thực hiện tổ hợp các phần nội dung tương ứng nó còn thực 
hiện thêm cả vấn đề hoàn chỉnh các địa chỉ tham chiếu của các biến và hàm chưa 
được đầy đủ trong bước thực hiện biên dịch. 
Các bộ liên kết có thể được kích hoạt thực hiện độc lập với bộ biên dịch và 
các tệp đối tượng được tạo ra bởi bộ biên dịch được coi như các tham biến vào. 
Đối với các ứng dụng nhúng nó thường chứa phần mã khởi tạo đã được biên dịch 
cũng phải được gộp ở trong danh sách tham biến vào này. 
Nếu cùng một biểu tượng được khai báo hơn một lần nằm trong một tệp đối 
tượng thì bộ liên kết sẽ không thể xử lý. Nó sẽ kích hoạt cơ chế báo lỗi để người 
phát triển chương trình xem xét lại. Hoặc khi một biểu tượng không thể tìm được 
địa chỉ tham chiếu thực trong toàn bộ các tệp đối tượng thì bộ liên kết sẽ cố gắng 
tự giải quyết theo khả năng cho phép dựa vào các thông tin ví dụ như chứa trong 
phần mô tả của thư viện chuẩn. Điều này cũng thường hoặc có thể gặp với trường 
hợp các hàm tham chiếu trong chương trình. 
Rất đáng tiếc là các hàm thư viện chuẩn thường yêu cầu một vài thay đổi 
trước khi nó có thể được sử dụng trong chương trình ứng dụng nhúng. Vấn đề ở 
đây là các thư viện chuẩn cung cấp cho các bộ công cụ phát triển chỉ dừng đến khả 
năng định dạng và tạo ra tệp đối tượng. Hơn nữa chúng ta cũng rất ít khi có thể 
truy nhập được vào mã nguồn của các thư viện chuẩn để có thể tự thay đổi. Hiện 
nay cũng có một số nhà cung cấp dịch vụ phần mềm hỗ trợ công cụ chuyển đổi 
hay thay đổi thư viện C chuẩn để ứng dụng cho các ứng dụng nhúng, ví dụ như 
Cygnus. Gói phần mềm này được gọi là newlib và được cung cấp miễn phí. Chúng 
ta có thể tải về trang web của Cygnus. Nó sẽ hỗ trợ chúng ta giải quyết vấn đề mà 
bộ liên kết có thể gặp phải khi chương trình sử dụng các hàm thuộc thư viện C 
chuẩn. 
Sau khi đã hợp nhất thành công tất cả các thành phần mã và phần dữ liệu tương 
ứng cũng như các vấn đề về tham chiếu tới các biểu tượng chưa được thực thi trong 
quá trình biên dịch đơn lẻ, bộ liên kết sẽ tạo ra một bản sao đặc biệt của chương 
trình có khả năng định vị lại (relocatable). Hay nói cách khác, chương trình được 
hoàn thiện ngoại trừ một điều: Không có địa chỉ bộ nhớ nào chưa được gán bên 
trong các phần mã và dữ liệu. Nếu chúng ta không phải là đang phát triển phần 
Chương 2. Các thành phần của một hệ thống nhúng 
 27 
mềm cho hệ nhúng thì quá trình biên dịch có thể kết thúc tại đây. Tuy nhiên, với 
hệ nhúng ngay cả hệ thống nhúng đã bao gồm cả hệ điều hành chúng ta vẫn cần 
phải có một mã chương trình (image) nhị phân được định vị tuyệt đối. Thực tế nếu 
có một hệ điều hành thì phần mã và dữ liệu cũng thường gộp cả vào bên trong 
chương trình có khả năng định vị lại. Toàn bộ ứng dụng nhúng bao gồm cả hệ điều 
hành thường liên kết tĩnh với nhau và thực hiện như một mã chương trình nhị phân 
thống nhất. 
• Quá trình định vị (Locating) 
Công cụ thực hiện việc chuyển đổi một chương trình có khả năng định vị lại 
thành một dạng mã chương trình nhị phân có thể thực thi được gọi là bộ định vị. 
Nó sẽ đảm nhiệm vai trò của bước đơn giản nhất trong các bước thực thi biên dịch 
nói chung. Thực tế chúng ta phải tự làm hầu hết công việc của bước này bằng cách 
cung cấp thông tin về bộ nhớ đã được cấu hình trên nền phần cứng mà chúng ta 
đang phát triển và đó chính là tham số đầu vào cho việc thực thi của bộ định vị. Bộ 
định vị sẽ sử dụng thông tin này để gán các địa chỉ vật lý cho mỗi phần mã lệnh và 
dữ liệu bên trong chương trình được thực thi mà có thể định vị lại. Tiếp theo nó sẽ 
tạo ra một tệp có chứa chương trình bộ nhớ nhị phân để có thể nạp trực tiếp vào 
bộ nhớ chương trình trên nền phần cứng thực thi. 
Trong nhiều trường hợp bộ định vị là một chương trình khá độc lập với các 
phần công cụ khác trong hệ thống phần mềm phát triển. Tuy nhiên trong các bộ 
công cụ phát triển GNU chức năng này được tích hợp luôn trong bộ liên kết. Tuy 
nhiên không nên nhầm lẫn về chức năng của chúng trong quá trình thực thi biên 
dịch. Thông thường chương trình chạy trên các máy tính mục đích chung thì hệ 
điều hành sẽ thực hiện việc chuyển đổi và gán chính xác địa chỉ thực cho các phần 
mã và dữ liệu trong chương trình ứng dụng, còn với chương trình phát triển chạy 
trên hệ nhúng thì việc này phải được thực hiện bởi bộ định vị. Đây cũng chính là 
điểm khác biệt cơ bản khi thực hiện biên dịch một chương trình ứng dụng cho hệ 
nhúng. 
Thông tin về bộ nhớ vật lý của hệ thống phần cứng phát triển mà cần phải 
cung cấp cho bộ định vị GNU phải được định dạng theo kiểu biểu diễn của bộ liên 
kết. Thông tin này đôi khi được sử dụng để điều khiển một cách chính xác thứ tự 
trong các phần mã chương trình và dữ liệu bên trong chương trình có thể định vị 
lại. Nhưng ở đây chúng ta cần phải thực hiện nhiều hơn thế, tức là phải thiết lập 
chính xác khu vực của mỗi phần trong bộ nhớ. 
2.4. CÂU HỎI VÀ BÀI TẬP 
1. Nêu các thành phần phần cứng thường có trong một hệ thống nhúng. 
2. Bộ vi xử lý có thể đƣợc tổ chức theo những kiến trúc nào, đặc điểm của mỗi 
loại kiến trúc đó. 
3. Nêu cấu trúc, nguyên lý hoạt động và các loại bộ nhớ Ram. 
4. Nêu cấu trúc, nguyên lý hoạt động và các loại bộ nhớ Rom. 
Chương 2. Các thành phần của một hệ thống nhúng 
 28 
5. Trình bày phương pháp quản lý bộ nhớ trong hệ thống nhúng. 
6. Nêu sự khác nhau giữa vào ra nối tiếp và vào ra song song. 
7. Phân tích đặc điểm, vị trí và chức năng của hệ thống BUS. 
8. Trình bày về hệ điều hành trong hệ thống nhúng. 
9. Trình bày về trình điều khiển thiết bị. 
10. Trình bày về trình điều khiển ngắt. 
11. Trình bày về trình điều khiển bộ nhớ. 
12. Trình bày về trình điều khiển bus. 
Chương 3. Thiết kế và cài đặt hệ thống nhúng 
 29 
CHƯƠNG 3. XÂY DỰNG HỆ THỐNG NHÚNG 
Để xây dựng hệ thống embedded Linux, chúng ta phải trải qua nhiều công 
đoạn. Nếu đi đúng hướng thì chúng ta có thể rút ngắn nhiều thời gian. Công đoạn 
thiết kế chia ra thành 2 phần, bao gồm phần cứng và phần mềm. Nếu là cá nhân thì 
có thể làm tuần tự từ hardware đến software, nếu làm việc theo nhóm thì có thể đi 
song song. Một điều quan trọng đối với kỹ sư phần cứng là: thiết kế phải thỏa mãn 
mối tương quan giữa phần cứng và phần mềm. Có nghĩa là giữa hardware và 
software phải được đồng bộ trong quá trình thiết kế. Nếu kỹ sư phần cứng có thêm 
1 chút kiến thức nhất định về phầm mềm thì công việc sẽ tiến triển thuận lợi hơn, 
và ngược lại, kỹ sư phần mềm biết chút ít về phần cứng thì việc viết các chương 
trình ứng dụng sẽ trở nên trôi chảy. 
3.1. CÁC BƯỚC XÂY DỰNG PHẦN CỨNG 
3.1.1. Lựa chọn kiến trúc CPU 
Có rất nhiều kiến trúc CPU được support bởi Linux OS ví dụ như: ALPHA, 
ARM, SH, MIP, POWER PC... Tuy nhiên, chúng ta sẽ tập trung kiến trúc ARM. 
Hình 3.1 ARM’s Opportunity 
3.1.2. Lựa chọn CPU vendor 
Sau khi lựa chọn cấu trúc CPU, ta sẽ lựa chọn sản phẩm CPU từ các nhà 
sản xuất chíp. Hiện nay trên thế giới có nhiều hãng khác nhau, bao gồm: TI, 
SAMSUNG, Marvell, Freescale, NXP, ATMEL... Theo mình thì chúng ta nên khởi 
đầu với sản phẩm của hãng nào có cộng đồng phát triển mã nguồn mở mạnh, có 
khả năng cấp tài liệu miễn phí (bao gồm cho cá nhân thay vì chỉ dành riêng cho 
công ty, doanh nghiệp). Việc lựa chọn này có ảnh hưởng đến khả năng thành công 
của dự án. 
3.1.3. CPU được support bởi hệ điều hành nào 
Sau khi lựa chọn CPU vendor, chúng ta sẽ có được danh sách CPU trong 1 
dòng sản phẩm. Điều đầu tiên ta cần xác định rõ CPU này được hỗ trợ bởi hệ điều 
hành nào, và có phù hợp với hệ điều hành mà chúng ta cần phát triển hay không. 
Ví dụ cho hệ điều hành Linux: CPU cần có MMU (Memory Management Unit) và 
Chương 3. Thiết kế và cài đặt hệ thống nhúng 
 30 
hỗ trợ bus bộ nhớ ngoài. Ngoài ra chúng ta cần xem xét đến tốc độ CPU, các ngoại 
vi cần phải có trong hệ thống... Và cuối cùng là giá thành của CPU như thế nào, 
có sẵn trên thị trường hay không. 
3.1.4. Tìm hiểu đặc tả, cơ chế boot của CPU 
Hình 3.2 Components of a Typical Embedded System 
Công việc đầu tiên của kỹ sư thiết kế hardware sẽ không loại trừ việc đọc 
datasheet và tìm hiểu các tài liệu đặc tả cho CPU này: 
+ Cấu hình chân của CPU (package type): Cái này rất quan trọng đối với 
trường hợp VN chúng ta. Năng lực sản xuất PCB trong nước là có hạn, vì thế việc 
lựa chọn cấu hình chân CPU sẽ trở nên khó khăn và eo hẹp hơn. 
+ Cơ chế boot của CPU: Trước tiên xâu dựng dự án, cơ chế boot của CPU 
là phần cực kỳ quan trọng mà chúng ta cần phải xem xét đến. Thông thường thì 
các đặt tả từ nhà sản xuất đề cập đến vấn đề này. Khi có đầy đủ thông tin về cơ chế 
này, người thiết kế phần cứng sẽ có quyết định lựa chọn linh kiện nào phù hợp cho 
từng kiểu boot. Ví dụ: NAND Flash, NOR FLash, SPI Dataflash, I2C EEPROM, 
MMC... 
3.1.5. Xây dựng sơ đồ nguyên lý cho hệ thống 
Để có được schematic hoàn chỉnh cho hệ thống, chúng ta cần tập hợp thông 
tin từ các CPU vendor càng nhiều càng tốt, bao gồm các tài liệu về schematic check 
list, CPU user manual, design application note... 
3.1.6. Thiết kế PCB 
Công đoạn thiết PCB tốn nhiều công sức, khi layout cần chú ý đến các 
đường bus giao tiếp bộ nhớ ngoài, các tụ trở mạch lọc cho PLL, các tụ lọc nguồn 
cho CPU. 
Chương 3. Thiết kế và cài đặt hệ thống nhúng 
 31 
Hình 3.3 The board CAD layout with layers merged 
3.2. CÁC BƯỚC XÂY DỰNG PHẦN MỀM 
Tương tự phần cứng, việc xây dựng phần mềm cũng được chia ra nhiều công 
đoạn: 
3.2.1. Cài đặt boot loader 
Thông thường các hãng sản xuất chíp cung cấp cho chúng ta mã nguồn, công 
cụ để xây dựng boot loader. Đa số các CPU được sản xuất với ROM on chip và 
được cài sẵn chương trình boot. Tuy nhiên, thông thường những chương trình này 
ko đủ khả năng boot được Linux OS, người thiết kế hệ thống cần phải kết hợp 
chương trình này với các thiết bị lưu trữ (được nêu ở trên) để thực hiện những 
chương trình boot có tính năng mạnh hơn. Tùy vào loại CPU khác nhau mà ta phải 
trải qua 2 hay 3 tầng boot loader để khởi động được Linux OS. Ví dụ như MPU 
AT91SAM9 của ATMEL có 3 tầng bootloader: ROM boot ---> AT91BootStrap -
---> u-boot. 
Chương 3. Thiết kế và cài đặt hệ thống nhúng 
 32 
Hình 3.4 Boot sequence 
3.2.2. Cài đặt Linux OS (porting) 
Thành phần nồng cốt của Linux OS là kernel, về bản chất nó chỉ là các mã 
lệnh chương trình thực thi trên CPU. Tuy nhiên, kernel giữ vai trò quản lý các tiến 
trình hoạt động trong hệ thống. Kernel Linux được xây dựng bởi code C và một số 
ASM cho từng loại kiến trúc CPU cụ thể. Source code của kernel được quản lý bởi 
tổ chức phát triển mã nguồn mở Linux, chúng ta có thể download miễn phí 
tại www.kernel.org. Tuy nhiên, khi ta xây dựng phần cứng mới thì không hẳn có 
thể chạy được Linux OS, bởi vì can phải đảm bảo mối tương quan giữa phần cứng 
và kernel. Thông thường các CPU vendor xây dựng phần cứng chuẩn được gọi là 
evaluation kit. Họ sẽ chỉnh sửa source kernel (startup code, driver...) để board có 
thể vận hành được Linux OS. Thao tác này theo thuật ngữ người ta gọi là porting. 
Kết quả của việc porting tạo ra các bản vá (patch). 
3.2.3. Phát triển driver 
Source kernel Linux bao gồm tập hợp các driver đã viết sẵn và được chuẩn 
hóa thành tài liệu. Tuy nhiên, người phát triển có thể tự viết driver cho riên mình 
để phù hợp với nhu cầu của dự án. Linux kernel hỗ trợ cho việc phát triển driver 
theo 2 dạng: built-in hoặc là module. 
3.2.4. Xây dựng root file system (rootfs) 
Khung sườn của hệ điều hành Linux là rootfs. Đây là tập hợp những chương 
trình ứng dụng, các tiện ích của hệ điều hành. Chúng ta có thể xây dựng rootfs từ 
nhiều nguồn khác nhau: OpenEmbedded (Angstrom), LTIB, Buildroot, Debian... 
3.2.5. Phát triển phần mềm ứng dụng 
Chương 3. Thiết kế và cài đặt hệ thống nhúng 
 33 
Linux OS cung cấp cho chúng ta tập hợp thư viện rất phong phú cho nhiều 
lĩnh vực khác nhau: mạng, đồ họa, image processing, telecom... Người phát triển 
phần mềm sẽ dùng những thư viện này và viết chương trình theo mong muốn. 
Hình 3.5 Architecture of the GNU/Linux operating system 
3.3. CÂU HỎI VÀ BÀI TẬP 
1. Liệt kê các bước trong quá trình thiết kế hệ thống nhúng 
2. Mô tả các bước trong quá trình thiết kế hệ thống nhúng 
3. Liệt kê các bước trong quá trình cài đặt và thử nghiệm hệ thống nhúng 
4. Mô tả các bước trong quá trình cài đặt và thử nghiệm hệ thống nhúng