sdk demo 一大堆没用的代码, 有各种各样的 api 又没资料教怎么使用, 封装又太乱, 求出个像 esp8266 一样的接口 SDK, 不知道搞这么多库进去干嘛, 是别人没网去找库吗? 太恶心了, 连一个延时函数也要封装一下! , rtos 那些优先级被使用 , 等等用的不清不楚, 高一大堆乱七八糟的代码!
很多时候呢, 埋怨并没有用, 资料文档确实挺少, 毕竟生态还在建设嘛, 你认为 demo 没有用, 可能仅仅对你没有用而已, 只是我觉得还是挺好用的. 有这时间还不自己多摸索一下, 不用那么浮躁嘛, 现在不是有问答社区了, 不会用的问就好了嘛, 大会看到能帮忙的都会帮忙回答.
Makefile 工程模板可以么? 我正在调试, 调试 OK 后共享给大家
我这边搞了个 MakeFile 的模板, 可以参考 http: //ask. winnermicro. com/article/57. html
SDK 确实用起来不是很方便, 各个模块耦合性很强, 很难单独拿出某一块来用. 官方的想法可能是想做一个大而全的平台, 想让用户可以傻瓜式的开发. 但是离目标还很远. 这一点其实我觉得完全可以仿其他厂家成熟的模式, 就像国内为什么那么多和 STM32 类似的芯片, 就是因为大家已经熟悉那个框架了, 容易上手. 个人提几点建议, 也许有助于该芯片的发展:
1, SDK 分层模块化, 底层包装寄存器等硬件外设, 各个功能模块完全独立. 应用层再根据功能划分包装, 可以综合多个模块实现一定复杂功能模块. 这样既适合裸机基础应用开发, 也适合顶层复杂应用软件开发.
2, SDK 需要可裁剪, 类似前面所说, 做一个 LED 闪烁, 编译出来都有几百 K 了, 虽然有些宏定义可以关掉, 但是有些不管有用没用都不能关掉, 否则报错. 我觉得没用的模块不能关掉就是 SDK 的最大的 BUG, 比如蓝牙和 WIFI, 如果说设计这个芯片的时候就是设计成必须开启蓝牙和 WIFI 才能工作, 那我无话可说, 否则就是 SDK 设计的问题.
3, 资料的问题以及软件 BUG, 如果说官方没精力维护和更改, 完全可以发动大家群策群力. 发布悬赏, 发现一处资料问题或一个软件 BUG, 奖励若干元, 相信改进起来比官方效率高很多. 官方还可以节约一笔不菲的养人费用. 就好像我现在摸索这个芯片, 都找到好几个 BUG 了, 但是没地方讲, 讲了也不知道有没有用, 只能让 BUG 继续存在了.
本人整理了一下 SDK, 弄了个 VSCode + CMake + Ninja 的项目模板, 有需要的可以去试试
研究了几天了, 发现咱们这 SDK 以及对应的教程有如下特点:
1, 大而全
2, 多而乱
有点像头脑风暴, 不管先后顺序, 都有了, 感觉虚无缥缈, 一点也不踏实.
希望针对以上问题进行改进, 尤其是介绍清楚以下内容:
1, 各个功能函数各种前缀是啥意思?
2, 针对示例重新完善, 主要是示例是否在操作系统下运行, 建议参考下 RT-THREAD 的教程.
第一: 用 demo SDK 开发代码混乱.
第二: SDK 集成的第三方库不易维护, 升级, 扩展.
第三: 有些功能往往不需要太复杂, 用的也不多. 自己写的代码效率高, 导致自命名文件名被集成的第三方库占用 (不得不另起文件名) .
第四: 开发自己程序往往都是针对性的功能, 你实际用的功能不及 SDK 中的库十分之一.
第五: 程序越大, 下载烧录越慢, 比如: 明明就点一个 LED 程序, 程序实际只需一秒下载完成, 偏偏花了十多秒下载完成.
第六: SDK 越复杂, 问题越多, 因为不是你写的代码, 那些功能怎么样处理和使用的都不清不楚, 如果不买 调试器 很难查到 bug. 这就又涉及到你必须花个 70 多买个调试器.
对于喜欢精简代码, 强迫症的我, 用着很不爽!
官方要是少花时间去集成第三方库, 如果开发一个 SDK 只提供芯片的接口, 将接口, 芯片资料文档写好, 总比去弄这些花花草草好, 因为第三方库是通用库, 网上什么资料没有, 网上没有的资料, 你集成进去也没有用, 除非官方自己写第三方库教程, 不然别人还是不知道怎么用, 这也是国内芯片永远比不了国外芯片是有原因的!