[features] 增加独立工程模式的功能 #250

BernardXiong · 2025-01-09T12:18:47Z

想法说明

目前RT-Thread的方式，在开发的时候会变成更多以BSP为主的方式，而对于工程业务逻辑，当不需要过多关注板卡情况时，并不是那么友好。而当所有构建脚本都使用scons脚本，Python脚本时，会太编程化（灵活度足够高，但不利于IDE、UI工具配置模式）

希望可以做到：

可以创建独立工程；
工程可以灵活选择RT-Thread版本（及路径）；
工程可以灵活切换芯片，驱动；
支持到附带的json配置文件模式，这样更利于集成到一些UI工具配置中；

挑战

目前在RT-Thread的一些BSP中，也引入了SDK_LIB，链接脚本，输出产物名称也都统一，这些都会在一定层面影响到统一化支持。

ThinkCodeStudio · 2025-02-07T03:36:23Z

想法说明

目前RT-Thread的方式，在开发的时候会变成更多以BSP为主的方式，而对于工程业务逻辑，当不需要过多关注板卡情况时，并不是那么友好。而当所有构建脚本都使用scons脚本，Python脚本时，会太编程化（灵活度足够高，但不利于IDE、UI工具配置模式）

希望可以做到：

可以创建独立工程；

工程可以灵活选择RT-Thread版本（及路径）；

工程可以灵活切换芯片，驱动；

支持到附带的json配置文件模式，这样更利于集成到一些UI工具配置中；

挑战

目前在RT-Thread的一些BSP中，也引入了SDK_LIB，链接脚本，输出产物名称也都统一，这些都会在一定层面影响到统一化支持。

我现在的工作流

我现在使用的是 env + clion 开发 5.1.0
我本人是从高级编程语言开发一直学到嵌入式的, 我的想法更偏向应用软件开发

我的想法

在实际开发流程中, 我需要先安装 env 工具, 再下载源码, 删除bsp其他的芯片和板卡工程, 保留用到的模板工程

我希望env工具能帮我下载源码, 并增量添加bsp工程, 再加上上面的功能

我认为RTThread Studio的问题

版本: 2.2.7
优点:

开箱即用, 界面化配置
缺点:
每次创建工程都有 RTT 源码, 导致不同工程有大量的重复代码
基于eclipse的工具开发体验很烂
代码高亮提示不好, 我在找那个变量使用时需要用"查找"
代码提示不好
拼写检查不好, 我拼错了没有提示
...

我认为env的问题

版本: 1.5.2
整体非常满意
只有一点不满意的是 env 工具不能配置进环境变量, 这导致了我在使用clion开发时还要打开env软件切换软件使用, 不能在clion内部的终端使用

我对开发工具的设想

以我现在使用的clion举例
首先是跨平台, 其次是可在系统终端使用, 然后具体的细节可参考 rust 的 cargo 工具
然后终端程序的好处是可以配合其他脚本语言去控制工程的配置编程和适配
整合功能, 我不需要去做复杂的环境配置, 我不需要为了开发不断的切换不同的工具
我希望这个工具整合了源码下载, 工程创建, 代码编译, 下载调试(最好支持远程调试, 无线调试)
由于嵌入式开发对板子强相关, 有时候程序是一套程序, 但是板子有多个型号, 在编译中最好可选择编译配置文件,

我希望搭配终端工具会有配套的vscode 和 clion 插件, 但插件功能不能太复杂, 点名批评其他厂商的插件, 比如esp等的插件, 在vsc里做的和独立软件一样, 为什么不从vscode里分离出去, 我的vsc不只做他家的活, 做出能识别工程, 编译, 下载调试就够了, 如果增强的化也加强对编码体验的优化.

我知道图形界面开发考虑到大部分人, 但是图形界面对我来说学习成本高, 而且不像终端工具那么的灵活

BernardXiong · 2025-02-07T11:07:57Z

我认为env的问题
版本: 1.5.2
整体非常满意
只有一点不满意的是 env 工具不能配置进环境变量, 这导致了我在使用clion开发时还要打开env软件切换软件使用, 不能在clion内部的终端使用

这点可以展开说说吗？目前的env是可以做到了工具链自动探测，或者用户自己配置亦可。然后可能的还包括RTT_ROOT？所以在最前面说的，希望有份配置的json文件，由这份配置文件来指定RTT_ROOT在哪里，进而还包括，如果BSP、驱动并不需要当前工程带，也可以有BSP_ROOT（也包括SDK_ROOT，如果有的话）指向到对应位置。然后这份json配置文件可以在vscode中打开，直接使用UI方式进行配置

BernardXiong · 2025-02-07T11:32:28Z

这个图更希望是类似这样的，env做为独立的命令行工具支撑基础设施。而 vscode扩展 ➕ env的方式，形成一个简单易用的工具。当然因为env的基座在这里，所以也可以和其他的IDE进行配合，包括在env命令的基础上加入其他的命令，来做构建也好，做创建工程也好等等的。

ThinkCodeStudio · 2025-02-08T06:18:12Z

我认为env的问题
版本: 1.5.2
整体非常满意
只有一点不满意的是 env 工具不能配置进环境变量, 这导致了我在使用clion开发时还要打开env软件切换软件使用, 不能在clion内部的终端使用

这点可以展开说说吗？目前的env是可以做到了工具链自动探测，或者用户自己配置亦可。然后可能的还包括RTT_ROOT？所以在最前面说的，希望有份配置的json文件，由这份配置文件来指定RTT_ROOT在哪里，进而还包括，如果BSP、驱动并不需要当前工程带，也可以有BSP_ROOT（也包括SDK_ROOT，如果有的话）指向到对应位置。然后这份json配置文件可以在vscode中打开，直接使用UI方式进行配置

我可以理解的就是有一个json格式的配置文件, 然后在VSCode中打开这个文件显示UI界面?(类似于jupyter插件) 如果不是, 而且在插件中设置带UI界面我是不推荐的, 类似于esp的工具

esp这种方式做成一个插件不如直接改vscode成一个专用IDE(类似于AMD Vitis 2024版), 毕竟vscode是一个通用编辑软件, 我并不希望在vscode中加入IDE, 因为这会影响我使用VSCode做其他事.
所以如果做VSCode插件的话, 功能一定要简单, 面向文件的; 如果想让VSCode管理工程集成开发, 那就基于VSCode改出一个新软件. (也可以考虑基于IntelliJ IDEA改, 就像 Android Studio)

然后我不满意的是env现在是一个独立的终端应用软件, 其使用的还是 scons, menuconfig这些命令行工具, 我想有一个命令行工具去整合这些工具, 包括了项目的创建, 配置, 编译和调试, 然后这个命令行工具还是安装即用的(和RTThread Studio功能差不多, 不过是 控制台应用程序), 就直接在系统终端应用里就可以使用(比如 powershell, Windows terminal), 还有VSCode软件内的终端.

这个图更希望是类似这样的，env做为独立的命令行工具支撑基础设施。而 vscode扩展 ➕ env的方式，形成一个简单易用的工具。当然因为env的基座在这里，所以也可以和其他的IDE进行配合，包括在env命令的基础上加入其他的命令，来做构建也好，做创建工程也好等等的。

还是打算把源码和SDK放在工程里吗? 我希望的是把我不关心的代码都不加入我的工程中, 因为我的代码也在做版本管理, 源码本不是我写的代码, 加入我的工程就会造成我的工程体积变大.
我也不希望把三方包放到的我的工程里, 因为有的时候我已经使用过一个软件包了, 那我再创建一个工程后可以继续使用这个软件, 不需要重新下载, 也不要进入我的版本管理.

还有如果我每次创建一个新的工程, 使用的都是同一版本的源码就会造成工程与工程之间有代码重复, 所以我的想法是在同一源码版本下管理不同的工程, 最好的情况是将我们应用项目和系统源码三方包完全隔开, 其实我的想法就是像linux一样应用开发和系统开发完全隔开.

然后我的工程中有一个配置文件, 里面描述了我使用的是哪个版本的系统, 哪个芯片, 哪个版本的HAL库和BSP, 最好在这些库的代码里都添加版本宏定义, 让我编写不同本版芯片的代码, 然后命令行工具会读取这个文件再整合编译成固件

BernardXiong · 2025-02-09T17:36:39Z

VSCode插件的话, 功能一定要简单

这个是希望追求的目标，不过一步步来吧，可能会显得麻烦，也有可能从简到繁再到简。

还是打算把源码和SDK放在工程里吗?

并不是，而是通过配置指向到对应的路径位置。

想法是在同一源码版本下管理不同的工程

如果是这样，则需要自行手动来构造整体目录结构了。这样的方式或许就有些类似于rt-thread本身的发布版本，这个时候或许可以是在配置上设置当前默认的工程是哪个，可以在根目录下build，或也可以生成workspace结构直接切换过仅显示对应的文件。

感觉到的一点是，这个过程是逐步的，可能从简到繁再到简，最终好用。需要一个过程

jswyll · 2025-02-22T03:30:40Z

我是vscode插件RT-Thread项目助手的作者，不过我之前主要都是用vscode的nano版，对env、scons和RT-Thread标准版还不太了解，仅供参考。

我的看法

关于上面讨论的问题：

clion开发怎么用它内置的终端来使用env的命令？

RT-Thread项目助手v0.2.0对接env的思路是这样的：

ConEmu看起来只是一个cmd终端，vscode本身是有终端的，官方文档说要在env中用code .才能在vscode中使用相关命令。我推测只是相关的环境变量的原因，于是我把网盘的各个env版本全部试用了一遍，用printenv命令对比直接用vscode打开项目的环境变量区别，综合env1.x和env2.x的结果是：

"ENV_DIR": "env安装路径",
"ENV_ROOT": "env安装路径",
"RTT_DIR": "rt-thread路径",
"RTT_ROOT": "rt-thread路径",
"BSP_DIR": "BSP路径",
"BSP_ROOT": "BSP路径",
"PATH": "env安装路径的各个工具路径",
"RTT_EXEC_PATH": "env安装路径/tools/gnu_gcc/arm_gcc/mingw/bin",
"PKGS_DIR": "env安装路径/packages",
"PKGS_ROOT": "env安装路径/packages",
"PYTHON": "env安装路径/.venv/Scripts/python.exe",
"PYTHONHOME": "env安装路径/tools/Python27",
"PYTHONPATH": "env安装路径/tools/Python27",
"SCONS": "env安装路径/tools/Python27/Scripts",
"VENV": "env安装路径/.venv",
"VIRTUAL_ENV": "env安装路径/.venv"

（其实还有一大堆ConEmu相关的环境变量，但既然在vscode中没有使用到就忽略了。）

所以理论上只要把这些环境变量设置好就可以不用通过code .启动，vscode本身有terminal.integrated.env.windows来设置终端的环境变量，可以手动在.vscode/settings.json中设置，例如env2.x可以设置为：

    // ...
    "terminal.integrated.env.windows": {
        "BSP_ROOT": ".",
        "ENV_ROOT": "c:/env-windows",
        "RTT_ROOT": "rt-thread",
        "PYTHON": "c:/env-windows/.venv/Scripts/python",
        "SCONS": "c:/env-windows/.venv/Scripts/Scripts",
        "RTT_EXEC_PATH": "c:/env-windows/tools/gnu_gcc/arm_gcc/mingw/bin",
        "PKGS_ROOT": "c:/env-windows/packages",
        "PATH": "c:/env-windows/tools/bin;c:/env-windows/.venv/Scripts;c:/env-windows/.venv/Scripts/Scripts;c:/env-windows/tools/gnu_gcc/arm_gcc/mingw/bin;c:/env-windows/tools/git-2.41.0-32-bit/cmd;${env:PATH}",
        "VENV": "c:/env-windows/.venv",
        "VIRTUAL_ENV": "c:/env-windows/.venv"
    },

具体实现方法：

vscode插件只需要写一个函数实现自动写入就行，例如updateTerminalIntegratedEnv函数https://github.com/jswyll/jswyll-vscode-rtthread/blob/release/src/main/project/generate.ts#L780。
插件需要为终端执行一个前置命令chcp 437，那样不管是powershell、cmd等都可以正常执行scons、pkgs命令了。

@ThinkCodeStudio 应该手动可以把相关的环境变量设置到clion里（我不知道有没有这个设置）。或者如果只使用一个版本的env的话，直接设置到系统中的环境变量去。

esp插件像把一个笨重的IDE塞进了vscode？

我不这么认为，我用了两三年这个插件，整体感觉是不错的。它提供了很多界面是为了不熟悉的人快速上手，它本身也支持全部操作都在终端用命令行操作。至于“笨重”，ESP32开发所需的工具太多，复杂了也不可避免。

它有许多值得参考的地方：

  - 新手只需要选择框架的版本，就会下载对应版本所需的所有工具、python虚拟环境，然后就可以开始开发；

  - 框架的版本不是存在项目文件夹内，而是下载到选择的地方，所以可以很方便的切换版本，也复用了同一框架版本及其工具；

  - 如果想要覆盖框架的某个组件代码，可以在项目内的components文件夹内新建同名文件夹；

  - 可以在项目中添加一个sdkconfig.defaults来设置具体项目的默认值；可以针对不同的硬件型号设置不同的默认配置；

  - 使用idf_component.yml进行组件管理，例如添加一个lvgl组件只需要添加一行`lvgl/lvgl: "8.3.10"`就可以把lvgl v8.3.10添加到项目中，对git管理来说只变化了一行代码。

当然，这个插件让vscode状态栏摆满了按钮，弹出一些窗口，这都可以选择不显示。而且只需要在用到esp的工作区才启用这个插件就好。

VSCode插件的话，功能一定要简单？

插件本身简单或复杂不重要，适合大部分用户使用才行。或许更佳的是，既能方便新手快速入门，也能进阶开发？

短期来看，既然env工具已经比较强大了，像jswyll.jswyll-vscode-rtthread插件那样对接一下env的命令，实现还是比较简单的。

长期来看，或许可以像esp插件那样快捷开始——帮助用户下载env工具，不用手动下载安装，降低新手学习RT-Thread的门槛？
要不要RT-Thread源码和SDK放在工程里？

我觉得是要支持放在工程里的。举一个场景，只会用Keil MDK的小白张三遇到了问题，经验丰富的李四提供了一个解决的demo，李四希望把整个demo打包压缩丢给张三、张三直接用MDK打开就能用，如果少了源码和BSP驱动就太为难张三了。

但目前把RT-Thread源码直接放在工程里我也不太喜欢，毕竟我有很多项目用的了同一个版本的RT-Thread源码。
主仓库下RT-Thread源码和BSP混在一起，笨重，而且BSP很可能和源码不兼容
我可能根本用不到iar的project.ewp，我希望生成哪个ide的项目就只包含该ide的文件；template.xxx、BSP的维护文档这些看起来是仅制作BSP时用的文件，项目用不到？

能不能让bsp配置文件描述不同ide的所需文件；如果bsp没有维护这个字段才把bsp全部拷贝到工程里。
配置文件用json还是yaml？

个人倾向于json。虽然yaml更好看，但我觉得类型不够清晰，例如key: 123、key: '123'``key: "123"看起来类型不够明确、唯一。

而且，在vscode中可以配置JSON Schema来校验、代码提示、字段说明。官方可以在指定方案后提供一个$schema的https链接，帮助BSP维护者规范配置：

我的想法

参考nodejs包管理package.json大胆想象一种方案：

RT-Thread主仓库只保留RT-Thread内核及其组件。

{
    "name": "RT-Thread",
    "description": "RT-Thread is an open source IoT Real-Time Operating System (RTOS).",
    "version": "3.1.5",
    "author": "RT-Thread Development Team <[email protected]>",
    "repository": "https://github.com/RT-Thread/rt-thread",
    "license": "Apache-2.0",
    "dependencies": {},
    ...
}

不同BSP的公共SDK以系列（例如STM32F4的HAL库）为单位，一种系列建一个仓库。

{
    "name": "STM32CubeF4",
    "description": "STM32Cube MCU Full Package for the STM32F4 series - (HAL + LL Drivers, CMSIS Core, CMSIS Device, MW libraries plus a set of Projects running on all boards provided by ST (Nucleo, Evaluation and Discovery Kits)).",
    "version": "1.26.0",
    "author": "STMicroelectronics",
    "repository": "https://github.com/STMicroelectronics/STM32CubeF4",
    "license": "BSD-3-Clause",
    "dependencies": {
      "CMSIS": "5.6.0"
    },
    ...
}

BSP对接RT-Thread版本和SDK版本。描述已支持的语义化版本范围，原则上使用精确版本或已发布过的版本。

{
  "name": "stm32f407-atk-explorer",
  "description": "适用于正点原子探索者开发板v2和V3的BSP支持包。",
  "version": "0.1.0",
  "author": "RT-Thread Development Team <[email protected]>",
  "repository": "https://github.com/RT-Thread/bsp/stm32f407-atk-explorer",
  "license": "Apache-2.0",
  "dependencies": {
    "sdk/STM32CubeF4": "1.26.0"
  },
  // 支持的RT-Thread版本
  "supported_rtthread_versions": [
    "3.1.5",
    "~4.1.0",
    ">=5.0.0 <=5.1.0"
  ],
  // 支持的芯片型号
  "supported_chips": [
    "STM32F407VET6",
    "STM32F407ZGT6"
  ],
  // 支持的IDE
  "supported_ides": {
    "RT-Thread Studio": {
      // 所需文件
      "includes": [
        "libraries/STM32F4xx_HAL/**",
        "board/linker_scripts/link.lds"
      ]
    },
    "vsocde": {
      "includes": [
        "libraries/STM32F4xx_HAL/**",
        "board/linker_scripts/link.lds",
        "README.md"
      ],
      // 具体IDE所需的额外依赖
      "dependencies": {
        "tools/arm-none-eabi-gcc": "10.3.1"
      }
    },
    "mdk5": {
      "includes": [
        "libraries/STM32F4xx_HAL/**",
        "board/linker_scripts/link.sct",
        // 具体型号所需的额外文件
        {
           "STM32F407ZGT6": "board/linker_scripts/linkscrpt-STM32F407ZG.sct",
        }
      ]
    },
    "mdk4": {
      "includes": [
        "libraries/STM32F4xx_HAL/**",
        "board/linker_scripts/link.sct"
      ]
    },
    "iar": {
      "includes": [
        "libraries/STM32F4xx_HAL/**",
        "board/linker_scripts/link.icf"
      ]
    }
  },
  ...
}

项目中，指定依赖的rt-thread、bsp和在线软件包的精确版本

{
    "name": "rtthread",
    "description": "正点原子探索者V3开发板的一个RT-Thread项目。",
    "dependencies": {
      "bsp/stm32f407-atk-explorer": "0.1.0",
      "packages/cJSON": "1.7.17"
    },
    "rtthread_version": "3.1.5",
    "chip": "STM32F407ZGT6",
    // 公共字段...
    "ide": {
        "vsocde": {
            // 可覆盖公共字段...
        }
    },
    ...
}

BSP对于不同RT-Thread版本的支持，通过git分支或宏定义来实现：

#if RT_THREAD_VERSION == RT_THREAD_VERSION_VAL(3,1,5)
    ...
#elif RT_THREAD_VERSION <= RT_THREAD_VERSION_VAL(5,1,0)
    ...
#else
    #error "Bsp is not support this RT-Thread version"
#endif

env抓取BSP列表、符合条件的版本列表供用户选择，生成具体IDE的项目，其中rt-thread、packages、bsp、sdk下载到env安装位置，复制所用版本到项目中并加入git忽略规则，允许添加额外参数表示不复制；安装依赖时，递归安装依赖的依赖；RT-Thread Studio可以调用内置env的命令来生成。

可能需要不断地调整方案，这可能需要为方案也安排版本号，env工具负责兼容与迁移。

emmm，这是一个浩瀚的工程。

我的期望

选定一个BSP，至少有一种IDE能够正常编译；如果能生成对应ide的项目就应该能用，否则不生成。

dongly · 2025-02-22T07:09:07Z

ConEmu看起来只是一个cmd终端，vscode本身是有终端的，官方文档说要在env中用code .才能在vscode中使用相关命令。我推测
只是相关的环境变量的原因，于是我把网盘的各个env版本全部试用了一遍，用printenv命令对比直接用vscode打开项目的环境变量> 区别，综合env1.x和env2.x的结果是：

在 env-windows 中, 只要运行 tools/bin/env-init.bat,就可以初始化env环境了,这与 ConEmu 无关,V1.5.x 与 V2.x.x 都有效.
这是我在 VSCode 中的配置:

"terminal.integrated.profiles.windows": {
             "RTT Env2": {
            "path": [
                "${env:windir}\\Sysnative\\cmd.exe",
                "${env:windir}\\System32\\cmd.exe"
            ],
            "args": [
                "/K",
                "D:\\DevTools\\env2\\tools\\bin\\env-init.bat"
            ],
        },
   ...
    },

BernardXiong · 2025-02-24T02:03:17Z

我不建议使用env-windows了，不过确实env-windows做到了大一统，解决了很多按照的问题。但携带的ConEmu， Ctrl+` 快捷键则和vscode的冲突了；在简单的vscode-rt-smart扩展那边，可以做到了很好的和env脚本结合在一起（目前看这份扩展在windows，linux下工作还可以）。
不建议使用studio的工程模式，因为studio本身的工程是由makefile方式构成；而rt-thread更多使用scons/SConscript方式来组织，两边是不同步的。所以建议是走纯粹的scons方式，也就是env的方式。

一些细节性的地方确实可以多学习到一些，

如果想要覆盖框架的某个组件代码，可以在项目内的components文件夹内新建同名文件夹；

可以在项目中添加一个sdkconfig.defaults来设置具体项目的默认值；可以针对不同的硬件型号设置不同的默认配置；

BernardXiong mentioned this issue Feb 6, 2025

[Feature] RTT BSP 瘦身计划 RT-Thread/rt-thread#9960

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[features] 增加独立工程模式的功能 #250

[features] 增加独立工程模式的功能 #250

BernardXiong commented Jan 9, 2025

ThinkCodeStudio commented Feb 7, 2025

想法说明

挑战

BernardXiong commented Feb 7, 2025

BernardXiong commented Feb 7, 2025

ThinkCodeStudio commented Feb 8, 2025

BernardXiong commented Feb 9, 2025 •

edited

Loading

jswyll commented Feb 22, 2025

dongly commented Feb 22, 2025

BernardXiong commented Feb 24, 2025

[features] 增加独立工程模式的功能 #250

[features] 增加独立工程模式的功能 #250

Comments

BernardXiong commented Jan 9, 2025

想法说明

挑战

ThinkCodeStudio commented Feb 7, 2025

想法说明

挑战

我现在的工作流

我的想法

我认为RTThread Studio的问题

我认为env的问题

我对开发工具的设想

BernardXiong commented Feb 7, 2025

BernardXiong commented Feb 7, 2025

ThinkCodeStudio commented Feb 8, 2025

BernardXiong commented Feb 9, 2025 • edited Loading

jswyll commented Feb 22, 2025

我的看法

我的想法

我的期望

dongly commented Feb 22, 2025

BernardXiong commented Feb 24, 2025

BernardXiong commented Feb 9, 2025 •

edited

Loading