Embedded operating system development environment architecture design method based on VSCode

Abstract

The invention relates to a VSCode-based embedded operating system development environment architecture design method, which comprises the following steps that an embedded operating system development environment adopts an open architecture design and supports the realization of system integration with various embedded operating systems and construction through a configuration file, and the dependent resources in the development process comprise a target resource library and a host resource library; the function module and the development sequence are code editing-gt; system configuration-gt; performing cross compiling-gt; carrying out mirror image loading-gt; and remote debugging. The problem of how to realize tool chain automatic configuration, construction process intelligent generation and debugging interface unified adaptation of a cross-platform embedded development environment through a standardized architecture design is solved. The cross-platform tool chain automatic configuration efficiency is remarkably improved, the development environment configuration complexity is greatly reduced, the multi-architecture debugging compatibility and flexibility are enhanced, and the development efficiency and collaborative experience are optimized.

Description

Technical Field

[0001] This invention relates to the field of embedded system development tools, and more specifically to a cross-platform embedded operating system development environment architecture design method based on Visual Studio Code (VSCode). Background Technology

[0002] 1. PlatformIO Plugin Solution The core mechanism of this solution is to install the PlatformIO plugin through the VSCode extension market, which automatically integrates toolchains (such as ARM GCC), debuggers (OpenOCD), and library management systems, supporting development on multiple platforms such as STM32 and ESP32.

[0003] The advantages of this solution are: it supports automatic configuration of the compilation environment, dependency libraries and debugging interface, and also supports a variety of embedded frameworks (such as STM32 HAL, Arduino, ESP-IDF).

[0004] The disadvantages of this plan: Complex projects require deep customization of platformio.ini, which is prone to errors when editing text and is difficult to adapt to debugging non-standard hardware. Compared with professional IDEs, its real-time debugging and memory analysis functions are weaker.

[0005] 2. Makefile + GCC toolchain solution The core mechanism of this solution is to manually write a Makefile in VSCode to define compilation rules, use the GCC cross compiler to generate an executable program, and use the TFTP32 tool and manually written gdb debugging scripts to achieve burning and debugging.

[0006] The advantages of this approach are: it supports deep customization of compilation options, memory layout (.ld file), and optimization strategies; it does not depend on specific plugins; and it is compatible with any toolchain.

[0007] The disadvantages of this solution are: complex configuration, manual management of dependency paths, startup files and peripheral drivers, high learning cost, and a certain technical threshold for users.

[0008] 3. Keil Assistant Plugin Solution The core mechanism of this solution is to integrate the Keil MDK toolchain (such as ARMCC) into VSCode, reusing the Keil project configuration and debugging engine. The advantages of this solution include: support for professional debugging, such as real-time variable tracking, hardware breakpoints, and performance analysis.

[0009] The drawback of this approach is that its closed ecosystem only supports the ARM architecture and cannot be extended to platforms such as RISC-V.

[0010] Based on the analysis of the shortcomings of existing related technical solutions, the core technical problems to be solved by this patent application can be summarized into the following three aspects: 1. Cross-platform toolchain automated configuration issues Existing solutions (such as PlatformIO) require manual customization of complex configuration files (such as platformio.ini) through text editing, which is prone to configuration failure due to path errors, parameter conflicts or format issues. Furthermore, they are difficult to adapt to the debugging needs of non-standard hardware and lack an automated toolchain discovery and dynamic adaptation mechanism for heterogeneous hardware platforms (ARM / RISC-V / XTensa), resulting in reliance on manual intervention.

[0011] 2. The problem of high complexity in development environment configuration. Makefile-based solutions require developers to manually manage compilation rules, dependency paths, startup files, and peripheral drivers. The configuration process is cumbersome and error-prone, significantly increasing the learning curve and development cycle. Furthermore, the lack of a unified engineering template and intelligent build system prevents the automatic generation of appropriate compilation scripts, memory layouts (.ld files), and debugging interface configurations based on the chip model.

[0012] 3. Scalability issues across multiple architecture platforms Closed solutions (such as Keil Assistant) only support the ARM architecture and cannot be extended to emerging platforms such as RISC-V and ESP32. They also rely on commercially licensed toolchains, which limits development flexibility. The lack of open and modular debug engine interfaces makes them incompatible with multi-architecture debuggers and open-source toolchains. Summary of the Invention

[0013] To address the challenges of achieving automated toolchain configuration, intelligent build process generation, and unified debugging interface adaptation for cross-platform embedded development environments through standardized architecture design, this paper proposes an embedded operating system development environment architecture design method based on VSCode. This method aims to reduce configuration complexity, improve multi-hardware compatibility and development efficiency, and focuses on solving core issues such as automated toolchain integration, operating system adaptability, standardized debugging interfaces, and scalability of the build system.

[0014] The technical solution of this invention is as follows: An embedded operating system development environment architecture design method based on VSCode is presented. The embedded operating system development environment adopts an open architecture design, supporting integration with various embedded operating systems and build systems via configuration files. The resources relied upon during development include target and host resource libraries. The functional modules and development sequence are: code editing -> system configuration -> cross-compilation -> image loading -> remote debugging, as detailed below: Code editing: Includes basic editing and auto-completion functions, providing convenience for embedded software programming and code analysis, and shortening the editing-compiling-debugging cycle; uses the Monaco editor framework and implements auto-completion function by combining with language service protocols; System Configuration: Based on system environment variables, the system reads the operating system definition model file and operating system module definition model file from the target repository. It provides a graphical form interface for users to select the operating system version and hardware platform, automatically creates the system configuration data model, and enables tree-view editing of the system configuration data model by extending the VSCode editor extension point. When the system configuration editor saves, it calls the Handlebars code generator to generate operating system framework code, build scripts, and debug scripts based on the code templates in the target repository. The build scripts and debug scripts automatically associate the corresponding operating system runtime libraries, header files, and debuggers based on the user-selected operating system version, hardware platform, and configuration data. Cross-compilation: Extending VSCode's command and menu extension points enables compilation commands and right-click context menus. Users can select compilation commands through VSCode's command controller or select the compilation menu through the right-click context menu in the resource browser to execute compilation. The compilation process automatically creates compilation tasks based on the build script, adds Cygwin and GCC toolchain environment variables to the tasks, and then calls the make and GCC toolchain execution instructions under the host repository according to the build rules in the build script. After successful compilation, an executable program will be generated in the compilation path. Image loading: Extending VSCode's command and menu extension points to implement compilation commands and right-click context menus. Users can select the load command through VSCode's command controller or select the load menu through the right-click context menu in the resource browser to execute the loading. The loading principle is to start the TFTP service, set the executable program's path to the TFTP service path, set the TFTP client command in the bootloader when the target machine starts up, and send a request to obtain the executable file from the host machine's IP address. After receiving the request, the TFTP service will transmit the executable file in packets. After the data packets are successfully transmitted, the target machine's bootloader will automatically run the executable program. Remote debugging: The principle of remote debugging is GDB remote debugging. After the executable program is loaded and run, a network connection is established between the debugging agent gdb on the host machine and the debugging service gdb server in the embedded operating system. MI debugging commands and data are transmitted in this connection and converted into VSCode debugging graphical interface data through the VSCode debugging adapter. Users can then control operations and view debugging information through the VSCode debugging graphical interface.

[0015] Furthermore, the target repository is a local folder. The system environment variable REDE_TARGET_HOME is set to point to this folder path. The folder contains the operating system system definition model file ProductModel.json, the operating system static library .a, the operating system header file .h, the operating system module definition model file .json, and the code template .handlebars.

[0016] Furthermore, the host repository is a local folder whose path is set in the system environment variable REDE_HOST_HOME to point to; the folder contains the cross-compilation environment cygwin, gcc, and the debugger gdb.

[0017] Furthermore, the tree nodes in the tree editor in the system configuration correspond to the operating system's functional modules, and the hierarchical relationship between each tree node is displayed to the user in a tree structure. Users can check and decheck each tree node, which respectively represent enabling and disabling the functional module. Clicking on each tree node will open a form displaying the configurable parameters of that tree node module.

[0018] Furthermore, during remote debugging, users can control operations and view debugging information through the VSCode debugging graphical interface, including: setting breakpoints, single-stepping, jumping in, jumping out, running, pausing, and viewing debugging information through the stack view, variable view, and register view.

[0019] The beneficial effects of this invention are as follows: I. Significantly Improved Efficiency of Cross-Platform Toolchain Automated Configuration Dynamic hardware platform adaptation: The system automatically generates a configuration data model by combining the operating system definition model (ProductModel.json) and module definition model in the target resource library with a form-based graphical interface. Users only need to select the operating system version and hardware platform (such as ARM / RISC-V), and the system automatically associates the corresponding toolchain, header files, and debugger, eliminating path errors and parameter conflicts in manually configured files such as platformio.ini.

[0020] Toolchain discovery and integration automation: The host repository comes pre-configured with a cross-compilation environment (GCC) and debugger (GDB), and the environment variable (REDE_HOST_HOME) enables automatic path binding. This avoids developers manually downloading / configuring the toolchain and solves the problem of open-source toolchain version fragmentation.

[0021] II. Significantly reduced complexity in development environment configuration Intelligent build system generation: Build scripts (Makefile / task.json) and debug scripts (launch.json) are dynamically generated using the Handlebars template engine. Based on the user-selected chip model, it automatically generates appropriate compilation rules, peripheral driver initialization code, and memory allocation schemes, replacing the tedious process of manually writing Makefiles.

[0022] Unified management of engineering templates: The target resource library includes built-in operating system framework code templates (.handlebars), combined with a tree-view editor to configure parameters (such as network card IP addresses). Standardized peripheral driver configuration processes (e.g., automatic generation of Ethernet initialization code) reduce hardware initialization failures caused by incorrect startup file configurations.

[0023] III. Enhanced compatibility and flexibility in multi-architecture debugging Open debug engine interface: The debug agent (GDB) and debug service (GDB Server) communicate via a standardized network protocol, and the VSCode debug adapter (DAP) translates debug commands. Compatible with debuggers for multiple architectures such as ARM / RISC-V.

[0024] Seamless integration of remote debugging workflow: TFTP service automatically transfers executable files to the target machine, and GDB Server provides real-time feedback of debugging data to the VSCode graphical interface. This enables complex debugging operations such as register monitoring and peripheral register viewing, resolving the strong coupling between debugging scripts and hardware platforms in traditional solutions.

[0025] IV. Optimization of Development Efficiency and Collaboration Experience A fully automated lifecycle pipeline: a closed-loop process of code editing -> system configuration -> cross-compilation -> image loading -> remote debugging is built into a single VSCode environment. This reduces the cost for developers switching between multiple tools.

[0026] Resource isolation and cross-platform consistency: The target and host repositories are isolated via environment variables, and the VSCode plugin supports cross-platform compatibility with Windows and Linux. This ensures consistent environment configurations during team collaboration, eliminating the typical problem of "it works in the local environment but fails in others' environments." Attached Figure Description

[0027] Figure 1 This is a diagram of the embedded operating system development environment architecture for this invention. Figure 2 is an example diagram of the embedded operating system definition model of the present invention; Figure 2-1 and 2-2 The complete image is shown in Figure 2 after being pieced together. Figure 3 This is an example diagram illustrating the embedded operating system module definition model of the present invention; Figure 4 This is an example diagram of the handlebars template of the present invention; Figure 5 This is an example image showing the effect of generating the header file for the handlebars template of this invention; Figure 6 is an example diagram of the cross-compilation task.json file of the Ruihua Embedded Operating System of this invention; Figure 6-1 and 6-2 The complete figure is obtained after splicing. Figure 7 This is an example diagram of the execution of the task.json file in the cross-compilation of the Ruihua embedded operating system according to the present invention; Figure 8 This is an example diagram of starting the TFTP service in this invention; Figure 9 This is an example diagram of TFTP data transmission according to the present invention; Figure 10 is an example of the launch.json file for debugging the Ruihua operating system according to the present invention; Figure 10-1 and 10-2 The complete figure 10 is obtained after splicing. Figure 11 This is an example image showing the debugging effect of the Ruihua operating system in VSCode. Detailed Implementation

[0028] The present invention will now be described in detail with reference to the accompanying drawings and specific embodiments. These embodiments are based on the technical solution of the present invention and provide detailed implementation methods and specific operating procedures. However, the scope of protection of the present invention is not limited to the following embodiments.

[0029] The embedded operating system development environment is implemented through customized plugins on VSCode. VSCode runs on a desktop operating system, interacting with the user through a graphical interface and communicating with the embedded operating system via TCP and UDP links. VSCode was chosen as the platform for developing plugins and serving as the embedded operating system development environment because VSCode itself consumes few resources and starts up quickly, making it suitable for resource-sensitive embedded development scenarios. It avoids the bloat of traditional IDEs, allowing developers to focus on core code writing and debugging. VSCode plugins provide features such as syntax highlighting, intelligent completion, and code refactoring for multiple languages, and support debugging capabilities such as breakpoint debugging, register monitoring, and peripheral device operation. VSCode is cross-platform compatible, supporting Windows, Linux, and macOS systems, ensuring seamless migration of the development environment across different operating systems and improving team collaboration and development flexibility. The VSCode community is active, and the plugin marketplace allows for the rapid integration of required functionalities.

[0030] Embedded operating system development environments provide full lifecycle development support for applications based on embedded operating systems.

[0031] An embedded operating system development environment architecture design method based on VSCode is as follows: The embedded operating system development environment adopts an open architecture design, supporting integration with various embedded operating systems and build systems through configuration files. The main functional modules and development sequence are: code editing -> system configuration -> cross-compilation -> image loading -> remote debugging. The resources that development depends on include the target resource library and the host resource library, which are described below: The target repository is a local folder. The system environment variable `REDE_TARGET_HOME` should be set to point to this folder. This folder contains the operating system system definition model file (`ProductModel.json`), the operating system static library (`.a`), the operating system header files (`.h`), the operating system module definition model file (`.json`), and the code template (`.handlebars`).

[0032] The host repository is a local folder. The system environment variable `REDE_HOST_HOME` must be set to point to this folder. This folder contains the cross-compilation environment (Cygwin, GCC) and the debugger (GDB).

[0033] Code editing: Supports C, C++, and other code editing, including basic editing and auto-completion features, facilitating embedded software programming and code analysis, thereby accelerating the development process, shortening the edit-compile-debug cycle, and reducing the error rate. Using the Monaco editor framework, combined with the Language Service Protocol (LSP) to implement auto-completion functionality, improves the user-friendliness of the auto-completion feature, enhances the efficiency of the integrated development environment, and reduces the consumption of host machine resources.

[0034] System Configuration: Based on system environment variables, the system reads the operating system definition model file and operating system module definition model file from the target repository. It provides a graphical form interface for users to select the operating system version and hardware platform, automatically creating a JSON-formatted system configuration data model. This model is then edited using a tree-view editor extension point in VSCode. The tree nodes correspond to operating system functional modules, displaying a hierarchical structure. Users can check and decheck each node, enabling or disabling functional modules. Clicking on a node opens a form showing the configurable parameters for that module; for example, the network interface card (NIC) module node can configure parameters such as IP address and gateway address. When the system configuration editor saves, it calls the Handlebars code generator to generate operating system framework code, build scripts (task.json, makefile), and debug scripts (launch.json) based on the code templates in the target repository. The build and debug scripts automatically associate the corresponding operating system runtime libraries, header files, and debuggers based on the user-selected operating system version, hardware platform, and configuration data.

[0035] Cross-compilation: Extending VS Code's command and menu extensions enables compilation commands and right-click context menus. Users can select compilation commands through VS Code's command controller or execute compilation via the right-click context menu in the resource browser. The compilation process automatically creates compilation tasks based on the build script `task.json`, adds Cygwin and GCC toolchain environment variables to the tasks, and then calls the `make` and `gcc` toolchains from the host repository to execute instructions according to the build rules in the Makefile. The compilation process is output in VS Code's OUPUT view, with warnings or errors highlighted in yellow or red. Successful compilation generates an executable program in the compilation path, typically in .elf and .out format.

[0036] Image loading: This extends VSCode's command and menu extension points to implement compilation commands and right-click context menus. Users can select the loading command through VSCode's command controller or execute the loading through the right-click context menu in the resource browser. The loading principle involves starting a TFTP service, setting the executable's path to the TFTP service path, configuring the TFTP client command in the target machine's bootloader, and sending a request to retrieve the executable file from the host machine's IP address. Upon receiving the request, the TFTP service will transmit the executable file in packets. The packet transmission process is output in VSCode's OUPUT view. After successful packet transmission, the target machine's bootloader automatically runs the executable.

[0037] Remote debugging: The principle of remote debugging is GDB remote debugging. After the executable program is loaded and run, a network connection is established between the debugging agent gdb on the host machine and the debugging service gdb server in the embedded operating system. MI debugging commands and data are transmitted in this connection and converted into VSCode debugging graphical interface data through VSCode's C / C++ Debug Adapter (DAP). Users can then perform control operations such as setting breakpoints, single-stepping, jumping in, jumping out, running, and pausing through VSCode's debugging graphical interface, as well as view debugging information through stack view, variable view, register view, etc.

[0038] The following section uses the domestically developed Ruihua embedded operating system as an example to illustrate the specific implementation steps of the above functions and why these technology stack combinations were chosen: Step 1: Integrating the Embedded Operating System For an embedded operating system development environment to develop embedded operating systems, the first step is to integrate the embedded operating system. Due to the open architecture design, this integration work can be handled by different embedded operating system vendors, thus enabling support for multiple embedded operating systems.

[0039] When selecting the technology stack for operating system definition and operating system module definition models, JSON is a better choice due to its strong structured expression capabilities, comprehensive toolchain support, efficient transmission, and cross-language compatibility. JSON's key-value pairs and nested structures can clearly map complex configuration models (such as objects and arrays), while VSCode natively provides JSON syntax highlighting, auto-completion, and validation functions, significantly improving development efficiency. Furthermore, JSON's lightweight nature (30%~50% smaller than XML) and broad language parsing support (such as JavaScript's JSON.parse() and Python's json.loads()) makes it the standard data format in the VSCode ecosystem (such as settings.json and launch.json), ensuring seamless flow of configuration data between the editor and external systems. As shown in Figure 2, the Ruihua embedded operating system definition model ProductModel.schema.json. Figure 3 As shown, the Ruihua Embedded Operating System Module Definition Model is FT1500A-64bits_CETC32_SMP_BSP.json.

[0040] When selecting a code template technology stack, Handlebars was chosen. Handlebars is a JavaScript-based semantic template engine that uses double curly braces {{}} to dynamically bind data to static templates. Handlebars' {{key}} syntax naturally adapts to JSON's key-value pair structure, seamlessly integrating with operating system configuration models. Handlebars can directly bind nested properties (such as {{user.address.city}}) without additional parsing logic, making it suitable for the tree-structured design of operating system configuration models. Furthermore, Handlebars supports internal syntax, using {{#if}} and {{#each}} to implement conditional rendering and loops, thereby generating filtered data. Handlebars also supports registering logic extension functions (such as date formatting and numerical calculations), for example, Handlebars.registerHelper("parseInt", str =>parseInt(str)), enhancing the template's ability to handle complex business logic. Figure 4 , 5 As shown, this is a handlebars template that generates a header file based on system configuration data, and the effect of the generated header file.

[0041] Step 2: Cross-compilation Cross-compilation in VSCode relies heavily on the `tasks.json` configuration file. `tasks.json` defines automated compilation tasks, integrating command-line compilation into VSCode: the compiler (e.g., gcc) is specified via `command`, compilation parameters (e.g., `-g` generates debug information, `-o` specifies the output path) are set via `args`, and dynamic path variables and error parsing are supported. The default compilation task is executed by pressing Ctrl+Shift+B, generating an executable file. Figure 6 shows an example of `tasks.json` for cross-compilation using the Ruihua Embedded Operating System integrated with the aarch64 toolchain. Figure 7 The image shows the effect of executing the compilation task defined in the task.json file above in vscode.

[0042] Step 3: Image Loading In embedded operating system development, TFTP (Trivial File Transfer Protocol) is used to load images primarily due to its lightweight, efficient, and easy-to-implement characteristics, making it particularly suitable for resource-constrained embedded environments. TFTP is a minimal file transfer protocol based on UDP (port 69), designed specifically for small file transfers. A TFTP server is implemented in VSCode through a custom plugin, allowing the development board to send requests to retrieve the compiled executable image file via a TFTP client. Figure 8 , 9 As shown, this is an example of a TFTP service and data transfer implemented by developing a plugin in VSCode.

[0043] Step 4: Remote Debugging Remote debugging in VSCode relies heavily on the launch.json configuration file. launch.json defines the debugger behavior and controls the program debugging session. It specifies the C / C++ debugger (based on GDB / LLDB) using the debugger type: "type": "cppdbg", and "program" points to the executable file generated by tasks.json (e.g., "${fileDirname} / main"). The debugging process supports breakpoints, variable monitoring, and call stack viewing. Debugging is initiated by pressing F5. Figure 10 shows an example of launch.json for debugging the Ruihua embedded operating system in VSCode. Figure 11 As shown, this demonstrates the effect of using the aforementioned debug configuration file in VSCode to debug the Ruihua Embedded Operating System.

[0044] The above-described embodiments are merely one implementation of the present invention, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of the invention. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of the present invention, and these all fall within the protection scope of the present invention. Therefore, the protection scope of this invention should be determined by the appended claims.

Claims

1. A method for designing an embedded operating system development environment architecture based on VSCode, characterized in that, The embedded operating system development environment adopts an open architecture design, supporting integration with various embedded operating systems and build systems through configuration files. The resources relied upon during development include target and host resource libraries. The functional modules and development sequence are: code editing -> system configuration -> cross-compilation -> image loading -> remote debugging, as detailed below: Code editing: Includes basic editing and auto-completion functions, providing convenience for embedded software programming and code analysis, and shortening the editing-compiling-debugging cycle; uses the Monaco editor framework and implements auto-completion function by combining with language service protocols; System Configuration: Based on system environment variables, the system reads the operating system definition model file and operating system module definition model file from the target repository. It provides a graphical form interface for users to select the operating system version and hardware platform, automatically creates the system configuration data model, and enables tree-view editing of the system configuration data model by extending the VSCode editor extension point. When the system configuration editor saves, it calls the Handlebars code generator to generate operating system framework code, build scripts, and debug scripts based on the code templates in the target repository. The build scripts and debug scripts automatically associate the corresponding operating system runtime libraries, header files, and debuggers based on the user-selected operating system version, hardware platform, and configuration data. Cross-compilation: Extending VSCode's command and menu extension points enables compilation commands and right-click context menus. Users can select compilation commands through VSCode's command controller or select the compilation menu through the right-click context menu in the resource browser to execute compilation. The compilation process automatically creates compilation tasks based on the build script, adds Cygwin and GCC toolchain environment variables to the tasks, and then calls the make and GCC toolchain execution instructions under the host repository according to the build rules in the build script. After successful compilation, an executable program will be generated in the compilation path. Image loading: Extends VSCode's command and menu extension points to implement compilation commands and right-click context menus. Users can select the load command through VSCode's command controller or select the load menu through the right-click context menu in the resource browser to execute the load. The loading principle is to start the TFTP service, set the path of the executable program to the TFTP service path, set the TFTP client command in the bootloader when the target machine starts, send a request to obtain the executable file from the host machine IP address, and after the TFTP service receives the request, it will transmit the executable file in packets. After the data packet transmission is successful, the target machine bootloader will automatically run the executable program. Remote debugging: The principle of remote debugging is GDB remote debugging. After the executable program is loaded and run, a network connection is established between the debugging agent gdb on the host machine and the debugging service gdb server in the embedded operating system. MI debugging commands and data are transmitted in this connection and converted into VSCode debugging graphical interface data through the VSCode debugging adapter. Users can then control operations and view debugging information through the VSCode debugging graphical interface.

2. The method for designing an embedded operating system development environment architecture based on VSCode according to claim 1, characterized in that, target repository: A local folder. Set the REDE_TARGET_HOME environment variable in the system environment variables to point to this folder path. The folder contains the operating system system definition model file ProductModel.json, the operating system static library .a, the operating system header file .h, the operating system module definition model file .json, and the code template .handlebars.

3. The embedded operating system development environment architecture design method based on VSCode according to claim 1, characterized in that, The host repository is a local folder. The system environment variable REDE_HOST_HOME is set to point to this folder path. The folder contains the cross-compilation environment cygwin, gcc, and the debugger gdb.

4. The embedded operating system development environment architecture design method based on VSCode according to claim 1, characterized in that, The tree nodes in the system configuration tree editor correspond to the operating system function modules, and the hierarchical relationship between the tree nodes is displayed to the user in a tree structure. Users can check and decheck each tree node, which represents enabling and disabling the function module, respectively. Clicking on each tree node will open a form displaying the configurable parameters of that tree node module.

5. The embedded operating system development environment architecture design method based on VSCode according to claim 1, characterized in that, During remote debugging, users can control operations and view debugging information through the VSCode debugging graphical interface, including: setting breakpoints, single-stepping, stepping in, stepping out, running, pausing, and viewing debugging information through the stack view, variable view, and register view.

Images