Modbus communication library adaptation method under MATLAB and CCS joint development mode

Abstract

The application discloses a Modbus communication library adaptation method under a MATLAB and CCS combined development mode, which comprises the following steps: writing a Modbus drive code unit, creating a Simulink module for the Modbus drive code unit by using a code inheritance tool, setting the code related to a DSP hardware drive to a state of exempting from compilation and completely reserving during the creating process, restoring the code related to the DSP hardware drive to an executable state after the creating process, encapsulating a plurality of created Modbus drive modules to form a Modbus drive module library, calling the modules in the Modbus drive module library in Simulink to build a Modbus communication model and generate code, and deploying the code to a DSP. The method can break away from the limitation of hardware resources provided by MATLAB for DSP development, quickly complete Modbus-based communication development based on the self-written Modbus drive code, and has the advantages of high development efficiency, easy integration and the like.

Description

Technical Field

[0001] This invention relates to the field of model design and automatic code generation, and in particular to a Modbus communication library adaptation method under the joint development approach of MATLAB and CCS. Background Technology

[0002] Currently, the MATLAB and CCS joint development approach relies on a hardware support package jointly developed by TI and MathWorks, opening up new avenues for embedded development: executable DSP code can be directly generated from Simulink models. Compared to embedded software development methods that rely on editing C code, this approach offers higher visibility, stronger portability, and allows for logic simulation on Simulink, simplifying testing. MATLAB provides a corresponding hardware support package for DSP low-level driver development and supports the generation of target code for the hardware support package and its built-in Simulink modules, but it lacks direct support for peripheral development needs in embedded systems. Furthermore, MATLAB does not yet have a dedicated support package for the Modbus protocol for DSP development, making it impossible to directly utilize Simulink modules to build Modbus communication models.

[0003] In patent application CN201310675197.4, entitled "Method for Implementing MODBUS Asynchronous Serial Communication Protocol using DSP," the Modbus protocol is developed using a DSP as the core through program design. This requires programmers to be proficient in the characteristics and structure of the hardware and its dedicated programming language, making it quite difficult. In patent application 201810144868.7, entitled "Method for Code Generation Using Simulink Custom Microcontroller Low-Level Drivers," a low-level module library based on automatic code generation technology is designed by writing S-function scripts and TLC files for code generation. This achieves the goal of encapsulating handwritten code into Simulink modules in MATLAB. However, this method still requires understanding the S-function and TLC file structure, and on this basis, it requires manually writing some configuration files; it also cannot handle cases where compilation fails when the code contains related hardware registers.

[0004] To address the issue that the limitations of Simulink's hardware resources prevent the rapid construction of Modbus communication models using Simulink modules during DSP development based on model design methods, a Modbus communication library adaptation method under the joint development approach of MATLAB and CCS is urgently needed to support the rapid development of Modbus communication functions on DSPs. Summary of the Invention

[0005] In view of this, the purpose of this invention is to provide a Modbus communication library adaptation method under the joint development of MATLAB and CCS, so as to solve the problem that in the process of developing DSP using the model-based design method, the limitations of the hardware resources provided by Simulink for DSP development make it impossible to directly use the modules in Simulink to quickly complete the Modbus communication model construction.

[0006] The Modbus communication library adaptation method under the joint development approach of MATLAB and CCS in this invention

[0007] Step 1: Write Modbus driver code to obtain Modbus driver code unit, which includes code related to DSP hardware driver;

[0008] Step 2: Use the code inheritance tool to create a Simulink module for the Modbus driver code unit. During the creation process, set the code involving DSP hardware drivers to be uncompilable and retain it completely.

[0009] After creation, the code involving DSP hardware drivers is restored to an executable state, and the multiple created Modbus driver modules are encapsulated to obtain multiple encapsulated Modbus driver modules corresponding to the Modbus driver code units, forming a Modbus driver module library.

[0010] Step 3: In Simulink, call the modules in the Modbus driver module library to build the Modbus communication model and generate code, and then deploy it to the DSP.

[0011] Furthermore, in step 2, the code inheritance tool LCT is invoked to create a Modbus driver module for the Modbus driver code unit.

[0012] Furthermore, the Modbus driver module encapsulated in step 2 has a corresponding user interface.

[0013] Furthermore, the code involving hardware drivers refers to code that involves operations on relevant peripheral registers in the DSP.

[0014] Furthermore, step 2 specifically includes:

[0015] Step 2.1: Comment out the hardware driver-related code in the Modbus driver code unit to prevent that part of the code from being compiled.

[0016] Step 2.2: Call the code inheritance tool LCT to initialize the functions written in C language in the Modbus driver code unit into LCT structures, and specify the LCT structure parameters;

[0017] Step 2.3: Use the code inheritance tool LCT to generate an S-Function source file for the function, and compile and link the S-Function source file to generate a .mexw64 executable file, which is then used to create a Modbus driver module for Simulink model building and simulation.

[0018] Step 2.4: Use the code inheritance tool to generate the tlc file required for subsequent model code generation;

[0019] Step 2.5: Uncomment the code related to the hardware driver;

[0020] Step 2.6: Repeat the above sub-steps for all code units of the driver modules to be created;

[0021] Step 2.7: Package the created Modbus driver module, and organize and archive the packaged Modbus driver module to form a Modbus driver module library.

[0022] Furthermore, in step 2.1, all code segments inside the function body in the function definition section of the source file are commented out; in the header file, only the conditional compilation section used to avoid header file redefinition is retained, and the rest are commented out.

[0023] Furthermore, the Modbus driver code unit includes an initialization unit and a data transceiver unit;

[0024] The initialization unit includes a parameter configuration module and a port initialization module;

[0025] The data transceiver unit includes a data receiving module, a receiving timeout detection module, a message frame parsing and slave response module;

[0026] The parameter configuration module is used for storage space allocation and device address configuration; the storage space allocation configures the resource size required for each storage block; the device address configuration specifies the slave device ID, which serves as the unique identifier of the slave device in the communication network;

[0027] The port initialization module is used for port initialization, and initializes the corresponding serial port peripherals and GPIO on the DSP according to the selected port mode.

[0028] The data receiving module is called during the serial port receive interrupt, and receives a single character and saves it to the message buffer when the receive interrupt occurs.

[0029] The receive timeout detection module is called in the timer interrupt. This module uses the timer to determine the time interval of received characters, and then determines the termination of a message frame.

[0030] The message frame parsing and slave response module is called in the idle task block. It is used to parse the received complete message frame and return a response after the slave device receives the complete message frame.

[0031] Furthermore, the port modes include three types: RS485, RS232, and RS485 & RS232.

[0032] Furthermore, the data receiving modules include two types: RS485 data receiving modules and RS232 data receiving modules.

[0033] The beneficial effects of this invention are as follows: The Modbus communication library adaptation method provided by this invention can get rid of the limitations of hardware resources provided by MATLAB for DSP development. By utilizing special processing in the module creation process, it is possible to quickly complete the Modbus-based communication development based on self-written Modbus driver code, and at the same time, it is possible to realize the self-customization of Modbus communication function modules to meet various communication needs. Attached Figure Description

[0034] Figure 1 This is a flowchart of the Modbus communication library adaptation method under the joint development mode of MATLAB and CCS in this embodiment of the invention.

[0035] Figure 2 This is a schematic diagram of the Modbus driver code unit in an embodiment of the present invention;

[0036] Figure 3 for Figure 1 The flowchart shows the steps involved in S21 calling LCT to create a Modbus driver module for the Modbus driver code unit. Detailed Implementation

[0037] The present invention will be further described below with reference to the accompanying drawings and embodiments.

[0038] The specific implementation methods provided by this invention are based on the DSP28335 hardware platform and the MATLAB software platform, and are illustrated with an application example of Modbus communication using the RS485 bus.

[0039] A specific embodiment of the present invention discloses a Modbus communication library adaptation method under the joint development approach of MATLAB and CCS. Please refer to [link / reference]. Figure 1 This includes steps S1 to S4:

[0040] S1. Independently write Modbus driver code to obtain the Modbus driver code unit. See the example of the Modbus driver code unit for details. Figure 2 It includes an initialization unit 1 and a data transceiver unit 2. The initialization unit 1 includes a LibModbusParameter configuration module 11 and a LibModbusInit port initialization module 12; the data transceiver unit 2 includes a LibModbus Receive RS232 / RS485 data receiving module 21, a LibModbus Timer Step receive timeout detection module 22, and a LibModbus Thread message frame parsing and slave response module 23.

[0041] The Libmodbus Parameter configuration module 11 is used for storage space allocation and device address configuration. The Modbus protocol allows devices to map four different data types to independent storage blocks and use different function codes to access different types of data. Storage space allocation configures the resource size required for each storage block; device address configuration specifies the slave device ID, which serves as a unique identifier for the slave device in the communication network.

[0042] The LibModbus Init port initialization module 12 is used for port initialization and has three modes to choose from: RS485, RS232, and RS485 & RS232. This module will initialize the corresponding serial peripherals and GPIO on the DSP according to the selected port.

[0043] The LibModbus Receive RS232 / RS485 data receiving module 21 is called in the serial port receive interrupt. It is divided into an RS485 data receiving module and an RS232 data receiving module according to the communication hardware interface circuit. When the receive interrupt occurs, it receives a single character and saves it to the message buffer.

[0044] The LibModbus Timer Step receive timeout detection module 22 is invoked in a timer interrupt to determine data timeout conditions. In the reception of a complete data frame, the entire data frame must be transmitted as a continuous stream. If the time interval between two complete message frames is greater than 3.5 character intervals, the receive timeout detection module determines the termination of a message frame based on the time interval of the received characters. In this module, if the detected receive interval exceeds 4 system step times, it is determined that a message frame has been terminated.

[0045] The LibModbus Thread message frame parsing and slave response module 23 is called in the Simulink idle task block. Upon receiving a complete message frame, the slave parses the received message frame and returns a response. Specifically, it checks if the ID number in the received message frame matches the slave device; if not, it ignores the frame. Otherwise, it performs a CRC check on the data frame to prevent the slave from responding to message frames that have transmission errors during communication. The data segment in the message frame contains additional information about the function the slave needs to perform. This data segment is parsed, and a response frame encapsulated in a specific format is returned to respond to the master's request.

[0046] S2. Use the code inheritance tool to create Simulink modules for the Modbus driver code units. During the creation process, set the code involving the DSP hardware driver to an uncompilable state and retain it completely. After creation, restore the code involving the DSP hardware driver to an executable state, encapsulate it to obtain the Modbus driver module corresponding to each Modbus driver code unit, and form a Modbus driver module library. The specific steps are S21 to S23:

[0047] S21. Use MATLAB's code inheritance tool LCT to create a Modbus driver module for the Modbus driver code unit described in step S1. For detailed steps, please refer to [link to steps]. Figure 3 Including S211 to S215:

[0048] S211. Comment out the code involving the hardware driver to prevent it from being compiled. Since the compiler used in the code inheritance tool is a C compiler, not a compiler specific to the target DSP hardware, the code involving GPIO and SCI peripheral registers defined in the target DSP28335 will fail to compile. Therefore, the code involving the hardware driver is temporarily commented out; this will be restored in subsequent steps and will not affect the calling of the hardware driver code. Specifically, the code involving the hardware driver refers to operations on the relevant peripheral registers in the DSP.

[0049] As an improvement to the above embodiments, in specific implementation, all code segments inside the function body in the function definition section of the source file are commented out; only the conditional compilation section used to avoid header file redefinition is retained in the header file, and the rest are all commented out. In this way, it is not necessary to analyze the code line by line to find the exact line of code involving the hardware driver, which is simpler and faster for operators.

[0050] S212. The code inheritance tool LCT is invoked to initialize the LCT structure for functions written in C language, and the LCT structure parameters are specified. The LCT structure parameters include: the path to the driver source code and header file, the S-Function name, and the exported function declaration.

[0051] S213. Call the code inheritance tool LCT to generate S-Function source files for C functions, and compile and link the S-Function source files to generate .mexw64 executable files, which are then used to create a driver module for Simulink model building and simulation.

[0052] S214. Call the code inheritance tool LCT to generate the tlc file required for subsequent model code generation.

[0053] S215. After completing the above steps, restore the commented-out code from step S211.

[0054] Prior to this step, the code involving hardware drivers was set to an uncompilable state, which allowed the aforementioned LCT-based steps to proceed smoothly. This is because, based on the existing LCT, if a code unit contained hardware driver-related code, the aforementioned steps would result in errors, preventing further progress. Furthermore, the process of creating a module using LCT does not actually modify the code unit itself; its compilation process can be understood as a validity check. In other words, as long as this check passes, the code in the code unit will be executed unchanged in subsequent encapsulation, model building, simulation, and deployment steps. Therefore, by restoring the commented-out code in step S211, these hardware driver-related codes can be executed in subsequent steps.

[0055] By analogy, steps S211 to S215 are repeated for the source files and header files of all the functions defined in the driver modules to be created, until all the functional modules required in the Modbus communication library are created.

[0056] S22. Perform module encapsulation and design the user interface. Use the Mask Editor to complete the module encapsulation, enabling the module to interact with the user.

[0057] S23. Create a Modbus driver module library. Organize and archive all the encapsulated Modbus driver modules, and add them to the Simulink browser library for easy reuse.

[0058] S3. In Simulink, call the Modbus driver module from the Modbus driver module library to build the Modbus communication model and generate code, and deploy it to the DSP28335 hardware test platform. Some necessary non-Modbus driver modules can be functional modules from the TI C2000 hardware support package. When building the Modbus communication model, model parameter configuration is required, including configuring the SCI serial communication parameters and system step size. These configurations can be completed through the user interface added during module encapsulation.

[0059] In this embodiment, since the DSP hardware test platform uses SCIB to expand the RS485 communication interface, the SCIB serial communication parameters should be configured as follows: start bit 1, data length 8, no parity check, stop bit 1, that is, 10 bits are required to transmit 1 character of data; in this embodiment, the SCIB serial communication baud rate (BaudRate) is set to 115200, and the system step size is set to 0.0001.

[0060] As an improvement to the above embodiments, the system step size setting can adopt other settings. In different embodiments, other parameters can also be considered for the SCI serial communication parameters and the system step size. It should be noted that the system step size, i.e., the timer timing period, is related to Modbus communication timeout handling and packet operation. In this embodiment, the Modbus adapter layer's receive timeout detection module considers an interval greater than 4 system steps (Fixed Step Size) as a timeout. Improper system step size configuration will affect the normal operation of Modbus communication. Therefore, the system step size setting should adapt to changes in SCI communication parameters, specifically following the following relationship:

[0061] Fixed Step Size≥(3.5*N) / (4*Baud Rate)

[0062] Where N is the number of binary bits required to transmit one character, and in this embodiment N = 10.

[0063] S4. Connect the DSP28335 hardware test platform to the host computer and use MODSACN32 software to observe the data interaction under Modbus communication.

[0064] Configure communication parameters in the MODSACN32 software connection settings, including: baud rate, word length, parity, and stop bits; select the Modbus protocol as the standard RTU transmission mode; the MODSACN32 can establish a connection once it recognizes a valid COM port.

[0065] In this embodiment, the connection settings are configured with a baud rate of 115200, a word length of 8, no parity, and 1 stop bit. It should be noted that these parameters are the same as the serial communication parameters configured for SCIB in step S3.

[0066] The correctness of the Modbus driver module design was further verified by observing data interaction through the Memery Copy module in Simulink. A variable data module was created within a timer interrupt, updating the data periodically. This data was then stored in the Modbus input register via the Memery Copy module. In the MODSACN32 software, the RS485 device ID was selected, and function code 04 was called to observe data changes. If the data was updated periodically, it indicates that the register operations based on Modbus communication are functioning correctly. The coil register value was modified in the MODSACN32 software, and the coil's on / off state was sent to the GPIO via the Memery Copy module. The on / off state of an onboard LED was used to simulate the coil's operation. If changing the coil register value in the MODSACN32 software controlled the LED's on / off state, it indicates that the coil operations based on Modbus communication are functioning correctly.

[0067] The above description is only a preferred embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any changes or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in the present invention should be included within the scope of protection of the present invention.

Claims

1. A Modbus communication library adaptation method under the joint development approach of MATLAB and CCS, characterized in that, Includes the following steps: Step 1: Write Modbus driver code to obtain Modbus driver code unit, which includes code related to DSP hardware driver; Step 2: Use the code inheritance tool to create a Simulink module for the Modbus driver code unit. During the creation process, set the code involving DSP hardware drivers to be uncompilable and retain it completely. After creation, the code involving DSP hardware drivers is restored to an executable state, and the multiple created Modbus driver modules are encapsulated to obtain multiple encapsulated Modbus driver modules corresponding to the Modbus driver code units, forming a Modbus driver module library. Step 3: In Simulink, call the modules in the Modbus driver module library to build the Modbus communication model and generate code, and then deploy it to the DSP.

2. The method according to claim 1, characterized in that, In step 2, the code inheritance tool LCT is called to create a Modbus driver module for the Modbus driver code unit.

3. The method according to claim 1, characterized in that, The Modbus driver module encapsulated in step 2 has a corresponding user interface.

4. The method according to claim 1, characterized in that, The code involving the DSP hardware driver refers to the code that involves operations on the relevant peripheral registers in the DSP.

5. The method according to claim 1, characterized in that, Step 2 specifically includes: Step 2.1: Comment out the hardware driver-related code in the Modbus driver code unit to prevent that part of the code from being compiled. Step 2.2: Call the code inheritance tool LCT to initialize the functions written in C language in the Modbus driver code unit into LCT structures, and specify the LCT structure parameters; Step 2.3: Use the code inheritance tool LCT to generate an S-Function source file for the function, and compile and link the S-Function source file to generate a .mexw64 executable file, which is then used to create a Modbus driver module for Simulink model building and simulation. Step 2.4: Use the code inheritance tool to generate the tlc file required for subsequent model code generation; Step 2.5: Uncomment the code related to the hardware driver; Step 2.6: Repeat steps 2.1-2.5 for all code units of the driver modules to be created; Step 2.7: Package the created Modbus driver module, and organize and archive the packaged Modbus driver module to form a Modbus driver module library.

6. The method according to claim 5, characterized in that, In step 2.1, all code segments inside the function body in the function definition section of the source file are commented out; in the header file, only the conditional compilation section used to avoid header file redefinition is retained, and the rest are commented out.

7. The method according to claim 1, characterized in that, The Modbus driver code unit includes an initialization unit and a data transceiver unit; The initialization unit includes a parameter configuration module and a port initialization module; The data transceiver unit includes a data receiving module, a receiving timeout detection module, a message frame parsing and slave response module; The parameter configuration module is used for storage space allocation and device address configuration; the storage space allocation configures the resource size required for each storage block; the device address configuration specifies the slave device ID, which serves as the unique identifier of the slave device in the communication network; The port initialization module is used for port initialization, and initializes the corresponding serial port peripherals and GPIO on the DSP according to the selected port mode. The data receiving module is called during the serial port receive interrupt, and receives a single character and saves it to the message buffer when the receive interrupt occurs. The receive timeout detection module is called in the timer interrupt. The receive timeout detection module uses the timer to determine the time interval of received characters, and then determines the termination of a message frame. The message frame parsing and slave response module is called in the idle task block. After receiving a complete message frame, the slave device parses the received complete message frame and returns a response.

8. The method according to claim 7, characterized in that, The port modes include RS485, RS232, and RS485 & RS232.

9. The method according to claim 7, characterized in that, The data receiving modules include two types: RS485 data receiving modules and RS232 data receiving modules.

Images