请教UCGUI如何固化字库？谢谢！----已有解决方案
我现在用44B0X，UCOS和UCGUI已经能运行了。没有仿真器，每次修改程序都需要烧录。由于汉字库太大，烧录时间太长。我希望能一次性烧录字库固化，以后再烧录只需要烧程序就好。需要解决的问题：
1 字库怎样做成单独的.HEX或.BIN文件
2 UCGUI的字库结构怎样让它按指定地址编译
3 怎么让UCGUI取固化的字库
谢谢哪位大侠指教!
admin-ucgui:
解决后的优点:
1. 字体不占用RAM空间,放在FLASH当中.
2. 一次性将字体烧写到FLASH当中后,无须再次下载.
3. 方便调试, 减少大量不必要下载的数据.
[此贴子已经被admin-ucgui于2007-3-29 16:44:22编辑过]
admin-ucgui
等级：管理员
文章：1042
积分：7778
注册：2003-12-30
第 2 楼
楼主提出的问题是一个比较好的问题, 很好.
的确,UCGUI中的字体不是独立的二进制文件, 它时包含了字符的点阵数据以及将这些数据关联起的结构.所以是根据其结构来进行分离, 具体可以如下:
1.在字体的.C文件中,有如下类似结构:
GUI_CONST_STORAGE GUI_FONT GUI_Font8_1 = {
GUI_FONTTYPE_PROP /* type of font */
,8 /* height of font */
,8 /* space of font y */
,1 /* magnification x */
,1 /* magnification y */
,{&GUI_Font8_1_Prop}
, 7, 5, 7
};
我们把这个结构抽出来, 剩余字体.c文件单独指定绝对地址编译成BIN文件, 然后把的地址值&GUI_Font8_1_Prop填充回到GUI_Font字体结构当中.
这种分离的方法, 是把字体的.C文件与UCGUI分开了,其实如果C编译器本身支持绝对定址的话, 就不用了, 据我查找了多处资料, 发觉在ICCAVR的C编译器支持如下定义:
#pragma abs_address:<address>
#pragma end_abs_address
使用如下:
#pragma abs_address:0x4000
const unsigned char string[] = "this is a test";
#pragma end_abs_address
具体可以参考"AVR单片机C语言开发入门指导"一书,清华大学出版, 在这里可以下载到:
http://www.mcu123.com/news/Soft/ebook/uc/AVR/200608/16.html
有关程序区绝对定位的内容是:
4．6．4 程序存储器的绝对定位-----220页.
大家可以下载看一看, 我想如果有这种类似的编译器关键字支持, 那么这个程序区绝对定位就很容易使用了, 那就可以对字体的.C文件进行绝对定位了.不知道其余的编译器是如何支持的.
在C51中,也有程序区绝对定位的支持, 可以指定特定函数的起始地址.但不知道要实现这种UCGUI中字库的绝对定位是如何使用, 熟悉的朋友可以帮忙指出.
研究uC/GUI, 构思新的嵌入式GUI,有挑战性,爽.......
网名:ucgui
Google Wave: ucgui.com@gmail.com
QQ: 106719880
UCGUI研究学习群--12111753
UCGUI Wave, 查找 with:public UCGUI
举报帖子
删除单贴
复制贴子
加为精华
单贴屏蔽
帖子评价
admin-ucgui
等级：管理员
文章：1042
积分：7778
注册：2003-12-30
关于这个问题到现在已经有将近一年时间了...
现在我才能提出一个比较完善的解决办法,希望对大家有帮助.
先前提出的办法,有好几个地方都没有讲清楚.其实倒是问问题的人说得比较清楚,主要有如下几个问题:
1. 如何指定常量数据编译到FLASH或者其它的ROM当中.
2. 如何让给常常量数据一个精确的定位,因为FLASH除了常量还有代码,所以空间上必须仔细安排.
3. 调试时是否有可以支持常量数据的下载工具.即Flash Loader类似的工具.
现在我们来具体的讲一讲:
一. ADS1.2环境的做法.
[1]. 这里有一篇E文的文章,专门讲解了分散加载文件的格式,如下:
http://www.ucgui.com/ucgui/DUI0151A_ADS1_2_LinkUt.pdf
[2]. 另外,在另外一份电子书:
"ARM体系结构与编程.pdf",这本书比较大,在这里就不上传了,大家在GOOGLE上查找一下很容易找到的.这本书中也有专门讲解了ADS的链接器ASLINK的知识.
[3]. 这里提供具体的SCF分散加载文件如下:
假如仅包含了F6x8.c这种字体,要将这种字体编译链接至0xf000,scf文件如下:
ROM_LOAD 0x0
{
ER_RO +0
{
*(+RO)
}
ER_RW +0
{
*(+RW)
}
ER_RO_CONST 0xf000
{
f6x8.o(+RO-DATA)
}
ER_ZI +0
{
*(+ZI)
}
}
如上,指定以上文件来进行链接时,f6x8.o中的常量就编译到0xf000起始处了, RO-DATA表示的就是只读属性的字体.
如此将字体定义到FLASH中之后,就不必加载至RAM当中了,只要将字体烧写至这个指定字体一次就可以了, 大大方便了下载过程,减少了不必要的数据下载以及RAM占用.
二. IAR环境的做法.
IAR环境下也有类似的链接命令文件,这里我仅提供一份参考资料,当中详细讲述了如何进行链接命令文件的书写,以达到常量数据定位到FLASH当中的目的.
http://www.ucgui.com/ucgui/armbegin.pdf
三. GNU环境下的做法.
GNU工具链下,达成这个目的就更加的容易了,同样仅提供一份LD链接器的说明文件如下:
http://www.ucgui.com/ucgui/ld.pdf
总结:在嵌入式当中,由于各个器件的内存布局情况千差万别,所以在链接的时,各种链接器都有相应的链接文件,有的默认情况下不使用链接文件,或者是使用默认的链接文件, 在ADS环境中,可以通过一些能数来配置,生成时仅包含RO/RW/ZI三个默认段.
四. 关于字体固化的其它思路的做法.
在后期的UCGUI390版本以后, 可能也是考虑到了那种.C文件格式的字体不太好, 要独立指定字体常量数据的地址不太方便, 因此后期UCGUI又推出了其它两种格式的字体:
[1]. SIF字体-----系统独立字体.
优点: 相比.C字体格式文件, 其最大的优点就是与具体的UCGUI代码是两个独立的部分, 可以独立的安排一段内存空间来存放SIF字体的二进制数据, 这其实也就解决了我们上面通过LINK的方法来特别指定.C格式字体的常量数的位置的问题.
缺点: 与XBF字体相比. 他的缺点就是必须给SIF字体的二进制数据块分配一段内存空间, 对于内存空间比较紧张的情况, 不太理想.
[2]. XBF字体-----外部位图字体.
优点: XBF字体与SIF字体一样, 同样无须用链接器来指定其链接后在映象中的地址, 它的二进制字体数据同样也是与UCGUI代码是分离的两个独立部分, 而且他更无须将字体数据映射到一段内存空间, 可以将XBF格式字体放在一段不用映射到内存空间的存储介质上(如通过一I/O读写), 通过一个回调函数来读取XBF字体的数据.
缺点: 目前看来, 除了因为这种介质的读取速度比较慢而稍微影响到字体的显示之外, 没有别的坏处, 它一无须用LINK来指定字体数据的内存地址; 二更不必要映射一段内存空间; 三还可以提供足够多的字体支持,只要存储介质空间大.
具体的关于UCGUI支持的这三种格式的字体, 详情可以参见这个贴子:
