建议尽快升级到Lib3.0（std periph & USB）

2万 · 2009-4-22 10:22

新的库产生的代码明显减小
但是对比源码看，相对2.x并没有多少改动，最后发现效率来源于ST对库的架构做了优化

stm32f10x_conf.h 中可以看到一部分
以前是一堆宏定义，自己开关
现在时自己控制对include的开关

中断向量映射ISR程序：
以前是所有ISR都有一个空函数
现在是所有中断默认到一个Default ISR,用户自己声明一个ISR会自动覆盖相应中断到Defaul ISR

当然，对ARM CMSIS的支持，使我们更方便重用
Doxygen的支持，我们可以用工具自动产出很多文档，更是节约了不少无谓的人力

只看该作者 · 2009-4-22 10:45

新的ISR应该怎么产生，这块儿变化最大了

只看该作者 · 2009-4-22 10:50

2万 · 2009-4-22 12:04

用2.x的库编译，出来是46K
换新的库，居然只有34K

都是把Optimization的Level设置为0

所以，好奇才去分析ST新的库的架构，确实有很多值得我们学习的地方。
这种思路，做不用库的纯裸奔也用得上。

只看该作者 · 2009-4-22 18:32

偶的Optimize Level设置为High。。。
并且，Multi-file compilation，Discard Unused Publics没有用，以后也44。

只看该作者 · 2009-4-22 19:56

改进的是，在极高优化下，以前中断Vector被优化掉的现象没有了，这个问题以前给ST的工程师发过mail，在新版本的库中确实得到改进。

但如果使用IAR的最高优化（最大Size优化+Multi-file compilation+Discard Unused Publics），某些中断会被优化掉，需要修改stm32f10x_it.c文件解决。是否要向ST提供解决方法？

2万 · 2009-4-22 20:31

这是早年Keil C51留下的经验教训。
等功能都基本OK后，再开优化。

只看该作者 · 2009-4-22 23:15

最大的改变是：FWLib3.0的封装更加完美，移植起来更方便。它把中断,cortex m3相关的东西封装好，然后把stm32外设另外封装好，之后在链接起来。你用的时候可以选择用库或者不用库，但哪些烦人的寄存器定义和映射你都可以用。另外对中断那里的重新封装更加的方便，代码也会少很多。总之，比2.0有了很大的进步。

至于优化嘛，嘿嘿，一般我也开Low那档，本人原则(工控)，稳定压倒一切，容量不够换大的嘛。

只看该作者 · 2009-4-22 23:24

新库确实感觉很清晰！！！

有些代码我看得比较糊涂，大家感觉怎么样？？

设置时钟的函数看着还可以，但是有些..............
比如说这个函数
void GPIO_Init(GPIO_TypeDef* GPIOx, GPIO_InitTypeDef* GPIO_InitStruct)里面的语句很多啊

那些库读起来大家觉得是小菜一碟么????

是不是多看几遍就会懂了？？？

只看该作者 · 2009-4-23 03:29

偶的代码是在Versaloon上用的，功能基本都OK了，所以偶希望占用的空间越小越好，就都使用最高的优化级别。
其他应用的话，肯定根据需要选择不同的优化级别。

3.0.0的库其实也有一些可以改进的，比如：system_stm32f10x.c中的static void SetSysClockTo72(void)函数：
/*!< PLLCLK = 8MHz * 9 = 72 MHz */
RCC->CFGR &= (uint32_t)((uint32_t)~(RCC_CFGR_PLLSRC | RCC_CFGR_PLLXTPRE | RCC_CFGR_PLLMULL));
RCC->CFGR |= (uint32_t)(RCC_CFGR_PLLSRC | RCC_CFGR_PLLMULL9);
这个默认了系统使用8M晶振，如果使用12M的话就有问题了，2.0.3的库中的RCC_Configuration函数中可以这么实现：
/* PLLCLK */
RCC_PLLConfig(RCC_PLLSource_HSE_Div1, (_SYS_FREQUENCY * 1000000 / HSE_Value - 2) << 18);
这里只是默认系统频率是晶振频率的整数倍。使用8M或者12M晶振，只需要修改HSE_Value即可。

只看该作者 · 2009-4-23 08:47

如果你使用了库，那么在 stm32f10x_conf 文件中需要重定义时钟的，再那里你可以重新配置。总的来说，比2.0好。

void GPIO_Init(GPIO_TypeDef* GPIOx, GPIO_InitTypeDef* GPIO_InitStruct) 是一个端口寄存器初始化，指针和结构体概念搞明后看起来你就会顺畅多了。

2万 · 2009-4-23 09:22

我们用它的目的，一是使用它的稳定性，二是降低自家的重复劳动

只看该作者 · 2009-4-23 10:11

顺便问问

只看该作者 · 2009-4-23 21:20

你们的编译速度变慢了么？

只看该作者 · 2009-4-23 21:41

取消BROWSE INFORMATION选项

只看该作者 · 2009-4-23 21:55

还有那个BROWSE INFORMATION功能我得用啊！！！

我估计是新库的头文件不在keil的INC导致编译速度慢的

2万 · 2009-4-24 11:28

原因是inlcude文件的搜索目录更多了

因为ST把不同的.h文件放置于不同的目录，编译就会按照顺序挨个去找。
以前只有一个include目录，现在要搜索好几个，自然会慢些。
另外Keil的编译器会自动去分析你include的.h文件是否有更新，
拆分.h文件增多也会让编译速度下降。

我自己程序源代码也从原来的六七个c文件，功能化整理成了18个c文件了。
我现在很少build ALL了，因为一次要一分钟零十秒（刚测试的）。

总体而言，架构优化还是值得的。
少build All就可以了

只看该作者 · 2009-4-25 11:06

我看原因小有可能是5楼没选 Options For TArget 下的 Use MicroLIB吧！！！

选好还是不选好呢？答：不清楚！

----------------------
另外：楼上说的听起来有道理！！！

只看该作者 · 2009-4-25 14:39

2万 · 2009-4-25 14:45

MicroLib是一个阳春版本的C运行库，体积小了，功能弱了。
就像赛扬相对奔腾一样，价钱便宜了，功耗上去了。

举个例子，C程序必须有的main函数的标准声明是：
int main(int argc,char *argv[]);
但是MicroLib把它简化成了：
void main(void);
没有了参数没有了返回值。

一般情况下，建议选用MicroLib库，对STM32来说，它正合适。
没必要充大款，非把程序无缘无故搞得挺肥大的。

更多内容，请参看Keil的网站链接：
相关链接:http://www.keil.com/arm/microlib.asp

建议尽快升级到Lib3.0（std periph & USB）

我没看明白

看了像是优化了不少

我的代码减小了10K的样子

偶的代码怎么米有减少那么多？

3.0.0还没完美

我在调试的时候一般不开优化

FWLib3.0 和 FWLib2.0比较

请问 库的代码大家都能看得懂么？

这个库很简单，有一定C语言的功力和经验都能够很容易看懂

如果你不使用库的话，要在system_stm32f10x.c中根据实际定义时

对一般的工程师而言，库的代码看懂应该是没什么问题

哪里有下？

用了新库之后，MDK编译速度变慢了！！！

看看你OPTIONS的设置

哦 请问15楼 你这是在哪里知道的？

新库确实会编译变慢

4楼代码减少很多，5楼代码减少的不多！！？？？

总体而言，架构优化还是值得的。

那就顺便唠叨下MicroLib

核心会员奖章

坚毅之洋流

十世金身

技术导师奖章

精华达人奖章

甘甜之泉水

以坛为家

技术高手奖章

技术领袖奖章

精英会员奖章

奔腾之江水

技术奇才奖章

社区建设奖章

湍急之河流

常驻人口

请问库的代码大家都能看得懂么？

哦请问15楼你这是在哪里知道的？