首先在这里要提一下Keil的网页转换工具FCARM.exe的使用，花费了我好几个小时。TI也有一个类似的程序，是Makefsfile，并且源码公开的。
这个FCARM.exe，一直认为只要这个custom arguments里边设置好了FCarm.exe的路径就可以在勾选 include in target build后会自动执行这个程序，转换网页文件，这样岂不是很方便，要不把这些网页文件加到右边干什么（后来明白加到右边只是起到浏览和修改的作用），但实质上，Keil在build之前并不执行程序，而是在translating，这样即使你所有的配置都正确，它并不是在执行程序，只是translating。所以不能勾选include in target build，这样做是不行的。不过也有可能是哪个地方我没设置到，有经验的指点一下啊。
这样做问题并没有解决掉，我们要的是方便地在Keil build的时候同时对网页文件自动地经行转换，而不是每次都进入到DOS里边，当然在命令行下可以毫无疑问的正常运行，但并不方便。
这样就有另外一种解决方法，那就是在build前设置运行user 程序：
这样就把问题解决了。
web.inp是个什么文件呢？有了它结合Keil的run user program很方便，它就是把FCARM.exe 这个程序在命令行中执行的时候，后面的参数就保存在这个文件中，和在FCARM后输入命令没什么区别。注意要使用两个@@，两个@作用相当于命令行中的一个@，但是这里两个不可少，后面的地址给出网页源文件相对于工程的所在目录的地址！
所以最后的网页数据应该是26584+18*8=26728/1024=26.1kb
这是不添加网页文件时的大小：
这是添加网页RS_web.c后的大小：采用了三级优化：
可以看到网页文件的数据被完全编译进了RO-data段：足足多了26316字节约25.7k。
发现经过编译之后的大小要变原来的c格式的数据文件要小一点，小了26728-26316=412个字节。由此可见数据文件似乎并没有足量的全部编译。
我们总共转换了17个文件：
17个文件大约39kb，按压缩率89%计算，最后的大小应该是34kb左右，和上面的26kb还是有一段举例。这个34kb是不准确的，经过准确计算这17个文件的大小实际为29704个字节，合29K左右再按压缩率89%计算，约为26436个字节，合25.8K，和上面已经很小的差距了。
也就是说，把所有网页文件的字节数加起来，乘以压缩率，就基本上是最后写进flash里边的大小了。
注意使用FCARM转换后生成的网页数据，一般是结合Keil的RL这种的TCPnet来使用，和TI的makefsfile工具产生的数据有很大的不同，不能简单的通用。
初步看了看，有以下几点不同：
1.FCARM产生的一个C文件，makefsfile产生的是一个.h的头文件
2.FCARM把所有文件生成的数据都放在了一个数组里边，而makefsfile对每一个文件转换成一个数组。
相比Keil自带的这个转换工具，我觉得makefsfile更好用，更灵活。
比如你开发了好几个网页，在当前工程的文件夹myweb下有index.htm,404.htm,styles.css，page1.htm,page2.htm,..然后这些网页中引用的图片都放在了myweb/images下的这个文件夹，而只需要在命令行下（当然如果你要经常修改网页，你也可以按照上面的方法，把它放到Run user Program before build栏里边，这样每次修改了网页之后，只需要重新编译一下即可。）敲入下面的命令就可以转换了：最好是把makefsfile复制到myweb所在的同一个路径上，都在当前工程下。
makefsfile -i myweb -o webdata.h -h -r
-h:生成的网页数据不包含http头部。
-r：修改网页后重新生成相同文件名的网页数据时不用询问，直接覆盖原来的数据文件。
最后我们只需要把这个头文件include到lmi_fs.c文件中，编译之后也是被放到了RO-data段中。
我自己创建的几个简单的例程，我明天会放到网上，供网友参考。
[
本帖最后由 academic 于 2010-11-8 16:44 编辑 ]
提升卡
变色卡
千斤顶
1/9 
京公网安备 11010802033920号
Copyright © 2005-2025 EEWORLD.com.cn, Inc. All rights reserved
