《電子技術(shù)應(yīng)用》
您所在的位置:首頁 > 模擬設(shè)計(jì) > 設(shè)計(jì)應(yīng)用 > 基于ATmegal28的LED屏圖像數(shù)據(jù)解碼設(shè)計(jì)
基于ATmegal28的LED屏圖像數(shù)據(jù)解碼設(shè)計(jì)
摘要: 針對目前對全彩LED顯示屏圖像數(shù)據(jù)的處理需依賴計(jì)算機(jī)的情況,提出利用ATmegal28單片機(jī)實(shí)現(xiàn)JPEG圖像解碼的方法,并利用此方法實(shí)現(xiàn)了通過GPRS網(wǎng)絡(luò)對全彩LED顯示屏圖像數(shù)據(jù)的遠(yuǎn)程傳輸。針對ATmegal28的資源和性能特點(diǎn),對JPEG解碼進(jìn)行了可行性分析。重點(diǎn)論述Huffman解碼、IDCT解碼和圖像縮放的優(yōu)化算法在ATmegal28單片機(jī)上的實(shí)現(xiàn)。由于圖像的處理在單片機(jī)上實(shí)現(xiàn),降低了產(chǎn)品的成本,具有較強(qiáng)地生產(chǎn)實(shí)用性。
Abstract:
Key words :

  隨著LED顯示屏的普及和成本的降低,LED顯示屏已經(jīng)成為公共場合信息宣傳的一種重要工具。目前實(shí)現(xiàn)對LED顯示屏的文字圖像更改的方法主要有:顯示屏通過串口或網(wǎng)線與計(jì)算機(jī)連接實(shí)現(xiàn)更改;通過GPRS網(wǎng)絡(luò)實(shí)現(xiàn)數(shù)據(jù)的遠(yuǎn)程傳輸,接收后在計(jì)算機(jī)上用特定軟件解碼后發(fā)送到LED顯示屏顯示。以上方法始終需要在計(jì)算機(jī)平臺上實(shí)現(xiàn),附加成本較高。設(shè)計(jì)利用手機(jī)作為發(fā)送端,發(fā)送彩信至GPRS模塊,利用ATmegal28單片機(jī)直接對彩信圖像進(jìn)行解碼然后發(fā)送到LED顯示屏上進(jìn)行顯示。

  l JPEG解碼可行性分析

  該設(shè)計(jì)所用全彩LED屏接收的數(shù)據(jù)格式為Xmp格式,Xmp格式是簡化的BMP格式。Xmp格式在圖像數(shù)據(jù)前有6個(gè)字節(jié)表示圖像的屬性,第1字節(jié)為1個(gè)點(diǎn)的字節(jié)數(shù);第2字節(jié)為XMP文件中包含的圖片個(gè)數(shù);第3,4字節(jié)為圖像的高;第5,6字節(jié)為圖像的寬,其后為圖像每點(diǎn)的顏色。每點(diǎn)的顏色用2個(gè)字節(jié)表示(16位色)。由于所用全彩LED屏只有64×64像素,所以JPEG解碼后還需進(jìn)行圖像的縮放。

  JPEG解碼過程中所需要的緩存主要包括原始JPEG圖像數(shù)據(jù)的緩存、中間變量的緩存以及解出的Xmp數(shù)據(jù)的緩存。根據(jù)JPEG圖像的復(fù)雜度及壓縮比的不同,一般一幀320×240的彩色JPEG圖像的大小在2~20 KB。JPEG解碼緩存主要用于存儲Huffman表,量化表,IDCT解碼的臨時(shí)結(jié)果等。這些大約需要8 KB。解出的Xmp數(shù)據(jù)的緩存要求的RAM相對比較固定為9 KB。綜上JPEG解碼大致需25 KB的RAM。ATmegal28內(nèi)部只有4 KB的SRAM,所以該系統(tǒng)外擴(kuò)了64 KB的外部RAM。

  2 軟件實(shí)現(xiàn)

  該設(shè)計(jì)采用avr—gcc作為編譯工具。avr-gcc默認(rèn)設(shè)置棧由內(nèi)部RAM的頂部向下生長。由于圖像處理過程中需要占用大量的RAM空間,所以應(yīng)該通過設(shè)置把所有數(shù)據(jù)區(qū)移到外部RAM,只留棧區(qū)在內(nèi)部RAM,避免數(shù)據(jù)的相互覆蓋。

  JPEG解碼過程主要包括Huffman解碼、反量化及IDCT變換、色彩變換等模塊。該文采用的LED顯示屏是64×64點(diǎn)像素,并且只能顯示Xmp格式的圖片。因此在JPEG解碼后需增加圖像的縮放模塊。其流程框圖如圖1所示。

流程框圖

  2.1 Huffman解碼的實(shí)現(xiàn)

  Huffman解碼是解碼過程中重要的一環(huán)。傳統(tǒng)的哈夫曼解碼需要逐位查找哈夫曼表,進(jìn)行比較判斷,由于查找過程需要大量的移位及循環(huán)。這樣的解碼效率非常低。針對這種情況,充分考慮到ATmegal28的存儲容量的限制,在讀文件頭時(shí),軟件事先構(gòu)造出不同碼長下的哈夫曼碼字的最小值表和最大值表如表1所示,最小值在哈夫曼表中的索引以及哈夫曼樹各葉子結(jié)點(diǎn)對應(yīng)的編碼表。

軟件事先構(gòu)造出不同碼長下的哈夫曼碼字的最小值表和最大值表

  在解碼的時(shí)候,讀取1串二進(jìn)制數(shù)據(jù),分別與各碼長下的最大值和最小值進(jìn)行比較,如果在哈夫曼表中沒有該碼長的碼字,說明該比特?cái)?shù)據(jù)不是完整的Huff_man編碼,接著讀取下一個(gè)比特?cái)?shù)據(jù)加在前面的比特?cái)?shù)據(jù)組成的新的碼字,然后再在最小值表和最大值表中進(jìn)行查找,直至找到確切的碼字。最后把該碼字減去同一碼長下最小值,加上此最小值在哈夫曼表中的索引即可得到該碼字在編碼表中的位置。

  2.2 IDCT變換的實(shí)現(xiàn)

  將8×8塊中的顏色分量單元的64個(gè)值逐一乘以對應(yīng)的量化表內(nèi)位置相同的系數(shù),然后再將64個(gè)數(shù)據(jù)進(jìn)行Z字型的重新排列,進(jìn)行IDCT變換。IDCT的運(yùn)算量很大,其中要進(jìn)行大量的浮點(diǎn)乘法和加法運(yùn)算,因而在解碼過程中IDCT所占時(shí)間最多。采用行列分解法先將二維IDCT分解成一維8點(diǎn)的IDCT,對于一維8點(diǎn)IDCT采用Loeffler的快速算法。圖2為Loef—fler算法的流程圖,Loeffler算法運(yùn)算因子的解釋如圖3 所示。

Loef

Loeffler算法運(yùn)算因子的解釋

  直接對旋轉(zhuǎn)因子進(jìn)行計(jì)算需要4次乘法和2次加法,這樣1次8個(gè)點(diǎn)的一維IDCT變換總共需要14次乘法和26次加法??梢詫πD(zhuǎn)因子進(jìn)行變形如式(1)所示: 

公式

  從而1次旋轉(zhuǎn)因子計(jì)算只需要3次乘和3次加。進(jìn)而進(jìn)行1次一維IDCT只需11次乘和29次加。因?yàn)槌朔ㄟ\(yùn)算的代價(jià)高于加法運(yùn)算,所以這種變形是有益的。完成一次二維的IDCT運(yùn)算總共要進(jìn)行16次的8點(diǎn)一維IDCT運(yùn)算。由于ATmegal28在速度方面的限制,在IDCT運(yùn)算過程中把浮點(diǎn)操作改進(jìn)為整形運(yùn)算,并且把公式的值擴(kuò)大211倍存儲起來,為IDCT運(yùn)算做準(zhǔn)備。

 

  2.3 圖像的縮放

  由于該設(shè)計(jì)所使用的顯示屏為64×64個(gè)像素,所以對于JPEG格式的彩信需要先進(jìn)行解碼,然后再進(jìn)行縮放,使其成為64×64的格式。一般情況下,圖像縮放是采用目標(biāo)圖像到源圖像“逆向映射”法。但是考慮到ATmegal28 RAM容量的限制,如果先解出源圖像,則會占用大量的RAM,因此采用源圖像到目標(biāo)圖像的映射方法。當(dāng)解出源圖像一個(gè)像素的RGB值時(shí),通過運(yùn)算求出其在目標(biāo)圖像中的位置;先判斷此位置是否為零,如果是,則直接存儲;如果否,則求兩數(shù)的平均值后存儲。對于源圖像中n個(gè)像素點(diǎn)對應(yīng)目標(biāo)圖像1個(gè)像素點(diǎn)的情況,這個(gè)目標(biāo)圖像像素點(diǎn)的顏色分量I=I1/2n+…+In/2,其中:I1為對應(yīng)源圖像中第一個(gè)像素點(diǎn)的顏色分量,In為最后一個(gè)的顏色分量。

  該設(shè)計(jì)所用方法得到的Xmp格式圖像與最近鄰域法所得圖像的比較如圖4所示。圖4(a)為Lena原圖,圖4(b)為采用最近鄰域法得到的:Xmp格式圖像,圖4(c)為本文所用方法得到的Xmp格式圖像。對比可知,這里所用的方法得到的圖像像素點(diǎn)間過渡比較平滑,有比較好的顯示效果。此方法是對最近鄰域法的改進(jìn),既避免了在使用最近鄰域法時(shí)源圖像某些像素信息的丟失,又節(jié)省了系統(tǒng)的RAM資源。

該設(shè)計(jì)所用方法得到的Xmp格式圖像與最近鄰域法所得圖像的比較

  3 硬件實(shí)現(xiàn)

  該系統(tǒng)的硬件實(shí)現(xiàn)框圖如圖5所示:

該系統(tǒng)的硬件實(shí)現(xiàn)框圖

  系統(tǒng)以ATmegal28單片機(jī)為主要芯片,通過RS 232和TR800進(jìn)行數(shù)據(jù)傳輸。ATmegal28通過命令讀取TR800接收到的彩信圖像,進(jìn)行解碼處理。然后通過RS 232把數(shù)據(jù)傳輸?shù)饺蔐ED顯示屏進(jìn)行圖像的更改。在Amegal28與外部SRAM之間使用了鎖存器,該設(shè)計(jì)采用的是74AHC573。TR-800模塊是一個(gè)高性能、功耗小的GPRS模塊,它內(nèi)嵌了WAP協(xié)議棧、TCP/IP協(xié)議棧、MMS協(xié)議棧便于用戶的二次開發(fā)以及固件的升級。由于以上特點(diǎn),該設(shè)計(jì)選用此模塊來實(shí)現(xiàn)對彩信收發(fā)處理功能。LED顯示屏的傳輸協(xié)議遵守Xmodem通信協(xié)議,采用CRC校驗(yàn)。整個(gè)系統(tǒng)運(yùn)行效果表明,ATmegal28在采用16 MHz晶振的情況下解碼167×173像素的JPEG圖片大約需要1s。

  4 結(jié) 語

  提出適合于全彩LED顯示屏的遠(yuǎn)程圖像傳輸設(shè)計(jì),并給出關(guān)鍵問題的解決方法。由于利用單片機(jī)實(shí)現(xiàn)了圖像的軟件解碼,這給工程上應(yīng)用帶來便利。該設(shè)計(jì)能廣泛應(yīng)用于車載,或者戶外廣告屏的圖像數(shù)據(jù)的處理傳輸。將計(jì)算量龐大的JPEG解碼算法成功地在ATmegal28上進(jìn)行移植,并由此實(shí)現(xiàn)全彩LED顯示屏圖像數(shù)據(jù)的遠(yuǎn)程更改,具有較強(qiáng)生產(chǎn)實(shí)用性。設(shè)計(jì)完成的“基于GPRS的遠(yuǎn)程交互式多用戶智能信息屏”在第十屆“挑戰(zhàn)杯”全國大學(xué)生課外學(xué)術(shù)科技作品競賽中獲二等獎。

此內(nèi)容為AET網(wǎng)站原創(chuàng),未經(jīng)授權(quán)禁止轉(zhuǎn)載。