Method and device for generating executable file

Abstract

The invention discloses a method and a device for generating an executable file. The method comprises the steps of obtaining a visual model corresponding to a to-be-executed algorithm, wherein the to-be-executed algorithm is an algorithm to be executed by a digital signal processor in an embedded system; converting the visual model into a program code through a code generator in the simulation tool to obtain a target program code; a code debugging project is created through a code debugging component and the target program code, the code debugging component is a component in a code debugging tool, and the code debugging tool is used for providing a development environment for system development of the digital signal processor; and compiling the code debugging project to generate an executable file which can be executed by the digital signal processor. According to the scheme provided by the embodiment of the invention, the development difficulty of the embedded system can be reduced, and the development efficiency of the embedded system is improved.

Description

Technical Field

[0001] This application belongs to the field of embedded development technology, and in particular relates to a method and apparatus for generating executable files. Background Technology

[0002] DSP (Digital Signal Processor) has efficient digital signal processing capabilities, a dedicated instruction set and hardware accelerator, and high-precision computing and control capabilities. It is commonly used in embedded systems.

[0003] In the development of embedded systems, DSP development projects are typically created using a DSP development environment to complete operations such as hardware configuration, source code addition, compilation, and deployment. This approach relies on a dedicated DSP development environment, resulting in a lengthy development process, complex user interfaces, increased complexity, and reduced efficiency in embedded system development. Summary of the Invention

[0004] This application provides a method and apparatus for generating executable files, which can reduce the development difficulty of embedded systems and improve the development efficiency of embedded systems.

[0005] In a first aspect, embodiments of this application provide a method for generating an executable file. The method includes: obtaining a visual model corresponding to an algorithm to be executed, wherein the algorithm to be executed is an algorithm to be executed by a digital signal processor in an embedded system; converting the visual model into program code using a code generator in a simulation tool to obtain target program code; creating a code debugging project using a code debugging component and the target program code, wherein the code debugging component is a component in a code debugging tool, and the code debugging tool is used to provide a development environment for the system development of a digital signal processor; and compiling the code debugging project to generate an executable file that can be executed by the digital signal processor.

[0006] Secondly, embodiments of this application provide an executable file generation apparatus, comprising: a model acquisition module for acquiring a visual model corresponding to an algorithm to be executed, wherein the algorithm to be executed is an algorithm to be executed by a digital signal processor in an embedded system; a code generation module for converting the visual model into program code through a code generator in a simulation tool to obtain target program code; a project creation module for creating a code debugging project through a code debugging component and the target program code, wherein the code debugging component is a component in a code debugging tool, and the code debugging tool is used to provide a development environment for the system development of a digital signal processor; and a file generation module for compiling the code debugging project to generate an executable file that can be executed by the digital signal processor.

[0007] Thirdly, embodiments of this application provide an electronic device, which includes: a processor and a memory storing computer program instructions; the processor executes the computer program instructions to implement the executable file generation method as described in the first aspect.

[0008] Fourthly, embodiments of this application provide a computer-readable storage medium storing computer program instructions, which, when executed by a processor, implement the executable file generation method described in the first aspect.

[0009] Fifthly, embodiments of this application provide a computer program product in which instructions, when executed by a processor of an electronic device, cause the electronic device to perform the executable file generation method described in the first aspect.

[0010] As described above, in this embodiment, the visual model is converted into program code using a code generator, eliminating the need for designers to program, thus reducing the professional requirements for designers and lowering the development difficulty and complexity of embedded systems. Furthermore, in this embodiment, the creation and compilation of the code debugging project are achieved by calling the code debugging component within the code debugging tool, rather than by calling the code debugging tool itself. This means that during the development and design of the embedded system, it is unnecessary to start the development environment corresponding to the digital signal processor, achieving decoupling between the development and design of the embedded system and the development environment of the digital signal processor. This lowers the barrier to entry for designers, thereby reducing the development difficulty of embedded systems and improving their development efficiency.

[0011] Therefore, it can be seen that the solution provided in the embodiments of this application can reduce the development difficulty of embedded systems and improve the development efficiency of embedded systems. Attached Figure Description

[0012] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments of this application will be briefly introduced below. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0013] Figure 1 This is a flowchart illustrating a method for generating an executable file according to an embodiment of this application; Figure 2 This is a schematic diagram of a hardware driver interface template provided in one embodiment of this application; Figure 3 This is a schematic diagram of an embedded system development provided in one embodiment of this application; Figure 4 This is a schematic diagram of the structure of an executable file generation apparatus provided in another embodiment of this application; Figure 5 This is a schematic diagram of the structure of an electronic device provided in another embodiment of this application. Detailed Implementation

[0014] The features and exemplary embodiments of various aspects of this application will be described in detail below. To make the objectives, technical solutions, and advantages of this application clearer, the application will be further described in detail below with reference to the accompanying drawings and specific embodiments. It should be understood that the specific embodiments described herein are only intended to explain this application and not to limit it. For those skilled in the art, this application can be implemented without some of these specific details. The following description of the embodiments is merely to provide a better understanding of this application by illustrating examples.

[0015] It should be noted that, in this document, relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising..." does not exclude the presence of additional identical elements in the process, method, article, or apparatus that includes said element.

[0016] To facilitate understanding, before explaining the solution provided in this application, the background of the solution provided in this application will be explained first.

[0017] DSP, or Digital Signal Processor, is similar to microcontrollers and ARM (Advanced RISC Machines, RISC microprocessors). It internally includes an instruction set and an ALU (Arithmetic and Logic Unit), and is commonly used in various embedded control systems. It features efficient digital signal processing capabilities, a dedicated instruction set and hardware accelerators, and high-precision computation and control capabilities.

[0018] In related technologies, when designing and developing embedded systems, the embedded algorithm needs to be written as embedded C code. Then, a DSP development project is created using a DSP development environment (e.g., CCS5.5). After completing hardware configuration, adding source code, compiling, and deployment, the design and development of the embedded system can be realized.

[0019] However, writing embedded algorithms into embedded C code requires designers to have ample experience in embedded C coding, resulting in a high learning curve for designers without prior embedded development experience. Furthermore, many control system designers typically use Simulink modeling to complete system design; there is a significant difference between visual model system design and abstract embedded C code system design, necessitating a large number of embedded software engineers to develop the embedded C code.

[0020] In addition, DSPs have a dedicated development environment, CCS (Code Composer Studio), which is used for creating development projects, configuring hardware, compiling projects, and deploying executable files. However, the CCS development process is lengthy and the user interface is complex, requiring considerable learning to become familiar with and use it.

[0021] Therefore, it is evident that developing embedded systems requires designers to have considerable experience, resulting in a relatively high technical threshold. Furthermore, the coupling between DSP and CCS increases the difficulty and reduces the efficiency of embedded system development.

[0022] To lower the technical barrier for designers to understand the underlying hardware information of a platform, this application provides a method and apparatus for generating executable files. In this application, a Model-Based Design (MBD) approach is employed. A code generation toolchain from a simulation tool (e.g., MATLAB) is invoked to link hardware configuration files and interface programs from the corresponding visual model of the algorithm (e.g., a Simulink model), generating embedded C code. The DSP's development environment (CCS) is decoupled, directly completing the creation and compilation of the CCS project. Finally, an executable file is generated and directly deployed to the DSP board to realize the development of an embedded system. The solution provided in this application offers a low-learning-cost, low-development-environment-dependency embedded system design tool for DSP-based embedded systems, improving the development efficiency of embedded systems.

[0023] The method for generating executable files provided in the embodiments of this application will be described first. The development tools for the embedded system (e.g., a computer) can serve as the execution subject of the method provided in the embodiments of this application.

[0024] In some embodiments, Figure 1 A flowchart illustrating a method for generating an executable file according to an embodiment of this application is shown. Figure 1 As shown, the method includes the following steps S101 to S104: Step S101: Obtain the visualization model corresponding to the algorithm to be executed.

[0025] In step S101, the algorithm to be executed is the algorithm that the digital signal processor (DSP) in the embedded system is to execute. When the embedded system is running, the DSP in the embedded system is to execute the algorithm. For example, in the scenario where the embedded system is applied to a vehicle, the DSP can execute relevant algorithms to process the signals detected by the radar.

[0026] In step S101, the visualization model can be a model generated by the visualization simulation tool Simulink. Simulink is a visualization simulation tool in MATLAB that provides a graphical editor, a customizable module library, and a solver to achieve the modeling and simulation of dynamic systems, thereby enabling multi-domain simulation and model-based design. Using the Simulink simulation tool, designers build a visualization model based on the relevant logic of the algorithm. For example, for an algorithm for preprocessing radar signals, designers only need to connect the signal synchronization module, background noise filtering module, automatic gain control module, pulse compression module, Fourier transform module, and data verification module sequentially according to the signal preprocessing flow to obtain the visualization model corresponding to the signal preprocessing. By inputting the radar signal into this visualization model, the preprocessing of the radar signal can be achieved.

[0027] In one example, MATLAB is deployed in the development tool. In scenarios where an executable file needs to be generated, the development tool can respond to the designer's file generation command by retrieving a visualization model of the algorithm required to generate the executable file from its local storage. This visualization model can be stored in the development tool's local storage. Upon receiving the file generation command, the development tool determines the model identifier of the required visualization model from the command and then reads the visualization model corresponding to the model identifier from the storage unit.

[0028] Step S102: The visual model is converted into program code using the code generator in the simulation tool to obtain the target program code.

[0029] In step S102, the simulation tool is a tool capable of code programming, such as MATLAB. MATLAB includes a built-in code generator RTW (Real-Time Workshop) toolchain, which can directly convert Simulink models into real-time executable C code. Therefore, the code generator can automatically convert the visual model into program code, eliminating the need for designers to manually program, reducing the difficulty and complexity of program code development, lowering the barrier to entry for designers, and improving the development efficiency of embedded systems.

[0030] Step S103: Create a code debugging project using the code debugging component and the target program code.

[0031] In step S103, the code debugging component is a component of the code debugging tool, which can be used to create and compile the code debugging project. The code debugging tool is used to provide a development environment for the system development of digital signal processors. In this embodiment, the digital signal processor is a DSP, and the code debugging tool is a DSP-specific development environment tool, CCS.

[0032] It should be noted that, in the embodiments of this application, the designer can configure the installation path of the code debugging tool CCS environment in the development tool, so that the development tool can directly call the code debugging component, i.e. the CCS component, according to the installation path, without having to start the CCS development environment, thereby decoupling the DSP-based embedded system development from the CCS development environment and reducing the complexity of embedded system development.

[0033] In addition, in step S103, to generate an executable file that the DSP can execute, the target program code generated in step S102 needs to be debugged. Therefore, a code debugging project needs to be created. In this embodiment, the development tool creates a project file by calling the CCS component, and then adds the target program code to the project file to obtain the code debugging project.

[0034] Step S104: Compile the code debugging project to generate an executable file that the digital signal processor can execute.

[0035] In step S104, the development tool is equipped with a compiler and a linker. The development tool compiles the code debugging project through the compiler and linker to generate an executable file that the DSP can execute. The executable file is then downloaded to the DSP, which can then execute the algorithm to be executed in step S101. In this way, the designer can debug the embedded system based on the input and output signals of each component or unit in the embedded system.

[0036] Based on the scheme defined in steps S101 to S104 above, it can be seen that in this embodiment, the visual model is converted into program code by a code generator, eliminating the need for designers to program, thus reducing the professional requirements for designers and lowering the development difficulty and complexity of embedded systems. Furthermore, in this embodiment, the creation and compilation of the code debugging project are achieved by calling the code debugging component in the code debugging tool, rather than calling the code debugging tool itself. That is, during the development and design of the embedded system, it is not necessary to start the development environment corresponding to the digital signal processor, achieving decoupling between the development and design of the embedded system and the development environment of the digital signal processor. This lowers the barrier to entry for designers, thereby reducing the development difficulty of embedded systems and improving their development efficiency.

[0037] Therefore, it can be seen that the solution provided in the embodiments of this application can reduce the development difficulty of embedded systems and improve the development efficiency of embedded systems.

[0038] The implementation process of the method provided in the embodiments of this application is described below.

[0039] After obtaining the visual model corresponding to the algorithm to be executed, the development tool automatically converts the visual model into program code through the code generator, thereby reducing the usage threshold for designers and improving the development efficiency of embedded systems.

[0040] In some embodiments, the development tool obtains the driver interface information corresponding to the digital signal processor, then compiles the visualization model using a code generator to generate a model compilation file; next, it converts the model compilation file into model code using a code generation template, and generates target program code based on the model code and the driver interface information.

[0041] In the above embodiments, the driver interface information corresponding to the DSP includes at least one interface function. The interface function is used to configure the corresponding interface. For example, the LibBlockOutputSignal() function is used to configure the output port, while functions such as AD_Trigger() and AD_Read() are used to configure the port of the digital-to-analog converter trigger and the data reading port according to the board hardware of the embedded system.

[0042] It should be noted that during the hardware board development phase of an embedded system, manufacturers typically provide the peripheral hardware interface functions used on the embedded system's hardware board. Based on these functions, they develop hardware driver interface templates that allow the generated embedded C code to directly call the peripheral hardware on the embedded system's hardware board. These hardware driver interface templates usually have the suffix ".tlc," for example... Figure 2A schematic diagram of a hardware driver interface template is shown, wherein the aforementioned hardware driver interface template contains driver interface information.

[0043] In the above embodiments, the model compilation file includes at least the model information of the visualization model and the model compilation information. The model information may include, but is not limited to, the name of the visualization model, its functional description, and the generation time of the visualization model. The model compilation information may include, but is not limited to, the version number of the visualization model, the configuration parameter set, and the input and output parameters.

[0044] Furthermore, in the above embodiments, the code generation template includes the code format of the code executed by the digital signal processor. That is, the development tool can convert the model compilation file into model code that conforms to the code format requirements.

[0045] In one example, the development tool calls the RTW toolchain (i.e., the code generator) to link the hardware driver interface template, thereby obtaining the driver interface information corresponding to the DSP. Then, the development tool compiles the visualization model by calling the RTW toolchain, generating embedded C code for the hardware board of the embedded system. In addition to hardware interface functions, the generated embedded C code also includes main functions and algorithm functions. Code generation templates with the .tlc suffix are developed for the main functions and algorithm functions respectively to control the format of the main functions and algorithm functions and increase the readability of the generated code.

[0046] After generating the model code, the development tool also generates the target program code based on the model code and driver interface information. Specifically, the development tool determines the hardware interface functions of the digital signal processor (DSP) from the driver interface information based on the hardware configuration information corresponding to the DSP; then, it performs code integration processing on the program code corresponding to the hardware interface functions and the model code to obtain the target program code.

[0047] In the above embodiments, the DSP's hardware configuration information refers to the configuration information of the embedded system's hardware board that the development tools can recognize. This may include, but is not limited to, information about the JTAG (Joint Test Action Group) connection to the emulator and device information of peripheral devices connected to the embedded system's hardware board. The DSP's hardware configuration information is typically stored in a hardware configuration file, which is usually a file with the .ccxml extension.

[0048] It should be noted that, in the embodiments of this application, by generating the hardware configuration information corresponding to the hardware board of the embedded system, and then developing the driver interface information for the hardware board, designers can develop DSP-based embedded systems under the same hardware configuration without repeatedly configuring the hardware configuration in the CCS project, as long as the JTAG connection between the emulator and the DSP chip is not changed. The configuration can be generated once and used permanently, and the correct interaction between the DSP and the hardware devices on the hardware board of the embedded system can be guaranteed.

[0049] As an example, the development tool compiles the visualization model into an RTW file (i.e., a model compilation file) using the RTW toolchain. This file is an intermediate product of code generation, recording all information about the visualization model, including creation and compilation information, name and version number, configuration parameter set, inputs and outputs, and parameters. A code generation template is then used to generate a model code file based on the RTW file, consisting of .h and .c files. Finally, a custom integration template is used to integrate the model code with the DSP's basic code (i.e., the program code corresponding to the hardware interface functions), resulting in the target program code.

[0050] It should be noted that the above-mentioned custom integration template includes the hardware interface template and the target of the main function.

[0051] Furthermore, it should be noted that by determining the hardware interface functions through the hardware configuration information corresponding to the DSP, and then integrating the program code of the hardware interface functions with the model code, the target program code is automatically generated, improving code generation efficiency and thus improving the development efficiency of embedded systems.

[0052] Furthermore, after generating the target program code, the development tool creates a code debugging project using the code debugging component and the target program code.

[0053] In some embodiments, the development tool first obtains the simulation configuration information corresponding to the simulation tool and the hardware configuration information corresponding to the digital signal processor. Then, it creates a project file based on the simulation configuration information. Next, it adds the target program code and hardware configuration information to the project file to obtain the code debugging project.

[0054] It should be noted that, in the above embodiments, the hardware configuration information includes at least the emulator information (e.g., test clock, test mode) and the board information of the board on which the digital signal processor is located (e.g., hardware layout on the board, port connection status of the DSP, etc.). The emulator is used to link the terminal device and the digital signal processor, and the terminal device can be a peripheral device connected to the embedded system.

[0055] Furthermore, in the above embodiments, the simulation configuration information is related to the configuration of the simulation tool, such as the configuration information of the project path (e.g., source code directory, data directory, etc.), file classification rules (e.g., managing functions and scripts in separate directories), and version control integration (e.g., Git repository configuration, etc.).

[0056] In one example, the designer configures the installation path of the CCS development environment in the development tools. This installation path allows the CCS components to be called without needing to start the CCS development environment. Then, the CCS components are called to create project files such as .pjt, .cproject, and .project according to the MATLAB configuration information (i.e., simulation configuration information), ensuring that subsequent files (i.e., target program code, hardware configuration information, etc.) can be included in the project files. Next, the generated .c embedded code, .h header files, and .asm assembly language source files are added to the project files. The .asm assembly language source files are generated during the embedded system development process, specifically for developing DSP memory and addresses. Next, the corresponding DSP library files and static library files are added to the project files. For example, for a C6713 DSP chip, the rts6700.lib library file and .a static library files can be added to the project files. Finally, the linker command file (.cmd) and the hardware configuration file (.ccxml) are added to the project files, completing the creation of the CCS project and obtaining the code debugging project.

[0057] By calling the CCS component to automatically create code debugging projects, the technical threshold for designers is lowered, the efficiency of code debugging project creation is improved, and a foundation is laid for improving the development efficiency of embedded systems.

[0058] Furthermore, after creating the code debugging project, the development tools compile the code debugging project to generate an executable file that the DSP can execute.

[0059] In some embodiments, the development tool first obtains the compilation file corresponding to the code debugging project, and then compiles the code debugging project using the compilation file to obtain an executable file.

[0060] In the above embodiments, the compilation file includes at least the compilation parameters required during the compilation of the code debugging project. In the embodiments of this application, the compilation file can be a makefile generated by a compilation template. The compilation template is an optimized code template generated by MATLAB. By using the code format in the compilation template to compile the code debugging project, an executable file that can be directly applied in the DSP can be obtained.

[0061] It should be noted that the Makefile is used to store the parameters and options for the compiler and linker, and also to store the relationships between all source files. When the compiler compiles, it directly calls the Makefile to link the hardware configuration file (mainly containing chip information and JTAG information) with the embedded C code, thus enabling the compilation of the code debugging project and generating an executable file with the .out extension.

[0062] As can be seen from the above executable file generation process, in this embodiment of the application, the CCS component is used to realize the creation of project files and the compilation of code debugging projects. It can be fully decoupled from the CCS development environment, and the entire process can be completed in the development tool without starting the CCS development environment, thereby reducing the development difficulty of embedded systems and improving the development efficiency of embedded systems.

[0063] Furthermore, after generating the executable file, it needs to be downloaded to the digital signal processor (DSP).

[0064] In some embodiments, after compiling the code debugging project to generate an executable file that the digital signal processor can execute, the development tool executes the executable file by calling a program loading script. Specifically, the development tool calls the program loading script corresponding to the code debugging component, downloads the code burning program to the digital signal processor through the simulator, and then controls the digital signal processor to run the code burning program, read and run the executable file, and obtain the code execution result.

[0065] It should be noted that the code programming program is typically downloaded to the DSP using the Load Programmable program within the CCS development environment. The DSP can then run the program to read the executable file. This method requires starting the CCS development environment, increasing the complexity of embedded system development.

[0066] The program loading script can be the Loadti script within the CCS development environment. By calling this script, the code for programming can be downloaded to the DSP, allowing the DSP to read and run the executable file. This process decouples embedded system development from the CCS development environment by calling the Loadti script instead of activating the CCS development environment. Program deployment via JTAG can be completed without starting the CCS development environment, and the executable file obtained after compiling the CCS project is downloaded to the DSP via JTAG for normal operation.

[0067] In some embodiments, after compiling the code debugging project to generate an executable file that the digital signal processor can execute, the development tool can also convert the executable file into a binary file; then, the binary file is burned into the memory (e.g., onboard Flash) of the digital signal processor; the digital signal processor is controlled to restore the binary file into an executable file and run the executable file to obtain the code execution result, so that the development tool can adjust the embedded system according to the code execution result to improve the system performance of the embedded system.

[0068] It's important to note that for executable file programming, the executable file (.out) is typically converted into a binary file (.bin) for the DSP's Flash memory. Then, with the terminal connected to the DSP via JTAG, the CCS development environment's debug function is used to run the programming program, read the binary file, and write it to the DSP's Flash memory. The DSP then permanently stores the binary file in its onboard Flash, enabling it to automatically run the program upon power-up. This method not only requires starting the CCS development environment but is also complex and demands a deep understanding of the DSP development process from the designer, increasing the difficulty of embedded system development. Furthermore, the programming program for the binary file differs for different DSP chip models. For example, programming the TMS320C6713B DSP chip requires a proprietary program, making executable file programming inflexible.

[0069] To address the aforementioned issues, in this embodiment of the application, the development tool can employ either of the following two burning methods to burn binary files: The first method involves using a simulator to write the binary file into the DSP's Flash memory. Specifically, after compiling the code debugging project to generate an executable file that the digital signal processor can execute, the development tool converts the executable file into a binary file, and then uses a simulator to write the binary file into the Flash memory of the board where the digital signal processor is located.

[0070] It should be noted that with the method of directly downloading the executable file to the DSP, the development tool needs to re-download the executable file to the DSP after a DSP failure or power outage and restart. To reduce the number of times the executable file needs to be downloaded and improve the development efficiency of the embedded system, in this embodiment, the binary file is burned into the DSP's Flash memory. Therefore, after a DSP failure or power outage and restart, the DSP can directly read the binary file from the Flash memory and convert it, thus eliminating the need for repeated downloads and improving the development efficiency of the embedded system.

[0071] The second method involves writing binary files via serial communication. Specifically, after compiling the code debugging project to generate an executable file that the digital signal processor can execute, the development tool converts the executable file into a binary file and writes the binary file into the memory of the board containing the digital signal processor via serial communication.

[0072] It should be noted that the method of downloading the code to the DSP and running it via the Loadti script, and reading the executable file, still requires a JTAG connection between the development tool and the DSP. In the second method, binary file writing is achieved through serial communication, eliminating the need for a JTAG connection to the DSP. This enables online upgrades, simplifies embedded system development, and improves its efficiency.

[0073] In some embodiments, Figure 3 This diagram illustrates the principle of embedded system development, based on Figure 3 As can be seen, embedded system development mainly includes the following steps S301 to S308: In step S301, the development tool first reads the visualization model and then reads the DSP's hardware driver interface template and hardware configuration file through the driver interface. Step S302: The development tool compiles the visualization model using the rtwbuild component in the RTW toolchain to generate an RTW file; Step S303: Convert the RTW file into model code using the code generation template, and then generate embedded C code using the driver interface information and the model code; Step S304: Create a code debugging project, i.e., a CCS project, using the CCS component and embedded C code; Step S305: The compiler compiles the CCS project according to the makefile generated by the compilation template, and generates an executable file with the .out extension. Step S306: Convert the .out executable file into a .bin binary file using a binary conversion tool; Step S307: Download the code burning program to the DSP using the simulator; In step S308, the DSP runs a code programming program to read the .bin binary file and writes the read file data into the DSP's Flash memory.

[0074] As described in steps S301 to S308 above, by calling the MATLAB toolchain to link the hardware configuration file and hardware driver interface template, embedded C code is generated. Then, the CCS component is called to create a CCS project. Finally, the CCS component is called to perform the compilation, linking, and deployment operations of the project. This method realizes the direct generation of embedded C code that can be used in embedded systems from a visual model and one-click deployment to the DSP of the embedded system. This solution can reduce the complexity of embedded system design and development, making simple graphical modeling (i.e., Simulink modeling) the last step in the design, while other work can be completed with one click using this invention.

[0075] This concludes the introduction of the methods provided in the embodiments of this application.

[0076] As can be seen from the above, the solution provided in this application frees designers from the tedious low-level information such as DSP hardware configuration and hardware interface drivers. Without a thorough understanding of the hardware, designers can generate embedded C code from a visual model and then generate a CCS project, reducing the difficulty of developing DSP-based embedded systems. Furthermore, the solution adopted in this application also decouples the dedicated DSP development environment CCS. The entire process from code generation to deployment does not require starting the CCS environment, lowering the barrier to entry for designers. Moreover, the solution provided in this application also offers various onboard Flash programming schemes, a JTAG connection scheme without CCS, and an online upgrade scheme for serial port data transmission.

[0077] In summary, the embodiments of this application provide a one-click development method for DSP-based embedded systems with low learning costs and low development environment dependence, which can greatly reduce the learning costs for designers and improve the development efficiency of embedded systems.

[0078] This application also provides an executable file generation apparatus, such as... Figure 4 As shown, the device 400 includes: a model acquisition module 401, a code generation module 402, a project creation module 403, and a file generation module 404.

[0079] The model acquisition module 401 is used to acquire the visualization model corresponding to the algorithm to be executed, which is the algorithm that the digital signal processor is to execute in the embedded system. The code generation module 402 is used to convert the visual model into program code through the code generator in the simulation tool to obtain the target program code; Project creation module 403 is used to create a code debugging project using the code debugging component and the target program code. The code debugging component is a component in the code debugging tool, which provides a development environment for the system development of digital signal processors. The file generation module 404 is used to compile the code debugging project and generate an executable file that the digital signal processor can execute.

[0080] In some embodiments, the code generation module includes: a driver information acquisition module, a compiled file generation module, a first file conversion module, and a code generation submodule. The driver information acquisition module is used to acquire driver interface information corresponding to the digital signal processor; the compiled file generation module is used to compile the visualization model using a code generator to generate a model compiled file, wherein the model compiled file includes at least model information and model compilation information of the visualization model; the first file conversion module is used to convert the model compiled file into model code using a code generation template, wherein the code generation template includes the code format of the code executed by the digital signal processor; and the code generation submodule is used to generate target program code based on the model code and the driver interface information.

[0081] In some embodiments, the code generation submodule is specifically used to determine the hardware interface function of the digital signal processor from the driver interface information based on the hardware configuration information corresponding to the digital signal processor; and to perform code integration processing on the program code and model code corresponding to the hardware interface function to obtain the target program code.

[0082] In some embodiments, the project creation module is specifically used to obtain the simulation configuration information corresponding to the simulation tool and the hardware configuration information corresponding to the digital signal processor. The hardware configuration information includes at least the simulator information of the simulator and the board information of the board on which the digital signal processor is located. The simulator is used to link the terminal device and the digital signal processor. The module creates a project file corresponding to the simulation configuration information through the code debugging component. The module adds the target program code and hardware configuration information to the project file through the code debugging component to obtain a code debugging project.

[0083] In some embodiments, the file generation module is specifically used to obtain the compilation file corresponding to the code debugging project, wherein the compilation file includes at least the compilation parameters required during the compilation process of the code debugging project; and the code debugging project is compiled using the compilation file to obtain an executable file.

[0084] In some embodiments, the executable file generation apparatus further includes: a first code execution module, configured to, after compiling the code debugging project and generating an executable file that the digital signal processor can execute, further include: calling the program loading script corresponding to the code debugging component, downloading the code burning program to the digital signal processor through a simulator; controlling the digital signal processor to run the code burning program, reading and running the executable file, and obtaining the code execution result.

[0085] In some embodiments, the executable file generation apparatus further includes a second file conversion module, a file burning module, and a file execution module. The second file conversion module is used to convert the executable file into a binary file after compiling the code debugging project to generate an executable file that the digital signal processor can execute. The file burning module is used to burn the binary file into the memory of the digital signal processor. The file execution module is used to control the digital signal processor to restore the binary file into an executable file and run the executable file to obtain the code execution result.

[0086] In some embodiments, the file burning module is specifically used to download the code burning program to the digital signal processor via an emulator.

[0087] In some embodiments, the file writing module is specifically used to write binary files to the memory of the board where the digital signal processor is located via serial communication.

[0088] The executable file generation apparatus provided in this application embodiment can implement all the processes implemented in the foregoing method embodiments, and will not be described again here to avoid repetition.

[0089] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is merely an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiments can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit. Furthermore, the specific names of the functional units and modules are only for easy differentiation and are not intended to limit the scope of protection of this application. The specific working process of the units and modules in the above system can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0090] Figure 5 A schematic diagram of the hardware structure of the electronic device provided in an embodiment of this application is shown.

[0091] The electronic device may include a processor 501 and a memory 502 storing computer program instructions.

[0092] Specifically, the processor 501 may include a central processing unit (CPU), an application-specific integrated circuit (ASIC), or one or more integrated circuits that can be configured to implement the embodiments of this application.

[0093] Memory 502 may include mass storage for data or instructions. For example, and not limitingly, memory 502 may include a hard disk drive (HDD), floppy disk drive, flash memory, optical disk, magneto-optical disk, magnetic tape, or Universal Serial Bus (USB) drive, or a combination of two or more of these. Where appropriate, memory 502 may include removable or non-removable (or fixed) media. Where appropriate, memory 502 may be internal or external to the integrated gateway disaster recovery device. In a particular embodiment, memory 502 is non-volatile solid-state memory.

[0094] In specific embodiments, the memory 302 can be implemented in the form of ROM (Read Only Memory), RAM (Random Access Memory), static storage device, dynamic storage device, etc. The memory 302 can store the operating system and other applications. When the technical solutions provided in the embodiments of this specification are implemented through software or firmware, the relevant program code is stored in the memory 302 and executed by the processor 301. The processor 301 reads and executes the computer program instructions stored in the memory 302 to implement any of the executable file generation methods in the above embodiments.

[0095] In one example, the electronic device may also include a communication interface 503 and a bus 510. Wherein, as... Figure 5 As shown, the processor 501, memory 502, and communication interface 503 are connected through bus 510 and complete communication with each other.

[0096] The communication interface 503 is mainly used to realize communication between various modules, devices, units and / or equipment in the embodiments of this application.

[0097] Bus 510 includes hardware, software, or both, that couples components of an electronic device together. For example, and not limitingly, the bus may include an Accelerated Graphics Port (AGP) or other graphics bus, an Enhanced Industry Standard Architecture (EISA) bus, a Front Side Bus (FSB), HyperTransport (HT) interconnect, an Industry Standard Architecture (ISA) bus, an Infinite Bandwidth Interconnect, a Low Pin Count (LPC) bus, a memory bus, a Microchannel Architecture (MCA) bus, a Peripheral Component Interconnect (PCI) bus, a PCI-Express (PCI-X) bus, a Serial Advanced Technology Attachment (SATA) bus, a Video Electronics Standards Association Local (VLB) bus, or other suitable buses, or combinations of two or more of these. Where appropriate, bus 510 may include one or more buses. Although specific buses are described and illustrated in embodiments of this application, this application contemplates any suitable bus or interconnect.

[0098] Furthermore, in conjunction with the executable file generation methods in the above embodiments, this application embodiment can provide a computer storage medium for implementation. This computer storage medium stores computer program instructions; when these computer program instructions are executed by a processor, they implement any of the executable file generation methods in the above embodiments.

[0099] The computer-readable medium of this embodiment includes permanent and non-permanent, removable and non-removable media, and information storage can be implemented by any method or technology. Information can be computer-readable instructions, data structures, program modules, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transfer medium that can be used to store information accessible by a computing device.

[0100] The computer instructions stored in the storage medium of the above embodiments are used to cause the computer to execute the executable file generation method as described in any of the above embodiments, and have the beneficial effects of the corresponding method embodiments, which will not be repeated here.

[0101] Furthermore, in conjunction with the executable file generation methods in the above embodiments, this application embodiment can provide a computer program product for implementation. When the instructions in this computer program product are executed by the processor of an electronic device, the electronic device performs an executable file generation method as described in any of the above embodiments.

[0102] It should be clarified that this application is not limited to the specific configurations and processes described above and shown in the figures. For the sake of brevity, detailed descriptions of known methods are omitted here. In the above embodiments, several specific steps are described and shown as examples. However, the method process of this application is not limited to the specific steps described and shown. Those skilled in the art can make various changes, modifications, and additions, or change the order of steps, after understanding the spirit of this application.

[0103] The functional modules shown in the above-described block diagram can be implemented as hardware, software, firmware, or a combination thereof. When implemented in hardware, they can be, for example, electronic circuits, application-specific integrated circuits (ASICs), appropriate firmware, plug-ins, function cards, etc. When implemented in software, the elements of this application are programs or code segments used to perform the required tasks. Programs or code segments can be stored on a machine-readable medium or transmitted over a transmission medium or communication link via data signals carried on a carrier wave. "Machine-readable medium" can include any medium capable of storing or transmitting information. Examples of machine-readable media include electronic circuits, semiconductor memory devices, ROM, flash memory, erasable ROM (EROM), floppy disks, CD-ROMs, optical disks, hard disks, fiber optic media, radio frequency (RF) links, etc. Code segments can be downloaded via computer networks such as the Internet, intranets, etc.

[0104] It should also be noted that the exemplary embodiments mentioned in this application describe methods or systems based on a series of steps or apparatus. However, this application is not limited to the order of the above steps; that is, the steps can be performed in the order mentioned in the embodiments, or in a different order, or several steps can be performed simultaneously.

[0105] The foregoing flowcharts and / or block diagrams of the methods and apparatus for generating executable files according to embodiments of the present disclosure have described various aspects of the present disclosure. It should be understood that each block of the flowcharts and / or block diagrams, and combinations of blocks in the flowcharts and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus to produce a machine such that these instructions, executable via the processor of the computer or other programmable data processing apparatus, enable the implementation of the functions / actions specified in one or more blocks of the flowcharts and / or block diagrams. Such a processor can be, but is not limited to, a general-purpose processor, a special-purpose processor, a special application processor, or a field-programmable logic circuit. It is also understood that each block of the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can also be implemented by special-purpose hardware performing the specified functions or actions, or can be implemented by a combination of special-purpose hardware and computer instructions.

[0106] The above description is merely a specific implementation of this application. Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, modules, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here. It should be understood that the protection scope of this application is not limited thereto. Any person skilled in the art can easily conceive of various equivalent modifications or substitutions within the technical scope disclosed in this application, and these modifications or substitutions should all be covered within the protection scope of this application.

Claims

1. A method for generating an executable file, characterized in that, include: Obtain the visualization model corresponding to the algorithm to be executed, wherein the algorithm to be executed is the algorithm to be executed by the digital signal processor in the embedded system; The visualization model is converted into program code using the code generator in the simulation tool to obtain the target program code; A code debugging project is created using a code debugging component and the target program code, wherein the code debugging component is a component of a code debugging tool, and the code debugging tool is used to provide a development environment for the system development of the digital signal processor; The code debugging project is compiled to generate an executable file that the digital signal processor can execute.

2. The method according to claim 1, characterized in that, The step of converting the visualization model into program code using a code generator in the simulation tool to obtain the target program code includes: Obtain the driver interface information corresponding to the digital signal processor; The visualization model is compiled using the code generator to generate a model compilation file, wherein the model compilation file includes at least the model information and model compilation information of the visualization model; The model compilation file is converted into model code using a code generation template, wherein the code generation template includes the code format of the code executed by the digital signal processor; The target program code is generated based on the model code and the driver interface information.

3. The method according to claim 2, characterized in that, The step of generating the target program code based on the model code and the driver interface information includes: Based on the hardware configuration information corresponding to the digital signal processor, the hardware interface function of the digital signal processor is determined from the driver interface information; The program code corresponding to the hardware interface function and the model code are integrated to obtain the target program code.

4. The method according to claim 1, characterized in that, The process of creating a code debugging project using the code debugging component and the target program code includes: The simulation configuration information corresponding to the simulation tool and the hardware configuration information corresponding to the digital signal processor are obtained. The hardware configuration information includes at least the simulator information of the simulator and the board information of the board on which the digital signal processor is located. The simulator is used to connect the terminal device and the digital signal processor. The code debugging component is used to create a project file corresponding to the simulation configuration information. The target program code and the hardware configuration information are added to the project file using the code debugging component to obtain the code debugging project.

5. The method according to claim 1, characterized in that, The process of compiling the code debugging project to generate an executable file that the digital signal processor can execute includes: Obtain the compilation file corresponding to the code debugging project, wherein the compilation file includes at least the compilation parameters required during the compilation process of the code debugging project; The executable file is obtained by compiling the code debugging project using the compiled file.

6. The method according to any one of claims 1 to 5, characterized in that, After compiling the code debugging project to generate an executable file that the digital signal processor can execute, the method further includes: The program loading script corresponding to the code debugging component is invoked, and the code burning program is downloaded to the digital signal processor through the simulator; The digital signal processor is controlled to run the code burning program, read and run the executable file, and obtain the code execution result.

7. The method according to any one of claims 1 to 5, characterized in that, After compiling the code debugging project to generate an executable file that the digital signal processor can execute, the method further includes: Convert the executable file into a binary file; The binary file is burned into the memory of the digital signal processor; The digital signal processor is controlled to restore the binary file to the executable file and run the executable file to obtain the code execution result.

8. The method according to claim 7, characterized in that, The step of writing the binary file into the memory of the digital signal processor includes: The binary file is burned into the memory of the board containing the digital signal processor using an emulator.

9. The method according to claim 7, characterized in that, The step of writing the binary file into the memory of the digital signal processor includes: The binary file is burned into the memory of the board containing the digital signal processor via serial communication.

10. An apparatus for generating an executable file, characterized in that, include: The model acquisition module is used to acquire the visualization model corresponding to the algorithm to be executed, wherein the algorithm to be executed is the algorithm to be executed by the digital signal processor in the embedded system; The code generation module is used to convert the visualization model into program code through the code generator in the simulation tool to obtain the target program code. The project creation module is used to create a code debugging project using a code debugging component and the target program code, wherein the code debugging component is a component in a code debugging tool, and the code debugging tool is used to provide a development environment for the system development of the digital signal processor; The file generation module is used to compile the code debugging project and generate an executable file that the digital signal processor can execute.

Images