本来不想用ttf字体的。因为变态的硬件工程师只接了4M Bytes的nor flash。除去系统和驱动,给应用程序剩下的空间只有2M。这年头2M的flash够干嘛呀! 但新的客户要求程序更花哨,更漂亮,添加了很多效果。其中不同大小的字就有几种。如果用点阵字库,一种字体也需要创建多种字库。而客户给的汉仪菱心体ttf字库才1.5M bytes。综合比较觉得使用ttf字体在存储空间上会划算一些。 参照http://www.minigui.org/cgi-bin/lb5000/topic.cgi?forum=6&topic=5548帖子的步骤终于添加了ttf的支持。步骤如下
1 . 安装freetype-1.3.1库
手动编译成动态库后 编译minigui程序总是报错误error: no memory region specified for loadable section `.plt' 。 我只好编译成静态库libttf.a。将库拷贝到编译器的连接库目录。在编译器的inlcude目录下创建freetype1目录。并将头文件拷贝到该目录下。
2. 启用ttf
可以按常规make menuconfig中启用。我直接修改config.h文件,找到#undef _TTF_SUPPORT, 改为#define _TTF_SUPPORT 1 ,找到#undef _UNICODE_SUPPORT, 改为#define _UNICODE_SUPPORT 1 。 然后make install编译minigui库
3. MiniGUI.cfg文件修改
将arial.ttf和stxinwei.ttf 拷贝到设备的/uar/local/lib/minigui/res/fonts目录下。
truetypefonts改为
[truetypefonts]
font_number=2
name0=ttf-arial-rrncnn-0-0-ISO8859-1
fontfile0=/usr/local/lib/minigui/res/font/arial.ttf
name1=ttf-stxinwei-rrncnn-0-0-GB2312
fontfile1=/usr/local/lib/minigui/res/font/stxinwei.ttf
4. 应用程序编写
HWND hwnd;
HDC hdc;
HWND timeedit, spin;
SIZE size;
/* 创建编辑框使用的逻辑字体 */
timefont = CreateLogFont ("ttf", "stxinwei", "GB2312",
FONT_WEIGHT_REGULAR, FONT_SLANT_ROMAN, FONT_SETWIDTH_NORMAL,
FONT_SPACING_CHARCELL, FONT_UNDERLINE_NONE, FONT_STRUCKOUT_NONE,
30, 0);
spin = CreateWindow (CTRL_SLEDIT,
"nihao?",
WS_VISIBLE,
10241,
0, 250, 400, 200, hWnd, 0);
SetWindowFont (spin, timefont);
注意CreateLogFont 创建的字体大小好像不能超过32。超过后显示汉字会异常。还没有查原因。英文则可以更大。另外不知是不是库的问题,我的应用程序在不使用ttf库前,9M的空闲内存可以跑好几次。而使用ttf库后,仅仅连接了ttf库,跑一次都经常内存不够。也不知道什么原因。
同事在wince下写了个网络驱动,让我帮忙写个小程序测试网络流量。这还不简单。三下五除二一下子写了个测试程序出来。主体思想是建立连接后创建两个线程,一个专门收,一个专门发。然后定时统计收发的数据长度。主要代码如下:
//发送线程
void * __stdcall thread_send(void * lpparam)
{
int slen;
SOCKET m_sock = (SOCKET)lpparam;
char * send_buf = (char *)malloc(1024);
while(!bthreadstop)
{
slen = send(m_sock,send_buf,1024,0);
if(slen == SOCKET_ERROR)
{
CString str;
str.Format(_T("send error:%d"), WSAGetLastError());
AfxMessageBox(str);
break;
}
total_send += slen;
Sleep(50);
}
free(send_buf);
return 0;
}
//接收线程
void * __stdcall thread_recv(void * lpparam)
{
int rlen;
SOCKET m_sock = (SOCKET)lpparam;
char * recv_buf = (char *)malloc(1024);
while(!bthreadstop)
{
rlen = recv(m_sock,recv_buf,1024,0);
if(rlen == SOCKET_ERROR)
{
CString str;
str.Format(_T("recv error:%d"), WSAGetLastError());
AfxMessageBox(str);
break;
}
total_recv += rlen;
}
free(recv_buf);
return 0;
}
void CTcptest_ceDlg::OnButtonConnect()
{
...... //连接代码省略
//connect ok.
CreateThread(NULL,0,(LPTHREAD_START_ROUTINE)thread_recv,(void *)m_sock,0,0);
CreateThread(NULL,0,(LPTHREAD_START_ROUTINE)thread_send,(void *)m_sock,0,0);
}
满怀信心的交给同事去测试。才一会儿问题就出现了。使用同样的代码,一个用evc编译后在wince模拟器上跑,另一个用vc编译后在PC上跑。
现象:
1. 终端发 PC收 持续一分钟没断线。
2. 终端收 PC发 持续一分钟没断线。
3. 终端和PC同时收发,几秒后终端发送和接收的数据都为零。
改用两台PC互相通信。 同样的代码,同时收发速度达到11.9Mbyte/s。这个速度还算正常,也证明了我的代码至少表面上是OK的。
添加打印后发现 PC 在开始的1秒内发送64K的数据后就停住了,后面持续很久发送数据量都为零。总的表现就是PC端猛的发一下数据,然后等待,然后又猛的发一下数据,又等待。如是循环。 根据http://www.techrss.cn/html/2007/05-20/18912.htm帖子说明似乎是PC发送太快了。 在PC的send线程中sleep一下,情况确实有所改善。等待10ms时,传输大约3M的数据后不能再发送。 等待50ms时,传输了大约50M的数据。
这是个很奇怪的问题。为什么PC发得太快会导致wince终端网络不能收发呢?