1，完结了SD卡读取文本文件的内容。–完结
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;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的代码吧！一移植就成功了。
