SD卡讀取bmp圖片移植調試完成

2，接著讓SD卡讀取24位bmp圖片，并顯示。--完成 步驟1，移植。 步驟2，調試。
調試步驟：
第一步：驗證能從SD的FAT32文件系統中讀取所有bmp圖片數據---完成。
第二步：驗證處理后的像素數據正確。---完成。
第三步：把處理完的像素數據，通過顯示屏顯示。--完成。
主要困難點：一開始不知道24bit bmp的圖片的行末尾數據會自動補0，因為一個掃描行必須為4的倍數。

參考了2種代碼。調試如下。

第一步：驗證能從SD的FAT32文件系統中讀取所有bmp圖片數據---完成。
一開始以為讀文件的內容的函數不能讀圖片數據。來后對比其他參考程序后，發現是可以讀的，別人也在調用這個函數讀圖片數據呢。

復習了FAT32的文件系統，知道了apple.bmp的數據內容在2101扇區，于是讓read One block直接讀，但是讀不出。發現在znfat.c中調用read one block讀2101扇區是可以的，說明數據能讀，并且讀出來看了下，內容和winhex一樣。但是循環讀幾個block后，就死機了。
于是，再往下分析 znFAT_Read_File函數，原來for(i=pfi->FileCurPos;iBytesPerSector;i++)中的指針中的數值一直在變化。把它改成
imin=pfi->FileCurPos;
imax=pArg->BytesPerSector;
for(i=imin;i那么這段函數算是可以用了。不會循環幾次就死機了。

但是因為bmp文件大于512byte。所以要循環讀的。讀完后都放在file_info中，但是發現讀第一個512是對的，讀第二個512就變成了0.后來發現原因。原來是file_info一定要定義一個范圍。這樣下次讀的時候就可以覆蓋之前的512個字節.一開始定義為UINT8 *file_info;于是循環讀的時候就出問題了。改成UINT8 file_info[512];就ok了。已經證明能順利從SD的FAT32文件系統中讀取所有bmp圖片數據，并且和winhex中看出的數值是一致的。

第二步：驗證處理后的像素數據正確。---完成。
復習了bmp文件的格式，主要是24位bmp的格式，數據是從左下角，以行方式讀到右上角的。并且一個像素由B，R，G三個字節組成。前54個字節是文件頭。后面的是真正的數據值。ok，24為bmp真彩就這幾個要點。于是看了看把24位轉為為16位的方法。這里在調試的時候因為漏看了數據的組織方式是左下角到右上角。導致我之前一度懷疑24位轉16的代碼有問題。不過，轉換代碼中，我沒有把B，G，R轉為16位后再進行與操作。導致數據丟失。后來串口打印出來才看出的。

第三步：把處理完的像素數據，通過顯示屏顯示。--完成。
這步照理很簡單啊。但是顯示的圖像就是很奇怪，一開始顯示一條斜線。
于是我網上搜索了下，主要有2種方案，
1，一種是一個個點寫入。
2，另一種是設置顯示區域，然后填充數據。后來查出來。
方案1：調試后發現。
address_set(x,x,y,y);我移植過來就改了函數名稱為address_set，其實，我的這個函數應該是address_set(x,y,x,y);怪不得顯示一條斜線呢！
然后就是每3個字節，處理成16bit的2個字節，一點點顯示出來。但是顯示的圖片就是不對。難道讀出的數據有問題？我之前檢查過每問題了。難道處理后的數據有問題，我之前檢查過函數也正確。于是，把處理后的數據打印出來，與Image2LCD中處理的數據對比。發現了很奇怪，前182個像素處理的很ok，很特別的是182就是第一行數據，到第183-185這3個字節處理的結果和Image2LCD是不同的，然后發現如果放棄183.去處理184-185轉為2個字節，那么就和Image2LCD一致了。然后突然先到了之前網頁上看到的一句話，說一個掃描行必須為4的倍數。不是4的倍數就自動補0，這些0就是無效的像素數據了。如下圖,終于發現了關鍵的問題。但是代碼要怎么改呢？于是乎，想到了方案2的代碼中，本來以為很多余的一句，我把它注釋掉了。原來就是很關鍵的一句話。znFAT_Read_File(&FileInfo,FileInfo.FileCurOffset,270,file_info);從每行的頭開始讀取數據。那么就移植方案2的代碼吧！一移植就成功了。