感觉ST写固件库人有问题

ggch

感觉ST写固件库人有问题 [复制链接]

我开始用1.0版本固件库，后来升级2.0.3费了好大劲。主要里面移植有操作系统。
现在想用带两个CAN的片子，本想直接把这CAN文件覆盖掉就可以了。谁知里面连个数据结构
比如以前用u8 u16  U32
可新库用 uint32_t 等


这些东西都要该，有那么必要吗？还有整天把库整的不兼容，我感觉对于大公司，这种做法实在不能接受。

XY

                                 好多受害者，不止你一人，感觉写库的人不是ST原装的似的，有游击队的嫌疑

eeworld_ken

                                 哈哈

lee437

                                 哈哈。 同感

ldmark

比如以前用u8 u16  U32
可新库用 uint32_t 等
------------------------------------------
uint32_t更标准。
C99标准直接定义的类型。

估计写库（主要）的，换人了。

thanks1

整了一上午，把原来的操作系统也加上

才编译通过，还不知道能不能运行。

原来操作底层的库大部分都得动。郁闷，本来就在原来基础上整加一个CAN，代码就动这么多

ersuo4s

                                 哈哈

emile1732

                                 我从2.0 升到3.0 改的东西太多了。。。

sheji105

                                 2.0 升到3.0 这个真是麻烦啊，开始时用的是2.0的，可现在官网上的文档都是3.0的了，不改很麻烦，改了也麻烦。

liu21b

3.0及以后版本的库是基于ARM的CMSIS标准的，里面的类型定义都有了统一的规范。

ST官方有个文档，就是讲从2.0升到3.0的库的一个应用笔记AN2953

http://www.st.com/internet/com/T ... NOTE/CD00228916.pdf

amanonline

                                 真的挺麻烦的,虽然我从来没用过.

ruiurijunxian

                                 这个到是比较郁闷

gzzhida

                                 我也遇到过这些问题，以前凑合用，为了使用串口4和5，不得不升级，这玩意像生孩子，生一边，以后就省劲了

inonme

                                 st的库写的极其臃肿不堪

guiziqian

                                 这些改动主要还是为了标准化，没什么可抱怨的。

linwei1234

我也遇到过这些问题，以前凑合用，为了使用串口4和5，不得不升级，这玩意像生孩子，生一边，以后就省劲了

“生一边，以后就省劲了”  赞同

ling.wo

st的库写的极其臃肿不堪

确实如此，但对STM32问题不大，对STM8影响大

congyue

                                 

lmx5078

我倒是觉得固件库还是很还用的，就像WIN的API函数一样，不用难道每次都要自己写吗！
入行不深，个人观点！

chou

比如以前用u8 u16  U32
可新库用 uint32_t 等
------------------------------------------
uint32_t更标准。
C99标准直接定义的类型。

估计写库（主要）的，换人了。

如此看来，实际上之前的那帮人，根本连C99的标准是何物都不知道 。。。