1. Nội dung thiết kế tốt nghiệp:
4.2.3 Các lệnh giao tiếp SDcard
Có ba chế độ giao tiếp Sdcard là: chế độ SD 1bit – 4bit và chế độ SPI.
Trong đề tài sử dụng chế độ SPI gồm một đường data, một đường clock, một đường command giao tiếp với vi xử lý Nios2.
Cấu trúc một lệnh gồm 6 byte được truyền nhận trên đường Command (Bảng 4.4). Bảng 4.4 Cấu trúc 1 command [9] 1 1 6 32 7 1 Start bit always 0 Host Always 1
CMD Argument CRC-7 Stop bit always 1.
CRC-7: Với mỗi lệnh Command được truyền đi đều có 7 bit CRC-7, có tác dụng
như mã chống lỗi cho mỗi gói dữ liệu đó. Ngoài ra với mỗi Sector dữ liệu trên đường data cũng có mã chống lỗi 16 bit CRC-16.
Argument: với mỗi lệnh khác nhau thì thành phần 32 bit này có vai trò là những
tham số có tác dụng khác nhau.
68
Một số lệnh thường sử dụng:
Command 0 (Go_IDLE_STATE): Đưa thẻ nhớ về trạng thái chờ Idle.
Command 1 (ALL_SEND_ORC): Yêu cầu thẻ gửi thông tin của thanh ghi OCR.
Command 2 (ALL_SEND_CID): Yêu cầu thẻ gửi ID-Cards. Thông tin trả về sẽ trong gói response của thẻ.
Command 3 (SEND_RELATIVE_ADDR): Yêu cầu thẻ gửi địa chỉ phản tương đối về host (2 bytes).
Command 7: Chuyển Card về chế độ Transfer Mode. Command 9: Lấy thông tin thanh ghi CSD.
Command 55 (APP_CMD): Trước mỗi command đặc biệt ACMD ta phải gửi trước lệnh này.
Command 17 (BLOCK_READ): Đọc một block dữ liệu (sector 512 bytes). Command 24 (BLOCK_WRITE): Ghi một block dữ liệu (sector 512 bytes).
Thông thường mỗi lệnh hay gói dữ liệu sẽ có response trả về với các cấu trúc reponse và độ dài khác nhau tùy theo mỗi lệnh.
Danh sách các lệnh giao tiếp SD card trong chuẩn SPI được nêu cụ thể ở Bảng 4.5.
69
Bảng 4.5 Danh sách lệnh SD card trong chuẩn SPI [18]
4.2.4 Một số thủ tục với SD card
Dưới đây, nhóm tác giả sẽ giới thiệu một số thủ tục với SD card mà hệ thống sử dụng.
Initialization: Quá trình khởi tạo thẻ nhớ SD được minh họa trên Hình 4.4
Hình 4.4 Quá trình khởi tạo thẻ nhớ SD
Response(R3) ? STA RT Set Input/ Output IO Send CMD 0 Send CMD 55 Send ACMD 41 Send CMD 2 Send CMD 3
70
Đầu tiên HOST sẽ gửi lệnh CMD 0 để tạo trạng thái chờ lệnh IDLE cho Card. Tiếp theo gửi lệnh CMD 55 để gửi lệnh đặc biệt ACMD41, có tác dụng kiểm tra mức điện áp của Card và quá trình khởi tạo của card hoàn thành chưa? Bằng cách nhận gói tin phản hồi (R3) thông tin thanh ghi OCR về trạng thái Card.
Sau đó, Host gửi CMD 2 để lấy thông tin về Card trong thanh ghi CID (phản hồi R2).
Sau khi có thông tin nhận dạng Card (Identification Information), CMD3 được gửi đi để lấy địa chỉ của tương đối của Card “RCA” (Relative Address) sử dụng cho quá trình truyền nhận dữ liệu.
Data tranfer mode: quá trình chuyển chế độ data tranfer được minh họa trên Hình 4.5.
Hình 4.5 Quá trình chuyển chế độ data tranfer
Lệnh CMD 9 với tham số có địa chỉ tương đối của Card và Respone dạng R2 trả về giá trị thanh ghi CSD để lấy thông tin như độ dài block.
Lệnh CMD 7 với tham số có địa chỉ tương đối của Card, kết nối trực tiếp giữa host và thẻ được chọn, chuyển chế độ Card thành chế độ Tranfer mode.
Lệnh CMD 16 xác định độ dài block truyền đi phù hợp với tham số.
Read a block: quá trình đọc 1 block trong SD card được minh họa trên Hình 4.6.
Hình 4.6 Quá trình đọc 1 block trong SD card
Send CMD 17
Data ready?
Read data 512*8 bit
Send 16 Pulse CLK Send CMD 9 Send CMD 7 Send CMD 16
71
Lệnh đọc 1 block CMD 17 với tham số 32 bit chỉ ra địa chỉ vật lý của byte đầu tiên của block 512 bytes cần đọc.
Quá trình đọc được bắt đầu khi có dữ liệu trên đường DATA và được đồng bộ bởi tín hiệu trên đường CLK, sau khi đọc xong host sẽ gửi 16 xung CLK delay để chờ tín hiệu trên đường DATA kết thúc.
4.3 Giao tiếp flash USB
Hệ điều hành nhúng uClinux được sử dụng trong hệ thống với những tùy biến hỗ trợ đa dạng trong việc giao tiếp với các ngoại vi hay những phần mềm ứng dụng, việc giao tiếp với flash USB đã trở nên dễ dàng và nhanh chóng hơn.
Kit DE2 cung cấp giao tiếp USB Host và Device, sử dụng chip điều khiển USB ISP-1362 (Hình 4.7).Với chuẩn USB 2.0, hỗ trợ truyền dữ liệu ở 2 chế độ là full- speed (12 Mbit/s) và low-speed (1.5 Mbit/s).
Hình 4.7 Giao tiếp giữa khối vi xử lý và chip ISP 1362 [15]
ISP-1362 có thể được lập trình từ vi xử lý, hai tín hiệu yêu cầu ngắt là INT1 cho ngắt chế độ Host, INT2 dùng cho ngắt chế độ Device.
Vi xử lý có thể điều khiển giao tiếp với chức năng như là một Host, Device hay OTG (On-The-Go) thông qua bốn thanh ghi giao tiếp:
Device Controller command (dc_com) Device Controller data (dc_data) Host Controller command (hc_com) Host Controller data (hc_data)
72
Việc lựa chọn các thanh ghi trên dựa vào tín hiệu A0 và A1 của chip. Mỗi thanh ghi trên có thể được truy cập theo địa chỉ và tín hiệu A0, A1 (Bảng 4.6).
Bảng 4.6 Địa chỉ thanh ghi ISP-1362 [15]
Ngoài ra, ISP-1362 có tổng cộng 4 KB buffer chia làm bốn phần sử dụng với mục đích khác nhau và cũng có thể ghi/đọc như đối với các thanh ghi nói trên. Sơ đồ khối các thành phần của ISP 1362 được mô tả trên Hình 4.8.
73
Lập trình cho ISP1362 có thể chia làm hai dạng là: Ghi/đọc 8 hoặc 16 bit.
Ghi/đọc 32 bit.
Với ghi đọc 8/16 bit, quá trình chia làm hai giai đoạn: command và data. Trong quá trình command, lệnh cụ thể được ghi vào cổng thanh ghi command. Trong quá trình data, dữ liệu yêu cầu được ghi vào / đọc ra từ cổng thanh ghi data.
Hình 4.9 Chu kì truy cập thanh ghi 32 bit mode
Với ghi đọc 32 bit, quá trình chia làm ba giai đoạn: command, first data, second data. Sau khi lệnh được ghi vào thanh ghi command, 2 word 16 bit sẽ được ghi vào/ đọc ra từ cổng thanh ghi data (word thấp được truy cập trước). Hình 4.10 biểu diễn hàm ghi đọc dữ liệu 32 bit.
74
4.4 Cấu hình sử dụng flash USB và thẻ nhớ SD với uClinux
Để sử dụng giao tiếp hệ điều hành nhúng với thiết bị flash USB, các module software cần thiết phải cấu hình trong hệ điều hành như: Host controller driver (cho ISP-1362), Mass storage, định dạng FAT và một số ứng dụng để mount phân vùng nhớ. Với kiến trúc software trên hệ điều hành có tính module hóa cao, việc cấu hình trở nên đơn giản mà không cần viết thêm chương trình người sử dụng nào khác. Hình 4.11 mô tả về cấu trúc phân tầng software cho giao tiếp USB.
Hình 4.11 Kiến trúc phân tầng software cho giao tiếp USB
Với việc sử dụng các lớp ứng dụng, thư viện sẵn có để giao tiếp với thẻ nhớ SD khiến cho việc giao tiếp và đọc dữ liệu video trở nên chậm và không đáp ứng kịp về tốc độ, nên thẻ nhớ sẽ được giao tiếp bởi chương trình người sử dụng thông qua chuẩn giao tiếp đã tìm hiểu ở trên. Tuy nhiên, trong báo cáo này vẫn trình bày về việc tích hợp thẻ nhớ trong hệ điều hành uClinux.
4.4.1 Tích hợp driver USB (ISP1362) [19]
75
Chúng ta thay thế component ISP1362 bằng component mới tạo từ file ISP1362_CTRL.v. Ta thêm component vừa tạo vào hệ thống, đặt tên chính xác là “ISP1362” rồi genarate lại SOPC và biên dịch lại project. [19]
Ta sửa file linux-2.6/drivers/usb/host/isp1362-hcd.c để bỏ qua đoạn skip check clock timeout 100ns.
static int isp1362_hc_reset(struct usb_hcd *hcd) {
int ret = 1;
struct isp1362_hcd *isp1362_hcd = hcd_to_isp1362_hcd(hcd); return ret;
}
Tiếp theo, chúng ta cấu hình make menuconfig để tích hợp driver USB như hướng dẫn trong tài liệu tham khảo [19]. Sau khi cấu hình xong, ta tiến hành biên dịch lại kernel, nạp file zImage xuống kit. Khi boot kernel, hệ điều hành uClinux sẽ tự nhận USB được cắm vào kit như mô tả trên Hình 4.12.
Hình 4.12 Đọc file text trong USB
Ta thực thi lệnh để mount USB vào phân vùng tạm thời /mnt:
76
Sau khi USB đã mount thành công, ta thực thi lệnh để đọc file text đã được lưu sẵn trong USB:
cat filename.txt
Kết quả đọc file được mô tả trên Hình 4.12. File hung.txt có nội dung “abcdef” đã được đọc ra màn hình.
4.4.2 Tích hợp SD card (SPI) [20]
Quá trình tích hợp driver cho thẻ nhớ SD gồm các bước như sau:
Như hướng dẫn tài liệu tham khảo [20], chúng ta thêm component SPI (3 wire serial) vào hệ thống rồi generate lại SOPC.
Để nối chân của component SPI vừa thêm vào, ta thêm các dòng sau vào nios2 port map trong file top entity của project.
.MISO_to_the_mmc_spi (SD_DAT), .MOSI_from_the_mmc_spi (SD_CMD), .SCLK_from_the_mmc_spi (SD_CLK), .SS_n_from_the_mmc_spi (SD_DAT3),
Tiếp theo, chúng ta cấu hình menuconfig để tích hợp driver cho thẻ SD như hướng dẫn tại tài liệu tham khảo [20]. Sau khi cấu hình xong, ta tiến hành biên dịch lại kernel, nạp file zImage xuống KIT. Khi boot kernel, hệ điều hành uClinux sẽ tự nhận thẻ SD khi cắm vào KIT. Quá trình đọc file text lưu sẵn trong thẻ nhớ SD được mô tả ở Hình 4.13.
77
Ta thực thi lệnh để mount thẻ SD vào phân vùng tạm thời /mnt:
mount –t vfat /dev/mmcblk0p1 /mnt
Sau khi thẻ SD đã được mount thành công, ta thực thi lệnh để đọc file text đã được lưu sẵn trong thẻ:
cat filename.txt
Kết quả đọc file được mô tả trên Hình 4-13, file hung.txt lưu trong thẻ nhớ có nội dung “abcdef” đã được đọc ra.
4.5 Kết luận
Sau khi tìm hiểu kỹ càng cấu trúc và giao thức hoạt động của thẻ nhớ SD cũng như USB, nhóm tác giả đã tích hợp thành công các driver này vào hệ điều hành uClinux. Hệ thống đã có thể điều khiển các thiết bị lưu trữ này một cách thành công.
78
Chƣơng 5. Truyền video từ PC xuống kit FPGA
qua mạng LAN
_* Nguyễn Văn Khánh *_ Chương này trình bày chức năng nhận một video được mã hóa theo chuẩn MJPEG truyền từ máy tính xuống hệ thống Nios II qua cổng giao tiếp Ethernet. Giao thức được dùng để truyền dữ liệu là giao thức truyền file thời gian thực RTP (Real- time Transport Protocol). Do hệ thống được tích hợp bộ giải mã JPEG bằng phần cứng nên tốc độ xử lý sẽ cao hơn khi giải mã bằng phần mềm. Đồng thời, video được nén theo chuẩn MJPEG, tuy chưa phải là chuẩn nén tối ưu nhưng cũng góp phần làm giảm dung lượng dữ liệu cần truyền đi. Mô hình truyền video được mô tả trong Hình 5.1 dưới đây.
MJPEG video
Hình 5.1 Quá trình truyền video từ PC xuống kit 5.1 Lý do lựa chọn giao thức
Về cơ bản, việc truyền dữ liệu từ PC xuống kit có thể thực hiện bằng nhiều giao thức khác nhau: UDP, TCP, RTSP, RTP...Tuy nhiên, xuất phát từ mục đích của đề tài: Xây dựng một hệ thống có khả năng hiển thị dữ liệu video được streaming trực tiếp từ máy tính, để đảm bảo việc hiển thị hình ảnh diễn ra liên tục giao thức được sử dụng phải dựa trên giao thức UDP. Do UDP không yêu cầu truyền lại gói tin bị lỗi mà bỏ qua gói đó tiếp tục truyền gói tiếp theo. Hình ảnh hiển thị sẽ không bị ảnh hưởng nhiều nếu số gói bị mất là nhỏ. Ngược lại, với TCP khi có một gói lỗi, thì gói
79
tin đó sẽ được truyền lại cho đến khi bên nhận thu được thành công gói đó. Điều này có thể làm gián đoạn việc hiển thị video.
RTP là giao thức được thực hiện dựa trên nền UDP thích hợp cho việc truyền dữ liệu end to end, real-time, streaming data. Ngoài ra RTP còn hỗ trợ truyền dữ liệu đến nhiều điạ chỉ đích khác nhau qua chế độ phát multicast. Đây là một đặc tính rất quan trọng khi muốn mở rộng hướng phát triển của đề tài, video sẽ được hiển thị ở các khung hình có kích thước khác nhau: 640x480, 1024x768...(mỗi một khung hình này sẽ gồm nhiều bảng LED nhỏ ghép lại, và mỗi một bảng LED sẽ tương ứng với một địa chỉ IP riêng biệt) hoặc cùng một nội dung video nhưng sẽ được hiển thị trên nhiều màn hình.
Chính vì những lý do trên nên nhóm tác giả quyết định lựa chọn RTP là giao thức truyền dữ liệu qua mạng LAN sử dụng trong đồ án.
5.2 Lý thuyết cơ sở về giao thức RTP 5.2.1 Tổng quan về giao thức 5.2.1 Tổng quan về giao thức
RTP là một chuẩn định dạng gói, sử dụng cho việc truyền dữ liệu audio/video qua mạng IP, được phát triển bởi nhóm Audio/Video Transport của IETF (Internet Engineering Task Force). RTP thường được kết hợp sử dụng với các giao thức khác: RTSP, H.323… Chuẩn định dạng này cũng được sử dụng rộng rãi trong các hệ thống truyền thông và giải trí đa phương tiện: điện thoại, truyền hình hội nghị (video conference) và các ứng dụng push-to-talk dựa trên nền tảng web.
Các thành phần của giao thức [10]:
Giao thức truyền dữ liệu thời gian thực được thực hiện qua hai giao thức con RTP và RTCP (Real-time Transport Control Protocol).
RTP: thực hiên truyền dữ liệu thời gian thực. Giao thức này sẽ cung cấp các
thông tin liên quan đến thời gian lấy mẫu (cho việc đồng bộ hóa), số thứ tự gói tin (cho việc phát hiện ra tổn thất và tái sắp xếp lại các gói tin) và định dạng của payload (cho phép chỉ ra định dạng mã hóa của dữ liệu).
80
RTCP: Giao thức điều khiển RTP, dùng để xác định các phản hồi về QoS
(chất lượng dịch vụ ) và việc đồng bộ hóa giữa các luồng dữ liệu. Băng thông của RTCP chỉ chiếm một phần nhỏ so với băng thông của RTP, khoảng 5%.
Ngoài ra, trong giao thức còn có thêm một số các giao thức báo hiệu tùy chọn (H.323. MGCP, Megaco, SCCP, SIP).
Phiên làm việc:
Một phiên RTP sẽ đựợc tạo ra tương ứng với một luồng dữ liệu đa phương tiện (video/audio). Trong mỗi phiên thường bao gồm một địa chỉ IP và hai địa chỉ cổng giành cho RTP và RTCP. (Địa chỉ cổng của RTP là cổng chẵn và cổng RTCP là cổng lẻ tiếp theo.) Ví dụ cổng RTP là 9012 thì cổng RTCP là 9013.
RTP và RTCP thường sử dụng các cổng UDP không có đặc quyền, nằm trong khoảng từ 1024 đến 65535.
5.2.2 Các định dạng của Payload và Profile [10]
Một điểm đáng chú ý trong thiết kế của RTP: hỗ trợ nhiều định dạng đa phương tiện (như H264, MPEG4, MJPEG, MPEG ..) đồng thời cho phép bổ sung các định dạng mới mà không cần thay đổi lại các tiêu chuẩn trước đó. RTP được thiết kế dựa trên kiến trúc “phân khung mức ứng dụng” ALF (Application Level Framing). Các thông tin liên quan đến một ứng dụng cụ thể sẽ không xuất hiện trong tiêu đề của RTP, mà sẽ được qui định bới định dạng của payload và profile. Đối với mỗi lớp ứng dụng (video, audio) RTP định nghĩa một định dạng profile và một hay nhiều các định dạng payload được hỗ trợ.
Profile sẽ xác định CODEC (coder/decoder) dùng để mã hóa các dữ liệu tải và ánh xạ các dữ liệu này tới CODEC tương ứng trong trường PT (Payload Type) của header RTP.
Mỗi định dạng payload sẽ mô tả việc truyền dữ liệu được mã hóa.
Do phần mềm chỉ thực hiện việc truyền dữ liệu giữa một PC và một kit nên việc sử dụng RTCP sẽ là không cần thiết. Phần trình bày dưới đây sẽ tập trung vào các đặc tính của giao thức truyền dữ liệu RTP.
81
5.2.3 Cấu trúc tiêu đề gói tin RTP
Tiêu đề gói tin RTP bao gồm các trường được thể hiện trong Hình 5.2.
Hình 5.2 Cấu trúc tiêu đề gói tin RTP
12 byte (96 bit) đầu tiên là thành phần cố định trong tiêu đề của mọi gói tin RTP. Tiếp sau đó là phần tiêu đề mở rộng và dữ liệu tải (payload).
Ý nghĩa của các trường trong tiêu đề:
Version (V): 2 bit
Trường này chỉ ra phiên bản RTP đang sử dụng. (Phiên bản RTP đang sử dụng hiện nay là 2 (theo RFC 3550). Đối với phiên bản dự thảo đầu tiên trường Version được thiết lập bằng 1).
Padding (P): 1 bit
Nếu bit P được thiết lập (gán giá trị bằng 1) thì gói tin RTP sẽ chứa một hay