a一级爱做片免费观看欧美,久久国产一区二区,日本一二三区免费,久草视频手机在线观看

新聞中心

EEPW首頁 > 設計應用 > 裝備無線自動跟蹤攝像頭的警用車輛支持系統*(下)

裝備無線自動跟蹤攝像頭的警用車輛支持系統*(下)

作者:■ Joo Sunwoong、Suh Hoseong、Moon Youngje 韓國仁荷大學、韓國航空航天大學、弘益大學 時間:2008-04-08 來源:電子產品世界 收藏

  uClinux 上 C2H 加速的 JPEG 壓縮

本文引用地址:http://www.j9360.com/article/81346.htm

  按JPEG標準進行的圖像壓縮大小為640x400。libjpeg的前向式DCT函數被加速器取代;該加速器使用C2H編譯器開發而成,可以在uClinux環境中進行訪問。將C2H加速器與uClinux 結合非常重要,因為它要與其它任務同時運行。對libjpeg(標準庫)進行加速使我們可以無需增加額外的DSP芯片或任何常見的軟件就能獲得性能的提升。使用libjpeg的應用程序可以通過重新編譯提高壓縮性能,而不必修改任何代碼。

  自定義的OBD-II接口

  車輛都有一個用于進行管理的發動機控制單元(ECU)。警用車輛上也有這樣的設備。對于新近制造的車輛來說,ECU是一個非常重要的組件,其作用是將發動機與各種電子控制部件結合起來。OBD-II是一個接口,可以將計算機或診斷工具連接到ECU以便進行車輛維護,它可以實現設備間的通信。

  OBD標準有很多種,具體取決于車輛的制造商。本項目采用的是ISO9141-2國際標準。通過 OBD-II,可以了解車輛的行駛速度、燃油狀態和車輛的故障情況。其初始化過程為5波特,通信速度為10.4k波特。對于接收到的信息部分字節,必須進行補充并將其發送到ECU進行通信。在SoPC平臺上使用的是UART組件,因為它與串行通信類似。

  性能參數

  表1 列出了在圖像處理模塊上發送控制信號,到步進馬達上接收初始操作信號之間的時間間隔。該時間間隔是通過示波器測量得出的。通過 GPIO 接口啟動步進馬達后,在軟件程序控制器中,Nios處理器會接收中斷信號,并生成操作信號。

  汽車跟蹤攝像頭的速度主要取決于圖像處理性能。表2顯示了基于不同平臺的每種跟蹤算法的測試幀速率。實際上,DE2的幀速率接近60幀/秒,因為圖像處理模塊以隔行掃描模式運行;但是,我們根據有效幀的數量將其標記為29幀/秒。

  另一個結果是,C2H加速的libjpeg的DCT函數可以實現JPEG的快速壓縮。640x400的24 位位圖經過了20倍強壓縮以實現精確的測量。使用C2H編譯所顯示出來的性能比這種沒有加速器設計的性能要差。要解決此問題,我們更改了緩沖區管理方法。在修改了DCT函數后,性能提升了4倍。

  我們在設計該時,考慮了在 uClinux 上使用 USB 調制解調器時的性能下降問題。然而事實顯示,網絡性能與在 PC 環境中運行的性能幾乎相同。

  設計的體系結構

  整個系統由 uClinux 操作系統控制。包括圖像處理模塊在內的攝像頭控制系統和子系統由完整的 FPGA 組成。

  標準 JPEG 庫 libjpeg 的 DCT 函數被更改為 C2H 加速器。圖像處理模塊、VGA 控制器和步進馬達控制器被組合成一個單獨的 SoPC 組件。總共消耗了 31000 LE。

  設計描述

  組合uClinux和C2H

  使用操作系統可以靈活地在復雜的多設備環境系統中進行開發。uClinux內核是適合于非 MMU處理器的操作系統內核。由于uClinux系統中沒有內存管理單元,因此可以極大地簡化基于 Nios 處理器對定制的硬件加速器進行訪問的應用程序的使用。

  在 Nios IDE 環境中編寫的代碼經過很少的更改或無需更改即可在 uClinux 下的多任務環境中運行,因為在 uClinux 中對內存映射地址的寫操作沒有限制。

  我們可以通過常用的技術在uClinux上使用C2H加速器。將 C2H 加速器從 Nios IDE 移到 uClinux 上所需步驟如下:

  第一步是生成一個臨時項目。然后,在Nios IDE中編譯并生成加速器?,F在,我們可以在 Debug目錄中看到加速器的打包函數。將這些頭文件(Header file)和打包函數復制到 uClinux開發目錄中。如果您尚未對FPGA編程,則進行該項編程。

  下一步是使用Nios的gcc工具和elf2flt選項編譯經過加速的應用程序。確保必需的頭文件(如 system.h 或 io.h)存在。在完成此步驟后,將生成的執行文件復制到單片機上。在大多數情況下,它的速度會比僅使用軟件的系統要快。

  可惜的是,我們在將 libjpeg DCT 函數轉換成加速器時面臨著性能方面的問題。我們將在接下來的部分介紹針對性能問題的解決方案。

  優化C2H編譯器的JPEG庫

  一般情況下,開發人員會考慮使用DSP進行JPEG壓縮,但 DSP 需要有自己的軟件程序來提供支持。選擇可以加速libjpeg的C2H編譯器是一個正確的決定,因為許多現有應用程序都使用作為JPEG標準庫的libjpeg。

  但是,在使用C2H編譯器轉換原始的DCT函數時,它所顯示的性能比僅使用軟件設計的性能低。從結構上來說,對數據高速緩存的刷新是一個問題,它的數據處理工作是以64個字節為單位進行的。我們設計了適合于C2H編譯器的經過優化的緩沖區管理系統。這個管理器實現了 4 倍的性能提升。

  創建自定義的 SoPC 組件

  每個部件都由VerilogHDL單獨設計,并作為一個組件添加到SoPC中。圖像處理模塊、VGA 控制器和步進馬達控制器被組合成一個單獨的SoPC組件,因為這些部件相互之間都有密切的關聯。這些組件作為Avalon Master的組件在 SRAM 上寫入圖像數據。

  使用自定義指令對 MPEG 音頻進行解碼

  在使用Nios II處理器和uClinux的環境中播放MPEG音頻存在三個主要問題:處理器性能、FIFO的大小以及在uClinux中用于輸出的設備驅動程序。

  我們發現,100 MHz Nios II處理器在Cyclone II芯片上對立體聲128Kbps 44.1KHz MP3音頻進行解碼時會有性能損失。如果FIFO足夠大,則可以在該系統中播放單聲道音頻,但CPU會一直分配用于播放音頻的性能。

  我們在Nios處理器上添加了使用自定義指令的64位乘法器以實現64位乘法計算;這種運算方法在Libmad庫中經常用到。播放的性能提升了大約2.5倍,用于計算的時鐘使用率有所降低。

  還有其它一些原因使音頻播放質量不佳。首先是采樣率不好,其次是緩沖區大小不足,最后是多任務處理環境。音頻將參考使用 17 MHz 的時鐘。



評論


相關推薦

技術專區

關閉