基于ATmegal28的LED屏圖像數(shù)據(jù)解碼設(shè)計(jì)

摘 要：針對(duì)目前對(duì)全彩LED顯示屏圖像數(shù)據(jù)的處理需依賴計(jì)算機(jī)的情況，提出利用ATmegal28單片機(jī)實(shí)現(xiàn)JPEG圖像解碼的方法，并利用此方法實(shí)現(xiàn)了通過(guò)GPRS網(wǎng)絡(luò)對(duì)全彩LED顯示屏圖像數(shù)據(jù)的遠(yuǎn)程傳輸。針對(duì)ATmegal28的資源和性能特點(diǎn)，對(duì)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í)用性。
關(guān)鍵詞：ATmegal28；JPEG解碼；Huffman解碼；IDCT解碼；全彩LED顯示屏

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

l JPEG解碼可行性分析
??? 該設(shè)計(jì)所用全彩LED屏接收的數(shù)據(jù)格式為Xmp格式，Xmp格式是簡(jiǎn)化的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解碼過(guò)程中所需要的緩存主要包括原始JPEG圖像數(shù)據(jù)的緩存、中間變量的緩存以及解出的Xmp數(shù)據(jù)的緩存。根據(jù)JPEG圖像的復(fù)雜度及壓縮比的不同，一般一幀320×240的彩色JPEG圖像的大小在2～20 KB。JPEG解碼緩存主要用于存儲(chǔ)Huffman表，量化表，IDCT解碼的臨時(shí)結(jié)果等。這些大約需要8 KB。解出的Xmp數(shù)據(jù)的緩存要求的RAM相對(duì)比較固定為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的頂部向下生長(zhǎng)。由于圖像處理過(guò)程中需要占用大量的RAM空間，所以應(yīng)該通過(guò)設(shè)置把所有數(shù)據(jù)區(qū)移到外部RAM，只留棧區(qū)在內(nèi)部RAM，避免數(shù)據(jù)的相互覆蓋。
??? JPEG解碼過(guò)程主要包括Huffman解碼、反量化及IDCT變換、色彩變換等模塊。該文采用的LED顯示屏是64×64點(diǎn)像素，并且只能顯示Xmp格式的圖片。因此在JPEG解碼后需增加圖像的縮放模塊。其流程框圖如圖1所示。

?

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

?

??? 在解碼的時(shí)候，讀取1串二進(jìn)制數(shù)據(jù)，分別與各碼長(zhǎng)下的最大值和最小值進(jìn)行比較，如果在哈夫曼表中沒有該碼長(zhǎng)的碼字，說(shuō)明該比特?cái)?shù)據(jù)不是完整的Huff_man編碼，接著讀取下一個(gè)比特?cái)?shù)據(jù)加在前面的比特?cái)?shù)據(jù)組成的新的碼字，然后再在最小值表和最大值表中進(jìn)行查找，直至找到確切的碼字。最后把該碼字減去同一碼長(zhǎng)下最小值，加上此最小值在哈夫曼表中的索引即可得到該碼字在編碼表中的位置。
2．2 IDCT變換的實(shí)現(xiàn)
??? 將8×8塊中的顏色分量單元的64個(gè)值逐一乘以對(duì)應(yīng)的量化表內(nèi)位置相同的系數(shù)，然后再將64個(gè)數(shù)據(jù)進(jìn)行Z字型的重新排列，進(jìn)行IDCT變換。IDCT的運(yùn)算量很大，其中要進(jìn)行大量的浮點(diǎn)乘法和加法運(yùn)算，因而在解碼過(guò)程中IDCT所占時(shí)間最多。采用行列分解法先將二維IDCT分解成一維8點(diǎn)的IDCT，對(duì)于一維8點(diǎn)IDCT采用Loeffler的快速算法。圖2為L(zhǎng)oef—fler算法的流程圖，Loeffler算法運(yùn)算因子的解釋如圖3 所示。

?

??? 直接對(duì)旋轉(zhuǎn)因子進(jìn)行計(jì)算需要4次乘法和2次加法，這樣1次8個(gè)點(diǎn)的一維IDCT變換總共需要14次乘法和26次加法。可以對(duì)旋轉(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)算過(guò)程中把浮點(diǎn)操作改進(jìn)為整形運(yùn)算，并且把的值擴(kuò)大211倍存儲(chǔ)起來(lái)，為IDCT運(yùn)算做準(zhǔn)備。

2．3 圖像的縮放
??? 由于該設(shè)計(jì)所使用的顯示屏為64×64個(gè)像素，所以對(duì)于JPEG格式的彩信需要先進(jìn)行解碼，然后再進(jìn)行縮放，使其成為64×64的格式。一般情況下，圖像縮放是采用目標(biāo)圖像到源圖像“逆向映射”法。但是考慮到ATmegal28 RAM容量的限制，如果先解出源圖像，則會(huì)占用大量的RAM，因此采用源圖像到目標(biāo)圖像的映射方法。當(dāng)解出源圖像一個(gè)像素的RGB值時(shí)，通過(guò)運(yùn)算求出其在目標(biāo)圖像中的位置；先判斷此位置是否為零，如果是，則直接存儲(chǔ)；如果否，則求兩數(shù)的平均值后存儲(chǔ)。對(duì)于源圖像中n個(gè)像素點(diǎn)對(duì)應(yīng)目標(biāo)圖像1個(gè)像素點(diǎn)的情況，這個(gè)目標(biāo)圖像像素點(diǎn)的顏色分量I=I1／2n+…+In／2，其中：I1為對(duì)應(yīng)源圖像中第一個(gè)像素點(diǎn)的顏色分量，In為最后一個(gè)的顏色分量。
??? 該設(shè)計(jì)所用方法得到的Xmp格式圖像與最近鄰域法所得圖像的比較如圖4所示。圖4(a)為L(zhǎng)ena原圖，圖4(b)為采用最近鄰域法得到的：Xmp格式圖像，圖4(c)為本文所用方法得到的Xmp格式圖像。對(duì)比可知，這里所用的方法得到的圖像像素點(diǎn)間過(guò)渡比較平滑，有比較好的顯示效果。此方法是對(duì)最近鄰域法的改進(jìn)，既避免了在使用最近鄰域法時(shí)源圖像某些像素信息的丟失，又節(jié)省了系統(tǒng)的RAM資源。

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

?

??? 系統(tǒng)以ATmegal28單片機(jī)為主要芯片，通過(guò)RS 232和TR800進(jìn)行數(shù)據(jù)傳輸。ATmegal28通過(guò)命令讀取TR800接收到的彩信圖像，進(jìn)行解碼處理。然后通過(guò)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ā)以及固件的升級(jí)。由于以上特點(diǎn)，該設(shè)計(jì)選用此模塊來(lái)實(shí)現(xiàn)對(duì)彩信收發(fā)處理功能。LED顯示屏的傳輸協(xié)議遵守Xmodem通信協(xié)議，采用CRC校驗(yàn)。整個(gè)系統(tǒng)運(yùn)行效果表明，ATmegal28在采用16 MHz晶振的情況下解碼167×173像素的JPEG圖片大約需要1s。

4 結(jié) 語(yǔ)
??? 提出適合于全彩LED顯示屏的遠(yuǎn)程圖像傳輸設(shè)計(jì)，并給出關(guān)鍵問(wèn)題的解決方法。由于利用單片機(jī)實(shí)現(xiàn)了圖像的軟件解碼，這給工程上應(yīng)用帶來(lái)便利。該設(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)杯”全國(guó)大學(xué)生課外學(xué)術(shù)科技作品競(jìng)賽中獲二等獎(jiǎng)。