有害動(dòng)物智能聲防系統中音頻控制子系統的研制
加入技術(shù)交流群
軟件的中間層是應用程序層，包括音頻解碼子程序、串口通信子程序、隨機數生成子程序等。在嵌入式Linux環(huán)境下，有更豐富的系統函數和開(kāi)源軟件作支持，使應用程序的實(shí)現更容易。例如，其中的MP3解碼子程序采用音頻解碼庫libmad提供的高級API編寫(xiě)。libmad是一個(gè)開(kāi)源的高精度MPEG音頻解碼庫，它支持MPEG-1標準中Layer I、Layer II和LayerIII（即MP3）格式的音頻解碼，且解碼過(guò)程使用定點(diǎn)計算，非常適合沒(méi)有浮點(diǎn)運算支持的平臺(如ARM平臺)。使用libmad提供的高級API，很容易實(shí)現MP3數據的解碼，其過(guò)程只需打開(kāi)對應的音頻設備文件，并將SD卡上待解碼的音頻文件映射到內存中，然后調用libmad的解碼函數即可。在方案1的實(shí)現上，研發(fā)者需自己編程實(shí)現的FAT文件格式處理、音頻參數提取和設置、解碼數據讀寫(xiě)控制等功能，在本方案中均是由操作系統驅動(dòng)程序以及l(fā)ibmad解碼庫中的庫函數自動(dòng)完成的。另外，在OSS音頻驅動(dòng)和SD卡驅動(dòng)的支持下，可方便地實(shí)現對WAV音頻文件播放子程序的編制。WAV音頻文件由于直接存儲了PCM編碼的音頻數據，雖文件較大，但沒(méi)有壓縮失真，其音質(zhì)也優(yōu)于MP3。
軟件的上層是流程控制層。由于方案2與方案1所實(shí)現的功能基本相同，故其軟件的流程并無(wú)本質(zhì)差異，具體功能仍可參見(jiàn)圖3。嵌入式Linux具備多任務(wù)管理功能，即能以分時(shí)復用方式“同時(shí)”處理多個(gè)進(jìn)程，并提供有多種進(jìn)程間的通信協(xié)調機制，例如信號機制等。信號機制用于多任務(wù)間的通信，其實(shí)質(zhì)是在軟件層次上對中斷機制的一種模擬。與方案1不同的是，在嵌入式Linux環(huán)境中，使用信號機制能方便地實(shí)現中斷控制。在程序中設置為當串口收到數據時(shí)，向系統進(jìn)程發(fā)出信號，系統進(jìn)程收到信號后轉向執行事先指定的處理程序，從而實(shí)現中斷控制。
4 兩種實(shí)現方案的實(shí)驗測試和對比
按上述兩方案構建了實(shí)現農作物有害動(dòng)物智能化聲防系統用的音頻控制子系統。實(shí)驗測試結果表明，以?xún)煞N方案研發(fā)的音頻控制子系統均達到了預期目標，能準確、可靠地與無(wú)線(xiàn)通信模塊通信，在總控制器控制下實(shí)時(shí)調整各種工作參數。音頻控制子系統在觸發(fā)、隨機2種工作模式下，均能準確、清晰地播放當前聲防目標對應的音頻文件。采用可熱插拔的SD卡確保了聲防音頻文件更新方便。而且基于所采用的FAT16文件格式，該子系統能支持最高容量為2 GB的SD卡，實(shí)現了大容量音頻文件的可靠存儲。
由于采用不同的硬件平臺而構建，2種音頻控制子系統實(shí)現方案在功能、開(kāi)發(fā)難度以及構建成本等方面有所不同。
在功能方面，方案1能對比特率在192 kb/s及以下的MP3文件做流暢的解碼播放，但播放更高比特率的文件時(shí)，受AT89C51SND1處理速度以及現有程序的數據讀寫(xiě)效率限制，不能保證寫(xiě)入解碼緩沖區數據的連續性，從而導致輸出聲音有間斷。而且由于硬件解碼的限制，不能對其他格式的音頻文件進(jìn)行解碼播放。方案2由于采用軟件解碼，且所選用微處理器S3C2440的主頻達400 MHz，理論上只要移植對應的解碼子程序，便可對任何格式的音頻文件進(jìn)行解碼播放。對方案2的測試發(fā)現，其確實(shí)能對任意比特率的MP3、WAV格式的音頻文件進(jìn)行解碼播放。而且方案2中，系統完全有能力在完成音頻解碼任務(wù)之同時(shí)，還處理更多復雜的任務(wù)(MP3解碼程序只占用了S3C2440處理能力的7%左右)，具有很強的擴展性。例如，音頻控制子系統可在探測器節點(diǎn)發(fā)現有害動(dòng)物后進(jìn)行聲音采集或視頻采集，并運行語(yǔ)音識別子程序或經(jīng)視覺(jué)檢測對探測到的有害動(dòng)物種類(lèi)進(jìn)行判斷，從而使整個(gè)聲防系統的聲防目標更準確，達到更好的聲防效果。另外，由于嵌入式操作系統對硬件的屏蔽性，實(shí)現方案2的軟件很容易在其他硬件平臺上移植。
在軟件開(kāi)發(fā)過(guò)程中，方案1需要關(guān)注每個(gè)硬件設備的操作細節，其軟件的編程量較大。而方案2由于所選用的Linux操作系統直接提供硬件驅動(dòng)程序，且也有大量開(kāi)源軟件資源可供應用程序編程所利用，故其軟件的開(kāi)發(fā)相對容易。但方案2需移植嵌入式操作系統作為軟件開(kāi)發(fā)平臺，包括建立BootLoader引導程序，配置、編譯并移植操作系統內核和文件系統等，這與采用向單片機直接燒寫(xiě)程序的方案1相比，開(kāi)發(fā)難度稍大。在軟件調試方面，方案1中單片機程序的每次變更都需重新寫(xiě)入ROM。而方案2可利用Linux的網(wǎng)絡(luò )功能，將微機上的編程目錄以NFS方式掛載在嵌入式Linux文件系統中，從而實(shí)現在微機端編寫(xiě)、修改程序，在嵌入式Linux系統上直接“遠程”運行修改后的程序，調試較為方便。
從構建成本上比較，方案1的硬件成本更低一些。但隨著(zhù)制造工藝的不斷進(jìn)步，32 bit微處理器的成本會(huì )進(jìn)一步降低，再考慮外圍器件的成本，以方案2構建音頻控制子系統的性?xún)r(jià)比，與基于方案1構建的相比已有優(yōu)勢。
數字化、智能化是農業(yè)現代化發(fā)展的必然趨勢。為確?？煽啃院托阅茏顑?yōu)，本文利用嵌入式技術(shù)、采用兩種技術(shù)方案研發(fā)實(shí)現了農作物有害動(dòng)物智能化聲防系統中起重要作用的音頻控制子系統。實(shí)驗測試發(fā)現，“單片機+硬件解碼”構建方案能基本滿(mǎn)足功能需求，但其系統性能和升級擴展能力受到硬件限制；而“ARM微處理器+軟件解碼”構建方案能完全滿(mǎn)足功能需求，而且具有很強的擴展性和可移植性。本文引用地址：http://dyxdggzs.com/article/163084.htm
pid控制器相關(guān)文章:pid控制器原理
評論