v5.1.1 需要推进的点

[mysterywolf]

• [x] 内核：整理kservice.c/.h
• [ ] 部分BSP的HAL库需要拆成软件包的方式，不能把HAL库嗷嗷往主仓提交，例如STM32的HAL库
  • https://github.com/RT-Thread/rt-thread/pull/8907
• [x] pin框架read返回值从rt_uint8_t 改为rt_ssize_t
• [ ] 使用os.join.path函数，而不是直接用/连接路径
• [ ] 整理BSP
  • [ ] MM32
  • [x] NXP
  • [x] Infineon
• [ ] CH32 上CI看护
• [x] HPM上CI看护
• [ ] 重构完善scons --dist打包命令

[BernardXiong]

发布env v2.0，启用python中的venv环境，并提供软件包下载功能。

[wirano]

不能再同意第二条了😂

[pineapple-man]

stm32中的HAL库真的太多了,感觉BSP就显的很乱

[chnykn]

第二条非常有必要

[meng-plus]

整个仓库都大的太恐怖了全是bsp占用

[charlown]

怎么拆分厂家的驱动库做成软件包的形式，有个范例就好了 ch32 ci看护是arm还是risc-v出了问题么？沁恒最近在risc-v方面大力发展, 他们arm的芯片很久没出新的

[mr-cn]

建议BSP把具体的board也拆分出去，主仓库保留对chip的支持就好了

[dujunqiu]

stm32用的HAL库，gd32用的标准库，能统一一下就好了

[meng-plus]

我最近在玩repo 我认为他是个很好的多仓库管理工具，是否考虑往这个方向发展下 即使同一个芯片的HAL库官方也在持续更新，拆包有助于精简仓库占用，独立更好的维护每个组件

https://git-repo.info/zh_cn/docs/multi-repos/overview/

[GPTKEY]

可以考虑：对于STM32 直接修改构建脚本， 去掉BSP中的HAL库，直接使用CubeMX生成的HAL库，这样兼容性更强

[dujunqiu]

我最近在玩repo 我认为他是个很好的多仓库管理工具，是否考虑往这个方向发展下 即使同一个芯片的HAL库官方也在持续更新，拆包有助于精简仓库占用，独立更好的维护每个组件

好主意，我看NXP的github库，已经拆分成多个子模块独立管理了

[wdfk-prog]

可以考虑：对于STM32 直接修改构建脚本， 去掉BSP中的HAL库，直接使用CubeMX生成的HAL库，这样兼容性更强

• 的确如此;甚至对于驱动中有关初始化配置的部分,都可以去除;保留一些常用配置修改既可;
• 不然对于每个系列都要兼容,不仅代码难看,而且维护起来也不容易,加个功能容易在其他没验证的系列出问题
• 但是如果是CubeMx生成的Hal库,就需要用户对驱动有意识,自行进行正确的配置