CN116450109A - Modbus communication library adaptation method under MATLAB and CCS combined development mode - Google Patents
Modbus communication library adaptation method under MATLAB and CCS combined development mode Download PDFInfo
- Publication number
- CN116450109A CN116450109A CN202310577741.5A CN202310577741A CN116450109A CN 116450109 A CN116450109 A CN 116450109A CN 202310577741 A CN202310577741 A CN 202310577741A CN 116450109 A CN116450109 A CN 116450109A
- Authority
- CN
- China
- Prior art keywords
- modbus
- driving
- module
- code
- codes
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
- 230000006854 communication Effects 0.000 title claims abstract description 49
- 238000004891 communication Methods 0.000 title claims abstract description 48
- 238000000034 method Methods 0.000 title claims abstract description 36
- 238000011161 development Methods 0.000 title claims abstract description 25
- 230000006978 adaptation Effects 0.000 title claims abstract description 9
- 238000004806 packaging method and process Methods 0.000 claims abstract description 9
- 230000008569 process Effects 0.000 claims abstract description 9
- 230000006870 function Effects 0.000 claims description 21
- 230000004044 response Effects 0.000 claims description 10
- 238000001514 detection method Methods 0.000 claims description 8
- 230000002093 peripheral effect Effects 0.000 claims description 8
- 230000003993 interaction Effects 0.000 claims description 6
- 230000010354 integration Effects 0.000 abstract 1
- 238000013461 design Methods 0.000 description 4
- 238000012360 testing method Methods 0.000 description 4
- 230000005540 biological transmission Effects 0.000 description 2
- 230000008859 change Effects 0.000 description 2
- 238000005538 encapsulation Methods 0.000 description 2
- 230000006872 improvement Effects 0.000 description 2
- 238000012545 processing Methods 0.000 description 2
- 230000009286 beneficial effect Effects 0.000 description 1
- 125000004122 cyclic group Chemical group 0.000 description 1
- 238000010586 diagram Methods 0.000 description 1
- 238000005516 engineering process Methods 0.000 description 1
- 238000004088 simulation Methods 0.000 description 1
- 238000006467 substitution reaction Methods 0.000 description 1
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/30—Creation or generation of source code
- G06F8/31—Programming languages or programming paradigms
- G06F8/315—Object-oriented languages
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/30—Creation or generation of source code
- G06F8/35—Creation or generation of source code model driven
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/30—Creation or generation of source code
- G06F8/37—Compiler construction; Parser generation
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- General Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Computing Systems (AREA)
- Communication Control (AREA)
Abstract
The invention discloses a Modbus communication library adaptation method under a MATLAB and CCS combined development mode, which comprises the steps of compiling a Modbus driving code unit, creating a Simulink module for the Modbus driving code unit by using a code inheritance tool, and setting codes related to DSP hardware driving to be free from compiling and completely reserved in the creation process; after the creation is completed, restoring codes related to DSP hardware driving to an executable state, and packaging a plurality of created Modbus driving modules to form a Modbus driving module library; and calling a module in the Modbus driving module library in the Simulink to build a Modbus communication model and generate codes, and deploying the modules in the Modbus driving module library into the DSP. The method can get rid of the limitation of hardware resources provided by MATLAB for DSP development, and communication development based on Modbus can be rapidly completed based on autonomous writing of Modbus driving codes, and has the advantages of high development efficiency, easiness in integration and the like.
Description
Technical Field
The invention relates to the field of model-based design and automatic code generation, in particular to a Modbus communication library adaptation method under a MATLAB and CCS joint development mode.
Background
At present, the combined development mode of MATLAB and CCS is based on a hardware support package jointly developed by TI company and MathWorks company, and a new way is developed for embedded development: executable code of the DSP may be generated directly from the Simulink model. Compared with an embedded software development mode for editing the C code, the method has the advantages that the visibility is higher, the portability is stronger, the logic can be simulated on the Simulink, and the test work is simplified. MATLAB provides a matched hardware support package for DSP bottom layer drive development, and provides support for hardware support package and target code generation of a self-contained Simulink module, but lacks direct support for peripheral development requirements in embedded development. The development of the DSP in MATLAB is not specific to the corresponding support packet of the Modbus protocol, and the building of the Modbus communication model cannot be completed by directly utilizing the module in the Simulink.
In the patent with the application number of CN201310675197.4, named "method for implementing MODBUS asynchronous serial communication protocol with DSP", the development of MODBUS protocol with DSP as a core is performed in a programming manner, which requires that the programmer be skilled in the characteristics and structure of hardware and its dedicated programming language, and has a great difficulty. In the patent with the application number of 201810144868.7 and the name of a method for generating codes by utilizing a bottom layer driver of a Simulink custom singlechip, a bottom layer module library based on an automatic code generation technology is designed by writing an S function script and a TLC file for generating codes, so that the aim of packaging handwritten codes into Simulink modules in MATLAB is fulfilled. However, the method still needs to understand the S function and TLC file structure, and needs to manually write some configuration files on the basis; and cannot handle cases where the code cannot be compiled when there are associated hardware registers in the code.
In order to solve the problem that in the current process of developing a DSP based on a model design method, the Modbus communication model building cannot be completed by directly utilizing a module in the Simulink due to the limitation of hardware resources provided by the Simulink for DSP development, a Modbus communication library adaptation method in a MATLAB and CCS combined development mode is needed to support the rapid development of Modbus communication functions on the DSP.
Disclosure of Invention
In view of the above, the present invention aims to provide a method for adapting a Modbus communication library in a combined MATLAB and CCS development mode, so as to solve the problem that in the current process of developing a DSP based on a model design method, the module in the Simulink cannot be directly used to quickly complete the establishment of a Modbus communication model due to the limitation of hardware resources provided by the Simulink for DSP development.
The invention relates to a Modbus communication library adapting method under the combined development mode of MATLAB and CCS,
step 1, writing Modbus driving codes to obtain Modbus driving code units, wherein the codes comprise codes related to DSP hardware driving;
step 2, calling a code inheritance tool to create a Simulink module for the Modbus driving code unit, and setting codes related to DSP hardware driving to a compiling-free state and completely reserving the codes in the creating process;
after the creation is completed, restoring codes related to DSP hardware driving into an executable state, and packaging the created Modbus driving modules to obtain a plurality of packaged Modbus driving modules corresponding to Modbus driving code units to form a Modbus driving module library;
and step 3, calling a module in the Modbus driving module library in the Simulink to build a Modbus communication model and generate codes, and deploying the Modbus communication model and the codes into the DSP.
Further, in the step 2, a code inheritance tool LCT is called to create a Modbus driving module for the Modbus driving code unit.
Further, the Modbus driving module encapsulated in the step 2 has a corresponding user interaction interface.
Further, the code related to hardware driving is code related to operation of related peripheral registers in the DSP.
Further, the step 2 specifically includes:
step 2.1, setting codes related to hardware driving in a Modbus driving code unit as notes, so that the codes are free from compiling;
step 2.2, calling a code inheritance tool LCT to initialize a function written in a C language in a Modbus driving code unit into an LCT structure body, and designating parameters of the LCT structure body;
step 2.3, calling a code inheritance tool LCT to generate an S-Function source file for the Function, compiling and linking the S-Function source file to generate a mexw64 executable file, and further creating a Modbus driving module for building and simulating a Simulink model;
step 2.4, calling a code inheritance tool to generate a tlc file required by generating a model code subsequently;
step 2.5, restoring the annotated codes related to the hardware driving part;
step 2.6, repeatedly executing the sub-steps on all code units of the driving module to be created;
and 2.7, packaging the created Modbus driving modules, and arranging and archiving the packaged Modbus driving modules to form a Modbus driving module library.
Further, in step 2.1, the function definition part in the source file annotates all the code segments in the function body; only a conditional compiling part for avoiding redefinition of the header file is reserved in the header file, and all the rest is annotated.
Further, the Modbus driving code unit comprises an initialization unit and a data receiving and transmitting unit;
the initialization unit comprises a parameter configuration module and a port initialization module;
the data receiving and transmitting unit comprises a data receiving module, a receiving timeout detection module, a message frame analysis and slave response module;
the parameter configuration module is used for distributing storage space and configuring equipment addresses; the resource size required by each storage block is configured in the allocation of the storage space; the equipment address configuration designates the ID of the slave equipment as the unique identification of the slave equipment in the communication network;
the port initialization module is used for initializing the port, and initializing the serial port peripheral equipment and the GPIO corresponding to the DSP according to the selected port mode;
the data receiving module is invoked in the serial port receiving interrupt, receives a single character when the receiving interrupt comes, and stores the single character in the message buffer area;
the receiving timeout detection module is invoked in the timer interrupt, and the module judges the time interval condition of the received characters by using a timer so as to judge the termination of a frame of information;
the message frame analysis and slave response module is invoked in the idle task block and is used for analyzing the received complete message frame and returning a response after the complete message frame is received by the slave device.
Further, the port mode comprises three types of RS485, RS232 and RS485 and RS 232;
further, the data receiving module comprises an RS485 data receiving module and an RS232 data receiving module.
The invention has the beneficial effects that: the Modbus communication library adaptation method provided by the invention can get rid of the limitation of hardware resources provided by MATLAB for DSP development, and realizes the rapid completion of communication development based on Modbus by utilizing special processing in the module creation process based on the Modbus driving code independently written, and simultaneously can realize the independent customization of the Modbus communication function module to meet various communication requirements.
Drawings
Fig. 1 is a flowchart of a Modbus communication library adapting method in a MATLAB and CCS joint development mode in an embodiment of the present invention;
FIG. 2 is a schematic diagram of a Modbus driver code Unit according to an embodiment of the present invention;
fig. 3 is a flowchart illustrating a step of S21 in fig. 1 to call LCT to create a Modbus driver module for a Modbus driver code unit.
Detailed Description
The invention is further described below with reference to the drawings and examples.
The specific implementation mode provided by the invention is based on a DSP28335 hardware platform and a MATLAB software platform, and is described by combining with a Modbus communication application example of an RS485 bus.
The invention discloses a Modbus communication library adaptation method under a MATLAB and CCS joint development mode, referring to FIG. 1, comprising the following steps of S1 to S4:
s1, independently writing Modbus driving codes to obtain Modbus driving code units. Referring to fig. 2, an embodiment of a Modbus driver code unit includes an initialization unit 1 and a data transceiver unit 2. The initialization unit 1 comprises a Libmodbus Parameter parameter configuration module 11 and a LibModbus Init port initialization module 12; the data transceiver unit 2 comprises LibModbus Receive RS232/RS485 data receiving modules 21 and LibModbus Timer Step, a timeout detection module 22 and a LibModbus Thread message frame analyzing and slave response module 23.
The Libmodbus Parameter parameter configuration module 11 is used for allocating storage space and configuring equipment addresses. The Modbus protocol allows devices to map four different data types into separate memory blocks and access the different types of data using different function codes. The resource size required by each storage block is configured in the allocation of the storage space; the device address configuration specifies a slave device ID as a unique identification of a slave device in the communication network.
The LibModbus Init port initializing module 12 is used for port initialization, three modes including RS485, RS232, RS485 and RS232 can be selected, and the module initializes the serial port peripheral and GPIO corresponding to the DSP according to the selected port.
The LibModbus Receive RS/RS 485 data receiving module 21 is called in the serial port receiving interrupt, and is divided into an RS485 data receiving module and an RS232 data receiving module according to a hardware interface circuit of communication, and single characters are received temporarily and stored in a message buffer area when the receiving interrupt occurs.
The LibModbus Timer Step receive timeout detection module 22 invokes in a timer interrupt to determine a data timeout condition. In a frame complete data reception, the entire data frame must be transmitted as a continuous stream. The time interval between two complete message frames is greater than 3.5 characters, and the receiving timeout detection module judges the termination of a frame of message according to the time interval condition of receiving characters. In this module, if the reception interval time is detected to exceed 4 system step times, it is determined to determine termination of one frame message.
The LibModbus Thread message frame parsing and slave response module 23 invokes in the idle task block of Simulink. After receiving the complete message frame, the slave station analyzes the received complete message frame and returns a response. The specific operation is as follows: judging whether the ID number in the received message frame accords with the slave device or not, directly ignoring the received message frame if the ID number does not accord with the slave device, otherwise, performing CRC (cyclic redundancy check) on the data frame to prevent the slave device from responding to the message frame with transmission errors in the communication process. The data segment in the message frame contains additional information of the slave to execute the function, analyzes the data segment, and returns a response frame packaged according to a specific format to respond to the master station request.
S2, calling a code inheritance tool to create a Simulink module for the Modbus driving code unit, and setting codes related to DSP hardware driving to a compiling-free state and completely reserving the codes in the creation process; after the creation is finished, restoring codes related to DSP hardware driving to an executable state, and packaging to obtain Modbus driving modules corresponding to each Modbus driving code unit to form a Modbus driving module library, wherein the specific steps are as follows:
s21, calling a code inheritance tool LCT of MATLAB to create a Modbus driving module for the Modbus driving code unit in the step S1. Referring to fig. 3, the steps include S211 to S215:
s211, annotating the code related to the hardware drive, so that the part of code is free from compiling. Since the compiler used when the code inheritance tool is a C compiler, and is not a compiler aiming at the target hardware DSP, codes related to GPIO and SCI related peripheral registers defined in the target hardware DSP28335 cannot be compiled, the code related to hardware driving is temporarily annotated, and the code is restored in the subsequent steps, so that the invoking of the code of the hardware driving part is not influenced. The code related to hardware driving is specifically the operation of relevant peripheral registers in the DSP.
As an improvement to the above embodiment, in the concrete implementation, the function definition part in the source file makes all the code segments inside the function body to be annotated; only the conditional compiling part for avoiding redefinition of the header file is reserved in the header file, and all the rest is annotated, so that codes can be analyzed without sentence by sentence to find out exact code lines related to hardware driving, and the method is simpler and faster for operators.
S212, calling a code inheritance tool LCT to initialize an LCT structure body for a function written in a C language, and designating LCT structure body parameters. The LCT structure parameters include: the driver source code and header file path, the S-Function name and the output Function declaration.
S213, calling a code inheritance tool LCT to generate an S-Function source file for the C Function, compiling and linking the S-Function source file to generate a mexw64 executable file, and further creating a driving module for building and simulating a Simulink model.
S214, calling a code inheritance tool LCT to generate a tlc file required by generating a model code later.
S215, after the steps are completed, restoring the code annotated in the step S211.
Before this step, the code related to the hardware driving is set to be free from the compiling state, which allows the above LCT-based step to be smoothly implemented, because if the code related to the hardware driving exists in the code unit based on the existing LCT, the above step may be wrongly reported, resulting in no continuation; on the other hand, the process of creating the module by using the LCT does not actually make any change to the code unit itself, and the compiling process can be understood as a validity check; that is, as long as this check is passed, the code in the code unit will be executed intact in the subsequent packaging, model building, simulation, and deployment steps. Thus, by restoring the code annotated in step S211, it is possible that these codes involving hardware driving are executed in the subsequent steps.
And similarly, repeatedly executing steps S211 to S215 on source files and header files defined by functions of all driving modules to be created until all the functional modules needed in the Modbus communication library are completely created.
S22, module packaging is carried out, and a user interaction interface is designed. And finishing module encapsulation by using a Mask Editor, so that the module has the capability of interacting with a user.
S23, creating a Modbus driving module library. And (3) sorting and archiving all the encapsulated Modbus driving modules, and adding the Modbus driving modules into a Simulink browsing library for repeated calling.
S3, invoking the Modbus driving modules in the Modbus driving module library in the Simulink to build a Modbus communication model and generate codes, and deploying the Modbus communication model and the codes to the DSP28335 hardware test platform, wherein some necessary non-Modbus driving modules can adopt functional modules in a TI C2000 hardware support package. When the Modbus communication model is built, model parameter configuration is needed to be carried out, wherein the model parameter configuration comprises configuration of SCI serial port communication parameters and system step length of the Modbus communication model, and the configuration work can be completed through a user interaction interface added during module encapsulation.
In this embodiment, since the DSP hardware testing platform uses the SCIB extended RS485 communication interface, the SCIB serial communication parameters should be specifically configured, the start bit 1, the data length 8, no parity check, and the stop bit 1, that is, 10 bits are needed for transmitting 1 character data; in this embodiment, SCIB serial port communication baud rate (BaudRate) is set to 115200, and the system step size is set to 0.0001.
As an improvement to the above embodiments, other settings may be used for the system step size setting, and in different embodiments, other parameters may be considered for the SCI serial communication parameters and the system step size. It should be noted that the system Step Size, that is, the timer timing time is related to the timeout processing and the packet operation of the Modbus communication, and in this embodiment, the timeout detection module of the receiving timeout of the Modbus adaptation layer regards an interval time greater than 4 system Step sizes (Fixed Step Size) as a timeout, and the improper configuration of the system Step sizes may affect the normal operation of the Modbus communication. Therefore, the system step size is set to adapt to the variation of the SCI communication parameters, and the following relation should be specifically followed:
Fixed Step Size≥(3.5*N)/(4*Baud Rate)
where N is the number of binary digits required to transmit a character, n=10 in this embodiment.
And S4, connecting the DSP28335 hardware test platform with an upper computer, and observing data interaction under Modbus communication by using MODSAN 32 software.
The configuration of communication parameters in the MODSACN32 software connection setup includes: baud rate, word length, parity and stop bits; the Modbus protocol is selected as a standard RTU transmission mode; the MODSACN32 recognizes a valid COM port to establish a connection.
In this embodiment, the baud rate 115200, word length 8, no parity, and stop bit 1 are configured in the connection setup. It should be noted that this parameter is the same as the serial communication parameter configuring SCIB in step S3.
And observing data interaction in the Simulink through a memory Copy module, and further verifying the correctness of the design of the Modbus driving module. Creating a module with variable data in the timer interrupt, finishing data updating once at intervals, storing the data into an input register of Modbus through a memory Copy module, selecting an equipment ID of RS485 in MODSAN 32 software, calling 04 function code to observe data change, and if the data is found to be updated once at intervals, indicating that the register operation based on Modbus communication can be correctly operated; by modifying the value of the coil register in the MODSAN 32 software, the switch state of the coil is sent to the GPIO through the memory Copy module, the on-off state of the coil is simulated by using the on-board LED lamp on-off condition, and if the on-off state of the lamp can be controlled by changing the value of the coil register in the MODSAN 32 software, the operation of the coil based on Modbus communication can be correctly run.
The present invention is not limited to the above-mentioned embodiments, and any changes or substitutions that can be easily understood by those skilled in the art within the technical scope of the present invention are intended to be included in the scope of the present invention.
Claims (9)
- The Modbus communication library adaptation method under the combined development mode of MATLAB and CCS is characterized by comprising the following steps of:step 1, writing Modbus driving codes to obtain Modbus driving code units, wherein the codes comprise codes related to DSP hardware driving;step 2, calling a code inheritance tool to create a Simulink module for the Modbus driving code unit, and setting codes related to DSP hardware driving to a compiling-free state and completely reserving the codes in the creating process;after the creation is completed, restoring codes related to DSP hardware driving into an executable state, and packaging the created Modbus driving modules to obtain a plurality of packaged Modbus driving modules corresponding to Modbus driving code units to form a Modbus driving module library;and step 3, calling a module in the Modbus driving module library in the Simulink to build a Modbus communication model and generate codes, and deploying the Modbus communication model and the codes into the DSP.
- 2. The method of claim 1, wherein the calling a code inheritance tool LCT in step 2 creates a Modbus driver module for the Modbus driver code unit.
- 3. The method of claim 1, wherein the Modbus driver modules encapsulated in step 2 have corresponding user interaction interfaces.
- 4. The method of claim 1, wherein the code related to hardware driving is code related to operation of an associated peripheral register in the DSP.
- 5. The method according to claim 1, wherein the step 2 specifically comprises:step 2.1, setting codes related to hardware driving in a Modbus driving code unit as notes, so that the codes are free from compiling;step 2.2, calling a code inheritance tool LCT to initialize a function written in a C language in a Modbus driving code unit into an LCT structure body, and designating parameters of the LCT structure body;step 2.3, calling a code inheritance tool LCT to generate an S-Function source file for the Function, compiling and linking the S-Function source file to generate a mexw64 executable file, and further creating a Modbus driving module for building and simulating a Simulink model;step 2.4, calling a code inheritance tool to generate a tlc file required by generating a model code subsequently;step 2.5, restoring the annotated codes related to the hardware driving part;step 2.6, repeatedly executing the sub-steps on all code units of the driving module to be created;and 2.7, packaging the created Modbus driving modules, and arranging and archiving the packaged Modbus driving modules to form a Modbus driving module library.
- 6. The method according to claim 5, wherein in step 2.1, the function definition part in the source file annotates all the code segments inside the function body; only a conditional compiling part for avoiding redefinition of the header file is reserved in the header file, and all the rest is annotated.
- 7. The method of claim 1, wherein the Modbus driver code unit comprises an initialization unit and a data transceiver unit;the initialization unit comprises a parameter configuration module and a port initialization module;the data receiving and transmitting unit comprises a data receiving module, a receiving timeout detection module, a message frame analysis and slave response module;the parameter configuration module is used for distributing storage space and configuring equipment addresses; the resource size required by each storage block is configured in the allocation of the storage space; the equipment address configuration designates the ID of the slave equipment as the unique identification of the slave equipment in the communication network;the port initialization module is used for initializing the port, and initializing the serial port peripheral equipment and the GPIO corresponding to the DSP according to the selected port mode;the data receiving module is invoked in the serial port receiving interrupt, receives a single character when the receiving interrupt comes, and stores the single character in the message buffer area;the receiving timeout detection module is invoked in the timer interrupt, and the module judges the time interval condition of the received characters by using a timer so as to judge the termination of a frame of information;the message frame analysis and slave response module is invoked in the idle task block and is used for analyzing the received complete message frame and returning a response after the complete message frame is received by the slave device.
- 8. The method of claim 7, wherein the port mode comprises three of RS485, RS232, and RS485& RS 232.
- 9. The method of claim 7, wherein the data receiving module comprises two types of RS485 data receiving module and RS232 data receiving module.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202310577741.5A CN116450109A (en) | 2023-05-19 | 2023-05-19 | Modbus communication library adaptation method under MATLAB and CCS combined development mode |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202310577741.5A CN116450109A (en) | 2023-05-19 | 2023-05-19 | Modbus communication library adaptation method under MATLAB and CCS combined development mode |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN116450109A true CN116450109A (en) | 2023-07-18 |
Family
ID=87135791
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202310577741.5A Pending CN116450109A (en) | 2023-05-19 | 2023-05-19 | Modbus communication library adaptation method under MATLAB and CCS combined development mode |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN116450109A (en) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN116861823A (en) * | 2023-07-27 | 2023-10-10 | 南京初芯集成电路有限公司 | Chip design method for reducing front-end design process |
-
2023
- 2023-05-19 CN CN202310577741.5A patent/CN116450109A/en active Pending
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN116861823A (en) * | 2023-07-27 | 2023-10-10 | 南京初芯集成电路有限公司 | Chip design method for reducing front-end design process |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US7464016B2 (en) | Hot plug and hot pull system simulation | |
| US6708329B1 (en) | Method and apparatus for producing modules compatible with a target system platform from simulation system modules utilized to model target system behavior | |
| Fernandes et al. | VHDL generation from hierarchical Petri net specifications of parallel controllers | |
| WO1996002039A1 (en) | Hardware design verification system and method | |
| CN108038294B (en) | UVM environment building method and system | |
| Herrera et al. | Systematic embedded software generation from SystemC | |
| CN101231589B (en) | System and method for developing embedded software in-situ | |
| CN116450109A (en) | Modbus communication library adaptation method under MATLAB and CCS combined development mode | |
| CN116681013B (en) | Simulation verification method, platform, device, equipment and medium of network chip | |
| US7469359B2 (en) | Method and apparatus for testing communication software | |
| US20030106042A1 (en) | System and method for animating state diagram through debug connection | |
| CN112202798B (en) | Data protocol conversion method, system, electronic device and storage medium | |
| CN111142861B (en) | Method and device for integrating structured comprehensive control system | |
| CN115827285B (en) | Cross-platform communication method, system, device, equipment and medium | |
| US7028283B1 (en) | Method of using a hardware library in a programmable logic device | |
| US7552440B1 (en) | Process communication multiplexer | |
| US7305633B2 (en) | Distributed configuration of integrated circuits in an emulation system | |
| CN111371799B (en) | Method, device and equipment for controlling data receiving and transmitting of MCTP (Multi-channel media Port) controller | |
| CN114428702A (en) | Information physical test system containing general interface module | |
| US7702764B1 (en) | System and method for testing network protocols | |
| CN113703339A (en) | Automatic driving simulation method, device, equipment and storage medium | |
| CN113609052A (en) | Chip simulation system based on FPGA and microprocessor and implementation method | |
| CN112230848A (en) | NVM automatic configuration method, device and equipment | |
| CN117648211B (en) | Runtime unified interface, server and calling method of artificial intelligent framework | |
| CN115509146B (en) | Distributed communication resource integration method for flight maintenance simulator |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination |