[参考译文] LAUNCHXL-CC1352P：CCS 可用性反馈

Josh、您好！

请随时在此主题上发布您的反馈。 感谢您愿意分享您的经验和改进建议。

Ki

谢谢！ 感谢您的支持。

在上下文方面、我将与同事一起使用 GitHub 样式的工作流和协作来处理项目。 我不熟悉 SimpleLink 平台、但不熟悉其他平台上的嵌入式开发。

总之、硬件和各种 SDK 协议栈之间没有太多抽象、SysConfig GUI 工具并不是真正用于比较 SDK 版本和平台之间的配置。 这些问题使得编写可移植和可维护代码变得更加困难。

例如、BLE 堆栈应独立于工具链和平台-当然、前提是硬件具有运行该堆栈的资源。 例如、应该可以 轻松地升级 SDK、而不必深入了解平台特定的配置和工具链版本、也不必了解"导出旧符号"选项等

在其他环境中、在次版本号之间升级库只是更改版本号的问题。 在 SimpleLink 环境中、将 SDK 从5.2升级到5.3可能意味着 SysConfig 中有许多更改和复选框(除了源代码更改)。

一些更具体的意见：

通过 Resource Explorer 可以轻松找到大量有用的示例。 好极了。 但是、对于每个 SDK 示例、至少有8个副本- NoRTOS 等、TI 编译器与 gcc 等 这些示例与 SDK 版本和 SysConfig 工具紧密耦合。 您不仅可以从一个示例中获取一些射频代码、还可以将其与另一个示例中的代码进行组合-它至少取决于您拥有的 SDK、电路板等  

2. SysConfig 中的电路板迁移("switch (beta)")功能不起作用、即使在同一系列中从一个器件移至另一个器件-它运行时没有错误、但会导致无线电无响应。 同样、这似乎是抽象失败、尤其是在无线电硬件相同的情况下。  

SysConfig 和堆栈配置之间的线路非常模糊。 例如、通过 SysConfig 维护哪些滤波器带宽、启用哪些频带等、SysConfig 显然是一个 GUI、可帮助管理复杂性。 但是、这使得很难在打算在多个平台上运行的项目之间比较 SysConfig。 我很感谢您可能不使用 SysConfig、但它似乎是向前发展的方向、因此很高兴能够为此找到解决方案。

在每个 CCS 工程目录中、IDE 配置、工程配置和动态生成的编译数据都混乱。 最好更好地组织这样的系统、这样才能很难看到应该是源代码存储库的一部分、什么是临时数据(例如、 在 cmake 样式的工程中、您通常会创建一个"编译"目录、该目录与源代码完全、很明显地是分开的)。

SimpleLink 平台非常有前景且灵活、所提供的示例非常有用且功能齐全、但我觉得我们更加重视帮助人们快速制作原型、而不是构建能够在整个软件生命周期内轻松维护的系统。

谢谢、