关于汉字显示实验的更新字库部分的疑问

冰封小凯

在stm32库函数版本的pdf第618页，课本第456页，有关于汉字的GBK12，GBK16和UNIGBK部分的刷写进flash的操作
现摘取部分内容如下：
while(res==FR_OK)//死循环执行
{
  res=f_read(fftemp,tempbuf,4096,(UINT *)&bread);//读取数据     
  if(res!=FR_OK)break;            //执行错误
  SPI_Flash_Write(tempbuf,offx+flashaddr,4096);  //从 0 开始写入4096个数据  
  offx+=bread;      
  fupd_prog(x,y,size,fftemp->fsize,offx);        //进度显示
  if(bread!=4096)break;            //读完了.
}
红颜色显示的部分感觉有误：我的理解是这样的，按照原子哥的程序，三个字库是顺序刷入flash的，当第一个字库
完全刷入后，最后那部分的数据量即bread的数值应该会小于4096，可是，红颜色的部分显示部分表明，最后那部分
数据也是刷入了4K字节，那么就会使最后一个字节的地址后（4096-bread）个地址被刷入数据，这样，第二个字库
是从最后一字节的地址开始写入，而外部flash写入前会进行校验，由于开始地址之后的部分地址有数据，那么就会校验
失败，会将这个4K的flash扇区进行擦除，那么就实际上第一个字库的最后部分的内容会被刷成0xFF;

我认为，那个4096如果改成bread，则可以避免这个现象。

冰封小凯

原子哥，帮忙看一下啊。。。。。。。怎么没有人搭理我啊

正点原子

确实会有这个问题。

冰封小凯

回复【3楼】 正点原子 :
------------------------------
回复【3楼】 正点原子 :
---------------------------------
原子哥，是不是那个4096如果改成bread，则可以避免这个现象？

还有一个问题就是，在同样一页的另一个函数u8 update_font(u16 x,u16 y,u8 size,u8 src），在我的理解看来，也是有问题的，
现复制原函数如下：
u8 update_font(u16 x,u16 y,u8 size,u8 src)
{    
    u8 *gbk16_path;
    u8 *gbk12_path;
    u8 *unigbk_path;
    u8 res;          
    if(src)//从25qxx更新
    {
        unigbk_path=(u8*)UNIGBK_25QPATH;
        gbk12_path=(u8*)GBK12_25QPATH;
        gbk16_path=(u8*)GBK16_25QPATH;
    }else//从sd卡更新
    {
        unigbk_path=(u8*)UNIGBK_SDPATH;
        gbk12_path=(u8*)GBK12_SDPATH;
        gbk16_path=(u8*)GBK16_SDPATH;
    }   
     res=0XFF;        
    ftinfo.fontok=0XFF;
     SPI_Flash_Write((u8*)&ftinfo,FONTINFOADDR,sizeof(ftinfo));    //清除之前字库成功的标志.防止更新到一半重启,导致的字库部分数据丢失.
     SPI_Flash_Read((u8*)&ftinfo,FONTINFOADDR,sizeof(ftinfo));    //重新读出ftinfo结构体数据
     LCD_ShowString(x,y,240,320,size,"Updating UNIGBK.BIN");        
    res=updata_fontx(x+20*size/2,y,size,unigbk_path,0);            //更新UNIGBK.BIN
    if(res)return 1;
     LCD_ShowString(x,y,240,320,size,"Updating GBK12.BIN  ");
    res=updata_fontx(x+20*size/2,y,size,gbk12_path,1);            //更新GBK12.FON
    if(res)return 2;
    LCD_ShowString(x,y,240,320,size,"Updating GBK16.BIN  ");
    res=updata_fontx(x+20*size/2,y,size,gbk16_path,2);            //更新GBK16.FON
    if(res)return 3;       
    //全部更新好了
    ftinfo.fontok=0XAA;
      SPI_Flash_Write((u8*)&ftinfo,FONTINFOADDR,sizeof(ftinfo));    //保存字库信息
    return 0;//无错误.        
} 

红色的代码表明是从flash开始更新，我有点不理解，意思是从外部flash中读取数据，然后再刷入外部flash里面，对吗？
如果是这样的，好像这样做，没什么意义。。。。。。只要保留从SD卡刷flash，这一步，不就行了吗？？
是不是我哪里对这段程序理解不对啊，望原子哥给点提示。。。。。。。。

正点原子

回复【4楼】冰封小凯:
---------------------------------
1，是的。
2，因为我们的外部FLASH，分成3部分了：字库部分，文件系统管理部分（模拟成U盘），用户使用部分。
所以字库从外部flash更新就是：从模拟U盘读取字库，刷入字库部分flash区域。

冰封小凯

回复【5楼】正点原子:
----------------------------
原子哥，你这样说我就有点明白了，可是，咱们都知道，没法像SD卡那样，通过PC机，直接下载字库文件到W25Q64 flash
芯片的文件管理部分，然后通过这个函数转移到字库部分。
按照你的说法，是不是这个意思；我们可以通过文件系统将SD卡的内容转移到W25Q64 flash芯片的文件管理部分，然后通过
这个函数设置从flash更新字库，达到更新字库的目的，是这样吗？

正点原子

回复【6楼】冰封小凯:
---------------------------------
是可以这么做。

冰封小凯

原子哥，今天晚上，我对这个问题进行的一下验证，结果很令我吃惊，竟然，没有出现我在这个贴子里所猜测的那个问题。
我验证的方法是在汉字显示实验主函数的最下面的那个while（1）循环里添加了一个读flash第二个和第三个字库的倒数15个
字符，通过JTAG，输出观察，验证这个字符是不是很来的字库的内容相。结果跟原来的一样。。。。。。。


原子哥帮忙试一下这个程序，使用前得把这个压缩包的system文件拷到SD卡根目录，因为我把第二第三个字库的倒数15个字符
改了一下，方便测试，下载到战舰开发板上，刷新一下，flash字库，就可以通过调试观察，我定义的buffer内容，进行验证了。。。

正点原子

回复【8楼】冰封小凯:
---------------------------------
最后一次是写入多少个字节？

冰封小凯

回复【9楼】正点原子:
---------------------------------
不是第三个字库GBK16总大小的字节数吗？我觉得主要是看写入的第二个GBK12字库末尾的字节，看看有没有发生改变就，这个是重点。。。。。

正点原子

回复【10楼】冰封小凯:
---------------------------------
没有问题的了。
你写4096，无非就是把后面的数据多写了一点点罢了，后续你还是会重新写一次。

冰封小凯

回复【11楼】正点原子:
---------------------------------
对啊，它是先读出整个扇区到数组里，忘了这一步了，我一直还怀疑，为什么每次写入那个SPI_FLASH_BUF[]数组，只写后面那部分，而没有管前面的数据。原来，前面的数据存放的是擦除前的数据。

谢谢原子哥的辛勤帮助。。。。。。。