A method and system for generating BSP code based on a large language model

Abstract

This invention discloses a BSP code generation method and system based on a large language model. The method includes: parsing and extracting features from the original SDK of the target chip to construct a chip capability model of the target chip; constructing a transformation descriptor based on the chip capability model of the target chip and a predefined BSP specification knowledge base; constructing a large code language model and fine-tuning the large code language model; inputting the transformation descriptor into the fine-tuned large code language model to generate source code files; automatically verifying and integrating the source code files; and assembling the verified and integrated source code files into a BSP project file that can be directly compiled and used. This invention can quickly and automatically generate compliant and reliable BSP projects, significantly improving development efficiency, lowering the technical threshold, ensuring code quality, and being compatible with multiple vendor SDKs, effectively accelerating the expansion of the embedded operating system ecosystem.

Description

Technical Field

[0001] This invention relates to the field of embedded system software development tools, and in particular to a BSP code generation method and system based on a large language model. Background Technology

[0002] With the rapid development of the Internet of Things (IoT) and smart devices, the number of embedded microcontroller models has surged. Adapting a Board Support Package (BSP) for the real-time operating system of each microcontroller chip has become a demanding and critical task. Taking the RT-Thread operating system as an example, traditional BSP development requires developers to deeply understand the chip manufacturer's Software Development Kit (SDK) and manually package it into BSP code that conforms to the RT-Thread device driver framework and kernel porting layer interface. This results in repetitive and inefficient development, long development cycles, high technical barriers, and inconsistent code quality, severely restricting the speed of embedded operating system support for new chips and ecosystem expansion, making it difficult to meet the industry's demand for rapid adaptation to a massive number of chips. Summary of the Invention

[0003] The purpose of this invention is to overcome the shortcomings of the prior art. This invention provides a BSP code generation method and system based on a large language model, which can quickly and automatically generate compliant and reliable BSP projects, greatly improve development efficiency, lower technical threshold, ensure code quality, and be compatible with multiple vendor SDKs, effectively accelerating the expansion of the embedded operating system ecosystem.

[0004] This invention provides a BSP code generation method based on a large language model, the method comprising:

[0005] The original SDK of the target chip is parsed and its features are extracted to construct a chip capability model of the target chip; A transformation descriptor is constructed based on the chip capability model of the target chip and a predefined BSP specification knowledge base; Construct a large code language model and fine-tune it. The transformation descriptor is input into the fine-tuned code language model to generate source code files; Automated verification and integration of the source code files; The verified and integrated source code files are assembled into a BSP project file that can be directly compiled and used.

[0006] Furthermore, the process of parsing and extracting features from the original SDK of the target chip to construct a chip capability model includes: Preprocess the original SDK of the target chip; Based on the built-in SDK structure knowledge base, the structural paradigm of the original SDK of the target chip is identified, and the key files of the original SDK of the target chip are obtained. Semantic analysis and information extraction are performed on the key files of the original SDK of the target chip to obtain the chip capability information of the target chip; A blank data model object is created, and the chip capability information of the target chip is filled into the nodes of the blank data model object to generate the chip capability model of the target chip.

[0007] Furthermore, when the structural paradigm of the original SDK of the target chip cannot be identified, manual configuration is performed, and the SDK structure knowledge base is updated based on the manual configuration results.

[0008] Furthermore, the semantic analysis and information extraction of key files in the original SDK of the target chip to obtain chip capability information includes: Regular expressions and a lightweight parser are used to parse the feature header files of the target chip; Static code analysis is used to parse the peripheral driver library files of the target chip. Parse the target chip's startup file and linker file.

[0009] Furthermore, the construction of the transformation descriptor based on the chip capability model of the target chip and the predefined BSP specification knowledge base includes: Determine the driver conversion task, extract the peripheral driver to be converted from the chip capability model of the target chip, and anchor the core elements of the peripheral driver to be converted. Extract the key functions and data structures of the peripheral driver to be converted; Query the predefined BSP specification knowledge base and match the driver framework standard corresponding to the peripheral driver to be converted; The data obtained above are combined to form a transformation descriptor consisting of multi-paragraph structured text.

[0010] Furthermore, the construction of the large code language model and the fine-tuning of the large code language model include: Select the code-major language model that matches the BSP code; Collect a large amount of "transformation descriptor-target-driven code" pairing data and form training pairs; Based on the training pairs, the selected code-large language model is trained using a supervised fine-tuning method; The code generated by the trained code-large language model is aligned with the generation preferences of the trained code-large language model using a reinforcement learning method based on human feedback.

[0011] Furthermore, the step of inputting the transformation descriptor into the fine-tuned code large language model to generate source code files includes: The transformation descriptor is input into the fine-tuned code language model, and a complete C language source code file is generated autoregressively, conditioned on the structured description of the chip capability model of the target chip.

[0012] Furthermore, the automated verification and integration of the source code files includes: Perform syntax and compilation checks on the source code file; Static analysis was performed on the API compliance of the source code files. The hardware dependencies and consistency between the source code file and the chip capability model of the target chip are checked. The code style and security rules of the source code files are checked.

[0013] Furthermore, assembling the verified and integrated source code files into a BSP project file that can be directly compiled and used includes: Create a standardized BSP project catalog that matches the target chip; Install and modify the startup file and linker file in the chip capability model of the target chip; Generate the board-level core configuration file for the target chip; Integrate the source code files to generate a configuration file for building the BSP project file; Build an IDE project template, fill in the BSP information of the target chip, and generate a BSP project metadata file.

[0014] This invention also provides a BSP code generation system based on a large language model, which is used to implement the above-mentioned BSP code generation method based on a large language model. The system includes: A chip capability model building module is used to parse and extract features from the original SDK of the target chip to build a chip capability model of the target chip. A transformation descriptor construction module is used to construct transformation descriptors based on the chip capability model of the target chip and a predefined BSP specification knowledge base; A code-large language model construction module is used to construct a code-large language model and fine-tune the code-large language model. A source code file generation module is used to input the transformation descriptor into the fine-tuned code language model to generate source code files. A verification and integration module, which is used to automatically verify and integrate the source code file; The project file assembly module is used to assemble the verified and integrated source code files into BSP project files that can be directly compiled and used.

[0015] This invention provides a BSP code generation method and system based on a large language model. It achieves fully automated generation of BSP code from chip SDK through a large language model, significantly reducing the manual development cycle from days or weeks to minutes, greatly improving development efficiency. The generated code strictly adheres to the driver framework specifications, ensuring a unified style, high reliability, and strong consistency, effectively solving the problem of inconsistent quality in manual development. Simultaneously, it lowers the threshold for embedded operating system porting, allowing developers to complete adaptation without needing expertise in the underlying details of the target chip's real-time operating system. It is compatible with heterogeneous SDKs from multiple vendors, has strong generalization capabilities, and ensures direct compilation and execution of the code through multi-level automated verification, ultimately outputting a complete and usable BSP project that can quickly support new chip adaptation and operating system ecosystem expansion. Attached Figure Description

[0016] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0017] Figure 1 This is a flowchart of the BSP code generation method based on a large language model in Embodiment 1 of the present invention; Figure 2 This is a flowchart of constructing a chip capability model of a target chip in Embodiment 1 of the present invention; Figure 3 This is a flowchart of constructing a transformation descriptor in Embodiment 1 of the present invention; Figure 4 This is a flowchart of constructing and fine-tuning a large code language model in Embodiment 1 of the present invention; Figure 5 This is a flowchart of assembling source code files to generate BSP project files in Embodiment 1 of the present invention; Figure 6 This is an architecture diagram of the BSP code generation system driven by a large language model in Embodiment 2 of the present invention. Detailed Implementation

[0018] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0019] In this invention, it should be understood that terms such as “comprising” or “having” are intended to indicate the presence of features, figures, steps, behaviors, components, portions or combinations thereof disclosed in this specification, and are not intended to exclude the possibility that one or more other features, figures, steps, behaviors, components, portions or combinations thereof are present or added.

[0020] It should also be noted that, unless otherwise specified, the embodiments and features described in the present invention can be combined with each other. The present invention will now be described in detail with reference to the accompanying drawings and embodiments.

[0021] In the field of embedded microcontroller development, the adaptation process of board support packages (BSPs) relies on the manual parsing and encapsulation of the chip manufacturer's software development kit (SDK). This process requires developers to deeply understand the structured content of the SDK and convert it into code that conforms to the device driver framework and kernel porting layer interface of the real-time operating system. The SDK parsing requires manual identification of hardware characteristics, peripheral driver logic, and startup configurations, leading to repetitive operations, extended development cycles, higher technical barriers, and unstable code quality. This, in turn, restricts the speed at which the operating system supports new chips and the ecosystem's expansion capabilities.

[0022] For example, when adapting the RT-Thread operating system to new 32-bit microcontroller chips, developers need to process the feature header files, peripheral driver libraries, and linker scripts in the chip SDK one by one, and manually compare the hardware register definitions with the operating system interface specifications to complete the code writing. Furthermore, due to the differences in SDK structures among different chip manufacturers, developers need to repeatedly verify the compatibility of the hardware abstraction layer and the driver framework, resulting in frequent development process interruptions. At the same time, the code implementation relies on personal experience, leading to deviations in API consistency, hardware dependency handling, and resource management in the generated BSP modules, affecting the overall portability and stability of the system.

[0023] If the above problems are not resolved, the inefficiency of BSP development will exacerbate the bottleneck effect of the expansion of the embedded operating system ecosystem, making it difficult for the integration process of new chips to adapt to the rapid iteration of chip models in the Internet of Things industry, thereby hindering the timeliness of device deployment and market responsiveness.

[0024] Example 1 Embodiment 1 of the present invention provides a BSP code generation method based on a large language model, the method comprising: The original SDK of the target chip is parsed and its features are extracted to construct a chip capability model of the target chip; A transformation descriptor is constructed based on the chip capability model of the target chip and a predefined BSP specification knowledge base; Construct a large code language model and fine-tune it. The transformation descriptor is input into the fine-tuned code language model to generate source code files; Automated verification and integration of the source code files; The verified and integrated source code files are assembled into a BSP project file that can be directly compiled and used.

[0025] In one optional implementation of this embodiment, such as Figure 1 As shown, Figure 1 The flowchart of the BSP code generation method based on a large language model driven by the present invention is shown in Embodiment 1 of the present invention, including the following steps: S101. Analyze and extract features from the original SDK of the target chip to construct a chip capability model of the target chip; In one optional implementation of this embodiment, the unstructured, heterogeneous target chip's original SDK is first deeply analyzed and transformed into a unified, structured, programmable query intermediate representation, namely, the target chip's chip capability model. This model is a complete abstraction of the chip's hardware resources, software driver interfaces, and engineering configurations. The construction process follows a multi-level, progressive analysis flow, with the original SDK as input and a structured JSON model as output, providing precise input for the core data conversion and code generation stages.

[0026] Specifically, such as Figure 2 As shown, Figure 2 The flowchart illustrating the construction of a chip capability model for a target chip in Embodiment 1 of the present invention is shown, including the following steps: S201. Preprocess the original SDK of the target chip; In one optional implementation of this embodiment, the original SDK of the target chip is decompressed or standardized.

[0027] Specifically, since the original SDK of the target chip is usually a complete software development kit, it is usually provided in the form of compressed package (such as .zip, .tar.gz) or source code directory. Therefore, compressed package needs to be decompressed, while source code directory needs to be scanned in a standardized manner.

[0028] S202. Identify the structural paradigm of the original SDK of the target chip based on the built-in SDK structure knowledge base, and obtain the key files of the original SDK of the target chip; In one optional implementation of this embodiment, based on the built-in SDK structure knowledge base, it is identified whether the structural paradigm of the original SDK of the target chip conforms to the common paradigms in the knowledge base (e.g., ST's STM32CubeMX series, NXP's MCUXpresso SDK series, GigaDevice's GD32 Firmware Library, etc.). Based on this identification process, the key files of the original SDK of the target chip can be obtained, including the target chip series / model and kernel type, and the core component directories in the SDK can be located, such as Drivers / (driver layer), Device / (device header file), Projects / (sample project), Middlewares / (middleware), etc., to establish an index for subsequent targeted parsing.

[0029] It should be noted that when the original SDK structure of the target chip cannot be identified, manual configuration should be performed, and the SDK structure knowledge base should be updated based on the manual configuration results.

[0030] Specifically, if the SDK does not conform to common paradigms, a clear error report is generated, indicating that the SDK structure cannot be recognized, and guiding the user to perform manual configuration (users can manually annotate key files and paths through interactive tools, record this pattern and update the knowledge base for future reuse).

[0031] S203. Perform semantic analysis and information extraction on the key files of the original SDK of the target chip to obtain the chip capability information of the target chip; In one optional implementation of this embodiment, a parser performs semantic analysis and information extraction on the key files of the original SDK of the preprocessed target chip to obtain chip capability information for subsequent construction of the chip capability model.

[0032] Specifically, the chip capability information used to build the chip capability model mainly includes the chip's feature header files, peripheral driver library files, startup files, and linker files.

[0033] In an optional implementation of this embodiment, regular expressions and a lightweight parser are used to parse the feature header file of the target chip.

[0034] Specifically, for device-specific header files such as stm32f407xx.h and MKL25Z4.h, regular expressions and a lightweight parser are used for parsing. Regular expressions are primarily used for quickly scanning and extracting text information with fixed, simple patterns. Specifically, they can be used to: extract register and peripheral base addresses: scan all #define macros and identify strings with fixed patterns (usually all uppercase, connected by underscores, and ending with _BASE), such as PERIPH_BASE, APB1PERIPH_BASE, and USART1_BASE. Extract interrupt request numbers (IRQn): identify simple macro definitions like #define USART1_IRQn 37 and extract the correspondence between peripherals and interrupt numbers. Extract clock constants: identify constant macros that define the system clock frequency, such as #define HSE_VALUE 8000000UL.

[0035] Lightweight parsers are used to understand code blocks with complex syntactic structures, resolving their internal hierarchy and type relationships. For example, parsing register structure type definitions: For complex declarations like `typedef struct { ...} USART_TypeDef;`, regular expressions struggle to reliably extract their internal member variables, offsets, and data types. A parser can parse C language type definition syntax, understand that `USART_TypeDef` is a structure type, and further analyze its internal members (such as SR, DR, BRR registers) to understand the register layout.

[0036] Furthermore, this embodiment mainly includes the extraction of three feature header files: register and peripheral mapping, interrupt request number (IRQn) extraction, and clock and pin configuration. Register and peripheral mapping: Scan all macros defined with #define, identify patterns such as PERIPH_BASE, APB1PERIPH_BASE, USART1_BASE, etc., and construct a precise mapping table from peripheral names to their memory mapping base addresses. Then, parse the register structure type definitions (such as typedef struct { ...} USART_TypeDef;) to understand the register layout.

[0037] Interrupt Request Number (IRQn) Extraction: The mapping between peripheral devices and their interrupt request numbers is extracted from the relevant definitions in the interrupt vector table (such as the IRQn_Type enumeration or #define USART1_IRQn 37). Each peripheral interrupt has a corresponding interrupt request number, and each interrupt request number corresponds to a pointer to the entry address of an interrupt service routine (ISR) in the interrupt vector table. This is the interrupt vector. The interrupt service routine is then generated. This completes the interrupt implementation.

[0038] Clock and Pin Configuration: Extract configuration constants (such as HSE_VALUE and HSI_VALUE) related to the system clock and peripheral clock sources, as well as pin multiplexing definitions, to provide a basis for the subsequent automatic generation of clock configuration and pin initialization code in board.h.

[0039] In one optional implementation of this embodiment, static code analysis is used to parse the peripheral driver library files of the target chip.

[0040] Specifically, for peripheral driver source files such as stm32f4xx_hal_uart.c and fsl_uart.c, a more in-depth static code analysis method is used for parsing.

[0041] Furthermore, this embodiment mainly includes two parts: extraction of functions and structures from peripheral driver library files, and configuration and status recognition, wherein: Function and Structure Extraction: Construct a lightweight abstract syntax tree to extract all function declarations (including parameter lists and return types) and global structure / enumeration type definitions. Pay special attention to functions with specific prefixes that characterize hardware operations, such as ST's HAL_ / LL_ series, NXP's UART_ / LPUART_ series, and GD's gpio_ / rcu_ series functions. This is achieved by analyzing function names and parameter types (especially those containing peripheral handle pointers such as UART_HandleTypeDef). Or a base address pointer such as USART_TypeDef The system establishes a mapping relationship between "peripheral instance -> driver function set" by analyzing the parameters and key operations within the function (such as directly manipulating huart->Instance->DR). For example, it identifies that HAL_UART_Init, HAL_UART_Transmit, HAL_UART_Receive, and HAL_UART_IRQHandler all belong to the driver function set of USART1 / 2 / 3...

[0042] Configuration and status identification: Analyze the driver initialization structure (such as UART_InitTypeDef) and extract configurable parameters (baud rate, data bits, stop bits, parity bits, etc.) so that the corresponding configuration options can be exposed in the generated BSP driver.

[0043] In an optional implementation of this embodiment, the startup file and link file of the target chip are parsed.

[0044] Specifically, for parsing the startup file (.s or .c), the process involves parsing the assembly startup file, extracting the interrupt vector table (especially the interrupt service routine symbols related to specific peripherals), the initial stack pointer (__initial_sp), and the heap size (__heap_size).

[0045] Furthermore, for parsing linker files (.ld or .icf), the memory layout is parsed, and the starting addresses and sizes of regions such as FLASH and RAM are extracted to generate the correct linker file in the BSP.

[0046] S204. Create a blank data model object, and fill the corresponding chip capability information of the target chip into the nodes of the blank data model object to generate the chip capability model of the target chip.

[0047] In one optional implementation of this embodiment, a centralized blank data model object (i.e., a JSON tree) is established, and all the chip capability information extracted above (including chip series / model, kernel type, memory mapping, clock constants, peripheral driver information, startup file and link file paths, etc.) are integrated and associated, and correspondingly filled into the nodes of the blank data model object to construct a structured chip capability model of the target chip.

[0048] Specifically, the filling process includes: 1. Create the model root node and fill in mcu_family, mcu_model, and core obtained from the SDK metadata.

[0049] 2. Fill memory_map: Fill in the flash and SRAM area information parsed from the linked file here.

[0050] 3. Fill clock_tree: Clock constants parsed from the header file are filled here.

[0051] 4. Construct the peripherals array: This is the key to integration. For example, for a serial port peripheral (USART): from the header file parsing, obtain its name, base_addr, and irq_number; from the driver library file analysis, obtain its related functions list, config_struct, and handle_struct names; associate this information and combine it into a peripheral object representing "USART1", and add it to the peripherals array.

[0052] 5. Record file paths: Record the paths of startup_file and linker_script in the model.

[0053] Through the above filling process, the chip capability model of the target chip is constructed.

[0054] Through the above technical solution, this application can systematically and automatically extract and organize chip capability information from complex and diverse original manufacturer SDKs. This refined analysis and structured modeling process effectively solves the problems of complex original manufacturer SDK structures, scattered information, and difficulty in unified representation, ensuring that the constructed chip capability model is comprehensive, accurate, and standardized. This high-quality chip capability model provides a solid foundation for subsequent BSP code generation based on large language models, significantly improving the accuracy and reliability of code generation, reducing the error rate and workload of manual analysis and modeling, thereby improving the efficiency and automation level of the entire BSP code generation method.

[0055] In an optional implementation of this embodiment, steps S102-S105 are the core of moving from "information extraction" to "intelligent creation." The goal is to dynamically transform the static "chip capability model" and predefined "RT-ThreadBSP" specification knowledge base generated in step S101 into high-quality C language source code that conforms to the target framework through a large language model. The entire process is divided into: S102 (construction of the transformation descriptor), S103 (construction and fine-tuning of the large code language model), S104 (generation of source code files), and S105 (verification and integration of the source code files).

[0056] S102. Construct a transformation descriptor based on the chip capability model of the target chip and the predefined BSP specification knowledge base; In one optional implementation of this embodiment, the "transformation descriptor" is a "refined context" or "super hint word" that connects the original SDK information with the target RT-Thread driver code. Specifically, it is a structured task instruction generated by extracting, associating, and formatting key information from the "chip capability model" and the "specification knowledge base" through a descriptor generation engine.

[0057] Specifically, such as Figure 3 As shown, Figure 3 The flowchart illustrating the construction of a transformation descriptor in Embodiment 1 of the present invention is shown, including the following steps: S301. Determine the driver conversion task, extract the peripheral driver to be converted from the chip capability model of the target chip, and anchor the core elements of the peripheral driver to be converted. In one optional implementation of this embodiment, it is first necessary to determine that the current task is a "driver conversion task", select the peripheral driver to be converted from the peripherals list in the chip capability model of the target chip, and anchor the core elements of the peripheral driver to be converted: target chip model (from mcu_model), target peripheral type and instance (name: USART2, type: uart).

[0058] S302. Extract the key functions and data structures of the peripheral driver to be converted; In one optional implementation of this embodiment, the source information of the peripheral driver to be converted is extracted and formatted, including key functions and data structures, as well as hardware context information.

[0059] Specifically, for key functions and data structures, the names and full signatures of all key functions are extracted from the functions list of the peripheral device, with functions in categories such as initialization, data transmission and reception, interrupt handling, and control being specifically selected.

[0060] Furthermore, for hardware context information, base_addr (base address) and irq_number (interrupt number) are extracted from the peripheral entry, and core (kernel type) and other information are extracted from the top-level information of the chip capability model.

[0061] It should be noted that the processed information has been organized into a section titled "Key Functions and Data Structures of Original Drivers" and presented in a clear list format.

[0062] S303. Query the predefined BSP specification knowledge base and match the driver framework standard corresponding to the peripheral driver to be converted; In one optional implementation of this embodiment, a predefined "RT-Thread BSP specification knowledge base" is queried, and a match is made based on the peripheral's type (e.g., UART). The knowledge base returns the corresponding driver framework standard, which includes: Standard device operation set structure: for example, the specific definition of struct rt_uart_ops.

[0063] The prototypes of the member functions that must be implemented: such as the expected function signatures of configure, control, putc, getc, etc.

[0064] Driver registration paradigm: For example, the registration function (rt_hw_usart_init) and the standard device registration interface (rt_device_register) that the UART driver should call.

[0065] Interrupt handling specifications: The interrupt service routine writing template required by the RT-Thread kernel, including calls to rt_interrupt_enter() and rt_interrupt_leave(), as well as the reporting method for device-specific interrupts (such as rt_hw_serial_isr).

[0066] It should be noted that the returned driver framework standard is organized into the "RT-Thread Driver Framework Specification" section, which clearly states the "target syntax" that the model needs to follow.

[0067] Furthermore, the "RT-Thread BSP Specification Knowledge Base" is a structured collection of rules, templates, and metadata. It serves as the blueprint for generating standardized BSPs in this embodiment. Its construction is not through machine learning, but rather through manual summarization and generalization of the RT-Thread official codebase, coding standards, and best practices, solidified in a program-readable data format. Its main contents include: 1. Standard BSP Structure Template: Defines the standard catalog layout for BSPs of different series of chips (such as ARM Cortex-M, RISC-V) and different manufacturers.

[0068] 2. Driver Framework Interface Specification: The RT-Thread standard device driver framework details are clearly defined for each peripheral type (UART, SPI, I2C, pin, ADC, etc.). Taking UART as an example, its specific specification items include: The name of the driver operation set structure, such as: struct rt_uart_ops.

[0069] A list of member functions that must be implemented and their precise function signatures.

[0070] Device registration function prototype: For example, a UART device should call rt_hw_serial_register.

[0071] The standard device configuration structure is: struct serial_configure.

[0072] A template for writing interrupt service routines (ISRs), including mandatory calls such as rt_interrupt_enter / leave().

[0073] 3. Configure and build script templates: Kconfig templates define how to generate hierarchical configuration menu options for different drivers. For example, when drv_usart.c exists, how to automatically add configuration items such as config BSP_USING_UARTx and configBSP_UARTx_TX_BUFSIZE to drivers / Kconfig.

[0074] The SConscript template defines how to add the generated driver files and original library files to RT-Thread's SCons build system. The template contains conditional logic that determines whether to add drv_usart.c to the compilation list based on configuration macros in rtconfig.h (such as BSP_USING_UART2).

[0075] 4. Chip-specific patch rules: Stores specific processing rules for different chip manufacturers or architectures. For example: For ST's STM32 series, board.h must include #include "stm32f4xx.h", and the system clock initialization function template name is SystemClock_Config.

[0076] For NXP's Kinetis series, the naming convention for memory regions in the linker file might be m_interrupts and m_text.

[0077] For the ARM Cortex-M core, interrupt service functions need to be defined by adding __attribute__((section(".isr_vector"))) or by using a specific macro (such as void USART2_IRQHandler(void)). The knowledge base stores rules on how to map the irq_number in the chip capability model to the correct function name and declaration.

[0078] 5. IDE Project Templates (Optional): Project file templates for different integrated development environments (such as .uvprojx files for Keil MDK, .ewp files for IAR Embedded Workbench, tasks.json for VSCode, etc.).

[0079] S304. Combine the data obtained above to form a transformation descriptor composed of multi-paragraph structured text.

[0080] In one optional implementation of this embodiment, the data obtained above is combined according to a predefined, optimized prompt template to form the final multi-paragraph structured text, namely the "transformation descriptor".

[0081] The above technical solution systematically identifies driver conversion tasks, extracts key information from the chip capability model, and matches it with the BSP specification knowledge base to ultimately form a structured conversion descriptor. This significantly improves the efficiency and accuracy of the large language model in understanding driver conversion intentions and generating high-quality BSP code. This effectively solves the complexity of converting between chip-specific capabilities and general BSP specifications, avoids the tediousness and error-proneness of manually writing conversion rules, and significantly improves the automation level and reliability of BSP code generation.

[0082] S103. Construct a large code language model and fine-tune the large code language model; In one optional implementation of this embodiment, such as Figure 4 As shown, Figure 4 The flowchart illustrating the construction and fine-tuning of a large code language model in Embodiment 1 of the present invention is shown, including the following steps: S401. Select the code big language model that matches the BSP code; In one optional implementation of this embodiment, DeepSeek-Coder is selected as the basis for the large code model, with the number of optional parameters ranging from 7B to 13B, such as CodeLlama-13B-Instruct or DeepSeek-Coder-V2-Lite. This type of model performs well in code understanding, generation, and completion tasks, and its moderate number of parameters makes it suitable for domain-specific fine-tuning and deployment.

[0083] S402. Collect a large amount of "transformation descriptor-target-driven code" pairing data and form training pairs; In an optional implementation of this embodiment, a large amount of "transformation descriptor-target driver code" pairing data is collected. The transformation descriptors are automatically generated by the "descriptor generation engine" based on historical SDK and BSP data, while the target driver code is high-quality RT-Thread driver source code that has been manually written or reviewed. An example training pair is: (Descriptor_for_STM32_UART, standard drv_usart.c).

[0084] S403. Based on the training pairs, the selected code-large language model is trained using a supervised fine-tuning method; In one optional implementation of this embodiment, the selected code-large language model is trained using the composed training pairs and a standard supervised fine-tuning method. The training objective is to minimize the difference between the target code generated by the model based on the input descriptors and the real standard code (usually using the cross-entropy loss function). This allows the model to establish a complex mapping from various pattern constraints in the descriptors to specific code snippets.

[0085] S404. Using human feedback reinforcement learning methods, the generated code from the trained code-large language model is used to align the generation preferences of the trained code-large language model.

[0086] In one optional implementation of this embodiment, reinforcement learning from human feedback (RLHF) is used to evaluate the quality of the code generated by the trained code-large language model. The evaluation dimensions include functional correctness, code standardization, code quality, efficiency and performance, and security. Preference data is generated, and a reward model is trained using the generated preference data. Furthermore, the generation preferences of the trained code-large language model are aligned using a proximal policy optimization (PPO) algorithm, which can further improve the security, reliability, and style consistency of the generated code.

[0087] Furthermore, the specific criteria for the evaluation dimensions are as follows: Functional correctness: Does the code logic correctly implement the basic operations of the peripheral device (initialization, sending, receiving, interrupt handling)? Could it cause hardware hangs or data errors? Code quality: Does the code strictly adhere to the RT-Thread device driver framework interface? Are the structure definitions, function signatures, and registration processes correct? Code quality: Does it include necessary error checking (such as null pointer exceptions, parameter validity)? Is resource management (such as interrupt enabling / disabling) appropriate? Is the code style clear and consistent? Efficiency and Performance: Are the interrupt service routines concise and efficient? Does the data transmission and reception logic incur unnecessary performance overhead? Security: Are there any potential risks such as buffer overflows or race conditions? Through the above technical solutions, this application can significantly improve the quality and reliability of BSP code generated based on a large language model. By selecting an initial model that matches the BSP code and performing supervised fine-tuning with a large amount of "transformation descriptor-target-driven code" pairing data, the model can accurately learn the mapping relationship from high-level functional descriptions to specific driver code, ensuring the functional correctness of the generated code. Furthermore, by introducing human feedback reinforcement learning, the model can optimize the code's style, efficiency, readability, and adherence to specific coding standards based on the preferences and experience of human experts, thereby generating BSP code that is more in line with actual engineering needs and easier to maintain and integrate. This effectively solves the problems of insufficient accuracy and inconsistent quality that may exist when general-purpose large language models generate domain-specific code, greatly improving the automation level of BSP code generation and the usability of the final code.

[0088] S104. Input the transformation descriptor into the fine-tuned code language model to generate source code files; In an optional implementation of this embodiment, the transformation descriptor is input into the fine-tuned code language model, and a complete C language source code file is generated autoregressively, conditioned on the structured description of the chip capability model of the target chip.

[0089] Specifically, in the actual conversion process, the constructed conversion descriptor is input into the fine-tuned code language model. The structured description of the target chip's chip capability model is used as a condition. The generation process integrates the understanding of the original HAL function logic, the adherence to the RT-Thread framework interface, and the correct use of the given hardware context (address, interrupt number), and regressively generates a complete C language source code file.

[0090] By combining the transformation descriptor with a structured description of the target chip's capability model as input to the large code language model, and employing an autoregressive generation method, the generated source code files ensure that they are not only complete C language code but also accurately reflect the target chip's hardware characteristics and programming specifications. This significantly improves the accuracy and reliability of BSP code generation, avoiding debugging and modification work caused by hardware mismatch or incomplete code, thereby greatly improving the development efficiency and quality of BSP code. The generated code can be directly compiled and used, reducing the possibility of manual intervention and error introduction.

[0091] S105. Perform automated verification and integration on the source code file; In one optional implementation of this embodiment, before the source code file is integrated into the BSP project file, it needs to go through an automated verification and integration process. The core of this process is "syntax and specification check".

[0092] In an optional implementation of this embodiment, the source code file is subjected to syntax and compilation checks.

[0093] Specifically, a compiler front-end such as GCC or Clang is used to perform compilation checks on the generated C source code files (.c files) in strict mode (-Wall -Wextra -Werror). This can catch basic problems such as syntax errors, undefined identifiers, and type mismatches. Passing the check means that the code is at least syntactically correct.

[0094] In one optional implementation of this embodiment, static analysis is performed on the API compliance of the source code file.

[0095] Specifically, integrate a custom static analysis tool (or develop based on CLang's LibTooling). This tool loads the RT-Thread kernel header files, examines the generated driver code, and checks the following items: Check if the necessary header files such as rt_device.h and rtthread.h are correctly referenced.

[0096] Check if a structure instance conforming to standard interfaces such as struct rt_uart_ops has been correctly defined.

[0097] Does the driver registration function ultimately call the correct framework API (such as rt_hw_serial_register)?

[0098] Does the interrupt service routine contain the necessary rt_interrupt_enter / leave() calls?

[0099] In an optional implementation of this embodiment, the hardware dependencies and consistency between the source code file and the chip capability model of the target chip are checked.

[0100] Specifically, the generated C language source code file is compared with the data in the target chip's chip capability model. The comparison content is as follows: The base address of the register used in the generated code (such as (USART_TypeDef) Does 0x40004400 match the base_addr in the model?

[0101] Check if the interrupt service routine function name matches the vector symbol defined in the startup file.

[0102] Are the configured clock, pins, etc., within the range supported by the chip?

[0103] In one optional implementation of this embodiment, the code style and security rules of the source code file are checked.

[0104] Specifically, tools such as cppcheck and clang-format are used to ensure that the generated code conforms to the predefined code style (such as indentation and naming conventions) and to perform simple potential bug checks (such as null pointer dereferencing and array out-of-bounds risks).

[0105] It should be noted that source code files that fail will be returned to the system along with error reports, and the system will attempt to regenerate them or mark them as requiring manual intervention.

[0106] By employing the aforementioned technical solutions, the source code files generated by the large language model undergo multi-dimensional and automated verification and integration, significantly improving the quality, reliability, and usability of the generated code. Specifically, syntax and compilation checks ensure the fundamental correctness of the code, preventing compilation failures; static API compliance analysis guarantees correct interaction between the code and underlying interfaces, reducing runtime errors; hardware dependency and consistency checks ensure perfect matching between the code and the target chip hardware, avoiding functional anomalies caused by hardware incompatibility; and code style and security rule checks further enhance code readability and maintainability, effectively mitigating potential security risks. These measures work together to enable the source code files generated by the large language model to be directly assembled into high-quality, compilable, and deployable BSP project files, significantly reducing the workload of manual debugging and modification, and improving BSP development efficiency and code quality.

[0107] S106. Assemble the verified and integrated source code files into a BSP project file that can be directly compiled and used.

[0108] In one optional implementation of this embodiment, a complete BSP project directory is automatically generated based on the chip capability model of the target chip and the standard BSP directory template, Kconfig script template, SConscript build script template, etc. stored in the predefined BSP specification knowledge base, and then assembled and integrated in combination with the verified and integrated source code files.

[0109] Specifically, such as Figure 5 As shown, Figure 5 The flowchart illustrating the assembly of source code files into BSP project files according to Embodiment 1 of the present invention is shown, including the following steps: S501. Create a standardized BSP project directory that matches the target chip; In an optional implementation of this embodiment, the corresponding directory structure template is matched in the knowledge base based on the target chip's MCU_family (e.g., STM32), and then a template is created at the user-specified output location.<mcu_model> The BSP root directory is named -ai-generate (e.g., stm32f407-atk-explorer), and all subdirectories in the template are fully instantiated.

[0110] S502. Install and modify the startup file and link file in the chip capability model of the target chip; In an optional implementation of this embodiment, the startup assembly file (such as startup_stm32f407xx.s) is copied from the startup_file path of the chip capability model to the libraries / CMSIS / directory.

[0111] Specifically, based on the peripherals list in the "chip capability model," the interrupt vector table in the startup file is modified. The specific operation involves finding the position corresponding to `irq_number` in the vector table and ensuring it points to the interrupt service routine function name defined in the AI-generated driver file. For example, it ensures that the symbol `USART2_IRQHandler` correctly points to the address of the generated `USART2_IRQHandler` function in the vector table. If the original startup file contains a weak definition, the system will strengthen its pointing.

[0112] In an optional implementation of this embodiment, the linked file is copied and adapted.

[0113] Specifically, the base and size of flash and SRAM are read from the memory_map of the chip capability model, and these values ​​are used to replace the original definition of the MEMORY area in the linker file template (such as STM32F407VETx_FLASH.ld). Simultaneously, the allocation size or symbol definition of the heap and stack may be adjusted according to the memory management requirements of RT-Thread.

[0114] S503, Generate the board-level core configuration file for the target chip; In an optional implementation of this embodiment, a board-level core configuration file for the target chip is generated, including board.h and board.c files.

[0115] Specifically, regarding the board.h file, this is a collection of chip-specific macro definitions, dynamically generated by filling templates, and its content includes: Chip model definition: e.g., #define BSP_USING_STM32F407VGTx Key clock constant definitions extracted from the chip capability model clock_tree.

[0116] Peripheral bus base address reference declaration.

[0117] Based on the peripherals list, device usage macros are generated, such as #define BSP_USING_UART1 and #define BSP_USING_UART2, to provide configuration feedback to Kconfig.

[0118] Include the necessary original chip header files, such as #include "stm32f4xx.h".

[0119] More specifically, the board.c file contains board-level initialization functions, which sequentially call the rt_hw_board_init() function to populate the framework. The specific content includes: HAL_Init().

[0120] SystemClock_Config(): Its function body is generated by the system based on the clock_tree information in the chip capability model, by calling the clock configuration function template of the corresponding chip series in the knowledge base.

[0121] Peripheral pin initialization code: Analyze the original SDK sample project or MX configuration file (if it exists) to generate code snippets for initializing GPIOs used for USART, SPI, etc.

[0122] The driver initialization function calls for each peripheral device, such as rt_hw_usart_init().

[0123] S504. Integrate the source code files to generate a configuration file for building the BSP project file; In an optional implementation of this embodiment, the source code file (drv_xxx.c) that has been automatically verified and integrated is placed in the drivers / directory, and the following build configuration file is generated: Generate drivers / Kconfig: Traverse the driver files in the drivers / directory and automatically add the corresponding configuration menu item to drivers / Kconfig for each peripheral instance; Generate drivers / SConscript: Based on the driver file and Kconfig configuration, generate the build script to ensure that drv_usart.c is correctly included in the compilation when the user selects BSP_USING_UART1 through menuconfig.

[0124] Generate top-level Kconfig and SConscript: Call the top-level template in the knowledge base to generate the project entry file.

[0125] S505: Build an IDE project template, fill in the BSP information of the target chip, and generate a BSP project metadata file.

[0126] In one optional implementation of this embodiment, a README.md file is created, which automatically fills in the generated BSP name, chip model, list of supported peripherals, and a brief user manual. Based on the IDE project template in the knowledge base (optional, such as template.uvprojx for Keil MDK or template.ewp for IAR), the placeholders in the template are replaced with the specific information of the current BSP (chip model, macro definition, file path), generating a project file that can be directly opened with the corresponding IDE.

[0127] The above technical solution systematically assembles the verified and integrated source code into a BSP project file that can be directly compiled and used, solving the pain points of traditional BSP development, such as time-consuming, error-prone, and difficult-to-standardize manual configuration of project files. By creating a standardized directory, automatically configuring startup and linker files, generating board-level core configurations, integrating source code and generating build configuration files, and building IDE project templates, this solution achieves a seamless conversion from source code to a deployable BSP project. This not only greatly improves the efficiency and accuracy of BSP project generation and reduces the workload of developers, but also ensures the consistency and maintainability of BSP projects across different chips, enabling the generated BSP to be directly compiled, debugged, and deployed in mainstream development environments, thereby accelerating the product development cycle.

[0128] In summary, Embodiment 1 of this invention provides a BSP code generation method based on a large language model. This method achieves fully automated generation of BSP code from chip SDK through a large language model, significantly reducing the manual development cycle from days or weeks to minutes, greatly improving development efficiency. The generated code strictly adheres to the driver framework specifications, exhibiting a unified style, high reliability, and strong consistency, effectively solving the problem of inconsistent quality in manual development. Simultaneously, it lowers the threshold for embedded operating system porting, allowing developers to complete adaptation without needing expertise in the underlying details of the target chip's real-time operating system. It is compatible with heterogeneous SDKs from multiple vendors, possesses strong generalization capabilities, and ensures direct compilation and execution of the code through multi-level automated verification. The final output is a complete and usable BSP project, enabling rapid support for new chip adaptation and operating system ecosystem expansion.

[0129] Example 2 Embodiment 2 of the present invention provides a BSP code generation system based on a large language model. The BSP code generation system based on a large language model is used to implement the BSP code generation method based on a large language model described in Embodiment 1. The system includes a chip capability model construction module, a transformation descriptor construction module, a code large language model construction module, a source code file generation module, a verification and integration module, and a project file assembly module.

[0130] In one optional implementation of this embodiment, such as Figure 6 As shown, Figure 6 The following diagram illustrates the architecture of a BSP code generation system based on a large language model driven by the present invention, comprising the following modules: Chip capability model construction module 10, which is used to parse and extract features from the original SDK of the target chip to construct the chip capability model of the target chip; In an optional implementation of this embodiment, the step of parsing and extracting features from the original SDK of the target chip to construct the chip capability model of the target chip includes: Preprocess the original SDK of the target chip; Based on the built-in SDK structure knowledge base, the structural paradigm of the original SDK of the target chip is identified, and the key files of the original SDK of the target chip are obtained. Semantic analysis and information extraction are performed on the key files of the original SDK of the target chip to obtain the chip capability information of the target chip; A blank data model object is created, and the chip capability information of the target chip is filled into the nodes of the blank data model object to generate the chip capability model of the target chip.

[0131] In an optional implementation of this embodiment, when the structural paradigm of the original SDK of the target chip cannot be identified, manual configuration is performed, and the SDK structure knowledge base is updated based on the manual configuration result.

[0132] In an optional implementation of this embodiment, the step of performing semantic analysis and information extraction on the key files of the target chip's original SDK to obtain the chip capability information of the target chip includes: Regular expressions and a lightweight parser are used to parse the feature header files of the target chip; Static code analysis is used to parse the peripheral driver library files of the target chip. Parse the target chip's startup file and linker file.

[0133] The transformation descriptor construction module 20 is used to construct transformation descriptors based on the chip capability model of the target chip and a predefined BSP specification knowledge base; In an optional implementation of this embodiment, the construction of the transformation descriptor based on the chip capability model of the target chip and the predefined BSP specification knowledge base includes: Determine the driver conversion task, extract the peripheral driver to be converted from the chip capability model of the target chip, and anchor the core elements of the peripheral driver to be converted. Extract the key functions and data structures of the peripheral driver to be converted; Query the predefined BSP specification knowledge base and match the driver framework standard corresponding to the peripheral driver to be converted; The data obtained above are combined to form a transformation descriptor consisting of multi-paragraph structured text.

[0134] The code-large language model construction module 30 is used to construct the code-large language model and fine-tune the code-large language model. In an optional implementation of this embodiment, the step of constructing a large code language model and fine-tuning the large code language model includes: Select the code-major language model that matches the BSP code; Collect a large amount of "transformation descriptor-target-driven code" pairing data and form training pairs; Based on the training pairs, the selected code-large language model is trained using a supervised fine-tuning method; The code generated by the trained code-large language model is aligned with the generation preferences of the trained code-large language model using a reinforcement learning method based on human feedback.

[0135] Source code file generation module 40 is used to input the transformation descriptor into the fine-tuned code language model to generate source code files. In an optional implementation of this embodiment, the step of inputting the transformation descriptor into the fine-tuned code-large language model to generate source code files includes: The transformation descriptor is input into the fine-tuned code language model, and a complete C language source code file is generated autoregressively, conditioned on the structured description of the chip capability model of the target chip.

[0136] Verification and integration module 50, which is used to automatically verify and integrate the source code file; In an optional implementation of this embodiment, the automated verification and integration of the source code file includes: Perform syntax and compilation checks on the source code file; Static analysis was performed on the API compliance of the source code files. The hardware dependencies and consistency between the source code file and the chip capability model of the target chip are checked. The code style and security rules of the source code files are checked.

[0137] The project file assembly module 60 is used to assemble the verified and integrated source code files into BSP project files that can be directly compiled and used.

[0138] In an optional implementation of this embodiment, assembling the verified integrated source code files into a BSP project file that can be directly compiled and used includes: Create a standardized BSP project catalog that matches the target chip; Install and modify the startup file and linker file in the chip capability model of the target chip; Generate the board-level core configuration file for the target chip; Integrate the source code files to generate a configuration file for building the BSP project file; Build an IDE project template, fill in the BSP information of the target chip, and generate a BSP project metadata file.

[0139] In summary, Embodiment 2 of this invention provides a BSP code generation system based on a large language model, used to implement the BSP code generation method based on a large language model described in Embodiment 1. It achieves fully automated generation of BSP code from chip SDK through a large language model, significantly shortening the manual development cycle from days or weeks to minutes, greatly improving development efficiency. The generated code strictly adheres to the driver framework specifications, exhibiting a unified style, high reliability, and strong consistency, effectively solving the problem of inconsistent quality in manual development. Simultaneously, it lowers the threshold for embedded operating system porting, allowing developers to complete adaptation without needing expertise in the underlying details of the target chip's real-time operating system. It is compatible with heterogeneous SDKs from multiple vendors, has strong generalization capabilities, and ensures direct compilation and execution of the code through multi-level automated verification, ultimately outputting a complete and usable BSP project, enabling rapid support for new chip adaptation and operating system ecosystem expansion.

[0140] The foregoing has provided a detailed description of the BSP code generation method and system based on a large language model driven by the present invention. Those skilled in the art will understand that all or part of the steps in the various methods of the above embodiments can be implemented by a program instructing related hardware. The program can be stored in a computer-readable storage medium, which may include: read-only memory (ROM), random access memory (RAM), disk or optical disk, etc.

[0141] Furthermore, the embodiments of the present invention have been described in detail above. Specific examples have been used to illustrate the principles and implementation methods of the present invention. The description of the above embodiments is only for the purpose of helping to understand the method and core ideas of the present invention. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of the present invention. Therefore, the content of this specification should not be construed as a limitation of the present invention.

Claims

1. A BSP code generation method based on a large language model, characterized in that, The method includes: The original SDK of the target chip is parsed and its features are extracted to construct a chip capability model of the target chip; A transformation descriptor is constructed based on the chip capability model of the target chip and a predefined BSP specification knowledge base; Construct a large code language model and fine-tune it. The transformation descriptor is input into the fine-tuned code language model to generate source code files; Automated verification and integration of the source code files; The verified and integrated source code files are assembled into a BSP project file that can be directly compiled and used.

2. The BSP code generation method based on a large language model as described in claim 1, characterized in that, The process of parsing and extracting features from the original SDK of the target chip to construct a chip capability model includes: Preprocess the original SDK of the target chip; Based on the built-in SDK structure knowledge base, the structural paradigm of the original SDK of the target chip is identified, and the key files of the original SDK of the target chip are obtained. Semantic analysis and information extraction are performed on the key files of the original SDK of the target chip to obtain the chip capability information of the target chip; A blank data model object is created, and the chip capability information of the target chip is filled into the nodes of the blank data model object to generate the chip capability model of the target chip.

3. The BSP code generation method based on a large language model as described in claim 2, characterized in that, When the original SDK structure paradigm of the target chip cannot be identified, manual configuration is performed, and the SDK structure knowledge base is updated based on the manual configuration results.

4. The BSP code generation method based on a large language model as described in claim 2, characterized in that, The step of performing semantic analysis and information extraction on key files of the original SDK of the target chip to obtain chip capability information includes: Regular expressions and a lightweight parser are used to parse the feature header files of the target chip; Static code analysis is used to parse the peripheral driver library files of the target chip. Parse the target chip's startup file and linker file.

5. The BSP code generation method based on a large language model as described in claim 1, characterized in that, The construction of the transformation descriptor based on the chip capability model of the target chip and the predefined BSP specification knowledge base includes: Determine the driver conversion task, extract the peripheral driver to be converted from the chip capability model of the target chip, and anchor the core elements of the peripheral driver to be converted. Extract the key functions and data structures of the peripheral driver to be converted; Query the predefined BSP specification knowledge base and match the driver framework standard corresponding to the peripheral driver to be converted; The data obtained above are combined to form a transformation descriptor consisting of multi-paragraph structured text.

6. The BSP code generation method based on a large language model as described in claim 1, characterized in that, The construction of the large code language model and the fine-tuning of the large code language model include: Select the code-major language model that matches the BSP code; Collect a large amount of "transformation descriptor-target-driven code" pairing data and form training pairs; Based on the training pairs, the selected code-large language model is trained using a supervised fine-tuning method; The code generated by the trained code-large language model is aligned with the generation preferences of the trained code-large language model using a reinforcement learning method based on human feedback.

7. The BSP code generation method based on a large language model as described in claim 1, characterized in that, The step of inputting the transformed descriptor into the fine-tuned code language model to generate source code files includes: The transformation descriptor is input into the fine-tuned code language model, and a complete C language source code file is generated autoregressively, conditioned on the structured description of the chip capability model of the target chip.

8. The BSP code generation method based on a large language model as described in claim 1, characterized in that, The automated verification and integration of the source code file includes: Perform syntax and compilation checks on the source code file; Static analysis was performed on the API compliance of the source code files. The hardware dependencies and consistency between the source code file and the chip capability model of the target chip are checked. The code style and security rules of the source code files are checked.

9. The BSP code generation method based on a large language model as described in claim 1, characterized in that, The process of assembling the verified and integrated source code files into a BSP project file that can be directly compiled and used includes: Create a standardized BSP project catalog that matches the target chip; Install and modify the startup file and linker file in the chip capability model of the target chip; Generate the board-level core configuration file for the target chip; Integrate the source code files to generate a configuration file for building the BSP project file; Build an IDE project template, fill in the BSP information of the target chip, and generate a BSP project metadata file.

10. A BSP code generation system driven by a large language model, characterized in that, The BSP code generation system based on a large language model is used to implement the BSP code generation method based on a large language model as described in any one of claims 1-9, and the system includes: A chip capability model building module is used to parse and extract features from the original SDK of the target chip to build a chip capability model of the target chip. A transformation descriptor construction module is used to construct transformation descriptors based on the chip capability model of the target chip and a predefined BSP specification knowledge base; A code-large language model construction module is used to construct a code-large language model and fine-tune the code-large language model. A source code file generation module is used to input the transformation descriptor into the fine-tuned code language model to generate source code files. A verification and integration module, which is used to automatically verify and integrate the source code file; The project file assembly module is used to assemble the verified and integrated source code files into BSP project files that can be directly compiled and used.

Images