2.1 應用要求

　　將上述嵌入式系統應用于實時多媒體數據的網絡傳輸，如圖2所示。這里的實時多媒體可以是 MPEG-4或 MPEG-2 等，其數據流一般是連續、恒定碼率的。

　　2.2 硬件擴展

　　根據上述數據流的特點，需在嵌入式系統與外設(編、解碼器)之間加入數據緩沖控制單元。對于發送端和接收端，數據緩沖控制單元的設計有所不同，下面以MPEG-2 為例說明。這里考慮系統的處理能力、網絡的承受能力以及圖像質量，MPEG-2 的輸出為 4Mbps 的CBR(固定比特率)TS流。

　　2.2.1 發送端

　　編碼器送出連續、恒定速率的碼流。如果將此碼流直接送到 CPU 外部總線，將會導致操作系統頻繁地處理中斷，甚至會產生中斷不能及時處理從而導致數據丟失。因此，有必要在編碼器與外部總線之間加上 FIFO，同時用 CPLD 實現 FIFO 的讀寫控制邏輯。編碼器送出的數據流連續不斷地以恒定速率寫入FIFO;當FIFO中的數據積聚到一定值后，每寫入若干個數據就向CPU發一個中斷;CPU在收到中斷后通過外部總線讀入相當量的數據，并將其打包送入網絡。正常情況下，每個中斷讀數據個數是一定的，在一段時間內FIFO寫入和讀出將維持平衡，且不會產生“饑餓”狀態;當操作系統因處理別的任務而沒有及時響應中斷時，FIFO將暫時進入“飽和”狀態，但只要FIFO容量足夠大就不會產生數據溢出現象。由于CPU從FIFO讀取單位數據的速度大大高于外設向FIFO寫單位數據的速度，“飽和”狀態一般能消除。由此，可以解決前述問題。

　　2.2.2 接收端

　　在接收端，由于解碼器的輸入要求是一個連續、恒定速率的碼流，同樣要求在CPU外部總線與編碼器之間加上FIFO和CPLD。同時，接收端的數據包由于經過了網絡，不可避免地會引入延時，且數據包之間的延時是不確定的，甚至會產生數據包的丟失。這些都需要在接收端予以考慮，增加了接收端數據緩沖控制單元的復雜度。

　　為了解決數據包到達延時及抖動問題(數據包的丟失將間接導致延時的增加)，可以簡單地靠增大FIFO容量解決。但增大FIFO將意味著從編碼器到解碼器之間延時的增加，影響了實時性。因此，為了保證一定的實時性，同時考慮成本因素，不能單純靠增大FIFO解決。

　　由于FIFO容量的限制，在出現大延時的情況下，FIFO將可能出現“空”狀態。這意味著送給解碼器的數據流會有中斷，從而可能導致解碼器的不正常工作并可能不能恢復(在數據流恢復正常后)。為此，需要在FIFO出現“空”狀態之前，即處于“饑餓”狀態時(可以設置一個閾值)，由CPLD停止向FIFO讀數據而向解碼器發填充包。填充包中含有同步頭，可以維持解碼器的同步。短時間的插空包會使視頻圖像出現馬賽克，如果時間過長，可能會出現黑屏。在實際試驗中，接收端視頻的質量與網絡的負載情況有關。當網絡負載較重時，圖像會出現馬賽克，黑屏現象一般極少發生。

　　2.3 驅動程序

　　為了使μClinux下的應用程序能通過外部總線訪問FIFO，需要編寫相應的驅動程序。驅動程序主要包括三個基本部分，即CPU相關寄存器的初始化設置以及CPU對外部I/O口的讀操作和寫操作。其中，初始化設置主要包括中斷號及其類型設置、外部I/O口數據位寬度和讀寫時序設置等。