RT-Thread
[Feature] RTT BSP 瘦身计划
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下面。
- [x] STM32F1
- [x] STM32F2
- [x] STM32F3
- [x] STM32F7
- [x] STM32H7
修复BSP之后请检查一下几个项目
- [ ] bsp执行
scons --dist看是否有error，参考stm32，修复，参考 #10130 - [ ] readme 中添加
pkgs --update明确说明，需要下载软件包
https://github.com/RT-Thread/rt-thread/pull/8907
https://github.com/RT-Thread/rt-thread/tree/master/bsp/nrf5x
厂商SDK挪走后README中的快速上手部分是否应该修改一下，毕竟不能“开箱即用”了，需要scons --menuconfig和pkgs --update。
https://github.com/RT-Thread/rt-thread/blob/2fdb9381bb93cc8e89887ef4b49104257cc991ff/bsp/stm32/stm32l431-BearPi/README.md?plain=1#L62-L74
厂商SDK挪走后README中的快速上手部分是否应该修改一下，毕竟不能“开箱即用”了，需要
scons --menuconfig和pkgs --update。https://github.com/RT-Thread/rt-thread/blob/2fdb9381bb93cc8e89887ef4b49104257cc991ff/bsp/stm32/stm32l431-BearPi/README.md?plain=1#L62-L74
可以，欢迎pr一下
另外测试了一下rt-thread studio似乎也没准备好，导入bsp直接报错了，看上去也没有先更新，直接dist了，而且python版本可能也会导致一些问题？
个人觉得，如果rt-thread studio能导入bsp自动拉sdk，可能快速上手用studio更为合适？方便那些不想/不会装环境的人。
另外测试了一下rt-thread studio似乎也没准备好，导入bsp直接报错了，看上去也没有先更新，直接dist了，而且python版本可能也会导致一些问题？
个人觉得，如果rt-thread studio能导入bsp自动拉sdk，可能快速上手用studio更为合适？方便那些不想/不会装环境的人。
确实这块需要说明一下，studio这块先update再导入即可，
增强env工具的功能吧, 改成下载源码后使用env创建对应芯片的模板工程, 然后其他开发板的bsp改成demo软件包
https://club.rt-thread.org/ask/article/d273bbcd1f8779bc.html 已经有了，欢迎试试。
增强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创建对应芯片的模板工程, 然后其他开发板的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讨论看看
增强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那边也列了一个议题 https://github.com/RT-Thread/env/issues/250
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库，避免冗余代码的下载。
关于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团队的工作负担，同时提升用户的信任度和体验。
• 质量参差不齐：贡献者的水平和经验不同，可能导致软件包的质量和规范性存在差异。
• 维护问题：如果贡献者失去兴趣或无法继续维护，可能导致某些软件包无人更新，影响用户体验。
• 信任问题：用户可能对非官方创建的软件包存在信任问题，担心其安全性和兼容性。
现在很多厂商也在GitHub之类的地方放库了，工具能否实现拉取厂商包+维护者patch，然后自动合并patch生成sdk。这样用户也方便知道改了什么，维护也方便点。
• 质量参差不齐：贡献者的水平和经验不同，可能导致软件包的质量和规范性存在差异。 • 维护问题：如果贡献者失去兴趣或无法继续维护，可能导致某些软件包无人更新，影响用户体验。 • 信任问题：用户可能对非官方创建的软件包存在信任问题，担心其安全性和兼容性。
现在很多厂商也在GitHub之类的地方放库了，工具能否实现拉取厂商包+维护者patch，然后自动合并patch生成sdk。这样用户也方便知道改了什么，维护也方便点。
可以呀，欢迎把某个bsp改成你说的这种软件包PR上来看看效果。
对于BSP瘦身计划，我个人总结主要有这么几种类型的BSP以及相关建议：
1.类似nxp，本身的SDK机制比较复杂，不好fork上游独立仓库，建议可以以静态软件包的形式维护，将主仓内有关原厂文件（原厂驱动、链接脚本、CMSIS...）单独抽离为软件包的形式（不以fork上游仓库形式）； 2.类似renesas，依赖代码生成器的配置生成驱动文件，建议这种我们只需要保留一个最小体量工程即可，同时保留生成器配置文件，这样代码量也不会很大； 3.类似STM32，HAL库完全独立出来并且驱动文件默认全部生成，建议fork并跟进上游仓库更新。 ...
可能每家厂商都有一些自己的维护习惯，需要根据不同厂家的实际BSP情况看看怎么处理好
HAL-SDK软件包的权限是不是会比较麻烦？大家有什么建议吗？ 比如如果社区其他github维护的话，如果该仓库主转行或者长期不维护，导致SDK软件包长期没有合并PR。或者删库之类的 如果RTT维护的话，RTT 维护的成本也比较多.
HAL-SDK软件包的权限是不是会比较麻烦？大家有什么建议吗？ 比如如果社区其他github维护的话，如果该仓库主转行或者长期不维护，导致SDK软件包长期没有合并PR。或者删库之类的 如果RTT维护的话，RTT 维护的成本也比较多.
更建议用官方账号弄个BSP组织，然后创建SDK仓库，后续抽离出来的SDK往这里面提，否则情况就会像软件包仓库一样新增PR无法及时合并（当然软件包仓库毕竟归属作者本身，可以让后续软件包作者新增软件包加入RTT官方账号作为管理者，以便PR合并）
大佬们，你们好。 对瘦身计划和执行方式也初步的学习了一下。 目前梳理下来确实还是存在一个仓库归放的问题，放于维护者个人账号下可能存在长期不更新或者删库的情况，RTT账号下建仓库进行维护最可靠，但也带来维护成本。 即使厂商官方账号可以将cmsis/hal-driver抽取出来独立建库，但适合于rt-thread的文件还需要额外进行处理。以stm32f4为参考 https://github.com/RT-Thread-packages/stm32f4_cmsis_driver和https://github.com/RT-Thread-packages/stm32f4_hal_driver。 这两个中间处理仓库放厂商官方账号内不合适（因为已有一份极为相似的库，且有的维护者不一定是厂商人员），放维护者个人账号内也不太合适，如果个人维护者删库和不更新就直接影响了使用（因为RTT是提取的这份中间处理库来使用）
大佬们，你们好。 对瘦身计划和执行方式也初步的学习了一下。 目前梳理下来确实还是存在一个仓库归放的问题，放于维护者个人账号下可能存在长期不更新或者删库的情况，RTT账号下建仓库进行维护最可靠，但也带来维护成本。 即使厂商官方账号可以将cmsis/hal-driver抽取出来独立建库，但适合于rt-thread的文件还需要额外进行处理。以stm32f4为参考 https://github.com/RT-Thread-packages/stm32f4_cmsis_driver和https://github.com/RT-Thread-packages/stm32f4_hal_driver。 这两个中间处理仓库放厂商官方账号内不合适（因为已有一份极为相似的库，且有的维护者不一定是厂商人员），放维护者个人账号内也不太合适，如果个人维护者删库和不更新就直接影响了使用（因为RTT是提取的这份中间处理库来使用）
应对这种情况，在私人仓库中，添加supperthomas 或者mysterywolf 或者熊大，为仓库共同维护人员如何？可以帮忙合并PR 删库没关系，删库的gitee有备份，删库我们会把仓库转到官方仓库中，默认维护人员自愿放弃维护。总之瘦身大方向不会变，或者有什么其他建议好办法也可以提
大佬们，你们好。 对瘦身计划和执行方式也初步的学习了一下。 目前梳理下来确实还是存在一个仓库归放的问题，放于维护者个人账号下可能存在长期不更新或者删库的情况，RTT账号下建仓库进行维护最可靠，但也带来维护成本。 即使厂商官方账号可以将cmsis/hal-driver抽取出来独立建库，但适合于rt-thread的文件还需要额外进行处理。以stm32f4为参考 https://github.com/RT-Thread-packages/stm32f4_cmsis_driver和https://github.com/RT-Thread-packages/stm32f4_hal_driver。 这两个中间处理仓库放厂商官方账号内不合适（因为已有一份极为相似的库，且有的维护者不一定是厂商人员），放维护者个人账号内也不太合适，如果个人维护者删库和不更新就直接影响了使用（因为RTT是提取的这份中间处理库来使用）
应对这种情况，在私人仓库中，添加supperthomas 或者mysterywolf 或者熊大，为仓库共同维护人员如何？可以帮忙合并PR 删库没关系，删库的gitee有备份，删库我们会把仓库转到官方仓库中，默认维护人员自愿放弃维护。总之瘦身大方向不会变，或者有什么其他建议好办法也可以提
可以把rtt的账号到仓库成员：https://github.com/rtthread-bot
对于有官方hal仓库的bsp比如stm32可以直接引用官方连接，rtt需要的脚本可以放bsp中，这样就不用再建个仓了
+1，不过直接执行脚本不太合适。
个人觉得方案为官方包+patch比较合适，然后可以对历史版本做对应的patch，来避免厂商对主分支的修改。如果厂商没有在GitHub release放历史版本，维护者可以建个仓拉厂商库放release里再加到package.json。
fork的话，个人用下来有一点比较蛋疼，默认不开issue，很多人也不开，别人催更都要找其他联系方式催。（而且搞得厂商sdk要我维护一样，毕竟在我的仓库里，感觉上就有点工作压力，给别人的信任感也不如厂商，不仔细看也不知道作者魔改了点啥。）
例子： https://github.com/RT-Thread/rt-thread/pull/9983 https://github.com/RT-Thread/packages/pull/1858 https://github.com/kaidegit/ch32v307-sdk-rtt-patch
25/2/16社区例会针对此issues讨论结果： 1、厂商有官方仓库的，尽量rtt或者作者fork官方仓库进行commit，建议作者和rtt都加合并权限； 2、厂商没有官方仓库的，可以委托rtt建软件包仓库或者自己创建直接拷贝sdk，建议作者和rtt都加合并权限。后续作者放弃，rtt可以fork进行后续维护； 3、现有的慢慢基于上述规则挪到软件包； 4、新进BSP需要遵守述两个规则，才可以合并到RTT主线仓库
BSP拆分势在必行，有人塞100MB的系统镜像，没有压缩，内容基本是空的
bsp\nxp\imx\imx6ull-smart\emmc\boot.fat
bsp\nxp\imx\imx6ull-smart\emmc\image\input\boot.fat
这两个文件完全一致，100MB*2，太离谱了
BSP拆分势在必行，有人塞100MB的系统镜像，没有压缩，内容基本是空的 bsp\nxp\imx\imx6ull-smart\emmc\boot.fat bsp\nxp\imx\imx6ull-smart\emmc\image\input\boot.fat 这两个文件完全一致，100MB*2，太离谱了
可以pr一下