现有的SDK太杂乱,后续有推出精简版的计划吗?

[Harvey_PH]

现在的YCT工具为了芯片的兼容,生成的工程结构简直没法看,各种乱七八糟的东西全部堆在一起,逼死强迫症是一回事,代码里也会有很多不必要的冗余,导致排查问题的时候很麻烦.
这是自带的HelloWorld DEMO,什么都没加,编译出来就10几K了. ,全系列芯片的CMSIS都给你放进来 . ,(也不知道为什么要单独列出来)
本来云途最开始的SDK就存在外设功能过度封装,臃肿复杂的问题,比如控制GPIO的文件就有irq---driver---port_hw_access.c----port_hw_access.h----gpio_hw_access.h,排查问题时少一个都不行,看的头疼.现在随着工具自动化的提高这样的情况愈演愈烈了,各种不明所以的文件充斥工程,看起来就头大.
我也不是说这样的库模式一定就不好,但是是否后续可以考虑和ST一样对于常用的外设,简化软件架构,出一个精简版的LL SDK.

[Harvey_PH]

这是某友商的标准库模式,

[Frankie]

• SDK有自己的设计理念和架构，合理的分层增加了软件的可靠性/维护性/可读性
  • 过度的分层会增加代码大小？
    • 不会，开启编译器优化会解决相应的问题，代码大小不会大很多
  • 所有驱动写在一个.c 文件里面好吗？
    • 代码维护困难
    • 可重用性差
    • 调试和测试困难
    • 编译时间较长

你看到的KEIL结构混乱是因为KEIL只能创建一级目录导致的（建议你换成IAR或者其他工具）
下图是IAR生成的工程结构：

[cdmar79]

同感，我的建议：

1. sdk 中，建议把对mcal支持的函数和基础寄存器的操作函数进行分离；
2. 如我，使用中其实很多都是独立控制的，比如rcu ipc，有时候设备开有时候又需要关，然后，你们目前CLOCK_SYS_Init，我就傻眼了。
3. XXX_hw_access.h有这么个意思，想把基础寄存器操作独立出来，但是，没完善（没彻底），而且，没有直接基于XXX_hw_access的demo，导致我们上又上不来、下又下不去（下去就要破开管理层函数，一点点磨，太痛苦了）

[pengh1994]

同感，比如GPIO输入读取，必须把整个port的值读回，再自行根据所在的PIN_index分解。