CN115599372A

CN115599372A - Development system and method for offline software on-loop simulation

Info

Publication number: CN115599372A
Application number: CN202210412024.2A
Authority: CN
Inventors: 林佑任; 林建璋; 朱家苇; 蔡腾纬; 董丰瑄
Original assignee: Delta Electronics Inc
Current assignee: Delta Electronics Inc
Priority date: 2021-07-09
Filing date: 2022-04-19
Publication date: 2023-01-13
Also published as: TW202303392A; TWI821998B

Abstract

The invention provides a development system for offline software on-loop simulation and an offline software on-loop simulation method. The 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 setting header file and a product program. The processing required by the peripheral modules is added to the hardware abstraction layer at compile time. The chip control program is provided to the controller chip or the circuit simulation software to be executed to control the product-related circuit by controlling the peripheral module.

Description

Development system and method for offline software on-loop simulation

Technical Field

The present invention relates to software-on-loop simulation, and more particularly to a development system for offline software-on-loop simulation and an offline software-on-loop simulation method.

Background

A typical circuit device includes a controller chip and product-related circuits.

The controller chip can control the product-related circuit by executing the firmware, thereby realizing the automatic control of the circuit.

During the development of firmware, software-in-the-loop simulation (software-in-the-loop simulation) method is mostly used to generate firmware compatible with a specific controller chip.

The software-in-loop simulation method can be divided into a real-time software-in-loop simulation (real-time software-in-loop simulation) method and an off-line software-in-loop simulation (off-line software-in-loop simulation) method.

In a general real-time software-in-the-loop simulation method, a development system is directly connected to a circuit device through a high-speed communication interface and/or specific hardware to directly measure signals of peripheral modules. The real-time software-in-the-loop simulation method has a high hardware cost due to the need for a high-speed communication interface and/or specific hardware.

Referring to fig. 1, fig. 1 is a schematic diagram illustrating a conventional off-line software in-loop simulation method.

In the existing offline software-in-loop simulation method, a developer must first implement a model-in-the-loop (MIL) simulation method to generate a controller model.

A controller model is a model used to automatically generate controller program code executable by a control object, such as a controller chip of a particular brand/model.

The developer can provide the generated controller program code for the control object to execute, and verify whether the program logic is correct by observing the operation result, thereby realizing the off-line software-in-loop simulation method.

In the conventional offline software-in-loop simulation method, the circuit simulation software used by the developer must support the type of the currently used controller chip, and the controller program code generated by the controller model can be correctly compatible with the type of the controller chip, so as to correctly perform the simulation.

Further, for different brands/models of controller chips, the circuit simulation software must provide different controller models to perform the aforementioned automatic program code generation.

The above situation makes the circuit simulation software only support limited controller chip brands/models, and once the unsupported controller chip brands/models are met, the circuit simulation software cannot automatically generate the controller program codes compatible with the controller chip.

Therefore, the existing software-in-the-loop simulation method has the problems, and a scheme for more effective is needed to be provided.

Disclosure of Invention

The present invention provides a development system and a method for offline software in-loop simulation, which can make the product program compatible with the designated controller chip or circuit simulation software through the hardware abstraction layer of the general firmware architecture without changing the product program.

In one embodiment, an offline software-on-loop simulation development system comprises a database and a general firmware architecture. The general firmware architecture includes an application layer and a hardware abstraction layer. The database comprises at least one chip periphery function library, and each chip periphery function library comprises at least one processing program. The general firmware framework generates a chip control program after being compiled. The application layer comprises a product program and a set header file, wherein the product program records program codes for controlling a product-related circuit, and the set header file is used for connecting the processing program required by a peripheral module. The hardware abstraction layer contains the processing program, wherein the application layer adds the corresponding processing program from the database to the hardware abstraction layer in compilation according to the peripheral module to be controlled by a specific entity controller chip or a 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 circuit by controlling the peripheral module.

In one embodiment, an off-line software-in-loop simulation method comprises: a) Obtaining a product program and a set header file, wherein the product program records program codes for controlling a product-related circuit, the set header file is used for connecting a processing program required by a peripheral module, and the processing program is used for controlling the peripheral module in an entity controller chip or a circuit simulation software; b) Executing a compiler to compile the product program and the set 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 the step b) comprises: b1 Searching the handler from a database based on the set header file and adding the handler 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 set header file; and, b 3) providing the chip control program to the physical controller chip or the circuit simulation software.

The invention can quickly transfer the product program to different types of controller chips or circuit simulation software, thereby effectively shortening the firmware development time.

Drawings

Fig. 1 is a schematic diagram of a conventional off-line software in-loop simulation method.

Fig. 2 is a schematic diagram of an off-line software-in-loop simulation method according to an embodiment of the present invention.

FIG. 3A is a diagram of the compiler architecture of the development system according to an embodiment of the present invention.

FIG. 3B is an execution architecture diagram of a product model of a development system according to an embodiment of the invention.

Fig. 3C is an execution architecture diagram of a virtual model of a development system according to an embodiment of the present invention.

FIG. 4A is a flowchart of an off-line software-in-loop simulation method according to an embodiment of the present invention.

FIG. 4B is a flow chart of compiling according to an embodiment of the invention.

FIG. 5 is a diagram of the compiler architecture of a product schema according to an embodiment of the present invention.

FIG. 6 is an execution architecture diagram of a product model according to an embodiment of the invention.

FIG. 7 is a flow chart of a product model according to an embodiment of the invention.

FIG. 8 is a diagram of the compiler architecture of a virtual schema in accordance with an embodiment of the present invention.

FIG. 9 is a diagram of an execution architecture of a virtual model according to an embodiment of the present invention.

FIG. 10 is a flowchart of a virtual mode according to an embodiment of the present invention.

FIG. 11 is an architecture diagram of a hardware abstraction layer according to an embodiment of the present invention.

FIG. 12 is a diagram illustrating a data link of a generic firmware architecture according to an embodiment of the present invention.

Fig. 13 is a partial schematic view of a setting header file according to an embodiment of the invention.

Fig. 14 is a schematic diagram illustrating a processing procedure of a controller chip according to an embodiment of the invention.

FIG. 15 is a partial schematic diagram of a processing procedure of circuit-based phantom software according to an embodiment of the invention.

Fig. 16 is a flow diagram of non-preemptive scheduling in accordance with an embodiment of the present invention.

FIG. 17 is a flowchart of an interrupt/non-interrupt process according to an embodiment of the present invention.

Description of reference numerals:

1: database with a plurality of databases

2: program code

3: compiled artifacts

10: universal firmware architecture

100: application layer

101: hardware abstraction layer

11: chip control program

20: setting header file

21: product program

22: peripheral initialization program

23: non-preemptive scheduler

30: library of chip peripheral functions

300: processing program

301: processing program

31: entity controller chip

32: solid peripheral module

33. 330-333: circuit related to physical product

34: virtual controller chip

35: dynamic link function library

36. 360-362: virtual peripheral module

37. 370-373: virtual product related circuit

41: power monitoring

42: fan speed control

43: LED control

44: external overcurrent protection

45: digital closed loop control

pwm1-pwm5, v1-v5, i1-i5, tacho1-tacho2, led1-led2, duty1-duty2: signal

S10-S12: simulation procedure

S20-S22: compiling step

S30-S33: product mode simulation procedure

S40-S41: product mode setting step

S50-S53: virtual mode simulation procedure

S60-S61: virtual mode setting step

S70-S72: non-preemptive scheduling step

S80-S82: interrupt/non-interrupt handling procedure

S90-S97: non-preemptive interrupt/non-interrupt processing steps

Detailed Description

The following detailed description of a preferred embodiment of the present invention will be made with reference to the accompanying drawings.

Please refer to fig. 2, fig. 3A, fig. 3B, and fig. 3C. Fig. 2 is a schematic diagram of an off-line software-in-loop simulation method according to an embodiment of the present invention. FIG. 3A is a diagram of the compiler architecture of the development system according to an embodiment of the present invention. Fig. 3B is an execution architecture diagram of a product model of a development system according to an embodiment of the invention. Fig. 3C is an execution architecture diagram of a virtual model of a development system according to an embodiment of the present invention.

The invention provides a development system of off-line software on-loop simulation and an off-line software on-loop simulation method, which can quickly transfer a product program to a specified control object and generate firmware (such as a chip control program) compatible with the specified control object by simple setting, thereby providing excellent product program transplanting capability.

The aforementioned control objects may be, for example, different kinds/models of controller chips or circuit simulation software for simulating different controller chips.

In the present invention, the development system may be a general-purpose computer system such as a personal computer, a notebook computer, a tablet computer, etc., and may include a memory (e.g., a register, a cache memory, a flash memory, a hard disk, a solid state disk, a RAM, a ROM, an EEPROM, etc.), an input device (e.g., a keyboard, a mouse, a touch pad, etc.), an output device (e.g., a display, a speaker, etc.), a communication interface (e.g., a USB interface, a Wi-Fi interface, a bluetooth interface, a serial communication interface, etc.), a processor (e.g., a CPU, a GPU, an ALU, etc.) electrically connected to the above devices, and/or other computer devices.

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

The processor can be used for executing programs/software stored in the memory, reading and writing data in the memory, and interacting with developers through the input device and the output device.

The development system of the present invention may include a generic firmware architecture 10 constructed with code 2 and providing a Product Mode (Product Mode) and a Virtual Mode (Virtual Mode). In the product mode (i.e., the real world shown in fig. 3B), the control object may be the physical controller chip 31. In the virtual mode (i.e., the circuit simulation software shown in FIG. 3C), the control object may be the virtual controller chip 34 of the circuit simulation software.

One or more libraries 30 of chip periphery functions may be included in the database 1 of the development system. Each library 30 corresponds to a controller chip, such as the solid controller chip 31 or the virtual controller chip 34.

Also, each library 30 may include one or more processes (e.g., 300-301 processes in FIG. 3A). The plurality of processing programs 300 to 301 of each of the chip peripheral libraries 30 are used to control a plurality of 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.

The generic firmware architecture 10 of the development system is a code 2 architecture, and the development system includes a compiler (compiler), and the generic firmware architecture 10 generates the chip control program 11 (i.e., the compiled product 3 of the generic firmware architecture 10) after being compiled (complied) by the compiler. The chip control program 11 can be used to control the peripheral modules to execute the functions specified by the product program 21.

The generic firmware architecture 10 may include an Application Layer (Application Layer) 100 and a Hardware Abstraction Layer (HAL) 101.

The application layer 100 includes a product program 21 and its header file (head file) 20.

The product program 21 is recorded with program codes for controlling the product-related circuits. The header file 20 is set to connect the processing programs 301 required for the peripheral modules of the designated controller chip (e.g., the physical peripheral module 32 of the controller chip 31 or the virtual peripheral module 36 of the virtual controller chip 34).

In particular, the developer may write the product program 21 for the control function to be implemented. The product program 21 may call the product-related sub-program without considering the type of the control object (e.g., the controller chip 31 or the virtual controller chip 34) to be executed.

Then, after determining the control object of the product program 21, the developer can modify the set header file 20 of the product program 21 to link the processing program 301 for controlling the peripheral module through the set header file 20.

Furthermore, the developer can select the corresponding peripheral module according to the control function used by the product program 21, and set the processing program 301 required by the peripheral module in the setting header file 20.

The processing program 301 is compatible with the peripheral modules of the designated controller chip (e.g., the physical peripheral module 32 of the solid controller chip 31 or the virtual peripheral module 36 of the virtual controller chip 34), and can be used as a medium for controlling the peripheral modules by the product program 21.

Taking the fan speed control function as an example, the 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.

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

In the present invention, the development system may use a compiler to compile the code 2 of the generic firmware architecture 10 to obtain the chip control program 11.

Specifically, the compiler may search the database 1 for the chip-peripheral function library 30 corresponding to the current controller chip based on the set header file 20, extract the handler 301 specified by the set header file 20 from the plurality of handlers 300-301 in the found chip-peripheral function library 30, and add the handler 301 to the hardware abstraction layer 101.

Then, the compiler can perform compiling and linking on all the codes 2 of the generic firmware architecture 10 to generate the chip control program 11.

In the present invention, the generated chip control program 11 is provided to the physical controller chip 31 (product mode) or the circuit simulation software (virtual mode) of the real world.

In the product mode, the developer may connect the development system to the entity controller chip 31 through the communication interface, and burn the chip control program 11 into the entity controller chip 31 through the development software and the communication interface corresponding to the entity controller chip 31.

When the physical controller chip 31 executes the chip control program 11, the product program 21 of the chip control program 11 may 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 circuit 33 connected to the physical peripheral module 32.

In one embodiment, each of the physical peripheral modules 32 has one or more dedicated signal pins (pins), and can be connected to the corresponding physical product related circuit 33 through the pins.

In an embodiment, the physical product-related circuit 33 may be, for example, but not limited to, a fan device, a power device, and a lighting device.

In the virtual mode, the chip control program 11 is included in a Dynamic-Link Library (DLL) 35, and the developer updates the Dynamic Link Library 35 to the circuit simulation software.

The virtual controller chip 34 of the circuit emulation software can then execute the mobile mode link library 35. When executing the dynamic link 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.

Thus, the developer can verify the circuit control flow (program logic) defined by the product program 21 by observing the execution result of the chip control program 11 (e.g. the response or return signal of the entity-related circuit 33/the virtual-product-related circuit 37, or the signal transmitted and received by the entity-peripheral module 32/the virtual-peripheral module 36), and can quickly diagnose whether the product program 21 has defects or errors.

The generic firmware architecture 10 of the present invention provides excellent portability.

Specifically, when replacing different types of controller chips (including the physical controller chip 31 and the virtual controller chip 34), the present invention can perform offline software-on-loop simulation on the new controller chip without rewriting the product program 21 by only expanding the chipset 30 for the new controller chip and modifying the set header file 20 to connect the processing program 301 of the compatible chipset 30.

In addition, the invention does not need to depend on the control model constructed by the model in the ring, and has the version control capability of the optimized design change.

Specifically, frequent modification and repeated testing of the product program 21 are generally required during the circuit device development process, resulting in a large number of versions of the product program 21.

The off-line software in-loop method adopted in the related art automatically generates program codes through a control model, and is not easy to perform version management.

The invention does not need to automatically generate program codes through a control model, and the product programs 21 of each version are in a text format, thereby being convenient for version management.

Please further refer to fig. 3A, fig. 3B, fig. 3C, fig. 4A and fig. 4B. FIG. 4A is a flowchart of an off-line software-in-loop simulation method according to an embodiment of the present invention. FIG. 4B is a flowchart of compiling according to an embodiment of the invention.

The off-line software-in-loop simulation method of the embodiments of the invention can be realized by the development system of the embodiments of the invention.

The off-line software on-loop simulation method of the present embodiment mainly includes steps S10 to S12.

In step S10, the development system obtains the product program 21 and the setting header file 20, and sets the operation mode based on the setting header file 20.

In one embodiment, the developer can set the operation mode in the setting header file 20 to be the product mode or the virtual mode.

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

In one embodiment, in the product mode, the compiler may be physically provided by development software corresponding to the controller chip 31.

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

Referring to FIG. 4B, in one embodiment, the step of executing the compiler may include steps S20-S22.

In step S20, at the stage before generating the executable file (Pre-build), the development system searches the linked handler 301 from the database 1 based on the set header file 20, and adds the handler 301 to the hardware abstraction layer 101.

In step S21, at the stage of generating the executable file (Build), the development system compiles and links the application layer 100 and the hardware abstraction layer 101 of the generic firmware architecture 10 by a compiler to generate the executable chip control program 11.

In step S22, at the stage after generating the executable file (Post-build), the development system provides the chip control program 11 to the physical controller chip 31 or the circuit simulation software.

For example, in the product mode, the development system may implant the chip control program 11 into the physical controller chip 31.

In another example, in the virtual mode, the development system may import the dynamic link library 35 with the chipset control program 11 to the virtual controller chipset 34 of the circuit simulation software.

Referring back to fig. 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 circuit by controlling the peripheral module.

Please further refer to fig. 5, fig. 6 and fig. 7 for explaining the product mode of the present invention. FIG. 5 is a diagram of the compiler architecture of a product schema according to an embodiment of the present invention. FIG. 6 is an execution architecture diagram of a product model according to an embodiment of the invention. FIG. 7 is a flow chart of a product model according to an embodiment of the invention.

In order to make the development system execute the product mode, the developer may set the operation mode to the product mode in the setting header file 20, select the physical controller chip 31, and select the physical peripheral modules 32 required by the product program 21.

In one embodiment, the application layer 100 may include one or more peripheral initialization programs 22, each peripheral initialization program 22 being used to initialize a corresponding processing program 301 during execution.

In the compiling process, the compiler links each peripheral initialization program 22 to the processing program 301 of the corresponding physical peripheral module 32.

The present invention can set the usage of the physical peripheral module 32 according to the product requirement by configuring the peripheral initialization program 22.

In one embodiment, the developer may link the peripheral initialization program 22 corresponding to the processing program 301 with the configuration header file 20, so that the peripheral initialization program 22 is added to the application layer 100 during compiling.

In one embodiment, the development system further comprises development software for performing the compilation. The aforementioned development software corresponds to the currently employed entity controller chip 31, for example, a development tool provided for the supplier of the entity controller chip 31.

In one embodiment, the development system may be connected to the entity controller chip 31, burn the chip control program 11 into the entity controller chip 31, and start the chip control program 11 in the entity controller chip 31, so that the entity controller chip 31 controls the entity product related circuit 33 by controlling the entity peripheral module 32.

Referring to fig. 6, in the example of fig. 6, the product program 21 can provide a plurality of control functions (e.g., sub-control programs), which are power monitoring 41, fan speed control 42, LED control 43, external overcurrent protection 44, and digital closed loop control 45.

During execution, the configuration header file 20 provides parameter values to the product program 21 and the peripheral initialization program 22.

The plurality of peripheral initialization programs 22 can be used to initialize the plurality of processing programs 301, respectively.

The control functions of the product program 21 can control the corresponding physical peripheral modules 32 through the processing programs 301, so as to control the physical product-related circuits 330-333 through controlling the physical peripheral modules 32.

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

Next, the entity-product related circuit 331 adjusts the magnitudes of the voltage signal v1 and the current signal i1 to generate a voltage signal v2 and a current signal i2, and transmits the voltage signal v2 and the current signal i2 to another entity peripheral module 32 (e.g., an analog/digital conversion module), so that the digital closed-loop controller 45 determines the next pwm control signals pwm1 and pwm2 according to the digital values of the voltage signal v2 and the current signal i 2.

Thereby, the external overcurrent protection 44 can monitor the digital value of the current signal i2 to determine whether to trigger the overcurrent protection.

In another example, the fan speed control 42 may control the corresponding physical peripheral module 32 (e.g., the pwm module) to send the pwm control signal pwm3 to the physical product-related circuit 332 (e.g., the fan control circuit) through the corresponding processing program 301, so that the physical product-related circuit 332 adjusts the fan speed based on the pwm control signal pwm3 and transmits the adjustment result (the speed signal tacho 1) to another physical peripheral module 32 (e.g., the speed signal receiving module), so that the fan speed control 42 may obtain the adjustment result through the corresponding another processing program 301 for the speed feedback control.

In another example, the LED controller 43 may control the corresponding physical peripheral module 32 (e.g., the LED control module and the analog/digital conversion module) to send the 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 LED 1.

Referring to fig. 7, the off-line software in the present embodiment can perform steps S30-S33 in the product mode of the ring simulation method.

In step S30, the development system acquires the setting header file 20. The aforementioned setting header file 20 is already set by the developer.

Specifically, the developer may perform the following steps S40-S41 to set the aforementioned setting header file 20.

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 from the setting header file 20.

In step S41, the developer sets the operation mode as the product mode in the setting header file 20.

In step S31, the developer executes the compiler in the development software corresponding to the entity controller chip 31 to compile the program code 2 of the general firmware architecture 10 to obtain the chip control program 11. The compiler may, for example, execute the contents of the steps S20-S22, which is not described herein again.

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

In step S32, the development system starts the chip control program 11 burned into the physical controller chip 31.

In step S33, the physical controller chip 31 controls the physical product related circuit 33 by executing the chip control program 11 to control the physical peripheral module 32.

Therefore, the present invention enables the product program 22 to control the physical peripheral module 32 of the physical controller chip 31, and further control the physical product related circuit 33.

Please further refer to fig. 8, 9 and 10 for illustrating the virtual model of the present invention. FIG. 8 is a diagram of the compiler architecture of a virtual schema in accordance with an embodiment of the present invention. FIG. 9 is a diagram of an execution architecture of a virtual model according to an embodiment of the present invention. FIG. 10 is a flowchart illustrating a virtual mode according to an embodiment of the invention.

In order to make the development system execute the virtual mode, the developer can set the operation mode to the virtual mode in the setting header file 20, select the circuit simulation software, select the virtual controller chip 35 to be simulated, and select the virtual peripheral module 36 required by the product program 21.

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

In one embodiment, the application layer 100 of the generic firmware architecture 10 may include a Non-Preemptive Scheduler (NPS) 23, wherein the Non-Preemptive Scheduler 23 is added to the application layer 100 during compilation.

In one embodiment, the circuit simulation software may activate the chip control program 11 to trigger the non-preemptive scheduler 23 when executing, so as to simulate the hardware interrupt/non-interrupt behavior in a software manner.

The virtual mode of the present invention mainly tests and verifies the control function of the product program 21 by pure software, thereby verifying whether the product program 21 has a design defect.

It should be noted that, in the virtual mode, since the physical controller chip 31 is not connected, no interrupt event caused by hardware occurs, which may result in the simulation being not realistic enough.

To solve the hardware interrupt handling problem in the virtual mode, the general firmware architecture 10 of the present embodiment further includes a non-preemptive scheduler 23. The non-preemptive scheduler 23 is used to simulate a program interrupt.

In one embodiment, the non-preemptive scheduler 23 is a software scheduling manager that is only activated when executing the virtual mode. The non-preemptive scheduler 23 may periodically invoke software functions (interrupt service routine and non-interrupt service routine) written in the chip of the controller chip through a Dynamic-Link Library (DLL) 35, thereby solving the problem that the circuit simulation software cannot simulate the interrupt handling behavior of the physical controller chip. The dynamic link library 35 is obtained by compiling the program code 2 of the generic firmware architecture 10, and includes the chip control program 11.

In one embodiment, the circuit simulation software may set the parameters of the non-preemptive scheduler 23 during execution, and perform interrupt/non-interrupt processing by the non-preemptive scheduler 23.

In one embodiment, the circuit simulation software may include periodic interrupt service routine, aperiodic interrupt service routine, and non-interrupt service routine. The non-preemptive scheduler 23 is used to execute the aforementioned periodic interrupt service routine, non-periodic interrupt service routine and non-interrupt service routine to simulate periodic interrupt, non-periodic interrupt and non-interrupt.

In one embodiment, the circuit simulation software may control the virtual peripheral module 36 through the non-preemptive scheduler 23 to control the virtual product related circuit 37 every time the set reference frequency occurs.

Referring to fig. 9, in the example of fig. 9, the product program 21 can provide a plurality of control functions (e.g., sub-control programs), which are power monitoring 41, fan speed control 42, LED control 43, external overcurrent protection 44, and digital closed loop control 45. Various control functions are triggered to execute by the non-preemptive scheduler 23.

The control functions of the product program 21 control the corresponding virtual peripheral modules 36 by the processing programs 301, and thereby control the virtual product-related circuits 37 by controlling the virtual peripheral modules 36.

For example, the digital closed-loop control 45 may control the corresponding virtual peripheral module 360 (e.g., a virtual input/output signal module) to send the adjustment control signal 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 the PWM 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 the voltage signal v3 and the current signal i3 to the virtual product-related circuit 371.

Then, the virtual product related circuit 371 adjusts the multiplying power of the voltage signal v3 and the current signal i3 to generate a voltage signal v4 and a 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/digital conversion module).

Then, 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.

The digital closed-loop control 45 determines a new control signal duty1 according to the digital voltage signal v5 and the digital current signal i 5. The external overcurrent protection 44 may determine whether to trigger the overcurrent protection by monitoring the digital value obtained by the virtual peripheral module 360 through the corresponding another processing program 301.

In another example, the fan speed control 42 may control the corresponding virtual peripheral module 360 to send the adjustment control signal duty2 to the virtual product-related circuit 372 (e.g., the virtual fan control circuit) through the corresponding processing program 301, so that the virtual product-related circuit 372 simulates the adjustment of the fan speed based on the adjustment control signal duty2 and virtually transmits the adjustment result (the speed signal tacho 2) to the virtual peripheral module 360, so that the fan speed control 42 may obtain the adjustment result through the corresponding processing program 301 for speed feedback control.

In another example, the LED control 43 may control the corresponding virtual peripheral module 360 to send the 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 adjust the LED brightness based on the digital LED control signal LED 2.

Referring to fig. 10, the offline software in the present embodiment can perform steps S50-S53 in the virtual mode according to the ring simulation method.

In step S50, the development system acquires the setting header file 20. The aforementioned setting header file 20 is already set by the developer.

Specifically, the developer may perform the following steps S60-S61 to set the aforementioned setting header file 20.

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

In one embodiment, the developer may further select the virtual controller chip 35 and the desired virtual peripheral module 36 in the circuit simulation software.

In step S61, the developer sets the operation mode as the virtual mode in the setting header file 20.

In step S51, the development system uses the compiler to compile the environment provided by the circuit simulation software, so as to obtain the chip control program 11. The compiler may, for example, execute the contents of the steps S20-S22, which is not described herein again.

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

Then, the development system can update the dynamic link function library 35 with the chip control program 11 to the virtual controller chip 35 provided by the circuit simulation software.

In step S52, the development system activates the chip control program 11 in the dynamic link function library 35 updated to the virtual controller chip 35 provided by the circuit simulation software to trigger the non-preemptive scheduler 23.

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

Therefore, the invention can realize the software-in-loop simulation of the product program 21 in the circuit simulation software.

Please further refer to fig. 11 to fig. 15. FIG. 11 is an architecture diagram of a hardware abstraction layer according to an embodiment of the present invention. FIG. 12 is a diagram illustrating a data link of a generic firmware architecture according to an embodiment of the invention.

Fig. 13 is a partial schematic view of a setting header file according to an embodiment of the invention. Fig. 14 is a schematic diagram illustrating a processing procedure of the controller chip according to an embodiment of the invention. FIG. 15 is a partial schematic diagram of a processing procedure of circuit-based phantom software according to an embodiment of the invention.

In one embodiment, as shown in FIG. 11, the hardware abstraction layer 101 may include a plurality of header files. Each header file is used for setting and connecting the processing program of the corresponding peripheral module.

In one embodiment, as shown in FIG. 12, in the application layer 100, the product program may include a hardware abstraction layer header file cfa _ hal.h via an instruction # include "cfa _ hal.h".

In the application layer cfa _ hal.h, the product program may include a set header file cfa _ hal _ config.h via an instruction # include "cfa _ hal _ config.h". Setting the header file cfa _ hal _ config.h may provide the execution parameters to the product program.

Also, for example, in configuring an ADC (analog/digital converter), the product program may establish a data flow with an ADC processing procedure cfa _ ADC _28035.c of the hardware abstraction layer, and establish a data flow with a peripheral module (e.g., an ADC module) through the ADC processing procedure cfa _ ADC _ 28035.c.

Additionally, the ADC handler cfa _ ADC _28035.C may include a hardware abstraction layer header file cfa _ hal.h by an instruction # include "cfa _ hal.h".

In a hardware abstraction layer header file cfa _ hal.h of the hardware abstraction layer, the ADC handler cfa _ ADC _28035.c may include the ADC header file cfa _ adc.h by an instruction # include "cfa _ adc.h".

In the ADC header file cfa _ adc.h of the hardware abstraction layer, the ADC handler cfa _ ADC _28035.c may wrap the controller chip header file cfa _ ADC _28035.h with an instruction # include "cfa _ ADC _ 28035.h".

Thereby, the product program can control the peripheral modules (ADC modules) through the controller chip (such as TI TMS320F28035 control chip).

In one embodiment, as shown in fig. 13, the developer can set the parameter in the setting header file cfa _ hal _ config.h.

The parameter contents may include: a current operating mode, a product mode or a virtual mode; the manufacturer, model and compiler used of the entity control chip under the product mode; the circuit simulation software in the virtual mode and the compiler used are not limited.

For example, the parameters may be set to: a product mode; the physical controller chip is a control chip TI TMS320F28035; the compiler is C2000.

In another example, the parameters may be set as: a virtual mode; the circuit simulation software is S-function of SIMULINK; the compiler is MinGW-w64.

For example, as shown in FIG. 14, in product mode, the set header file may be coupled to the process cfa _ adc _28035.C to make the chip control process compatible with the current physical controller chip.

In another example, as shown in fig. 15, in the virtual mode, the set header file may be connected to the processing program cfa _ adc _ simulink.c to make the chip control program compatible with the current circuit simulation software.

Please refer to fig. 2 to 16. Fig. 16 is a flow diagram of non-preemptive scheduling in accordance with an embodiment of the present invention.

The off-line software loop simulation method of this embodiment can simultaneously execute steps S70-S72 to provide the interrupt/non-interrupt processing function when executing the chip control program.

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

In one embodiment, when there are a plurality of periodic interrupt service routines having different periodic interrupt frequencies, the development system may determine the reference frequency, such as the minimum value, the maximum value, or the average value, based on the plurality of periodic interrupt frequencies.

In one embodiment, the development system selects the highest frequency among the plurality of periodic interrupt frequencies as the reference frequency.

For example, if the plurality of periodic interrupt frequencies are 5KHz, 200KHz, and 1KHz, the non-preemptive scheduler 23 may select 200KHz as the trigger frequency.

Then, the development system may set a non-interrupt trigger period for a non-interrupt counter for the non-interrupt service routine based on the reference frequency.

In addition, the development system may set an aperiodic interrupt trigger period to an aperiodic interrupt counter for an aperiodic interrupt service routine based on the reference frequency.

For example, if the reference frequency is 100KHz, the non-interrupt frequency is desirably set to 50KHz, and the aperiodic interrupt service frequency is desirably set to 10KHz, the non-interrupt trigger period may be set to 2 (i.e., one non-interrupt is performed every two occurrences of the reference frequency), and the aperiodic interrupt trigger period may be set to 10 (i.e., one aperiodic interrupt is performed every ten occurrences of the reference frequency).

In step S71, the development system executes the interrupt/non-interrupt program processing by the non-preemptive scheduler 23.

In one embodiment, the interrupt/non-interrupt processing includes executing a periodic interrupt service routine, a non-periodic interrupt service routine, and a non-interrupt service routine.

Specifically, program execution has three interrupt mechanisms, namely, a non-interrupt service routine (e.g., polling), a periodic interrupt service routine (periodic ISR), and a non-periodic ISR.

In the product mode, the physical controller chip 31 may perform the aforementioned interrupt processing.

In the virtual mode, the present invention simulates the execution of the interrupt processing by the non-preemptive scheduler 23.

Step S71 may include steps S80-S82 to process the three interrupt mechanisms.

In step S80, the development system executes the non-interrupt service program to process the non-interrupt event.

In step S81, the development system executes the periodic interrupt service routine to process the periodic interrupt event.

In step S82, the development system executes the aperiodic interrupt service to handle the aperiodic interrupt event.

In step S72, the development system determines whether to end the interrupt/non-interrupt processing.

If execution is finished, the method is ended.

If the execution does not need to be finished, step S71 is executed again to continue the repeated execution of the interrupted/uninterrupted program process based on the reference frequency.

Therefore, the invention detects the non-interrupt event and the non-periodic interrupt event in a round-robin mode, and can effectively simulate the hardware interrupt in a pure software environment.

Please refer to fig. 2 to 17. FIG. 17 is a flowchart of an interrupt/non-interrupt process according to an embodiment of the present invention.

In the present embodiment, the non-preemptive scheduler 23 repeatedly executes step S71 (i.e., interrupt/non-interrupt program processing) shown in fig. 16 at the reference frequency. Compared with the embodiment of FIG. 16, the interrupted/uninterrupted program processing of the present embodiment may comprise the following steps S90-S97.

In step S90, the non-preemptive scheduler 23 controls the non-interrupt counter and the aperiodic interrupt counter to count, such as increment by 1 or decrement by 1.

In step S91, the non-preemptive scheduler 23 processes the periodic interrupt event corresponding to the reference frequency.

After step S91, the non-preemptive scheduler 23 may execute the interrupt/non-interrupt process again.

In step S92, the non-preemptive scheduler 23 determines whether the value of the non-interrupt counter satisfies the non-interrupt trigger period.

If yes, the non-preemptive scheduler 23 executes step S93; if not, the process is finished.

In step S93, the non-preemptive scheduler 23 processes the non-interrupt event.

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.

After step S94, the non-preemptive scheduler 23 may execute the interrupt/non-interrupt processing again.

In step S95, the non-preemptive scheduler 23 determines whether the value of the aperiodic interrupt counter satisfies the set aperiodic interrupt trigger period.

If yes, the non-preemptive scheduler 23 executes step S96; if not, the process is finished.

In step S96, the non-preemptive scheduler 23 processes the aperiodic interrupt event.

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.

After step S97, the non-preemptive scheduler 23 may execute the interrupt/non-interrupt processing again.

Therefore, the invention can simulate hardware interruption to obtain a more accurate simulation result.

The above description is only a preferred embodiment of the present invention, and not intended to limit the scope of the present invention, so that equivalent variations using the teachings of the present invention are all included within the scope of the present invention, and it is obvious that the present invention is not limited thereby.

Claims

1. An off-line software-in-the-loop simulation development system, comprising:

a database including at least one chip peripheral function library, each chip peripheral function library including at least one processing program; and

a generic firmware architecture for generating a chip control program after being compiled, the generic firmware architecture comprising:

an application layer including a product program and a set header file, wherein the product program records program codes for controlling a product-related circuit, and the set header file is used for connecting 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 in compilation according to the peripheral module to be controlled by a specific entity controller chip or a circuit simulation software;

the chip control program is provided to the physical controller chip or the circuit simulation software for execution, and controls the peripheral module to control the product-related circuit.

2. The development system of claim 1, further comprising a development software for performing the compilation, the development software corresponding to the physical controller chip;

wherein, in the setting header file, the operation mode is set as a product mode, and the physical controller chip and a required physical peripheral module are selected;

the development system is used for connecting the entity controller chip and controlling a relevant circuit of an entity product by controlling the entity peripheral module by starting the chip control program which is burned to the entity controller chip.

3. The development system of claim 1, further comprising the circuit simulation software for simulating a virtual controller chip, a virtual peripheral module of the virtual controller chip, and a virtual product-related circuit;

wherein, in the setting header file, the operation mode is set as a virtual mode, and the circuit simulation software is selected;

wherein the application layer further comprises a non-preemptive scheduler, the non-preemptive scheduler being added to the application layer during compilation;

wherein, the circuit simulation software is used for starting the chip control program to trigger the non-preemptive scheduler when executing;

the non-preemptive scheduler is used for triggering the product program during execution, and the chip control program is used for controlling the virtual peripheral module so as to control the virtual product related circuit.

4. The development system of claim 3 wherein said circuit emulation software is adapted to set parameters of said non-preemptive scheduler when executing and to perform an interrupt/non-interrupt process through said non-preemptive scheduler.

5. The development system of claim 4 wherein the circuit emulation software further comprises a periodic interrupt service routine, a non-periodic interrupt service routine, and a non-interrupt service routine;

the non-preemptive scheduler is configured to execute the periodic interrupt service routine, the aperiodic interrupt service routine, and the non-interrupt service routine.

6. The development system of claim 4 wherein the non-preemptive scheduler is configured 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 4 wherein the non-preemptive scheduler is configured to select a highest frequency among the plurality of periodic interrupt frequencies as a reference frequency and to repeatedly execute the interrupt/non-interrupt process 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;

the non-preemptive scheduler is used for controlling the non-interrupt counter and the non-periodic interrupt counter to count each time when the interrupt/non-interrupt program is executed, processing a periodic interrupt event, processing a non-interrupt event and resetting the non-interrupt counter when the value of the non-interrupt counter meets a non-interrupt trigger period, and processing a non-periodic interrupt event and resetting the non-interrupt counter when the value of the non-periodic interrupt counter meets a non-periodic interrupt trigger period.

9. The development system of claim 1 wherein the application layer further comprises a peripheral initialization program added to the application layer at compile time and used to initialize the handler at execution time;

the setting header file is used for connecting the peripheral initialization program corresponding to the processing program.

10. The development system of claim 1, further comprising:

a memory for storing the database and the generic firmware architecture; and

a processor electrically connected to the memory for executing programs.

11. An off-line software-in-the-loop simulation method, comprising:

a) Obtaining a product program and a set header file, wherein the product program records program codes for controlling a product-related circuit, the set header file is used for connecting a processing program required by a peripheral module, and the processing program is used for controlling the peripheral module in an entity controller chip or a circuit simulation software;

b) Executing a compiler to compile the product program and the set 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) comprises:

b1 Searching the handler from a database based on the set header file and adding the handler 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 set header file; and

b3 Provide the chip control program to the physical controller chip or the circuit simulation software.

12. The off-line software-in-loop simulation method of claim 11, wherein in the set header file, the operation mode is set to a product mode, the physical controller chip and a desired physical peripheral module are selected;

step b) includes executing the compiler in a development software corresponding to the physical controller chip;

wherein step c) comprises:

c1 Starting the chip control program burned to the physical controller chip; and

c2 The physical controller chip executes the chip control program to control the physical peripheral module to control a physical product-related circuit.

13. The offline software-on-loop simulation method of claim 11, wherein in the set header file, the operation mode is set to a virtual mode, the circuit simulation software is selected;

step b) further comprises executing the compiler in an environment provided by the circuit simulation software;

wherein step c) comprises:

c3 Starting the chip control program updated to a virtual controller chip provided by the circuit simulation software to trigger a non-preemptive scheduler; and

c4 In the circuit simulation software, the non-preemptive scheduler triggers the product program to control a virtual peripheral module to control a virtual product-related circuit through the chip control program.

14. The off-line software-in-the-loop simulation method of claim 13, wherein step c 4) comprises:

c41 Setting parameters of the non-preemptive scheduler; and

c42 Execute an interrupt/non-interrupt process by the non-preemptive scheduler.

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

16. The off-line software-in-the-loop simulation method of claim 14, wherein step c 41) comprises:

c411 Determining a reference frequency based on a plurality of periodic interrupt frequencies;

c412 Setting a non-interrupt trigger period for a non-interrupt counter based on the reference frequency; and

c413 Set an aperiodic interrupt trigger period for an aperiodic interrupt counter based on the reference frequency.

17. The off-line software-in-loop simulation method of claim 16, wherein step c 411) comprises selecting a highest frequency among the plurality of periodic interrupt frequencies as the reference frequency.

18. The off-line software-in-loop simulation method of claim 14, wherein step c 42) comprises repeatedly performing the interrupt/non-interrupt routine processing at a reference frequency.

19. The off-line software-in-loop simulation method of claim 18, wherein the interrupt/non-interrupt routine processing comprises:

d1 Control a non-interrupt counter and a non-periodic interrupt counter count:

d2 Processing a periodic interrupt event;

d3 When the value of the non-interrupt counter satisfies a non-interrupt trigger period, processing a non-interrupt event and resetting the non-interrupt counter; and

d4 When the value of the aperiodic interrupt counter satisfies an aperiodic interrupt trigger period, an aperiodic interrupt event is processed and the non-interrupt counter is reset.

20. The off-line software-in-loop simulation method of claim 19, wherein step d 1) comprises incrementing or decrementing the value of the non-interrupt counter and the value of the aperiodic interrupt counter.