嵌入式系統的實時數據接口擴展

針對所采用的 CPU 沒有 MMU，選用了目前在嵌入式系統中被廣泛使用的μClinux。μClinux 是從標準的Linux 2．0 內核發展而來的，但其源代碼針對典型的嵌入式應用已經作了許多精簡和修改，使得其內核比標準的 Linux 內核要小很多，不過它仍然保留了標準 Linux的主要特色。

目前最新的μClinux 版本已經支持 S3C4510B 及典型開發板，如果所采用的 CPU 及開發板沒有被支持，應根據實際情況移植。此外，由于在外部總線接了 CPLD和 FIFO，為了使應用程序能訪問它，需要在μClinux 下開發相應的驅動程序。

2 實時數據接口的擴展

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口數據位寬度和讀寫時序設置等。