Off-line software-in-the-loop simulation development system and method

Abstract

The present invention provides an off-line software-in-the-loop simulation development system and an off-line software-in-the-loop simulation method. A general firmware architecture is compiled to generate a chip control program. The general firmware architecture includes an application layer and a hardware abstraction layer. The application layer has a setup header file and a product program. Processing programs required by peripheral modules are added to the hardware abstraction layer at compile time. The chip control program is provided to a controller chip or circuit simulation software to control product-related circuits by controlling peripheral modules.

Description

Technical Field

[0001] This invention relates to software-in-the-loop simulation, and more particularly to an offline software-in-the-loop simulation development system and an offline software-in-the-loop simulation method. Background Technology

[0002] Typical circuit devices include controller chips and product-related circuitry.

[0003] The controller chip can control the product's related circuits by executing firmware, thereby achieving automatic circuit control.

[0004] In the firmware development process, software-in-the-loop simulation is often used to generate firmware that is compatible with a specific controller chip.

[0005] The aforementioned software-in-the-loop simulation methods can be divided into real-time software-in-the-loop simulation methods and offline software-in-the-loop simulation methods.

[0006] Typical real-time software-in-the-loop (Software-in-the-Loop) simulation methods connect the development system directly to circuit devices via high-speed communication interfaces and / or specific hardware to directly measure signals from peripheral modules. Due to the need for high-speed communication interfaces and / or specific hardware, real-time software-in-the-loop simulation methods have high hardware costs.

[0007] Please see Figure 1 , Figure 1 This is a schematic diagram of existing offline software-in-the-loop simulation methods.

[0008] In existing offline software-in-the-loop simulation methods, developers must first implement a model-in-the-loop (MIL) simulation method to generate the controller model.

[0009] A controller model is used to automatically generate executable controller program code for a controlled object (such as a controller chip of a specific brand / model).

[0010] Developers can provide the generated controller program code to the controlled object for execution and verify the correctness of the program logic by observing the running results, thereby realizing the offline software-in-the-loop simulation method.

[0011] In existing offline software-in-the-loop simulation methods, the circuit simulation software used by the developer must support the type of controller chip currently in use. Only then can the controller program code generated by the controller model be correctly compatible with this type of controller chip, and thus perform the simulation correctly.

[0012] Furthermore, for controller chips of different brands / models, the circuit simulation software must provide different controller models to execute the aforementioned automatic program code generation.

[0013] The above situation means that circuit simulation software can only support a limited number of controller chip brands / models. Once it encounters an unsupported controller chip brand / model, the circuit simulation software cannot automatically generate controller program code compatible with this controller chip.

[0014] Therefore, existing software-in-the-loop simulation methods have the aforementioned problems, and there is an urgent need for more effective solutions. Summary of the Invention

[0015] The main objective of this invention is to provide an offline software-in-the-loop simulation development system and an offline software-in-the-loop simulation method, which can make the product program compatible with a specified controller chip or circuit simulation software through a hardware abstraction layer of a general firmware architecture, without requiring changes to the product program.

[0016] In one embodiment, an offline software-in-the-loop simulation development system includes a database and a general firmware architecture. The general firmware architecture includes an application layer and a hardware abstraction layer. The database contains at least one chip peripheral function library, and each chip peripheral function library contains at least one processor. The general firmware architecture, after compilation, generates a chip control program. The application layer includes a product program and a configuration header file. The product program records program code used to control product-related circuitry, and the configuration header file is used to link the processor required by a peripheral module. The hardware abstraction layer contains the processor, wherein the application layer adds the corresponding processor from the database to the hardware abstraction layer during compilation based on the peripheral module to be controlled by a specific physical controller chip or circuit simulation software. The chip control program is provided to the physical controller chip or the circuit simulation software for execution, and controls the product-related circuitry by controlling the peripheral module.

[0017] In one embodiment, an offline software-in-the-loop simulation method includes: a) obtaining a product program and a configuration header file, wherein the product program records program code for controlling a product-related circuit, and the configuration header file is used to link a processing program required by a peripheral module, the processing program being used to control the peripheral module in a physical controller chip or a circuit simulation software; b) executing a compiler to compile the product program and the configuration header file to generate a chip control program; and c) executing the chip control program in the physical controller chip or the circuit simulation software to control the product-related circuit by controlling the peripheral module; wherein step b) includes: b1) searching for the processing program from a database based on the configuration header file and adding the processing program to a hardware abstraction layer; b2) compiling an application layer and the hardware abstraction layer to generate the chip control program, wherein the application layer includes the product program and the configuration header file; and b3) providing the chip control program to the physical controller chip or the circuit simulation software.

[0018] This invention can quickly adapt product programs for different types of controller chips or circuit simulation software, thereby effectively shortening firmware development time. Attached Figure Description

[0019] Figure 1 This is a schematic diagram of existing offline software-in-the-loop simulation methods.

[0020] Figure 2 This is a schematic diagram of an offline software-in-the-loop simulation method according to an embodiment of the present invention.

[0021] Figure 3A This is a compilation architecture diagram of a development system according to an embodiment of the present invention.

[0022] Figure 3B This is an execution architecture diagram of the product mode of a development system according to an embodiment of the present invention.

[0023] Figure 3C This is an execution architecture diagram of the virtual mode of the development system according to an embodiment of the present invention.

[0024] Figure 4A This is a flowchart of an offline software-in-the-loop simulation method according to an embodiment of the present invention.

[0025] Figure 4B This is a flowchart illustrating the compilation process of an embodiment of the present invention.

[0026] Figure 5 This is a compilation architecture diagram of a product model according to an embodiment of the present invention.

[0027] Figure 6 This is an execution architecture diagram of a product mode according to an embodiment of the present invention.

[0028] Figure 7 This is a flowchart illustrating a product model according to an embodiment of the present invention.

[0029] Figure 8 This is a compilation architecture diagram of a virtual mode according to an embodiment of the present invention.

[0030] Figure 9 This is an execution architecture diagram of a virtual mode according to an embodiment of the present invention.

[0031] Figure 10 This is a flowchart illustrating a virtual mode according to an embodiment of the present invention.

[0032] Figure 11 This is an architecture diagram of the hardware abstraction layer according to an embodiment of the present invention.

[0033] Figure 12 This is a schematic diagram of the data connection of a general firmware architecture according to an embodiment of the present invention.

[0034] Figure 13 This is a partial schematic diagram of the header setting according to an embodiment of the present invention.

[0035] Figure 14 This is a schematic diagram of the processing program of a controller chip according to an embodiment of the present invention.

[0036] Figure 15 This is a partial schematic diagram of the processing procedure of circuit simulation software according to an embodiment of the present invention.

[0037] Figure 16 This is a flowchart of a non-preemptive scheduling method according to an embodiment of the present invention.

[0038] Figure 17 This is a flowchart of an interrupt / non-interrupt procedure processing according to an embodiment of the present invention.

[0039] Explanation of reference numerals in the attached figures:

[0040] 1: Database

[0041] 2: Program code

[0042] 3: Compiled output

[0043] 10: General Firmware Architecture

[0044] 100: Application Layer

[0045] 101: Hardware Abstraction Layer

[0046] 11: Chip Control Program

[0047] 20: Set header file

[0048] 21: Product Procedure

[0049] 22: Surrounding Initialization Procedure

[0050] 23: Non-preemptive scheduler

[0051] 30: Chip peripheral function library

[0052] 300: Handling Procedure

[0053] 301: Handling Procedure

[0054] 31: Physical controller chip

[0055] 32: Physical peripheral modules

[0056] 33, 330-333: Circuits related to physical products

[0057] 34: Virtual controller chip

[0058] 35: Dynamically Linked Function Libraries

[0059] 36, 360-362: Virtual Peripheral Module

[0060] 37, 370-373: Circuits related to virtual products

[0061] 41: Power Monitoring

[0062] 42: Fan speed control

[0063] 43: LED Control

[0064] 44: External overcurrent protection

[0065] 45: Digital Closed-Loop Control

[0066] pwm1-pwm5, v1-v5, i1-i5, tacho1-tacho2, led1-led2, duty1-duty2: signals

[0067] S10-S12: Simulation Steps

[0068] S20-S22: Compilation Steps

[0069] S30-S33: Product Model Simulation Steps

[0070] S40-S41: Product Mode Setting Steps

[0071] S50-S53: Virtual Mode Simulation Steps

[0072] S60-S61: Virtual Mode Setup Steps

[0073] S70-S72: Non-preemptive scheduling steps

[0074] S80-S82: Interrupt / Non-interrupt handling steps

[0075] S90-S97: Non-preemptive interrupt / non-interrupt handling steps Detailed Implementation

[0076] A preferred embodiment of the present invention will now be described in detail with reference to the accompanying drawings.

[0077] Please see Figure 2 , Figure 3A , Figure 3B and Figure 3C . Figure 2 This is a schematic diagram of an offline software-in-the-loop simulation method according to an embodiment of the present invention. Figure 3A This is a compilation architecture diagram of a development system according to an embodiment of the present invention. Figure 3B This is an execution architecture diagram of the product mode of a development system according to an embodiment of the present invention. Figure 3C This is an execution architecture diagram of the virtual mode of the development system according to an embodiment of the present invention.

[0078] This invention proposes an offline software-in-the-loop simulation development system and an offline software-in-the-loop simulation method. With only simple settings, product programs can be quickly transferred to specified control objects, and firmware compatible with the specified control objects (such as the chip control program described later) can be generated, thus providing excellent product program portability.

[0079] The aforementioned controlled object may be, for example, different types / models of controller chips or circuit simulation software used to simulate different controller chips.

[0080] In this invention, the development system may be, for example, a general-purpose computer system such as a personal computer, a laptop computer, or a tablet computer, and may include a memory (such as a temporary register, cache memory, flash memory, hard disk drive, solid-state drive, RAM, ROM, EEPROM, etc.), an input device (such as a keyboard, mouse, touchpad, etc.), an output device (such as a display, speaker, etc.), a communication interface (such as a USB interface, Wi-Fi interface, Bluetooth interface, serial communication interface, etc.), a processor (such as a CPU, GPU, ALU, etc.) electrically connected to the above devices, and / or other computer devices.

[0081] The aforementioned memory can be used to store the database 1, Common Firmware Architecture (CFA) 10, development software, circuit simulation software and / or other programs / software of the present invention.

[0082] The processor can be used to execute programs / software stored in memory, read and write data to memory, and interact with developers through input and output devices.

[0083] The development system of this invention may include a general firmware architecture 10 composed of program code 2, and provides a product mode and a virtual mode. In product mode (i.e.... Figure 3B In the real world shown, the controlled object can be a physical controller chip 31. In virtual mode (i.e., Figure 3C The circuit simulation software shown can be used to control the virtual controller chip 34 of the circuit simulation software.

[0084] The database 1 of the development system may contain one or more chip peripheral function libraries 30. Each chip peripheral function library 30 corresponds to a controller chip, such as a physical controller chip 31 or a virtual controller chip 34.

[0085] Furthermore, each chip peripheral function library 30 may contain one or more processing programs ( Figure 3A (Taking multiple 300-301 processing programs as an example). The multiple processing programs 300-301 of each chip peripheral function library 30 are used to control multiple peripheral modules of the corresponding controller chip, such as the physical peripheral module 32 of the physical controller chip 31, or the virtual peripheral module 36 of the virtual controller chip 34.

[0086] The general firmware architecture 10 of the development system is the same as the architecture of program code 2, and the development system includes a compiler. After the general firmware architecture 10 is compiled by the compiler, a chip control program 11 is generated (that is, the compiled product 3 of the general firmware architecture 10). The chip control program 11 can be used to control the aforementioned peripheral modules to perform the functions specified by the product program 21.

[0087] The general firmware architecture 10 may include an application layer 100 and a hardware abstraction layer (HAL) 101.

[0088] Application layer 100 includes product program 21 and its configuration header file 20.

[0089] Product program 21 contains program code used to control product-related circuits. The header file 20 is configured with the processing program 301 required to connect to the peripheral modules of the specified controller chip (such as physical peripheral module 32 of physical controller chip 31 or virtual peripheral module 36 of virtual controller chip 34).

[0090] Specifically, developers can write product program 21 for the control functions to be implemented. The aforementioned product program 21 can call product-related subroutines, and does not need to consider the type of the control object to be executed (such as physical controller chip 31 or virtual controller chip 34).

[0091] Next, after deciding on the control object to execute product program 21, the developer can modify the configuration header file 20 of product program 21 to link the processing program 301 used to control peripheral modules through the configuration header file 20.

[0092] Furthermore, developers can select the corresponding peripheral modules based on the control functions used by the product program 21, and set the processing program 301 required by this peripheral module in the setting header file 20.

[0093] The aforementioned processing program 301 is compatible with the peripheral modules of the specified controller chip (such as the physical peripheral module 32 of the physical controller chip 31 or the virtual peripheral module 36 of the virtual controller chip 34) and can serve as the medium for the product program 21 to control the peripheral modules.

[0094] Taking the fan speed control function as an example, product program 21 must send a fan speed control signal (PWM signal) to the fan device (product-related circuit) through the PWM module (peripheral module) of the controller chip.

[0095] Taking LED control as an example, product program 21 must send I / O control signals to the LED device (product-related circuit) through the GPIO module (peripheral module) of the controller chip.

[0096] In this invention, the development system can use a compiler to compile the program code 2 of the general firmware architecture 10 to obtain the chip control program 11.

[0097] Specifically, the compiler can search the database 1 for the chip peripheral function library 30 corresponding to the current controller chip based on the setting header file 20, extract the processor 301 specified by the setting header file 20 from the multiple processors 300-301 of the found chip peripheral function library 30, and add the processor 301 to the hardware abstraction layer 101.

[0098] Next, the compiler can compile and link all program code 2 of the general firmware architecture 10 to generate the chip control program 11.

[0099] In this invention, the generated chip control program 11 is provided to the physical controller chip 31 in the real world (product mode) or circuit simulation software (virtual mode).

[0100] In the product mode, developers can connect the development system to the physical controller chip 31 through the communication interface, and burn the chip control program 11 to the physical controller chip 31 through the development software and communication interface corresponding to the physical controller chip 31.

[0101] When the physical controller chip 31 executes the chip control program 11, the product program 21 of the chip control program 11 can control the physical peripheral module 32 of the physical controller chip 31 through the processing program 301. By controlling the physical peripheral module 32, the product program 21 can indirectly control the physical product-related circuits 33 connected to the physical peripheral module 32.

[0102] In one embodiment, each physical peripheral module 32 has one or more dedicated signal pins, which can be connected to the corresponding physical product-related circuits 33.

[0103] In one embodiment, the physical product-related circuitry 33 may be, for example, a fan device, a power supply device, or a lighting device, but is not limited thereto.

[0104] In virtual mode, the chip control program 11 is included in the dynamic-link library (DLL) 35, and the developer updates the dynamic-link library 35 to the circuit simulation software.

[0105] Next, the virtual controller chip 34 of the circuit simulation software can execute the mobile-state link function library 35. When executing the mobile-state link function library 35, the product program 21 of the chip control program 11 can control the virtual peripheral module 36 of the virtual controller chip 34 through the processing program 301. By controlling the virtual peripheral module 36, the product program 21 can indirectly control the virtual product-related circuits 37 connected to the virtual peripheral module 36.

[0106] In this way, developers can verify the circuit control flow (program logic) defined in the product program 21 by observing the execution results of the chip control program 11 (such as the response or feedback signals of the physical product-related circuit 33 / virtual product-related circuit 37, or the signals sent and received by the physical peripheral module 32 / virtual peripheral module 36), and can quickly diagnose whether there are defects or errors in the product program 21.

[0107] The universal firmware architecture 10 of this invention provides excellent portability.

[0108] Specifically, when replacing different types of controller chips (including physical controller chip 31 and virtual controller chip 34), the present invention only needs to expand the chip peripheral function library 30 for the new controller chip and modify the setting header file 20 to link the processing program 301 of the compatible chip peripheral function library 30, so as to perform offline software-in-the-loop simulation in the new controller chip without rewriting the product program 21.

[0109] Furthermore, since the present invention does not rely on the control model constructed by the model-in-the-loop, it has superior version control capabilities for design changes.

[0110] Specifically, during the development of circuit equipment, the product program 21 usually needs to be frequently modified and repeatedly tested, resulting in a large number of versions of the product program 21.

[0111] The offline software-in-the-loop method used in related technologies automatically generates program code through a control model, which is not easy to manage in terms of version control.

[0112] Since this invention does not require automatic generation of program code through a control model, the product program 21 of each version is in text format, which facilitates version management.

[0113] Please refer to further information. Figure 3A , Figure 3B , Figure 3C , Figure 4A and Figure 4B . Figure 4A This is a flowchart of an offline software-in-the-loop simulation method according to an embodiment of the present invention. Figure 4B This is a flowchart illustrating the compilation process of an embodiment of the present invention.

[0114] The offline software-in-the-loop simulation methods of the various embodiments of the present invention can be implemented using the development systems of the various embodiments of the present invention.

[0115] The offline software-in-the-loop simulation method of this embodiment mainly includes steps S10-S12.

[0116] In step S10, the development system obtains the product program 21 and the configuration header file 20, and sets the running mode based on the configuration header file 20.

[0117] In one embodiment, the developer can set the operating mode to product mode or virtual mode in the configuration header file 20.

[0118] In step S11, the development system compiles the product program 21 and the header file 20 in the general firmware architecture 10 by executing the compiler to generate the chip control program 11.

[0119] In one embodiment, under product mode, the aforementioned compiler entity may be provided by the development software corresponding to the controller chip 31.

[0120] In one embodiment, in virtual mode, the aforementioned compiler may be provided by circuit simulation software.

[0121] Please see Figure 4B In one embodiment, the aforementioned step of executing the compiler may include steps S20-S22.

[0122] In step S20, during the pre-build stage before generating the executable file, the development system searches for the linked processor 301 from the database 1 based on the header file 20 and adds the processor 301 to the hardware abstraction layer 101.

[0123] In step S21, during the stage of generating an executable file (Build), the development system uses a compiler to compile and link the application layer 100 and hardware abstraction layer 101 of the general firmware architecture 10 to generate an executable chip control program 11.

[0124] In step S22, during the post-build stage after generating the executable file, the development system provides the chip control program 11 to the physical controller chip 31 or circuit simulation software.

[0125] For example, in a product model, the development system can embed a chip control program 11 into the physical controller chip 31.

[0126] In another example, in virtual mode, the development system can import a dynamically linked library 35 with chip control program 11 into the virtual controller chip 34 of the circuit simulation software.

[0127] Please refer to the following: Figure 4A In step S12, the physical controller chip 31 or the virtual controller chip 34 of the circuit simulation software executes the chip control program 11 to control the product-related circuits by controlling the peripheral modules.

[0128] Please refer to further information. Figure 5 , Figure 6 and Figure 7 This is used to illustrate the product model of the present invention. Figure 5 This is a compilation architecture diagram of a product model according to an embodiment of the present invention. Figure 6 This is an execution architecture diagram of a product mode according to an embodiment of the present invention. Figure 7 This is a flowchart illustrating a product model according to an embodiment of the present invention.

[0129] To enable the development system to run in product mode, the developer can set the running mode to product mode in the header file 20, select the physical controller chip 31, and select the physical peripheral modules 32 required by the product program 21.

[0130] In one embodiment, the application layer 100 may include one or more peripheral initialization procedures 22, each peripheral initialization procedure 22 being used to initialize the corresponding processing procedure 301 during execution.

[0131] Furthermore, during the compilation process, the compiler links each peripheral initialization program 22 to the corresponding entity peripheral module 32's handler 301.

[0132] The present invention allows for the configuration of the peripheral initialization program 22 to set the usage mode of the physical peripheral module 32 according to product requirements.

[0133] In one embodiment, the developer can link the peripheral initialization program 22 corresponding to the handler 301 in the header file 20, thereby making the peripheral initialization program 22 added to the application layer 100 during compilation.

[0134] In one embodiment, the development system further includes development software for performing compilation. This development software corresponds to the currently used physical controller chip 31, for example, it is a development tool provided by the supplier of the physical controller chip 31.

[0135] In one embodiment, the development system can connect to the physical controller chip 31, burn the chip control program 11 to the physical controller chip 31, and start the chip control program 11 in the physical controller chip 31 so that the physical controller chip 31 controls the physical product related circuits 33 by controlling the physical peripheral module 32.

[0136] Please see Figure 6 ,At Figure 6 In the example, product program 21 can provide a variety of control functions (e.g., sub-control programs), namely power monitoring 41, fan speed control 42, LED control 43, external overcurrent protection 44 and digital closed-loop control 45.

[0137] During execution, the header file 20 can provide parameter values ​​to the product program 21 and the peripheral initialization program 22.

[0138] Multiple peripheral initialization programs 22 can be used to initialize multiple processing programs 301 respectively.

[0139] The aforementioned multiple control functions of product program 21 can be controlled by multiple processing programs 301 to control the corresponding multiple physical peripheral modules 32, thereby controlling multiple physical product-related circuits 330-333 by controlling the multiple physical peripheral modules 32 respectively.

[0140] For example, the digital closed-loop control 45 can control the corresponding physical peripheral module 32 (e.g., a pulse width modulation module) to send pulse width modulation control signals pwm1 and pwm2 to the physical product related circuit 330 (e.g., a voltage / current control circuit) through the corresponding processing program 301, so that the physical product related circuit 330 sends voltage signal v1 and current signal i1 to the physical product related circuit 331.

[0141] Next, the physical product-related circuit 331 adjusts the magnitudes of the voltage signal v1 and the current signal i1 and generates the voltage signal v2 and the current signal i2, and transmits the voltage signal v2 and the current signal i2 to another physical peripheral module 32 (e.g., an analog-to-digital conversion module) so that the digital closed-loop control 45 determines the next pulse width modulation control signals pwm1 and pwm2 based on the digital values ​​of the voltage signal v2 and the current signal i2.

[0142] Therefore, the external overcurrent protection 44 can monitor the digital value of the current signal i2 to determine whether the overcurrent protection is triggered.

[0143] In another example, the fan speed control 42 can control the corresponding physical peripheral module 32 (e.g., a pulse width modulation module) to send a pulse width modulation control signal pwm3 to the physical product related circuit 332 (e.g., a fan control circuit) through the corresponding processing program 301. This causes the physical product related circuit 332 to adjust the fan speed based on the pulse width modulation control signal pwm3, and transmit the adjustment result (speed signal tacho1) to another physical peripheral module 32 (e.g., a speed signal receiving module). This allows the fan speed control 42 to obtain the adjustment result through the corresponding other processing program 301 for speed feedback control.

[0144] In another example, the LED controller 43 can control the corresponding physical peripheral module 32 (e.g., the LED control module and the analog / digital conversion module) to send a digital LED control signal led1 to the physical product-related circuit 333 (e.g., the LED circuit) through the corresponding processing program 301, so that the physical product-related circuit 333 adjusts the LED brightness based on the digital LED control signal led1.

[0145] Please see Figure 7 In this embodiment, the offline software-in-the-loop simulation method can execute steps S30-S33 in product mode.

[0146] In step S30, the development system obtains the configuration header file 20. The aforementioned configuration header file 20 has been configured by the developer.

[0147] Specifically, developers can perform the following steps S40-S41 to set the aforementioned configuration header file 20.

[0148] In step S40, the developer selects the physical controller chip 31 to be used and the physical peripheral modules 32 required by the product program 21 in the configuration header file 20.

[0149] In step S41, the developer sets the running mode to product mode in the configuration header file 20.

[0150] In step S31, the developer executes a compiler in the development software corresponding to the physical controller chip 31 to compile the program code 2 of the general firmware architecture 10 to obtain the chip control program 11. The aforementioned compiler may, for example, execute the contents of the aforementioned steps S20-S22, which will not be described in detail here.

[0151] In one embodiment, after obtaining the chip control program 11, the development system burns the generated chip control program 11 to the physical controller chip 31 through the development software and communication interface.

[0152] In step S32, the development system starts the chip control program 11 that has been burned into the physical controller chip 31.

[0153] In step S33, the physical controller chip 31 controls the physical peripheral module 32 to control the physical product-related circuits 33 by executing the chip control program 11.

[0154] In this way, the present invention enables the product program 21 to control the physical peripheral module 32 of the physical controller chip 31, and thereby control the physical product-related circuits 33.

[0155] Please refer to further information. Figure 8 , Figure 9 and Figure 10 This is used to illustrate the virtual mode of the present invention. Figure 8 This is a compilation architecture diagram of a virtual mode according to an embodiment of the present invention. Figure 9 This is an execution architecture diagram of a virtual mode according to an embodiment of the present invention. Figure 10 This is a flowchart illustrating a virtual mode according to an embodiment of the present invention.

[0156] To enable the development system to run in virtual mode, the developer can set the running mode to virtual mode in the header file 20, select the circuit simulation software, select the virtual controller chip 34 to be simulated, and select the virtual peripheral module 36 required by the product program 21.

[0157] In one embodiment, the development system may include circuit simulation software. The circuit simulation software is used to simulate the virtual controller chip 34, one or more virtual peripheral modules 36 of the virtual controller chip 34, and virtual product-related circuits 37.

[0158] In one embodiment, the application layer 100 of the general firmware architecture 10 may include a non-preemptive scheduler (NPS) 23, which is added to the application layer 100 during compilation.

[0159] In one embodiment, the circuit simulation software can start the chip control program 11 during execution to trigger the non-preemptive scheduler 23, thereby simulating the interrupt / non-interrupt behavior of the hardware in a software manner.

[0160] The virtual mode of the present invention mainly uses pure software to test and verify the control function of the product program 21, thereby verifying whether the product program 21 has any design flaws.

[0161] It is worth mentioning that in virtual mode, since there is no physical controller chip 31 connected, no hardware-induced interrupt events will occur, which will result in the simulation not being realistic enough.

[0162] To address the hardware interrupt handling issue in virtual mode, the general firmware architecture 10 of this embodiment further includes a non-preemptive scheduler 23. The non-preemptive scheduler 23 is used to simulate program interrupts.

[0163] In one embodiment, the non-preemptive scheduler 23 is a software scheduling manager that is only started when virtual mode is executed. The non-preemptive scheduler 23 can periodically call software functions (interrupt service routines and non-interrupt service routines) written in the controller chip via a dynamic-link library (DLL) 35, thereby solving the problem that circuit simulation software cannot simulate the interrupt handling behavior of a physical controller chip. The aforementioned dynamic-link library 35 is obtained by compiling the program code 2 of the general firmware architecture 10 and contains the chip control program 11.

[0164] In one embodiment, the circuit simulation software can set the parameters of the non-preemptive scheduler 23 during execution and execute interrupt / non-interrupt routine processing through the non-preemptive scheduler 23.

[0165] In one embodiment, the circuit simulation software may include periodic interrupt service routines, aperiodic interrupt service routines, and non-interrupt service routines. A non-preemptive scheduler 23 is used to execute the aforementioned periodic interrupt service routines, aperiodic interrupt service routines, and non-interrupt service routines to simulate periodic interrupts, aperiodic interrupts, and non-interrupts.

[0166] In one embodiment, the circuit simulation software can control the virtual peripheral module 36 via a non-preemptive scheduler 23 each time a set reference frequency occurs, in order to control the virtual product-related circuits 37.

[0167] Please see Figure 9 ,At Figure 9 In this example, product program 21 can provide various control functions (e.g., sub-control programs), namely power monitoring 41, fan speed control 42, LED control 43, external overcurrent protection 44, and digital closed-loop control 45. These various control functions are triggered and executed by a non-preemptive scheduler 23.

[0168] During execution, the header file 20 can provide parameter values ​​to the product program 21 and the peripheral initialization program 22.

[0169] Multiple peripheral initialization programs 22 can be used to initialize multiple processing programs 301 respectively.

[0170] The aforementioned multiple control functions of product program 21 can be controlled by multiple processing programs 301 to control the corresponding multiple virtual peripheral modules 36, thereby controlling multiple virtual product-related circuits 37 by controlling the multiple virtual peripheral modules 36 respectively.

[0171] For example, the digital closed-loop control 45 can control the corresponding virtual peripheral module 360 ​​(e.g., a virtual input / output signal module) to send adjustment control signals to the virtual peripheral module 361 (e.g., a virtual PWM module) through the corresponding processing program 301, and control the virtual peripheral module 361 to send pulse width modulation control signals pwm4 and pwm5 to the virtual product-related circuit 370 (e.g., a virtual voltage / current control circuit), so that the virtual product-related circuit 370 sends voltage signal v3 and current signal i3 to the virtual product-related circuit 371.

[0172] Next, the virtual product-related circuit 371 adjusts the magnitude of the voltage signal v3 and the current signal i3 and generates the voltage signal v4 and the current signal i4, and transmits the voltage signal v4 and the current signal i4 to another virtual peripheral module 362 (e.g., a virtual analog-to-digital conversion module).

[0173] Next, the virtual peripheral module 362 converts the adjustment result into a digital voltage signal v5 and a digital current signal i5 (digital adjustment result), and transmits the digital voltage signal v5 and the digital current signal i5 to the virtual peripheral module 360.

[0174] The digital closed-loop control 45 determines a new control signal, duty 1, based on the digital voltage signal v5 and the digital current signal i5. The external overcurrent protection 44 can monitor the digital values ​​obtained by the virtual peripheral module 360 ​​through another corresponding processing program 301 to determine whether to trigger the overcurrent protection.

[0175] In another example, the fan speed control 42 can control the corresponding virtual peripheral module 360 ​​to send an adjustment control signal duty2 to the virtual product-related circuit 372 (e.g., a virtual fan control circuit) through the corresponding processing program 301. This allows the virtual product-related circuit 372 to simulate adjusting the fan speed based on the adjustment control signal duty2, and virtually transmit the adjustment result (speed signal tacho2) to the virtual peripheral module 360. This enables the fan speed control 42 to obtain the adjustment result through the corresponding processing program 301 for speed feedback control.

[0176] In another example, the LED controller 43 can control the corresponding virtual peripheral module 360 ​​to send a digital LED control signal led2 to the virtual product-related circuit 373 (e.g., a virtual LED circuit) through the corresponding processing program 301, so that the virtual product-related circuit 373 can simulate and adjust the LED brightness based on the digital LED control signal led2.

[0177] Please see Figure 10 In this embodiment, the offline software-in-the-loop simulation method can execute steps S50-S53 in virtual mode.

[0178] In step S50, the development system obtains the configuration header file 20. The aforementioned configuration header file 20 has been configured by the developer.

[0179] Specifically, developers can perform the following steps S60-S61 to set the aforementioned configuration header file 20.

[0180] In step S60, the developer selects the circuit simulation software to be used in the header file 20.

[0181] In one embodiment, the developer may further select the virtual controller chip 34 and the required virtual peripheral modules 36 in the circuit simulation software.

[0182] In step S61, the developer sets the running mode to virtual mode in the configuration header file 20.

[0183] In step S51, the development system uses a compiler to compile the environment provided by the circuit simulation software to obtain the chip control program 11. The aforementioned compiler may, for example, execute the contents of the aforementioned steps S20-S22, which will not be described in detail here.

[0184] In one embodiment, the non-preemptive scheduler 23 is added to the application layer 100 at compile time.

[0185] Next, the development system can update the dynamically linked library 35 with chip control program 11 to the virtual controller chip 34 provided by the circuit simulation software.

[0186] In step S52, the development system starts the chip control program 11 in the dynamic link library 35 of the virtual controller chip 34 provided by the circuit simulation software, which has been updated to trigger the non-preemptive scheduler 23.

[0187] In step S53, in the circuit simulation software, the non-preemptive scheduler 23 triggers the product program 21. The product program 21 controls the virtual peripheral module 36 to control the virtual product-related circuits 37 through the chip control program 11.

[0188] In this way, the present invention enables software-in-the-loop simulation of product program 21 in circuit simulation software.

[0189] Please refer to further information. Figures 11 to 15 . Figure 11 This is an architecture diagram of the hardware abstraction layer according to an embodiment of the present invention. Figure 12 This is a schematic diagram of the data connection of a general firmware architecture according to an embodiment of the present invention. Figure 13 This is a partial schematic diagram of the header setting according to an embodiment of the present invention. Figure 14 This is a schematic diagram of the processing program of a controller chip according to an embodiment of the present invention. Figure 15 This is a partial schematic diagram of the processing procedure of circuit simulation software according to an embodiment of the present invention.

[0190] In one embodiment, such as Figure 11 As shown, the hardware abstraction layer 101 may contain multiple header files. Each header file is used to define and link the corresponding peripheral module's processing program.

[0191] In one embodiment, such as Figure 12 As shown, in the application layer 100, the product program can include the hardware abstraction layer header file cfa_hal.h by using the instruction #include "cfa_hal.h".

[0192] In the application layer's cfa_hal.h, the production application can include the configuration header file cfa_hal_config.h by specifying it with the directive #include "cfa_hal_config.h". The configuration header file cfa_hal_config.h provides execution parameters to the production application.

[0193] Furthermore, taking the configuration of an ADC (analog-to-digital converter) as an example, the product program can establish a data stream with the ADC processing program cfa_adc_28035.c in the hardware abstraction layer, and establish a data stream with peripheral modules (such as ADC modules) through the ADC processing program cfa_adc_28035.c.

[0194] In addition, the ADC processing program cfa_adc_28035.c can include the hardware abstraction layer header file cfa_hal.h by the instruction #include “cfa_hal.h”.

[0195] In the hardware abstraction layer header file cfa_hal.h, the ADC processing program cfa_adc_28035.c can include the ADC header file cfa_adc.h by the instruction #include “cfa_adc.h”.

[0196] In the ADC header file cfa_adc.h in the hardware abstraction layer, the ADC processing program cfa_adc_28035.c can include the controller chip header file cfa_adc_28035.h by the instruction #include “cfa_adc_28035.h”.

[0197] In this way, the product program can control peripheral modules (ADC modules) through a controller chip (such as the TI TMS320F28035 controller chip).

[0198] In one embodiment, such as Figure 13 As shown, developers can set parameters in the configuration header file cfa_hal_config.h.

[0199] The aforementioned parameters may include: the current operating mode, product mode or virtual mode; the manufacturer, model and compiler of the physical control chip in product mode; and the circuit simulation software and compiler in virtual mode, but are not limited thereto.

[0200] For example, the parameters can be set as follows: product mode; physical controller chip is TITMS320F28035; compiler is C2000.

[0201] In another example, the parameters can be set as follows: virtual mode; circuit simulation software is SIMULINK's S-function; compiler is MinGW-w64.

[0202] For example, such as Figure 14 As shown, in product mode, the header file can be linked to the processor cfa_adc_28035.c to make the chip control program compatible with the current physical controller chip.

[0203] In another example, such as Figure 15 As shown, in virtual mode, the header file can be linked to the processing program cfa_adc_simulink.c to make the chip control program compatible with current circuit simulation software.

[0204] Please see Figures 2 to 16 . Figure 16 This is a flowchart of a non-preemptive scheduling method according to an embodiment of the present invention.

[0205] The offline software-in-the-loop simulation method of this embodiment can simultaneously execute steps S70-S72 when executing the chip control program to provide interrupt / non-interrupt program processing functions.

[0206] In step S70, the development system sets the parameters of the non-preemptive scheduler 23.

[0207] In one embodiment, when there are multiple periodic interrupt service routines, and the multiple periodic interrupt service routines have different periodic interrupt frequencies, the development system can determine a reference frequency, such as a minimum value, a maximum value, or an average value, based on the multiple periodic interrupt frequencies.

[0208] In one embodiment, the development system selects the highest frequency from a plurality of periodic interrupt frequencies as the reference frequency.

[0209] For example, if multiple periodic interrupt frequencies are 5 kHz, 200 kHz and 1 kHz, the non-preemptive scheduler 23 can select 200 kHz as the trigger frequency.

[0210] Next, the development system can set the non-interrupt trigger period for the non-interrupt counter used for non-interrupt service routines based on the reference frequency.

[0211] In addition, the development system can set the non-periodic interrupt trigger period for the non-periodic interrupt counter used for non-periodic interrupt service routines based on the reference frequency.

[0212] For example, if the base frequency is 100 kHz, the uninterrupt frequency is to be set to 50 kHz, and the non-periodic interrupt service frequency is to be set to 10 kHz, then the uninterrupt trigger period can be set to 2 (i.e., an uninterrupt is executed once every two occurrences of the base frequency), and the non-periodic interrupt trigger period can be set to 10 (i.e., a non-periodic interrupt is executed once every ten occurrences of the base frequency).

[0213] In step S71, the development system executes interrupt / non-interrupt procedure processing through the non-preemptive scheduler 23.

[0214] In one embodiment, interrupt / non-interrupt procedure processing includes executing a periodic interrupt service routine, a non-periodic interrupt service routine, and a non-interrupt service routine.

[0215] Specifically, program execution has three interrupt mechanisms: non-interrupt service routines (e.g., polling), periodic interrupt service routines (ISRs), and non-periodic interrupt service routines (ISRs).

[0216] In the product mode, the physical controller chip 31 can perform the aforementioned interrupt handling.

[0217] In virtual mode, the present invention simulates the aforementioned interrupt handling through a non-preemptive scheduler 23.

[0218] Step S71 may include steps S80-S82 to process the above three interruption mechanisms.

[0219] In step S80, the development system executes a non-interruptible service routine to handle non-interruptible events.

[0220] In step S81, the development system executes a periodic interrupt service routine to handle periodic interrupt events.

[0221] In step S82, the development system executes an aperiodic interrupt service routine to handle aperiodic interrupt events.

[0222] In step S72, the development system determines whether to terminate the interrupt / non-interrupt procedure processing.

[0223] If execution ends, the method terminates.

[0224] If execution does not need to be terminated, step S71 is executed again to continue repeating the interrupt / non-interrupt procedure processing based on the reference frequency.

[0225] Therefore, this invention detects non-interrupt events and non-periodic interrupt events through a polling method, which can effectively simulate hardware interrupts in a pure software environment.

[0226] Please see Figures 2 to 17 . Figure 17 This is a flowchart of an interrupt / non-interrupt procedure processing according to an embodiment of the present invention.

[0227] In this embodiment, the non-preemptive scheduler 23 executes repeatedly at a reference frequency. Figure 16 The illustrated step S71 (i.e., interrupt / non-interrupt procedure processing). With Figure 16 Compared to the previous embodiment, the interrupt / non-interrupt procedure processing in this embodiment may include the following steps S90-S97.

[0228] In step S90, the non-preemptive scheduler 23 controls the non-interrupt counter and the non-periodic interrupt counter to count the number of times, such as incrementing by 1 or decrementing by 1.

[0229] In step S91, the non-preemptive scheduler 23 processes periodic interrupt events that conform to the reference frequency.

[0230] After step S91, the non-preemptive scheduler 23 can execute the interrupt / non-interrupt procedure again.

[0231] In step S92, the non-preemptive scheduler 23 determines whether the value of the non-interrupt counter meets the non-interrupt trigger cycle.

[0232] If the condition is met, the non-preemptive scheduler 23 executes step S93; otherwise, the process ends.

[0233] In step S93, the non-preemptive scheduler 23 processes non-interruptible events.

[0234] In step S94, the non-preemptive scheduler 23 resets the non-interrupt counter to re-time the waiting time for the next non-interrupt event to be processed.

[0235] After step S94, the non-preemptive scheduler 23 can perform interrupt / non-interrupt processing again.

[0236] In step S95, the non-preemptive scheduler 23 determines whether the value of the non-periodic interrupt counter meets the set non-periodic interrupt triggering period.

[0237] If the condition is met, the non-preemptive scheduler 23 executes step S96; otherwise, the process ends.

[0238] In step S96, the non-preemptive scheduler 23 processes non-periodic interrupt events.

[0239] In step S97, the non-preemptive scheduler 23 resets the non-interrupt counter to re-time the waiting time for the next non-periodic interrupt event to be processed.

[0240] After step S97, the non-preemptive scheduler 23 can perform interrupt / non-interrupt processing again.

[0241] Therefore, this invention can simulate hardware interrupts to obtain more accurate simulation results.

[0242] The above description is merely a preferred embodiment of the present invention and is not intended to limit the claims of the present invention. Therefore, all equivalent variations made using the content of the present invention are similarly included within the scope of the present invention and are hereby declared.

Claims

1. An offline software-in-the-loop simulation development system, comprising: A database, including at least one chip peripheral function library, each of the chip peripheral function libraries including at least one processing program; and A generic firmware architecture, after being compiled, generates a chip control program. This generic firmware architecture includes: An application layer includes a product program and a configuration header file, wherein the product program records program code used to control related circuitry of a product, and the configuration header file is used to connect to the processing program required by a peripheral module; and A hardware abstraction layer, including the processing program, wherein the application layer adds the corresponding processing program from the database to the hardware abstraction layer during compilation based on the peripheral module to be controlled by a specific physical controller chip or a circuit simulation software. The chip control program is used to be provided to the physical controller chip or the circuit simulation software for execution, and controls the product-related circuits by controlling the peripheral modules.

2. The development system of claim 1 further includes development software for performing compilation, the development software corresponding to the physical controller chip; in, In this configuration header file, the operating mode is set to a product mode, and the physical controller chip and the required physical peripheral module are selected. The development system is used to connect to the physical controller chip and, by starting the chip control program that has been burned into the physical controller chip, enables the physical controller chip to control the circuitry of a physical product by controlling the physical peripheral modules.

3. The development system as described in claim 1 further includes the circuit simulation software, used to simulate a virtual controller chip, a virtual peripheral module of the virtual controller chip, and a virtual product-related circuit; in, In this configuration header file, the operating mode is set to virtual mode, and the circuit simulation software is selected; The application layer also includes a non-preemptive scheduler, which is added to the application layer during compilation. The circuit simulation software is used to start the chip control program during execution to trigger the non-preemptive scheduler. The non-preemptive scheduler is used to trigger the product program during execution, and controls the virtual peripheral module through the chip control program to control the related circuits of the virtual product.

4. The development system as described in claim 3, wherein the circuit simulation software is used to set the parameters of the non-preemptive scheduler during execution and to execute an interrupt / non-interrupt procedure through the non-preemptive scheduler.

5. The development system as described in claim 4, wherein the circuit simulation software further includes a periodic interrupt service routine, a non-periodic interrupt service routine, and a non-interrupt service routine. in, The non-preemptive scheduler is used to execute the periodic interrupt service routine, the non-periodic interrupt service routine, and the non-interrupt service routine.

6. The development system of claim 4, wherein the non-preemptive scheduler is used to determine a reference frequency based on a plurality of periodic interrupt frequencies during execution, set a non-interrupt trigger period for a non-interrupt counter based on the reference frequency, and set a non-periodic interrupt trigger period for a non-periodic interrupt counter based on the reference frequency.

7. The development system of claim 6, wherein the non-preemptive scheduler is used to select the highest frequency among the plurality of periodic interrupt frequencies as a reference frequency, and to repeatedly execute the interrupt / non-interrupt procedure processing at the reference frequency.

8. The development system of claim 7, wherein the non-preemptive scheduler includes a non-interrupt counter and a non-periodic interrupt counter; in, The non-preemptive scheduler is used to control the non-interrupt counter and the non-periodic interrupt counter to count each time the interrupt / non-interrupt procedure is executed, to process a periodic interrupt event, to process a non-interrupt event and reset the non-interrupt counter when the value of the non-interrupt counter meets a non-interrupt trigger cycle, and to process a non-periodic interrupt event and reset the non-interrupt counter when the value of the non-periodic interrupt counter meets a non-periodic interrupt trigger cycle.

9. The development system of claim 1, wherein the application layer further includes a peripheral initialization program, which is added to the application layer at compile time and is used to initialize the processing program at execution time; in, This header file is used to link the peripheral initialization program corresponding to this process.

10. The development system as described in claim 1, further comprising: A memory is used to store the database and the general firmware architecture; and A processor, electrically connected to the memory, is used to execute programs.

11. An offline software-in-the-loop simulation method, comprising: a) Obtain a product program and a configuration header file, wherein the product program records program code used to control a product-related circuit, and the configuration header file is used to connect a processing program required by a peripheral module, the processing program being used to control the peripheral module in a physical controller chip or a circuit simulation software. b) Execute a compiler to compile the product program and the configuration header file to generate a chip control program; and c) Execute the chip control program in the physical controller chip or the circuit simulation software to control the product-related circuits by controlling the peripheral module; Step b) includes: b1) Based on the header file, search for the processor in a database and add the processor to a hardware abstraction layer; b2) Compile an application layer and the hardware abstraction layer to generate the chip control program, wherein the application layer includes the product program and the configuration header file; and b3) Provide the chip control program to the physical controller chip or the circuit simulation software.

12. The offline software-in-the-loop simulation method as described in claim 11, wherein in the configuration header file, the operating mode is set to a product mode, and the physical controller chip and a required physical peripheral module are selected; Step b) includes executing the compiler in the development software corresponding to the physical controller chip; Step c) includes: c1) Start the chip control program that has been burned into the physical controller chip; and c2) The controller chip of the entity executes the chip control program to control the peripheral modules of the entity to control the related circuits of an entity product.

13. The offline software-in-the-loop simulation method as described in claim 11, wherein in the configuration header file, the operating mode is set to a virtual mode, and the circuit simulation software is selected; Step b) also includes executing the compiler in an environment provided by the circuit simulation software; Step c) includes: c3) Start the chip control program in a virtual controller chip provided by the circuit simulation software that has been updated to trigger a non-preemptive scheduler; and c4) In the circuit simulation software, the product program is triggered by the non-preemptive scheduler to control a virtual peripheral module to control a virtual product-related circuit through the chip control program.

14. The offline software-in-the-loop simulation method as described in claim 13, wherein step c4) comprises: c41) Set the parameters of the non-preemptive scheduler; and c42) An interrupt / non-interrupt procedure is executed through the non-preemptive scheduler.

15. The offline software-in-the-loop simulation method of claim 14, wherein the interrupt / non-interrupt procedure processing includes executing a periodic interrupt service routine, a non-periodic interrupt service routine, and a non-interrupt service routine.

16. The offline software-in-the-loop simulation method as described in claim 14, wherein step c41) comprises: c411) A reference frequency is determined based on multiple periodic interrupt frequencies; c412) Set a non-interrupt trigger cycle for a non-interrupt counter based on the reference frequency; and c413) Based on the reference frequency, a non-periodic interrupt trigger period is set for a non-periodic interrupt counter.

17. The offline software-in-the-loop simulation method of claim 16, wherein step c411) includes selecting the highest frequency from the plurality of periodic interrupt frequencies as the reference frequency.

18. The offline software-in-the-loop simulation method of claim 14, wherein step c42) includes repeatedly executing the interrupt / non-interrupt procedure processing at a reference frequency.

19. The offline software-in-the-loop simulation method of claim 18, wherein the interrupt / non-interrupt procedure processing includes: d1) Control the counting of a non-interrupt counter and a non-periodic interrupt counter: d2) Handle a periodic interrupt event; d3) When the value of the non-interrupt counter satisfies a non-interrupt trigger cycle, process a non-interrupt event and reset the non-interrupt counter; and d4) When the value of the non-periodic interrupt counter satisfies a non-periodic interrupt trigger cycle, process a non-periodic interrupt event and reset the non-periodic interrupt counter.

20. The offline software-in-the-loop simulation method as described in claim 19, wherein step d1) includes incrementing or decrementing the value of the non-interrupt counter and the value of the non-periodic interrupt counter.

Images