[Feature] RTT BSP 瘦身计划

[supperthomas]

Describe problem solved by the proposed feature

由于bsp目前过于大，现在大家下载整个rtthread也过于庞大，
但是下下来之后，大部分是bsp的内容，bsp和.git的内容占到大小的90%

可以看到bsp占了2.2G，外加904M的.git
实际上RTTHREAD内部代码占到100M左右，包括文档。差不多3%左右。
目前BSP大头也是芯片比较多的厂商

之前为了方便大家能够实现开箱即用的快速开发形式，将HAL库放到BSP中，但是随着bsp越来越多，HAL也越来越庞大，而且大部分是用不到的芯片。所以为了能够方便各个芯片用户的快速使用，将厂商SDK以软件包的形式上传，保留RTTHREAD的适配，可以放到BSP中。
其他形式由于网络等因素，综合考虑目前软件包的形式优点比较明显。

Describe your preferred solution

目前希望STM32能够持续的将HAL库都剥离出来，避免其他非STM32的用户下载冗余代码。
目前比较统一建议是：
参考bsp/nrf5x和STM32/L4系列，将厂商的HAL库形成一个软件包的形式供需要的用户单独执行pkgs --update 下载
这一块后续新增bsp会强制要求将SDK整合成软件包的形式，精简bsp，没有特殊情况，不再接收厂商单独的SDK放到bsp中。
STM32系列可以参考L4系列将HAL库整合成软件包的形式。
软件包目前统一放到下面的目录中，bsp中默认选中即可。
https://github.com/RT-Thread/packages/tree/master/peripherals/hal-sdk

Describe possible alternatives

大家有好的建议也可以放到这个comment下面。

• STM32F1
• STM32F2
• STM32F3
• STM32F7
• STM32H7

修复BSP之后请检查一下几个项目

• bsp执行scons --dist 看是否有error，参考stm32，修复，参考 [bsp][at32]Update AT32 sdk_dist.py #10130
• readme 中添加pkgs --update 明确说明，需要下载软件包

[supperthomas]

#8907

https://github.com/RT-Thread/rt-thread/tree/master/bsp/nrf5x

[kaidegit]

厂商SDK挪走后README中的快速上手部分是否应该修改一下，毕竟不能“开箱即用”了，需要scons --menuconfig和pkgs --update。

rt-thread/bsp/stm32/stm32l431-BearPi/README.md

Lines 62 to 74 in 2fdb938

	### 快速上手
	本 BSP 为开发者提供 MDK5 和 IAR 工程，并且支持 GCC 开发环境。下面以 MDK5 开发环境为例，介绍如何将系统运行起来。
	#### 硬件连接
	使用数据线连接开发板到 PC，打开电源开关。
	#### 编译下载
	双击 project.uvprojx 文件，打开 MDK5 工程，编译并下载程序到开发板。
	> 工程默认配置使用 ST-LINK 仿真器下载程序，在通过 microUSB 连接开发板的基础上，点击下载按钮即可下载程序到开发板

[supperthomas]

厂商SDK挪走后README中的快速上手部分是否应该修改一下，毕竟不能“开箱即用”了，需要scons --menuconfig和pkgs --update。

rt-thread/bsp/stm32/stm32l431-BearPi/README.md

Lines 62 to 74 in 2fdb938

	### 快速上手
	本 BSP 为开发者提供 MDK5 和 IAR 工程，并且支持 GCC 开发环境。下面以 MDK5 开发环境为例，介绍如何将系统运行起来。
	#### 硬件连接
	使用数据线连接开发板到 PC，打开电源开关。
	#### 编译下载
	双击 project.uvprojx 文件，打开 MDK5 工程，编译并下载程序到开发板。
	> 工程默认配置使用 ST-LINK 仿真器下载程序，在通过 microUSB 连接开发板的基础上，点击下载按钮即可下载程序到开发板

可以，欢迎pr一下

[kaidegit]

另外测试了一下rt-thread studio似乎也没准备好，导入bsp直接报错了，看上去也没有先更新，直接dist了，而且python版本可能也会导致一些问题？

个人觉得，如果rt-thread studio能导入bsp自动拉sdk，可能快速上手用studio更为合适？方便那些不想/不会装环境的人。

.log

[supperthomas]

另外测试了一下rt-thread studio似乎也没准备好，导入bsp直接报错了，看上去也没有先更新，直接dist了，而且python版本可能也会导致一些问题？

个人觉得，如果rt-thread studio能导入bsp自动拉sdk，可能快速上手用studio更为合适？方便那些不想/不会装环境的人。

.log

确实这块需要说明一下，studio这块先update再导入即可，

[supperthomas]

https://club.rt-thread.org/ask/question/00bb8810ee1e627e.html

[ThinkCodeStudio]

增强env工具的功能吧, 改成下载源码后使用env创建对应芯片的模板工程, 然后其他开发板的bsp改成demo软件包

[supperthomas]

增强env工具的功能吧, 改成下载源码后使用env创建对应芯片的模板工程, 然后其他开发板的bsp改成demo软件包

https://club.rt-thread.org/ask/article/d273bbcd1f8779bc.html
已经有了，欢迎试试。

[ThinkCodeStudio]

增强env工具的功能吧, 改成下载源码后使用env创建对应芯片的模板工程, 然后其他开发板的bsp改成demo软件包

https://club.rt-thread.org/ask/article/d273bbcd1f8779bc.html 已经有了，欢迎试试。

不是我描述的功能, 我的想法是源码里bsp文件是空的, 这样先清空bsp文件夹减少源码的大小, 然后再在源码的根目录使用env的一个命令去创建一个基础的bsp模板工程, 就是Hello World的程度, 再在这个基础上开发.
至于bsp中的厂商开发板工程就直接移到软件包里, 我用rtt开发时都是用的我们自己画的板子, 所以其他厂商的工程也是没用的
这种工程创建方式像一些编程语言的终端工具, 你们也可以做一个, 我假如你们做了一个叫 "rtt" 的工具, 然后我再终端输入:

rtt init  # 把RT Thread最新稳定版源码下载到当前目录
rtt new stm32_hello -c stm32f407ze -t cmake # 下载对应的工程模板并配置bsp环境
cd bsp/stm32/stm32_hello # 跳转到bsp目录下
rtt config # 配置bsp 相当于 menuconfig
rtt update # 更新软件包
rtt build # 编译

rtt list # 查看支持的bsp 模板工程列表 

[supperthomas]

增强env工具的功能吧, 改成下载源码后使用env创建对应芯片的模板工程, 然后其他开发板的bsp改成demo软件包

https://club.rt-thread.org/ask/article/d273bbcd1f8779bc.html 已经有了，欢迎试试。

不是我描述的功能, 我的想法是源码里bsp文件是空的, 这样先清空bsp文件夹减少源码的大小, 然后再在源码的根目录使用env的一个命令去创建一个基础的bsp模板工程, 就是Hello World的程度, 再在这个基础上开发.
至于bsp中的厂商开发板工程就直接移到软件包里, 我用rtt开发时都是用的我们自己画的板子, 所以其他厂商的工程也是没用的
这种工程创建方式像一些编程语言的终端工具, 你们也可以做一个, 我假如你们做了一个叫 "rtt" 的工具, 然后我再终端输入:

rtt init  # 把RT Thread最新稳定版源码下载到当前目录
rtt new stm32_hello -c stm32f407ze -t cmake # 下载对应的工程模板并配置bsp环境
cd bsp/stm32/stm32_hello # 跳转到bsp目录下
rtt config # 配置bsp 相当于 menuconfig
rtt update # 更新软件包
rtt build # 编译

rtt list # 查看支持的bsp 模板工程列表 

这个rtstudio上已经实现，可以多试试rtstudio。不过你的想法挺好的，或许你可以提个pr或者issue讨论看看

[BernardXiong]

增强env工具的功能吧, 改成下载源码后使用env创建对应芯片的模板工程, 然后其他开发板的bsp改成demo软件包

https://club.rt-thread.org/ask/article/d273bbcd1f8779bc.html 已经有了，欢迎试试。

不是我描述的功能, 我的想法是源码里bsp文件是空的, 这样先清空bsp文件夹减少源码的大小, 然后再在源码的根目录使用env的一个命令去创建一个基础的bsp模板工程, 就是Hello World的程度, 再在这个基础上开发. 至于bsp中的厂商开发板工程就直接移到软件包里, 我用rtt开发时都是用的我们自己画的板子, 所以其他厂商的工程也是没用的 这种工程创建方式像一些编程语言的终端工具, 你们也可以做一个, 我假如你们做了一个叫 "rtt" 的工具, 然后我再终端输入:

rtt init # 把RT Thread最新稳定版源码下载到当前目录
rtt new stm32_hello -c stm32f407ze -t cmake # 下载对应的工程模板并配置bsp环境
cd bsp/stm32/stm32_hello # 跳转到bsp目录下
rtt config # 配置bsp 相当于 menuconfig
rtt update # 更新软件包
rtt build # 编译

rtt list # 查看支持的bsp 模板工程列表

欢迎基于env来进行增强，包括创建独立的工程，在env那边也列了一个议题 RT-Thread/env#250

[supperthomas]

RT-Thread BSP瘦身计划规则

1.目标

• 减少冗余：精简BSP中的HAL库和其他不必要的文件，避免用户下载大量用不到的代码。

• 优化结构：将厂商SDK以软件包的形式整合，便于用户按需下载。

• 提升用户体验：简化用户获取RT-Thread的流程，减少初始下载体积。

2.BSP精简规则

2.1 HAL库处理

• 剥离HAL库：对于STM32等芯片，不再将HAL库直接集成在BSP中。HAL库应以软件包的形式提供。

• 软件包管理：将HAL库及其他厂商SDK整合为软件包，存放在统一的目录中，例如`

• 默认选中：在BSP中默认选中相关软件包，用户可通过pkgs --update命令单独下载所需的HAL库。

2.2 新增BSP要求

• 强制软件包形式：新增BSP时，必须将厂商SDK整合成软件包形式，不再接收单独的SDK文件放入BSP中。

• 精简BSP内容：BSP中仅保留与RT-Thread适配的必要代码，避免包含不必要的文件和库。

2.3 现有BSP优化

• 逐步迁移：对于现有的BSP，逐步将其HAL库迁移到软件包形式。优先处理占用空间较大的BSP。

• 参考案例：以bsp/nrf5x和STM32/L4系列为参考，将HAL库整合成软件包的形式。

2.4 文档与说明

• 更新文档：在RT-Thread的官方文档中，详细说明BSP瘦身计划的目标、规则以及如何使用软件包下载HAL库。

• 用户指南：为用户提供清晰的指南，说明如何通过pkgs --update命令下载所需的HAL库。

3.用户反馈与改进

• 收集反馈：在GitHub Issue中收集用户对BSP瘦身计划的反馈和建议。

• 持续优化：根据用户反馈，持续优化BSP结构和软件包管理机制。

4.监督与执行

• 代码审查：在代码提交和合并过程中，严格审查新增BSP是否符合精简规则。

• 定期检查：定期检查现有BSP，确保其符合精简要求。

---

规则示例

新增BSP提交要求

• 文件结构：

• bsp/芯片型号/：仅包含RT-Thread适配代码。

• packages/peripherals/hal-sdk/芯片型号/：存放HAL库软件包。

• 提交说明：

• 提交时需附带说明文档，说明如何通过pkgs --update下载HAL库。

• 提交的BSP必须通过代码审查，确保符合精简规则。

现有BSP优化流程

• 迁移步骤：

• 将现有BSP中的HAL库迁移到packages/peripherals/hal-sdk/。

• 更新BSP代码，确保其依赖的HAL库可通过软件包管理工具下载。

• 提交优化后的BSP，并附带迁移说明。

---

总结
通过以上规则，RT-Thread项目可以有效减少BSP的体积，优化代码结构，提升用户体验。同时，通过软件包管理机制，用户可以根据实际需求下载所需的HAL库，避免冗余代码的下载。

[supperthomas]

关于HAL库软件包的创建主体（RT-Thread团队还是贡献者），需要综合考虑项目的维护成本、社区参与度、质量控制以及用户体验等多个因素。以下是两种选择的优缺点分析，以及我的建议：

1.由RT-Thread团队创建

优点

• 质量保证：RT-Thread团队对项目的整体架构和技术细节有更深入的了解，能够确保软件包的质量和兼容性。

• 统一规范：团队可以制定统一的软件包规范和格式，确保所有HAL库软件包的一致性，便于用户使用和维护。

• 长期维护：团队可以对软件包进行持续更新和维护，确保其与RT-Thread的最新版本兼容。

• 用户体验：由官方团队创建的软件包更容易获得用户的信任，减少用户对软件包可靠性的疑虑。

缺点

• 工作量大：创建和维护大量的HAL库软件包会增加RT-Thread团队的工作负担，可能导致资源分配紧张。

• 响应速度慢：团队可能无法及时响应所有厂商SDK的更新和用户需求，导致软件包的更新速度较慢。

2.由贡献者创建

优点

• 社区参与度高：鼓励社区成员参与，可以提高社区的活跃度和参与感，增强项目的开源文化。

• 快速响应：贡献者可以更快速地响应特定厂商SDK的更新和用户需求，及时发布新的软件包。

• 减轻团队负担：减少RT-Thread团队的工作量，使其能够专注于核心功能的开发和维护。

缺点

• 质量参差不齐：贡献者的水平和经验不同，可能导致软件包的质量和规范性存在差异。

• 维护问题：如果贡献者失去兴趣或无法继续维护，可能导致某些软件包无人更新，影响用户体验。

• 信任问题：用户可能对非官方创建的软件包存在信任问题，担心其安全性和兼容性。

我的建议
结合RT-Thread项目的实际情况和社区的运作模式，建议采用“官方主导，社区协作”的方式：

1.官方团队主导核心架构和规范

• 制定规范：RT-Thread团队制定统一的软件包规范和格式，明确软件包的结构、命名规则、依赖关系等。

• 提供模板：提供标准的软件包模板和创建指南，帮助贡献者快速上手。

• 审核机制：建立严格的审核机制，确保所有提交的软件包符合规范，质量可靠。

2.鼓励社区贡献者参与

• 激励机制：通过社区积分、荣誉徽章等方式激励贡献者参与软件包的创建和维护。

• 协作平台：提供专门的协作平台或工具，方便贡献者提交和维护软件包。

• 技术支持：RT-Thread团队提供技术支持，帮助解决贡献者在创建和维护软件包过程中遇到的问题。

3.官方团队负责关键HAL库和长期维护

• 关键HAL库：对于一些使用广泛的芯片（如STM32系列），由RT-Thread团队负责创建和维护其HAL库软件包，确保质量和兼容性。

• 长期维护：对于社区贡献的软件包，RT-Thread团队定期进行检查和维护，确保其与RT-Thread的最新版本兼容。

总结
通过“官方主导，社区协作”的方式，既可以保证软件包的质量和规范性，又能充分发挥社区的力量，减轻RT-Thread团队的工作负担，同时提升用户的信任度和体验。

[kaidegit]

• 质量参差不齐：贡献者的水平和经验不同，可能导致软件包的质量和规范性存在差异。

• 维护问题：如果贡献者失去兴趣或无法继续维护，可能导致某些软件包无人更新，影响用户体验。

• 信任问题：用户可能对非官方创建的软件包存在信任问题，担心其安全性和兼容性。

现在很多厂商也在GitHub之类的地方放库了，工具能否实现拉取厂商包+维护者patch，然后自动合并patch生成sdk。这样用户也方便知道改了什么，维护也方便点。