Codewarrior下开发Kinetis使用ewl_noio库以减少代码空间

只看该作者 · 2015-3-29 18:20

在一些对成本敏感且控制功能简单的应用领域，小Flash空间的芯片比较受欢迎，以前这部分都是8位机的地盘，而现在随着ARM产品越来越丰富，低端产品的覆盖率也在增加，其也开始慢慢觊觎这部分市场了。飞思卡尔Kinetis系列中KL02和KE04就是其中比较有代表性的两款产品系列，这两个系列里有部分型号拥有最小8k Flash空间管脚数最少14或者16个SSOP封装，哎，ARM做到这份儿上不容易啊，呵呵。。。

对一些小存储空间的MCU来说，每一个字节的空间都是宝贵的（粒粒皆辛苦啊），所以我们在使用小Flash空间开发时除了要对代码进行功能优化之外还要注意减少不必要的空间损耗，比如一些冗余的常数变量，用不到的API函数或者隐藏起来的一些自带函数库。今天我想说的就是在用Codewarrior10.x开发KL02或者KE04时如何去掉一个占空间的大户，即Debug I/O库（实际上就是一些printf和scanf之类的打印函数实现），这个Debug I/O我们在新建一个工程时是默认勾选的，如下图所示：

这个库我们大多数情况下是用不到的，但是在最后编译时其却包含在其中，所以我们在对KL02 8kflash型号的芯片随便编写几个底层驱动后再编译就会发现8k代码空间已经没剩下多少了，下图为我添加了部分工程后编译生成的bin格式文件的大小（注意Codewarrior下面，虽然其生成的文件都是.hex后缀，但是实际上里面具体的格式可能是S19或者是纯二进制数据，这个跟配置的输出类型有关系），可以看到已经耗掉7k多的代码空间了，有点束手束脚的感觉。

这时我们可以通过对该工程配置，去掉其新建工程时自带的Debug I/O库函数（默认为ewl库），选择ew_noio，即不使用Codewarrior自带Debug库函数。具体工程配置和再次编译后输出的bin格式文件大小如下图所示，可以看到使用ewl_noio库之后大概空闲出4k左右的代码空间出来，这对一共才有8k Flash的MCU来说多出一半可用的空间，已经非常可观了，这下子就可以游刃有余的继续增加功能代码了。

只看该作者 · 2015-3-29 18:20

飞思卡尔官方的代码包中的基于Codewarrior10.4的工程默认都是选择ewl库的，即使能了Debug I/O函数接口的，而这个库所占的空间对大多数Kinetis型号来说不算太大，但是对只有8k或者16k代码空间的MCU来说已经不能再这样浪费掉了，所以这就需要我们手动去修改默认库为ewl_noio，即屏蔽掉了Debug I/O相关的函数库以节省空间。此外，实际上如果我们打算新建工程的时候，也建议在最上面截图中的I/O Support选项选择No I/O，其实现的配置和手动修改成ewl_noio库是一样的。

只看该作者 · 2015-3-29 18:38

对一些小存储空间的MCU来说，每一个字节的空间都是宝贵的，需要这样的设计

1万 · 2015-3-29 22:23

楼上说的有道理，不过目前的芯片已经空间不小了，好多都超过8 k

1万 · 2015-3-29 22:24

即屏蔽掉了Debug I/O相关的函数库以节省空间。

1万 · 2015-3-29 22:24

如果程序不是需求空间多就可以不用管

1万 · 2015-3-29 22:25

对一共才有8k Flash的MCU来说多出一半可用的空间

1万 · 2015-3-29 22:26

如果这样的，那么可以试一试

只看该作者 · 2015-3-31 19:39

刚刚好碰到代码空间不足的问题，谢谢你分享！
我想请教另外一个问题，在CodeWarrior 的工程中，我已经配置整个工程的优化级别为 O1 ，但是我又不想把某一个文件优化，随后就把这个文件设置优化级别为 O0，编译过后发现不能生成HEX 文件，如果那个文件回复回原来的默认优化级别（既O1，因为整个工程的优化级别都是O1），又能生成HEX文件。我想要在不优化某个文件的情况下，又想生成HEX文件，我应该怎么做？
如果你能帮我解决问题，我会真心的感谢你！