Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

[Feature] RTT BSP 瘦身计划 #9960

Open
supperthomas opened this issue Jan 31, 2025 · 26 comments
Open

[Feature] RTT BSP 瘦身计划 #9960

supperthomas opened this issue Jan 31, 2025 · 26 comments
Assignees
@mysterywolf

Comments

@supperthomas
Copy link
Member

Describe problem solved by the proposed feature

由于bsp目前过于大，现在大家下载整个rtthread也过于庞大，
但是下下来之后，大部分是bsp的内容，bsp和.git的内容占到大小的90%
Image
可以看到bsp占了2.2G，外加904M的.git
实际上RTTHREAD内部代码占到100M左右，包括文档。差不多3%左右。
目前BSP大头也是芯片比较多的厂商

Image

之前为了方便大家能够实现开箱即用的快速开发形式，将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下面。
@supperthomas
Copy link
Member Author

supperthomas commented Jan 31, 2025 •
edited
Loading

#8907

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

@kaidegit
Copy link
Contributor

kaidegit commented Feb 3, 2025

厂商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
Copy link
Member Author

厂商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
Copy link
Contributor

kaidegit commented Feb 3, 2025

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

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

.log

@supperthomas
Copy link
Member Author

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

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

.log

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

@supperthomas
Copy link
Member Author

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

@ThinkCodeStudio
Copy link

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

@supperthomas
Copy link
Member Author

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

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

@ThinkCodeStudio
Copy link

增强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
Copy link
Member Author

supperthomas commented Feb 6, 2025 •
edited
Loading

增强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
Copy link
Member

增强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 supperthomas mentioned this issue Feb 6, 2025
Merged
10 tasks
@supperthomas
Copy link
Member Author

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
Copy link
Member Author

关于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
Copy link
Contributor

kaidegit commented Feb 8, 2025

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

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

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

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

@supperthomas supperthomas mentioned this issue Feb 10, 2025
Open
10 tasks
@supperthomas
Copy link
Member Author

• 质量参差不齐：贡献者的水平和经验不同，可能导致软件包的质量和规范性存在差异。
• 维护问题：如果贡献者失去兴趣或无法继续维护，可能导致某些软件包无人更新，影响用户体验。
• 信任问题：用户可能对非官方创建的软件包存在信任问题，担心其安全性和兼容性。

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

可以呀，欢迎把某个bsp改成你说的这种软件包PR上来看看效果。

@kurisaW
Copy link
Contributor

kurisaW commented Feb 10, 2025

对于BSP瘦身计划，我个人总结主要有这么几种类型的BSP以及相关建议：

1.类似nxp，本身的SDK机制比较复杂，不好fork上游独立仓库，建议可以以静态软件包的形式维护，将主仓内有关原厂文件（原厂驱动、链接脚本、CMSIS...）单独抽离为软件包的形式（不以fork上游仓库形式）；
2.类似renesas，依赖代码生成器的配置生成驱动文件，建议这种我们只需要保留一个最小体量工程即可，同时保留生成器配置文件，这样代码量也不会很大；
3.类似STM32，HAL库完全独立出来并且驱动文件默认全部生成，建议fork并跟进上游仓库更新。
...

可能每家厂商都有一些自己的维护习惯，需要根据不同厂家的实际BSP情况看看怎么处理好

@kaidegit kaidegit mentioned this issue Feb 10, 2025
Open
10 tasks
@supperthomas
Copy link
Member Author

supperthomas commented Feb 11, 2025 •
edited
Loading

HAL-SDK软件包的权限是不是会比较麻烦？大家有什么建议吗？
比如如果社区其他github维护的话，如果该仓库主转行或者长期不维护，导致SDK软件包长期没有合并PR。或者删库之类的
如果RTT维护的话，RTT 维护的成本也比较多.

@kurisaW
Copy link
Contributor

kurisaW commented Feb 11, 2025 •
edited
Loading

HAL-SDK软件包的权限是不是会比较麻烦？大家有什么建议吗？ 比如如果社区其他github维护的话，如果该仓库主转行或者长期不维护，导致SDK软件包长期没有合并PR。或者删库之类的 如果RTT维护的话，RTT 维护的成本也比较多.

更建议用官方账号弄个BSP组织，然后创建SDK仓库，后续抽离出来的SDK往这里面提，否则情况就会像软件包仓库一样新增PR无法及时合并（当然软件包仓库毕竟归属作者本身，可以让后续软件包作者新增软件包加入RTT官方账号作为管理者，以便PR合并）

@supperthomas
Copy link
Member Author

https://github.com/RT-Thread-packages/stm32l4_cmsis_driver

@sheltonyu
Copy link
Contributor

sheltonyu commented Feb 11, 2025 •
edited
Loading

大佬们，你们好。
对瘦身计划和执行方式也初步的学习了一下。
目前梳理下来确实还是存在一个仓库归放的问题，放于维护者个人账号下可能存在长期不更新或者删库的情况，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
Copy link
Member Author

supperthomas commented Feb 11, 2025 •
edited
Loading

大佬们，你们好。 对瘦身计划和执行方式也初步的学习了一下。 目前梳理下来确实还是存在一个仓库归放的问题，放于维护者个人账号下可能存在长期不更新或者删库的情况，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有备份，删库我们会把仓库转到官方仓库中，默认维护人员自愿放弃维护。总之瘦身大方向不会变，或者有什么其他建议好办法也可以提

@supperthomas
Copy link
Member Author

添加共同维护人的方法
Image

@heyuanjie87
Copy link
Contributor

对于有官方hal仓库的bsp比如stm32可以直接引用官方连接，rtt需要的脚本可以放bsp中，这样就不用再建个仓了

@Rbb666
Copy link
Member

Rbb666 commented Feb 11, 2025

大佬们，你们好。 对瘦身计划和执行方式也初步的学习了一下。 目前梳理下来确实还是存在一个仓库归放的问题，放于维护者个人账号下可能存在长期不更新或者删库的情况，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

@kaidegit
Copy link
Contributor

kaidegit commented Feb 11, 2025 •
edited
Loading

对于有官方hal仓库的bsp比如stm32可以直接引用官方连接，rtt需要的脚本可以放bsp中，这样就不用再建个仓了

+1，不过直接执行脚本不太合适。

个人觉得方案为官方包+patch比较合适，然后可以对历史版本做对应的patch，来避免厂商对主分支的修改。如果厂商没有在GitHub release放历史版本，维护者可以建个仓拉厂商库放release里再加到package.json。

fork的话，个人用下来有一点比较蛋疼，默认不开issue，很多人也不开，别人催更都要找其他联系方式催。（而且搞得厂商sdk要我维护一样，毕竟在我的仓库里，感觉上就有点工作压力，给别人的信任感也不如厂商，不仔细看也不知道作者魔改了点啥。）

例子：
#9983
RT-Thread/packages#1858
https://github.com/kaidegit/ch32v307-sdk-rtt-patch

@supperthomas
Copy link
Member Author

或者这样，有github官方仓库的可以放在这个issue下面，rtthread负责fork一下，开发者可以提pr到这个仓库。

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@mysterywolf mysterywolf

Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
9 participants
@BernardXiong @heyuanjie87 @mysterywolf @ThinkCodeStudio @sheltonyu @kaidegit @supperthomas @Rbb666 @kurisaW